到目前为止,我正在做的是在调试器下运行的应用程序上运行GUI功能自动化,以便我可以摆脱死锁并捕获崩溃,并计划制作边界检查器构建,并针对该版本重复测试.我还通过PC-Lint对源的静态分析,希望找到潜在的死锁,但没有任何有价值的结果.@H_403_3@
应用程序是C,MFC,多个文档/视图,每个文档有多个线程.我使用的锁定机制是基于一个对象,其中包含一个指向CMutex的指针,该指针被锁定在ctor中,并在dtor中释放.我使用这个对象的局部变量根据需要锁定各种代码,而且如果达到超时,我的互斥体有一个超时时间会触发一个警告.我尽可能避免锁定,尽可能使用资源拷贝.@H_403_3@
还会做什么其他的测试？@H_403_3@
编辑：我已经跨越了一些不同的测试和编程论坛的这个问题,因为我很想看看不同的思维方式和学派如何处理这个问题.如果你看到它在其他地方交叉张贴,那么道歉.一个星期左右,我将提供一个摘要链接到答复@H_403_3@
解决方法
>使用law of large numbers,不仅要进行一次,而且要多次执行.
>通过夸大场景来强制测试您的代码.例如.要测试您的互斥体类,请使用互斥体保护代码的场景：@H_403_3@
>是非常短和快(一个指令)
>是耗时(睡眠价值很大)
>包含显式上下文切换(Sleep(0))@H_403_3@
>在各种不同的架构上运行测试. (即使您的软件仅适用于Windows,在具有和不具有超线程的单核和多核处理器以及各种时钟速度下进行测试)>尝试设计您的代码,使其大部分不会暴露于多线程问题.例如.而不是访问共享数据(这需要锁定或非常仔细设计的锁避免技术),让您的工作线程对数据副本进行操作,并使用队列与他们进行通信.那么你只需要测试你的队列类来进行线程安全>当系统空闲以及来自其他任务的负载(例如,我们的构建服务器经常并行运行多个构建)时,运行测试,只显示系统处于负载状态时发生的许多多线程错误.)>避免在超时时断言.如果这样的断言失败,您不知道代码是否断开,超时是否太短.相反,使用非常慷慨的超时(只是为了确保测试最终失败).如果要测试一个操作不需要一段时间,测量持续时间,但不要超时.@H_403_3@
