软件验证策略是软件单元验证过程中所有活动的基础，因此也是评估的基础。软件验证策略是基础实践1所要求的:开发包括回归策略在内的软件单元验证策略。
本文是ASPICE系列文章的第2部分。通过链接查看第1部分：ASPICE系列：顺利通过ASPICE流程软件单元验证(SWE.4)
对于评估人员来说，单元验证策略必须至少包括以下10个方面:
1. 所有单元的定义。定义可以是通用的，也可以是特定的。确保单元是唯一可识别的。在最简单的情况下，可以把一列函数或文件分类为单元。
2. 定义如何涵盖与验证和测试相关的特定需求。这包含功能需求、非功能需求和过程需求。
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中被评为部分或更糟。
隐含地，评估人员还期望参与过程的所有人员都了解软件单元验证策略的内容。如果他们没有证据，例如邮件、日志或类似的形式，可能会出现测试人员被召集到评估中，并在面试中确定他们的知识的情况。
在ASPICE中，更详细地描述了更高级别的工作产品验证策略(WP ID 19-10)。它规定了验证策略需要安排活动、处理风险和限制、验证的独立程度和其他方面等能力和要求。