软件测试（SOFTWARE TESTING）

软件测试包括动态验证一个程序在一组有限的测试用例上提供了预期的行为，这些测试用例是从通常无限的执行域中选择的。
在上述定义中，粗体字对应于描述软件测试知识领域（KA）的关键问题：

• 动态：这一术语意味着测试总是对选定的输入执行程序。因为一个复杂的系统，仅仅用一个不确定的输入值来指定一个不确定的行为是不够的。然而，在本KA中，术语“输入”将被保留，其隐含的约定是，其含义在其重要的情况下也包括指定的输入状态。静态技术不同于动态测试，是动态测试的补充。静态技术包含在软件质量KA中。值得注意的是，不同社区的术语并不统一，有些社区使用术语“测试”也指静态技术。
• 有限：即使是在简单的程序中，理论上也有很多测试用例，因此穷举测试可能需要数月或数年才能执行。这就是为什么在实践中，一套完整的测试通常被认为是无限的，测试是在所有可能的测试的子集上进行的，这是由风险和优先级标准决定的。测试总是意味着一方面有限的资源和时间表，另一方面固有的无限测试需求之间的权衡。
• 选择：许多提议的测试技术在如何选择测试集上有本质的不同，软件工程师必须意识到，不同的选择标准可能产生不同程度的有效性。如何在给定的条件下确定最合适的选择标准是一个复杂的问题，在实践中，风险分析技术和软件工程的专业知识被应用。
• 预期：必须有可能（尽管并非总是容易）决定所观察到的程序测试结果是否可接受；否则，测试工作是无用的。可以对照用户需求（通常称为验证测试）、规范（验证测试）或潜在需求或期望的预期行为检查观察到的行为（见软件需求KA中的验收测试）。

近年来，软件测试的观点逐渐成熟为一种建设性的观点。测试不再被视为一种只在编码阶段完成后才开始的活动，而检测失败的目的有限。在整个开发和维护生命周期中，软件测试是或应该是无处不在的。实际上，软件测试的规划应该从软件需求过程的早期阶段开始，测试计划和程序应该系统地、持续地开发，并且可能随着软件开发的进行而细化。这些测试计划和测试设计活动为软件设计者提供了有用的输入，并有助于突出潜在的弱点，例如文档中的设计疏忽/矛盾或遗漏/含糊不清。

对于许多组织来说，提高软件质量的方法是预防：预防问题显然比纠正问题要好得多。因此，可以将测试视为提供有关软件功能和质量属性的信息的一种手段，也可以在错误预防无效的情况下识别故障。这也许是显而易见的，但值得承认的是，即使在完成了广泛的测试活动之后，软件仍然可能包含错误。交付后遇到的软件故障通过纠正性维护解决。软件维护主题包含在软件维护KA中。

在软件质量KA（参见软件质量管理技术）中，软件质量管理技术主要分为静态技术（无代码执行）和动态技术（代码执行）。这两个类别都很有用。本文主要研究动态技术。

软件测试也与软件构建相关（参见软件构造KA中的构建测试）。尤其是，单元测试和集成测试与软件构建密切相关。

软件测试KA的主题分解：

1.软件测试基础

1.1.测试相关术语

1.1.1.测试术语及相关定义

引用的参考文献中提供了测试和测试相关术语的定义，总结如下。

1.1.2. 故障与错误

软件工程文献中使用了许多术语来描述故障：fault, failure 和 error等等。对于系统很重要必须查明原因的故障（使用fault）和以交付系统中不期望的结果（使用failure）。事实上，软件中很可能存在从不以失败的形式表现出来的错误（参见第1.2节“关键问题”中测试的理论和实践限制）。因此，测试可以揭示故障，而且必须排除故障。当区别不重要时，更通用的术语“缺陷”可以用来指故障或失败。

然而，应该认识到失败的原因不能总是明确地确定。一般来说，没有理论标准可以确定导致观测到的故障的原因。可能会说，这是必须修改的错误，以消除失败，但其他修改可能也可以工作得很好。为了避免歧义，可以使用导致失败的输入，而不是错误，即导致出现失败的输入集。

1.2.关键问题

1.2.1.测试选择标准/测试充分性标准（停止规则）

测试选择标准是一种选择测试用例或确定一组测试用例足以满足特定目的的方法。测试充分性标准可用于决定何时完成或已完成足够的测试[4]（见第5.1节“实际考虑”中的终止）。

