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