快捷搜索:

软件测试过程质量的度量

软件测试阶段的过程度量内容或项目对照多,包括软件测试进度、测试覆盖度、测试缺陷呈现/到达曲线、测试缺陷累积曲线、测试效率等。在进行测试过程度量时,要基于软件规模度量(如功能点、工具点等)、繁杂性度量、项目度量等措施,从三个不合的测度来完备度量测试的历程状态:

1. 测试广度的丈量供给了若干需求(在所有需求的数目中)在某一时候已经被测试,来度量测试计划的履行、测试进度等状态;

2. 测试深度是对被测试覆盖的自力基础路径占在法度榜样中的基础路径的总数的百分比的测度,基础路径数目的度量可以用McCabe环形谋略繁杂度措施来谋略。

3. 历程中网络的缺陷数度量,发明的、修正的和关闭的缺陷数量在历程中的差异、成长趋势等,为历程质量、开拓资本额外投入、软件宣布猜测供给紧张依据。

如前所述,测试历程的度量可以将历程状立场量和历程结果度量结合起来阐发,是测试过程度量更有效。

在测试阶段,主要的历程质量度量有:

* 缺陷度量或缺陷散播度量

* 测试用例的深度、质量和有效性

* 测试履行的效率和质量

* 缺陷申报的质量

* 测试覆盖度(测试整体的质量)

* 测试情况的稳定性或有效性

缺陷度量是测试阶段的主要度量内容,包括产品缺陷度量和缺陷过程度量。产品缺陷度量将鄙人一回做具体先容,而测试情况的稳定性或有效性度量,就像软件有效性一样,用MTTF来丈量。以是下面将简单先容其他度量内容,如 软件缺陷到达模式、PTR呈现/积压模型、测试用例的度量、基于需求的测试覆盖评估、基于代码的测试覆盖评估等等。

1. 基于光阴的缺陷到达模式

产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标,缺陷到达模式可以供给更多的历程信息,无意偶尔纵然获得的整体缺陷率是一样的,但其质量差异可能较大年夜,缘故原由便是缺陷到达的模式不一样。越多的缺陷到达越早,则测试历程质量就越好。无论是从测试进展的不雅点,照样从用户从新发明(customer rediscoveries)的不雅点来看,缺陷的历程跟踪是异常紧张的,开拓周期里大年夜量的严重缺陷将有可能阻拦测试的进展,也一定直接影响软件产品的质量和机能。

相对产品宣布光阴、上一个版本的缺陷水平来说,常常会被项目经理或开拓经历问的便是:

* 缺陷何时到达峰值?这个峰值无意偶尔若干?

* 在到达峰值后又要化若干光阴趋于(低落)到一个低而稳定的水平?

* 低而稳定的水平持续若干光阴,当前版本可以宣布?

回答这些问题,恰是缺陷达到模式要实现的目标。定性的阐发对照轻易,测试团队越成熟,峰值到达得越早,无意偶尔可以在第一周末或第二周就达到峰值。这个峰值的数值取决于代码质量、测试用例的设计质量和测试履行的策略、水平等,多半环境下,可以根据基线(或历史数据)推得。从一个峰值达到一个低而稳定的水平,必要长得多的光阴,至少是达到峰值所用的光阴的4-5倍。这个光阴取决于峰值、缺陷移除效率等等。

2. PTR累积模型

测试的目标在于尽早地发明软件缺陷,经由过程测试用例可以更有效、更快地发明软件中缺陷,而软件缺陷经由过程PTR(问题跟踪申报,Problem Tracking Report)来描述。是以,PTR的数量必然程度上代表了软件的质量。每个缺陷/PTR都有一个生命周期,从测试职员发明问题并形成申报(称为PTR呈现,也称缺陷到达),开拓/设计职员要重现、修正这个PTR/缺陷,并构建、提交包孕已修正PTR/缺陷的新软件包(New Build)给测试组,所修正的问题获得验证直到该问题经由过程测试为止(称为PTR关闭),测试历程中特准光阴PTR维持的数量(所有新发明的PTR和关闭的PTR的差值)——PTR累积/积压值。PTR呈现/累积模型便是根据问题跟踪申报的两种数据——某个光阴单位内的PTR呈现值和某个光阴PTR累积值来度量测试中所发明的缺陷变更历程,即软件产品德量状态的变更历程。

3.测试用例的深度、质量和有效性

