可靠性测试

可靠性测试

我们认为软件可靠性始终是重要的，但它对于任务关键型、安全关键型和高使用率系统是必不可少的。如您所料，可靠性测试可用于降低可靠性问题的风险。可靠性故障背后的常见问题包括内存泄漏、磁盘碎片和耗尽、间歇性基础设施问题以及超时值低于可行值。

可靠性定义为:"软件产品在规定的时间内或规定的操作次数内，在规定的条件下执行其所需功能的能力"。我们可以通过评估从其他测试中收集的指标来获得一些信息，也可以通过重复执行长测试套件来测试可靠性。现实中，这需要自动化来获得有意义的数据。

成熟度：(1) 组织在流程和工作实践的有效性和效率方面的能力。另请参阅能力成熟度模型集成，测试成熟度模型集成。(2) 软件产品避免因软件缺陷而导致失败的能力。

运营验收测试： 验收测试阶段的运行测试，通常由运营和/或系统管理人员在（模拟）运行环境中进行，重点关注运行方面，如可恢复性、资源行为、可安装性和技术合规性。

运营概况： 组件或系统执行的一系列不同任务的表示，可能基于用户与组件或系统交互时的行为及其发生概率。任务是逻辑的而非物理的，可以在多台机器上执行，也可以在非连续的时间段内执行。

可恢复性测试： 确定软件产品可恢复性的测试过程。

可靠性增长模型： 在对组件或系统进行连续测试期间，由于消除了导致可靠性失效的缺陷，可靠性随时间增长的模型。

可靠性测试： 确定软件产品可靠性的测试过程。

健壮性：组件或系统在无效输入或压力环境条件下能够正确运行的程度。

围绕可靠性这一主题，已经形成了一门精确的数学科学。这涉及到对系统使用模式的研究，有时称为运行曲线。运行曲线通常不仅包括任务集，还包括可能活跃的用户、他们的行为以及某些任务发生的可能性。一种流行的定义将运行概况描述为 "系统使用方式的量化特征"。

运行状况可以帮助分配资源，用于架构设计、开发、测试、性能分析、发布以及软件开发生命周期（SDLC）中可能发生的其他活动。对于可靠性测试，运行状况可以帮助企业了解系统在执行任务时的可靠性，哪些任务最需要可靠性测试，哪些功能最需要测试。

硬件往往会随着时间的推移而磨损；换句话说，通常会发生物理故障，导致硬件失效。而软件则永远不会磨损。随着时间的推移，软件可靠性的局限性几乎总是可以追溯到源于系统需求、设计和实施的缺陷。

硬件随时间变化的可靠性。大多数故障发生在运行的最初几周。如果能在使用初期存活下来，那么电子硬件很有可能会继续工作很长时间--通常会超过被更快、更智能、更先进的设备所取代的时间点。

在测试和调试期间，软件的故障率相对较高；在SDLC期间，故障率将呈下降趋势（我们希望如此！）。然而，硬件在其使用寿命内趋于稳定，而软件则在其使用寿命的早期就开始过时，需要升级。愤世嫉俗的人可能会说，这些升级往往不是必需的，而是软件业推动的，因为如果不升级产品，软件业就赚不到钱。不那么愤世嫉俗的人可能会指出，总有一些功能缺失，需要升级和增强。每次升级都会带来故障高峰（因此降低了可靠性），然后随着时间的推移逐渐消失，直到下一次升级。

