【测试设计】如何提升测试用例设计水平?
定义
测试用例(Test Case)是测试设计的一个产出物,它直接体现测试设计的思想,一份漂亮的测试用例不仅仅是设计思路的优秀体现,更是便于流转和执行,具有可读性、传递性。它一般是为某个特殊目标而编制的一组测试输入、执行条件及预期结果,用以核实程序是否满足某个特定需求及没有完成多余操作,即保证以下两点:
- 程序做了它应该做的事情
- 程序没有做它不该做的事情
因此,作为测试实施依据的测试用例,必须要能完整覆盖测试需求,而不应针对单个Case去评判好坏。
怎么写好用例
0、用例模板
首先,一份漂亮的测试用例-需有一个用例模板,模板可以将测试用例的结构形式固定化、标准化,对编写者启引导作用,保证一份测试用例数据完整。
1、对被测版本足够了解
由粗略详细步骤来解读产品需求文档,如交互、功能流程、边界、约束等等。充分理解技术实现原理(实现的逻辑原理、架构及对其他平台的依赖、接口等)。
深入理解用户群,分析用户使用场景、可能的使用方法及用户心理,完全从用户角度出发,来设计Case,同时对用户体验做出一定的判断。
2、设计Case优先级
一般BugFree或禅道工具中编写好Case后可以按优先级来筛选优先级,如果是用Excel文档来写可以来通过不同背景色来标识相应的优先级,无论评审还是执行,都可以按此来查阅。无论是冒烟测试用例还是功能测试用例,节省大量时间。
3、从粗到细分析需求
可以使用工具辅助,第一遍需求分析时,粗略画出测试需求框架;第二遍分析需求时,开始延伸每个出子测试点;细化测试点时,可参考或引用写好的公共Case, 也要考虑到被测版本中该功能的特性。另外需要考虑的就是测试点的颗粒度要把握好。
4、测试用例Update
需求分析阶段和开发阶段,都可能出现需求变更,这时对于我们前期粗略整理好的测试点就需要及时的同步更新了。另外在Case评审阶段,可能会出现Case冗余或遗漏,也需要在评审结束后在Case池里及时修整。如果项目中有使用需求工具之类的,可以利用工具去同步通知到每个节点的负责人,会大大 减少UPdate的时间。
5、常见的用例设计方法:
1)等价类划分
2)边界值分析法
3)因果图方法
4)正交表分析法
5)场景分析方法
6)状态图法
7)错误猜测法
其中
1)等价类、边界值主要是针对数据
2)其他几种主要针对业务或场景
3)再使用其他方法设计用例时几乎都要用到等价类
如何快速提升TestCase能力
1、 熟悉业务
这是必备条件,因为所有Case都是从业务层开始入手的,而终端使用者也是以业务为出发点。
2、 培养用户思维
测试人员需要站在客户的角度分析用户需要什么、想要什么、不想要什么,这样有利于我们更好的挖掘隐含需求。所以设计场景时也同样是站在用户角度。
3、 勿限制测试思维
对于好的测试人员,都会有自己的一份通用测试用例表, 每次编写测试用例时,会将重复或公共的功能摘出来,去参照已有的通用Case。但若不能做到及时更新,随公司项目变更等,很可能在某些项目中固步自封,不能灵活地运用。
所以通用Case总结更新是必不可少的,也可以分享出来让同行参谋 ,大家集思广益,也许其他人有更新奇的方法,这样会不断地开拓自己的测试思维 ,而不至于一直重复原有的经验。
4、 乐于分享,有计划地总结
给自己的学习过程制订一个详细的计划,量化到天,排好每天要学习的东西。同时最重要的是,一定要养成总结的习惯 ,每天总结 ,每个项目总结 ,总结测试方法,总结Bug原因,奇葩Bug等等,这些将会成为你日后工作的宝贵财富。
同时,主动总结久了,你会发现自己有质的提升,而且对于当前的工作会更游刃有余,经验是靠日积月累的。
一份漂亮的测试用例
一份漂亮的测试用例应该具有目标、可读、简洁的特点,而这些是通过从各个属性所填的内容散发出来的。
1、用例编号
用例编号就是测试用例文档中一个代号,需全局唯一,我们可以通过代号快速找到测试用例。
用例编号的书写,建议是项目名_模块名_001,我们可以通过编号快速知道一个项目有多少用例,项目中一个模块有多少用例。
2、用例标题
目的:概述测试用例的主要内容,明确用例意图
在做用例评审时,通过浏览一个模块的用例标题,能快速判断有没有遗漏功能;通过浏览一个功能用例标题,能快速判断出有没有遗漏正常或异常case。
一个测试用例的好坏,一半体现在测试用例标题上。一个好用例的标题,书写方式有三种:
- 一句完整的话(不超过30个汉字)
- 功能简报形式
- 例:电影详情页-返回
- 例:栏目-发布
- 例:电影-添加
- 按条件/状态
- 例:发起转码-无源媒体文件
- 例:发起转码-有源媒体文件
- 例:鉴权-已订购产品已过期
- 例:鉴权-已订购产品未过期
- 例:鉴权-未订购产品
3、预置条件
预置条件-测试用例能执行的前提条件。可以是到达某一状态,也可以是一些配置。
书写要求:一个简洁的结果。
- 用户已成功登陆
- 自动审核的开关已关
- 不需要写是怎么登陆的/如何将开关关掉的。
4、测试步骤
测试步骤是指如何执行用例,先做什么后做什么,是有顺序的概念在的。
步骤和用例的目标需要是一致的,任意一个偏离目标整个case就是无意义的。
书写要求:可执行的操作,功能用例步骤不大于7,流程用例步骤随业务而定-这里不做限制。
- 采集电影[check1]
- 预处理电影[check2]
- 审核电影[check3]
- 发布电影[check4]
5、预期结果
预期结果是和测试步骤一一对应的,有几个检查点,就需要有几个结果。
书写要求:和测试步骤中check点一一对应,检查点>=1个
预期结果需要是可检查的,可从三个方面进行校验:
- 界面(结果会直接显示在界面上的)
- 数据库(有些数据只会存于数据库中)
- 磁盘(文件数据需具体到磁盘上看是否存在,数据是否正确)
6、测试数据
测试数据:测试时使用到的数据。
书写要求:可用电影。
不用写到实际数据,在测试添加电影功能时,不需要写具体电影、导演、演员、宣传图片。
具体的数据-可以在数据准备时做好,如符合规格的图片(海报、图标、剧照),符合码率的媒体文件(正片和预览片)。
测试用例整体是有逻辑的
测试用例整体是有逻辑的-需要有用例设计的魂,编写测试用例的两个途径:
- 先有用例设计,从整个产品/项目出发,先确定测试范围、测试目标,再细化范围到具体对象->具体功能,确定设计用例技术和测试方法,再来编写用例。
- 测试执行后-通过Bug反推 修改补充用例。
两者相结合才会产出一份漂亮且有效的测试用例,理论->实践->理论过程。
编写测试用例常见问题
- 用例标题意图不明确
- 用例中引用其他用例
- 用例中包含过多的细节
- 用例中出现笼统的词
- 反复、多次
- 确定反复的具体次数
- 确定一个反复的范围
- 长时间
- 确定长时间的具体时间
- 确定一个长时间的范围
- 大量
- 确定具体的数据量
- 从需求/规格中中参照值
- 用例中步骤不可执行
- 用例中期望结果不可验证