测试用例是测试履行的根基,其质量的短长直接关系到测试的质量,也就影响着软件质量的包管历程。测试用例的度量将包孕测试用例的深度、质量和有效性,而且包孕自动化程度的度量,即若干比例的测试用例已被自动化了。

测试用例的深度(TCD, Test Case Depth)度量可以表示为每KLOC的测试用例数或每个功能点/工具点的测试用例数,而测试用例的效率可以用每100或1000个测试用例所发明的缺陷数来衡量,不合的测试阶段是不一样,应该对同一阶段的不合版本进行对照,而不宜对同一版本的不合阶段进行对照。而测试用例的质量(TCQ, Test Case Quality)可以用由测试用例发明的缺陷数量来度量,即TCQ = 测试用例发明的缺陷数量/总的缺陷数量由于还有一部分缺陷可以经由过程ad-hoc 测试(随机、自由的测试)、集体走查(Work-through)和Fire-drill测试(类似消防练习的用户压力/验收测试)等其他手段发明缺陷。

4.测试履行的效率和质量

测试履行的质量一样平常可以用软件宣布后所遗留的软件缺陷和总缺陷数的比值来衡量,一样平常要求低于0.5%,也可以经由过程种子公式或交叉测试等措施衡量。测试履行的效率可以用下列几种措施来综合度量:

* 每小我日所履行的测试用例数

* 每小我日所发明的缺陷数

* 每改动的KLOC所运行的测试用例数

5.缺陷申报的质量

正/关闭的(等级高的)缺陷和测试职员所报的所有(等级高的)缺陷的比值,这个值越靠近1,有效性就越高,假如考察等级高的缺陷,其正常值大年夜约在0.92 – 0.96

* 缺陷申报质量,可以用一些中心状态为“必要弥补信息”、“不是缺陷”的缺陷数量来衡量,一样平常占总缺陷数的3%-5%为正常,高于或低于这个值都可能不正常,高于5%,可能阐明缺陷申报质量低;低于3%,可能阐明测试职员缺少狐疑精神。

6.基于需求的测试覆盖评估

基于需求的测试覆盖评估是依附于对已履行/运行的测试用例的核实和阐发,以是基于需求的测试覆盖评测就转化为评估测试用例覆盖率:测试的目标是确保100% 的测试用例整个成功地履行。一样平常在测试计划中,就定义了测试的事情量、测试用例数量和测试用例覆盖率(98%-100%),我们根据事先确定的测试日程安排,可以将测试计划值做成曲线,然后根据实际履行结果,按期(天天或每周)去画实际值曲线,从而可以进行测试全历程监控和猜测。

在履行测试活动中,评估测试用例覆盖率又可分为两类测试用例覆盖率估算:

* 确定已经履行的测试用例覆盖率,即在所有测试用例中有若干测试用例已被履行。假定Tx已履行的测试历程数或测试用例数,Rft是测试需求的总数:

* 已履行的测试覆盖 = Tx/Rft

* 确定成功的测试覆盖,即履行时未呈现掉败的测试,如没有呈现缺陷或意外结果的测试,假定Ts是已履行的完全成功、没出缺陷的测试历程数或测试用例数。

* 成功的测试覆盖 = Ts/Rft

7.基于代码的测试覆盖评估

基于代码的测试覆盖评测是对被测试的法度榜样代码语句、路径或前提的覆盖率阐发。假如利用基于代码的覆盖,则测试策略是根据测试已经履行的源代码的若干来表示的。这种测试覆盖策略类型对付安然至上的系统来说异常紧张。

评估代码覆盖率,必要断定测试目标期望的、总的测试代码行数,在测试中真正履行的代码行数及其百分比,将此结果记录在测试评估申报中。测试历程中已经履行的代码的若干,与之相对的是要履行的残剩代码的若干。代码覆盖可以建立在节制流(语句、分支或路径)或数据流的根基上。节制流覆盖的目的是测试代码行、分支前提、代码中的路径或软件节制流的其他元素。数据流覆盖的目的是经由过程软件操作测试数据状态是否有效,例如,数据元素在应用之前是否已经定义。

基于代码的测试覆盖经由过程以下公式谋略:

已履行的测试覆盖 = Tc/Tnc

此中Tc是用代码语句、前提分支、代码路径、数据状态鉴定点或数据元素名表示的已履行项目数,Tnc(Total number of items in the code)是代码中的项目总数。

您可能还会对下面的文章感兴趣: