测试用例之度——系列之颗粒度(上)-阿里云开发者社区

开发者社区> 开发与运维> 正文

测试用例之度——系列之颗粒度(上)

简介:

测试用例是测试工作的核心。测试工作是讲究投入产出比的工作,这也是测试用例设计的指导思想。

  测试用例有度的概念,正如亚里士多德在《伦理学》中讨论道德为例:道德意味着过与不及之间的状态。面向测试用例,网上流传着这么一句话:“不同的机构会有不同的测试目的;相同的机构也可能有不同测试目的,可能是测试不同区域或是对同一区域的不同层次的测试”

  下面就列举测试用例设计的方方面面,看不同的团队,不同的测试目的,如何把握测试用例设计之度。

  颗粒度:

  颗粒度的粗细,有无标准?什么是粗?什么是细?

  1、以功能点划分?

  仅仅覆盖所有的功能性需求为粗?

  仅仅正向覆盖所有的功能需求(功能、性能)为粗?

  正向/负向覆盖所有的功能需求(功能、性能)以及正向覆盖性能需求为粗?

  正向/负向覆盖所有的需求为细?覆盖到产品包,涵盖兼容性、升级、安装、易用性为细?

  2、以STEP划分?

  每条用例有一个STEP为粗,三?五?十为细?以上为细?

  以测试设计思路的体现?

  只采用正向为粗?只采用正/负向为粗?考虑应用场景为细?考虑业务逻辑为细?

  3、以数量级?

  百条?千条?万条?

  4、以数据覆盖?

  等价类是粗?穷举是细?

  每个人、每个机构判定测试用例粗细的标准都不一样,没有标准的答案。所以测试用例颗粒度的粗细,本身就是一个相对而言的标准。

  尝试用图示来表示颗粒度粗细的常规概念:




 测试用例颗粒度粗、细的特点是什么?

  用例设计分析:

  粗颗粒度面向宏观,面向正向的功能点、大的功能模块和整体性,体现测试用例的设计思路;细颗粒度面向微观,面对具体的一个个功能点的正向/负向逻辑,体现测试用例的细节和完备性。

  面对测试执行人员:

  粗颗粒度用例不容易被测试新手执行,因为很多约定成俗的操作、现象,甚至行业术语都不清楚。细颗粒度用例相对较易被测试新手执行。

  覆盖度:

  粗颗粒度覆盖度可能小于细颗粒度用例(粗颗粒度只覆盖全部正向和部分负向,细颗粒度覆盖全部正向、负向、其他等);但还有一种可能性,就是粗细用例均覆盖全面,但是深度不同。类似下雨的降雨量不同,对农作物(产品)的意义不同。

  可维护性:

  毫无疑问,测试用例和需求的匹配,测试用例本身的维护是大多数团队的工作难点重点,粗颗粒度便于维护,方便和需求保持高度一致;细颗粒度用例,越细越不容易维护,维护成本过大,特别是需求频繁变更会导致不可维护。

  类似的概念,比如自动化测试环节,GUI不停改变导致的脚本重写类似。

  时间:

  粗颗粒度构架和评审的时间较短,适合周期较紧的项目;细颗粒度构建和编写的时间较长,适合周期宽松或更倾向于质量的项目。

  资源:

  粗颗粒度占用资源较少(人力、评审、会议室等),适合小团队或同一团队多项目模式;细颗粒度占用资源较多,适合大团队或单一项目模式。

  风险:

  毫无疑问,粗颗粒度用例的风险是漏测,存在很大概率漏测的风险,依赖于测试人员的个人素质;细颗粒度也存在漏测,不过相对更可能是测试人员自己的想当然跳过用例不执行。

  细颗粒度用例最大的风险就是可维护性,或者投入产出比。


本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章