软件测试操作指南和规范

1、软件测试操作指南1 概述1.1 目的为确保软件产品质量，使产品能够顺利交付和通过验收，同时提升测试组的工作秩序与效率，特编写本文档，以作参考。1.2 对象范围本文档适用于测试人员在项目不同阶段（内网环境测试及正式环境测试）的功能测试。2 职责Ø 配合产品经理、项目经理了解需求Ø 编写测试计划、测试方案、搭建测试环境Ø 完成所承担的测试任务，并按要求提交Bug、优化建议等到Bug管理平台（禅道）。Ø 配合开发人员修复Bug、回归Bug。Ø 配合项目的顺利发布。3 测试流程3.1 前期准备3.1.1 需求详细的需求是测试的重点依据， 因此测试人员需

2、提前介入，充分了解需求。3.1.2 原型与设计原型，是需求和功能的具象化表达，它能帮助测试人员更形象的了解各个需求与功能的实现。UI设计图，是在原型的基础上综合考虑产品目标、功能需求场景、用户体验等因素后设计出的产品各版块、界面和元素。是测试最终的参考依据。因此测试人员必须对认真阅读，真正弄懂系统需求和详细设计。3.2 制订测试计划与方案在测试之前，测试人员需根据项目需求制定测试计划与方案，其内容应包括以下内容： Ø 测试时间安排；Ø 测试人员安排；Ø 测试环境、工具和测试软件等；Ø 测试用例、测试数据和预期的结果。3.3 编写测试用例测试点将测试模块分

3、解成多个功能点，测试点应涵盖功能点，也涵盖了正常测试和异常测试。输入数据 输入数据包括： 界面输入数据 数据库的初始数据 其他外部输入数据等输入数据尽可能全面详细列出，并具有典型性。全面是指：数据能达到模块所涉及的全部功能，典型是指这个数据能充分反映功能特点。测试描述 测试描述，即测试过程中的具体操作步骤，包括：（1） 前置条件：测试执行时所必须的条件，即发生这个用例的前提条件；（2） 所执行的动作：包括鼠标、键盘、加载外部数据等操作；（3） 系统的反应：包括光标定位、光标聚焦、显示字段值、按钮的状态、系统提示和消息等。预期输出数据 按准备的输入数据和设计的测试过程，模块应输出的数据。 输出数

4、据包括：屏幕输出数据、输出到数据库的数据、输出到其他外部地方的数据，并指出断点结果或最终结果。3.4 功能测试功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。3.4.1 Web功能测试在Web功能测试过程中，常用的测试方法如下3.4.1.1 链接测试测试每一个链接是否都有对应的页面，并且页面之间切换正确。3.4.1.2 表单测试当用户在web应用系统上向服务器提交信息时，就需要使用表单操作，在表单测试过程中，一般关注N点（1） 格式规范：空格检查、输入法半角全角检查、密码检查、字符串长度检查、字符类型检查、标点符号检查、特殊字符检查、中文字符处理

5、等；（2） 提交信息完整性：比如，用户注册，登录，信息变更等等；这种情况下，我们必须测试提交信息的完整性，以检验提交给服务器的数据的正确性 ；（3） 考虑常理逻辑，如：出生日期、工作年限是否恰当，填写手机号码的表单是否符合号码逻辑，所在地省份城市区域间的匹配等，如果设定使用默认值，也需要测试。3.4.1.3 导航测试 所谓的导航测试，就是在不同的页面跳转之间，或者按钮，对话框，列表以及窗口等，通过考虑这些因素，去判断一个应用系统是否易于导航：是否直观？系统的主要模块是否可以通过主页访问或者到达？站点是否需要站内地图或者搜索引擎等其他帮助？web系统导航的另外一个重点就是页面结构、导航、菜单、风

