Testing MT code for correctness is, as already stated, quite a hard problem. In the end it boils down to ensuring that there are no incorrectly synchronised data races in your code. The problem with this is that there are infinitely many possibilities of thread execution (interleavings) over which you do not have much control (be sure to read this article, though). In simple scenarios it might be possible to actually prove correctness by reasoning but this is usually not the case. Especially if you want to avoid/minimize synchronization and not go for the most obvious/easiest synchronization option.

我遵循的一种方法是编写高度并发的测试代码，以使潜在的未检测到的数据竞争有可能发生。然后我运行这些测试一段时间:)我曾经无意中看到一个演讲，一些计算机科学家展示了一个这样做的工具(根据规格随机设计测试，然后疯狂地运行它们，同时检查定义的不变量是否被破坏)。

顺便说一下，我认为测试MT代码的这一方面在这里还没有提到:确定可以随机检查的代码不变量。不幸的是，找到这些不变量也是一个相当困难的问题。此外，它们在执行期间可能不会一直保持，因此您必须找到/强制执行可以期望它们为真的执行点。将代码执行到这样的状态也是一个难题(并且本身可能会引起并发性问题)。呼，这太难了!

一些有趣的链接可供阅读:

确定性交错:允许强制执行某些线程交错，然后检查不变量的框架 jMock Blitzer:压力测试同步 assertConcurrent:压力测试同步的JUnit版本 测试并发代码:简要介绍两种主要方法:蛮力(压力测试)或确定性(使用不变量)

如果你正在测试简单的new Thread(runnable).run() 您可以模拟Thread来按顺序运行可运行对象

例如，如果被测试对象的代码像这样调用一个新线程

Class TestedClass {
    public void doAsychOp() {
       new Thread(new myRunnable()).start();
    }
}

然后模拟new Threads并按顺序运行runable参数会有所帮助

@Mock
private Thread threadMock;

@Test
public void myTest() throws Exception {
    PowerMockito.mockStatic(Thread.class);
    //when new thread is created execute runnable immediately 
    PowerMockito.whenNew(Thread.class).withAnyArguments().then(new Answer<Thread>() {
        @Override
        public Thread answer(InvocationOnMock invocation) throws Throwable {
            // immediately run the runnable
            Runnable runnable = invocation.getArgumentAt(0, Runnable.class);
            if(runnable != null) {
                runnable.run();
            }
            return threadMock;//return a mock so Thread.start() will do nothing         
        }
    }); 
    TestedClass testcls = new TestedClass()
    testcls.doAsychOp(); //will invoke myRunnable.run in current thread
    //.... check expected 
}

看看我的相关答案在

为自定义Barrier设计一个Test类

它偏向于Java，但对选项进行了合理的总结。

总而言之(我认为)，它不是使用一些花哨的框架来确保正确性，而是如何设计你的多线程代码。拆分关注点(并发性和功能性)有助于提高信心。测试引导的面向对象软件的发展比我能更好地解释一些选项。

静态分析和形式化方法(参见并发性:状态模型和Java程序)是一种选择，但我发现它们在商业开发中用处有限。

不要忘记，任何加载/浸泡风格的测试都很少能保证突出问题。

好运！

听着，要做到这一点并不容易。我正在做一个本来就是多线程的项目。事件来自操作系统，我必须并发地处理它们。

处理测试复杂的多线程应用程序代码的最简单方法是:如果它太复杂而无法测试，那么您做错了。如果您有一个单独的实例，其中有多个线程作用于它，并且您无法测试这些线程相互踩在一起的情况，那么您的设计需要重做。它既简单又复杂。

有许多方法可以为多线程编程，以避免线程同时通过实例运行。最简单的方法是使所有对象都是不可变的。当然，这通常是不可能的。因此，您必须在设计中确定线程与同一实例交互的地方，并减少这些地方的数量。通过这样做，您可以隔离多线程实际发生的几个类，从而降低测试系统的总体复杂性。

但是您必须意识到，即使这样做，您仍然不能测试两个线程相互践踏的每一种情况。要做到这一点，您必须在同一个测试中并发地运行两个线程，然后准确地控制它们在任何给定时刻执行的行。你能做的就是模拟这种情况。但这可能需要您专门为测试编写代码，这充其量是迈向真正解决方案的半步。

测试代码是否存在线程问题的最好方法可能是对代码进行静态分析。如果您的线程代码没有遵循有限的线程安全模式集，那么您可能会遇到问题。我相信VS中的代码分析确实包含了一些线程的知识，但可能不多。

看，就目前的情况来看(可能还会持续很长一段时间)，测试多线程应用程序的最佳方法是尽可能降低线程代码的复杂性。最小化线程交互的区域，尽可能地进行测试，并使用代码分析来识别危险区域。

我最近发现了一个叫做Threadsafe的工具(用于Java)。它是一个静态分析工具，很像findbugs，但专门用于发现多线程问题。它不是测试的替代品，但我可以推荐它作为编写可靠的多线程Java的一部分。

它甚至可以捕捉到一些非常微妙的潜在问题，比如类包容、通过并发类访问不安全的对象以及在使用双重检查锁定范式时发现丢失的volatile修饰符。

如果您编写多线程Java，请尝试一下。

等待在帮助您编写确定性单元测试时也很有用。它允许您等待系统中的某个状态更新。例如:

await().untilCall( to(myService).myMethod(), greaterThan(3) );

or

await().atMost(5,SECONDS).until(fieldIn(myObject).ofType(int.class), equalTo(1));

它还支持Scala和Groovy。

await until { something() > 4 } // Scala example