并发类的覆盖驱动测试代码生成( 二 ) 摘要：以往的并发测试技术

2.2 覆盖驱动的测试代码生成现有的技术已经提出了各种交织覆盖标准以帮助从由测试引起的交织空间中选择代表性的交织。交织覆盖标准规定了交织必须满足的一组属性才能被视为测试覆盖要求。这些属性主要是根据特定的故障模型或错误特征得出的。基于交织的要求的示例包括那些构成数据竞赛，覆盖特定位置对或匹配有问题的访问模式的交织，这违反了某种形式的可序列化性。
文章插图
文章插图
图 1 激励示例的源代码
我们的研究问题是要生成能够在给定时间预算内共同实现最高覆盖率的测试。
激励示例挑战 1：通常（在测试之前）静态地得出 RQ 的覆盖范围要求是不可行的。虽然通常针对给定的测试输入来计算交织覆盖标准，但是覆盖指导的测试输入生成需要针对所有可能的测试输入来计算覆盖要求。然而，计算交织覆盖标准的可执行域恰好需要上下文敏感和同步敏感的分析，这对于并行程序来说是机器无法确定的。
文章插图
最近， Steenbuck 和 Fraser 提出了 ConSuite ，这是一种针对并发类的覆盖率指导的测试生成技术。首先，通过根据与部分交织类似的给定参数化交织覆盖，对访问 CUT 字段的字节码指令进行置换，通过上下文无关和同步不敏感的分析得出近似的覆盖要求 RQ 集。与交错覆盖率的计算不同，可以通过跟踪调用序列执行了哪些指令来精确而有效地计算调用序列的结构覆盖率。进行并发测试以确定并发测试所涵盖的覆盖范围要求是否可行并引起故障。
文章插图
文章插图
图 2 并行测试示例
文章插图
其次，忽略上下文敏感度也可能导致无法触发错误的交错，即使它们被测试覆盖也是如此。因此，在生成并发测试时，我们需要考虑同步的上下文。
方法AutoConTest 是一个由三个主要组件组成的迭代过程（图 3）
文章插图
图 3 第 n 次迭代中的 AutoConTest 过程概述。迭代直到达到时间预算 B
4.1 顺序覆盖本节介绍了有关呼叫序列上下文相关覆盖率度量 M ，称为顺序覆盖。令 E 表示呼叫序列 δ 的轨迹，即由顺序执行（单线程）执行的 δ 显示的事件的有序序列。事件可以是以下之一：
文章插图
文章插图
为了将方法调用 ci∈δ 与 ci 直接或间接调用的方法区别开来，在以下讨论中，我们将 ci 称为最外层方法调用。M（δ）的定义利用了这样的观察，即可以通过忽略 δ 中最外层方法调用的顺序执行顺序来计算覆盖率，而不会影响并发故障检测能力。这是因为线程安全性的一般形式不能保证在同一线程中原子地执行对线程安全类的共享库的多次调用。这些多次调用需要外部同步，以保持原子性。 Pradel 等人通过检查每个捕获的异常是否也可以通过调用的线性化来触发，从而在并发测试中修剪所有此类交错。顺序调用序列执行中忽略最外层方法调用的顺序的优点是，覆盖率 M 可能会更快达到饱和。
4.2 调用顺序生成在每次迭代中，调用序列生成组件都会系统地探索可能的调用序列的空间，并返回一个由 β 表示的，在当前迭代中探索的序列覆盖率最高的序列。此序列将用于组装新的并发测试。由于交织探索的成本随执行长度的增加而增加，因此当组件比较覆盖度提高程度相同的序列时，它会选择最短的序列（以最外面的方法调用的数量来衡量）。更正式地说，让我们在调用序列上定义以下关系。给定两个序列 δ1 和 δ2 ，在改善顺序覆盖率方面， δ1“优于”δ2 ，表示为 δ1?δ2 ，当且仅当 | ?M（δ1）|> | ?M（δ2）|或（| ?M（δ1 ）| = | ?M（δ2）|∧|δ1| <|δ2|）。令 Q 表示组件在给定迭代中探索的调用序列集。
文章插图