java - 单元测试实时/并发软件

Question

这个问题在这里已经有了答案:

关闭 10 年前。

Possible Duplicate:
How should I unit test threaded code?

经典的单元测试基本上只是将 x 放入并期望 y 输出，并使该过程自动化。因此，它适用于测试任何不涉及时间的事物。但是，我遇到的大多数重要错误都与时间有关。线程会破坏彼此的数据，或者导致死锁。发生不确定的行为——百万分之一。硬的东西。

对于多线程并发系统的“单元测试”部分有什么有用的吗？这样的测试是如何工作的？是否有必要长时间运行此类测试的主题并以某种巧妙的方式改变环境，以合理地确信它可以正常工作？

Answer 1

这些天我所做的大部分工作都涉及多线程和/或分布式系统。大多数错误都涉及“happens-before”类型错误，其中开发人员假设(错误地)事件 A 总是在事件 B 之前发生。但程序每运行 1000000 次，事件 B 先发生，这会导致不可预测的行为。

此外，实际上并没有任何好的工具来检测计时问题，甚至是由竞争条件引起的数据损坏。 Valgrind 工具包中的 Helgrind 和 drd 等工具非常适用于琐碎的程序，但它们在诊断大型复杂系统时并不是很有用。一方面，他们经常报告误报(尤其是 Helgrind)。另一方面，在 Helgrind/drd 下运行时实际上很难检测到某些错误，因为在 Helgrind 下运行的程序运行速度几乎慢了 1000 倍，而且您经常需要运行一个程序相当长的时间才能重现 比赛条件。此外，由于在 Helgrind 下运行会完全改变程序的时序，因此可能不可能重现某个时序问题。这就是微妙的时间问题。从某种意义上说，他们几乎是海森堡式的，因为更改程序以检测时序问题可能会掩盖原始问题。

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