• 0
  • 0
分享
  • 测试用例质量的评估,可以从这3个方面考量——软件测试圈
  • 曼倩诙谐 2022-11-01 11:15:44 字数 1118 阅读 1687 收藏 0

测试行业的那些事儿,还有哪些你不知道?填问卷,了解详情。链接:http://vote.51testing.com/  (马上就要进行第二轮抽奖了,还没有填问卷的要行动起来啦~)


  第一,根据测试用例的形式评估其质量,主要包括:

  1)测试用例与需求规格说明中需求条目的可追溯性,例如:我们要求每个需求条目至少有1个测试用例与之对应。目的是为了评估测试的需求覆盖率,以及分析需求发生变更的时候,对测试修改工作的影响程度。

  2)测试用例有无明确的期望结果。通常来说,测试用例的每个执行步骤,都应该明确描述期望的结果,以保证测试人员可以与测试实际结果进行比较,并分析是否需要提交缺陷报告,或者修改测试用例。

  3)是否满足公司内部定义的测试用例模板。例如:每个公司都可能定义了测试用例模板,比如定义了“测试类型”,要求每个测试用例和测试类型进行关联,并要求每个功能的测试用例需要覆盖所有的测试类型,例如:可移植性、互操作性、稳定性等。

  第二,根据测试用例覆盖率评估其质量,主要包括:

  1)需求的覆盖率,例如:我们主要负责系统测试级别,因此测试用例的需求覆盖率要求必须达到100%。

  2)质量特性的覆盖率,例如:我们在测试用例模板中采用测试类型的概念,要求每个功能的测试用例,必须100%覆盖所有的测试类型。而测试类型的定义,参考了ISO9126质量模型,以前缺陷的分析,需求条目的分析等。

  3)测试平台的覆盖率,例如:针对我们目前的通信产品,每个功能都需要在不同平台上运行,例如:不同的网元类型、接口类型、业务类型等。测试用例的对这些平台的覆盖率,也要求达到100%。

  第三,根据测试用例的有效性评估其质量,主要包括:

  1)测试用例的缺陷发现率,我们采用的计算方法是“系统测试发现的缺陷数目除以执行的测试用例数目,而得到的百分比”。

  2)脚本化测试的缺陷发现率,我们采用的计算方法是“根据测试用例步骤发现的缺陷数目/总发现的缺陷数目,得到的百分比”。假如这个百分比很低,说明设计的测试用例有效性方面比较差,而通过探索性测试发现的缺陷比例更高。

  3)遗漏到用户现场的缺陷率,我们采用的计算方法是“6个月内用户现场反馈的缺陷数目,除以系统测试级别发现的缺陷数目与6个月内用户现场反馈的缺陷数目之后,得到的百分比”。

  每个公司和测试团队在评估测试用例质量方面会存在不同的度量指标,基本的要求是这些度量指标简单容易收集,并且有利于改进测试过程和测试团队的测试能力,但切记不会针对测试人员个人的能力与绩效的评估。



作者:郑文强    

来源:http://www.51testing.com/html/65/n-4479265.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 1、基于webdriver的分层自动化框架及平台搭建,目前刚好在做这一块的工作,对于分层次和平台搭建,想问下大神有什么好的建议?我们拿数据驱动框架来举个例子。下面是我做的一个简单的框架样式:这样一个结构,分为base层(公共用例),element(元素层),properties(UI map层--properties文件),resource(资源层),task(存储suite的testng文件),testcase(case层),util(底层,方法层)。用这样一个结构来更容易理解,更便于维护我们的框架。当然,这是一个基本demo哈,可以根据自己的实际情况扩展。总之,没有最好的,只有最适合的,哈...
            0 1 2302
            分享
          •   前几天在我创建的技术交流群,几位同学聊起了兼容性测试相关的话题。有测试的方法技巧,有如何选择测试时的切入点,也有在质量和投入成本之间如何做平衡的思考。  翻了翻写过的技术文章,大多集中在后端、中间件以及稳定性测试方面,兼容性测试也有做过专项。这篇文章,我想结合自己对兼容性测试的理解,以及做技术专项的一些经验,谈谈我的一些看法。  如何理解兼容性测试  兼容性测试,最初是为了检查软件在不同的硬件、操作系统以及软件平台上是否可以正常运行,即软件的可移植性和正确性检查。操作系统如 Windows 和 Mac,各种浏览器兼容如Chrome、Firefox、IE。  近几年随着移...
            0 0 810
            分享
          •   需求分析是开始测试工作的第一步,产品会先产出一个需求文档,然后会组织需求宣讲,在需求宣讲中分析需求中是否存在问题,然后宣讲结束后,通过需求文档分析测试点并且预估排期。所以对于需求的理解非常重要。  需求文档  产品经理在做完用户需求调查之后,会根据用户需求输出一份需求文档,在文档中会详细描述用户所需的功能和功能实现的效果。文档生成之后,产品经理会和开发测试一起开一个需求宣讲会,讲解需求中的内容,并且会对需求中可能存在的问题进行讨论。  需求评审  在需求宣讲的过程中,其实也需要对需求本身进行评审。需求评审可以从以下角度去进行考虑。  1.站在使用者的角度,考虑用户会遇到的各种情况,反观各种...
            0 0 849
            分享
          •   想想自己从2002年毕业一直在做测试相关的工作,这么说来也算是在国内做测试比较早的老人了。  从最初在日企中做测试到现在在国企中做测试,期间也有在一家私企做过测试经理。测试的内容从最初的执行日本客户写的测试用例到最后作为测试经理指导别人写测试用例。从软件工程中涉及到的阶段来说做过JUNIT、NUNIT单元测试,在开发组中做过集成测试,在测试组做过系统测试,在用户方做过相应的验收测试等。从和开发人员分工协作的敏捷开发的迭代过程中来说,做过冒烟测试,回归测试,兼容性测试等。从测试的内容来说做过功能测试,性能测试。从测试的类型来说做过黑盒测试白盒测试。使用过操作系统有Windows,linux,...
            0 0 3415
            分享
          •   场景法用例设计  现在的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流。  这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时测试用例也更容易的得到理解和执行。  用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。  场景说明  基本流:是流经用例的最重要路径,图中的黑线。  备选流:自基本流开始,之后会在某特定条件下执行。  可能重新加入基本流(备选流1和3)  可能起源于另一备选流(备选流2)  终止用例不再重新加入某个流(备选流...
            0 0 1463
            分享
      • 51testing软件测试圈微信