使用 ConTest 进行多线程单元测试

发表于:2007-7-16 14:25

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Yarden Nir-Buchbinde    来源:IBM

分享:

使用 ConTest 进行单元测试

        当进行单元测试时需要 JVM 具有低的确定性,同时是更“模糊的”。这就是要用到 ConTest 的地方。如果使用 ConTest 运行几次 清单 2 的 NakedNamePrinter, 将得到各种结果,如清单 4 所示:

 

清单 4. 使用 ConTest 的无修饰的 NamePrinter

>Washington Irving (the expected result)
> WashingtonIrving (the space was printed first)
>Irving
 Washington (surname + new-line printed first)
> Irving
Washington (space, surname, first name)
 


        注意不需要得到像上面那样顺序的结果或相继顺序的结果;您可能在看到后面的两个结果之前先看到几次前面的两个结果。但是很快,您将看到所有的结果。ConTest 使各种交错情况出现;由于随机地选择交错,每次运行同一个测试时都可能产生不同的结果。相比较的是,如果使用 ConTest 运行如 清单 1 所示的 NamePrinter ,您将总是得到预期的结果。在此情况下,同步协议强制以正确的顺序执行,所以 ConTest 只是生成合法的 交错。

        如果您使用 ConTest 运行 PrintQueue,您将得到不同顺序的结果,这些对于单元测试来说可能是可接受的结果。但是运行几次以后,第 24 行的 LinkedList.removeFirst() 会突然抛出 NoSuchElementException 。bug 潜藏在如下的情形中:

        启动了两个 consumer 线程,发现队列是空的,执行 wait()。
        一个 producer 把任务放入队列中并通知两个 consumer。
        一个 consumer 获得锁,运行任务,并把队列清空。然后它释放锁。
        第二个 consumer 获得锁(因为通知了它所以它可以继续向下进行)并试图运行任务,但是现在队列是空的。
        这虽然不是此单元测试的常见交错,但上面的场景是合法的并且在更复杂地使用类的时候可能发生这种情况。使用 ConTest 可以使它在单元测试中发生。(顺便问一下,您知道如何修复 bug 吗?注意:用 notify() 取代 notifyAll() 能解决此情形中的问题,但是在其他情形中将会失败!)

ConTest 的工作方式

        ConTest 背后的基本原理是非常简单的。instrumentation 阶段转换类文件,注入挑选的用来调用 ConTest 运行时函数的位置。在运行时,ConTest 有时试图在这些位置引起上下文转换。 挑选的是线程的相对顺序很可能影响结果的那些位置:进入和退出 synchronized 块的位置、访问共享变量的位置等等。通过调用诸如 yield()sleep() 方法来尝试上下文转换。决定是随机的以便在每次运行时尝试不同的交错。使用试探法试图显示典型的 bug。

        注意 ConTest 不知道实际是否已经显示出 bug -- 它没有预期程序将如何运行的概念。是您,也就是用户应该进行测试并且应该知道哪个测试结果将被认为是正确的以及哪个测试结果表示 bug。ConTest 只是帮助显示出 bug。另一方面,没有错误警报:就 JVM 规则而言所有使用 ConTest 产生的交错都是合法的。

        正如您看到的一样,通过多次运行同一个测试得到了多个值。实际上,我们推荐整个晚上都反复运行它。然后您就可以很自信地认为所有可能的交错都已经执行过了。

ConTest 的特性

        除了它的基本的方法之外,ConTest 在显示并行 bug 方面引入了几个主要特性:

        同步覆盖:在单元测试中极力推荐测量代码覆盖,但是在测试并行程序时使用它,代码覆盖容易产生误导。在前两个例子中,无修饰的 NamePrinter 和多 bug 的 Print Queue,给出的单元测试显示完整的语句覆盖(除了 InterruptedException 处理)没有显示出 bug。 同步覆盖弥补了此缺陷:它测量在 synchronized 块之间存在多少竞争;也就是说,是否它们做了“有意义的”事情,您是否覆盖了有趣的交错。有关附加信息请参见 参考资料 。


        死锁预防: ConTest 可以分析是否以冲突的顺序嵌套地拥有锁,这表明有死锁的危险。此分析是在运行测试后离线地进行。


        调试帮助:ConTest 可以生成一些对并行调试有用的运行时报告:关于锁的状态的报告(哪个线程拥有哪个锁,哪个线程处于等待状态等等),当前的线程的位置的报告和关于最后分配给变量和从变量读取的值的报告。您也可以远程进行这些查询;例如,您可以从不同的机器上查询服务器(运行 ConTest)的状态。另一个对调试有用的特性可能是重放,它试图重复一个给定运行的交错(不能保证,但是有很高的可能性)。


        UDP 网络混乱:ConTest 支持通过 UDP(数据报)套接字进行网络通信的域中的并行混乱的概念。 UDP 程序不能依靠网络的可靠性;分组可能丢失或重新排序,它依靠应用程序处理这些情况。与多线程相似,这带来对测试的挑战:在正常环境中,分组往往是按正确的顺序到达,实际上并没有测试混乱处理功能。ConTest 能够模拟不利的网络状况,因此能够运用此功能并显示它的 bug。

挑战与未来方向

        ConTest 是为 Java 平台创建的。用于 pthread 库的 C/C++ 版本的 ConTest 在 IBM 内部使用,但是不包含 Java 版的所有特性。出于两种原因,用 ConTest 操作 Java 代码比操作 C/C++ 代码简单:同步是 Java 语言的一部分,并且字节码非常容易使用。我们正在开发用于其他库的 ConTest,例如 MPI 库。如果您想要使用 C/C++ 版的ConTest,请与作者联系。硬实时软件对于 ConTest 也是一个问题,因为工具是通过增加延迟而工作。为使用 ConTest,我们正在研究与监视硬实时软件相似的方法,但是在目前我们还不能确定如何克服此问题。

        至于将来的方向,我们正在研究发布一种 监听器 体系结构,它将允许我们在 ConTest 上应用基于监听器的工具。使用监听器体系结构将使创建原子数检查器、死锁侦听器和其他分析器以及尝试不必写入有关的基础设施的新的延迟机制成为可能。

结束语

        ConTest 是用于测试、调试和测量并行程序的范围的工具。它由位于以色列海法市的 IBM Research 实验室的研究人员开发,可以 从 alphaWorks 获得 ConTest 的有限制的试用版。如果您有关于 ConTest 的更多问题,请联系作者。

22/2<12
重磅发布,2022软件测试行业现状调查报告~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海漕溪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2023
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号