02-软件测试工作流程详解

一、需求分析

       参与需求评审会议，阅读并理解需求，主要就是熟悉业务，分析需求有哪些测试点，可以使用思维导图来记录测试点。例如：

获取测试点的思路：

（1）首先检查界面元素的显示是否正确。

（2）测试页面表单功能是否正常。

（3）针对表单测试时，需要对表单中的每个字段依次进行测试。凡是用户可输入的输入框内容，都要使用等价类划分法和边界值分析法，根据字段的约束条件进行测试。

（4）如果多个字段之间有关联关系或制约关系，那么在测试完单个字段的等价类和边界值之后，应该继续使用判定表等测试方法进行组合测试。

（5）当单个页面的内容都测试完毕后，再结合场景法等测试系统操作流程相关内容。

（6）系统操作流程测试完毕后，最后再使用错误推测法来确保没有遗漏的测试点。

二、编写测试计划

        参考需求规格说明书，安排测试人员在什么期限内、要测试哪些模块、提交哪些文档。通俗来讲，就是安排什么人在什么时间做什么事，最后产出什么东西。

1、编写目的
        此文档根据项目需求说明书，制定测试策略、评估测试风险、确定所需的资源，并对测试的工作量进行估计，安排测试人员和进度，并且列出测试项目的可交付元素。

2、参考文档
        项目需求说明书、详细设计文档、设计原型等。

3、测试概要
（1）测试目标

• 测试已实现的产品是否满足需求，包括：各个功能点是否以实现，业务流程是否正确。
• 系统运行是否稳定。
• Bug数和缺陷率是否控制在可接收范围内，遗留bug一般不超过bug总数的10%。

（2）测试范围：最终需要交付的功能模块列表
（3）测试所需人力、资源是否满足
（4）测试环境：服务器环境、终端环境、网络环境等
（5）bug管理工具

4、测试规范
        开始测试的标准：代码编译通过，软件可以正常安装运行，冒烟测试通过等。
        中断测试的标准：安装无法正确完成、程序代码编译不通过、系统服务异常等。

5、bug严重程度

• 致命【例如：软件的意外退出甚至操作系统崩溃，造成数据丢失】
• 严重【例如：由于单功能失效导致多个相关功能失效】
• 一般【例如：软件的单个功能失效】
• 轻微【软件界面的细微缺陷，例如：某个控件没有对齐等】

6、测试策略
        冒烟测试：依据开发提测时间变动。
        第一轮功能测试：执行测试用例，包括边界值测试、兼容性测试、易用性测试、用户界面测试、安全性测试。
        第二轮功能测试：bug复测及功能验证。
        回归测试：全面回归测试。
        性能测试：需确认具体性能测试方案和工具。
        发布测试
        测试报告总结

7、测试风险
        测试时间不足、开发进度延误、难以修复缺陷、其它原因。

   

8、测试输出文档
        测试计划、测试用例、测试bug单、测试报告。

三、编写测试用例

        测试用例是一种用来具体说明如何执行测试操作并验证结果的文档。参考需求规格说明书、概要设计、详细设计等文档，编写测试用例，编写完成之后需要对其进行评审。

1、设计测试用例的方法

• 等价类划分法【在规定了输入数据必须遵守的规则后，可确定一个有效等价类，即遵守规则的；也可确定若干个无效等价类，即从不同角度违反规则的】
• 正交实验法【在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例】
• 边界值分析法【选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值】
• 错误推测法【在测试程序时，可以根据经验或直觉推测程序中可能存在的各种错误】
• 判定表法【适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略】
• 还有其它场景法和状态迁移法等

2、测试用例包含的字段
（1）用例编号【由字符和数字组成的字符串，具有唯一性、易识别性。例如：TC_Agileone_login_001，其中TC表示TestCase、Agileone表示系统名、login表示模块名、001表示用例编号】
（2）用例标题【用一句话来表述该条用例是测试哪个测试点的】
（3）优先级【一般分为高、中、低，用来对测试用例进行标记】
（4）预置条件【在执行该条用例时，系统需要预先达到的状态或条件】

（5）创建人

（6）创建时间

（7）所属模块
（8）操作步骤【执行当前用例需要执行的操作步骤，需要明确的给出每一个步骤的描述】
（9）预期结果【来自于需求，要求测试达到的结果】

（10）实际结果【实际操作系统之后得到的结果】

（11）测试结果【pass / fail / NA，其中pass表示预期结果与实际结果相同、fail表示预期结果与实际结果不相同、NA表示当前用例或模块无法操作】

   

3、建立需求跟踪矩阵

        根据产品需求、测试点和测试用例，建立一个三者映射关联的列表，这个表就叫做需求跟踪矩阵。其作用是：方便进行用例需求覆盖率的统计；若需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新。

四、测试执行

        测试过程中发现bug，需要提交给开发人员进行修改，然后进行回归测试，验证开发人员是否修改完成。

1、测试环境搭建
        测试环境：硬件环境、软件环境
        硬件环境：测试必须的服务器、网络连接设备、打印机等硬件设备构成的环境。
        软件环境：被测软件运行的操作系统、数据库以及其它应用软件构成的环境。

   

2、执行测试用例
        根据测试用例优先级来执行测试用例

   

3、测试执行流程

        项目提测 - 冒烟测试 - 系统测试 - 回归测试 - 验收测试。

• 冒烟测试：对提测的项目基本功能进行粗略测试，检查基本功能是否正常。
• 系统测试：使用测试用例，对系统进行充分测试，当发现bug时，需要提交开发人员进行修改。
• 回归测试：当开发人员修改完bug后，需要让测试人员重新进行测试，检查bug是否修改完成、是否引入了新的bug。
• 验收测试：以用户为主，根据验收清单上规定的内容对最终产品进行测试。

        注：不同类型测试需要产出相对应的测试报告和缺陷报告，并将缺陷提交到缺陷管理库中。

五、编写测试报告

        编写测试报告，确认是否可以上线。

1、测试报告

        测试报告模板：测试报告模板-资源下载。一般来说，公司会有其自己的测试报告模板，根据模板填写相关内容即可。

   

2、缺陷报告
（1）缺陷编号【由字符和数字组成的字符串，具有唯一性、易识别性。例如：Bug_Agileone_login_001，其中Bug表示缺陷、Agileone表示系统名、login表示模块名、001表示缺陷编号】
（2）用例编号【说明是执行哪个测试用例时，出现了该缺陷】
（3）测试模块
（4）预置条件
（5）Bug标题
（6）测试步骤【通过什么样的操作，可以复现该bug】
（7）预期结果
（8）实际结果

（9）缺陷状态

（10）严重程度【致命、严重、一般、轻微】

（11）优先级【高、中、低】

（12）重现率【该bug出现的概率】

（13）指派【指派给谁进行处理】

（14）测试环境

（15）软件版本

（16）测试日期

（17）测试人员

（18）附件【注：最好附加上一些截屏图片或log日志】

（19）备注

   

3、如何处理不能重现的缺陷？

（1）一定要详细描述遇到缺陷的过程和相关环境配置，如果有日志的话，一定要附上相关的操作日志或者系统运行日志。

（2）对于不可重现的缺陷，一定要尽量描述清楚复现率是多少。例如：10次测试中只出现了3次，那么复现率为30%。

（3）对于不可重现的缺陷，当开发人员将缺陷设置为fixed之后，在验证时，不能只在一个版本上验证缺陷是否修复，至少要在3个以上的版本中验证都没问题，才能将缺陷关闭。