用MindMap整理测试要点，to be or not to be？

前段时间我们测试团队的一位同事在测试用例评审会议上借用MindMap图示来讲解测试要点，得到了开发同事的一致好评。开发同事反馈说以这样的形式来讲解比起以前对着Excel一行一行地过case要更清晰和高效。我想这其中最主要的一个原因是在测试用例评审会议上让大家大量阅读Excel里的细节内容的确让人难以长时间集中注意力，尤其对于某些测试用例，开发团队和测试人员都已经熟悉测试步骤，而“标题、步骤、数据、期望结果”这样的测试用例结构容易使重要的检查点淹没在大量重复的步骤中。现在通过MindMap言简意赅地拎出中重要的点，有结构有层次，当然更高效。另外，我觉得另一个重要的原因是MindMap大多可以在一个版面将一个复杂的用户故事呈现一个全貌，这对于一旦开始讲测试用例就只见树木不见森林的用例评审会无疑是一个福音：面对这样一幅全景图，大家更容易知道测试用例哪里遗漏了，而不仅仅是已有的逻辑哪里错了。

 

有着这样两大好处的新颖的测试用例讲解形式在测试团队中迅速推广开来，很多的MindMap文件开始在项目组流转。不光是测试人员用这种形式整理测试要点，做测试数据分析时也在用。不光是测试人员在用，开发人员做设计的时候也在用。一时间MindMap铺天盖地而来。终于，今天我感到了一点不对劲。

  

今天我在看一个测试用例的MindMap，发现里面提到了“要测试什么(what)”，但没有提到“如何测试(How)才能验证这个测试点是否正确”。这让我联想到平时有些需求看起来非常直白，但具体到如何测试却非常模糊。例如，对于海量的数据迁移的测试，逻辑清楚后还要考虑如何取样才能证明该逻辑的正确性。又如，接口相关的测试如果只考虑逻辑，可能在要开始测试执行的时候才发现由于双方schedule和环境的不一致性，测试难以开展。还有一些技术相关的需求变更，更是不但要知道做了哪些改变，还要知道如何测试才能以最小的代价测到点子上。所以，看来MindMap整理测试要点比较适用于内部运算比较复杂（而非交互性强）、细节的检查点比较多且散的需求。此时，测试人员可以利用MindMap图来整理思路和启发发散性的思考，也可以借用它来沟通自己的理解。但同时，更多地考虑可测试性，补充如何验证该测试点则会更有锦上添花的效果。

 

另一方面，也有一些需求并不适合MindMap图示的。比如，对于与数据多样性特别相关的需求，也许包含测试数据的实例是一个更好的选择；对于与流程步骤特别相关的需求，活动图更具优势。

 

作为测试人员，我们的任务是在合适的上下文下选择最能帮助我们测试当前需求的一种测试用例设计和展现的形式。此时，我突然有点好奇，不知道近期会不会有一个需求的测试用例设计需要用到数据实例、活动图和MindMap图这三种形式呢？带着期待继续我的测试。。。