如何应对阻塞测试的问题？

大家是否会经常遇到测试到一半，发现因为提测质量差，导致测试进行不下去的情况；又或者是发现提测的版本与需求相差很大，不知道是否进行后续的测试。小编今天和大家理一理测试过程中常见的阻塞测试问题及解决方案。

1.功能基本可以走通但是bug太多

这种情况是最头痛的。因为如果是以此为理由，打回去给开发，理由并不完全站得住。一个是大家对bug多的标准不一致，我们说bug多，开发不一定认可。这个时候我们需要针对bug的情况进行一下分析：

1) bug集中，且可以跟其他模块切开

测试发现的bug是集中在整个功能的某一个模块中，该模块与整个功能的其他模块可分割，可以单独测试。如果是整个功能都基本正常，只有其中的一个模块有问题，那么可以先对其他模块进行测试，bug较集中的模块提交给开发重新对代码进行排查，待重新提测后再进行测试，对整体测试时间无影响。

2) bug集中，但是跟其他模块关联性强

测试发现的bug是集中在整个功能的某一个模块中，该模块与整个功能的其他模块关系较密切，无法单独测试。对其他模块进行测试，只打回这一个模块给开发，待开发重新代码review后，确认影响范围重新测试。对整体测试时间有影响，但是影响不大，需要在确认测试范围的时候花费一些时间。

3)bug不聚类，多数bug都不是严重问题，关联性不强

bug分散在整个功能的的各个模块，基本是因为整体代码质量不高引起的。但是bug都不是什么严重的问题，集中在UI显示等模块，这个时候测试需要全功能测试，待开发修复完bug后进行修复问题的二轮测试。增加二轮测试，对整体测试时间有影响。

4)bug不聚类，半数bug都是较严重的问题

bug分散在整个功能的的各个模块，基本是因为整体代码质量不高引起的。针对这种情况只能是全部打回去给开发，整体代码review后重新提测。提测时间delay，对整体测试时间有影响。

2.功能实现的与策略不一致

有些时候，开发提测，产品也经过验收通过，但是到测试手里一看，实现跟需求明显是有差异的，这个时候应该怎么办？我们能做的，一定是第一时间找产品确认“开发做成这样你知道吗？”，一般会有两种结果。

1)产品认可开发的实现。

如果是这种情况，我们那就让产品发需求变更，我们按照变更后的需求对功能进行测试。这种处理方法对整体测试时间基本无影响，只需要增加一个新需求确认的环节。

2)产品对开发的实现不从，一定要改回来。

这种情况那就没办法了，打回去重新按照需求实现，然后重新提测吧。提测时间delay，对整体测试时间有影响。

3.出现崩溃等异常完全无法继续测试下去

这种情况没什么好讨论的，直接打回去，等开发修复完全后再重新测试。但是前面已经测试过的部分，需要跟开发确认，如果修改后无影响的，可以不必再次从头开始测试。

原文链接

如需转载该篇文章，请注明来自“搜狗测试”