| 最近产品新添加了一个新功能，在测试用例设计上应用到了基于状态图的测试用例测试方法，今天不是很忙，整理下看的资料写出这篇文章，不足的地方请指出。
首先，大概介绍下这个功能(就不详细透露产品信息)：当邮件服务器收到一封带有可疑附件的邮件，新功能会把这封邮件隔离到一个nsf数据库中，然后将这些可疑附件上传到一特定服务器上(类似360，右击选中文件，在沙盒中运行)，在这个特定服务器上会运行几个VM，分析这些可疑文件并给这些文件进行打分，判断是不是Virus，过一段时间，根据SHA值到特定服务器中查询可疑文件的分析结果，一旦拿到这封邮件中所有可疑文件的分析结果，便对这些那些Virus文件采取指定的动作(如，清除，删除，隔离等)，最后释放这封邮件。这交互过程如下图所示：
这篇文章只考虑两台Server间交互方面的测试用例设计，其他方面(如，邮件编码、文件类型大小、和其他功能的交互)先不用管。依据RD的design
doc 和SRS文档，利用xmind列出这一功能的所有测试点，然后写测试用例。我们来看看在思维导图中列出的关于两台server交互方面的测试点：
第一个是正常流程，在备注中给出了正常流程的具体步骤(如我上面所述)。第二个是error
handling，列出了sandbox出错的可能，但没有讲清楚这样的错误发生在什么样的场景下。测试用例也是基于这样的思维导图细化出来的。刚开始我也没察觉出有什么不妥，或则说有漏测的地方。依据这样的测试用例，两轮测试后，理应没有什么大问题了。直到我无意中发现这样两个问题：
问题一：一封邮件中有两个可疑文件，如果一个可疑文件过一段时间拿到了分析结果，但另一个文件一直无法给出分析结果，这时候预先设定的超时等待时间(1小时)到了，预期行为是不会再等待那个文件的结果，直接对拿到结果的文件做动作，然后release邮件。但实际结果是，每过大概半小时左右，就会把超时时间置0，导致的结果是这封邮件永远被hold在nsf中。
问题二：一封邮件中有可疑文件，被隔离到nsf中，然后把可疑文件上传到特定服务器，但这时候server负载过大，无法响应，可疑文件很长时间无法上传完成，这时候关闭服务器，发现处理进程无法退出。
先不管这两个问题是由什么原因造成的，两轮过后，这样的问题依旧没有被发现，说明这一块的测试用例设计还是不完善的。最近在看《探索性测试》这本书，书中“局部探索式测试法”提到了“如何测试软件状态“，我就想尝试着画出两台server间交互的状态图，又找了些关于state-based
test方面的文章看。
设计状态图，需要：
- Models each state a system can exist in
- Models each state transition
- Defines for each state transition(start state、input、output、finish
state)
用状态图来描述系统状态，一个节点代表一种状态。有一个初始状态开始，接收到输入，触发状态转换，到达下一个状态。来看看用visio画的两台server间的状态图：
完成后别忘了请同事review下，看有没有漏掉的点。有了这个状态图，便可以给出switch
coverage图了：
接下来，表格化这些步骤，这里仅列出两个：
显而易见，通过状态图可以很清晰地掌握整个交互过程, 保证cover这些状态转换,减少出现之前漏测情况的发生。
基于状态转换图的测试用例设计只是众多测试技术中一种，它也不是适用于所有场景，只有基于特定场景选用特定的测试技术，才能事半功倍。这需要我们不断总结，思考。 |
