28、无规范黑盒系统测试充分性评估

omega

于 2025-11-27 00:05:46 发布

阅读量35

点赞数

CC 4.0 BY-SA版权

分类专栏：软件测试前沿探秘文章标签：黑盒测试测试充分性 PAC框架

本文链接：https://blog.youkuaiyun.com/omega/article/details/155286263

软件测试前沿探秘专栏收录该内容

28 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

无规范黑盒系统测试充分性评估

在软件测试中，对于无规范的黑盒系统，评估测试充分性是一项具有挑战性的任务。本文将介绍两种估算测试用例数量的方法，以及如何使用 PAC 框架对测试集进行实证评估。

1. 基于版本空间估算测试用例数量

为了确保从测试集推断出的所有一致假设都在可接受的误差范围内，Haussler 基于版本空间的方法估算了所需测试用例的下限。

版本空间的定义 ：在测试环境中，测试集 D 由输入 x 及其预期输出 c(x) 组成。版本空间定义为：$V_{S_{H,D}} = {h \in H|(\forall \langle x, c(x) \rangle \in D)(h(x) = c(x))}$。
$\epsilon$-耗尽的版本空间 ：如果从 D 构建的所有假设相对于任何分布 D 的误差都低于 $\epsilon$，则称版本空间是 $\epsilon$-耗尽的，即 $(\forall h \in V_{S_{H,D}})error_D(h) < \epsilon$。
测试用例数量的下限 ：假设集合 D 由 m 个独立随机测试用例构成，$V_{S_{H,D}}$ 未达到 $\epsilon$-耗尽的概率小于 $|H|e^{-\epsilon m}$。在 PAC 框架内，该概率应小于或等于 $\delta$，可推导出测试用例数量 m 的下限为：$m \geq \frac{\ln|V_{S_{H,D}}| + \ln(1/\delta)}{\epsilon}$。

所需测试用例数量 m 与 $1/\epsilon$ 呈线性增长，与 $1/\delta$ 呈对数增长，与 $V_{S_{H,D}}$ 的大小呈对数增长。

2. 使用 Vapnik-Chervonenkis 维度界定测试集大小

对于某些系统，可能难以对 $V_{S_{H,D}}$ 的大小施加上限。Haussler 提出了一种替代方法，使用 Vapnik-Chervonenkis 或 VC 维度来界定测试集大小。

VC 维度的定义 ：
- 二分法 ：如果 I 是实例空间 X 的某个子集，假设 h $\in$ H 通过将 I 划分为属于 h 和不属于 h 的示例，在 I 上诱导出一个二分法。$\Pi_H(m)$ 表示 H 可以在任何 m 个实例的集合上诱导出的最大二分法数量。
- 打散：如果 H 能诱导出 I 的所有可能的 $2^I$ 个二分法，则称 H 打散了 I。H 的 VC 维度 $V_C(H)$ 是被 H 打散的 X 的最大子集的基数，即最大的 m 使得 $\Pi_H(m) = 2^m$。
测试用例数量的下限 ：Haussler 证明 $V_{S_{H,D}}$ 未达到 $\epsilon$-耗尽的概率小于 $2\Pi_H(2m)2^{-\epsilon m/2}$，结合 Blumer 等人的结果，可推导出测试用例数量 m 的下限为：$m \geq \frac{4\log_2(2/\delta) + 8V_C(H)\log_2(13/\epsilon)}{\epsilon}$。

Mitchell 指出，这种方法通常比基于版本空间的方法产生更严格的界限。m 与 $1/\delta$ 呈对数增长，与 $1/\epsilon$ 呈对数线性增长。

3. 对有限状态机系统的测试集进行界定

以确定性有限状态机（DFA）为例，说明上述两种技术如何估算测试所需的用例数量。

3.1 通过限制测试用例长度使用版本空间方法

对于 DFA 推断，版本空间可解释为一个格，最具体的元素是前缀树自动机（PTA），最一般的元素是通用 DFA。

PTA 的最大大小 ：如果测试用例的长度限制为 n，字母表的大小为 $\sigma$，则 PTA 的最大大小为 $\sum_{i=0}^{n} \sigma^i$。
版本空间的大小 ：$V_{S_{H,D}}$ 的大小受 PTA 状态集可能的划分数量限制，即最大大小的贝尔数。
测试用例数量的估算 ：假设测试集长度限制为 7，字母表大小为 3，PTA 的最大大小为 3280 个状态，$V_{S_{H,D}}$ 的上限约为 $1.5 * 10^{7722}$。若 $\epsilon = 0.1$，$\delta = 0.1$，则估算的测试用例数量 $m \geq 177,809.8277$。

这个数字是保守的最坏情况估计，实际中可能不需要这么多测试用例。

3.2 通过限制系统状态数量使用 VC 维度方法

对于任意 DFAs，VC 维度是无限的，只有对其最大状态数进行假设才能使其有限。如果最大状态数为 n，则 VC 维度上限为 $n \log_2 n$。

