（转）如何规范小开发公司的测试流程。?

提问 | 希杰

转自 | 知乎

链接 | https://www.zhihu.com/question/33406353/answer/417278125

 更多解答请查看知乎原文：https://www.zhihu.com/question/33406353/answer/417278125

如何规范小开发公司的测试流程。?

目前在一家创业公司上班，刚组建测试部门，领导让我规范和建立测试流程。头大。

 

1 号嘉宾一个比较懒的测试开发

7788：不邀自来。首先，作为一个刚组建的测试部门Leader，特别是在小的创业公司，题主应该先关注目前项目开发过程中存在的一些问题，如过需求不叫测试、开发提测质量差、用例覆盖率低等等。其次，回到问题本身，根据答主多年的测试经验，给出一些小小的建议。一般来说，通用的测试流程不外乎就是项目立项->需求评审->开发设计->设计评审->开发编码->测试用例编写->用例评审->功能测试->上线跟踪 然后根据目前存在的问题制定一些特定的流程，目的就是为了达到提高整个项目的质量和效率。答主目前在VPGAME(电竞赛事平台、赛事数据、互动娱乐)，我们是从以下流程重点把关：

一、产品测

需求评审：开发、测试拿到产品的PRD文档后，需要提前阅读并标出有疑问的地方，在需求评审上提出并沟通达到一致。保证产品、开发、测试对需求的理解一致，前期的修改成本是最低的。

二、开发测

开发设计：测试有条件的话应该参与到开发的设计评审和接口评审中，一方面可以达到理解开发设计的思路和逻辑，对之后的用例设计起到帮助，另一方面可以及早的发现开发设计上的错误和遗漏，将维护成本降到最低

开发提测：为了提高整个项目的效率，开发提测的质量也是至关重要的，如果出现一些流程性的问题，将影响到整个测试进度，所以测试这边应该事先将冒烟测试用例提供到开发，开发把冒烟测试用例全部测试通过后才可提测，测试接收到提测版本也应该先将冒烟测试用例过一遍，没有问题方可开始测试，否则打回重新开发直到符合标准。

三、测试测

用例设计：个人觉得用例设计应该分为两部分，一是根据需求分解出测试功能点并标出优先级，二是根据功能点设计测试用例和流程方面用例。

上线前验收：当项目达到上线标准时，应该出具测试报告发送至整个项目组，说明测试结果及存在的风险，并告知产品和运营可以进行验收测试，保证项目功能是符合他们要求的。

上线后跟踪：这一点有时候会被忽视，这块其实对测试来说也是有帮助的。如果线上有反馈问题，测试应该及时跟进，通知对应开发最快速度修复和总结出问题出现的场景和原因，最后需要把场景和对应的测试策略测试方法补充到用例当中，下次测试的时候应该重点关注。

四、其他

测试策略：比如自动化、持续集成、静态代码检查、代码覆盖率、APP专项测试等等，这就看项目需要和实际情况选择进行。

客观因素：需求变更等外部因素也经常打断我们的项目进度，我们需要做的就是不停的沟通，可以结合实际情况加入晨会流程，每天沟通好昨天的进度、碰到的问题、今天的计划，做到部门之间很透明。

以上是以VPGAME作为案例，当然各个公司因业务不同，产品不同，存在一定的差异和区别。说到底，流程是用来提升效率的。最重要的是，题主需要根据自己所在的公司，加入自己的思考，这点才是至关重要的。

附一张我们目前简单的流程图

 

2 号嘉宾钱蓓蕾-网易测试总监

钱蓓蕾：在首页看到这个话题，就不邀自来了。如果是刚组建测试团队，那需要整理的流程可多了。

1、梳理测试流程，可以重点把关的测试流程有：

需求Review：策划完成的需求文档必须让开发、测试、运营进行Review，提出Review意见并最终改掉。这种Review能发现需求的漏洞并提早改掉，提高整个研发过程的效率。

