情景测试的16种方法

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

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

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

 

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

·         测试是基于一个用户如何使用程序的场景，其中包括使用人员是如何被鼓励参与到程序的使用当中的。

·         场景是具有激发性的。利益相关者可能会给开发人员压力去改变程序。但这些改变恰恰会使测试失败。

·         场景是可信的。它不仅仅可能发生在现实世界里，它还要使利益相关者相信像这样的事情会发生。

·         场景包含了程序的复杂使用或者一个复杂的环境或者一个负责的数据集。