注意，上面的表中一个场景可能产生多个测试用例(见用例 2，3)，这是因为一个场景可能会有多种逻辑成分。假定有一个关于自定义照明策略的用例： 户主为一周的每天输入最多 7 种照明序列，系统用一个蜂鸣声确认每个输入。这个简单步骤将产生两个测试用例，如下表所示。
此外，这个过程中我们还发现了一个歧义性必须解决：“如果户主想输入多于 7 个，系统将怎样解决?”于是，测试团队和开发团队一起来讨论这件事情，这就是我们迭代发现过程的本质。3)第三步：确定测试条件下一步是在测试用例中确定引发执行这个测试用例的特定条件。也就是考虑一下，什么条件引起用户在一个用例中执行特定事件的序列呢?在这个过程中，测试人员要搜索用户步骤，发现引发特定测试用例的特定数据条件、分支等。每发现一个条件，测试人员都在矩阵中输入一个新的列表示这样的条件。在这个过程中，只要简单的创建一个列，表明对于这个条件将发生哪些状态(有效、无效、不可用)就足够了。A有效(V):为执行基本流，这个条件必须为真。B 无效(I):这个条件将激活备选流，引发特定场景。C不可用(N/A):所确定的条件无法应用于测试用例。我们来看一个简单的“控制灯”的用例，这里有三个改变系统行为的条件要考虑：D按下按钮少于 1秒。E下按钮超过 1秒。 F下按钮超过 1秒后松开。
它们将分别触发场景 1，2，3。下面列出这个用例描述。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
