用例和测试用例有不同的起源，并服务于尽管相关但却不同的目的，所以从用例到测试用例并不简单，但还是有合理的步骤，首先我们定义一下场景的概念：场景：或用例的一个实例，是一个用例的执行，其中特定用例以特定方式执行该用例。场景可能有多个，如下图所示，用户可能走主事件流，也可能走备选事件流 1 和 2，然后异常退出。每个路径都可以是被执行和测试的场景或实例。
既然我们已经定义了用例场景的概念，就可以提出一个四步的过程来完成这个目标。1）第一步：确定用例场景因为用例和场景之间是一对多关系，我们可以把基本流域备选流之间的关系用一个矩阵表达出来，假定已经有上面的用例，可以写出场景矩阵。
注意到我们描述的用例还不是太复杂，就产生了相当数量的场景。在很多情况下，测试人员需要设计一个既认识到测试所有的场景不现实，同时又有足够测试的测试策略。在烤炉策略的时候，首先列出所有的场景是必要的。另外，测试人员也要认识到，并不是所有的场景在原来的用例中都有描述，场景发现的过程要与开发团队交互地进行，这样做有两个原因：A 用例开发是用于实现的，没有百分之百穷尽，其详细程度对测试来说可能不够。B 测试团队的审查过程将通过执行用例创建新的发现场景，有的甚至在设计的时候都没有考虑到，所以就会发生修改设计。这也是我们在生命周期方法中选择迭代模型的原因之一，因为它允许我们有效的计划和管理这个过程。测试团队审查用例并发现漏洞，或者附加备选流程将可能产生更好的系统。2）第第二步：确定测试用例公司的测试过程千差万别，但测试用例都应该包括要实施的测试参数，包含测试的条件和预期的结果。下面的表就是一个公共的格式，使用一个矩阵，表达场景、条件、数据、预期和实际值。
注意，上面的表中一个场景可能产生多个测试用例（见用例 2，3），这是因为一个场景可能会有多种逻辑成分。假定有一个关于自定义照明策略的用例： 户主为一周的每天输入最多 7 种照明序列，系统用一个蜂鸣声确认每个输入。这个简单步骤将产生两个测试用例，如下表所示。
