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

提问 | 希杰

转自 | 知乎

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

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

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

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

 

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

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

1、产品测

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

2、开发测

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

开发提测：为了提升整个项目的效率，开发提测的质量也是相当重要的，若是出现一些流程性的问题，将影响到整个测试进度，因此测试这边应该事先将冒烟测试用例提供到开发，开发把冒烟测试用例所有测试经过后才可提测，测试接收到提测版本也应该先将冒烟测试用例过一遍，没有问题方可开始测试，不然打回从新开发直到符合标准。

3、测试测

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

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

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

4、其余

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

客观因素：需求变动等外部因素也常常打断咱们的项目进度，咱们须要作的就是不停的沟通，能够结合实际状况加入晨会流程，天天沟通好昨天的进度、碰到的问题、今天的计划，作到部门之间很透明。

以上是以VPGAME做为案例，固然各个公司因业务不一样，产品不一样，存在必定的差别和区别。说到底，流程是用来提高效率的。最重要的是，题主须要根据本身所在的公司，加入本身的思考，这点才是相当重要的。

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

 

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

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

一、梳理测试流程，能够重点把关的测试流程有：

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

测试用例Review：测试人员针对需求写出粗略的用例点以后，再让策划、开发、测试、运营Review一遍，目的仍是发现需求的遗漏点，根据咱们的经验，因为测试人员已经思考了测试点，因此至关因而对需求的细化和剖析，这个Review环节仍是能发现不少需求的漏洞。

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

上线前报告：上线之前，须要让测试人员发一封报告，重点指出测试过程当中发现的问题、及上线之后可能会出的质量问题，并在项目群里面、或者召集开会把这些风险一一沟经过。若是有由于时间不足、或者由于客观条件限制致使的测试不足的状况，必定要在这个环节进行说明，这样，若是上线之后出问题了，你们也能理解测试。

线上Bug Review：对于线上发现的Bug，若是没有分析流程，测试人员须要制定线上Bug的分析流程，先重点分析这个线上Bug产生的缘由、线上Bug的影响范围，而后你们一块儿决定能够有哪些改进措施能够避免同类线上Bug再犯。这种改进措施须要能真正落实的，若是是无关紧要的改进措施，就不要提了。这个措施可让你们一块儿剖析线上Bug的产生缘由，一方面能够避免项目组认为都是测试的错致使线上Bug，一方面，也发挥了测试人员质量保证的角色，推进流程让质量更好。

二、肯定测试技术能够提高的点：

环境部署：若是有技术积累，能够把测试环境的部署拿来让测试来作，这样测试人员能够本身控制测试的版本和配置。也提升测试人员的工做范围。

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

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

题主能够本身先评估须要引入上述哪些流程，而后，就是沟通、沟通、再沟通。所谓新官上任三把火，第一把火就是要把现有的状况先摸清楚。跟本身的组员沟通、跟项目的开发负责人、产品负责人沟通、跟本身的老大沟通。清楚他们但愿咱们重点改进的点，同时也把咱们想要推的流程、理念传递出去。

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

 

3 号嘉宾佐撰

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

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

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

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

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

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

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

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

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

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

- 缺陷管理流程

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

- 测试进入和退出标准

- 测试工具管理

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

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

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

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

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

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

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

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

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

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

我以为刚开始搞定这些也就差很少了

5 号嘉宾天狼星

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

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

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

三、推进需求端讨论，驱动问题提早发现。

四、推进自动化测试

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

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

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

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

总之，我的以为在小公司里，人是最须要考虑的因素。

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

本文完