虽然有一些加速硬件可靠性测试的技术，即所谓的 "高加速寿命测试"（HALT Highly Accelerated Life Tests），但软件可靠性测试通常需要延长测试时间。如果工作流程非常相似，则可以重复运行一小套预先设定的测试。(测试可以从不同的测试库中随机选择，如果测试之间的变化是可以预测或限制的，这种方法就可行。(例如，可以用这种方法测试电子商务系统。）测试可以使用某种统计模型（称为随机测试）即时生成。例如，电话交换机就是这样测试的，因为被叫号码、呼叫持续时间等的变化非常大。测试数据也可以随机生成，有时是根据模型生成。

此外，还存在用于可靠性测试的标准工具和脚本技术。这种测试几乎都是自动化的；我们从未见过人工可靠性测试的例子，我们认为这只是一种自欺欺人的做法。

给定目标可靠性水平后，我们可以使用可靠性测试和指标作为退出标准。换句话说，我们将继续努力，直到达到足够的稳定可靠性水平。在某些情况下，服务水平协议和合同会规定 "足够 "的含义。

许多企业使用可靠性增长模型来预测系统在未来某个时间的可靠性。当测试过程中发现故障时，开发人员应确定故障的根本原因并进行修复。这些修复工作应能提高可靠性。数学模型可以应用于这种改进，在开发过程的某些步骤中测量给定的可靠性，并推断未来的可靠性应该提高多少。

对于这些增长模型，已经提出了各种不同的数学模型，但这些模型背后的数学知识超出了本书的范围。有些模型比较简单，有些则非常复杂。然而，我们必须指出一点：无论企业选择使用哪种可靠性增长模型，最终都应根据经验数据对其进行调整；否则，结果很可能毫无意义。我们已经看到有很多资源被浪费在了不切实际的模型上，但结果却与现实大相径庭。这意味着，在系统交付生产后，测试团队仍应监控系统的可靠性，并利用这些数据来确定所选可靠性模型的正确性。

在现实世界中，可靠性是一个变化无常的东西。例如，您可能会期望系统在没有变化的情况下运行的时间越长，可靠性就越高。与此相平衡的是，系统运行的时间越长，就会有越多的人尝试以不同的方式来使用它；这可能会导致使用一些以前从未尝试过的功能，从而导致系统失效。

用于衡量可靠性的指标有：缺陷密度（每千行源代码[KLOC]或每个功能点有多少缺陷）。循环复杂度、基本复杂度、模块数量以及某些构造（如GOTOs）的计数都被用于确定复杂度、规模和编程技术与故障数量和分布的相关性。

面向对象开发也有自己的复杂性衡量方法，包括类的数量、每个类的平均方法数量、类的内聚性和类之间的耦合性、继承的深度等等。

我们倾向于在测试过程中开发可靠性测量方法，以便预测系统在真实世界中将如何工作。但现实世界往往比我们的测试环境复杂得多。正如您可能猜到的那样，这意味着会有一大堆问题影响到生产中的可靠性。在测试中，当我们试图预测未来时，我们需要考虑测试的人为因素。我们的测试环境越像生产环境，我们的可靠性增长模型就越有意义。

那么，这一切意味着什么呢？可靠性的精确实际数字可能不如趋势更有意义。我们的故障率是否呈下降趋势（意味着可靠性呈上升趋势）？

4.3.1 成熟度

• 定义

系统避免因软件故障而失效的能力。我们经常在软件开发生命周期中使用这个术语；系统越成熟，就越接近下一个开发阶段。

在成熟度测试中，我们监控软件成熟度，并将其与预期的、统计上有效的目标进行比较。这个目标可以是平均故障间隔时间（MTBF mean time between failures ），平均修复时间（MTTRmean time to repair），或者任何其他以某种间隔或强度来计算故障数量的指标。当然，有故障就有失败。成熟度测试要求所有相关方就哪些故障可计入这些指标达成一致。在成熟度测试过程中，当我们发现错误并进行修复时，我们希望可靠性得到提高。如前所述，许多企业使用可靠性增长模型来监控可靠性的增长。

4.3.1.1 内部成熟度指标

• 故障检测（Fault detection BUG发现率)

与预期相比，在被评审的软件产品中发现了多少缺陷的度量。这个度量是通过计算复查中发现的缺陷数量，并将该数量与静态测试阶段预计发现的数量进行比较来收集的。该指标的计算公式为X = A / B。

其中 A 是实际检测到的 bug 数量（来自评审报告），B 是预计的估计数量。18 如果 X 显著高于或低于 1.0，则说明发生了意外情况，需要进一步调查。

• 故障排除（Fault removal BUG修复率）

衡量在评审期间发现的缺陷有多少在设计和实施阶段被消除（纠正）。该指标的计算公式X = A / B

其中，A是在动态测试前（需求、设计或编码期间）修复的缺陷数量，B是评审期间发现的缺陷数量。结果为0 <= X <=1。数值越接近1越好。如果故障排除值正好为1，则意味着所有检测到的缺陷都已排除。

• 故测试充分性

衡量测试计划覆盖了多少所需的测试用例。要计算该指标，请计算（测试计划中）计划的测试用例数，并将该值与 "获得足够的测试覆盖率 "所需的测试用例数进行比较，计算公式为 X = A / B

其中，A是在测试计划中设计并在评审中确认的测试用例数量，B是所需的测试用例数量。我们在研究究竟是什么决定了所需的测试用例数量，或者究竟如何确定该值时，标准中没有具体的模型。如果没有一个特定的模型来确定达到所需的覆盖率所需的测试用例数，我们认为这个指标是没有用的。毕竟，测试可以来自需求、风险分析、用例、测试人员的经验等几十个不同的地方。如何量化这些呢？Rex的一些客户能够使用大量的、统计上有效的参数模型来预测B，在这种情况下，这个指标是有用的。

在测试用例充分覆盖了需求的情况也是有效的，需要测试用例充分考虑ISO25010，并经开发、测试、产品等认真评审。

4.3.1.2 外部成熟度指标

• 估计潜在故障密度：

衡量系统中有多少缺陷可能在未来出现故障。该指标取决于本章前面所讨论的可靠性增长估计模型。该指标的计算公式如下：X = {abs(A1 - A2)} / B 。

A1是系统中潜在缺陷的预测总数，A2是实际发生故障的总数，B是产品尺寸。要获得潜在缺陷的预测数量，您需要计算在指定试验期内通过测试发现的缺陷数量，然后使用可靠性增长模型预测未来的故障数量。实际发现的故障数量来自事故报告。有趣的是，标准并没有规定如何测量尺寸（B）；只要在可靠性增长模型中使用相同的测量方法，就没有关系。一些企业倾向于KLOC（数千行源代码），而另一些企业则倾向于测量功能点。

实际故障数量很有可能超过估计数量。标准建议重新估算，如果出现这种情况，可以使用不同的可靠性增长模型。该标准还指出，在实际发现故障较少的情况下，不应该仅仅为了使系统看起来更好而估计更多的潜在缺陷。我们相信这种情况永远不会发生！

该标准的一个概念性问题是，它似乎假定缺陷和故障之间存在一一对应的关系。潜在缺陷可能会导致0到N个故障，从而使这种关系失效，并可能使该指标失去意义。然而，可靠性增长模型可能内置了这一概念，允许出现这种可能性。标准建议尝试几种可靠性增长模型，找到最合适的模型。在某些方面，我们认为这就像根据律师说的你想听的话来选择律师一样......

• 测试用例的故障密度

测试期间检测到多少故障的度量。为了计算这一指标，请使用以下公式

X = A1 / A2

其中，A1是在此期间检测到的故障数量，A2是执行的测试用例数量。该指标的理想值取决于测试阶段。早期阶段（单元测试、组件测试和集成测试）的数值越大越好。在测试后期和运行阶段，数量越少越好。只有在整个生命周期内进行监控，并将其视为一种趋势而不是时间快照时，这个指标才真正有意义。尽管ISO 9126-2没有提到这一点，但如果不同测试级别的测试用例之间存在较大差异，测试用例的粒度可能会影响这一指标。一个单元测试用例通常测试一个对象或函数的单个操作，而一个系统测试用例可以轻松地持续几个小时，并在代码中发生成千上万个这样的操作。如果一个组织打算在多个测试级别中使用该指标，他们必须得出一种方法来规范A2的大小。如果仅在每个测试级别中单独使用，而不在不同测试级别之间进行比较，则该指标可能最为有用。该标准确实指出，测试应包括适当的测试用例：正常、特殊和异常测试。

• 故障解决

有多少故障条件得到解决而没有再次发生。该指标的计算公式为X = A1 / A2

其中，A1是试验期间解决且不再发生的故障总数，A2是检测到的故障总数。显然，每个组织都希望该值等于1。然而，在现实生活中，有些故障第一次并没有得到正确解决；故障再次发生的次数越多，该指标就越接近零。标准建议监控该指标的趋势，而不是将其作为时间快照。

• 故障密度

在定义的试用期内发现的故障数量与系统规模的比较。计算公式如下

X = A / B

A是检测到的故障数量，B是系统规模。这是一个最为重要的趋势指标。测试阶段越晚，我们希望该指标越低。在讨论故障密度时必须注意两点。对同一缺陷的重复报告会使结果失真，错误报告也是如此（在这种情况下，并不存在真正的缺陷，而是由测试环境、不良测试用例或其他外部问题导致的故障）。这个指标可以很好地衡量测试用例的有效性。一种不那么友好的观点可能认为，它是对代码首次发布时有多糟糕的一种衡量。

• 故障排除率（Fault removal） 衡量有多少缺陷得到纠正。该指标由两部分组成：一部分是实际发现的缺陷，另一部分是潜在缺陷的估计数量。计算公式为X = A1 / A2，Y = A1 / A3

其中，A1为已纠正缺陷的数量，A2为实际发现缺陷的总数，A3为系统中潜在缺陷的估计总数。实际上，第一个公式是衡量有多少已发现的缺陷没有被消除。如果X的值为1，则表示发现的每一个缺陷都被清除了；X的值越小，则表示系统中残留的缺陷越多。与其他一些指标一样，如果将其视为一种趋势，而不是孤立的时间，那么这种测量就更有意义。

如果Y的估计值大于1，企业可能需要调查软件是否存在特别多的缺陷，或者基于可靠性增长模型的估计是否有误。如果Y明显小于1，企业可能需要调查测试是否不足以发现所有缺陷。请记住，重复的事故报告会影响这一指标。Y越接近1.0，系统中剩余的缺陷就越少（假设可靠性模型是合适的）。

• 平均故障间隔时间（MTBF Mean time between failures）
  衡量软件在运行过程中出现故障的频率。要计算这一指标，需要统计在规定的使用期内发生的故障次数，并计算故障之间的平均间隔时间。并非所有故障都是相同的。例如，拼写错误或轻微渲染故障等小故障不包括在此指标中。只有那些中断系统可用性的故障才会被计算在内。该指标有两种计算方法：X = T1 / A，Y = T2 / A。T1 是总运行时间，T2是系统运行的所有时间间隔的总和。当系统不运行的时间间隔内有相当长的时间时，可使用第二种公式。无论哪种情况，A都是系统运行期间观察到的故障总数。

显然，X或Y的值越大越好。该指标可能需要对故障发生的原因进行更多研究。例如，可能有特定功能出现故障，而其他功能可能运行正常。确定故障类型的分布可能是有价值的，特别是当系统有不同的使用方法时。

• 测试覆盖率（Test coverage）

测试过程中执行了多少测试用例的度量。这个指标要求我们根据......来估计需要多少测试才能获得足够的覆盖率。正如我们前面所提到的，关于到底需要多少测试才能获得 "足够的覆盖率"，以及这些测试到底来自哪里，标准并不明确。该指标的计算公式如下：X = A / B

A是实际执行的测试用例数，B是根据需求估算的测试用例数，这些测试用例是实现充分覆盖所必需的。该值越接近1越好。

• 测试成熟度（Test maturity）

衡量系统测试情况的标准。用来预测系统在未来测试中的成功率。如前所述，公式X = A / B

其中A是通过的测试用例数，B是根据需求说明文档估计的充分覆盖所需的测试用例数。这里又出现了 "充分覆盖 "这个术语。如果您的组织能够得出合理的值，那么这些度量将非常有用。在这种特殊的情况下，标准对测试的类型提出了一些建议。该标准建议使用实时历史数据进行压力测试，尤其是高峰期的数据。标准还建议使用用户操作场景、峰值压力测试和超载数据输入。该指标越接近1，即与所有应运行的测试案例相比，通过的测试案例越多越好。

4.3.2 容错性

系统在软件故障情况下保持指定性能水平的能力。当容错内置于软件中时，它通常由额外的代码组成，以避免和/或存活并处理特殊情况。系统表现出容错性的关键程度越高，增加的代码和复杂度也就越高。

讨论容错时可能使用的其他术语包括容错和健壮性。在现实世界中，单一、孤立的故障是不可接受的。毫无疑问，某些故障可能会降低系统的性能，但继续提供服务的能力--即使是在性能降低的情况下--也是需要测试的功能。

负测试通常用于测试容错能力。我们通过测试部分或完全降低系统运行性能，同时测量特定的性能指标。容错性往往在测试的每个阶段进行测试。

在单元测试中，我们应该测试错误和异常处理，包括超出范围、不完整或语义不正确的接口值。在集成测试中，我们应该测试来自用户界面、文件或设备的错误输入。在系统测试中，我们可能会测试来自操作系统、互操作系统、设备和/或用户输入的错误输入。有价值的测试技术包括无效边界测试、探索性测试、状态转换测试（特别是寻找无效转换）和攻击。

故障模式（Fault Pattern）定义: "对造成危害的可识别计算系列的概括描述 "。这些故障模式具有正式定义的特征，并可在代码中完全定义。其理论依据是，如果我们能够定义某一领域中造成危害的计算的共同特征，我们就可以将这些特征用作词汇表，帮助我们以自动化的方式找到故障模式实例，从而将其删除。网站CWE(https://cwe.mitre.org/)，该网站的创建是为了对已发现的多种故障模式进行分类。CWE是Common Weakness Enumeration的缩写，其宗旨如下：

CWE在国际范围内免费供公众使用，它提供了一套统一的、可测量的软件缺陷，使人们能够更有效地讨论、描述、选择和使用软件安全工具和服务，从而发现源代码和操作系统中的这些缺陷，并更好地理解和管理与架构和设计相关的软件缺陷。

每种故障模式都有完整的描述和定义，并包含以下信息，以便开发人员在代码中发现故障模式时进行识别和清除。

• 完整描述
• 何时引入
• 适用平台
• 常见后果
• 检测方法
• 代码示例
• 潜在的缓解措施
• 与其他模式的关系

4.3.2.1 内部容错指标

• 避免故障(Failure avoidance) 衡量有多少故障模式得到控制，避免了关键和严重故障。要计算该指标，请计算避免的故障模式数量，并将其与需要考虑的故障模式数量进行比较，计算公式为X = A / B。

其中，A为设计和代码中明确避免的故障模式数量，B为需要考虑的故障模式数量。该标准并未定义应考虑的故障模式数量从何而来。我们认为，他们的假设是，每个组织将确定他们所关注的故障模式，并将该列表提供给开发人员和测试人员，或许可以使用CWE这样的网站。

• 避免错误操作（Incorrect operation avoidance）

衡量有多少功能是通过特定设计或代码实现的，以防止系统发生错误操作。与故障避免一样，我们计算为避免或防止关键和严重故障发生而实现的功能数量，并将其与组织定义的不正确操作模式数量进行比较。虽然操作模式一词没有正式定义，但需要避免的不正确操作模式的例子包括接受不正确的数据类型作为参数、不正确的数据输入顺序和不正确的操作顺序。根据给出的示例，操作模式与故障模式非常相似，定义了系统可能被错误使用的具体方式。同样，该指标的计算公式为X = A / B。

其中，A是明确设计用于预防的错误操作的数量，B是组织列出的应考虑的数量。标准并没有明确定义什么是关键或严重故障；我们的假设是，每个组织都需要编制自己的清单，也许可以通过挖掘缺陷数据库。

避免的一个例子可能是在处理API调用之前进行前提条件检查，检查每个参数以确保其包含正确的数据类型和允许值。显然，这样一个系统的开发人员必须在安全和性能之间做出权衡。

4.3.2.2 外部容错指标

• 故障避免（Breakdown avoidance）

衡量系统导致整个生产环境崩溃的频率。计算公式为X = 1 - A / B。

其中，A为总故障次数，B为故障次数。企业在计算该指标时可能会遇到的问题是如何准确定义故障。ISO 9126中对故障一词的定义如下： "用户任务的执行暂停，直到系统重新启动或失去控制，直到系统被迫关闭。如果次要故障也包含在计数中，则该指标可能看起来更接近于1，而非实际意义上的1。

理想情况下，系统设计应能够处理内部故障，而不会导致系统完全崩溃；当然，这通常是通过在系统中添加额外的故障检测和修复代码来实现的。当故障发生率较低时，测量故障发生间隔时间（MTBF）可能比这一指标更有意义。

• Failure avoidance

衡量有多少故障模式得到控制，避免了关键和严重故障。举两个例子：超出范围的数据和死锁。请记住，这些指标用于动态测试。为了捕捉这一特殊指标，我们将执行负测试，然后计算系统能够在强制故障中存活下来，而不会陷入临界或严重故障的频率。ISO 9126-2给出的故障影响示例如下：Critical、Serious、Average、Small、None

X = A / B

其中，A 是针对给定故障模式的测试用例避免发生的关键和严重故障的数量，B 是针对故障模式执行的测试用例的数量。数值越接近1越好，表示用户遭受的关键和严重故障越少越好。

• 避免错误操作：

衡量有多少系统功能的实现能够避免错误操作或数据损坏。可能发生的错误操作在这里定义为包括以下内容：

• 参数的数据类型不正确

• 不正确的数据输入顺序

• 不正确的操作顺序

为了计算这个测量值，我们计算了没有导致关键或严重故障的负面测试用例的数量（即负面测试用例通过）与我们为此目的执行的测试用例数量的比较。我们使用的公式为

X = A / B

其中，A为通过的测试用例数（即未发生关键或严重故障），B为运行的总测试用例数。该指标越接近1，越能说明避免了错误操作。当然，该指标应与覆盖率指标相匹配才有意义。例如，如果我们运行了10个测试，并且全部通过，我们的测量值就是1。如果我们运行1,000个测试，999个测试通过，则测量值为0.999。我们认为后一个值更有意义。

4.3.3 可恢复性

定义：在发生故障时重新建立指定性能水平和恢复直接受影响数据的能力。

显然，在测试之前，系统必须具备可恢复性。假设系统具有这种能力，典型的测试包括运行负面测试以导致故障，然后测量系统恢复所需的时间和恢复的水平。根据ISO9126，唯一有意义的测量是系统能够自动恢复。人工干预不算在内。

当软件故障的后果不堪设想，必须绝不允许其发生时，通常会在系统中内置故障切换功能。高可用性是这些情况下经常使用的术语。应测试高可用性工程的三个原则：

• 无单点故障（增加冗余）
• 发生故障时可靠的故障转移
• 当故障发生时立即检测到故障（触发故障转移所需的条件）

如果考虑到这个列表，高可用性确实要求可靠性的所有三个子特性（暂时忽略合规性）都存在（并因此进行测试）。Jamie曾在一家处理自动取款机和信用卡交易的企业担任过一段时间的咨询顾问。该机构就是一个需要高可用性的完美例子。

当有人在自动取款机上刷卡，或者在加油站或杂货店刷卡时，他们不愿意等上几个小时才能接受收费。大多数人只愿意等待几秒钟。当发生故障，卡片处理中断时，不允许交易丢失、遗忘或重复。

公平地说，可恢复系统的魔力并非全部来自软件。在为上述组织工作时，Jamie了解到，高可用性很大程度上来自于特殊的硬件（Tandem计算机）和特殊的操作系统。然而，所有相关的软件都必须具有最高的可靠性，并经过全面的测试，以确保每一笔交易都得到跟踪和执行、完成和记录。

尽管如此，许多可恢复性确实完全或主要来自软件系统。

冗余系统可用于保护处理器组、磁盘或整个系统。当一个项目出现故障时，可恢复性包括自动故障切换到仍在工作的项目，以及自动记录故障，以便系统操作员知道系统正在降级模式下工作。对这种系统的测试包括触发各种故障，以确定系统能够承受多大的破坏而仍能继续工作。

在某些环境下，仅有类似的系统阵列不足以确保可恢复性。如果阵列中的所有项目都是相同的，那么破坏阵列中一部分的故障模式可能也会影响其他部分。因此，一些高可用性系统设计有多个不同的系统。每个系统执行完全相同的任务，但以不同的方式完成。影响其中一个系统的故障模式不太可能影响其他系统。测试这样的系统仍然需要进行故障切换测试，以确保整个系统在故障发生后仍能正常运行。

备份和恢复测试也符合可恢复性测试的定义。这将包括测试物理备份和恢复任务以及实际执行这些任务的流程，并在事后测试数据，以确保恢复的数据是完整和正确的。

许多企业发现，他们确实拥有所有数据的备份。不幸的是，没有人测试过这些数据是否有效。灾难发生后，他们发现，由于没有对数据恢复进行全面测试而节省的资源，与数据恢复不正确所造成的损失相比，简直是微不足道。哎呀

4.3.3.1 内部可恢复性指标

• 可恢复性（Restorability）：
  衡量系统在异常事件或请求发生后恢复正常运行的能力。该指标通过计算设计和/或代码实现的恢复要求的数量，并将其与规范文档中的数量进行比较来计算。例如，如果系统具有重做或撤销操作的功能，则该功能将被视为恢复要求。此外，还包括允许回滚操作的数据库和事务检查点。测量公式同样包括一个比率。

X = A / B

其中A是通过审查确认实施的恢复需求的数量，B是需求或设计文档中要求的数量。该值为0 <= X <= 1。该值越接近1越好。

• 恢复有效性（Restoration effectiveness）

用于衡量修复技术的有效性。请记住，所有这些都是内部指标，预计将来自静态测试。我们通过计算和/或模拟来获得这一指标。这样做的目的是，当要求指定了一个特定的时间目标时，找到预计能满足时间目标的恢复要求（定义见前）的数量。当然，如果要求没有时间目标，那么这个指标就没有意义了。该衡量标准有一个现在很熟悉的公式X = A / B.

其中，A 是满足目标还原时间的已实施还原需求的数量，B 是有指定目标时间的需求的总数。例如，假设需求规格不仅要求具备回滚事务的能力，而且还规定必须在触发后的N毫秒内完成回滚。如果实际实现了这一功能，并且我们计算/模拟它确实能够正常工作，那么指标将等于1/1。如果未实现，则度量值为 0/1。

4.3.3.2 外部可恢复性指标

• 可用性(Availability)

衡量系统在指定时间内的可用性。计算方法是在尽可能类似生产的环境中测试系统，针对所有系统功能进行所有测试，并使用以下公式

X = { To / (To + Tr)}
Y = A1 / A2

其中，To为总运行时间，Tr为系统自我修复（系统无法使用）所需时间。我们只对系统能够自动修复的时间感兴趣；换句话说，我们不测量人工维护时系统不可用的时间。A1是用户在尝试使用软件时能够成功使用的总次数，A2是用户在观察期内尝试使用软件的总次数。

在上述公式中，X为总可用时间（越接近1，系统的可用性越高），Y为用户能够成功使用系统的时间。Y越接近1，可用性越好。

• 平均停机时间(Mean down time)

当系统发生故障时，在系统最终重新启动之前系统不可用的平均时间。如前所述，标准仅关注自动恢复功能时的测量值；当需要人工干预系统以重新启动时，则不使用此指标。要计算这一指标，请在规定的测试期间内测量故障发生后系统不可用的时间，计算公式为X = T / N。

其中，T是系统不可用的总时间，N是观察到的系统故障次数。X越接近零，该指标越好（即不可用时间越短）。

• 平均恢复时间：

衡量故障发生后系统自动恢复所需的平均时间。该指标在指定测试期间进行测量，计算公式为X = Sum(T) / N

其中，T为从所有故障中恢复的总时间，N为系统进入恢复模式的次数。人工维护时间不应包括在内。对于该指标而言，显然越小越好。该指标可能需要细化，以区分不同类型的恢复。例如，恢复被破坏的数据库所需的时间可能比恢复单个事务所需的时间要长得多。将所有不同类型的故障放在同一个度量中可能会造成误导。

• 可重启性

衡量系统在目标时间内恢复并重新向用户提供服务的频率。如前所述，该指标仅涉及自动恢复（不需要人工干预）。目标时间段可能来自需求（例如，指定的服务级别协议）。为计算该指标，我们计算测试期间系统因故障而必须重启的次数，以及其中有多少次重启发生在目标时间内。我们使用的公式是X = A / B

其中，A是在目标时间内执行的重启次数，B是发生的重启总次数。该测量值越接近1越好。该标准指出，由于不同类型的故障所需的恢复时间长度可能完全不同，因此我们可能需要对这一指标进行细化。

• 可恢复性

衡量系统在异常事件或请求发生后恢复正常运行的能力。在这种情况下，我们只对规范中定义的恢复感兴趣。例如，规范可能会定义系统包含恢复某些操作的能力，包括数据库检查点、事务检查点、重做功能、撤销功能等。本指标不涉及规范中未定义的其他还原操作。该指标的计算公式为X = A / B

其中A是成功修复的数量，B是根据规范测试的修复案例数量。和以前一样，数值越接近1越好，表明修复效果越好。

• 修复有效性： 用于衡量系统修复能力的有效性。该指标使用现在熟悉的公式计算：
  X = A / B

A是在目标时间内成功完成修复的次数，B是在要求的修复时间内完成的修复案例总数。数值越接近1，表明修复效果越好。同样，目标时间可能在要求或服务级别协议中定义。

参考资料

• 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
• 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
• python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md

4.3.4 合规性

4.3.4.1 内部合规性指标

可靠性合规性： 衡量系统在可靠性方面是否符合用户组织的内部标准、约定或规定。该指标的计算公式为X = A / B

A 是通过静态测试确认的符合规定的数量，B 是适用于系统的所有规定、标准和约定的数量。

4.3.4.2 外部合规性指标

• 可靠性合规性

衡量系统对适用法规、标准和约定的默认程度的指标。其测量公式为X = 1 - A / B

其中，A是指定但在测试期间未实施的可靠性符合性项目的数量，B是指定的可靠性符合性项目的总数。ISO 9126-2列出了以下可能存在符合性规范的地方：
产品说明;用户手册;符合性说明;相关标准、约定和规定。

越接近 "1 "越好；"1 "表示完全符合所有项目。

• 还没有人评论，欢迎说说您的想法！