标签: 单元验证

在基础实践 2 中 您 如何定义验证标准 ? 有了基础实践 1 中定义的战略指导方针，您就可以进入下一步了。这个 BP （基础实践） 既适用于静态测试也适用于动态测试。预期的结果是单元的特定测试用例和单元级静态检查的定义。在本文中，我们将讨论基础实践 2-7 本文是 A SPICE 系列文章的第 3 篇 。 点击查看 A SPICE 系列往期内容 ： ASPICE系列：顺利通过ASPICE流程软件单元验证(SWE.4)-面包板社区 (eet-china.com) ASPICE系列：如何定义软件单元验证策略-面包板社区 (eet-china.com) A SPICE 基础实践 基础实践 2: 制定单元验证标准 ASPICE 过程期望定义标准，以确保单元执行软件详细设计和非功能需求中所描述的操作。 所有的工作产品都应该按照软件单元验证策略中的描述进行生产。 例如，应为静态测试定义以下标准 : 静态测量的类型 ( 例如， 圈复杂 度的测量 ) 和成功的评价标准 ( 测量的 圈复杂 度小于 50) 。 符合编码标准 ( 如 MISRA) 符合项目中商定的设计模式 非功能性的技术标准，例如资源消耗 (RAM/ROM) 您可以为所有单元设置单元验证标准，或者专门为 一类 单元或单个单元设置单元验证标准。为了不让工作失去控制，建议 对 一般定义 保持慎重和保守 。 专业提示 ： 覆盖目标 ( 例如代码覆盖 ) 通常不适合作为单元验证标准。它们最好用作测试结束标准，从而确定测试何时可以被认为完成。 对于每个测试规范， 基础实践 6 “ 确保一致性 ” 要求在测试规范和软件详细设计之间进行内容检查。在大多数情况下，这是通过审查等质量保证措施来完成的。此检查的目的是证明测试用例正确地测试了链接需求的内容。明确地期望每个评审都有文档记录。 如果在评估过程中发现缺少或不充分的非功能需求 ( SWE .1) 或缺少或不充分的软件详细设计 ( SWE .3) ， BP2 评估可能会被降级。 换句话说，如果前面的过程没有完成，他们也不会得到一个好的评价。 基本实践 3: 执行软件单元的静态验证 使用基础实践 2 中定义的标准，软件单元的静态验证应该在基础实践 3 中执行。 该验证可以通过以下方式执行： 自动静态代码分析工具 代码审查 ( 例如检查编码标准和指导方针的符合性或正确使用设计模式 ) 成功标准应该使用 BP2 的标准来确定。它们 具体说明 检查是成功还是失败。基础可以是覆盖标准或遵从最大值 (max . 圈复杂 度 最大为 Y) 或最小值 ( min . 每行代码最少 x 行注释 ) 。 基础实践 4: 测试软件单元 使用基础实践 2 中创建的测试规范，软件单元测试将在基础实践 4 中执行。预期测试将按照软件单元验证策略中所描述的方式执行。 对于基础实践 3 和基础实践 4 ，明确要求记录包括结果在内的所有测试。如果出现异常 现象 和 检验发现的情况 ，应将其记录、评估和报告。 此外， B P4 要求 以有意义的方式总结所有数据。在软件单元验证中，通常需要大量的测试数据。测试数据应该在多个详细级别上 为 手动和自动执行验证结果 而 准备。对此的解决方案是一个有意义的总结，例如 通过饼图的 形式聚集所有测试结果。 基础实践 3 和基础实践 4 的评估说明 与软件单元验证策略 (BP1) 相比，验证测试执行的偏差导致 BP3 或 BP4 的贬值。 对于 BP3 和 BP4 ，缺乏有意义的总结 会 导致降级。如果一个测试只被评为通过 / 失败，而没有关于测试的附加信息，那么评估人员对受影响的基础实践的评价不会比 “ Partly ” 更好。自动化软件单元测试报告中对单元的模拟和计算可以被视为对评估的充分补充信息。 评估人员将希望分别看到 BP3 和 BP4 的评估示例。具体地说，他们想要用它来验证一个发现是否符合软件单元验证策略和 SUP.9 问题解决管理。 基础实践 5: 建立双向追溯 在 A SPICE 中有几个地方需要双向追溯。如何实施取决于你自己。在这种情况下，您需要将详细设计的需求与测试用例和静态测试的结果联系起来。测试用例依次链接到详细设计的需求。 在最简单的情况下，这可以通过表格的形式完成 ( 列 = 测试用例 ; 行 = 需求 ) 。这种实现需要大量维护，而且很容易出错。 Pro-Tip: 为此使用 模型动态测试工具 TPT 等工具，尽可能容易地创建链接，最好是自动生成报告。您可以将此跟踪报告 为概述 用于一致性评审 (SWE.4 BP6) 作。在更改请求的情况下，您可以更快地分析 对 测试用例 的依赖性 。 评估人员明确地希望您将测试用例和需求双向地链接起来 (BP5) 。 基础实践 7: 总结和交流结果 所有 单元 验证 结果应汇总并通报相关方。 B P7 明确地期望有证据表明已经报告了结果。所有类型的通信媒体，如信件、邮件、视频、论坛帖子等，都可以作为证据 ( 只要它们有记录并可追溯 ) 。 如果 SWE.4 的 BP 3 和 / 或 BP 4 被评为 “ None ” 或 “ P artly ” ，那么预 计 评估员会对 BP7 降级。 在 BP7 的 ACQ.13 项目要求 过程 中，需要确定相关方及其对信息的需求。 ACQ.13 项目要求过程不作为 A SPICE 评估的一部分进行审查。然而，一个项目不应该仅仅因为过程没有被评估就忽略它，这是一个很好的实践。 总结 A SPICE 要求质量保证的许多活动和结果。许多所需的结果也应该以可验证的方式进行检查。 了解并应用这些评估规则可以增加获得良好评估的可能性。通常，一个项目在 2 年后达到 1 级，在 2 年后达到 2 级。 经验表明，当团队愿意学习并不断工作以满足需求时，成功是最快实现的。