1.2.2.测试有效性/测试目标

测试有效性是通过分析一组程序执行来确定的。要执行的测试的选择可以由不同的目标来指导：只有根据所追求的目标才能评估测试集的有效性。

1.2.3. 缺陷发现测试

在缺陷发现测试中，成功的测试是导致系统失败的测试。这与证明软件满足其规范或其他期望属性的测试有很大不同，在这种情况下，如果在实际的测试用例和测试环境中没有观察到任何失败，那么测试就是成功的。

1.2.4. 预言问题

预言是任何人或机械代理，它决定一个程序在给定的测试中的行为是否正确，并相应地得出“通过”或“失败”的结论。存在许多不同类型的预言；例如，明确的需求规范、行为模型和代码注释。自动化的机械化预言可能是困难和昂贵的。

1.2.5.测试的理论和实践局限性

测试理论警告不要将不合理的信心归因于一系列成功的测试。不幸的是，测试理论的大多数既定结果都是否定的，因为它们指出了测试永远无法实现的东西，而不是实际实现的东西。在这方面最著名的引用是Dijkstra的格言，“程序测试可以用来显示bug的存在，但决不能显示它们的不存在”[5]。明显的原因是，在现实的软件中，完整的测试是不可行的。因此，测试必须基于风险[6，第1部分]来驱动，并且可以看作是一种风险管理策略。

1.2.6. 不可行路径问题

不可行路径是任何输入数据都无法执行的控制流路径。在基于路径的测试中，它们是一个重要的问题，特别是在测试输入的自动派生以执行控制流路径中。

1.2.7.可测试性

术语“软件可测试性”有两个相关但不同的含义：一方面，它是指满足给定的测试覆盖率标准的难易程度；另一方面，它被定义为如果软件出现故障，一组测试用例将暴露出故障的可能性，这可能是统计上测量的。这两种意义都很重要。

1.3. 测试与其他活动的关系

软件测试与静态软件质量管理技术、正确性证明、调试和程序构造有关，但不同于静态软件质量管理技术。然而，从软件质量分析师和认证者的角度考虑测试是有益的。

• 测试与静态软件质量管理技术（见软件质量KA[1*，c12]中的软件质量管理技术）。
• 测试与正确性证明和形式验证（参见软件工程模型和方法KA[1*，c17s2]）。
• 测试与调试（见软件构造KA中的构造测试和计算基础KA[1*，c3s6]中的调试工具和技术）。
• 测试与程序构建（参见软件构造KA[1*，c3s2]中的构建测试）。

2. 测试级别

在整个开发和维护过程中，软件测试通常在不同的层次上进行。可以根据测试对象（称为目标）或目的（称为测试级别的目标）来区分级别。

2.1. 测试的目标

测试的目标可以不同：单个模块、一组这样的模块（按目的、用途、行为或结构相关）或整个系统。可以区分三个测试阶段：单元、集成和系统。这三个测试阶段并不意味着任何过程模型，也没有任何一个被认为比其他两个更重要。

2.1.1. 单元测试

单元测试验证独立于可单独测试的软件元素的功能。根据上下文的不同，这些可以是单独的子程序，也可以是由高度内聚的单元组成的更大的组件。通常，单元测试是通过访问被测试的代码并在调试工具的支持下进行的。编写代码的程序员通常（但不总是）进行单元测试。

2.1.2. 集成测试

集成测试是验证软件组件之间交互的过程。经典的集成测试策略，如自顶向下和自下而上，通常用于层次结构的软件。

现代的系统集成策略通常是由体系结构驱动的，它涉及到基于确定的功能线程的软件组件或子系统的增量集成。集成测试通常是在开发的每个阶段进行的一项活动，在此期间，软件工程师将较低层次的观点抽象出来，并将注意力集中在他们正在集成的层次的观点上。对于其他小型、简单的软件，增量集成测试策略通常比一次将所有组件放在一起更好，这通常被称为“大爆炸”测试。

2.1.3. 系统测试

系统测试与测试整个系统的行为有关。有效的单元和集成测试将识别出许多软件缺陷。系统测试通常被认为适合于评估非功能性系统需求，如安全性、速度、准确性和可靠性（参见软件需求KA中的功能性和非功能性需求以及软件质量KA中的软件质量需求）。其他应用程序、实用程序、硬件设备或操作环境的外部接口也通常在此级别进行评估。

2.2. 测试目的

