我也开通测试空间了 : ) :)

转 如何写一份漂亮的测试用例?

上一篇 / 下一篇  2019-08-30 15:34:23 / 个人分类:web测试


测试用例是测试设计的一个产出物,它直接体现测试设计的思想,一份漂亮的测试用例不仅仅是设计思路的优秀体现,更是便于流转和执行,具有可读性、传递性。


首先,一份漂亮的测试用例-需有一个用例模板


  模板的作用:将测试用例的结构形式固定化、标准化,对编写者启引导作用,保证一份测试用例数据完整。



       两份模板差别在于 机顶盒1和机顶盒2,因在IPTV行业,是通过机顶盒展示给用户的,而当前机顶盒厂商多,需要进行兼容性测试,将需要测试的机顶盒直接标记在用例中,执行哪款盒子,就直接在哪款盒子上写结果即可。

 同一个功能在多个机顶盒上是否OK 一目了然,哪款盒子测试用例通过率/失败率也非常清晰,如你测试的是网站可将机顶盒改成 IE11 Chrome 等。


其次,测试用例具有目标、可读、简洁。

 

       测试用例的目标、可读、简洁是从各个属性所填的内容散发出来的。
  1、用例编号
  用例编号就是测试用例文档中一个代号,需全局唯一,我们可以通过代号快速找到测试用例。
  用例编号的书写,建议是项目名_模块名_001,我们可以通过编号快速知道一个项目有多少用例,项目中一个模块有多少用例。
  2、用例标题
  目的:概述测试用例的主要内容,明确用例意图
  在做用例评审时,通过浏览一个模块的用例标题,能快速判断有没有遗漏功能;通过浏览一个功能用例标题,能快速判断出有没有遗漏正常或异常case。
  一个测试用例的好坏,一半体现在测试用例标题上。
  一个好用例的标题,书写方式有三种:
  一:一句完整的话(不超过30个汉字)
  二:功能简报形式
  例:电影详情页-返回
  例:栏目-发布
  例:电影-添加
  三:按条件/状态
  例:发起转码-无源媒体文件
  例:发起转码-有源媒体文件
  例:鉴权-已订购产品已过期
  例:鉴权-已订购产品未过期
  例:鉴权-未订购产品
  3、预置条件
  预置条件-测试用例能执行的前提条件。可以是到达某一状态,也可以是一些配置。
  书写要求:一个简洁的结果。
  用户已成功登陆
  自动审核的开关已关
  不需要写是怎么登陆的/如何将开关关掉的。
       4、测试步骤
  测试步骤是指如何执行用例,先做什么后做什么,是有顺序的概念在的。
  步骤和用例的目标需要是一致的,任意一个偏离目标整个case就是无意义的。
  书写要求:可执行的操作,功能用例步骤不大于7,流程用例步骤随业务而定-这里不做限制。
  (1) 采集电影[check1]
  (2) 预处理电影[check2]
  (3) 审核电影[check3]
  (4) 发布电影[check4]
  5、预期结果
  预期结果是和测试步骤一一对应的,有几个检查点,就需要有几个结果。
  预期结果需要是可检查的,可从三个方面进行校验:
  一:界面(结果会直接显示在界面上的)
  二:数据库(有些数据只会存于数据库中)
  三:磁盘(文件数据需具体到磁盘上看是否存在,数据是否正确)
  书写要求:和测试步骤中check点一一对应,检查点>=1个
  6、测试数据
  测试数据:测试时使用到的数据。
  书写要求:可用电影。
  不用写到实际数据,在测试添加电影功能时,不需要写具体电影、导演、演员、宣传图片。
  具体的数据-可以在数据准备时做好,如符合规格的图片(海报、图标、剧照),符合码率的媒体文件(正片和预览片)。



最后,测试用例整体是有逻辑的-需要有用例设计的魂


       编写测试用例的两个途径
  1)先有用例设计,从整个产品/项目出发,先确定测试范围、测试目标,再细化范围到具体对象->具体功能,确定设计用例技术和测试方法,再来编写用例。
  2) 测试执行后-通过Bug反推 修改补充用例。
  两者相结合才会产出一份漂亮且有效的测试用例,理论->实践->理论过程。
  附上编写测试用例常见问题
  1、用例标题意图不明确
  2、用例中引用其他用例
  3、用例中包含过多的细节
  4、用例中出现笼统的词
  反复、多次
  确定反复的具体次数
  确定一个反复的范围
  长时间
  确定长时间的具体时间
  确定一个长时间的范围
  大量
  确定具体的数据量
  从需求/规格中中参照值
  5、用例中步骤不可执行
  6、用例中期望结果不可验证

