软件测试流程

引言 

在实际的测试工作中，不同的公司有不同的流程，但一般来说，必要的流程都会经历：需求阶段、开发阶段、测试阶段和发布上线几个阶段。

各阶段流程图如下：

一、需求阶段

1.需求文档

需求文档的形式要落实到文字上，避免口头描述，方便产品、开发、测试对需求有统一的理解和依据。

2.需求评审

开发、测试拿到产品的需求文档后，需提前阅读并标记出有疑问的地方，在需求评审会上提出，并沟通达成一致。针对会上提出的修改点，会后进行需求文档的修改，修改完成后及时同步开发测试。

3.排期计划

按照新版本的需求文档，重新评估工作量（开发周期和测试周期）。

二、开发阶段

1.开发设计

测试人员有条件的话，都应参与到开发的设计评审和接口评审中，这样可以帮助测试人员理解开发设计的思路和逻辑，有助于更全面的了解系统，对测试用例的设计起到帮助作用。另外，测试人员可以及早发现开发设计上的错误和遗漏，将维护成本降到最低。

2.接口文档

开发要写接口文档，方便测试过程中查阅。

3.用例设计

测试人员根据需求文档分解出测试功能点，根据功能点设计测试用例，并标记优先级。

4.用例评审

测试用例完成后，测试、产品、开发一起参与用例评审，目的是为了发现用例遗漏和需求遗漏，会后进行修改补充。

5.单元测试（开发自测）

在开发的过程中要做单元测试，避免小错误造成大的影响。

三、测试阶段

1.部署测试环境

此流程需要跟开发沟通。

2.正式提测

系统部署成功后，开发人员首先要对系统进行冒烟测试，没有问题后，创建提测单。测试人员收到提测单后，记录开始执行测试的时间，先执行一遍冒烟测试用例，没有问题则开始执行全流程测试，否则打回给开发直到符合标准。

3.测试并追踪bug

测试人员将发现的bug记录到系统，bug录入时需提供：严重级别、测试账号、复现步骤、操作系统、报错日志、预期结果、实际结果，必要时提供截图或者视频，以帮助开发能更快速定位问题。

4.回归测试

开发修复完bug，测试人员进行回归测试。针对有异议的bug，需要测试、开发、产品经理一起讨论，最后达成一致。项目上线前原则上需要开发修复完所有bug，但实际由于工期等问题，允许遗留不严重的bug。

1）需求点测试通过标准

①所有需求功能点/项中无遗留等级“高”及以上BUG。

②一级需求点中总计遗留bug<= 5 例如：遗留Bug=5，若存在“中”级BUG，则“中”级BUG<= 2；若无“中”级BUG，则“低”级BUG<= 5。

2）测试通过标准

①需求中定义的所有功能已实现。

②所有要求的测试用例和测试程序已经100％被执行。

③测试覆盖率已达到系统需求的95%以上。

④测试中所发现的缺陷和错误已经100%定位。

⑤缺陷等级为“高”或以上的BUG 100%得到解决，中、低 (一般严重或轻微严重问题)等级BUG 95%以上得到解决。其它BUG若不能解决应给出不能解决或不计划解决的原因。

5.测试报告

1）当一轮测试完成后，测试负责人应编写测试结果。 测试报告内容主要包括：测试版本号，测试内容，需求点总个数，新建bug总数、回归bug数、回归bug通过数、需求点通过数、需求点通过率、bug分布情况，以及测试结论。 然后以邮件方式发送给项目经理、开发经理，并抄送给项目组成员。

2）当一个版本测试完成后，测试负责人应该根据《测试报告模版》编写测试报告。说明测试情况并下测试结论，然后以邮件方式发送项目经理，抄送给项目组全体人员。

3）当项目达到上线标准时，应该出具测试报告发送给整个项目组，说明测试结果及存在的风险，并告知产品经理进行验收测试，保证项目功能是符合预期的。

四、发布上线

1.发布时间

选择合适的上线时间，出现问题方便及时修复。

2.上线后跟踪

如果线上有反馈问题，测试应及时跟进，通知对应开发以最快速度修复和总结问题出现的场景和原因。

3.总结复盘

把本次的问题总结归纳，下次项目流程中应该重点关注。