测试是针对特定的目标进行的，这些目标或多或少都有明确的规定，精度也各不相同。用精确、定量的术语说明测试的目标，支持测试过程的测量和控制。

测试的目的可以是验证不同的属性。可以设计测试用例来检查功能规范是否正确实现，这在文献中被称为一致性测试、正确性测试或功能测试。但是，也可以测试其他一些非功能属性，包括性能、可靠性和可用性等（参见软件质量KA中的模型和质量特征）。

测试的其他重要目标包括但不限于可靠性度量、安全漏洞识别、可用性评估和软件验收，为此将采取不同的方法。注意，一般来说，测试目标随测试目标的不同而不同；不同的测试级别处理不同的目的。

下面列出的副标题是文献中最常引用的副标题。请注意，某些类型的测试更适合于定制软件包的安装测试，例如，而其他类型的测试则更适合于消费类产品，例如beta测试。

2.2.1. 验收/鉴定测试

验收/鉴定测试确定系统是否满足其验收标准，通常通过对照客户要求检查所需的系统行为。因此，客户或客户代表指定或直接开展活动，以检查其要求是否得到满足，或者如果是消费品，则检查组织是否满足目标市场的规定要求。这个测试活动可能涉及也可能不涉及系统的开发人员。

2.2.2. 安装测试

通常，在完成系统测试和验收测试之后，在目标环境中安装软件时会对其进行验证。安装测试可以看作是在硬件配置和其他操作约束的操作环境中进行的系统测试。也可验证安装程序。

2.2.3. α和β测试

在软件发布之前，有时会给一小部分选定的潜在用户进行试用（alpha测试）和/或给更多的代表性用户（beta测试）。这些用户报告产品存在问题。Alpha和beta测试通常是不受控制的，并且不总是在测试计划中提及。

2.2.4. 可靠性实现与评估

测试通过识别和纠正故障来提高可靠性。此外，可以根据软件的操作概要随机生成测试用例，从而得出可靠性的统计度量（参见第3.5节“基于使用的技术”中的操作概要）。后一种方法称为操作测试。使用可靠性增长模型，这两个目标可以一起实现[3]（见第4.1节“被测程序的评估”中的寿命试验、可靠性评估）。

2.2.5. 回归测试

回归测试是“对系统或组件进行选择性的重新测试，以验证修改没有造成意外影响，并且系统或组件仍然符合其规定的要求。”，这种方法是显示软件仍然通过测试套件中先前通过的测试（事实上，有时也称为非回归测试）。对于增量开发，回归测试的目的是表明软件的行为不会因软件的增量更改而改变，除非它应该改变。在某些情况下，必须在每次进行更改时回归测试所提供的保证和执行回归测试所需的资源之间进行权衡，因为可能会执行大量的测试，这可能相当耗时。回归测试涉及选择、最小化和/或优先排序现有测试套件中的测试用例子集[8]。回归测试可以在第2.1节“测试目标”中描述的每个测试级别上进行，并且可以应用于功能和非功能测试。

2.2.6. 性能测试

性能测试验证软件是否满足指定的性能要求，并评估性能特征，例如容量和响应时间。

2.2.7.安全测试

安全测试的重点是验证软件是否受到外部攻击的保护。特别是，安全测试验证系统及其数据的机密性、完整性和可用性。通常，安全测试包括对软件或系统的误用和滥用进行验证（否定测试）。

2.2.8.压力测试

压力测试在最大设计负载下以及超过最大设计负载时对软件进行测试，目的是确定行为极限，并测试关键系统中的防御机制。

2.2.9.back-to-back测试

IEEE/ISO/IEC标准24765将back-to-back测试定义为“使用相同的输入执行一个程序的两个或多个变体的测试，比较输出，并在不一致的情况下分析错误。”

2.2.10.恢复测试

恢复测试旨在验证系统崩溃或其他“灾难”后的软件重启能力

2.2.11. 接口测试

界面缺陷是复杂系统中常见的问题。接口测试的目的是验证组件接口是否正确，以提供正确的数据和控制信息交换。通常测试用例是从接口规范生成的。接口测试的一个特定目标是模拟最终用户应用程序对api的使用。这涉及到API调用参数的生成、外部环境条件的设置以及影响API的内部数据的定义。

2.2.12. 配置测试

如果软件是为不同的用户而构建的，配置测试会在不同的指定配置下验证软件。

2.2.13. 可用性与人机交互测试

