ChapterDomainVerification.docVIP

Chapter 15. Domain Verification 我们建造的模型都只是模型的一个应用或一些片段部分。xUML模型建好以后，配上约束和可执行动作，此时仅意味着我们执行这些模型从而确保其产生渴望的行为。 有不同的多种验证方法可以用在模型上。Static verification（静态验证法）是一种核实模型工具。该工具理解xUML语义学，可以核实并确保模型被恰当建造—类有属性，属性有类型和约束，状态有过程，过程动作语言编译准确，等等。 本章重点是动态验证—以模型为背景的实际运行试验，就如测试Java或C程序那样。毕竟，模型是可执行的，所以你已知的绝大多数关于如何编写和运行软件的测试技术都同样有用。 本章看似接近本书的尾声，记住领域验证是个前进的过程，贯穿一个项目的整个过程。就如我们推荐的渐进性的模型开发，我们同样建议不断地测试模型。 本章提供一个理解如何从用例和模型建立测试向量的起点，以及如何自动执行，如何把单元测试连在一起做系统测试。 15.1 Finding Unit Tests for a Single Use Case 与其试图承担整个用例，我们可以一块一块地处理，每次一个活动。每个活动按照以下条件定义：一系列的先决条件，一个单一启动信号和一系列后置条件。 每个用例都可能有几个可能的路径，比如：Add Item to Order，因为一个用例是一系列可能的行为的一个规范。每个路径由系统状态和信号参数值的组合决定，每个潜在用例路径都是一个scenario。 Definition: scenario（脚本）是用来说明行为的特定的动作序列。 （场景）穿越一个用例的特定路径。 场景是我们想执行的每个测试实例的基础，每个场景的实际执行也是一个测试实例。 我们必须为对象建立系统状态，和能区分不同场景的信号参量，才能确定每个测试实例。 决定潜在参与场景的对象时，使用协作图和状态图简略地跟踪场景，并决定什么状态机需要考虑，以及各个状态机的多少不同的实例需要考虑。 在Figure 15.1（Add Item to Order）中, 我们有一个任意的未指定实例Order，一个具有一定现存数量的product，以及（基于场景的）一些选择。这就是一个问题 Figure 15.1. Use Case Add Item to Order 显然，先决条件把选择缩小了。比如说，Add Item to Order有一个先决条件：现有数量必须大于零并且小于库存量。如果没有这个先决条件，那么可能出现几个情况，一个是选择的数量小于零，一个是选择的数量大于库存量，再一个是选择的数量可以得到满足。 总之，任何一个测试值都可以按几个范围划分，如上所示，每个可能的结果导致一个不同的路径，因此导致一个不同的场景。 另一个场景源是相关对象的当前对象。建立状态机实例的初始状态，检查状态图找到满足前置条件的状态。在Figure 15.2的Order中,前置条件The order… is not expired and is not yet checked out，可以被一个确切的状态满足，Adding Selection to Order. Figure 15.2 Order Statechart Diagram (本章中使用了Chapter 10: Communicating Objects的例子，类同如Figure 15.3.) Figure 15.3. Product, Order, and Product Selection Classes 要使测试实例有价值，我们还需要建立预期结果并且核实模型是否呈现了预期的行为。有具体值和期望结果的测试实例的形式表现是一个测试向量（test vector）。 Definition: test vector 是一个系统状态的联合，有起始信号参数值，和一个我们已知的测试是否通过的期望值。 测试向量是自动测试的基础。通过为每个场景指定和注入一个测试向量，并使用效验机执行，我们可以确保每个测试实例按照用例执行，这是一个合法的需求描述方法。 在用例Add Item to Order例子中，有两个系统状态选择： 只有一个相关产品选择 许多相关产品选择 和两个有起始信号参数的选择： 产品还没有被选人Order中 产品已经被选人Order中 因此，有四个不同的场景——产品的不同选择组合。通过为上面描述的用例分配指定值，我们可以概括四个测试向量，如Figure 15.4. Figure 15.4. Four Different Test Vectors for a Single Use Case 为了从系统中得到期望的结果，必须要有前提条件状态。这样的正面测试很重要，但不可能得到完整的测试实例集合