6、格等是否一致，确保用户可以凭借直觉或者简单的判断就可以找到自己想要的内容。3.4.1.4 图形测试即UI界面测试，其中包括图片、动画、边框、颜色、字体、背景、按钮等等。其中要考虑的几个重点：（1） 界面是否符合系统现有逻辑，是否符合需求，（2）图片有明确的用途、代表，如：常见的分享按钮，是否使用准确，让用户看图即能知其意（3）页面整体风格是否和系统的用途一致（4）背景颜色，字体，搭配是否合理（5）整体界面测试，常说的用户体验。用户浏览时是否感觉舒适，整体风格等等3.4.1.5 相关性测试（1）功能相关性：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。常见的情况是，增加

7、某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形；（2）数据相关性：下拉列表默认值检查，下拉列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见；（3）内容相关性：主要用来检测web系统提供信息的准确性、相关性。比如：商品的价格，文字描述；信息的准确性，是否有拼写错误等。 3.4.1.6 兼容性测试Web兼容性测试，主要指浏览器兼容性。需适配的浏览器及其优先顺序为：IE 8.0+ 、360浏览器、chrome浏览器、Firefox浏览器、搜狗浏览器、QQ浏览器3.4.2 App功能测

8、试App测试包括android测试、iOS 测试，APP测试的时候，建议让开发打好包APK和IPA安装包，测试人员自己安装应用，进行测试。在测试过程中需要注意的测试点如下：安装和卸载（1） 应用是否可以在IOS不同系统版本或android不同系统版本上安装（iOS 系统需适配iOS 8.0+ 、android需适配4.4 +）（2）软件安装后是否可以正常运行，安装过程中是否可以取消，安装空间不足时是否有相应提示；（3）是否可以正常卸载，若卸载过程中出现死机，断电，重启等意外的情况，待环境恢复后是否可以正确卸载，卸载是否支持取消功能，单击取消后软件卸载情况是否正常。运行（1）测试APP安装完成后

9、，是否可以正常打开软件APP运行时，是否有加载图示（2）APP的速度是可以让人接受，切换是否流畅 （3）用户登录状态太久，session会过期，会出现“虽然是登录状态，系统会提示用户没有登录。异常测试异常指非正常性用户操作，如：手机断网、中途电话接入、手机断电等异常情况。（1）对于无网络时，是否可以浏览本地数据，不能获取数据时，能否给出友好提示，离线获取不到数据时，离线后又连上网，能否重新获取数据。（2）退出APP再开启APP时，是否能正常浏览；切换到后台再切回APP应用时可以正常浏览；锁屏后再解锁回到应用前台可以正常浏览；（3）正在操作App时，突然电话接入或突然离线，是否对操作有影响等。（

10、4）反复操作某个功能，不断点击，刷新时，是否会闪退数据更新（1）确认有数据更新后，哪些地方需要手动刷新，哪些地方需自动刷新。（2）确认从后台切换回前台时，哪些页面需要进行数据更新（3）根据需求和逻辑，确认哪些数据是从服务端请求实时响应，哪些是缓存到本地的数据。软件更新当客户端有新版本时，有更新提示软件更新一定要测，确保android软件更新可以正确更新新版本，且安装运行正确。（iOS软件更新必须从苹果应用商店App Store中更新 ) 用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提提示。当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的

11、功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）网络环境（1）测试G、，wifi 网络下应用运应的速度（2）内网测试时，选择到外网操作是否有异常处理（3）网络不好时 ， 提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒（4）有网到无网再到有网环境时，数据是否可以自动恢复，正常加载3.4.1.7 其他链接测试、导航测试、图片测试、内容测试、UI测试等各项功能测试，与Web功能测试类似，此处不做详细描述。3.5 回归测试回归测试是指开发人员修复bug后，重新进行测试以确认修改完成，以及没有引入新的错误或导致其他模块错误。回归测试过程如下：(1) 准确辨别出系统被修改

