大话测试七略——让你的测试效率飞跃

一、防患于未然

一步错，步步错。
做项目也一样，开头出错了，后面将引出一系列的错误。所以为了保证产品质量，测试也应该尽早介入。
那对于技术人员，项目的第一步是什么？产品需求（也可以是原型、UI）。
要做防患于未然，测试则一定要参与到需求评审中，并对需求有问题的地方一一指出并得以确认处理。
对于研发周期长的项目，往往会要求做概要设计、详细设计，测试也应该加入评审。
什么？没人叫你去评审？
冲上去！以质量的名义。

二、随机应变

拥抱变化，敢于变化。
项目和技术瞬息万变，如果还是以不变应对万变，那不管是测试效率，还是测试质量都将大打折扣。
这里主要以测试用例说事，在之前需要你思考几个问题：
1、你每次花多长时间写用例？与测试时间相比，过长还是过短？
2、你所写的用例，有多少是复制粘贴的部分，差异可能仅几个字符？
3、按测试用例执行测试，能找出所有bug吗？
4、用例外发现的bug有多少？

--------------------------------------------思考完后继续往下------------------------------------------
当用例已经成为测试的负担，远远大于执行测试时间，并挤压了测试时间，那我认为可以考虑简化一下。
如果测试团队整体从业经验较低，那用例应设计的较详细。
如果测试团队整体从业经验较高，探索性测试发现的bug比重较大，那尝试用测试思维导图代替用例。

三、算无遗漏

测试设计用例时，随着需求的梳理与深入，往往可能会灵机一动，福至心灵，掐指一算，料定某处必有妖异，应有bug显现。
不妨一一记录下来，找时间携手开发按图索骥，一一消除。

四、逐一击破

不要等大军压境，做困兽之斗。应该主动出击，逐一击破。
于测试也如此。测试不要等所有功能开发完后才进行。
往往开发一窝蜂的把功能扔过来，会让测试感觉天塌地陷，顾此失彼，怨气冲天；
产品最终质量很难保证，效率也无从谈起。
所以，不妨主动出击，让开发每开发完一个模块就交付测试，或者提前介入接口测试。
当整体交付时，留下更多的时间用于业务、异常等方面的测试，让我们的测试效率飙起来。

五、一剑封喉

千刀见血不如一剑封喉。
测试也如此，我们与其把精力分散到各处寻找些无关痛痒的bug；
不如集中精力保证核心功能和业务的测试质量，特别在测试时间不充裕的情况下。
这就是“28”定律。

六、不漏不缺

牵一发而动全身。
开发修复一个bug，或者新增优化一个小功能，也可能会导致其他功能受影响。
要做到不漏不缺，此时回归测试就显得很有必要。不仅仅是发版前的回归，还应该包括发版后的回归走查。
如果可以，可以让回归测试自动化。
如果自动化困难，那则分别针对试验室环境、线上环境制作一个回归测试list，原则是保证主要、高频使用功能被覆盖。

七、斩草除根

斩草不除根，春风吹又生。
做测试也一样。如果不从bug出现的根源上去寻找原因，做好质量改进工作，那后续还会出现类似的bug。
所以，每次项目测试后，我们都应该做好总结，分析bug出现的原因：

• 需求不完善？
• 开发人员的粗心大意？
• 测试用例覆盖度不够？
• 测试没做好回归测试？
• 团队信息不同步？

做好测试总结与分析，找到bug出现的根源，协同项目负责人逐一改进规避，才能让产品的质量越来越高。

这次就讲到这，欢迎关注小酋后续更多精彩文章。凑齐七略不易，希望大家关注公众号多多支持，咱们下次见~

本文由51ste.com网友编辑，未经授权，不得转载使用上述作品盈利；个人转载，需标明作者及出处。