🍅 视频学习：文末有免费的配套视频可观看

🍅 点击文末小卡片 ，免费获取软件测试全套资料，资料在手，涨薪更快

1. 梳理提需求流程

（1）规范需求list时间

有些团队可能会今天提一个需求，明天提一个；可以制定一个每周过需求list的时间，统一安排过本周的需求，并对需求进行优先级排序，开发和QA可根据本周的人力情况去安排本周的需求，避免需求乱提；而且各个角色要有一个明确的对接人，统一收敛到接口人，不要面向全员提需求；

（2）制定需求截止时间

制定需求截止时间，比如像App是需要发版的，发版一般是有固定周期的，若临近发版要加需求，会对版本有很大影响，所以需要制定一个需求截止时间，比如版本开发前一周的周四。

（3）紧急需求流程

若有特殊情况，比如CTO直拍的紧急需求，要走特殊流程，此流和需要走，比如需要发送邮件抄送产品及各技术老大，老大回复后才确认修改或增加需求。

2. 制定需求质量规范

出需求虽然是产品的工作范围，但一份需求的质量一定程度上会影响整个项目的质量。比如，跨部门的项目，由于涉及到外部系统，如果前期产品调研不够充分，对于业务边界了解不够清晰，对交互系统的是否可实现性无法确定，会直接导致开发阶段的问题。所以从整个项目的角度出发，QA需要关注需求的质量。

（1）需求是否达到评审状态

若评审如果需求前期调研不充分，产品对边界系统了解不清楚，疑问点较多，此需求存在很多不确定性，QA可将需求打回（可根据情况选择委婉或强硬）。

（2）需求的可行性

产品需要说明需求的预期收益，需要用历史数据说话，否则投入人力去做，需求丝毫没有收益，从资源层面来说是一种浪费。如果开发和QA评估，需求实现难度大，没有数据支撑，此需求需要重新调研。

设计阶段包括开发设计及UI设计。这个阶段比较常见的问题是，开发设计没有文档、

UI设计与需求文档原型图不一致；

开发文档可以跟开发提诉求，落实到文档，尤其是与外部系统交互的文档。

UI图与需求不一致，会导致开发和用例设计不能够明确以谁为准。尤其涉及到前端页面的需求，在FE开发过程中，不一致是很大的一个痛点。基于这种情况，可以制定UI准入规范，可包含以下内容：UI图格式、存放地址、出UI图时间（一般最晚在开发前一天提供）等；并且要求产品对UI图进行验收之后再提供给开发。

1. 准入规范

准入标准：如准入用例要占总用例的30%，开发需要执行完准入用例通过率需要达到100%后再进行提测。开发执行准入case与QA执行方式不一致，开发会用假数据mock，但真正走流程会有问题。执行准入是为后续测试流程更顺畅，更高效，所以可以要求开发执行方式是从前端触发，而不是后端直接mock。

准入用例确认：用例评审会可确定准入case范围，与开发达成一致。

打回流程：若准入用例执行不通过，后续怎么打回。

2. 提测流程

邮件提测or口头提测or平台提测，根据情况制定。

3. 测试日报

有些同学在测试过程中，是默默执行的，比如排期三天的测试需求，到了测试阶段，两天过去了，群里没动静，相关leader可能会对此需求的进度不了解，所以可以制定测试日报，规范测试流程，一般包含以下信息：

（1）    整体测试进度X%，整体风险评估

（2）    已测内容及未测内容

（3）    高优Bug及阻碍性问题反馈，以及解决时间，风险评估

4. Bug规范

包含但不仅限于

  （1）Bug标题及步骤规范，标题要言简意骇，避免阅读成本；步骤写清楚+截图

（2）Bug的流转要规范，比如已解决状态只能开发去更新；已关闭由QA执行等

（3）Bug解决方案，尤其关注不是Bug的情况，QA要提高质量Bug，与开发约定不是Bug的范围。

（4）Bug严重级别、优先级等

可根据自己所在团队的情况制定规范

5. 测试完成标准

功能测试规范、性能测试范围、兼容性测试规范、验收测试规范等

6. 测试报告模板

7. 测试复盘模板

8. 自测标准（若有）

测试阶段可以做的事情很多，可以根据自己所在团队的情况而定。一般是对测试过程的监控，使测试更顺畅，更高效。也可以通过项目结束后的数据，比如Bug占比及趋势，每周的线上Bug、二次上线率等来对测试流程进行优化。

• 线上问题跟进流程：进行轮值，对线上问题要快速响应，且给予结论。

• 灰度&线上问题收集

1.流程优化是一个持续过程，每个公司，每个团队情况不一样，总原则是：如果在项目过程中你感觉到某一点很别扭，很不爽，痛了，那么这就是优化点；

2.优化的手段是多样化的，流程规范去约束，开发和利用工具去辅助，都是优化方式；

3.流程优化是一件需要团队合作才能做得更好的事情，所以任何优化都需要与团队各角色达成一致，才能够有效地去落地。

4.优化过的流程要持续坚持去落地，作为负责人要起到督导作用，才能让你的团队持续精进。