如何制定和管理测试流程

参考 https://blog.csdn.net/zouhui1003it/article/details/81086451

 

提起测试管理，脑子里总是一篇空白或者就那么几句干巴巴的话。 学习下大神们总结的经验吧。

 

一个通用的测试流程流程，一般会包括： 项目立项-》需求评审-》开发设计-》设计评审-》开发编码

                                                                                                   -》测试用例编写-》用例评审-》功能测试-》上线追踪

 

一般来说，从0建立一个测试部门的机会比较少，通常接手时已经有了一定的人员基础，也有了一定的测试流程，在这种情况下要先找出目前流程中存在的问题，然后加以改进。 例如：过需求而无测试参加，无提测标准或提测标准不清楚导致提测质量差，用例的覆盖率不足。

 

无论是建立还是改进测试流程，我们都可以从以下几个方面进行把关：

1. 产品侧

需求评审：开发和测试拿到PRD后，一定要认真阅读，找出有疑问的地方，然后在评审会议上提出来，并进行3方的沟通，确保产品，开发，测试在对需求的理解上达到一致。  （前期发现问题，解决的成本是最低的）

2. 开发侧

开发设计：有条件的话，测试应该参加开发的设计评审和接口评审。 这样做，一方面有助于理解开发的设计思路和逻辑，对用例设计有帮助。另一方面，及早发现设计中的错误和遗漏（不是设计人员技术不足，而是人都有懒惰心理。工作中遇到过2次，一次是系统从第三方获取数据不进行缓存，导致服务的性能很差。 还有一次是，某个服务对其他服务有依赖，但不是必须的，采取同步访问的方式，在某个无法无法正确工作时，导致本服务停止工作。）

开发提测：为了提高整个项目的效率，提测的质量是非常重要的。 过低的提测质量，会导致无用功，流程不畅。 所以测试要提前准备好冒烟测试用例，交给开发，提测前开发需要保证所有的冒烟测试用例都通过。   然后，测试拿到版本后也先进行冒烟测试，如果不通过则打回开发。

3. 测试侧

用例设计：分为2个部分，根据需要分解出测试点，然后根据测试点设计测试用例

用例评审：按照需求写出粗略的测试点之后，让策划，开发，运维一起Review一遍，目的是发现遗漏的测试点。但是在这个过程中，因为测试人员深入思考了测试点，所以相当于对需求进行了细化和深入的剖析，这个环节还是能发现许多需求的漏洞的。

上线前测试：项目达到上线标准时，发送测试报告到整个项目组，重点说明测试过程发现的问题以及上线后可能出现的问题，并在群里或召集会议对这些问问一一沟通。 如果因时间原因测试不足，那么一定要在这个阶段进行说明，如果上线出现问题，大家也能理解。

上线后追踪： 如果线上有反馈问题，测试要及时跟进，配合开发迅速修复和总结出问题出现的原因和场景，并将这个场景和对应测试策略、方法补充到用例当中，下次测试时重点进行关注。 如果没有线上bug的分析流程，那么测试需要进行流程的制定，另外要研究是否可以采取什么措施避免类似的问题再次发生。

4. 其他

测试策略：包括自动化、持续集成、静态代码检查、代码覆盖率、App专项、压力测试、性能测试等，需要根据自己的项目特点进行选择。

客观因素：我们经常遇到的是需求变更，会打乱项目的进度。 我们能做的就是不停的沟通，可以结合实际的情况加入晨会，沟通好昨天的进度、碰到的问题，今天的计划等。

 

 

要想建立或改进测试流程：

1. 弄清楚产品形态，人员技术水平

2. 充分了解当前研发流程，对不合理的地方尤其不要急于下定论和提出改进意见，而要充分了解历史成因

3. 老板的真实想法，他们对测试部门的期望是什么？

4. 跟领导聊天了解领导期望的未来的或理想的研发流程是什么样的，和现有流程的差距在哪里、实现的难度在哪里，在这两点的指导下提出测试流程草案，除非是研发太扯蛋，否则最初的测试流程最好是在现在的研发流程上做少量提升和修改，草案要与领导与研发团队共同讨论，尽最大可能取得相关人员的理解和支持 试行 反馈 改进 无限循环

5. 流程最终是要由人执行的，好的流程并不意味值得到好的质量。 好流程，不如好工具和人员习惯。

6. 技术上建议做的以下几个方面：

    （1）控制版本发布，最好做到自动化，可参考使用jenkins，节约发版时间，保证版本一致性

    （2）控制开发提交测试环节，开发必须输出有效的功能清单和自测报告

    （3）推动需求端讨论，驱动问题的提早发现

    （4）推动自动化测试

    （5）建立起问题单管理系统和机制，基于问题单给出质量晾晒机制。这点对老大有用，开发讨厌。