(转)基于状态图的测试用例设计(state-based testing)

2012-12-17  白云 

最近产品新添加了一个新功能,在测试用例设计上应用到了基于状态图的测试用例测试方法,今天不是很忙,整理下看的资料写出这篇文章,不足的地方请指出。

首先,大概介绍下这个功能(就不详细透露产品信息):当邮件服务器收到一封带有可疑附件的邮件,新功能会把这封邮件隔离到一个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这些状态转换,减少出现之前漏测情况的发生。

基于状态转换图的测试用例设计只是众多测试技术中一种,它也不是适用于所有场景,只有基于特定场景选用特定的测试技术,才能事半功倍。这需要我们不断总结,思考。

--------------------------------------------------------------------------

转自:http://www.cnblogs.com/matt123/archive/2012/10/25/2740043.html






480°/4802 人阅读/0 条评论 发表评论

登录 后发表评论