提高测试设计质量的有效方法--详述“㈢级评审”机制在项目中的应用

treeou

在软件生产过程中，测试工作的重要性不言而喻，虽然敏捷开发模式将质量控制活动进一步分散，但不可否认，测试活动仍是保证软件质量的最重要环节。而对于测试活动而言，测试设计工作又是整个测试活动的重中之重，一个良好的测试结果离不优秀的测试设计，俗话说“大兵未动，粮草先行。”，测试设计便是测试工作的粮草。

既然测试设计如此重要，那么，影响测试设计质量的最大因素是什么？我们假设投入的人员数量是固定的，那么其它的诸如：时间、人员经验、人员业务知识等附加因素则对测试设计质量有着直接的、重要的影响。但仔细分析之下，这些因素通常又是实际工作中最难控制的，多数的项目没办法投入充足的时间、足够的人员来进行测试设计，甚至投入的人员对目标系统的业务知识也一无所知。那么在这种情况下，用什么方法可以让测试设计的质量和效率更高些呢！

传统的讲述测试设计方法中，主要是从技术手段方面提出的，比如：边界值分析法、因果图法、错误推测法等，同时试图从历史积累、同业经验等方面寻找借鉴，但却很少关注测试设计的实际过程。那问题来了，我们能不能通过某些方法，让测试设计的过程变得可信与与可控，从而提高测试设计的质量。

我们先来看看测试设计的根本目的是什么，我总结一下，不外忽以下四点：
1、促使测试人员深入的理解需求；
2、促使测试人员更好的理清测试思路和测试方法；
3、促使测试人员更好的规划测试路径和场景；
4、形成可供执行的测试用例（包括测试数据）；
这四项工作中前三项才是完成优秀测试设计的根本，测试用例只是对以上工作的落实和文字体现。那么问题来了，以前通行的做法是把重点放在第四点“形成可供执行的测试用例（包括测试数据）”上，在讲解和讨论完需求后就开始实际的编写测试用例、在测试用例编写完成后进行用例的评审。实际上，我们经过多个项目的证明，这种做法并没有达成预期的目的。所以，多数时间，在完成测试设计工作后，测试人员感觉效果不明显，又浪费了不少宝贵的时间。

其实这种通行的做法效果的确很一般，尤其是在面对较为复杂系统的测试设计工作中效果更加不好。基于这些问题，根据多年在各类项目中的工作实践，我整理出了一种较为实用的测试设计方法，将测试设计过程分解为：需求理解、思路设计、用例编写三个关键子活动，并在这三个子活动中加入评审机制做为出口的认证，称之为“三级评审”机制。以下对“三级评审”机制进行详细的描述，以便大家更好的理解。

第一级评审：需求理解评审
需求理解是整个测试设计活动的基础性工作，如果没有深入理解系统的需求，甚至理解偏差、错误，这种情况下设计的测试用例肯定是不可信、不完整的，不能保证测试结果的质量。“千里之行、始于足下”，基础性工作的重要性不言而喻，所以，这阶段工作需务必重视。这部分的工作内容通常分三部分来进行（评审），即：
1、系统整体需求理解；
2、所负责模块的需求理解；
3、所负责模块关联需求的理解；
这三部分内容缺一不可，理解结果的好坏代表了从“点”到“块”、从“块”“面”的深入程度，理解没问题代表根基牢固、主线正确，基本可以保证后续的工作不会偏离方向。通常这部分工作的成果物有需求理解笔记、系统（模块）关联图/表等。

第二级评审：设计思路评审
这部分是“三级评审”机制的重点工作内容。将这部分内容提出来，是因为我们在以往的测试用例设计活动中，有多次设计活动接近尾声，结果在评审时，甚至在执行时发现了太多的漏洞，除了用例颗粒度、书写方式等描述性问题外，用例效率也不高，进而影响了整体的工作进程。这里的用例效率包括二方面的含义：
1、用例的设计效率：指固定时间段内每人设计的用例数量；
2、用例的覆盖效率，指的是某固定的用例数所覆盖的功能点（或需求点）数；
主体思想指引工作方向，做事思路决定工作结果，这是我将测试设计思路这个活动分离出来，做为独立的测试设计过程的最主要原因。测试思路设计（评审）活动主要的工作内容有：
1、重点、要点、难点的分析；
2、测试思路的设计；
3、关联点配合思路；
这部分工作的完成代表从“方向”到“实践”的转变，代表基础性工作的结束。这部分内容没问题，接下来的测试用例设计工作就会变得容易很多。通常这部分工作的成果物有测试设计要点、业务流程图、系统数据流转图等。

第三级评审：测试用例评审
测试用例（包括测试数据）是测试设计结果的直接体现，也是测试人员在测试执行时的第一参照物。以前我们会将这项工作做为重点，认为通过详细的用例评审，找出遗漏的和不全面的设计，就可以保证测试用例的高质量和测试路径的高覆盖。但这项工作实在是太劳心、太费力了，并且实际工作中的效果并不好，不说评审时经常发现设计人员思路上的误区和设计上的低效率，就是多数的项目都属于时间紧、任务重的情况，根本没有时间进行详细的用例评审。所以，这项工作多是走了个过场，不但浪费了时间，也达不到应有的效果。所以在实际工作中，我们对这部分的工作方式做了调整和优化：在编写测试用例时，会根据时间和资源的投入情况对成果物的颗粒度进行设定；在评审时也会有所侧重，通常会以关键模块为主要目标、随机抽取某部分用例为策略展开评审活动，这样即节省了时间，也提高了评审的效率。当然了，这么做的信心也是来源于前二级评审活动的支持。

以上是根据以往的工作经验提出一套提高测试设计质量的管理方法，希望对各位同行，尤其是测试管理岗位人员有些帮助。（当然，如果你说项目时间太紧了，没有时间做测试设计，也没时间做评审，那么请忽略这篇文章。）

最后需要再强调一下，我们不要将测试设计工作的范围限定得太死了，没有任何理论和文章将测试设计活动定义为只是测试用例（包含测试数据）的设计。既然称之为测试设计“活动”，说明它是动态的，要有“过程”和“成果物”二方面的体现。所以，我们要将目光放得更高远些，跳出传统的只关注“结果”的方式，将“过程”和“结果”有效融合，统一管理起来，这才是测试设计工作的正确打开方式。

海海豚

谢谢分享！

51Testing_叮当

学习了

Miss_love