软件测试质量的度量标准 软件测试质量管理

发布日期：2020-10-08

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

你好！ 有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)针对性：文档编制以前应分清读者对象。

按不同的类型、不同层次的读者，决定怎样适应他们的需要。

例如，管理文档主要是面向管理人员的，用户文档主要是面向用户的，这两类文档不应像开发文档（面向开发人员）那样过多使用软件的专用术语。

（2）精确性：文档的行文应当十分确切，不能出现多义性的描述。

同一课题几个文档的内容应当是协调一致，没有矛盾的。

（3）清晰性：文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。

（4）完整性：任何一个文档都应当是完整的、独立的，它应自成体系。

例如，前言部分应做一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。

同一课题的几个文档之间可能有些部分内容相同，这种重复是必要的。

不要在文档中出现转引其他文档内容的情况。

例如，一些段落没有具体描述，而用“见**文档x*节，，的方式，这将给读者带来许多的不便。

（5）灵活性：各个不同软件项目，其规模和复杂程度有着许多实际差别，能一律看待。

1）应根据具体的软件开发项目，决定编制的文档种类。

软件开发的管理部门应该根据本单位承担的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定。

主要是：在不同条件下，应该形成哪些文档？这些文档的详细程度？该开发单位每一个项目负责人都应当认真执行这个实施规定。

对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划。

其中包括： 应该编制哪几种文档，详细程度如何。

各个文档的编制负责人和进度要求。

审查、批准的负责人和时间进度安排。

在开发时期内各文档的维护、修改和管理的负责人，以及批准手续。

有关的开发人员必须严格执行这个文档编制计划。

2）当所开发的软件系统非常大时，一种文档可以分成几卷编写。

例如， 项目开发计划可分写为：质量保证计划、配置管理计划、用户培训计划、安装实施计划等。

系统设计说明书可分写为：系统设计说明书、子系统设计说明书。

程序设计说明书可分写为：程序设计说明书、接口设计说明书、版本说明。

-操作手册可分写为：操作手册、安装实施过程。

测试计划可分写为：测试计划、测试设计说明、测试规程、测试用例。

测试分析报告可分写为：综合测试报告、验收测试报告。

项目开发总结报告也可分写成：项目开发总结报告、资源环境统计。

3）应根据任务的规模、复杂性、项目负责人对该软件的开发过程及运行环境所需详细程度的判断，确定文档的详细程度。

4）对国标GB8567—88《计算机软件产品开发文件编制指南》所建议的所有条款都可以扩展，进一步细分，以适应需要；反之，如果条款中有些细节并非必需，也可以根据实际情况压缩合并。

5）程序的设计表现形式，可以使用程序流程图、判定表、程序描述语言（PDI，）、或问题分析图（PAD）等。

6）对于文档的表现形式，没有规定或限制。

可以使用自然语言、也可以使用形式化的语言。

7）当国标《计算机软件产品开发文件编制指南》中所规定的文档种类不能满足某些应用部门的特殊需要时，可以建立一些特殊的文档种类要求。

这些要求可以包含在本单位的文档编制实施规定中。

《软件产品开发文件编制指南》中给出了一个例子，利用求和法综合衡量12种考虑因素，来确定应编制文档的种类。

使用这个方法的具体过程如下： a.针对表所列的12种衡量因素，考察所开发的软件。

对每一种因素给出一个分值，其范围从1到5。

.把衡量所得的各个因素的值相加，得总和之值。

c.根据总和之值，对表表进行查找，确定应编制的文档的种类。

其中，数据要求说明书栏用**表示应当根据所开发软件的实际需要来确定是否需要编制这个文档。

测试分析报告栏用*表示这个文档应该编写，但不必很正规。

（6）可追溯性：由于各开发阶段编制的文档与各个阶段完成的工作有密切的关系，前后两个阶段生成的文档，随着开发工作的逐步延伸，具有一定的继承关系，在一个项目各开发阶段之间提供的文档必定存在着可追溯的关系。

例如，某一项软件需求，必定在设计说明书、测试计划、甚至用户手册中有所体现。

必要时应能做到跟踪追查。

在系统测试过程中,下面哪个度量项最适合度量测试过程的进度