可用性和人机交互测试的主要任务是评估最终用户学习和使用软件的容易程度。一般来说，它可能涉及测试支持用户任务的软件功能、帮助用户的文档以及系统从用户错误中恢复的能力（参见软件设计KA中的用户界面设计）。

3. 测试技术

测试的目的之一是检测尽可能多的故障。为此已经开发了许多技术[6，第4部分]。这些技术试图通过尽可能系统地识别将产生代表性程序行为的输入来“破坏”程序；例如，通过考虑输入域的子类、场景、状态和数据流。

这里介绍的测试技术的分类是基于测试是如何生成的：来自软件工程师的直觉和经验、规范、代码结构、要发现的真实或想象的错误、预测的用法、模型或应用程序的性质。一类涉及两种或两种以上技术的组合使用。

有时，如果测试是基于关于软件是如何设计或编码的信息，则这些技术被分类为白盒（也称为玻璃盒），或者如果测试用例仅依赖于软件的输入/输出行为，则这些技术被分类为黑盒。下面的列表包括那些常用的测试技术，但是一些实践者比其他人更依赖其中一些技术。

3.1. 基于软件工程师的直觉和经验

3.1.1. Ad Hoc 随机测试

也许最广泛使用的技术是随机测试：测试依赖于软件工程师的技能、直觉和类似程序的经验。随机测试对于识别不容易由更形式化的技术生成的测试用例非常有用。

3.1.2. 探索性测试

探索性测试被定义为同时学习、测试设计和测试执行[6，第1部分]；也就是说，测试不是在既定的测试计划中预先定义的，而是动态设计、执行和修改的。探索性测试的有效性依赖于软件工程师的知识，这些知识可以从各种来源获得：测试期间观察到的产品行为、对应用程序、平台、故障过程的熟悉程度、可能的故障和失败的类型、与特定产品相关的风险等等。

3.2. 基于输入域的技术

3.2.1. 等价类划分

等价划分涉及根据指定的标准或关系将输入域划分为子集（或等价类）的集合。该标准或关系可以是不同的计算结果、基于控制流或数据流的关系，或者是系统接受和处理的有效输入与无效输入之间的区别，例如超出范围的值，这些输入不被接受并且应该生成错误消息或启动错误处理。通常从每个等价类中选取一组具有代表性的测试（有时只有一个）。

3.2.2. 成对测试

测试用例是通过为一组输入变量的，每一对组合有代表性的值，而不是考虑所有可能的组合而得到的。两两测试属于组合测试，通常也包括比成对更高级别的组合：这些技术被称为t-wise，其中考虑了t输入变量的每一个可能组合。

3.2.3. 边界值分析

测试用例选择在变量输入域的边界上或附近，其基本原理是许多故障往往集中在输入的极值附近。在这种情况下，一个非预期的输入或测试变量被选在测试程序的鲁棒性扩展之外。

3.2.4. 随机试验

测试纯粹是随机生成的（不要与第3.5节操作概要中描述的操作概要中的统计测试相混淆）。这种形式的测试属于输入域测试的范畴，因为输入域必须是已知的，以便能够在其中随机选取点。随机测试为测试自动化提供了一种相对简单的方法；最近，提出了增强的随机测试形式，其中随机输入采样由其他输入选择标准指导[11]。模糊测试或模糊化是一种特殊形式的随机测试，旨在破坏软件；它最常用于安全测试。

3.3. 基于代码的技术

3.3.1. 基于控制流的标准

基于控制流的覆盖标准旨在覆盖程序中的所有语句、语句块或指定的语句组合。基于控制流的标准中最强的是路径测试，它旨在执行程序控制流图中所有从入口到出口的控制流路径。由于穷举路径测试通常因循环而不可行，因此其他较不严格的标准侧重于限制循环迭代的路径覆盖率，如语句覆盖率、分支覆盖率和条件/决策测试。这种测试的充分性是用百分比来衡量的；例如，当所有的分支都被测试至少执行了一次时，就达到了100%的分支覆盖率。

3.3.2. 基于数据流的标准

在基于数据流的测试中，控制流图被注释为如何定义、使用和终止(未定义)程序变量的信息。最强的标准为定义所有使用路径，对于每个变量，执行从该变量的定义到该定义的使用的每个控制流路径段。为了减少所需路径的数量，采用了较弱的策略，例如所有定义和所有使用。

3.3.3. 基于代码测试的参考模型

