《解读汽车软件测试之“软件单元与集成测试”》

接上文。

第二篇针对软件需求测试。软件需求测试有时也被称为软件功能测试或者直接简称为软件测试。

1、概述

软件需求测试是汽车软件测试的第四级别。在此阶段之后，通常可以将软件交由验收团队或交付团队进行系统级测试。

测试目标：确保对集成的软件进行测试，以证明其符合软件需求。

测试依据：测试用例来源于软件需求，而表现形式可能是一份独立的软件需求说明书，也可能是在系统级需求或设计里做了软件标识的部分。

测试对象：运行在MCU或SOC上的集成软件。

测试设计：测试用例的设计可以选择如下方法，等价类划分（将输入数据划分为若干个等价类，从每个等价类中选取代表性的数据进行测试，以缩减测试用例）、边界值分析（重点关注输入值的边界条件，因为在这些边界附近，程序更容易出错）、决策表（用于描述在不同条件下的系统行为，帮助测试人员理解并测试复杂的逻辑条件）、状态转换测试（关注系统在不同状态之间的转换，确保系统在状态转换时能够正确工作）、错误猜测（基于测试人员的经验和直觉，猜测可能的错误并设计相应的测试用例）、负面测试（在某些情况下，测试人员需要考虑负面测试，即测试系统在不满足正常工作条件时的行为，如故障注入）。

测试环境：汽车软件开发中，我们常希望得到状态比较好的硬件，甚至实车环境，但软件需求测试并不追求于此，而且要尽量保证测试不受硬件的影响，因为要从理论逻辑层面保证软件需求被落实。比如，Matlab中基于模型的MIL测试环境、基于台架或虚拟ECU的SIL测试环境。当然，有时PC中无法模拟某些ECU或传感器，也只能使用真实硬件。

进入标准：完成必要的前序测试（如冒烟）且无重大问题、相关的测试设备（如线束、ECU、CANoe硬件）就位、已review并发布的软件需求测试用例与计划。

退出标准：已执行对应的测试用例、测试报告已完成、缺陷已录入工具链。除了常规的退出外，出于成本的考虑，还会有测试中止，比如，基本功能确认失效、发现的缺陷会影响其他功能测试结果有效性、对于发现的缺陷被修复后需重新测试的范围，或者在测试过程中，得知新的软硬件即将释放，也应综合评估后中止。

负责角色：软件测试人员。

2、测试用例选择

完整的软件需求测试会消耗大量的时间和资源，所以，我们需要在用例选择上做一个平衡，不全测，或者不是每次交付全测。一般有如下关注点。

产品风险大小：对于功能安全等级较高或者涉及到法律法规认证等高风险软件，通常，需要投入更多的资源在影响分析与测试量上，这是一个理所当然的决定。

不同配置下的功能是否适用：这需要我们有一个清晰的feature list或配置表，不适用的功能自然不需要测试。

功能是否实现：即便本配置有该功能，功能的成熟度也得达到可测水平。

变更的范围：结合接口文档、模型、追溯关系等，对软件组件自身的变更及其对未变更组件的影响进行评估，并进一步确认测试范围。有时，软件外部的系统环境或者车辆的变更都会影响到测试用例的选择。

历史测试状态：旧的版本、相近配置、相近分支或者平台主线的测试结果可能可以被当前软件沿用。一般在这里，也是基于变更来评估。

持续集成：为了确保基础功能没问题，我们可以设定一些关键的必测项，也就是不管什么修改，都至少运行这一套用例。结合自动化测试脚本，可以将其部署在持续集成流水线中。

全量测试：Delta测试很必要，但全量测试也不应舍弃，我们可以根据产品和项目特点制定一些执行全量测试的规则，比如，一年至少一次、切换分支基线后至少一次、发布D样件之前至少测试一次、软件上路试车前至少一次、发布10版软件后至少一次等。

3、双向可追溯性和一致性

所有软件级别的可测试需求必须至少被一个测试用例覆盖。

而为了检查测试覆盖率，必须能够通过工具实现测试报告、测试规范与相应需求之间的可追溯性，比较典型的是建立链接。

如果要发布的软件版本的测试覆盖率不完整，测试团队应向项目经理或客户汇报，并记录偏差原因和进行风险评估。

一致性呢，一般也只能通过评审来尽量保证。比如，软件测试人员应该参与软件需求的评审，而软件需求开发人员则参与软件测试的测试用例评审。

4、全文小结

本文首先从目标、对象、环境、进入/退出标准等方面概述了软件需求测试的基本概念和要求。

由于完整的软件需求测试会耗费大量的成本，如何选择测试用例进行Delta测试就是一个重要的课题，所以第二部分对此进行了介绍。

汽车软件开发中，一般至少应在这个层级及以上关注追溯。这也是本文最后一部分的内容。

5、写在最后

通常，处于软件开发末端的软件需求测试，承担了不该承担的拦截问题和保证交付的主要压力，让我们向他们致以歉意。

       原文标题 : 解读汽车软件测试之“软件需求测试”