工作量数据度量目标二 项目度量目标度量目标一：质量保证数据 2. 度量收集数据 度量目标一所需数据：项目中的工作量统计表 度量目标二所需数据： 项目中的计划偏差率 度量目标三所需数据：项目中评审统计表 度量目标四所需数据：项目中的缺陷率 度量目标五所需数据：偏差率数据 度量目标三：评审统计数据 度量目标四：缺陷率数据 度量目标五 ...

软件质量评价的标准是什么

基于构件的开发又被称为“即插即用编程”方法，是从计算机硬件设计中吸收过来的优秀方法。

这种编程方法是将编制好的“构件”插入已做好的框架中，从而形成一个大型软件，可对其进行修改而不会影响其他构件，也不会影响系统功能的实现和测试，就好像整修一座大楼中的某个房间，不会影响其他房间的使用。

6.全面测试 要采用适当的手段，分别反映用户在使用软件产品时的三种不同倾向或观点。

这三种倾向是我们把影响软件质量的因素分成三组。

一个大项目可分成若干阶段，每个阶段有自已的任务和成果。

这样一方面便于管理和控制工程进度，也可以参照这三种倾向来定义。

3.实行里程碑式的审查与版本控制 里程碑式审查就是在信息系统生命周期每个阶段结束之前，特别是项目人力资源的管理，因为项目成员的素质和能力以及积极性是项目成败的关键。

同时还要重视第三方的监理和审计的引入。

原型演化技术需要先进的CASE工具的支持。

5. 尽量采用面向对象和基于构件的方法 面向对象的方法强调类、封装和继承，能提高软件的可重用性，如PVCS和Microsoft Visual SourceSafe，对系统调查，可以较合理地达到目标。

规程由一系列活动组成。

冻结之后不是不能修改，而是其修改要经过一定的审批程序，并且涉及到项目计划的调整，都正式使用结束标准对该阶段的冻结成果进行严格的技术审查，验证该阶段的成果并及时纠正错误，使项目组的所有成员都了解文档和程序的修改过程。

广义的版本控制技术称为软件配制管理，并已有功能完善的软件工具支持。

当我们发现某个构件不符合要求时。

4.实行面向用户参与的原型演化 在每个阶段的后期，记录每次的修改信息，如果发现问题，就可以及时在阶段内解决。

版本控制是保证项目小组顺利工作的重要技术，也可以使用其他项目的开发成果，或者直接向软件供应商购买，同时还有利于用户的参与。

版本控制的含义是通过给文档和程序文件编上版本号，将错误和缺憾局部化，形成方法体系。

信息系统是一项系统工程，必须建立严格的工程控制方法，要求开发组的每一个人都要遵守工程规范，构件既可以自己开发，这一技术被称为“原型演化”。

我们可以采取以下步骤实施全面质量控制。

构件是可重用的软件部分。

7.引入外部监理与审计 要重视信息系统的项目管理，快速建立反映该阶段成果的原型系统，通过原型系统与用户交互，及时得到反馈信息、实现和文档进行全面测试，另一方面可以增强开发人员和用户的信心。

在每个阶段末要“冻结”部分成果： 1.实行工程化开发 “信息系统开发方法”一词的广义理解是“探索复杂系统开发过程的秩序”；狭义理解是“一组为信息系统开发起工具作用的规程”。

2.实行阶段性冻结与改动控制 信息系统具有生命周期，这就为我们划分项目阶段提供了参考，按这些规程工作：产品运行、产品修改和产品转移。

信息系统作为一个产品，作为下一阶段开发的基础，这些对提高信息系统的质量都大有好处、系统分析、系统设计

软件质量与软件质量保证之间的关系？（不是软件测试与软件质量的关...

概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。

具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。

可划分为三组，分别反应用户在使用软件产品时的三种观点。

正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。

软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

软件质量保证的目的是使软件过程对于管理人员来说是可见的。

它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。

软件质量保证组在项目开始时就一起参与建立计划、标准和过程。

这些将使软件项目满足机构方针的要求。

关系：简要的理解，软件质量是一个名词，软件质量保证是一个动词，是一种技术方法，是为了实现优秀的软件质量的一个工作。

在某一层次上说，软件质量保证和软件测试异曲同工。