虽然它本身不是一种技术，但是程序的控制结构可以用流图来图形化地表示，以可视化基于代码的测试技术。流图是一种有向图，其节点和弧对应于程序元素（参见数学基础中的图和树）。例如，节点可以表示语句或不间断的语句序列，而弧可以表示节点之间的控制转移。

3.4. 基于故障的技术

通过不同程度的形式化，基于故障的测试技术设计了专门用于揭示可能的或预定义的故障类别的测试用例。为了更好地关注测试用例的生成或选择，可以引入一个故障模型来对不同类型的故障进行分类。

3.4.1. 错误猜测

在错误猜测中，测试用例是由软件工程师专门设计的，他们试图预测给定程序中最合理的错误。一个好的信息来源是早期项目中发现的故障历史，以及软件工程师的专业知识。

3.4.2. 突变测试

变种是被测程序的一个稍微修改过的版本，与之不同的是，它的语法有一点变化。每个测试用例都执行原始程序和所有生成的突变体：如果一个测试用例成功地识别了程序和突变体之间的差异，则后者被称为“被杀死”。最初被认为是一种评估测试集的技术（见第4.2节）。突变测试本身也是一个测试标准：要么随机生成测试，直到有足够的突变体被杀死，要么专门设计测试来杀死存活的突变体。在后一种情况下，变异测试也可以归类为基于代码的技术。突变测试的基本假设是耦合效应，通过寻找简单的句法错误，可以发现更复杂但真实的错误。为了使这项技术有效，必须以系统的方式自动生成和执行大量的突变体[12]。

3.5. 基于使用的技术

3.5.1. 操作概要

在可靠性评估测试（也称为操作测试）中，测试环境尽可能地再现软件的操作环境或操作概要。目的是从观察到的测试结果中推断出软件在实际使用中的未来可靠性。在实际操作中，它们的输入或发生的概率是根据这个操作的频率来分配的。在系统测试过程中，可以使用操作概要文件来指导测试用例的推导，这些测试用例将评估可靠性目标的实现，并对不同功能的相对使用和重要性进行评估，这些功能类似于在操作环境中遇到的功能[3]。

3.5.2. 用户观察启发式算法

可用性原则可以为发现用户界面设计中的问题提供指导（参见软件设计中的用户界面设计）。专门的启发式，也被称为可用性检查方法，用于在受控条件下系统地观察系统的使用情况，以确定人们对系统及其接口的使用情况。例如，用户思维和可用性调查，甚至包括间接的现场观察和分析。

3.6. 基于模型的测试技术

本文中的模型是被测软件或其软件需求的抽象（正式）表示（见软件工程模型和方法中的建模）。基于模型的测试用于验证需求，检查其一致性，并生成侧重于软件行为方面的测试用例。基于模型的测试的关键组件是[13]：用于表示软件模型或其需求的符号；工作流模型或类似模型；用于生成测试用例的测试策略或算法；用于测试执行的支持基础设施；以及与预期结果相比较的测试结果评估。由于技术的复杂性，基于模型的测试方法通常与测试自动化工具结合使用。基于模型的测试技术包括以下内容。

3.6.1. 决策表

决策表表示条件（大致为输入）和操作（大致为输出）之间的逻辑关系。通过考虑各种可能的条件组合及其相应的综合作用，系统地导出了测试用例。一个相关的技术是因果图。

3.6.2. 有限状态机

通过将程序建模为有限状态机，可以选择测试来覆盖状态和转换。

3.6.3. 正式规范

用一种形式化的语言描述规范（参见软件工程模型和方法KA中的形式化方法）允许自动派生功能测试用例，同时提供一个用于检查测试结果的预言。

TTCN3（测试和测试控制符号版本3）是为编写测试用例而开发的语言。该符号是为测试电信系统的特殊需要而设计的，因此它特别适合于测试复杂的通信协议。

3.6.4. 工作流模型

工作流模型指定由人和/或软件应用程序执行的一系列活动，通常通过图形符号表示。每个动作序列构成一个工作流（也称为场景）。典型工作流和备选工作流都应进行测试[6，第4部分]。在业务流程测试中，特别关注工作流规范中的角色。

3.7.基于应用程序性质的技术

以上技术适用于各种软件。测试派生和执行的附加技术基于被测试软件的性质；例如，

