软件测试中对软件质量进行度量的指标常用的有哪些？

你好！ 有N多种指标：缺陷统计数据的度量（I）所有缺陷数量的时间走势或趋势统计 （Bug Trends By Time）未被处理的缺陷按照严重程度的统计 （Active Bugs By Severity） 未被处理的缺陷按照优先程度的统计 （Active Bugs By Priority）未被处理的缺陷数量的时间走势或趋势统计 （Active Bugs Over Time）已发现缺陷的数量和已修复的缺陷的数量的比率 （Fixed/Found）。

也被称为修改率或纠错率（Fix Rate） 未处理的缺陷数量和已处理的的缺陷数量的比率 （active/resolved）已处理的被修复的缺陷数量和已处理的缺陷数量的比率（Resolved as Fixed/resolved）重新被激活的已修复的缺陷数量（Bug re-activation rate）通过测试找到的缺陷的统计（Bugs opened by testing activity）所有的缺陷按照严重程度的统计（All Bugs By Severity）新被发现的缺陷按严重程度的统计 （Opened Bugs By Severity） 已处理的缺陷按照严重程度的统计 （Resolved Bugs By Severity） 被修复的缺陷按照严重程度的统计 （Fixed By Severity）不同语言版本缺陷数量的统计（Bugs opened by Language version）被报告存在缺陷的各功能统计（Where your bugs were found）处理缺陷的平均时间的统计（Average Time to Resolve）关闭缺陷的平均时间的统计（Average Time to Close）被处理缺陷的不同结论统计（Resolved Bugs By Resolution）详细的信息你可以留下邮箱，我发给你文件！

衡量软件测试质量的指标 测试用例覆盖率概念

1.什么是覆盖率覆盖率是用来度量测试完整性的一个手段，覆盖率是测试技术有效性的一个度量。

2.覆盖率的作用通过覆盖率数据，我们可以知道我们的测试是否充分，我们测试的弱点在哪些方面，进而指导我们设计能够增加覆盖率的测试用例，有效地提高测试质量。

但是不能一味地去追求覆盖率，要考虑进度、成本、范围之间的关系。

3.覆盖率计算的公式覆盖率=（至少被执行一次的item数）/item的总数4.覆盖率的分类覆盖率按照测试方法大体可以分为三类：白盒测试覆盖、灰盒测试覆盖、黑盒测试覆盖。

其他分类方法：面向对象的覆盖率（继承上下文覆盖、基于状态的上下文覆盖、基于线程的上下文覆盖）

数据库性能优化基准测试的度量指标有哪些

1. 测试广度的测量提供了多少需求（在所有需求的数目中）在某一时刻已经被测试，来度量测试计划的执行、测试进度等状态； 2. 测试深度是对被测试覆盖的独立基本路径占在程序中的基本路径的总数的百分比的测度，基本路径数目的度量可以用McCae环形计算复杂度方法来计算。

3. 过程中收集的缺陷数度量，发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等，为过程质量、开发资源额外投入、软件发布预测提供重要依据。

如前所述，测试过程的度量可以将过程状态度量和过程结果度量结合起来分析，是测试过程度量更有效。

在测试阶段，主要的过程质量度量有： * 缺陷度量或缺陷分布度量 * 测试用例的深度、质量和有效性 * 测试执行的效率和质量 * 缺陷报告的质量 * 测试覆盖度（测试整体的质量） * 测试环境的稳定性或有效性 缺陷度量是测试阶段的主要度量内容，包括产品缺陷度量和缺陷过程度量。

产品缺陷度量将在下一回做详细介绍，而测试环境的稳定性或有效性度量，就像软件有效性一样，用MTTF来测量。

所以下面将简单介绍其他度量内容，如 软件缺陷到达模式、考试大PTR出现积压模型、测试用例的度量、基于需求的测试覆盖评估、基于代码的测试覆盖评估等等。

1. 基于时间的缺陷到达模式 产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标，缺陷到达模式可以提供更多的过程信息，有时即使得到的整体缺陷率是一样的，但其质量差异可能较大，原因就是缺陷到达的模式不一样。

越多的缺陷到达越早，则测试过程质量就越好。

