关闭

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

发表于:2017-2-06 11:12

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:李乐    来源:51Testing软件测试网采编

  四、脑图用例实践指引
  脑图编写不是漫无目的去思考,正如探索式测试策略,并不是指无目的去做即兴测试,有原则指引很重要。团队采用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,这是对测试的误解,因此不建议实施脑图用例的几点:
  1、抱着通过脑图用例把需求覆盖100%、bug为0;
  2、对业务不熟悉,看不到脑图用例的故事点,因为它有时候比较隐晦;
  3、团队及主管没有耐心;
  4、通过外包做测试,需要详细用例执行步骤、测试报告;
  5、研发、测试没有沟通,只有研发完成交付,测试才介入;
  6、脑图用例,不仅对研发自身素质要求高,测试要求也高,不单单要有相关测试经验,而且也要有相关开发经验,可以理解开发过程遇到的问题甚至有时候需要渗入到开发代码中去排查。最后一张图,展示了脑图用例在Scrum框架中所处的位置,实际是贯穿整个从需求到运营阶段:
  
图-12-Scrum流程框架
22/2<12
《2023软件测试行业现状调查报告》独家发布~

精彩评论

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号