从用例得到测试用例

　　从用例得到测试用例

　　用例和测试用例有不同的起源，并服务于尽管相关但却不同的目的，所以从用例到测试用例并不简单，但还是有合理的步骤，首先我们定义一下场景的概念：场景：或用例的一个实例，是一个用例的执行，其中特定用例以特定方式执行该用例。场景可能有多个，如下图所示，用户可能走主事件流，也可能走备选事件流 1 和 2，然后异常退出。每个路径都可以是被执行和测试的场景或实例。

　　既然我们已经定义了用例场景的概念，就可以提出一个四步的过程来完成这个目标。1)第一步：确定用例场景因为用例和场景之间是一对多关系，我们可以把基本流域备选流之间的关系用一个矩阵表达出来，假定已经有上面的用例，可以写出场景矩阵。

　　注意到我们描述的用例还不是太复杂，就产生了相当数量的场景。在很多情况下，测试人员需要设计一个既认识到测试所有的场景不现实，同时又有足够测试的测试策略。在烤炉策略的时候，首先列出所有的场景是必要的。另外，测试人员也要认识到，并不是所有的场景在原来的用例中都有描述，场景发现的过程要与开发团队交互地进行，这样做有两个原因：A 用例开发是用于实现的，没有百分之百穷尽，其详细程度对测试来说可能不够。B 测试团队的审查过程将通过执行用例创建新的发现场景，有的甚至在设计的时候都没有考虑到，所以就会发生修改设计。这也是我们在生命周期方法中选择迭代模型的原因之一，因为它允许我们有效的计划和管理这个过程。测试团队审查用例并发现漏洞，或者附加备选流程将可能产生更好的系统。2)第第二步：确定测试用例公司的测试过程千差万别，但测试用例都应该包括要实施的测试参数，包含测试的条件和预期的结果。下面的表就是一个公共的格式，使用一个矩阵，表达场景、条件、数据、预期和实际值。

　　注意，上面的表中一个场景可能产生多个测试用例(见用例 2，3)，这是因为一个场景可能会有多种逻辑成分。假定有一个关于自定义照明策略的用例： 户主为一周的每天输入最多 7 种照明序列，系统用一个蜂鸣声确认每个输入。这个简单步骤将产生两个测试用例，如下表所示。

　　此外，这个过程中我们还发现了一个歧义性必须解决：“如果户主想输入多于 7 个，系统将怎样解决?”于是，测试团队和开发团队一起来讨论这件事情，这就是我们迭代发现过程的本质。3)第三步：确定测试条件下一步是在测试用例中确定引发执行这个测试用例的特定条件。也就是考虑一下，什么条件引起用户在一个用例中执行特定事件的序列呢?在这个过程中，测试人员要搜索用户步骤，发现引发特定测试用例的特定数据条件、分支等。每发现一个条件，测试人员都在矩阵中输入一个新的列表示这样的条件。在这个过程中，只要简单的创建一个列，表明对于这个条件将发生哪些状态(有效、无效、不可用)就足够了。A有效(V):为执行基本流，这个条件必须为真。B 无效(I):这个条件将激活备选流，引发特定场景。C不可用(N/A):所确定的条件无法应用于测试用例。我们来看一个简单的“控制灯”的用例，这里有三个改变系统行为的条件要考虑：D按下按钮少于 1秒。E下按钮超过 1秒。 F下按钮超过 1秒后松开。

　　它们将分别触发场景 1，2，3。下面列出这个用例描述。

　　4)第四步：增加数据值完成测试用例我们已经有了很好的进展，现在来确定完全的测试一个用例所需要的所有条件。用例只是对条件、场景、路径的描述，并没有具体的值，所以还需要到补充规范去找到一些有效的数据范围、接口协议等等信息。这恰恰也是利用测试用例解决当初的用例定义的需求的时候了，这也包括把最大/最小性能、最大/最小数据范围、最大/最小负载的定义和自行期间的数据量结合起来。 一旦确定了数据范围，就可以把它填入测试用例的矩阵，如下表所示。

原文转自：http://www.uml.org.cn/Test/200911126.asp