无论是从测试进展的观点，还是从用户重新发现（customeediscoveies）的观点来看，缺陷的过程跟踪是非常重要的，开发周期里大量的严重缺陷将有可能阻止测试的进展，也必然直接影响软件产品的质量和性能。

相对产品发布时间、上一个版本的缺陷水平来说，经常会被项目经理或开发经历问的就是： * 缺陷何时到达峰值？这个峰值有时多少？ * 在到达峰值后又要化多少时间趋于（降低）到一个低而稳定的水平？ * 低而稳定的水平持续多少时间，当前版本可以发布？ 回答这些问题，正是缺陷达到模式要实现的目标。

定性的分析比较容易，测试团队越成熟，峰值到达得越早，有时可以在第一周末或第二周就达到峰值。

这个峰值的数值取决于代码质量、测试用例的设计质量和测试执行的策略、水平等，多数情况下，可以根据基线（或历史数据）推得。

从一个峰值达到一个低而稳定的水平，考试大需要长得多的时间，至少是达到峰值所用的时间的4-5倍。

这个时间取决于峰值、缺陷移除效率等等。

2. PTR累积模型 测试的目标在于尽早地发现软件缺陷，通过测试用例可以更有效、更快地发现软件中缺陷，而软件缺陷通过PTR（问题跟踪报告，Polem Tacking Repot）来描述。

因此，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 测试（随机、自由的测试）、集体走查（Wok-though）和Fie-dill测试（类似消防训练的用户压力验收测试）等其他手段发现缺陷。

4.测试执行的效率和质量 测试执行的质量一般可以用软件发布后所遗留的软件缺陷和总缺陷数的比值来衡量，一般要求低于0.5%，考试大也可以通过种子公式或交叉测试等方法衡量。

测试执行的效率可以用下列几种方法来综合度量： * 每个人日所执行的测试用例数 * 每个人日所发现的缺陷数 * 每修改的KLOC所运行的测试用例数 5.缺陷报告的质量 正关闭的（等级高的）缺陷和测试人员所报的所有（等级高的）缺陷的比值，这个值越接近1，有效性就越高，如果考察等级高的缺陷，其正常值大约在0.92 – 0.96 * 缺陷报告质量，可以用一些中间状态为“需要补充信息”、“不是缺陷”的...

软件测试应该遵循哪些国家标准

一般的商业软件（不含嵌入式软件）不涉及军方的话，参照这3个标准，当然1、 GB/T 25000.51 -2010 《软件工程 软件产品质量要求和评价（ SQuaRE） 商业现货（ COTS）软件产品的质量要求和测试细则》 2、 GB/T 16260.1-2006《软件工程 产品质量 第 1 部分：质量模型》3、 GB/T 16260.2-2006《软件工程 产品质量 第 2 部分：外部度量》嵌入式软件参考的GB/T 30961-2014 嵌入式软件质量度量 国家标准至于军标的话就更多了，如果一般的企业不涉及军工的话，前3个就可以了，当然如果是嵌入式的可能会用到嵌入式的标准。

当然以上是针对软件测试应该涉及到的软件质量要求的标准，其他软件开发类的国标我就不在这里列举了。

...

【可靠性测试】可靠性测试有哪些内容？可靠性测试的范围和标准有哪...

一、对软件可靠性测试的认识 1.有关术语 （1）软件可靠性 在规定条件下，在规定时间内，软件不引起系统失效的概率。

该概率是系统输入和系统使用的函数，也是软件中存在故障的函数，系统输入将确定是否会遇到存在的故障。

（2）软件可靠性估计 应用统计技术处理在系统测试和运行期间采集、观察到的失效数据，以评估该软件的可靠性。

（3）软件可靠性测试 在有使用代表性的环境中，为进行软件可靠性估计对该软件进行的功能测试。

需要说明的是，＂使用代表性＂指的是在统计意义下该环境能反映出软件的使用环境特性 。

2.软件可靠性测试的目的 软件可靠性测试的主要目的有： （1）通过在有使用代表性的环境中执行软件，以证实软件需求是否正确实现。

（2）为进行软件可靠性估计采集准确的数据。

估计软件可靠性一般可分为四个步骤，即数据采集、模型选择、模型拟合以及软件可靠性评估。

可以认为，数据采集是整个软件可靠性估计工作的基础，数据的准确与否关系到软件可靠性评估的准确度。

