思维成测试??探索式测试实践篇

　　那么QA怎么测试一个程序是否具备了线程的安全性呢？需要通过reviewcode? 显然这是一件很困难的事情，而且效率不一定会高。因为个人感觉多线程的编程本来比一般的编程要难很多，需要注意的细节多很多。既然不能用白盒测试发现问题，那么怎么去测试呢？黑盒？

　　下面是我在多线程测试中的一些探索，结合这个bug的发现过程和大家分享一下。****.so 一个C++ NativeClient ，提供给Nginix **** Process 使用，考虑到这个NativeClient 可以启动多个连接，多个实例，那么对于测试者来说直接把这个 NativeClient 想象成一个黑色的盒子，测试预期是肯定这个“黑盒子“支持多线程。通过在这个NativeClient加上一层多线程的应用场景，通过多线程模式测试“黑盒子”的内部的线程安全性，看是否和QA预期结果一致。测试方案确定，用多线程测试多线程，这需要QA写的多线程自身要具备线程安全性，才能正确达到测试的预期结果。

　　以下是我当时为了测试开发****..so写的一个C++ 多线程的测试程序。下面摘录控制线程的几个主要方法，相信大家都不会陌生。（线程实体不在这里摘录了）

#include "pthread.h"
class Mutex
{
public:
static void pthreadMutexInit(pthread_mutex_t* aMutex_t);
static void pthreadCondInit(pthread_cond_t * aCond_t);
static void pthreadCondWait(pthread_mutex_t * aMutex_t，pthread_cond_t * aCond_t);
static void pthreadCondSignal(pthread_mutex_t * aMutex_t，pthread_cond_t * aCond_t);
static void pthreadCondBroadcast(pthread_cond_t * aCond_t);
}

　　写好测试程序和makefile 文件，在linux 平台编译成了MultThreadTool 进行测试，通过测试发现上述bug， 通过和Dev Review Code 发现由于回调线程与发送线程(网络线程)在request timeout Condition 重复多次调用了removeClinetTransaction 对象导致了crush。

　　接下来看一下开发解决方案 ， 把计划定时器， 取消定时器， onTimeout 放到发送线程，instead of 回调线程.。这样做的好处简化回调线程要处理的逻辑，让网络线程处理这些异常的条件，比如刚刚由于TimeOut 导致的 crush问题。通过这种测试方法，测试线程安全会更高效，在提高QA 测试技术的同时，也大程度的提高发现这种线程安全性的肯能性。刚刚讲的只是由于线程安全的一个方面，用同样的方法实际上还测试了线程安全性典型的另一个bug，线程间抢占资源导致的死锁。Bug: A add B as Friend then UpdateB Del A same time Cause Thread Lock together

　　这是个人探索式测试的第一次亲密接触，结合正开展的项目把理论变成了实践。后总结一下 “探索式测试是一种软件测试手段，不是一种具体的软件测试技术，但是它需要多种测试技术手段的支持”希望这篇文章能帮助QA提高日常的工作效率，同时帮助DEV 减少同类型错误的二次发生。