传统的
黑盒测试用例比较
繁杂，在实施敏捷的项目中会显得
水土不服，让测试人员过度关注用例步骤的编写、修改，甚至同一条用例经过多人执行得到相同结果，让人想到一个呼之欲出的广告词：一次编写，多人运行相同结果，没有思考的过程,应该对用例进行改革，以便快速响应开发的交付节奏，同时形成用例评审规范，让开发、测试知己
知彼，也加强开发自测的环节。本文主要讲敏捷中脑图用例的实践。
不写
测试用例或许测得更快，但绝不是一个测试人员的最佳素养，而现在的测试用例又过于繁杂，消耗了很多
时间，怎么办呢？
先看看测试用例的定义：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期
结果，以便测试某个程序路径或核实是否满足某个特定需求。
还有测试用例编写的一般原则：
· 测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
· 测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。
测试用例也遇到非常多的问题：对业务不熟悉、没有测试经验的人是无法做到的（比如死机怎么处理，
浏览器挂了
怎么办）说实在的，每种情况不可能写的很明细，谁能保证所有可能路径都写出来呢？不懂业务的测试人员，有执
行测试用例的价值吗？测试用例应当是有思考活动存在的；测试用例没有思考的过程 负责第一次编写的测试人员有
思考，但负责执行的测试人员，没有再继续跟开发交互测试过程，没有更深入的思考，而是仅仅按照用例执行，那
这种效果等于走过场；打开浏览器，输入账号密码登录，这些其实是不必要展示的步骤
做测试就要熟悉业务，测试人员应当更加关注的是开发是否做了正确的功能，功能是否做了正确的事情，在一个测
试、开发比例1:4（有些是1:10）的团队里面，测试人员的时间是有限的，不要陷入过分的步骤细节里面去深究，要
把重点思路放在运用哪些测试方法、如何组合更加有效覆盖测试故事点
开发人员完成任务之后，最后交付给测试人员，这种模式下，测试人员不能及早发现需求阶段的缺陷、及时编写测
试用例，用例评审滞后，发现缺陷同样也会滞后。而整个过程中丢失最大的环节就是：沟通、反馈。这在《全程软
件测试实践：从需求到运营》文中也曾提过。
倘若要是使用传统的用例编写，把测试团队人员的思维固化，这样子下去不进则退，不利于团队发展。鉴于此，创
建了敏捷脑图用例，有以下原则：
全程
软件测试，从需求阶段开始参与，在sprint会议上对功能点进行评估，消除含混性的疑点，将明确的作为
验收要点，作为脑图用例故事点的参考来源。
2、编写脑图用例，要与开发人员达成一致意见
开发过程中，测试人员可以根据原型图设计脑图用例（没有实际系统，测试也可以先行），与开发人员进行查
漏补缺（也就是用例评审环节），主要是确认测试功能点、测试故事，以及测试数据的准备，这几个方面不可能一
开始就明确下来，要不断沟通、挖掘、完善脑图用例。
第一版本脑图用例
要点：所见所想
当时的想法很简单，以需求为思考出发点，把所有功能性、非功能性的列举出来，然后再整理故事点。
第二版本的脑图用例
要点：
· 增加风险考虑
· 增加局部决策考虑 例如：一个输入框（或者叫元素），测试人员应当针对这个元素，结合数据，考虑使用
哪些测试方法进行操作
· 增加全局决策考虑 例如：一个业务查询操作，在
web上操作，会触发一系列元素（输入框、查询按钮），这
些应当如何组合、使用什么策略
· 遵循：重构->测试->重构->测试，的原则
脑图的形式展现并不是最重要问题，关键问题是：思考的出发点，这个要整个团队参与讨论，达成共识，才能传承
。
引出思考点，大家就可以不断补充脑图，刚开始所有点可能是零散的，甚至一点关系都没有，这个时候就需要
重构了，抽取相关点
脑图编写不是漫无目的去思考，正如探索式测试策略，并不是指无目的去做即兴测试，有原则指引很重要。团队采
用SMART原则进行脑图用例实践：
· Specific（具体的）：测试需要一个具体的目标（甚至原型图都可以），用来描述全景图。
· Measurable（可度量的）：有明确的度量可以评估目标是否达成（也就是验收条件作为测试故事点的评判标
准）。
· Achievable（可实现的）：当前的目标应该是可实现的。这潜在地要求将一个大的目标分解为多个小目标，
每个小目标也是具体的、可度量的。此外，跟踪小目标的完成情况也提供了整体进度的可度量性（一个业务操作会
经过很多路径，每个路径可以单独存在或者组合存在，需要切分测试）。
· Relevant（相关的）：测试故事点从需求出发（包括功能性和非功能性），结合业务特性，以及相关上下文
作为切入点。
· Time-boxed（有时间限制的）：为每一轮脑图用例的构建设定一个合理的时间窗口，例如在固定的时间窗口
（一些人的专注度是45分钟，一些是60分钟，中排除不相关干扰、专注
工作）。
脑图用例编写流程：
· 参与持续需求分析（不仅仅是需求阶段，开发阶段的变化也需要及时捕获）制定脑图用例框架
· 将业务|功能测试目标分解成一系列测试任务，每个测试任务有明确的时间限制和退出条件。
· 测试计划之后，优先选择一个测试任务，在一个测程内执行探索式测试，测程以45|60分钟为一轮，执行多
轮。
· 反思当前的测试进展，并优化测试计划。增加或删除一些测试任务，以更加准确地反应测试对象。
脑图用例分析第一步：
首先把业务需求分析结果填写到目标中，然后分析功能（如果没有系统，可以只看原型图），找到页面的相关元素
，逐个列入脑图中，再为每个元素使用一些测试方法，例如：等价类、边界值，进行局部决策，这样子，所有元素
的分析完毕，就进入第二部全局。
脑图用例分析第二步：
第二步继续完善，进行全局分析以及列举一些非功能性需求：
全局分析：
找到需求描述或者跟开发沟通代码有限制条件的地方，而不是针对某个元素；
对不同元素组合有依赖关系的，也需要列出来
非功能性：
这个在文档中可能没有给出，需要根据经验来评估，可以参考团队积累业务的测试经验，通用的点：出错的用
户体验是否ok、查询时间效率如何等等
风险：
尽可能琢磨需求，挖掘风险，例如需求说：根据选定频道，但是没有说这个频道不属于客户怎么办？这个就是
思考的强大力量了。
脑图用例分析第三步：
第三步是最关键一步，产出测试故事点，根据风险、目标、要点分析得出，这里举了简单例子，可以使用关键路径
组合的方法来做。
当然，做完一二三步，也只是在第一个时间窗口而已（这个时候也可以直接用于测试环境探索下，验证一些关
键思路，增强信心），后续还需要重构-测试，在下一个时间窗口，查漏补缺，不断完善才可以用于时间测试。
允许团队成员在模板基础上进行变化，以发挥更多的思维空间，
五、关于富脑图及轻脑图用例
允许团队成员在模板基础上进行变化，以发挥更多的思维空间，主要有两种模式作为参考：
· 富脑图用例
个人认为，大脑对于图像的记忆，比文字更长久。富脑图，注重以图片、图标、图标、关联关系等记忆为主。
· 轻脑图用例
注重以简洁文字记忆为主
团队可以在不同场景，选择合适的模板来发挥、扩散测试的思维点。
不断完善用例的展现以及思考的出发点。其实，在整个开发、测试环节中，思考、沟通是最重要的环节，把产生的
、达成共识的内容记录下来，汇集在脑图中展现，就可以看到整个需求点测试的全景图，然后再不断细化成测试故
事点，这完全符合思维扩散以及总结的模式，大脑也容易接受，而且可以不断重构->测试->重构->测试，不断迭代下去。
