前言
一套完整的测试流程，能大大保证产品的测试效率和质量。当然并不是所有的项目都要完全按照这个去执行，要根据项目的实际情况对流程实时的增加或减少。
测试流程图
测试流程图
流程说明
一、需求分析&需求评审
涉及人员：开发、测试、设计、产品、项管、数据
目的：需求评审过程中，开发从技术角度来分析实现方案，实现难易程度；设计从交互角度给出适当的建议，有没有不合理的交互流程，是否存在可优化的地方；测试从用户角度来给出产品逻辑上是否存在不合理的建议；数据给出的埋点是否合理，可实现。
需求分析后，若有疑问建议等，及时与需求方沟通。
产出：需求最新文档
二、编写测试计划
测试计划包含要素：
-
迭代版本相关信息
-
时间节点信息
-
需求范围
-
涉及的相关人员
-
测试人员分配
-
资源需求
-
风险评估
-
测试类型/方法/工具
三、测试人员设计测试用例 & 开发进入研发阶段
用例编写工具：
-
Excel (适合不是常变动的用例，例如最后的回归用例，可以利用 腾讯文档、钉钉中的Excel文档做记录)
-
Xmind (目前主流的用例编写工具)
产出：测试用例
四、用例评审
参与人员：所测项目所有涉及人员（产品，开发，测试，设计，数据，项管）
目的：对于编写用例过程中的不确认点，进行进一步确认，并确认一些细节规则或操作步骤等，避免功能点遗漏；
并确认出 一级用例，和所有人员达成一致，提供给开发同学自测以及产品同学验收
产出：一级测试用例 & 完整的测试用例
五、开发自测
需要在开发开发完成前，把一级用例提供给开发同学（可以在用例编写阶段先写一级用例），自测通过后提测给测试同学
输出：接口文档、测试数据等
六、测试人员介入测试
测试同学执行测试用例，提交BUG、跟踪BUG至BUG关闭
在整个测试过程中要积极推动流程，例如推动BUG解决，遇到有矛盾的地方时要积极召集相关人尽早决策，避免造成最后时间太赶，影响测试质量或者延期等
测试内容：
-
接口测试（理论上接口会早于客户端功能开发完成，所以可以提前进行接口测试，也进一步了解服务端实现逻辑）
- 目前推荐的工具：Postman，Jmeter，yaApi等
-
功能测试，核心业务测试
- 协助测试工具：Charles，fiddler等抓包工具，也可模拟弱网
-
兼容性测试
-
Android系统：Android 4.0 到 Android 11.0 （Android 8.0有个系统级BUG，在有透明主题或横竖屏切换时，可能会崩溃，该系统级BUG在Android 8.1上已修复）
-
iOS系统：iOS 9.0 - iOS14.0
-
各大厂家手机（华为，小米，OPPO，vivo等）
没有手机时可以借助第三方云平台测试例如 优测，云测等，需要充值
-
-
安全测试（合规性测试），一般需要开发同学编写测试工具，主要检测APP在未授权前是否获取了用户的Mac地址，IMEI等隐私信息
- 在xposed的基础上开发插件进行测试
-
性能测试
-
客端性能测试工具：Perfdog ，建议结合 Airtest使用。
-
接口性能测试工具：Jmeter
-
-
上线测试
-
上线前应要求开发提供上线手账，避免项目功能较大时，出现漏上，勿上等情况
-
尽量保证每一个服务上线前有白名单，先用白名单线上测试，在测试结束后记得清理数据
-
产出： BUG记录，性能测试报告等
七、测试报告
测试完成需要提供测试报告，发给涉及项目的所有相关人，包含：
-
版本信息
-
测试结果
-
测试人员
-
测试时间（包含各个关键时间节点）
-
需求池汇总
-
本版BUG总数，遗留的BUG等
-
风险同步
-
总结（在测试过程中影响测试质量，效率等的问题以及建议解决或规避方案）
缺陷管理流程
BUG流程图
BUG状态：
-
开放：表明问题单已经被创建，等待被指派人处理
-
开始进行：表示开发已接收此问题，并开始进行处理
-
已解决： 表明问题已经被处理完成，等待问题报告人的验证。从这个状态，问题单一般可以进一步变更为重新打开状态（Reopened）或关闭状态（Closed）
-
重新打开：表示问题经过验证发现没有被解决，就可以变更到这个状态。
-
关闭：测试人员验证问题已修复，更改至此状态。
-
不予处理：提交的bug不是问题或其他原因
-
重复提交：同其它已经存在的问题重复了，推荐把相关的单子链接起来
-
无法复现：被指派人无法复现此问题。
-
延期处理：当前版本不能修复此问题，需延期处理。
-
设计如此：这个不是问题，设计就是这样。
结语
面朝大海，春暖花开。
愿你一生努力，一生被爱。
网友评论