软件测试的流程

软件测试流程

前言：根据白月黑羽教学视频所整理的笔记，传送门：测试流程

一.调研阶段

通常是老板和产品经理做的事，调研想做的产品。

• 大体有哪些功能
• 是否有价值
• 到底能不能做

调研阶段确定产品的大体功能

二.需求分析阶段

这个阶段的工作通常是产品经理和开发经理讨论制定需求细节，开发人员和测试人员参与评审。

对一个系统，需要具体实现的功能，每个功能点要不断细化，子功能点也要继续细化。

这个阶段，产品经理和开发领导应该逐步推出需求文档，如果系统功能点很多，可能一个功能点就需要出一个需求文档。

测试人员需要做的事：

• 评审需求文档

通过评审了解需求，甚至参与需求分析讨论，看看需求有没有错误、矛盾、遗漏的地方。

• 整理测试需求（最好自己这样干）

原来的需求文档往往是写的比较乱，不全面。就需要再次整理，相当于是测试用例的提纲，为后续编写测试用例准备测试需求（其实是更加具体的、有条理的需求文档）

通常这一阶段比较耗时

三.设计阶段

开发人员根据需求文档，做出设计文档，这是开发编码的依据。

测试人员根据开发人员的设计文档，和开发人员多交流，得知产品的细节功能。

测试人员去可以了解系统的内部设计，比如系统由哪些子系统组成，子系统之间的接口如何通讯。这可以帮助你写出更有针对性的测试用例

搞清楚产品设计细节后，测试团队就应该编写测试计划，编写测试用例。

测试计划：

• 评估工作量和人力配备，风险评估，从而确定测试目标
• 制定测试任务（包括制定测试协调人、编写测试用例、学习和开发测试工具、准备环境），并且分派给人员
• 其他为了了实现测试目标和任务确定必要的测试活动。

测试计划通常是部门领导所干的活

分派给测试人员的任务，最重要的就是编写测试用例

四.开发阶段

开发工程师进行开发。

此时测试工程师可以：

• 评审测试用例
• 准备测试工具、学习使用测试工具
• 准备测试环境
• 和开发人员保持沟通，因为开发过程中开发人员随时可能推翻原来的设计，修改功能，你要相应改变测试用例

五.测试用例执行

冒烟测试：对系统的基本功能进行测试，如果没问题了再进入正式的测试环境。

开发人员发布完测试版本，测试人员就开始根据前面写的测试用来进行测试。

测试发现的问题（bug）提交到问题跟踪系统。

对测试用例不足的地方，及时改进

如果实际产品的实现和需求设计文档功能不符，就认为是bug。

和开发人员起争执了怎么办？

• 检查自身的bug描述是否有问题
• 尝试站在用户的角度去说服开发人员
• 找权威决策人（比如老板、产品经理），由这类角色来最终拍板

像起争执这类事很常见，需求设计文档不可能说每一处都那么详细。有些开发人员所实现的功能，符合需求设计文档，但依旧可以认为是bug。例如说登录时，用户输入错误的密码，但系统的提示信息不明显，用户不容易发现。

在测试结束后，通常会有一个测试报告，给出这次测试的结果描述。比如：

• 测试覆盖的功能点有哪些
• 总共多少测试用例，通过了多少，不通过的有多少
• 发现问题，哪些是特别严重得多

六.回归测试

当一轮测试结束后，会发现一些bug，开发人员就需要对这些bug进行修改。

根据bug的严重程序和出现几率，根据优先级来进行修复。

修改完毕之后会发布一个新的测试版本。

回归测试：

测试人员会根据所发布的新的测试版本进行测试，即回归测试。

主要目的：

• 验证bug是否正确修复了
• 确保在修复过程中没有引入其他bug

特别是第二点，查看新引入的代码（修改完 bug 后的代码/系统，以及进行正常迭代增加的新功能的代码）对旧功能是否有影响，是否因此引入了新的bug。

在进行测试的时候，往往为了节省人力资源，会引入自动化测试。

挑选哪些用例自动化呢？

• 需要反复执行的测试用例
• 对应功能点稳定
• 容易自动化

七.发布正式的版本

经过 N 次内部版本的发布、测试后，产品实现的功能越来越多，并且通常 bug 会越来越少，若是到了某个版本，经过评估，如果实现的功能足够，并剩余的bug，不影响产品发布给客户，就会作为正式版本发布给客户使用。

八.功能添加，产品迭代

虽然产品已经发布给客户使用了，但是产品后续还可能有后续的需求，需要在目前的版本的基础上继续开发。