创建好的情景测试用例的十六种方法
1)写出系统中对象的生存轨迹。对象是如何创建的,它发生了什么,怎么用它怎么修改它,怎么和它交互,什么时候它被毁坏或是移除?
2)列出可能的用户,分析他们的兴趣和目的。
3)考虑一下不利的用户,他们为什么会滥用你的系统?
4)列出系统事件。系统是怎么处理他们的?
5)列出特殊事件。系统是怎么调节这些事情发生的?
6)列出好处点,然后创建点对点流程一项一项去检查。
7)看看用户试图完成的特殊执行,例如关掉一个正在发请求的页面。什么是期望的数据,输出,显示等。
8)那些表单是和用户交互的?针对他们试试增删改查功能。
9)采访客户,了解用户最常遇到的挑战和系统失败的例子。
10)在用户旁边看其操作,看看他们具体是怎么做的。
11)去试试竞争产品,看看相似系统是怎么做的。
12)了解以前做这个产品的人对它的抱怨,或者他的竞争者对它的不满。
13)创建一个假的业务。把它看成是真的,处理数据。
14)试着从一个竞争的应用程序或者前面人用过的系统中转换真实数据。
15)看看竞争程序中的输出。你是如何在你的应用程序中创建这些报告,对象,任何东西的?
16)查看序列:用户(或者系统)依照一定的顺序做一个典型的任务X,为了达到完成任务X的目的, 最常见的子任务的序列是什么?
情景测试的风险
1)其他的测试方法更适合在测试的早期进行,代码不稳定的时候。
<1>一个场景很复杂,将会涉及很多功能。如果第一个功能被破坏了,其他的测试将不能进行。一旦这个功能被修复,后面一个被破坏的功能又会阻碍测试。
<2>在场景测试之前,每个功能模块的测试是分开的,这样一旦他们出现,就可以很有效的暴露问题所在。
2)场景测试并不能用来做程序覆盖测试
<1>它主要关注点通过一系列的用户场景来覆盖所有的功能或者需求。简单的语句覆盖率不能用这种方式达到。
3)重复使用场景可能没有很强的立足点,效率比较低。
<1>归档以及重复使用场景看上去是高效的做法,因为我们在创建一个好的用户场景上花费了很多工作。
<2>场景经常会暴露出设计的缺陷,我们很快可以知道什么是测试对设计的帮助。
<3>情景测试会暴露一些代码错误,因为他们连接了很多功能和很多数据。为了覆盖更多的关联,我们需要创建新的测试。
<4>做回归测试,要用单一的功能测试或者单元测试,而不是情景测试。