12、的部分；(2) 从测试用例库中，排除所有不再适用的测试用例，如果必要，适当增加新用例，形成新的测试用例库。(3) 依据新的测试用例，执行修改后的系统。3.6 版本发布版本发布的准则系统经过所有测试项后，必须符合以下标准n 致命错误：无n 功能错误：无n 功能及界面小Bug：项目经理、测试负责人审核通过n 优化及建议：项目经理、测试负责人审核通过若不满足以上要求，视为不合格。版本发布流程 3.7 测试流程图4 Bug(Bug)管理4.1 Bug管理工具测试组目前使用的Bug管理工具是“禅道”。禅道是集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体的一款开源的研发项目管理。测试组

13、使用禅道提Bug、管理Bug、回归Bug以及记录和执行测试用例。下图为禅道测试界面。禅道使用网址：:8086/zentao 禅道的详细使用手册见：l4.2 Bug的定义及其基本属性Bug是指在系统开发过程中的针对系统产品和开发过程中的问题，这些问题已经影响或可能会影响软件产品的质量。Bug应该具备以下属性，也就是往Bug管理库或者Bug列表中提交的Bug应该具备以下属性：属性名称描述Bug标识(ID)标记某个Bug的一组符号，每个Bug必须有一个唯一的标识Bug类型根据Bug的自然属性划分的Bug种类Bug验证程度因Bug引起的故障对软件产品的影响程度Bug所处的模块或子系统Bug分步的模块或

14、子系统Bug出现几率指发现错误的几率Bug的重现步骤详细的Bug重现步骤附件与Bug相关的附件（截图、附件、用例等）备注对Bug的其他描述4.3 Bug分类根据Bug的定义，将Bug分为如下列：（1）功能错误（bug）：功能上的错误性bug（2）小错误/细节：小错误，不影响总体流程和功能（3）优化建议：功能已满足但待改善，属于改良性建议（4）需求变动：原有的需求基础上的更改（5）设计Bug：UI设计Bug4.4 Bug严重性定义Bug的严重程度反映的是对Bug的发现对象可能造成的影响或后果来定义的。Bug等级Bug性质描 述1致命错误系统崩溃、系统死锁以及产品的基本功能有致命影响的Bug等2严

15、重Bug严重错误，严重影响系统的使用3一般Bug次要错误、布局不合理、文字错误等4微小Bug基本不影响系统的运行和功能的实现。但是与标准、规范和定义不一致建议优化不在定义、标准、范围的定义和约束之内，但是从提出者来看是需要完善的建议4.5 Bug优先级定义Bug优先级描 述1需要立刻进行修改2一天到两天之内必须修改3Bug需要正常排队等待修复或列入软件发布清单4留到组后解决，如果项目的进度跟紧张可以在产品发布以前不解决4.6 Bug状态定义Bug状态描 述激活测试人员提交一个新的Bug，等待开发人员修改打回开发人员并未重新问题，或要求Bug的报告者再次对Bug进行说明已分派指Bug已经分派给相

16、关开发人员，等待修改已确认指Bug已被相关开发人员却，等待排期修改已解决指Bug已被修改，等待测试人员回归验证。关 闭测试人员回归验证Bug，并已经修复重新激活测试人员回归验证，但Bug并没有修改正确4.7 Bug管理流程5 处理机制5.1 退回机制若在测试过程中发生如下情况，可将系统退回到相关开发负责人员：（1）经过测试后，发现与需求不符，或功能项存在较大的差异（2）单一功能模块，测试过程中发现Bug较多或者无法继续进行下一步测试，继续测试无意义（3）测试过程中，频繁死机或系统崩溃5.2 异常情况处理机制非正常情况下，需要进行特别处理的情形，此情况需要主管领导批准、签字确认：（1）上线时间紧急的情况下，未经测试部充分测试就发布到外网环境（2）产品经理尚未进行验收测试就需要上线5.3 报告机制若出现以下情况，需要及时向部门领导和项目经理汇报的情况：（1）测试后期出现重大逻辑错误，修改测试影响上线时间（2） 测试过程中用户需求出现重大变更（3） 测试负责人定期汇报测试情况6 测试完成的标准6.1 被测试出的、在软件错误级别分类中定义的：Ø 一级Bug，致命错误，100%得到修改并且回归通过Ø 二级Bug，严重错误，100%得到修改并且回归通