敏捷脑图测试用例实践之路(3)

图-1-Portal测试用例这个阶段，问题暴露越来越严重了：测试用例里面写死了数据、业务步骤不同测试人员都按照具体步骤来测试，就好比车载导航，变成“导航测试”了，如果需要测试其他客户、其他业务呢?有些测试人员就再复制一个用例出来，造成用例泛滥。测试用例依然没有思考的过程负责第一次编写的测试人员有思考，但负责执行的测试人员，没有再继续跟开发交互测试过程，没有更深入的思考，而是仅仅按照用例执行，那这种效果等于走过场。遇到十几个、甚至几十个步骤的功能，用例编写耗时例如：打开浏览器，输入账号密码登录，这些其实也是不必要展示的步骤，做测试就要熟悉业务，测试人员应当更加关注的是开发是否做了正确的功能，功能是否做了正确的事情，在一个测试、开发比例1:4(有些是1:10)的团队里面，测试人员的时间是有限的，不要陷入过分的步骤细节里面去深究，要把重点思路放在运用哪些测试方法、如何组合更加有效覆盖测试故事点。例如简洁的测试故事点：作为主帐户，输入正确的用户名和密码登录系统，以便能够查看当日的带宽数据。2不进则退-倒腾敏捷脑图用例传统的软件交付测试，可以简单描述为下图所示： 图-2-传统交付测试开发人员完成任务之后，最后交付给测试人员，这种模式下，测试人员不能及早发现需求阶段的缺陷、及时编写测试用例，用例评审滞后，发现缺陷同样也会滞后。而整个过程中丢失最大的环节就是：沟通、反馈。这在《全程软件测试实践：从需求到运营》文中也曾提过。倘若要是使用传统的用例编写，把测试团队人员的思维固化，这样子下去不进则退，不利于团队发展。鉴于此，创建了敏捷脑图用例，有以下原则：参与需求分析、记录验收要点全程软件测试，从需求阶段开始参与，在sprint会议上对功能点进行评估，消除含混性的疑点，将明确的作为验收要点，作为脑图用例故事点的参考来源。编写脑图用例，要与开发人员达成一致意见开发过程中，测试人员可以根据原型图设计脑图用例(没有实际系统，测试也可以先行)，与开发人员进行查漏补缺(也就是用例评审环节)，主要是确认测试功能点、测试故事，以及测试数据的准备，这几个方面不可能一开始就明确下来，要不断沟通、挖掘、完善脑图用例。3 脑图用例演化这里的重点主要讲一下脑图用例(推荐使用Xmind工具：http://www.xmind.net)的演化(测试故事点以后再做介绍)，从第一个大版本和第二个大版本的考虑，其中的小版本忽略。第一版本脑图用例要点：所见所想当时的想法很简单，以需求为思考出发点，把所有功能性、非功能性的列举出来，然后再整理故事点。 图-3-脑图用例模板v1.0第二版本的脑图用例要点：增加风险考虑

　　增加局部决策考虑例如：一个输入框(或者叫元素)，测试人员应当针对这个元素，结合数据，会考虑使用哪些测试方法进行操作呢?增加全局决策考虑例如：一个业务查询操作，在web上操作，会触发一系列元素(输入框、查询按钮)，这些应当如何组合、使用什么策略呢?遵循：重构->测试->重构->测试，的原则

图-4-脑图用例模板v2.0脑图的形式展现并不是最重要问题，关键问题是：思考的出发点，这个要整个团队参与讨论，达成共识，才能传承。引出思考点，大家就可以不断补充脑图，刚开始所有点可能是零散的，甚至一点关系都没有，这个时候就需要重构了，抽取相关点，下面会讲讲我们用什么方法来做。4 脑图用例实践指引脑图编写不是漫无目的去思考，正如探索式测试策略，并不是指无目的去做即兴测试，有原则指引很重要。团队采用SMART原则进行脑图用例实践：Specific(具体的)：测试需要一个具体的目标(甚至原型图都可以)，用来描述全景图。

原文转自：http://www.infoq.com/cn/articles/road-of-agile-mind-map-practice/