VC 维度的估算 ：假设系统最多包含 300 个状态，则 VC 维度上限为 $300 * \log_2(300) = 2,468.65$。
测试用例数量的估算 ：若 $\epsilon = 0.1$，$\delta = 0.1$，则估算的测试用例数量 $m \geq 1,387,032$。若将 $\epsilon$ 增加到 0.4，结果为 $m \geq 248,012$。

对于 DFAs，如果能限制状态数量，使用 VC 维度方法更好，因为它更容易为更复杂的系统计算估计值，且通常比版本空间方法计算的界限更低。

4. 使用 PAC 框架实证评估测试集

预测测试集大小只是使用 PAC 框架进行测试的好处之一，从实证角度看，该框架同样有价值，可对黑盒系统的测试集充分性进行统计上合理的测量。

4.1 系统、测试生成和模型推断技术的选择

系统描述 ：待测系统模拟 SSH 客户端的行为，用 Erlang 编写。如果输入序列不在规范范围内，系统会抛出“意外输入”异常。
测试用例生成 ：假设有 10 个测试场景的小样本，由于其只覆盖了程序行为的一小部分，需要大量随机生成测试用例。选择随机生成器，最大测试用例长度为 13。
模型推断算法 ：选择 Price 的 EDSM 蓝边状态合并算法进行模型推断，使用 Bernard Lambeau 公开的 Ruby 实现。

4.2 PAC 框架的应用

测试集生成 ：生成两个不相交的测试集 A 和 B，从同一分布中随机抽取，但不重叠。由于时间限制，生成算法运行一小时后终止，A 和 B 各包含 42,410 个测试用例。
模型推断与评估 ：使用测试集 A 的测试用例及其结果推断模型，然后用该模型预测测试集 B 的结果。根据传统的误差定义计算误差，得到测试集 A 的充分性评估为 99.99%。
结果分析 ：进一步分析发现，42,410 个测试用例中，42,397 个为真阴性，5 个为真阳性，5 个为假阳性，3 个为假阴性。随机生成的测试用例可能导致测试用例分布不均匀，从而使误差率有偏差。因此，使用平衡分类率（BCR）来平衡推断模型拒绝假阴性的能力。

综上所述，通过版本空间和 VC 维度方法可以估算测试用例数量，使用 PAC 框架可以对测试集的充分性进行实证评估。在实际应用中，应根据系统的特点选择合适的方法和技术。

无规范黑盒系统测试充分性评估

5. 方法对比与实际应用考量

在实际测试场景中，选择合适的测试用例数量估算方法至关重要。下面将进一步对比版本空间方法和 VC 维度方法，并探讨实际应用中的一些考量因素。

5.1 方法对比

方法	适用场景	计算复杂度	界限特点
版本空间方法	当能够对版本空间 (V_{S_{H,D}}) 的大小进行合理估计时适用，例如可以通过限制测试用例长度来控制版本空间大小	计算 (V_{S_{H,D}}) 的大小可能较为复杂，特别是当状态数或测试用例长度较大时，可能涉及到计算贝尔数等复杂操作	通常计算出的界限相对较宽松，对于复杂系统可能需要大量的测试用例
VC 维度方法	当难以估计版本空间大小，但可以对系统的复杂度（如状态数量）进行限制时适用	计算 VC 维度相对较为直接，只需根据系统的状态数量等参数进行计算	通常计算出的界限更严格，对于复杂系统能更高效地估算测试用例数量

从上述对比可以看出，对于不同类型的系统，两种方法各有优劣。例如，对于状态数量难以确定但可以控制测试用例长度的系统，版本空间方法可能更合适；而对于状态数量可以明确限制的系统，VC 维度方法则更具优势。

5.2 实际应用考量

在实际应用中，除了方法本身的特点外，还需要考虑以下因素：

系统特性 ：不同的系统具有不同的复杂度和行为模式。对于一些简单的系统，可能不需要过于复杂的估算方法；而对于复杂的系统，如具有大量状态和复杂输入输出关系的系统，则需要更精确的估算方法。
资源限制 ：测试过程中通常会受到时间、计算资源等方面的限制。如果计算资源有限，可能无法承受复杂的计算过程；如果时间紧迫，则需要选择能够快速得出估算结果的方法。
测试目标 ：测试的目标不同，对测试充分性的要求也不同。如果测试的目标是发现尽可能多的缺陷，可能需要更多的测试用例；如果测试的目标是验证系统的基本功能，那么可以适当减少测试用例数量。

6. 测试过程流程图

下面是一个使用 PAC 框架进行测试的流程图，展示了整个测试过程的主要步骤：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始]):::startend --> B(选择系统、测试生成和模型推断技术):::process
    B --> C(生成测试集 A 和 B):::process
    C --> D(使用测试集 A 推断模型):::process
    D --> E(使用模型预测测试集 B 的结果):::process
    E --> F{计算误差率}:::decision
    F -->|误差率可接受| G([测试集充分]):::startend
    F -->|误差率不可接受| H(调整测试用例生成策略):::process
    H --> C

从流程图可以看出，整个测试过程是一个循环迭代的过程。如果计算得到的误差率不可接受，需要调整测试用例生成策略，重新生成测试集并进行测试，直到达到可接受的误差率为止。