传统的黑盒测试用例比较繁杂，在实施敏捷的项目中会显得水土不服，让测试人员过度关注用例步骤的编写、修改，甚至同一条用例经过多人执行得到相同结果，让人想到一个呼之欲出的广告词：一次编写，多人运行相同结果，没有思考的过程。在经历过这些痛楚之后，对用例进行改革，以便快速响应开发的交付节奏，同时形成用例评审规范，让开发、测试知己知彼，也加强开发自测的环节。本文主要讲敏捷中脑图用例的实践。
一、转型测试掉进传统用例坑
在《软件测试转型之路》中，经历了无法忘记的几个月：每天高强度测试、反复编写、修改用例步骤，深刻体会：
不写测试用例或许测得更快，但绝不是一个测试人员的最佳素养，而现在的测试用例又过于繁杂，消耗了很多时间，怎么办呢？
先看看测试用例的定义：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
还有测试用例编写的一般原则：
· 测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
· 测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。
按照定义和原则以及模板，实践了三个月的备案系统，列举一些简单测试用例如下：
· 服务器、帐号信息
测试服务器地址：http://127.0.0.1/login.do
测试管理员账号和密码
管理员：admin
密码：admin
· ICP备案信息录入
测试数据参考：附录-ICP信息录入测试数据
· ICP备案历史信息查询 步骤名称
反思当时遇到的问题：
所有测试用例编写完毕，都经历了：第一次编写后调试、发现问题重新修改步骤、再次调试发布，过程相当繁琐，而且当时测试人力不足，还得把这些用例分配给客服进行测试，客服按照测试用例也遇到非常多的问题：死机怎么处理、浏览器挂了信息怎么办等等（实际上这里有一些决策是客服无法做得，对业务不熟悉、没有测试经验）。说实在的，不是专业测试人员，这个用例无法执行下去了，就是每种情况写的不够明细，谁能保证所有可能路径都写出来呢？不懂业务的测试人员，有执行测试用例的价值吗？测试用例应当是有思考活动存在的。
另外，在excel编写用例，不是永远的办法，后来把测试用例迁移到testlink上，确实比较方便，依然还是传统编写步骤的方式：
图-1-Portal测试用例
这个阶段，问题暴露越来越严重了：
1、测试用例里面写死了数据、业务步骤 不同测试人员都按照具体步骤来测试，就好比车载导航，变成“导航测试”了，如果需要测试其他客户、其他业务呢？有些测试人员就再复制一个用例出来，造成用例泛滥。
2、测试用例依然没有思考的过程 负责第一次编写的测试人员有思考，但负责执行的测试人员，没有再继续跟开发交互测试过程，没有更深入的思考，而是仅仅按照用例执行，那这种效果等于走过场。
3、遇到十几个、甚至几十个步骤的功能，用例编写耗时 例如：打开浏览器，输入账号密码登录，这些其实也是不必要展示的步骤，做测试就要熟悉业务，测试人员应当更加关注的是开发是否做了正确的功能，功能是否做了正确的事情，在一个测试、开发比例1:4（有些是1:10）的团队里面，测试人员的时间是有限的，不要陷入过分的步骤细节里面去深究，要把重点思路放在运用哪些测试方法、如何组合更加有效覆盖测试故事点。
例如简洁的测试故事点：作为主帐户，输入正确的用户名和密码登录系统，以便能够查看当日的带宽数据。
二、不进则退-倒腾敏捷脑图用例
传统的软件交付测试，可以简单描述为下图所示：
图-2-传统交付测试
开发人员完成任务之后，最后交付给测试人员，这种模式下，测试人员不能及早发现需求阶段的缺陷、及时编写测试用例，用例评审滞后，发现缺陷同样也会滞后。而整个过程中丢失最大的环节就是：沟通、反馈。这在《全程软件测试实践：从需求到运营》文中也曾提过。
倘若要是使用传统的用例编写，把测试团队人员的思维固化，这样子下去不进则退，不利于团队发展。鉴于此，创建了敏捷脑图用例，有以下原则：
全程软件测试，从需求阶段开始参与，在sprint会议上对功能点进行评估，消除含混性的疑点，将明确的作为验收要点，作为脑图用例故事点的参考来源。
2、编写脑图用例，要与开发人员达成一致意见
开发过程中，测试人员可以根据原型图设计脑图用例（没有实际系统，测试也可以先行），与开发人员进行查漏补缺（也就是用例评审环节），主要是确认测试功能点、测试故事，以及测试数据的准备，这几个方面不可能一开始就明确下来，要不断沟通、挖掘、完善脑图用例。
三、脑图用例演化
这里的重点主要讲一下脑图用例（推荐使用Xmind工具：http://www.xmind.net）的演化（测试故事点以后再做介绍），从第一个大版本和第二个大版本的考虑，其中的小版本忽略。
第一版本脑图用例
要点：所见所想
当时的想法很简单，以需求为思考出发点，把所有功能性、非功能性的列举出来，然后再整理故事点。
图-3-脑图用例模板v1.0
第二版本的脑图用例
要点：
· 增加风险考虑
· 增加局部决策考虑 例如：一个输入框（或者叫元素），测试人员应当针对这个元素，结合数据，会考虑使用哪些测试方法进行操作呢？
· 增加全局决策考虑 例如：一个业务查询操作，在web上操作，会触发一系列元素（输入框、查询按钮），这些应当如何组合、使用什么策略呢？
· 遵循：重构->测试->重构->测试，的原则
图-4-脑图用例模板v2.0
脑图的形式展现并不是最重要问题，关键问题是：思考的出发点，这个要整个团队参与讨论，达成共识，才能传承。
引出思考点，大家就可以不断补充脑图，刚开始所有点可能是零散的，甚至一点关系都没有，这个时候就需要重构了，抽取相关点，下面会讲讲我们用什么方法来做。
