单元测试实时/并发软件

Joo*_*kka 27 c c++ java concurrency unit-testing

可能重复:
我应该如何对线程代码进行单元测试?

经典的单元测试基本上只是将x放入并期望y out,并使该过程自动化.所以测试任何不涉及时间的东西都是有益的.但是,我遇到的大多数非常重要的错误都与时间有关.线程破坏彼此的数据,或导致死锁.不确定的行为发生了 - 一万分之一.硬的东西.

对于多线程并发系统的"单元测试"部分,有什么有用的东西吗?这些测试如何运作?是否有必要长时间运行此类测试的主题并以一种巧妙的方式改变环境,以便合理地确信它能正常工作?

Cha*_*via 12

我目前做的大部分工作都涉及多线程和/或分布式系统.大多数错误涉及"发生在之前"类型错误,其中开发人员(错误地)假定事件A将始终发生在事件B之前.但是,每运行一次程序,事件B首先发生,这会导致不可预测的行为.

此外,没有任何好的工具可以检测时序问题,甚至是竞争条件导致的数据损坏.像Valgrind工具包中的Helgrind和drd这样的工具非常适合于琐碎的程序,但它们在诊断大型复杂系统时并不是很有用.首先,他们经常报告误报(特别是Helgrind).另一方面,在Helgrind/drd下运行时实际检测某些错误很困难,因为在Helgrind下运行的程序运行速度慢了近1000倍,并且您经常需要运行一个程序很长时间才能重现竞争条件.另外,由于在Helgrind下运行完全改变了程序的时序,因此可能无法再现某个时序问题.这是微妙时间问题的问题; 他们几乎是海森堡人,因为改变一个程序以检测时间问题可能会掩盖原始问题.

可悲的事实是,人类仍然没有充分准备好处理复杂的并发软件.不幸的是,没有简单的方法对它进行单元测试.特别是对于分布式系统,您应该使用Lamport的先前发生的图表仔细规划您的程序,以帮助您确定程序中必要的事件顺序.但最终,你无法真正摆脱随机变化输入的暴力单元测试.它还有助于在单元测试期间改变线程上下文切换的频率,例如运行另一个占用CPU周期的后台进程.此外,如果您可以访问群集,则可以并行运行多个单元测试,这可以更快地检测错误并为您节省大量时间.


Jer*_*ner 5

如果你可以在Linux下运行你的测试,valgrind包含一个名为helgrind的工具,它声称可以检测使用pthreads的程序中的竞争条件和潜在的死锁; 您可能会从运行多线程代码中获得一些好处,因为它会报告潜在错误,即使它们实际上并未在特定测试运行中发生.