• 面向对象软件
• 软件系统
• 基于web的软件
• 并行程序
• 基于协议的软件
• 实时系统
• 安全关键系统
• 面向服务的软件
• 开源软件
• 嵌入式软件

3.8.选择和组合技术

3.8.1.功能与结构相结合

基于模型的测试技术和基于代码的测试技术通常是功能测试和结构测试的对比。这两种测试选择方法不应被视为替代方法，而应被视为补充；事实上，它们使用不同的信息来源，并被证明突出了不同类型的问题。它们可以结合使用，这取决于预算方面的考虑。

3.8.2.确定性与随机性

测试用例可以根据多种技术中的一种以确定的方式选择，也可以从输入的某些分布中随机抽取，如通常在可靠性测试中所做的那样。为了分析一种方法比另一种方法更有效的条件，已经进行了一些分析和实证比较。

4. 试验相关措施

有时测试技术与测试目标相混淆。测试技术可以被视为帮助确保实现测试目标的辅助工具[6，第4部分]。例如，分支覆盖是一种流行的测试技术。实现指定的分支覆盖度量（例如，95%的分支覆盖率）本身不应该是测试的目标：它是一种通过尝试在每个决策点系统地执行每个程序分支来提高发现失败的机会的方法。为避免此类误解，应明确区分基于观察到的测试输出对被测程序进行评估的测试相关度量和评估测试集完整性的度量。（有关度量程序的信息，请参阅软件工程管理KA中的软件工程度量。有关度量的信息，请参见软件工程（Engineering）过程KA中的软件过程和产品度量。）

测量通常被认为是质量分析的基础。测量也可用于优化测试的计划和执行。测试管理可以使用几种不同的过程度量来监视进度。（参见第5.1节“实际考虑”，了解对管理有用的测试过程措施的讨论。）

4.1. 测试程序的评估

4.1.1. 有助于计划和设计测试的程序度量

基于软件大小（例如，源代码行或功能大小；参见软件需求KA中的度量需求）或基于程序结构的度量可以用来指导测试。结构度量还包括确定模块之间调用频率的度量。

4.1.2. 故障类型、分类和统计

测试文献中有丰富的断层分类。为了使测试更有效，了解在被测软件中可能发现的故障类型以及这些故障在过去发生的相对频率是很重要的。这些信息在质量预测和过程改进中都很有用（参见软件质量KA中的缺陷描述）。

4.1.3. 故障密度

测试中的程序可以通过将发现的故障数作为发现的故障数与程序大小之间的比率来计算。

4.1.4. 测试终止,可靠性评估

软件可靠性的统计估计，可以通过观察达到的可靠性来获得，可以用来评估软件产品并决定是否可以停止测试（见第2.2节，可靠性实现和评估）。

4.1.5. 可靠性增长模型

可靠性增长模型提供了基于故障的可靠性预测。一般来说，他们假设，当导致所观察到的故障的故障已经修复（尽管有些模型也接受不完全修复）时，估计产品的可靠性平均呈现出增加的趋势。有许多已发表的可靠性增长模型。值得注意的是，这些模型分为故障计数和故障间隔时间模型。

4.2. 测试评估

4.2.1. 覆盖率/彻底性 措施

一些测试充分性标准要求测试用例系统地执行程序或规范中确定的一组元素（见主题3，测试技术）。为了评估已执行测试的彻底性，软件工程师可以监视覆盖的元素，以便动态地测量覆盖元素与总数量的比率。例如，可以测量在程序流图中覆盖的分支的百分比，或者在规范文档中列出的那些分支中执行的功能需求的百分比。基于代码的充分性标准需要测试程序的适当工具。

4.2.2. 故障播种

在故障播种中，一些故障在测试前被人为地引入到程序中。在执行测试时，这些种子故障中的一些将被显示出来，可能还有一些已经存在的故障。理论上，根据发现的人为故障的种类和数量，可以评估测试的有效性，并估计剩余的真实故障数。在实践中，统计学家质疑种子故障相对于真实故障的分布和代表性，以及任何外推所基于的小样本量。有些人还认为，使用这种技术时应该非常小心，因为在软件中插入错误会带来明显的风险。

4.2.3. 突变评分

在突变测试中（参见第3.4节“基于故障的技术”中的突变测试），被杀死的突变与产生的突变总数的比率可以作为已执行测试集有效性的度量。

4.2.4. 不同技术的比较及相对有效性