测试用例是测试设计的一个产出物,它直接体现测试设计的思想,一份漂亮的测试用例不仅仅是设计思路的优秀体现,更是便于流转和执行,具有可读性、传递性。


首先,一份漂亮的测试用例-需有一个用例模板


  模板的作用:将测试用例的结构形式固定化、标准化,对编写者启引导作用,保证一份测试用例数据完整。


       两份模板差别在于 机顶盒1和机顶盒2,因在IPTV行业,是通过机顶盒展示给用户的,而当前机顶盒厂商多,需要进行兼容性测试,将需要测试的机顶盒直接标记在用例中,执行哪款盒子,就直接在哪款盒子上写结果即可。

 同一个功能在多个机顶盒上是否OK 一目了然,哪款盒子测试用例通过率/失败率也非常清晰,如你测试的是网站可将机顶盒改成 IE11 Chrome 等。


其次,测试用例具有目标、可读、简洁。

 

       测试用例的目标、可读、简洁是从各个属性所填的内容散发出来的。
  1、用例编号
  用例编号就是测试用例文档中一个代号,需全局唯一,我们可以通过代号快速找到测试用例。
  用例编号的书写,建议是项目名_模块名_001,我们可以通过编号快速知道一个项目有多少用例,项目中一个模块有多少用例。
  2、用例标题
  目的:概述测试用例的主要内容,明确用例意图
  在做用例评审时,通过浏览一个模块的用例标题,能快速判断有没有遗漏功能;通过浏览一个功能用例标题,能快速判断出有没有遗漏正常或异常case。
  一个测试用例的好坏,一半体现在测试用例标题上。
  一个好用例的标题,书写方式有三种:
  一:一句完整的话(不超过30个汉字)
  二:功能简报形式
  例:电影详情页-返回
  例:栏目-发布
  例:电影-添加
  三:按条件/状态
  例:发起转码-无源媒体文件
  例:发起转码-有源媒体文件
  例:鉴权-已订购产品已过期
  例:鉴权-已订购产品未过期
  例:鉴权-未订购产品
  3、预置条件
  预置条件-测试用例能执行的前提条件。可以是到达某一状态,也可以是一些配置。
  书写要求:一个简洁的结果。
  用户已成功登陆
  自动审核的开关已关
  不需要写是怎么登陆的/如何将开关关掉的。
       4、测试步骤
  测试步骤是指如何执行用例,先做什么后做什么,是有顺序的概念在的。
  步骤和用例的目标需要是一致的,任意一个偏离目标整个case就是无意义的。
  书写要求:可执行的操作,功能用例步骤不大于7,流程用例步骤随业务而定-这里不做限制。
  (1) 采集电影[check1]
  (2) 预处理电影[check2]
  (3) 审核电影[check3]
  (4) 发布电影[check4]
  5、预期结果
  预期结果是和测试步骤一一对应的,有几个检查点,就需要有几个结果。
  预期结果需要是可检查的,可从三个方面进行校验:
  一:界面(结果会直接显示在界面上的)
  二:数据库(有些数据只会存于数据库中)
  三:磁盘(文件数据需具体到磁盘上看是否存在,数据是否正确)
  书写要求:和测试步骤中check点一一对应,检查点>=1个
  6、测试数据
  测试数据:测试时使用到的数据。
  书写要求:可用电影。
  不用写到实际数据,在测试添加电影功能时,不需要写具体电影、导演、演员、宣传图片。
  具体的数据-可以在数据准备时做好,如符合规格的图片(海报、图标、剧照),符合码率的媒体文件(正片和预览片)。



最后,测试用例整体是有逻辑的-需要有用例设计的魂


       编写测试用例的两个途径
  1)先有用例设计,从整个产品/项目出发,先确定测试范围、测试目标,再细化范围到具体对象->具体功能,确定设计用例技术和测试方法,再来编写用例。
  2) 测试执行后-通过Bug反推 修改补充用例。
  两者相结合才会产出一份漂亮且有效的测试用例,理论->实践->理论过程。
  附上编写测试用例常见问题
  1、用例标题意图不明确
  2、用例中引用其他用例
  3、用例中包含过多的细节
  4、用例中出现笼统的词
  反复、多次
  确定反复的具体次数
  确定一个反复的范围
  长时间
  确定长时间的具体时间
  确定一个长时间的范围
  大量
  确定具体的数据量
  从需求/规格中中参照值
  5、用例中步骤不可执行
  6、用例中期望结果不可验证


TAG:

 

评分:0

我来说两句

Open Toolbar