软件验证策略是软件单元验证过程中所有活动的基础，因此也是评估的基础。软件验证策略是基础实践 1 所要求的 : 开发 包括回归策略 在内的 软件单元验证策略。 本文是 A SPICE 系列文章的第 2 部分。 通过链接 查看第 1 部分 ： ASPIC E 系列： 顺利通过 ASPICE 流程软件单元验证 (SWE.4) ASPICE系列：顺利通过ASPICE流程软件单元验证(SWE.4)-面包板社区 (eet-china.com) 对于评估人员来说，单元验证策略必须至少包括以下 10 个方面 : 1. 所有单 元 的定义。定义可以是通用的，也可以是特定的。确保 单元 是唯一可识别的。在最简单的情况下， 可以把一列 函数或文件分类为单元。 您应该能够回答以下问题 ： 如何确保所有单元都包含在函数列表中 ？ 这可以通过 比如 定期检查列表或自动更新列表 等方式 来实现。 2. 定义如何涵盖与验证和测试相关的特定需求。这 包含 功能需求、非功能需求和过程需求。 您应该对整个项目的需求有一个概览。补充对单元验证有影响的信息。这些通常也是来自 A SPICE 、 ISO26262 或其他安全标准、 横断面荷载 手册、法律、利益相关方、 MISRA 等的要求。如果您明确地在验证策略中包含各个需求，并简要地记录您的解决方案以供实现，这将是很有帮助的。 3. 定义测试用例的 开发 方法和来自详细设计和非功能需求的测试数据。 这 需要 你 解释为此使用的方法，例如为所有接口形成等价类，正面和负面测试等等。 如果您有通用的单元定义，您可能也会为此使用通用的定义。如果你对质量管理和功能 安全单元有约束 或 变量 （ constraints/variants） ，那么 就会 期望它们也能显示质量管理和功能安全单元的概述。这一期望同样适用于所有其他变体。因此，通用的单元定义 会 增加测试工作 量 。 为了处理这方面的问题，我们建议预先分析所有的需求，并在此分析的基础上推导出最合适的方法。 4. 定义用于静态验证和评审的方法和工具的方法。 5. 定义 每个 测试环境和使用的每个测试方法 论 。 现成的工具实现方法。参考现有的工具供应商文档以节省时间。 使用掌握尽可能多的方法和技术的工具。节省培训和许可证的项目成本。有了一些可以广泛使用的工具，员工可以更快地重新确定优先级，不再需要熟悉工具。 使用已 有 的方法，例如等价类或限制测试来收集测试数据。 使用能最大限度地减轻重复活动工作量的工具，例如自动生成报告和可追溯性。 尽可能实现自动化 6. 根据项目和发布阶段定义测试覆盖范围。 没有人期望你在第一天就达到 100% 的覆盖率。利用项目的持续时间，并显示可实现的建设曲线。 从人员或其他资源方面得出你为此需要什么。 回顾你的策略，如果有偏差就进行调整。根据流程进行变更 ( SUP. 10 变更请求管理 ) 。 7. 定义 动态单元测试的测试启动条件和测试结束标准。 哪些条件导致哪些活动的开始 有相关序列吗 ? 什么时候终止，什么时候重新开始 ? 他们是怎么得到这个的 ? 他们什么时候停止测试 ? 最好不要使用时间，而是使用技术或可度量的标准 ( 覆盖度量，如何测试所有需求 ) 。说明为什么这些指标是充分的。 8. 如果测试级别是组合的，那么 需要 每个测试级别的充分测试覆盖率的文档。 如果您合并测试级别，您必须证明您如何确定覆盖级别。覆盖可以意味着代码覆盖、接口覆盖和需求覆盖。一个一致的基本原理是，例如，您将测试内容移动到更高的级别，因为您可以在这个级别上更有意义地分配测试用例和需求。 他们通常从标准和其他指导方针中获得覆盖率目标。 ISO 26262 为与安全相关的代码部分的代码覆盖率设定了目标。 ISO 26262 含蓄地 要求高覆盖率，并注明 :“ 无正当理由的 没有目标值或低目标值的结构覆盖率被认为是不 充分 的。 ” 一般来说，最好是证实所有覆盖率目标值低于 100% 。这可以通过使用发布计划和预定的需求或特性优先级 更 容易地完成。 专业建议： 从源代码引用或链接相关需求到软件单元验证策略的适当部分。 9. 处理失败的测试用例、失败的静态检查和检查结果的过程。 本程序应与 ASPICE 问题解决管理策略 (SUP.9) 过程相关并保持一致。 你应该描述谁被告知，以及如何和何时做什么。 你还应该描述你将在这个过程中分享什么信息 / 数据。 10. 执行回归测试的定义。 回归测试指的是在对单元进行更改后重新执行静态和动态测试。目标是确定一个单元中未 更改 的部分是否继续工作。 在自动化测试中，回归测试是 一键 完成的。 在持续集成 / 持续测试环境中，表明回归测试是由 “ 每日 构建 ” 或其他自动化保证的就足够了。 关于评估的说明 如果您没有覆盖软件单元验证策略中提到的所有 10 个方面，那么您肯定不会得到 BP1“ 开发软件单元验证策略包括回归策略 ” 的 “ 完全 ” 评估。直到第 4 点才完成第 2 点将导致他们在 BP1 中被评为部分或更 糟 。 隐含地，评估人员还期望参与过程的所有人员都了解软件单元验证策略的内容。如果他们没有证据，例如邮件、日志或类似的形式，可能会 出现 测试人员被召集到评估中，并在面试中确定他们的知识 的情况 。 在 A SPICE 中，更详细地描述了更高级别的工作产品验证策略 (WP ID 19-10) 。 它规定了验证策略 需要安排活动、处理风险和限制、 验证 的独立程度和其他方面 等能力和要求 。

