1. 场景描述
某邮件系统的黑盒测试。该系统主要由Java语言编写，包含一个主进程、十个邮件发送子线程和完成其他功能的若干子线程。每个邮件发送线程均会定时轮询内存缓存中的邮件队列，若队列不为空，则从中读取一条邮件数据，经过处理后调用邮件服务商的接口完成邮件的发送。
单条邮件数据由一个JSON字符串构成，该字符串包含了所有邮件发送需要的相关信息。邮件发送线程在处理邮件数据前必须先对JSON字符串进行解析才能获取邮件数据的内容。
2. 问题说明
邮件发送线程存在一个缺陷：它没有捕获JSON字符串的解析错误。因此当邮件队列中出现异常数据时（例如一个非JSON格式的字符串），处理这条数据的发送线程将抛出异常并自动退出。由于邮件系统并未建立监控和恢复子线程的机制，所以将导致的问题是：如果对系统的异常数据测试次数小于十次，尽管已有部分发送线程死亡，但是系统仍然能维持表层的正常工作，最终使得该缺陷难以被直接发现。
当然，我们可以采用最粗暴的方式，设计大量的异常数据对系统做连续性的破坏测试。但是此类测试存在问题：不能确定测试用例的数量。比如对于更大型的系统来说，它可能会启动更多的线程来处理数据，我们没法取得一个用例量值使得本次测试是100%可靠的，因此我们仍然有必要寻找一个能够确定测试用例数量的方法。
3. 测试方法
在Linux环境下，进程的线程信息是可以被获取的，因此可以通过观察线程数来找到类似的问题。相关的命令如下：
pstree -p [pid]
pstree的功能是将所有进程以树状图形式显示，-p参数则用于指定要查看的进程号。所以可以先使用ps工具找到Java进程的进程号，再使用pstree工具列出此进程的所有线程信息，如下所示：
上图的命令执行结果可能包含了我们在本次测试中不关心的线程，在此也可以使用另一个工具jstack配合grep命令来达到更进一步的目的，如下所示：
