Star （测试开发工程师）浏览器
有道笔记组用敏捷开发两年多了，对于敏捷，有不少的文章在写，我就不班门弄斧了，我只说下和咱们测试相关的一些状况。app
每次迭代，都有大量的测试用例，评审每每要花不少时间，效果很差；产品更新快，开发没有合适的依据自测，提测的质量没有预期的好；需求根据市场的需求不断有改动，全部人都为跟上需求而发愁；需求的内容量大，测试执行的时候会不记得有些功能的设计，若是找文档速度每每比较慢；准入测试没有很好的依据，不能在短期内发现block测试的问题。工具
像是个魔咒，又像一个怪圈，每次都在抱怨这些问题，然而却迟迟得不到很好的解决，直到有一天，咱们遇到了思惟导图…单元测试
思惟导图是英国著名心理学家东尼.博赞在20世纪60年代发明的风靡世界的思惟工具。通俗地说，思惟导图是一个简单、有效、美丽的思惟工具。它依据全脑的概念，按照大脑自身的规律进行思考，全面调动左脑的逻辑、顺序、条例、文字、数字以及右脑的图像、想象、颜色、空间、总体思惟，使大脑潜能获得最充分的开发，从而极大地发掘人的记忆、创造、身体、语言、精神、社交等各方面的潜能。测试
思惟导图是一种将放射性思考具体化的方法。放射性思考是人力大脑的天然思考方式，每一种进入大脑的资料，均可以成为一个思考中心，并由此中心向外发散出成千上万的关键点，每个关键点表明与中心主题的一个链接，而每个链接又能够成为另外一个中心主题，再再向外发散出成千上万的关键点，呈现出放射性立体结构。this
一般的记录方式都是线性的，一行一行，一页一页的下去，没法体现出来关系，也不能突出中心和重点，更不方便记忆。而思惟导图就是用图形结构的方式，列出相关内容，并表示出内容之间的关系，并显示出重点和核心，详细特色以下：
1. 简单，易用
2. 关联，每一思想主意均可能有联系
3. 可视化，容易记忆
4. 线状辐射，容许从各个角度展开工做
5. 提纲挈领，帮助咱们立足全局把握问题之间的联系spa
说了这么多都是在说思惟导图的思想和特色，那结合到咱们的应用中，就是使用思惟导图的软件（见附注），改善咱们测试的工做，走出测试的困境。操作系统
首先体如今测试用例评审的准备上。使用思惟导图，按思惟导图的思路，将整个功能做为一个中心，相关的做为分支，分支本身又做为一个新的中心，列出和它相关的部分，如此循环，直到穷尽。在列这些的时候，其实是测试技能自己和思惟导图工具的一种结合。在写case的时候，是一个从上到下的过程，每一层都进行分类，而后查看分类是否彻底，相似MECE的思想，当前层分类和覆盖足够之后，再进行下一层。
在使用思惟导图以前的状况是，在你对当前层进行细分的时候，突然发现上一层好像遗漏掉了什么，因而又要各类的添加补充。固然用excel作这个事情也能够，可是使用excel进行添加，每每须要仔细查找该添加到什么地方，层级关系也很差对应，并且在查找的过程也会打断原来的思路，不知道原来作到什么地方了，并且后续添加不得不一再的调整格式，添加行，合并单元格…设计
可是使用思惟导图就简单多了，发现哪一层少了什么，一眼就能找到，并且添加方便，添加以后并不会影响到以前想到的地方。这个思惟导图列出来，就至关于介于产品文档和case之间的一个产物，十分清晰的体现出各个功能之间的联系，以下图：
而后是用在具体的用例评审。评审是必不可少的一个环节，由于产品、开发、测试三方的理解会有差别，因此须要在评审过程当中达成一致。以前的评审，是使用excel，对着一条条的用例进行说明。一般思惟导图上列的一个功能至少对两条测试用例，每一个测试用例至少有两个操做步骤，当思惟导图最下一层的分支量达到100个的时候， 测试用例 行数每每能达到400行。当一条一条过 测试用例的时候，参与者每每就会陷在具体的 测试用例里，背景，大分类均可能不记得了，时间每每也要2个小时以上，并且若是是用例写出来以后，过一段时间再作的评审，那么写用例的人须要很长时间才能记起当时写用例的思路，可是看思惟导图每每只须要很短的时间就能记起来，并且自己思惟导图的内容也不容易忘记。
当使用思惟导图评审的时候，思惟导图的精简，内容相关，结构清晰，关联清楚的特色就一览无遗了，虽然不是过测试用例（其实测试用例自己是测试同事的事情，若是功能点列的足够全，又都达成一致的状况下，你们写出来的用例都是差很少的），可是全部该涉及到的地方都应该包含了。开会的时间每每也会少不少。在评审过程当中，若是有错误或不一致的地方，当时就能够修改完成，添加修改很是方便。
第三是用在把思惟导图转换为测试用例。思惟导图是介于需求和测试用例之间的产物，思惟导图会列出全部的功能点和各类组合，已是很全面了。可是测试用例要求的是有正向反向的测试用例，须要有具体的步骤，因此后面在写测试用例的时候就根据思惟导图所列的状况，加上步骤，加上正向反向的测试用例，就能够了，而不用像以前那样，根据需求一条条的想测试用例，又怕漏掉，写测试用例的工做变的简单不少。在根据思惟导图写用例的时候，思路会很清楚，功能之间的关联，写过的和没写过的部分，剩余多少工做，一目了然。
第四是评审结果的其它应用。评审过的思惟导图能够做为开发自测和测试执行准入测试的依据。要求开发自测一方面是由于bug发现的越早，修改的成本越低，即便一样是在产品发布以前，由测试人员测试出来的bug仍是比开发自测出来的bug的代价要高（固然是指的用简单的方式就能发现的bug，而不是要作不少尝试才能发现的）；另外一方面，开发同事在提交一个测试版本的时候，每每是以为本身作的已经很好了，而事实上经常会有明显的遗漏，那根据思惟导图进行自测一下，时间不长，并且又比较全面，比提供给开发的同事一些具体的测试用例效果要好的多。准入测试也和开发自测相似，要求快速，全面，抓住重点，因此按思惟导图执行是个很好的选择。
关于开发的自测，我还想多说一点。敏捷开发的一个核心实践和技术是TDD（Test-Driven Development），即测试驱动开发。原理是在开发功能代码以前，先编写单元测试用例代码，测试代码肯定须要编写什么产品代码。这固然是个理想的状态，大部分状况下都达不到。而咱们使用思惟导图做为参照并进行自测，实际上算是咱们走向TDD的过渡阶段，一样有助于产品的理解和开发质量的提升。
第五是咱们还但愿这个思惟导图能帮助开发的同事在开发的过程当中作一些检查，看看是否有遗漏的地方，是否有没有想到的地方（事实上，当咱们开发的同事在评审过咱们的思惟导图以后，说的最多的就是“这个东西要是早出来就行了”），只是如今咱们出图的时间比较落后，因此还须要进一步的努力。
在合适的场景下使用合适工具，对工做效率会有很大的提高；在不须要工具的场合勉强使用工具，只会让你的工做更加痛苦。思惟导图使用方便，功能强大，可是也不是在每一个场合都须要用到的。好比很小的功能的场合，硬要走这个流程，使用思惟导图，浪费人力。不过对于小的零散的功能，能够列在一个思惟导图里，持续更新，可是不走评审的流程，对于整个测试的积累仍是颇有用的。
赵本山有一句很经典的话：鞋合不合适，脚知道。套用到咱们这里就是，工具好很差用，用的人知道，思惟导图自己是一个颇有上手容易，又能给咱们带来不少便利，不妨来尝试一下吧。