已经进行了一些研究来比较不同测试技术的相对有效性。重要的是要准确地说明评估技术所依据的性质；例如，“有效性”一词的确切含义是什么？可能的解释包括发现第一个故障所需的测试次数、通过测试发现的故障数量与测试期间和之后发现的所有故障的比率，以及可靠性提高了多少。根据上述每一个有效性概念，对不同技术进行了分析和实证比较。

5. 测试过程

测试概念、策略、技术和措施需要集成到一个定义和控制的过程中。测试过程支持测试活动，并为测试人员和测试团队提供从测试规划到测试输出评估的指导，以确保以经济高效的方式实现测试目标。

5.1. 实际考虑

5.1.1. 合作/无私 编程

成功测试的一个重要因素是对测试和质量保证活动的合作态度。在软件开发和维护过程中，管理者在促进对故障发现和纠正的普遍接受方面起着关键作用；例如，克服程序员中个人代码所有权的思维定势，以及促进团队负责代码异常的协作环境。

5.1.2. 测试指南

测试阶段可以由不同的目标来指导，例如，基于风险的测试使用产品风险来确定测试策略的优先级和重点，基于场景的测试根据指定的软件场景定义测试用例。

5.1.3. 测试过程管理

在不同级别进行的测试活动（见主题2，测试级别）必须与人员、工具、策略和措施一起组织到一个定义良好的过程中，该过程是生命周期的一个组成部分。

5.1.4. 测试文档和工作产物

文档是测试过程形式化不可或缺的一部分[6，第3部分]。测试文件可包括测试计划、测试设计规范、测试程序规范、测试用例规范、测试日志和测试事件报告等。被测软件作为测试项记录在案。测试文档应该被生成并不断更新，以达到与软件工程中其他类型文档相同的质量水平。测试文档也应在软件配置管理的控制下（参见软件配置管理）。此外，测试文档包括可以为用户手册和用户培训提供材料的工作产品。

5.1.5. 测试驱动开发

测试驱动开发（Test-driven development，TDD）起源于核心XP（extreme programming，极限编程）实践之一，包括在编写要测试的代码之前编写单元测试（参见软件工程模型和方法KA中的敏捷方法）。作为一个独立的测试用例，而不是作为一个测试用例的TDD来正确地开发软件需求。TDD不是一种测试策略，而是一种要求软件开发人员定义和维护单元测试的实践；因此，它还可以对详细描述用户需求和软件需求规范产生积极影响。

5.1.6. 内部与独立测试团队

测试过程的形式化还可能涉及测试团队的组织形式化。测试团队可以由内部成员（即，在项目团队中，参与或不参与软件构建）、外部成员（希望带来公正、独立的观点）或内部和外部成员组成。考虑成本、进度、相关组织的成熟度级别以及应用程序的关键性可以指导决策。

5.1.7.成本/工作量估算和测试过程措施

管理者使用与测试所花费的资源以及不同测试阶段的相对故障查找有效性相关的一些度量来控制和改进测试过程。这些测试度量可以包括指定的测试用例数量、执行的测试用例数量、通过的测试用例数量和失败的测试用例数量等方面。

测试阶段报告的评估可以与根本原因分析相结合，以评估测试过程在尽早发现故障方面的有效性。这种评估可以与风险分析相联系。此外，值得花费在测试上的资源应该与应用程序的使用/关键性相称：不同的技术有不同的成本，并产生不同程度的产品可靠性信心。

5.1.8.终止测试

必须决定多少测试是足够的，以及何时可以终止测试阶段。彻底性度量，如实现的代码覆盖率或功能覆盖率，以及对故障密度或操作可靠性的估计，提供了有用的支持，但其本身并不充分。该决定还涉及对可能剩余故障产生的成本和风险的考虑，而不是继续测试产生的成本（见第1.2节“关键问题”中的测试选择标准/测试充分性标准）。

5.1.9.测试重用和测试模式

为了以一种有组织且经济高效的方式进行测试或维护，用于测试软件每个部分的方法应该被系统地重用。测试材料的存储库应在软件配置管理的控制下，以便软件需求或设计的更改可以反映在测试的更改中进行中在某些情况下测试某些应用程序类型所采用的测试解决方案，以及所做决定背后的动机，构成了一个测试以后可以在类似的模式中记录重用项目本身。

5.2. 测试活动

如以下描述所示，测试活动的成功管理在很大程度上取决于软件配置管理过程（参见软件配置管理）。

5.2.1. 规划

