场景测试
一个场景就是描述了一个假设情况的故事。在测试上，检查程序如何在这种假设环境下复现。
理想的场景测试是可靠的、有目的的、易于评估的、复杂的。
实际上，许多场景在这些特性中的至少一个上是微弱无力的，但人们依然称之为场景。这种模式的关键信息是当你设计一个场景测试并试图完成它时，你需要紧记这4个特性。
场景测试的一个重要变异是粗糙测试。故事中经常会有一个仅由普通用户使用的序列或数据值。然而，他们会出现在用户错误之外，或异常但似是而非的情形下，或敌对的用户行为下。Hans Buwalda(2000a,2000b)称之为“肥皂杀手”以区别于称之为“肥皂剧”的正常情形。类似的情形在安全测试或其他形式的压力测试下是普遍存在的。
在RUP（Rational Unified Process）中，场景出自使用用例。(Jacobson,Booch, & Rumbaugh,1999)。场景制定了参与者、角色、事务处理、参与者的目标、以及在试图达到目的的过程中发生的事件。场景是使用用例的一个实例化。一个简单的场景追溯了一个独立使用用例的全过程，指定了数据值以及用例中的路径。一个比较复杂的使用用例会首尾串联若干个使用用例，来追踪给定的任务。（参见Bittner & Spence,2003; Cockburn,2000; Collard,1999; Constantine & Lockwood,1999; Wiegers,1999.）警告性注意，请参见Berger(2001).
无论如何他们是继承来的，好的场景测试在第一次运行时具有很大的力度。
不同团队多久执行一个给定的场景测试。
有些团队创建一个类似回归测试的场景测试池。
其他团队（像我）一次或在很短时间内执行一个场景测试，然后设计另外一个场景而不是坚持使用一个以前用过的。
通常，测试人员生成的场景能洞察到产品内部。这在测试初期以及稍后的再一次测试中是非常真实的（当产品已经稳定，测试人员试图了解产品进一步的用途时。）
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51Testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
相关阅读：