测试用例Review：测试人员针对需求写出粗略的用例点之后，再让策划、开发、测试、运营Review一遍，目的还是发现需求的遗漏点，根据我们的经验，由于测试人员已经思考了测试点，所以相当于是对需求的细化和剖析，这个Review环节还是能发现很多需求的漏洞。

开发提测：测试人员事先发出冒烟测试用例，开发完成后，让开发人员先根据冒烟用例进行自测，自测通过了以后才提交给测试，然后测试再根据相同的用例做冒烟测试。这样能提高开发提测的质量。

上线前报告：上线以前，需要让测试人员发一封报告，重点指出测试过程中发现的问题、及上线以后可能会出的质量问题，并在项目群里面、或者召集开会把这些风险一一沟通过。如果有因为时间不足、或者因为客观条件限制导致的测试不足的情况，一定要在这个环节进行说明，这样，如果上线以后出问题了，大家也能理解测试。

线上Bug Review：对于线上发现的Bug，如果没有分析流程，测试人员需要制定线上Bug的分析流程，先重点分析这个线上Bug产生的原因、线上Bug的影响范围，然后大家一起决定可以有哪些改进措施可以避免同类线上Bug再犯。这种改进措施需要能真正落实的，如果是可有可无的改进措施，就不要提了。这个措施可以让大家一起剖析线上Bug的产生原因，一方面可以避免项目组认为都是测试的错导致线上Bug，一方面，也发挥了测试人员质量保证的角色，推动流程让质量更好。

2、确定测试技术可以提升的点：

环境部署：如果有技术积累，可以把测试环境的部署拿来让测试来做，这样测试人员可以自己控制测试的版本和配置。也提高测试人员的工作范围。

性能测试：如果是流量很大的产品，需要专业的服务端性能测试人员来进行性能测试，对于测试的专业性提升有很大的价值。

专项测试：如果是APP产品，需要让技术比较好的同学来探索专项的测试，把APP端的性能、流量、电量等体验提升上去。

题主可以自己先评估需要引入上述哪些流程，然后，就是沟通、沟通、再沟通。所谓新官上任三把火，第一把火就是要把现有的情况先摸清楚。跟自己的组员沟通、跟项目的开发负责人、产品负责人沟通、跟自己的老大沟通。清楚他们希望我们重点改进的点，同时也把我们想要推的流程、理念传递出去。

在推流程的时候，建议尽量不要把自己站在产品的对立面，而是要跟产品站在同一边，以产品的质量、开发效率等出发点来进行流程的推广。大家相处愉快，整个团队齐心协力，这才是老大愿意看到的局面。根据我的经验，其实不管是开发负责人还是老大，还是比较愿意尊重我们的职业经验，只要我们真正站在产品的角度去沟通，大多数人还是愿意配合的。

 

3 号嘉宾佐撰

佐撰：谢邀。这个话题好大 先简答一下吧。首先 制定流程的人一定要明白和坚守一个原则：流程不能是死的必须是活的 其次测试流程的核心是在保障研发效率的前提下提高产品质量  明白这两点接下来的事就容易理顺了

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

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

- 测试团队结构、岗位定义及职责范围

- 相关合作团队职责、主要联系人、沟通方式

- 产品研发周期、阶段 （瀑布开发要考虑到大的release、小的release和hot fix的不同）

- 测试在研发整个周期的不同阶段的任务和出品

- 测试类型（Unit test, Integration test, System test, UAT, performance test, etc）在本测试团队内的定义

- 测试出品主要包括测试计划、测试用例、缺陷报告、测试进度报告、测试完成报告（或质量评定报告），每项出品应该有相关模板和写作规范

- 测试用例撰写、审核、执行、记录执行结果的流程

- 缺陷管理流程

- 测试平台、测试实验室管理使用规范

- 测试进入和退出标准

- 测试工具管理

- 测试数据收集、统计和过程改进办法

- 员工培训计划、组内知识共享计划

嗯。。。这一大坨东西，没两年以上的沉淀是积累不出来的

