场景从用户的角度来描述系统的行为，反映系统的期望运行方式。它是由一系列相关活动组成，它就像一个剧本，是演绎系统未来预期的使用过程。场景可以看作是用户需求的内容，完全站在用户的视角来描述用户与系统的交互，之后的功能需求说明，则是用户需求分解的结果，定义了必须实现的软件功能。

　　针对用户需求内容的测试，我们称之为场景测试；而用户需求分解的结果，也就是功能特征的测试，对应系统功能测试；

　　功能测试主要关注系统提供的功能特征是否满足需求，测试功能的不同处理流程（正常或异常处理）；理论上，一个功能测试用例仅用于测试一个功能，一个功能可能需要多个功能测试用例来覆盖。

　　场景测试关注于不同场景、事务、业务流程等跨功能，仅用到各个功能的一部分处理流程；一个场景测试用例仅测试一个场景、事务或业务流程。场景测试首先在系统测试阶段测试通过，然后在用户确认阶段，由用户执行场景测试来进行产品验收。

　　功能测试是场景测试的先决条件，只有功能测试已经完成并且其发现的问题得到解决，场景测试才可能有效的实施。然而面对庞大的系统，并不能苛求所有的功能测试都完毕之后，才能执行场景测试。实际上，在迭代式开发模型下，测试是以场景为目标进行迭代测试，先测试某个场景上用到的功能是正确可用的，然后确认该场景测试通过，然后再执行下一个场景所用到的功能。如此循环往复，根据场景优先级逐步完成系统测试。

　　全面的系统测试在理论上是不可行的，因为庞大的功能特征使得投入的人时将是个天文数字。而采取以结果为导向的场景测试，将会得到最大的投入产出比。所以说，测试场景的主要价值在于使用用户典型的应用场景，按用户需要的紧急重要程度进行测试，使得测试工作高效。但是，有一个残酷的现实，那就是凡是提供给用户的功能，用户就可能用到，就需要做到全面测试。所以场景的概念实际上是需要延伸到开发阶段的，在开发阶段，可以根据场景优先级开发需要的功能，那些场景用不到的功能就先不做，从而在源头上规避不必要的投入。然而，开发并不是真正的源，真正的源头是需求分析设计。用户的需求，用户的实际应用最有发言权，所以直接与用户沟通的人是最有发言权的，也就是他们可以设计出最高效的场景。需求是直接研究用户需求，研究用户应用场景的人，然后需求建立在研究的基础之上，设计出产品的真实需求来。所以需求最有应用场景的发言权，最应该首先提出来用户典型应用场景，然后再设计出这些场景需要用到的功能特征。所以要做到场景测试，实际上需要从需求开始做起，需求与用户沟通，确认用户的实际场景，然后分析这些场景，并据此设计出产品的解决方案，得到用户使用产品的应用场景，并排列出优先级；然后开发根据场景优先级开发出产品；最后测试根据场景优先级进行测试，并结合软件实际情况，给出拓展场景，给出使用说明，推荐给用户使用。

　　至此，场景测试的探讨告一段落，这也印证了一个概念，那就是工作的高效源自规划，规划越充分，最后实践的越顺利。

版权声明：本文出自ice00snow的51Testing软件测试博客：http://www.51testing.com/?107630

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。