标签: 期望值

通过关注输出和行为验证，了解 FEY （ Full-Expectation-Yet ） 方法如何彻底改变软件测试。通过确保期望值的存在，这种方法 提高 了测试覆盖 度 、可靠性和整体软件质量。深入了解实现 FEY 方法的关键见解、挑战和好处，以释放测试工作的真正潜力。 在软件测试领域， 一个常见的挑战是在测试创建期间 为 每个输入定义期望值。这可能 还是会 导致 测试 不完 整或无效的测试覆盖，导致未检测到的问题从裂缝中溜走。在本文中，我们将探讨导致此 情况 的潜在问题，并介绍解决这些挑战的解决方案。 测试中的典型问题 : 软件 规范 之间的 差距 ：软件规范中不可能明确的描述每一种 每个边 界 情况或场景 ，因此 这些 在测试创建过程中 可能被忽视 。 测试有效性的丧失 ： 随着软件的变化，测试可能会过时并失去其相关性，仅通过视觉检查来确定其准确性 是很 困难 的 。 软件接口的复杂性 ： 软件系统通常有许多接口， 因此 时时刻刻 为 每个输入定义清晰的期望值具有挑战性。 大型 的自动化项目 ： 在大规模的自动化项目中，测试人员可能会忽略没有定义 期望值 的情况或测试 矢量 ，从而导致不完整的测试覆盖。 解决方案 —— 增加一个额外的监控层 为了应对这些挑战，我们建议实现一个额外的监控层，以确保每个接口都有 期望 值。 这是通过为每个接口创建专用变量来实现的，该变量 初始 默认 值 为 “false” 。然后，这个变量会在测试报告中 自动地突出显示。 如果在测试的任何给定点都没有定义期望值，那么测试将自动 失败 。这 让 测试人员能够在每次测试运行后快速识别未定义期望值的场景、输入或情况。 注重测试结果的方法特别适用于 : 安全关键行业 ： 诸如汽车、医疗、航空航天和其他安全关键领域的行业，在这些行业中，正确的行为和软件输出的准确性至关重要。 具有复杂软件的开发团队 ： 开发具有复杂功能、众多接口和复杂计算的软件项目的团队，这些项目需要对输出进行彻底的测试和验证。 测试经理和工程师 ： 通过有效的测试策略负责确保软件质量和 可靠性的专业人员 。这种方法为他们提供了一种系统的方法来监测和验证预期的输出。 质量保证团队 ： QA 团队试图通过结合涵盖输入和输出的综合方法来增强他们的测试过程，从而提高整体测试的覆盖 度 和有效性。 测试自动化专家 ： 测试自动化方面的专家，他们的目标是利用自动化工具和技术来简化和优化测试过程，并特别关注输出和行为验证。 应用该方法的领域 软件输出 / 计算的评估是测试的核心。测试用例是通过还是失败完全取决于期望值，因为这些值定义了软件的预期行为。因此，尽可能全面地描述这些期望值是至关重要的。 为了更好地理解这一事实，这里有一个简短的注解 测试自动化的基本原则 : 一个测试用例必须接受至少一个评估，以被评估为 通过 或失败。如果没有可用的评估，测试用例在 TPT 中被 判定 为 无结果 的 （ Inconclusive ） 。 如果所有的评估都通过了，那么测试用例就被认为是 通过 的 （ P assed ） 。 如果至少有一个评估失败，那么测试用例被认为是失败的 （ Failed ） 。 如果一个测试用例不能被执行，它会被标记为执行错误 （ Execution Errors ） 。 用一个简短的例子说明这种合理逻辑的缺点。 给一个 具有许多输出的测试对象创建一个测试用例。测试用例包含许多测试条件 ( 步骤 ) ，并 在 许多 情景下 ( 高覆盖 度 ) 激励 测试对象。现在的问题是 ： 测试用例只包含与行为无关的相关评估。因此，即使测试的 含量 很低或没有意义，也会被报告为 通过 。 这是非常不利的。但有解决办法。我们称这种方法为 Full-Expectation-Yet 。 简而言之， Full-Expectation-Yet （ FEY ） 方法 是： 为被测系统的每个输出创建一个检查变量。该变量的目的是在任何时候检查测试对象的输出是否存在预期值。 因此，对于每个样本 ( 带有输入数据的测试向量 ) ，测试变量的默认值为 false 。只有当输出存在指定的期望值时， 默认值才会 设置为 true 。 注： 在 TPT 中，评估可以定义为独立于测试数据的自定义实体。评估在测试执行后自动运行。 T PT 将自动执行对变量的求值以生成报告。如果存在没有期望值的时间间隔 ( 样本 ) ，则变量保留默认值 (false) ，并且测试用例失败。在这种情况下，测试对象的期望值是缺失的，它可以由测试人员来补充。 实施 FEY 方法的 3 个步骤 : 步骤 1 - 为测试对象的每个输出创建一个变量 步骤 2 - 定义每个变量， 以值 false 开始 步骤 3 - 在每次评估期望值时设置相应的变量值为 true 结果 由于对于每个输出，变量的初始值为 False ，并且只有在对输出进行测试时才设置为 true ，因此，如果测试对象的 激励 显示了测试中尚未指定的行为，则测试将失败。 为了检查尽可能多的情况，我们建议使用 软件结构 覆盖 度 指标 MC/DC 。 举个 例子 为了展示 FEY 方法的实用性和有效性，让我们 举 一个汽车行业的例子。想象一下，一个开发团队正在为自动驾驶汽车开发高级驾驶辅助系统 (ADAS) 。 通过实现 FEY 方法，团队可以为每个输出创建专用变量，例如碰撞检测、车道偏离警告和自适应巡航控制。通过为每个输出定义明确的期望值，团队可以全面测试这些关键功能的行为和准确性。 这确保了 ADAS 系统的可靠运行，为乘客和其他道路使用者提供了更高的安全性。这些例子突出了 FEY 方法在软件行为至关重要的行业中的实际 优势 和实际应用。 这种有条不紊的方法确保了 ： 测试中会考虑所有情况 / 场景 对于每种情况和每种结果，测试中都有一个期望值 如果测试对象发生变化， 可 确保所有测试的有效性 注： 在当前的 实施 中，输出和测试变量之间没有直接耦合。因此，必须在审查过程中 检查是否使用错误。 需要什么来实现 ? 您所需要的只是一个具有以下功能的自动化测试 ： 代码覆盖 度 的度量 ( 至少 是 决策覆盖 度 ， MC/DC 更好 ) 测试 数据期望值 的 独立定义 离散时间评估 ( 每个 步长 至少一次评估 ) 每次测试运行的整体评估 逐步实现 FEY 方法 ( 使用 TPT) —— 参考灯控的例子 连接被测系统 创建评估行为的评估 创建测试数据 ( 最好 是 基于需求 ) 实现监控层 记录测试对象的接口 为每个输出创建检查变量 通过检查变量扩展评估 运行测试并检查覆盖 度 ( 决策 或 使用 T PT 的模块 TASMO ，您可以通过代码 激活 所有路径和条件 自动生成测试数据 。 添加测试数据以实现 100% 的代码覆盖 度 如果检查变量显示某些测试数据没有定义期望值，则创建额外的评估。 FEY 方法的优缺点 FEY 方法的优势 确保测试的有效性 ( 对于每种情况，对测试项目都有明确的期望 ) 通过检测规范差距 并 结合覆盖 度 测量 来提高安全性，例如，对于具有大量 变化场景 的驾驶员辅助功能 非常简单易懂的实现 易于验证的审查 这种方法是兼容的，并且很好地补充了确保测试用例和需求可追溯性的方法 FEY 方法的弱点 如果实现被误用 ( 通过审查实现进行保护 ) ，其重要性就会降低。 未能发现相互矛盾的需求，例如，对于相同的情况，对于相同的结果，存在多个期望值 ( 通过一般测试方法来保证 —— 对于相同的测试向量，不同的期望值导致至少一次评估失败 ) 如果代码的行为受到参数的影响，则不考虑参数化 ( 通过多参数执行来保证 ) 总结 在本文中，我们探讨了与在软件测试中定义期望值相关的挑战，并介绍了一种称为 Full-Expectation-Yet (FEY) 方法的解决方案。测试的核心在于评估软件的输出和计算，而期望值的存在对于决定测试用例的 通过 或失败至关重要。 FEY 方法通过增加一个额外的监控层来解决传统测试方法的缺点。它涉及到为被测系统的每个输出创建专用变量，初始化为默认值 “false” 。然后在测试执行期间评估这些变量，如果没有定义预期的值，测试用例就会失败。这种方法确保在测试中涵盖所有情况和结果，从而提供了一种系统的方法来监测和验证预期的输出。 FEY 方法特别适用于具有安全关键开发的行业、从事复杂软件项目的开发团队、负责确保质量的测试经理和工程师，以及寻求增强其测试过程的质量保证团队。通过关注输出和行为验证，这种方法提高了整体的测试覆盖 度 、有效性和可靠性。 虽然 FEY 方法提供了几个优点，例如确保测试有效性和检测规范差距，但它也有缺点。实现的误用、检测矛盾需求的失败以及对参数化的有限考虑是需要解决的一些挑战。 通过实现 FEY 方法，软件测试可以发生革命性的变化，导致更全面和有效的测试实践，从而有助于提高软件质量和可靠性。 而 T PT 就是能使用 FEY 方法进行软件测试的嵌入式软件模型动态测试工具，如果您正苦于测试效率不高、测试过程冗杂的烦恼，欢迎 联系北汇信息 获取 T PT 试用，助力测试效率的提升。