（3）通过软件可靠性测试找出所有对软件可靠性影响较大的错误。

3.软件可靠性测试的特点 软件可靠性测试不同于硬件可靠性测试，这主要是因为二者失效的原因不同。

硬件失效一般是由于元器件的老化引起的，因此硬件可靠性测试强调随机选取多个相同的产品，统计它们的正常运行时间。

正常运行的平均时间越长，则硬件就越可靠。

软件失效是由设计缺陷造成的，软件的输入决定是否会遇到软件内部存在的故障。

因此，使用同样一组输入反复测试软件并记录其失效数据是没有意义的。

在软件没有改动的情况下，这种数据只是首次记录的不断重复，不能用来估计软件可靠性。

软件可靠性测试强调按实际使用的概率分布随机选择输入，并强调测试需求的覆盖面。

软件可靠性测试也不同于一般的软件功能测试。

相比之下，软件可靠性测试更强调测试输入与典型使用环境输入统计特性的一致，强调对功能、输入、数据域及其相关概率的先期识别。

测试实例的采样策略也不同，软件可靠性测试必须按照使用的概率分布随机地选择测试实例，这样才能得到比较准确的可靠性估计，也有利于找出对软件可靠性影响较大的故障。

此外，软件可靠性测试过程中还要求比较准确地记录软件的运行时间，它的输入覆盖一般也要大于普通软件功能测试的要求。

对一些特殊的软件，如容错软件、实时嵌入式软件等，进行软件可靠性测试时需要有多种测试环境。

这是因为在使用环境下常常很难在软件中植入错误，以进行针对性的测试。

4.软件可靠性测试的效果 软件可靠性测试是软件可靠性保证过程中非常关键的一步。

经过软件可靠性测试的软件并不能保证该软件中残存的错误数最小，但可以保证该软件的可靠性达到较高的要求。

从工程的角度来看，一个软件的可靠性高不仅意味着该软件的失效率低，而且意味着一旦该软件失效，由此所造成的危害也小。

一个大型的工程软件没有错误是不可能的，至少理论上还不能证明一个大型的工程软件能没有错误。

因此，保证软件可靠性的关键不是确保软件没有错误，而是要确保软件的关键部分没有错误。

更确切地说，是要确保软件中没有对可靠性影响较大的错误。

这正是软件可靠性测试的目的之一。

软件可靠性测试的侧重点不同于一般的软件功能测试，其测试实例设计的出发点是寻找对可靠性影响较大的故障。

因此，要达到同样的可靠性要求，可靠性测试比一般的功能测试更有效，所花的时间也更少。

另外，软件可靠性测试的环境是具有使用代表性的环境，这样，所获得的测试数据与软件的实际运行数据比较接近，可用于软件可靠性估计。

总之，软件可靠性测试比一般的功能测试更加经济和有效，它可以代替一般的功能测试，而一般的软件功能测试却不能代替软件可靠性测试，而且一般功能测试所得到的测试数据也不宜用于软件可靠性估计。

二、软件可靠性测试中需注意的问题 软件可靠性测试一般可分为四个阶段：制定测试方案，制定测试计划，进行测试并记录测试结果，编写测试报告。

制定测试方案时需要特别注意被测功能的识别和失效等级的定义。

制定测试计划时需设计测试实例，决定测试时要确定输入顺序，并确定程序输出的预期结果，这时也需注意测试覆盖问题。

1.功能识别 软件可靠性测试的第一步就是进行功能识别，确定使用剖面。

功能识别的目标是：识别所有被测功能以及执行这些功能所需的相关输入，识别每一个使用需求及其相关输入的概率分布。

为达到第一个目标，需要分析软件功能的所有集合，这些功能之间全部的约束条件，功能之间的独立性、相互关系和相互影响，还需分析系统的不同运行模式、失效发生时系统重构策略等对软件运行方式有较大影响的因素。

第一个目标也是一般软件功能测试需要达到的目标，但第二个目标则是软件可靠性测试特别强调的。

为了得到能够反映软件使用的有代表性的概率分布，测试人员必须和系统工程师、系统运行分析员和顾客共同合作。

需要指出的是，由于可靠性的要求，输入数据的概率分布应包括合法数据的概率分布和非法数据的概率分布两部分。

有时为了更好地反映实际使用状况...