51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1898|回复: 1
打印 上一主题 下一主题

测试用例颗粒度

[复制链接]
  • TA的每日心情
    无聊
    4 天前
  • 签到天数: 530 天

    连续签到: 2 天

    [LV.9]测试副司令

    跳转到指定楼层
    1#
    发表于 2018-12-28 15:14:29 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    本帖最后由 测试积点老人 于 2018-12-28 15:15 编辑

    前言

      在测试过程中,我们会经常遇到,实现一个功能有多个操作路径/步骤,比如:在一个库存管理系统中,需要修改一种类型箱子标签的打印格式,而打印这个箱子标签(唛头),涉及很多操作路径,比如有:

    • 【海外制单-海外制单界面】;
    • 【海外制单-自动打印海外发货唛头(标签)】;
    • 【海外制单-批量打印海外发货唛头】;
    • 【海外制单-打印海外箱单(按箱)】。

      这4个路径都可以打印同一个模板,也就是预期结果一样,但是四个路径操作方式不一样,那么这个时候是设计1条用例,还是4条用例呢?

      还有一种情况是一个操作产生多个不同的结果,比如:点击登陆按钮后,显示成功登陆系统的弹窗提示,同时写入1条登陆日志到数据库表AAA中,同时向系统发送1条接口日志,表示登陆成功。这个是时候,你是设计3个用例,还是1个用例呢?如果设计3个用例那么就是操作步骤跟预期结果一一对应的关系,如果设计1个用例就是1个操作步骤,多个结果(检查点)的关系。有时候我们就有些迷茫了,到底是设计少一些用例,还是设计多一些用例呢?

      在我测试的时候,就经常遇到这种情况,我通常的处理是,如果这个需求场景特别多,需要设计很多用例,时间又少,那么我尽量精简测试用例,如果某个需求场景少,那么有多个路径的情况,我会设计成多个用例,这样不至于让人看起来用例数量太少,担心需求用例覆盖不全的感觉。其实在测试理论实践上这就是测试用例颗粒度的把握问题。

      下面给大家讲解一下测试用例颗粒度的知识。


    颗粒度与测试的关系

      如果把测试用例设计得很细,照顾到每一个数据输入、每一个条件、每一个环境、每一个路径,那么测试用例的数量将是巨大的,虽然风险很小很小,但是测试效率会很低,并且测试执行没有思考的空间,可能使测试执行人员变得呆板(除非全部测试自动化),不需要创造力、思考。测试用例设计很粗,测试效率可能比较高,测试人员有一个发挥的空间,使测试更有趣,但这依赖于个人的责任感和能力,风险大得多。
      颗粒度的大小取决与以下几点:

    • “重要功能”、“特殊功能”颗粒密集度高,“通用功能”可以试用通用测试粒度,密集度应该可以大致界定。个人认为,假如你非要为了一个字体的样式而写了一大长串的测试用例 ,那么这个颗粒度就毫无意义了。

    • 颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度,或者说颗粒度的定义,不要说一个程序,就算是一个简单的登录都可以写出几乎无穷尽的测试用例,所以你需要指明功能、性能需求,使用环境等,并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度,也才好写测试用例,总之,客户的要求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。

    • 一般功能颗粒密集度可能会根 据项目或是时间来确定。如果时间充裕颗粒度可以适当小。

    • 粒度取决于测试的种类,一般用验收测试,是项目测试中颗粒度比较大。系统测试颗粒度相对较小。


    有效度量测试用例条件
    • 颗粒度可以跟代码行数对应:一般来说代码量越大,内部逻辑就越复杂,出现bug的的可能性也越高。对应的测试粒度也越小。

    • 测试团队内部对粒度达成一致,适当把握颗粒度:明确测试用例编写的颗粒度,大家都有这种感觉,你写测试用例,你测试这个产品的时候,你十条测试用例就测试完了,有人写三十条,你就觉得奇怪,我觉得十条已经是局限了,怎么你能写到三十条,你去看他的用例,发现这也能算一条,这是组织内部测试用例颗粒度没有达成一致。

    • 颗粒度要适合业务的需要:各公司测试用例设计的粒度不同,适合自己的需要,适合业务的需要即可,测试用例的数量统计方法,我觉得说明不了测试作得是否专业。

    • 测试用例设计的覆盖率和有效性,才是说明测试是否专业的依据之一:对于进行工作量的统计还可以,不过用例还是不能简单的以数量来看,设计一个很简单的功能点的用例可能很容易,可能一天能设计十个这样的用例,但是对于一个相对复杂的功能,可能一天才能准备两个用例,光靠数量是说明不了问题的。


    测试用例之度——系列之颗粒度

      测试用例是测试工作的核心。测试工作是讲究投入产出比的工作,这也是测试用例设计的指导思想。
      测试用例有度的概念,正如亚里士多德在《伦理学》中讨论道德为例:道德意味着过与不及之间的状态。面向测试用例,网上流传着这么一句话:“不同的机构会有不同的测试目的;相同的机构也可能有不同测试目的,可能是测试不同区域或是对同一区域的不同层次的测试”。
      下面就列举测试用例设计的方方面面,看不同的团队,不同的测试目的,如何把握测试用例设计之度。


    颗粒度:

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

    1. 以功能点划分?
      仅仅覆盖所有的功能性需求为粗?
      仅仅正向覆盖所有的功能需求(功能、性能)为粗?
      正向/负向覆盖所有的功能需求(功能、性能)以及正向覆盖性能需求为粗?
      正向/负向覆盖所有的需求为细?覆盖到产品包,涵盖兼容性、升级、安装、易用性为细?

    2. 以STEP划分?
      每条用例有一个STEP为粗,三?五?十为细?以上为细?
      以测试设计思路的体现?
      只采用正向为粗?只采用正/负向为粗?考虑应用场景为细?考虑业务逻辑为细?

    3. 以数量级?
      百条?千条?万条?

    4. 以数据覆盖?
      等价类是粗?穷举是细?
      每个人、每个机构判定测试用例粗细的标准都不一样,没有标准的答案。所以测试用例颗粒度的粗细,本身就是一个相对而言的标准。
      尝试用图示来表示颗粒度粗细的常规概念:


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


    用例设计分析:

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


    面对测试执行人员:

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


    覆盖度:

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


    可维护性:

      毫无疑问,测试用例和需求的匹配,测试用例本身的维护是大多数团队的工作难点重点,粗颗粒度便于维护,方便和需求保持高度一致;细颗粒度用例,越细越不容易维护,维护成本过大,特别是需求频繁变更会导致不可维护。
      类似的概念,比如自动化测试环节,GUI不停改变导致的脚本重写类似。


    时间:

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


    资源:

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


    风险:

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


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

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏2
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-25 09:27 , Processed in 0.068074 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表