与项目管理的所有其他方面一样，测试活动必须被规划。测试计划的关键方面包括人员协调、测试设施和设备的可用性、所有测试相关文档的创建和维护，以及对可能的不良结果的计划。如果要维护多个软件基线，那么一个主要的规划考虑是确保将测试环境设置为正确配置所需的时间和精力。

5.2.2. 测试用例生成

测试用例的生成基于要执行的测试级别和特定的测试技术。测试用例应在软件配置管理的控制下，并包括每个测试的预期结果。

5.2.3. 测试环境开发

用于测试的环境应与其他采用的软件工程工具兼容。它应该促进测试用例的开发和控制，以及预期结果、脚本和其他测试材料的记录和恢复。

5.2.4. 执行

测试的执行应该体现科学实验的一个基本原则：在测试过程中所做的每件事都应该被执行和记录得足够清楚，以便其他人可以复制结果。因此，测试应按照文件化的程序进行，使用被测软件的明确定义版本。

5.2.5. 测试结果评估

应评估测试结果，以确定测试是否成功。在大多数情况下，“成功”意味着软件按预期运行，没有任何重大的意外结果。并非所有意想不到的结果都必然是错误，但有时被确定为只是噪音。在排除故障之前，需要进行分析和调试，以隔离、识别和描述故障。当测试结果特别重要时，可召开正式评审委员会对其进行评估。

5.2.6. 问题报告/测试日志

测试活动可以输入到测试日志中，以标识何时进行测试、谁执行了测试、使用了什么软件配置以及其他相关标识信息。意外或不正确的测试结果可以记录在问题报告系统中，这些数据构成了以后调试和修复测试期间被视为失败的问题的基础。此外，未归类为故障的异常情况可以记录在案，以防它们后来证明比最初认为的更严重。测试报告也是变更管理请求过程的输入（参见软件配置管理KA中的软件配置控制）。

5.2.7.缺陷跟踪

可以跟踪和分析缺陷，以确定缺陷是何时引入软件的，创建缺陷的原因（例如，定义不清的需求、不正确的变量声明、内存泄漏、编程语法错误），以及何时可以在软件中首次观察到缺陷。缺陷跟踪信息用于确定软件测试和其他过程的哪些方面需要改进，以及以前的方法有多有效。

6. 软件测试工具

6.1. 测试工具支持

测试需要许多劳动密集型的任务，运行大量的程序执行，并处理大量的信息。适当的工具可以减轻文书工作的负担，减少繁琐的操作，减少出错的可能性。复杂的工具可以支持测试设计和测试用例生成，使其更加有效。

6.1.1. 选择工具

指导管理者和测试人员如何选择对他们的组织和过程最有用的测试工具是一个非常重要的话题，因为工具的选择极大地影响了测试的效率和有效性。工具选择取决于不同的证据，例如开发选择、评估目标、执行设施等等。一般来说，可能没有能够满足特定需求的独特工具，因此一套工具可能是一个合适的选择。

6.2. 工具类别

我们根据可用工具的功能对其进行分类：

• 测试框架（触发、响应）[1*，c3s9]提供了一个受控环境，在该环境中可以启动测试并记录测试输出。为了执行部分程序，提供了触发和响应来分别模拟调用和被调用的模块。
• 测试生成器[1*，c12s11]在生成测试用例时提供帮助。生成可以是随机的、基于路径的、基于模型的或其混合的。
• 捕获/重放工具[1*，c12s11]自动重新执行或重放先前执行的测试，这些测试记录了输入和输出（如屏幕）。
• 预言/文件比较器/断言检查工具[1*，c9s7]有助于确定测试结果是否成功。
• 覆盖率分析仪和仪器仪表[1*，c4]协同工作。覆盖率分析器评估在选定的测试覆盖率标准所要求的所有实体中，程序流图的哪些实体以及有多少实体被执行。多亏了在代码中插入记录探针的程序工具，才能完成分析。
• 跟踪器[1*，c1s7]记录程序执行路径的历史。
• 回归测试工具[1*，c12s16]支持在修改软件部分后重新执行测试套件。它们还可以根据所做的更改帮助选择测试子集。
• 可靠性评估工具[9*，c8]支持测试结果分析和图形可视化，以便根据选定的模型评估可靠性相关措施。

标签：基于,SWEBOK,技术,故障,软件工程,测试,软件,测试用例,软件测试
来源： https://blog.csdn.net/imlichao/article/details/111907628