4 号嘉宾JMasche-Tester，阿根廷足球，BBer

JMasche：强答一发吧。考虑流程之前，应该考虑的是你们公司的环境，或许这个才是最重要的。由于你们之前没有测试部门，那么你们老大建立测试部门的初衷是什么？他想要达到什么效果？这点很关键。如果他有想法，必须先弄清楚他的想法，再来查看实施可能性；如果他没清晰的想法，那么就需要不断的通过沟通，提出你的想法，他来反馈意见。快速非正式迭代。为什么这个很重要呢？因为一旦测试部门建立起来，会出现两个情况：1、研发周期被拉长。这个是一定的，无论采取什么办法，都会被拉长。创业公司我没呆过，想来对发布速度是有要求的吧。2、质量有可能在短期内下降。为什么呢？因为质量掌握在开发手上。而测试部建立起来之后，可能出现开发人员觉得有人兜底了，导致开发质量下降。后面有个号称质量保障的部门了，多了个背锅的家伙。呵呵

上面这俩点合在一起的最坏情况是什么呢？建立测试部后，研发周期拉长，而质量下降。开发抱怨测试带来额外任务增多，而且还搞不定质量。所以，回过头来，找老大，沟通：

1、为什么要建立测试部？原来出现严重质量问题？ok，这简单搞定上线发布环节就行了。如果只是很模糊的需要测试，那就要确定测试的范畴，能达到的效果。思考点包括：测试人力投入、测试周期。

2、基于第一点的范围和目的效果，再往你上游的开发环节看，设立转测试点要求，千万不要多，找到最关键两三点即可。这个环节要拉上开发负责充分沟通。

3、建立发布评审机制。参与人员和输出。

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

我觉得刚开始搞定这些也就差不多了

5 号嘉宾天狼星

天狼星：正是我现在做的事，忍不住写下来。首先看什么样的公司和什么样的产品以及周围的人的技术水平，老大们的真实想法。核心还是要从把当前产品出发，如何把产品测试好。这样才能得到老大甚至老板的认同。另外建议先做好规划和老板汇报下，摸清楚他们的期望。很多老板以为有了流程产品质量就会变好，这种事要先解释清楚，最终是要人执行和落地，而改革中也势必会有阻力，这时候一定要老板支持。然后技术上，不建议搞太多流程。技术上建议做以下几个动作

1、控制版本发布最好做到自动化，可参考使用jenkins，好处节约发版时间，避免测试版本与发布不一致

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

3、推动需求端讨论，驱动问题提前发现。

4、推动自动化测试

最好要看公司测试本身的职责。如果有其它质量部门负责制订流程的话还是要专人来做，制订流程及落实的工作并不是想象中一个兼职人员可以完成的。补充个人观点，好的流程不如好的工具和人员的习惯。之前看一篇文章写Google 的 代码评审，开发人员提交后自动进行静态检查，和送到评审员那里不通过无法提交。而对比华为花大价钱搞的IPD 效果大量人力物力，效果暂且不评论了。

6 号嘉宾王小二-尘世中迷途小书童

王小二：和题主有类似的经历，个人认为最主要的是还要搞好与领导的关系，以及开发老大的关系。首先要弄清楚公司领导要你这么做的目的是什么，以及他的期望是怎样的；其次要获取领导的绝对支持，特别是测试与开发起冲突时的支持（虽说测试与开发的大致利益是一致的，但实际操作中难免有冲突）；最后还要处理好与开发老大的关系，否则一些你想弄的流程、规范等等也很难推进落实。

至于具体的流程、规范，根据公司实际的情况制定，并且多与领导、同事以及开发人员讨论，实事求是、符合实际情况是最重要的。在具体执行的过程中，也要不断的权衡与开发、公司等之间的利益关系，对一些开发人员觉得不满的地方做好记录和解释工作，持续改进。

总之，个人觉得在小公司里，人是最需要考虑的因素。

————————————————————————————————————————————————————————————————————————————————————

本文完