上次的 A SPICE 评估是否出了问题而 您 不知道原因 ? 或者您马上要进行第一次评估？ 本系列文章是关于 如何准备A SPICE 流程 软件单元验证 (SWE.4) 评估的 。我们 探究这个 过程，预期交付 以及 评估人员的观点。永远记住一个 想法 : 怎样做才能成功地通过评估 ? 想要成功通过A SPICE 评估，项目的所有参与者都应具备以下特质： 对A SPICE 流程成熟度模型有很好的了解； 能够正确回答评估人员提出的问题 ； 能够解释他们的活动与参考 流程 的关系 。 对于每个过程， ASPICE 3.1 版本需要两种基本类型的交付物 : 工作 产品和 过程 产出 。 对于一个成功的评估，所有参与者都应该知道具体的 产出 ，因为评估人员在评估过程时会特 别注意这些 产出 。 值得注意的是 :“ 软件单元验证 (SWE.4)” 过程通常只等同于软件单元的动态测试。虽然这是一个基本的组成部分，但这里还有更多的期望。 评估的一般目标 A SPICE 评估旨在确定组织的成熟度级别。成熟度水平被视为高质量的指标。使用从参考过程模型派生的通用基础实践描述对每个过程执行评估。对于级别 1:“ 执行过程 ” 的评级，必须至少实现所有 要求 的 50%( 大部分 ) 。 提示 : 软件单元验证过程有 7 个基本实践 ( 见图 ) 。您应该考虑所有的基础实践。请不要忽视他们中的任何一个。第 1 级评估的定性要求非常高，基础实践的结果对上游和下游过程具有交叉依赖。糟糕的表现可能会导致其他领域的降级。 7 个基本实践的简要概述 : A SPICE 基础实践