测试用例之度——系列之颗粒度
测试用例是测试工作的核心。测试工作是讲究投入产出比的工作,这也是测试用例设计的指导思想。
测试用例有度的概念,正如亚里士多德在《伦理学》中讨论道德为例:道德意味着过与不及之间的状态。面向测试用例,网上流传着这么一句话:“不同的机构会有不同的测试目的;相同的机构也可能有不同测试目的,可能是测试不同区域或是对同一区域的不同层次的测试”
下面就列举测试用例设计的方方面面,看不同的团队,不同的测试目的,如何把握测试用例设计之度。
颗粒度:
颗粒度的粗细,有无标准?什么是粗?什么是细?
一、以功能点划分?
仅仅覆盖所有的功能性需求为粗?
仅仅正向覆盖所有的功能需求(功能、性能)为粗?
正向/负向覆盖所有的功能需求(功能、性能)以及正向覆盖性能需求为粗?
正向/负向覆盖所有的需求为细?覆盖到产品包,涵盖兼容性、升级、安装、易用性为细?
2、以STEP划分?
每条用例有一个STEP为粗,三?五?十为细?以上为细?
以测试设计思路的体现?
只采用正向为粗?只采用正/负向为粗?考虑应用场景为细?考虑业务逻辑为细?
3、以数量级?
百条?千条?万条?
4、以数据覆盖?
等价类是粗?穷举是细?
每个人、每个机构判定测试用例粗细的标准都不一样,没有标准的答案。所以测试用例颗粒度的粗细,本身就是一个相对而言的标准。
尝试用图示来表示颗粒度粗细的常规概念:
![0001.PNG 0001.PNG](https://i-blog.csdnimg.cn/blog_migrate/20f0c6d533601998cc7aa455a2a425b5.png)
测试用例颗粒度粗、细的特点是什么?
用例设计分析:
粗颗粒度面向宏观,面向正向的功能点、大的功能模块和整体性,体现测试用例的设计思路;细颗粒度面向微观,面对具体的一个个功能点的正向/负向逻辑,体现测试用例的细节和完备性。
面对测试执行人员:
粗颗粒度用例不容易被测试新手执行,因为很多约定成俗的操作、现象,甚至行业术语都不清楚。细颗粒度用例相对较易被测试新手执行。
覆盖度:
粗颗粒度覆盖度可能小于细颗粒度用例(粗颗粒度只覆盖全部正向和部分负向,细颗粒度覆盖全部正向、负向、其他等);但还有一种可能性,就是粗细用例均覆盖全面,但是深度不同。类似下雨的降雨量不同,对农作物(产品)的意义不同。
可维护性:
毫无疑问,测试用例和需求的匹配,测试用例本身的维护是大多数团队的工作难点重点,粗颗粒度便于维护,方便和需求保持高度一致;细颗粒度用例,越细越不容易维护,维护成本过大,特别是需求频繁变更会导致不可维护。
类似的概念,比如自动化测试环节,GUI不停改变导致的脚本重写类似。
时间:
粗颗粒度构架和评审的时间较短,适合周期较紧的项目;细颗粒度构建和编写的时间较长,适合周期宽松或更倾向于质量的项目。
资源:
粗颗粒度占用资源较少(人力、评审、会议室等),适合小团队或同一团队多项目模式;细颗粒度占用资源较多,适合大团队或单一项目模式。
风险:
毫无疑问,粗颗粒度用例的风险是漏测,存在很大概率漏测的风险,依赖于测试人员的个人素质;细颗粒度也存在漏测,不过相对更可能是测试人员自己的想当然跳过用例不执行。
细颗粒度用例最大的风险就是可维护性,或者投入产出比。
![粗细.PNG 粗细.PNG](https://i-blog.csdnimg.cn/blog_migrate/fd142dc8cccdccaa093f04cdb8c93239.png)
测试用例颗粒度常规应用场景的枚举:
上面分析了很多测试用例颗粒度粗、细的特点,那么,常规的测试来讲,如何大致定位测试用例颗粒度的粗细呢?
下面以 单一的应用环境来体现。
还是要强调那句话:相同的机构也可能有不同测试目的,可能是测试不同区域或是对同一区域的不同层次的测试。
单一条件:
1、时间因素:
时间短、项目紧、编写用例评审时间较短时,适合粗颗粒度用例。
项目周期较长时,适合细颗粒度用例。
比如规划六个月的项目,计划阶段和设计阶段有一个半月,测试前期进入,有足够的时间来进行人员培训、测试用例编写,需要细颗粒度。如果项目是一个月,测试准备时间只有五个工作日,那么可能在第三天就要完成第一轮的测试用例评审,建议以粗颗粒度为主,覆盖功能和体现思路。
2、项目人员:
测试人员中熟手多,思路和基础技能扎实,或测试人员构成责任心高时,可以采用粗颗粒度用例。
测试人员新手多,需要再指导下进行基础测试工作,或责任心一般时,需采用细颗粒度用例。
测试人员熟手和新手的区别,大家一目了然。在这里,特意把责任心作为测试用例编写粗细的一个判别标准。实际上,测试人员的职业素质中,就有责任心一项,这种品质方面的要求因人而异——而且每个人都肯定对自己的责任心还自我感觉良好。
举个例子,比如安装测试:
粗的写法:在微软的各种操作系统下进行遍历安装,确认setup安装成功。——那么责任心好的人,可能会去翻阅规格书,确认setup支持的操作系统,再依次安装测试。责任心一般的人,可能就想当然的认为visia这种过渡版本很少人用/server 2000 不是个人用户的菜,就直接跳过这两种系统。
所以面对责任心一般的人,就必须写成细的用例:安装测试:A、在window XP 的 SP2 环境下安装;B、在xp的SP3 环境下安装;C、在win server 2000 下安装;……。
3、项目质量性质
项目质量要求一般,或项目为过渡项目,生命周期短;项目为临时项目时,可采用粗颗粒度用例。
项目质量要求高,客户或公司对质量的定位为第一位,品牌工程项目,采用细颗粒度用例。
难道不是所有的项目都是高质量高要求的么?当然不是。
不同国家和民族的人对质量的要求是不一样的:美国是够用就好,德国是精益求精,中国是当场不挂就行。
不同产业链位置的公司对质量要求是不一样的:顶级公司做完美的产品,中级公司做性价比高的产品,底层公司做廉价的产品。
不同定位的公司对质量的要求是不一样的:在火车站门口的饭店吃的是客流量,在市区偏远地方的饭店吃的是回头客。
不同目的的单子对质量的要求是不一样的:做账拉回扣的虚项目,中标后无人使用,三年后设备升级,质量就没有要求。做重点项目,质量要求苛刻等。
所以,肯定会有不同的项目质量性质。也自然有不同的测试策略和测试目的,顺序导出的就是不同颗粒度的测试用例。
4、资源配置:
资源配置较少,无法实现测试用例的细化时,可以采用粗颗粒度的测试用例。
资源配置较多,可满足用例编写、评审、修订的交叉进行时,可采用细颗粒度。
举例:如果测试人员配置较少,一共就三五个人,每人负责一个项目,彼此没有时间去做评审,甚至项目都存在临时增多的现象,就无从谈起测试用例的细化,甚至粗颗粒度都较难实现,只能拉一个测试大纲出来。
或者测试团队有十多个人,但是项目是流水式过来的。需求、开发、测试是流水线模式处理大批量的项目,无法做到一个项目的全流程参与时,也很难展开测试用例评审、修订以致细化事宜。
5、需求变更:
需求变更较多时,建议采用粗颗粒度的用例,可较灵活的覆盖需求。经过一轮轮的评审,等需求基线化之后,在实际的滚动测试中,在逐步细化用例——根据项目实际情况。
需求变更较少时,或需求变更波及较小,不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估,可对应较大的细化测试用例变更量。
举例:一个需求,粗颗粒度的用例为100条,细颗粒度的用例为10000条。此需求变更,如果要修改粗颗粒度的用例,只需要修改10条;修改细颗粒度的用例,牵扯到细化的交叉逻辑,需要审阅2000条用例并可能修改1200条。
如果测试用例修改人非测试用例编写人,则修改时间还可能延长1.3倍。
6、项目对象:
如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员,可以采用粗颗粒度的用例。
如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者,要采用细颗粒度的用例。
面向专业人员的项目/产品,测试倾向于正向测试,一些问题或使用方式在规定、需求之外,可以在培训或规范中指定操作模式,或凭借技术人员的功底来避免问题。
面向非专业人员的项目/产品,无法做到培训和操作约定,各种稀奇古怪的使用方法,操作习惯,所以更倾向于细颗粒度,覆盖负向和随机操作的测试用例。
7、测试团队素质:
团队个体素质较高,可适应粗犷、敏捷的风格时,可以采用粗颗粒度的用例。
团队处于成立初期或磨合期,需要细化的规则约定来指导时,采用细颗粒度的用例。
8、公司决策投入:
公司对测试工作的投入,对产品质量的要求,对行业节奏的把握。具体分析,可参考项目质量性质部分的论述。
测试用例粗细的另外一个概念:用例的文字描述粗细。
(旧文贴成)
文档分为好多种,在后面写测试用例的时候你们会遇到类似的颗粒度的问题。
第一类是写给自己,以及懂这个技术的,差不多水平的同事看的。这样只需要大致的描述核心关键点就可以。
第二类是给技术一般的员工,但是有一定底子的人看的,这样基本的概念就不用描述,整体步骤描述清楚就可以。
第三类是给不懂技术,只会看图一步步操作的外行看的,这样就要详细细致的描述基本概念,步步都截图,傻瓜式的对比参照的搞过去。
举个例子,使用ping 命令
第一类写法:如果网络不通,使用ping命令测试一下网络是否通畅。
第二类写法:如果网络不通,在cmd模式下,使用ping X.X.X.X 的命令格式,测试一下网络是否通畅。
第三类写法:如果网络不通,点击开始,选择运行,然后在运行框里输入cmd,然后在弹出框里面,使用ping X.X.X.X 的命令格式,如果显示Reply from X.x.x.x bytes=32 time=3ms TTL=64,就是通畅,其他显示就是不通畅。
那么?你这份文档是写给谁看的?
————————————————————————
上述都是针对单一的外部环境给出的建议。如果外部环境参数较多,并且互相矛盾,比如团队新手多,但测试项目对质量要求很高,并且项目周期短时,如何构建测试用例的颗粒度,就更需要测试管理人员的平衡。
测试用例的粗细:掌握质量与效率之间的平衡。
上面分析了很多测试用例颗粒度粗、细的特点,那么,常规的测试来讲,如何大致定位测试用例颗粒度的粗细呢?
下面以 单一的应用环境来体现。
还是要强调那句话:相同的机构也可能有不同测试目的,可能是测试不同区域或是对同一区域的不同层次的测试。
单一条件:
1、时间因素:
时间短、项目紧、编写用例评审时间较短时,适合粗颗粒度用例。
项目周期较长时,适合细颗粒度用例。
比如规划六个月的项目,计划阶段和设计阶段有一个半月,测试前期进入,有足够的时间来进行人员培训、测试用例编写,需要细颗粒度。如果项目是一个月,测试准备时间只有五个工作日,那么可能在第三天就要完成第一轮的测试用例评审,建议以粗颗粒度为主,覆盖功能和体现思路。
2、项目人员:
测试人员中熟手多,思路和基础技能扎实,或测试人员构成责任心高时,可以采用粗颗粒度用例。
测试人员新手多,需要再指导下进行基础测试工作,或责任心一般时,需采用细颗粒度用例。
测试人员熟手和新手的区别,大家一目了然。在这里,特意把责任心作为测试用例编写粗细的一个判别标准。实际上,测试人员的职业素质中,就有责任心一项,这种品质方面的要求因人而异——而且每个人都肯定对自己的责任心还自我感觉良好。
举个例子,比如安装测试:
粗的写法:在微软的各种操作系统下进行遍历安装,确认setup安装成功。——那么责任心好的人,可能会去翻阅规格书,确认setup支持的操作系统,再依次安装测试。责任心一般的人,可能就想当然的认为visia这种过渡版本很少人用/server 2000 不是个人用户的菜,就直接跳过这两种系统。
所以面对责任心一般的人,就必须写成细的用例:安装测试:A、在window XP 的 SP2 环境下安装;B、在xp的SP3 环境下安装;C、在win server 2000 下安装;……。
3、项目质量性质
项目质量要求一般,或项目为过渡项目,生命周期短;项目为临时项目时,可采用粗颗粒度用例。
项目质量要求高,客户或公司对质量的定位为第一位,品牌工程项目,采用细颗粒度用例。
难道不是所有的项目都是高质量高要求的么?当然不是。
不同国家和民族的人对质量的要求是不一样的:美国是够用就好,德国是精益求精,中国是当场不挂就行。
不同产业链位置的公司对质量要求是不一样的:顶级公司做完美的产品,中级公司做性价比高的产品,底层公司做廉价的产品。
不同定位的公司对质量的要求是不一样的:在火车站门口的饭店吃的是客流量,在市区偏远地方的饭店吃的是回头客。
不同目的的单子对质量的要求是不一样的:做账拉回扣的虚项目,中标后无人使用,三年后设备升级,质量就没有要求。做重点项目,质量要求苛刻等。
所以,肯定会有不同的项目质量性质。也自然有不同的测试策略和测试目的,顺序导出的就是不同颗粒度的测试用例。
4、资源配置:
资源配置较少,无法实现测试用例的细化时,可以采用粗颗粒度的测试用例。
资源配置较多,可满足用例编写、评审、修订的交叉进行时,可采用细颗粒度。
举例:如果测试人员配置较少,一共就三五个人,每人负责一个项目,彼此没有时间去做评审,甚至项目都存在临时增多的现象,就无从谈起测试用例的细化,甚至粗颗粒度都较难实现,只能拉一个测试大纲出来。
或者测试团队有十多个人,但是项目是流水式过来的。需求、开发、测试是流水线模式处理大批量的项目,无法做到一个项目的全流程参与时,也很难展开测试用例评审、修订以致细化事宜。
5、需求变更:
需求变更较多时,建议采用粗颗粒度的用例,可较灵活的覆盖需求。经过一轮轮的评审,等需求基线化之后,在实际的滚动测试中,在逐步细化用例——根据项目实际情况。
需求变更较少时,或需求变更波及较小,不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估,可对应较大的细化测试用例变更量。
举例:一个需求,粗颗粒度的用例为100条,细颗粒度的用例为10000条。此需求变更,如果要修改粗颗粒度的用例,只需要修改10条;修改细颗粒度的用例,牵扯到细化的交叉逻辑,需要审阅2000条用例并可能修改1200条。
如果测试用例修改人非测试用例编写人,则修改时间还可能延长1.3倍。
6、项目对象:
如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员,可以采用粗颗粒度的用例。
如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者,要采用细颗粒度的用例。
面向专业人员的项目/产品,测试倾向于正向测试,一些问题或使用方式在规定、需求之外,可以在培训或规范中指定操作模式,或凭借技术人员的功底来避免问题。
面向非专业人员的项目/产品,无法做到培训和操作约定,各种稀奇古怪的使用方法,操作习惯,所以更倾向于细颗粒度,覆盖负向和随机操作的测试用例。
7、测试团队素质:
团队个体素质较高,可适应粗犷、敏捷的风格时,可以采用粗颗粒度的用例。
团队处于成立初期或磨合期,需要细化的规则约定来指导时,采用细颗粒度的用例。
8、公司决策投入:
公司对测试工作的投入,对产品质量的要求,对行业节奏的把握。具体分析,可参考项目质量性质部分的论述。
测试用例粗细的另外一个概念:用例的文字描述粗细。
(旧文贴成)
文档分为好多种,在后面写测试用例的时候你们会遇到类似的颗粒度的问题。
第一类是写给自己,以及懂这个技术的,差不多水平的同事看的。这样只需要大致的描述核心关键点就可以。
第二类是给技术一般的员工,但是有一定底子的人看的,这样基本的概念就不用描述,整体步骤描述清楚就可以。
第三类是给不懂技术,只会看图一步步操作的外行看的,这样就要详细细致的描述基本概念,步步都截图,傻瓜式的对比参照的搞过去。
举个例子,使用ping 命令
第一类写法:如果网络不通,使用ping命令测试一下网络是否通畅。
第二类写法:如果网络不通,在cmd模式下,使用ping X.X.X.X 的命令格式,测试一下网络是否通畅。
第三类写法:如果网络不通,点击开始,选择运行,然后在运行框里输入cmd,然后在弹出框里面,使用ping X.X.X.X 的命令格式,如果显示Reply from X.x.x.x bytes=32 time=3ms TTL=64,就是通畅,其他显示就是不通畅。
那么?你这份文档是写给谁看的?
————————————————————————
上述都是针对单一的外部环境给出的建议。如果外部环境参数较多,并且互相矛盾,比如团队新手多,但测试项目对质量要求很高,并且项目周期短时,如何构建测试用例的颗粒度,就更需要测试管理人员的平衡。
测试用例的粗细:掌握质量与效率之间的平衡。
本文出自 “柳记” 博客,请务必保留此出处http://eilfei2000.blog.51cto.com/2956473/729259