思维导图–云笔记测试的利器 – 有道技术沙龙博客

Star （测试开发工程师）

有道笔记组用敏捷开发两年多了，对于敏捷，有很多的文章在写，我就不班门弄斧了，我只说下和我们测试相关的一些情况。

每次迭代，都有大量的测试用例，评审往往要花很多时间，效果不好；产品更新快，开发没有合适的依据自测，提测的质量没有预期的好；需求根据市场的需求不断有改动，所有人都为跟上需求而发愁；需求的内容量大，测试执行的时候会不记得有些功能的设计，如果找文档速度往往比较慢；准入测试没有很好的依据，不能在短时间内发现block测试的问题。

像是个魔咒，又像一个怪圈，每次都在抱怨这些问题，然而却迟迟得不到很好的解决，直到有一天，我们遇到了思维导图…

思维导图是英国著名心理学家东尼.博赞在20世纪60年代发明的风靡世界的思维工具。通俗地说，思维导图是一个简单、有效、美丽的思维工具。它依据全脑的概念，按照大脑自身的规律进行思考，全面调动左脑的逻辑、顺序、条例、文字、数字以及右脑的图像、想象、颜色、空间、整体思维，使大脑潜能得到最充分的开发，从而极大地发掘人的记忆、创造、身体、语言、精神、社交等各方面的潜能。

思维导图是一种将放射性思考具体化的方法。放射性思考是人力大脑的自然思考方式，每一种进入大脑的资料，都可以成为一个思考中心，并由此中心向外发散出成千上万的关键点，每一个关键点代表与中心主题的一个连接，而每一个连接又可以成为另一个中心主题，再再向外发散出成千上万的关键点，呈现出放射性立体结构。

通常的记录方式都是线性的，一行一行，一页一页的下去，无法体现出来关系，也不能突出中心和重点，更不方便记忆。而思维导图就是用图形结构的方式，列出相关内容，并表示出内容之间的关系，并显示出重点和核心，详细特点如下：
1. 简单，易用
2. 关联，每一思想主意都可能有联系
3. 可视化，容易记忆
4. 线状辐射，允许从各个角度展开工作
5. 提纲挈领，帮助我们立足全局把握问题之间的联系

说了这么多都是在说思维导图的思想和特点，那结合到我们的应用中，就是使用思维导图的软件（见附注），改善我们测试的工作，走出测试的困境。

首先体现在测试用例评审的准备上。使用思维导图，按思维导图的思路，将整个功能作为一个中心，相关的作为分支，分支自己又作为一个新的中心，列出和它相关的部分，如此循环，直到穷尽。在列这些的时候，实际上是测试技能本身和思维导图工具的一种结合。在写case的时候，是一个从上到下的过程，每一层都进行分类，然后查看分类是否完全，类似MECE的思想，当前层分类和覆盖足够以后，再进行下一层。
在使用思维导图之前的情况是，在你对当前层进行细分的时候，忽然发现上一层好像遗漏掉了什么，于是又要各种的添加补充。当然用excel做这个事情也可以，但是使用excel进行添加，往往需要仔细查找该添加到什么地方，层级关系也不好对应，而且在查找的过程也会打断原来的思路，不知道原来做到什么地方了，而且后续添加不得不一再的调整格式，添加行，合并单元格…

但是使用思维导图就简单多了，发现哪一层少了什么，一眼就能找到，而且添加方便，添加之后并不会影响到之前想到的地方。这个思维导图列出来，就相当于介于产品文档和case之间的一个产物，十分清晰的体现出各个功能之间的联系，如下图：

然后是用在具体的用例评审。评审是必不可少的一个环节，因为产品、开发、测试三方的理解会有差异，所以需要在评审过程中达成一致。之前的评审，是使用excel，对着一条条的用例进行说明。通常思维导图上列的一个功能至少对两条测试用例，每个测试用例至少有两个操作步骤，当思维导图最下一层的分支量达到100个的时候，测试用例行数往往能达到400行。当一条一条过测试用例的时候，参与者往往就会陷在具体的测试用例里，背景，大分类都可能不记得了，时间往往也要2个小时以上，而且如果是用例写出来之后，过一段时间再做的评审，那么写用例的人需要很长时间才能记起当时写用例的思路，但是看思维导图往往只需要很短的时间就能记起来，而且本身思维导图的内容也不容易忘记。

当使用思维导图评审的时候，思维导图的精简，内容相关，结构清晰，关联清楚的特点就一览无遗了，虽然不是过测试用例（其实测试用例本身是测试同事的事情，如果功能点列的足够全，又都达成一致的情况下，大家写出来的用例都是差不多的），但是所有该涉及到的地方都应该包含了。开会的时间往往也会少很多。在评审过程中，如果有错误或不一致的地方，当时就可以修改完成，添加修改非常方便。

第三是用在把思维导图转换为测试用例。思维导图是介于需求和测试用例之间的产物，思维导图会列出所有的功能点和各种组合，已经是很全面了。但是测试用例要求的是有正向反向的测试用例，需要有具体的步骤，所以后面在写测试用例的时候就根据思维导图所列的情况，加上步骤，加上正向反向的测试用例，就可以了，而不用像之前那样，根据需求一条条的想测试用例，又怕漏掉，写测试用例的工作变的简单很多。在根据思维导图写用例的时候，思路会很清楚，功能之间的关联，写过的和没写过的部分，剩余多少工作，一目了然。

第四是评审结果的其它应用。评审过的思维导图可以作为开发自测和测试执行准入测试的依据。要求开发自测一方面是因为bug发现的越早，修改的成本越低，即使同样是在产品发布之前，由测试人员测试出来的bug还是比开发自测出来的bug的代价要高（当然是指的用简单的方式就能发现的bug，而不是要做很多尝试才能发现的）；另一方面，开发同事在提交一个测试版本的时候，往往是觉得自己做的已经很好了，而事实上常常会有明显的遗漏，那根据思维导图进行自测一下，时间不长，而且又比较全面，比提供给开发的同事一些具体的测试用例效果要好的多。准入测试也和开发自测类似，要求快速，全面，抓住重点，所以按思维导图执行是个很好的选择。

关于开发的自测，我还想多说一点。敏捷开发的一个核心实践和技术是TDD（Test-Driven Development），即测试驱动开发。原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。这当然是个理想的状态，大部分情况下都达不到。而我们使用思维导图作为参照并进行自测，实际上算是我们走向TDD的过渡阶段，同样有助于产品的理解和开发质量的提高。

第五是我们还希望这个思维导图能帮助开发的同事在开发的过程中做一些检查，看看是否有遗漏的地方，是否有没有想到的地方（事实上，当我们开发的同事在评审过我们的思维导图之后，说的最多的就是“这个东西要是早出来就好了”），只是现在我们出图的时间比较落后，所以还需要进一步的努力。

在合适的场景下使用合适工具，对工作效率会有很大的提升；在不需要工具的场合勉强使用工具，只会让你的工作更加痛苦。思维导图使用方便，功能强大，但是也不是在每个场合都需要用到的。比如很小的功能的场合，硬要走这个流程，使用思维导图，浪费人力。不过对于小的零散的功能，可以列在一个思维导图里，持续更新，但是不走评审的流程，对于整个测试的积累还是很有用的。

赵本山有一句很经典的话：鞋合不合适，脚知道。套用到我们这里就是，工具好不好用，用的人知道，思维导图本身是一个很有上手容易，又能给我们带来很多便利，不妨来尝试一下吧。