专栏名称: 51Testing软件测试网
51Testing软件测试网,人气最旺的软件测试技术门户,提供软件测试社区交流,软件测试博客,人才服务,测试沙龙,测试杂志,测试资料下载等全方位信息服务,是国内最专业的软件测试就业培训、企业服务供应商...
目录
相关文章推荐
51好读  ›  专栏  ›  51Testing软件测试网

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

51Testing软件测试网  · 公众号  · 测试  · 2017-02-06 17:31

正文


  传统的黑盒测试用例比较繁杂,在实施敏捷的项目中会显得水土不服,让测试人员过度关注用例步骤的编写、修改,甚至同一条用例经过多人执行得到相同结果,让人想到一个呼之欲出的广告词:一次编写,多人运行相同结果,没有思考的过程。在经历过这些痛楚之后,对用例进行改革,以便快速响应开发的交付节奏,同时形成用例评审规范,让开发、测试知己知彼,也加强开发自测的环节。本文主要讲敏捷中脑图用例的实践。

  一、转型测试掉进传统用例坑

  在《软件测试转型之路》中,经历了无法忘记的几个月:每天高强度测试、反复编写、修改用例步骤,深刻体会:

  不写测试用例或许测得更快,但绝不是一个测试人员的最佳素养,而现在的测试用例又过于繁杂,消耗了很多时间,怎么办呢?

  先看看测试用例的定义:测试用例(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-传统交付测试

  开发人员完成任务之后,最后交付给测试人员,这种模式下,测试人员不能及早发现需求阶段的缺陷、及时编写测试用例,用例评审滞后,发现缺陷同样也会滞后。而整个过程中丢失最大的环节就是:沟通、反馈。这在《全程软件测试实践:从需求到运营》文中也曾提过。

  倘若要是使用传统的用例编写,把测试团队人员的思维固化,这样子下去不进则退,不利于团队发展。鉴于此,创建了敏捷脑图用例,有以下原则:

  1、参与需求分析、记录验收要点

  全程软件测试,从需求阶段开始参与,在sprint会议上对功能点进行评估,消除含混性的疑点,将明确的作为验收要点,作为脑图用例故事点的参考来源。

  2、编写脑图用例,要与开发人员达成一致意见

  开发过程中,测试人员可以根据原型图设计脑图用例(没有实际系统,测试也可以先行),与开发人员进行查漏补缺(也就是用例评审环节),主要是确认测试功能点、测试故事,以及测试数据的准备,这几个方面不可能一开始就明确下来,要不断沟通、挖掘、完善脑图用例。

  三、脑图用例演化

  这里的重点主要讲一下脑图用例(推荐使用Xmind工具)的演化(测试故事点以后再做介绍),从第一个大版本和第二个大版本的考虑,其中的小版本忽略。

  第一版本脑图用例

  要点:所见所想

  当时的想法很简单,以需求为思考出发点,把所有功能性、非功能性的列举出来,然后再整理故事点。

 

 图-3-脑图用例模板v1.0

  第二版本的脑图用例

  要点:

  • 增加风险考虑

  • 增加局部决策考虑 例如:一个输入框(或者叫元素),测试人员应当针对这个元素,结合数据,会考虑使用哪些测试方法进行操作呢?

  • 增加全局决策考虑 例如:一个业务查询操作,在web上操作,会触发一系列元素(输入框、查询按钮),这些应当如何组合、使用什么策略呢?

  • 遵循:重构->测试->重构->测试,的原则

  图-4-脑图用例模板v2.0

  脑图的形式展现并不是最重要问题,关键问题是:思考的出发点,这个要整个团队参与讨论,达成共识,才能传承。

  引出思考点,大家就可以不断补充脑图,刚开始所有点可能是零散的,甚至一点关系都没有,这个时候就需要重构了,抽取相关点,下面会讲讲我们用什么方法来做。

......

 
推荐阅读

点击阅读☞敏捷环境中的自动回归测试

点击阅读☞自动化回归测试在敏捷环境中的挑战

点击阅读☞一个测试者眼中的敏捷和Scrum方法

点击阅读☞基于BDD的敏捷测试和实践

点击阅读☞敏捷项目管理实战经验谈

点击左下角“阅读原文”查看更多内容!