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