16、软件测试与实时系统设计方法解析
软件测试与实时系统设计方法解析
1. 因果图测试用例设计方法
因果图是一种可用于功能测试范围内的测试用例设计方法，它能系统地选择一组测试用例，这些测试用例有很高的概率检测出系统中存在的错误。该技术在开发测试用例时，会探索系统的输入以及输入的组合（即原因）。
1.1 因果图的基本概念
- 布尔图表示 ：使用布尔图来表示从输入到输出的链接。布尔图是一种形式逻辑模型，使用有限的符号集来表示逻辑运算符，如“与（and）”、“或（or）”、“与非（nand）”、“异或（xor）”和“非（not，即否定）”。
- 节点与链接含义 ：因果图中的节点代表原因和结果，链接代表因果转换或原因的逻辑组合。原因和结果可以链式连接，因此中间结果也可以代表中间原因。
- 主要节点类型 ：需要区分主要原因节点（那些不是其他原因结果的节点）和主要结果节点（那些不是其他结果原因的节点），这两种类型的节点都是隐式可观察的。其他节点称为中间结果，通常主要原因节点显示在图的左侧，主要结果节点显示在图的右侧。
- 约束标注 ：图中会标注一些约束，用于描述由于语法或环境问题而不可能出现的主要原因组合。
1.2 从因果图生成测试用例的步骤
- 分析用例和场景 ：仔细分析每个用例及其场景，以确定规范中的所有主要原因和结果。原因是一个独特的输入条件，结果是一个输出条件或系统状态的可观察变化，错误消息应被视为结果。
- 分配唯一标识 ：为每个原因和结果分配一个唯一的标识号。
- 构建布尔图 ：分析每个用例的语义内容及其场景规范，并将其转换为连接原因和结果的布尔图，这就是对所分析用例进行建模的因果图。
- 追溯原因组合 ：对于每个结果，通过图回溯找到所有会使该结果为真的原因组合，每个这样的组合在决策表中表示为一列。
- 生成测试用例 ：将决策表中的列转换为验收测试用例。
1.3 示例说明
以下为因果图的构建和测试用例生成的流程：
graph LR
A[分析用例和场景] --> B[分配唯一标识]
B --> C[构建布尔图]
C --> D[追溯原因组合]
D --> E[生成测试用例]
2. 金融单位管理（FUM）应用的验收测试
2.1 FUM 应用概述
金融单位管理（FUM）应用程序提供更新和查询与银行组织单位相关信息的服务。银行被划分为执行不同活动的金融单位，如销售金融产品、客户服务、支持服务等。一个典型的金融单位是分行，例如马德里储蓄银行在西班牙各地有超过 1500 家分行。
新单位创建后，在宣布其可运行之前，需要完成以下步骤：
1. 识别单位（名称和唯一识别码）
2. 分配单位站点
3. 人员分配
4. 办公室硬件安装
5. 法律放行确认
6. 会计放行确认
7. 确认金融单位相对于计算系统的运行状态
该应用使用 OMT 面向对象方法开发，用 Java 编码，并使用消息传递中间件将客户端机器连接到主机集中式数据库。设计和开发了以下元素：4 个用例、23 个业务类、53 个设计类和 12 个持久化类。
2.2 FUM 用例分析
以“创建金融单位（Create FU）”用例为例，其文档使用以下模板：
- 用例名称 ：Create FU
- 用例 ID ：UC1
- 类型 ：实际
- 主要参与者 ：组织员工
- 次要参与者 ：马德里储蓄银行员工（人事员工、会计员工、房地产员工、系统员工）
- 与其他用例的关系 ：不适用
- 描述 ：组织部门的用户启动此用例，以创建银行的新金融单位并建立其与其他单位的关系。
UC1 创建金融单位用例包含 7 个场景（独立执行路径），以人员分配场景为例：
- 名称 ：人员分配
- ID ：E1 - 3
- 前置条件 ：单位必须已识别，要分配人员的单位站点已创建。
- 描述 ：
1. 用户输入要分配人员的员工编号。
2. 系统检查员工是否已存在。
3. 用户输入该员工与该单位相关的工作分配（百分比）。
4. 系统以列表形式显示现有单位站点。
5. 用户选择单位站点。
6. 用户可以根据需要分配尽可能多的员工。
- 注意事项 ：工作代表在马德里储蓄银行组织中扮演的重要角色。
2.3 验收测试输出
2.3.1 识别的原因和结果
对于完整的 UC1 用例（包括其 7 个场景），识别出的原因和结果如下表所示：
| 原因 | 结果 |
| — | — |
| 1. 输入金融单位代码 | 100. 正确部分放行 |
| 2. 从代码列表中选择金融单位代码 | 101. 正确完全放行 |
| 3. 输入金融单位描述 | 102. 错误的 FU 代码 |
| 4. 从站点列表中选择站点 | 103. FU 描述中的错误 |
| 5. 输入员工描述 | 104. 错误的员工标识符 |
| 6. 确认法律放行 | 105. 错误的交互序列 |
| 7. 确认会计状态 | |
| 8. 确认相对于计算系统的运行状态 | |
| 9. 确认办公室硬件安装 | |
2.3.2 因果图
用例 1 被转换为一个布尔逻辑图，代表原因之间的约束和因果序列，使用了如“与（and）”、“或（or）”、“非（not）”等逻辑运算符以及“E（原因排除）”等约束。
2.3.3 决策表
通过确定因果图中哪些输入条件会导致每个已识别的输出条件，得到决策表，表中的每一列代表一个独立的测试用例。
| 原因/测试用例 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| — | — | — | — | — | — | — | — | — | — | — | — | — | — |
| 1. 输入金融单位代码 | F | T | T | - | - | F | F | F | F | F | F | F | T |
| 2. 从代码列表中选择金融单位代码 | – | – | – | T | T | T | F | F | F | F | F | F | – |
| 3. 输入金融单位描述 | – | F | T | – | – | – | – | – | – | – | – | – | T |
| 4. 从站点列表中选择站点 | – | – | – | T | – | – | T | – | – | – | – | – | T |
| 5. 输入员工描述 | – | – | – | – | F | T | – | T | – | – | – | – | T |
| 6. 确认法律放行 | – | – | – | – | – | – | – | – | T | – | – | – | T |
| 7. 确认会计状态 | – | – | – | – | – | – | – | – | – | T | – | – | T |
| 8. 确认相对于计算系统的运行状态 | – | – | – | – | – | – | – | – | – | – | T | – | T |
| 9. 确认办公室硬件安装 | – | – | – | – | – | – | – | – | – | – | – | T | T |
| 100. 正确部分放行 | F | F | T | T | F | T | F | F | F | F | F | F | F |
| 101. 正确完全放行 | F | F | F | F | F | F | F | F | F | F | F | F | T |
| 102. 错误的金融单位代码 | T | F | F | F | F | F | F | F | F | F | F | F | F |
| 103. 金融单位信息错误 | F | T | F | F | F | F | F | F | F | F | F | F | F |
| 104. 错误的员工标识符 | F | F | F | F | T | F | F | F | F | F | F | F | F |
| 105. 错误的序列 | F | F | F | F | F | F | T | T | T | T | T | T | F |
2.4 测试结果与总结
验收测试成功检测到了隐藏的错误，检测到并修复了与设计类相关的两个错误，并运行了回归测试以验证代码修改。以下是 FUM 因果测试的相关数据：
| 用例 | 原因数量 | 结果数量 | 中间节点数量 | 测试用例数量 |
| — | — | — | — | — |
| UC1 | 9 | 6 | 4 | 13 |
| UC2 | 4 | 4 | 1 | 5 |
| UC3 | 7 | 4 | 2 | 7 |
| UC4 | 6 | 2 | 2 | 6 |
验收测试工作耗时两个月，全部手动完成，使用了屏幕捕获和回复测试工具来生成测试脚本以进行回归测试。
3. 实时系统设计的组件化方法
3.1 实时系统设计面临的问题
使用形式化方法进行实时系统设计可以对已完成的规范进行分析和验证，但由于其复杂性，在工业开发中应用受限，导致实际用户（工业界）的实际需求与科学界之间存在差距。
3.2 组件化设计的优势
基于组件的设计作为一种设计技术，可以降低软件开发的复杂性和验证过程。在实时系统设计中，面向对象设计已证明其有效性，使用预定义组件可以显著改进并减少设计、实现和验证阶段。
3.3 实时系统设计环境
提出了一个从一组特定组件设计实时控制系统的环境，该环境提供图形界面来定义组件级别。每个组件都关联一个高级时间 Petri 网和一个 Ada 代码，它们组合起来构建原型和设计规范。
3.4 设计过程的关键决策
设计新开发环境的过程应考虑以下决策：
1. 选择合适的组件作为高级抽象提供给用户。
2. 选择支持这些抽象的形式化模型。
3. 将单个组件转换为形式化组件。
4. 构建组件和转换的库。
5. 提供一个全局模型来构建完整的规范。
6. 测试规范。
7. 用选定的语言生成原型。
3.5 形式化模型与语言选择
在实时系统开发中，Petri 网被广泛研究并用作指定并发系统的形式化方法，高级定时 Petri 网允许指定具有时间约束的并发系统。而 Ada 被认为是实现实时系统的合适语言。
3.6 组件化设计的流程
从基于预定义组件的架构设计出发，生成基于高级 Petri 网的规范和 Ada 代码，以验证最终实现的某些属性。该方法可与其他设计方法（如 HRT - HOOD）结合使用。以下为组件化设计的流程：
graph LR
A[选择组件] --> B[选择形式化模型]
B --> C[组件转换]
C --> D[构建组件库]
D --> E[构建全局模型]
E --> F[测试规范]
F --> G[生成原型]
综上所述，因果图测试用例设计方法为软件功能测试提供了有效的手段，而组件化设计方法为实时系统设计带来了降低复杂度和提高效率的解决方案。通过这些方法，可以更好地进行软件测试和系统设计，提高软件的质量和可靠性。
4. 因果图测试用例设计方法的优势与挑战
4.1 优势
- 系统性 ：因果图测试用例设计方法能够系统地选择测试用例，通过对输入和输入组合的探索，确保测试用例覆盖了各种可能的情况，从而提高了发现系统错误的概率。
- 避免歧义 ：将用例场景转换为布尔图，避免了文本需求的模糊性和不一致性，使得测试人员能够更准确地理解和执行测试。
- 可扩展性 ：该方法独立于实现语言，并且可以从小型应用扩展到大型应用，具有良好的可扩展性。
4.2 挑战
- 复杂性 ：构建因果图和决策表需要对系统的功能和逻辑有深入的理解，对于复杂的系统，这一过程可能会非常繁琐和耗时。
- 自动化程度低 ：目前该技术尚未完全自动化，虽然将图转换为决策表是一个算法过程，但仍需要人工干预，增加了测试成本。
4.3 应对策略
- 工具支持 ：使用一些支持因果图技术的工具，可以避免手动转换图的繁琐工作，提高测试效率。
- 培训与经验积累 ：测试人员需要接受相关的培训，积累经验，以更好地理解和应用因果图方法。
5. FUM 应用验收测试的经验总结
5.1 测试效果
通过对 FUM 应用的验收测试，成功检测到了隐藏的错误，如与设计类相关的两个错误，并及时进行了修复。这表明基于用例的验收测试能够有效地发现系统中的问题，提高软件的质量。
5.2 测试成本与效率
验收测试工作耗时两个月，全部手动完成，虽然使用了屏幕捕获和回复测试工具来生成测试脚本进行回归测试，但整体测试效率仍有待提高。在未来的测试中，可以考虑引入自动化测试工具，减少人工测试的工作量。
5.3 测试覆盖度
从 FUM 用例的测试结果来看，通过因果图生成的测试用例能够覆盖系统的各种功能和场景，确保了测试的全面性。但在实际测试中，仍需要根据系统的特点和需求，进一步优化测试用例，提高测试覆盖度。
6. 实时系统组件化设计的应用前景
6.1 降低开发成本
组件化设计可以复用预定义的组件，减少了开发过程中的重复工作，降低了开发成本。同时，由于组件的独立性和可替换性，系统的维护和升级也更加方便。
6.2 提高系统可靠性
通过使用高级定时 Petri 网和 Ada 代码进行规范和实现，可以更好地验证系统的行为和性能，提高系统的可靠性和稳定性。
6.3 促进技术融合
组件化设计方法可以与其他设计方法（如 HRT - HOOD）结合使用，促进不同技术的融合，为实时系统设计提供更多的选择和可能性。
6.4 应用领域拓展
实时系统组件化设计方法适用于各种实时控制系统，如工业自动化、航空航天、交通运输等领域。随着技术的不断发展，其应用领域将不断拓展。
7. 对比分析
7.1 因果图测试与传统测试方法
| 测试方法 | 优点 | 缺点 |
|---|---|---|
| 因果图测试 | 系统性强、避免歧义、可扩展性好 | 复杂性高、自动化程度低 |
| 传统测试方法 | 简单易行、成本低 | 覆盖度低、易受主观因素影响 |
7.2 组件化设计与传统设计方法
| 设计方法 | 优点 | 缺点 |
|---|---|---|
| 组件化设计 | 降低复杂度、提高效率、可复用性强 | 需要构建组件库、对设计人员要求高 |
| 传统设计方法 | 灵活性高、适应性强 | 开发周期长、维护成本高 |
8. 总结与展望
8.1 总结
因果图测试用例设计方法和实时系统组件化设计方法分别在软件测试和系统设计领域具有重要的应用价值。因果图测试方法通过将用例场景转换为布尔图，避免了文本需求的歧义，提高了测试的准确性和全面性；组件化设计方法通过复用预定义组件，降低了实时系统开发的复杂度和成本，提高了系统的可靠性和可维护性。
8.2 展望
- 自动化发展 ：未来，因果图测试方法有望实现更高程度的自动化，减少人工干预，提高测试效率。同时，组件化设计也将更加智能化，自动生成组件和规范，进一步降低开发成本。
- 跨领域应用 ：这两种方法将在更多领域得到应用，如人工智能、物联网等，为这些领域的软件测试和系统设计提供有效的解决方案。
- 技术融合创新 ：因果图测试方法和组件化设计方法可能会与其他技术（如机器学习、大数据等）融合，创造出更加高效、智能的软件测试和系统设计方法。