虽然车轮图测试分析法可以快速全面地进行测试设计，但是这种测试设计从系统内部出发，不会涉及用户如何认识和使用这个系统，这就可能导致出现洋洋洒洒设计了很多测试用例，但是到用户现场才发现用户根本就不是这样用的窘况。
要解决这个问题，就需要基于场景对被测系统进行分析，基于场景对测试进行分析和设计。
场景指用户会使用这个系统来完成预定目标的所有情况的集合。
场景本身也代表了用户的需求，所以可以认为场景是需求的一种描述形式。和从质量属性的角度去描述需求不同，场景是从使用者的角度去看系统的，主要解决如何使用系统的问题。
Karl E.Wiegers著作《软件需求》（Software Requirements的第二版）中给出一个化学品跟踪管理系统的场景图，该图可以很好地说明用户场景的特点。
《软件需求》中的化学品跟踪管理系统的用例图（场景图，局部）
1）可以分析出与这个系统相关的所有使用者（用户）。
2）可以明确用户会如何使用这个系统（用户的使用习惯）。
3）可以明确用户的关注点是什么。
在场景里，完全是从用户角度去理解系统的，从而可以挖掘出用户的隐含需求。如果不是站在化学品仓库保管人员的角度去看这个系统，就不会发现功能点“查看厂商的产品目录”和“请求一种化学品”之间有内在关系。
对一个用户来说，其和系统的功能点交互，通过操作步骤和系统的反馈一步步完成的。把那些与最核心、最直接的功能对应的步骤称为主步骤，对应的场景称为主要场景；与分支条件对应的是从步骤，对应场景为次要场景。下图总结了主要场景、次要场景和主步骤、从步骤之间的关系。
主要场景和次要场景示意图
主要场景和次要场景可以对应一个功能点，也可以对应不同功能点，两个功能点之间通过“分支条件”来连接。在这种情况中，显然分支条件等同于次要场景的前置条件，这暗示着，场景可以串联，形成一个更大、更复杂的场景。
串联场景
场景测试是从场景的角度对系统进行测试和验证。从另一个角度来说，场景测试也是一种需求测试。所以场景测试都是黑盒测试，其将系统或者系统功能作为黑盒，不会关注系统实现细节，主要关注用户的使用习惯和用户的关注点。
摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》
网友评论