1. 场景描述

某邮件系统的黑盒测试。该系统主要由Java语言编写,包含一个主进程、十个邮件发送子线程和完成其他功能的若干子线程。每个邮件发送线程均会定时轮询内存缓存中的邮件队列,若队列不为空,则从中读取一条邮件数据,经过处理后调用邮件服务商的接口完成邮件的发送。

单条邮件数据由一个JSON字符串构成,该字符串包含了所有邮件发送需要的相关信息。邮件发送线程在处理邮件数据前必须先对JSON字符串进行解析才能获取邮件数据的内容。


2. 问题说明

邮件发送线程存在一个缺陷:它没有捕获JSON字符串的解析错误。因此当邮件队列中出现异常数据时(例如一个非JSON格式的字符串),处理这条数据的发送线程将抛出异常并自动退出。由于邮件系统并未建立监控和恢复子线程的机制,所以将导致的问题是:如果对系统的异常数据测试次数小于十次,尽管已有部分发送线程死亡,但是系统仍然能维持表层的正常工作,最终使得该缺陷难以被直接发现。

当然,我们可以采用最粗暴的方式,设计大量的异常数据对系统做连续性的破坏测试。但是此类测试存在问题:不能确定测试用例的数量。比如对于更大型的系统来说,它可能会启动更多的线程来处理数据,我们没法取得一个用例量值使得本次测试是100%可靠的,因此我们仍然有必要寻找一个能够确定测试用例数量的方法。


3. 测试方法

在Linux环境下,进程的线程信息是可以被获取的,因此可以通过观察线程数来找到类似的问题。相关的命令如下:

pstree -p [pid]

pstree的功能是将所有进程以树状图形式显示,-p参数则用于指定要查看的进程号。所以可以先使用ps工具找到Java进程的进程号,再使用pstree工具列出此进程的所有线程信息,如下所示:

210009467.jpg

上图的命令执行结果可能包含了我们在本次测试中不关心的线程,在此也可以使用另一个工具jstack配合grep命令来达到更进一步的目的,如下所示:

210150404.jpg