如何提升测试阶段的工作效率

原创王掌柜的大排档不想延期

收录于合集

最近两个月一直在协助交付团队面试测试人员（功能测试），但是不知道什么原因，通过率极低。包括去年也断断续续在面试测试岗位，通过率也不高。

我始终觉得自己的要求并不高，没有很多天马行空或者实际工作用不太上的问题考察，始终围绕一个核心问题在考量，也就是今天想和大家分享的：如何提升项目管理过程中测试阶段的工作效率。

大多数候选人在回答这类问题时，更多的是把角度放在了某一具体节点上。比如执行案例的时候怎样更快一点，或者想办法让开发人员改bug更快一点（没有具体更快的方式，只是提到了要更快），或者说引入自动化测试、引入某些测试管理工具。但是无论哪个回答，都缺乏深入思考，缺乏具体可行的方法，缺乏对整个测试管理过程的全盘考虑。

下面我来分享一下自己的想法：

首先把测试过程整体分为如下几个阶段：

分析需求、制定计划、用例设计（编写+评审）、用例执行（冒烟+内部+联调+验收）、配合上线、测试总结

Ps：不同的团队分析需求（和需求分析不一样）和制定计划顺序可能有先有后，用例执行阶段会有差异，且整体执行的测试轮次也不一样，这些区别就不详细赘述了。

测试人员对需求有天然的优势

测试人员对需求的理解、熟悉程度，往往对后续的工作效率高低起着决定性影响。而且我始终认为一个熟练的功能测试者，应该是对所测系统中细节、逻辑、真实情况最了解的人，没有之一，了解程度超越了项目经理、需求人员。

因此在需求分析阶段，测试人员可以提出很多建设性意见，比如这个改造对现有逻辑影响的大小，或者细节上是否考虑不周等。而实际中很多团队的测试人员可能就没有参与需求分析，这也侧面形成了后续测试过程进度缓慢或者质量不佳的原因。

所以需求分析阶段测试的提前参与，或者针对已经定版的需求尽快吸收消化，对后面整体的执行过程会起到很大的促进作用。

测试人员的计划往往不是自己定的

按正常流程来说，需求理解之后，会形成用例的腹案，针对本需求的难易程度及时间计划会有一个大体的概念，最终在制定计划的时候再结合团队中各个岗位的实际情况评估出最终计划。

但更多情况是：任务计划的节点是跟着项目周期而定的。

比如说我评估一个项目的测试时间计划为1个月，但是项目整体周期才3个月，需求、设计、开发、投产准备，哪个阶段都不能省，哪个阶段时间都会被压缩。所以测试时间被领导或者甲方压缩了。“半个月能不能干完？能干完那就按照这个时间来做计划吧”

所以在计划阶段，我觉得更重要的不是我们评估需要多久，怎么安排组内工作。而是在工期被压缩的情况下如何排计划、分任务。

如果我们能找到“主线任务”，合理的进行优先级排序，并在任务安排过程中能够人尽其才，那制定出来的计划才可能是一个高效的计划。同时还可以考虑和其他节点交叉时间。比如提前进行用例评审，提前进入某些功能的测试执行阶段等。

用例到底写到什么程度才算合格

在用例编写和评审阶段，我们可以从工具、规范、全面性三个角度来提升效率。

工具即选择更适合团队的用例管理工具。如果是一两个人的测试组，那可能Excel或者思维导图更高效，如果是多人测试组或者遇到异地办公的小组，可能需要线上的用例管理工具，但工具又会有工具的弊端。无论哪种方式，都要适合团队，且能讲出工具的优势。

规范则是大家对测试用例编写和评审的规则要求，所有人都要按照同样的规范编写，后续评审、执行、组内协同、人员变动才能更节省时间。同时规范也是为了易读、易用。比如所属模块一定要用词统一；一定要包含测试点、前置条件、执行步骤、预期结果等关键要素；不同的要素怎么写，也可以根据项目情况来自行定义。评审时针对规范性、易读易理解等方面进行考量，也能保证用例的产出质量，为后续的执行阶段铺路。

全面性就不用解释了，用例是否满足需求，覆盖度是否完整，本身就是测试人员始终需要重点关注的问题。但是当有候选人说出了要尽量保证用例的全面性之后，我会反问：怎么保证全面性呢？大多数候选人除了表达和需求一致之外，就没有什么其他具体方法了。

所以这个问题大家可以交流一下，今天就不展开探讨了。

执行阶段的几个常见问题

用例执行阶段是耗时最长，最有可能造成计划延期的，也不是寥寥数语能涵盖全面的。我想重点从几个常见问题上入手来提高测试效率。

1、你会把缺陷定位准确之后再提给开发人员吗？

2、你会帮开发人员排查关键问题吗？

3、冒烟测试没通过，你有把代码打回去的勇气吗？

4、修复A缺陷从而引起B缺陷发生，这种关联性bug你有预防手段吗？

5、发现功能逻辑不合理，你会和需求或项目经理据理力争吗？

6、你和开发人员相处愉快吗？沟通效率上有提升空间吗？

7、如果有甲方或者第三方的人员来进行验收测试，你和他们相处有哪些技巧或经验吗？

8、你们团队开发组有自测流程吗？是形同虚设吗？

以上8个问题都或多或少的指向了提升测试效率的具体方法，本次只重点聊一下第四个问题。

关于关联性bug我在面试时经常会问，我觉得测试人员在提一个新的bug时，如果能够预想到关联功能，或者在解决这个bug时有自己的分析方案，一定要在备注中写出来。当然这些关键性问题在需求评审，用例评审过程中可以提前预知的，就可以先提出改造风险并形成相应的设计方案，以提高各方关于这类问题的重视程度与方案的完备程度。

这种关联性bug是非常耗时耗力的，最好的预防手段就是提前指出、提前关注。

我相信大部分项目在熟悉之后，都是能够准确预见关联性缺陷的，能多预见一个，测试效率就提高了一分。

还是要多总结多思考

其他的阶段就不再详细讨论了，还是希望我们在工作之余，能够跳出工作中的繁琐事务，针对自己的效率、方法、目标等进行复盘。自己复盘收效少的，可以多找同事、领导聊天，打破自己的思维限制，不然天花板就在前方等你了。

写在最后

关于测试阶段提升效率的方法，从思维模式到某些具体的方式，都能够举一反三到其他岗位的工作中。所以今天分享以上的内容，希望能够抛砖引玉，为大家带来些更好的思路。

可能是因为我们的招聘范围更多在二三线城市，互联网行业平均线本身就与一线城市有差距，同时又有出差的要求，所以让很多有能力的测试人员望而却步。

希望我们团队能尽快招到合适的人员，也希望各位互联网同行们能努力工作、善于总结、提高效率、共同成长。

Ps：这是一篇没有计划的发文，我也多年没有从事具体的测试工作了，一些观点如果不能与时俱进，还望各位测试大佬海涵并指出。

下一篇计划从“需求人员如何为实施团队赋能”上做一些讨论。这个题开的有点大，还没有想好怎么写，但是立了flag，总得去想办法完成不是吗？

欢迎各位同行关注“不想延期了”公众号

往期回顾：

开篇：真的不想延期了

面试问题：产品最重要的能力是什么

从收到需求到明确需求——需求洞察