软件测试流程&规范

前言

一套完整的测试流程，能大大保证产品的测试效率和质量。当然并不是所有的项目都要完全按照这个去执行，要根据项目的实际情况对流程实时的增加或减少。

测试流程图

流程说明

一、需求分析&需求评审

涉及人员：开发、测试、设计、产品、项管、数据

目的：需求评审过程中，开发从技术角度来分析实现方案，实现难易程度；设计从交互角度给出适当的建议，有没有不合理的交互流程，是否存在可优化的地方；测试从用户角度来给出产品逻辑上是否存在不合理的建议；数据给出的埋点是否合理，可实现。

需求分析后，若有疑问建议等，及时与需求方沟通。

产出：需求最新文档

二、编写测试计划

测试计划包含要素：

• 迭代版本相关信息
• 时间节点信息
• 需求范围
• 涉及的相关人员
• 测试人员分配
• 资源需求
• 风险评估
• 测试类型/方法/工具

三、测试人员设计测试用例 & 开发进入研发阶段

用例编写工具：

1. Excel (适合不是常变动的用例，例如最后的回归用例，可以利用 腾讯文档、钉钉中的Excel文档做记录)
2. Xmind (目前主流的用例编写工具)

产出：测试用例

四、用例评审

参与人员：所测项目所有涉及人员（产品，开发，测试，设计，数据，项管）

目的：对于编写用例过程中的不确认点，进行进一步确认，并确认一些细节规则或操作步骤等，避免功能点遗漏；

并确认出 一级用例，和所有人员达成一致，提供给开发同学自测以及产品同学验收

产出：一级测试用例 & 完整的测试用例

五、开发自测

需要在开发开发完成前，把一级用例提供给开发同学（可以在用例编写阶段先写一级用例），自测通过后提测给测试同学

输出：接口文档、测试数据等

六、测试人员介入测试

测试同学执行测试用例，提交BUG、跟踪BUG至BUG关闭

在整个测试过程中要积极推动流程，例如推动BUG解决，遇到有矛盾的地方时要积极召集相关人尽早决策，避免造成最后时间太赶，影响测试质量或者延期等

测试内容：

1. 接口测试（理论上接口会早于客户端功能开发完成，所以可以提前进行接口测试，也进一步了解服务端实现逻辑）

   1）目前推荐的工具：Postman，Jmeter，yaApi等

2. 功能测试，核心业务测试

   1） 协助测试工具：Charles，fiddler等抓包工具，也可模拟弱网

3. 兼容性测试

   1）Android系统：Android 4.0 到 Android 11.0 （Android 8.0有个系统级BUG，在有透明主题或横竖屏切换时，可能会崩溃，该系统级BUG在Android 8.1上已修复）
   2）iOS系统：iOS 9.0 - iOS14.0
   3）各大厂家手机（华为，小米，OPPO，vivo等）

   没有手机时可以借助第三方云平台测试例如 优测，云测等，需要充值

4. 安全测试（合规性测试），一般需要开发同学编写测试工具，主要检测APP在未授权前是否获取了用户的Mac地址，IMEI等隐私信息

   1）在xposed的基础上开发插件进行测试

5. 性能测试

   1）客端性能测试工具：Perfdog ，建议结合 Airtest使用。
   2）接口性能测试工具：Jmeter

6. 上线测试

   1）上线前应要求开发提供上线手账，避免项目功能较大时，出现漏上，勿上等情况

   2）尽量保证每一个服务上线前有白名单，先用白名单线上测试，在测试结束后记得清理数据

产出： BUG记录，性能测试报告等

七、测试报告

测试完成需要提供测试报告，发给涉及项目的所有相关人，包含：

• 版本信息
• 测试结果
• 测试人员
• 测试时间（包含各个关键时间节点）
• 需求池汇总
• 本版BUG总数，遗留的BUG等
• 风险同步
• 总结（在测试过程中影响测试质量，效率等的问题以及建议解决或规避方案）

缺陷管理流程

BUG状态：

• 开放：表明问题单已经被创建，等待被指派人处理
• 开始进行：表示开发已接收此问题，并开始进行处理
• 已解决： 表明问题已经被处理完成，等待问题报告人的验证。从这个状态，问题单一般可以进一步变更为重新打开状态（Reopened）或关闭状态（Closed）
• 重新打开：表示问题经过验证发现没有被解决，就可以变更到这个状态。
• 关闭：测试人员验证问题已修复，更改至此状态。
• 不予处理：提交的bug不是问题或其他原因
• 重复提交：同其它已经存在的问题重复了，推荐把相关的单子链接起来
• 无法复现：被指派人无法复现此问题。
• 延期处理：当前版本不能修复此问题，需延期处理。
• 设计如此：这个不是问题，设计就是这样。

结语

面朝大海，春暖花开。

愿你一生努力，一生被爱。