此外，这个过程中我们还发现了一个歧义性必须解决：“如果户主想输入多于 7 个，系统将怎样解决？”于是，测试团队和开发团队一起来讨论这件事情，这就是我们迭代发现过程的本质。3）第三步：确定测试条件下一步是在测试用例中确定引发执行这个测试用例的特定条件。也就是考虑一下，什么条件引起用户在一个用例中执行特定事件的序列呢？在这个过程中，测试人员要搜索用户步骤，发现引发特定测试用例的特定数据条件、分支等。每发现一个条件，测试人员都在矩阵中输入一个新的列表示这样的条件。在这个过程中，只要简单的创建一个列，表明对于这个条件将发生哪些状态（有效、无效、不可用）就足够了。A有效（V）：为执行基本流，这个条件必须为真。B 无效（I）：这个条件将激活备选流，引发特定场景。C不可用（N/A）：所确定的条件无法应用于测试用例。我们来看一个简单的“控制灯”的用例，这里有三个改变系统行为的条件要考虑：D按下按钮少于 1秒。E下按钮超过 1秒。 F下按钮超过 1秒后松开。
它们将分别触发场景 1，2，3。下面列出这个用例描述。
4）第四步：增加数据值完成测试用例我们已经有了很好的进展，现在来确定完全的测试一个用例所需要的所有条件。用例只是对条件、场景、路径的描述，并没有具体的值，所以还需要到补充规范去找到一些有效的数据范围、接口协议等等信息。这恰恰也是利用测试用例解决当初的用例定义的需求的时候了，这也包括把最大/最小性能、最大/最小数据范围、最大/最小负载的定义和自行期间的数据量结合起来。 一旦确定了数据范围，就可以把它填入测试用例的矩阵，如下表所示。
