情景测试的16种方法

之前翻译过一篇关于情景测试的文章link，因为现在我所在的项目的测试到了胶着阶段,因此又提及情景测试。所谓胶着，自是因为项目开发到了相对稳定阶段，测试也用很多种方式进了了几次了，如回归测试、全覆盖测试等等，现在进入了效果不明显的阶段。因为开发人员还在修bug，所以测试人员自是不能掉以轻心。但是，这个时候，测试人员效率不高，回归测试的具体执行不一定完全。那么，怎么调动测试人员的积极性，继续测试，又怎么能提高大家的测试效率，而不是一轮轮拿着测试用例浪费时间？

　　我想很多优秀的全局的测试方法可以在这个阶段使用。情景测试自是一个。每每谈及情景测试，就会觉得兴趣盎然，因为这个时候你可以跳出来，看看产品整体，完全从一个使用者的角度去看去想。虽然，测试人员时时都应该抱有全局观，但是在做任务的时候难免顾此失彼。想来，情景测试也可以在项目收尾的时候，让我们从整体上有个把握。

　　下面是我2008年5月曾第一次在组里推广的情景测试方法。情景的定义不是件容易的事情，如果定义的好，会达到很好的测试效果。不但可以找到一些遗漏的功能缺陷，也可提出些可用性方面的改善。以下提到的也许在现实角度不能完全实现，但是多数是可以受益的。这些方法理论是从很多英文资料翻译来的。原本把原文也贴了上来的，但是日志字数过多，被阻止发布。如果有人想要看英文资料，请留言，我会把它整理发到你的邮箱里。

　　理想的情景测试方法应该具备的一些特征

　　1）测试是基于一个用户如何使用程序的场景，其中包括使用人员是如何被鼓励参与到程序的使用当中的。
　　2）场景是具有激发性的。利益相关者可能会给开发人员压力去改变程序。但这些改变恰恰会使测试失败。
　　3）场景是可信的。它不仅仅可能发生在现实世界里，它还要使利益相关者相信像这样的事情会发生。
　　4）场景包含了程序的复杂使用或者一个复杂的环境或者一个负责的数据集。
　　5）测试结果容易被评估。这点是对所有的测试都意义重大，但是它对情景测试尤为重要，因为情景测试用例相对复杂。

　　为什么使用情景测试？

　　1）学习产品
　　2）把测试联系到归档的需求中来
　　3）为了实现想要的好处，使不足暴露出来
　　4）从专家的角度，探索使用程序
　　5）使一个缺陷报告更有说服力
　　6）把一些需求的问题提到表面，这些问题可能引发一些对曾经讨论过的需求的重新讨论（用新的数据）或者还没有被认同的未浮出水面的需求。

　　情景定义

　　设计情景测试像是需求分析，但又不是需求分析。他们依赖于相似的信息但是用法却大不相同。

　　1）需求分析人员试图促成关于要创建的系统的协定。测试人员是开拓一些不同意见去预见系统可能遇到的问题。
　　2）测试人员并不需要一定得到结论或者制定关于产品应该如何工作的建议。他的任务是曝露出一些可信的担心给产品利益相关人。
　　3）测试人员不必要做出产品设计的折中方案。他陈述这些折中方案的推论，尤其是那些意料之外或是相对期望的结果更严重的推论。
　　4）测试人员不必要尊重之前所达成的一致。（当心：坚持强调错误问题的测试人员将失去可信度）
　　5）情景测试的工作不需要穷尽，只是有用。

创建好的情景测试用例的十六种方法

　　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>做回归测试，要用单一的功能测试或者单元测试，而不是情景测试。