单元测试实时/并发软件

Question

经典的单元测试基本上只是将x放入并期望y放入，并使该过程自动化。因此，这对于测试 不涉及时间的
任何事物都是有益的。但是，然后，我遇到的大多数不重要的错误都与计时有关。线程破坏彼此的数据，或导致死锁。不确定性行为的发生率高达百万分之一。辛苦的东西。

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

Answer 1

我最近做的大部分工作都涉及多线程和/或分布式系统。大多数错误涉及“先于发生”类型的错误，在这种错误中，开发人员 假设
（错误地）事件A总是在事件B之前发生。但是，每运行1000000次程序，事件B就会首先发生，这会导致不可预测的行为。

此外，实际上并没有任何好的工具可以检测时序问题，甚至可以检测出由于竞争状况而导致的数据损坏。Valgrind工具箱中的Helgrind和drd之类的工具非常适合琐碎的程序，但在诊断大型复杂系统中不是很有用。一方面，他们非常频繁地报告误报（尤其是海格朗德）。另一方面，仅在Helgrind下运行的程序运行速度慢了将近1000倍，并且实际上经常需要运行相当长的时间才能
重现 竞争条件，因此在Helgrind / drd下运行时实际上很难检测到某些错误。此外，由于在Helgrind下运行会完全改变程序的时间，因此可能
无法实现 重现某个定时问题。这就是定时问题的问题。从某种意义上说，它们几乎是海森堡式的，因为更改程序以检测时序问题可能会掩盖原始问题。

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