测试目标：确保对集成的软件进行测试，以证明其符合软件需求。
测试依据：测试用例来源于软件需求，而表现形式可能是一份独立的软件需求说明书，也可能是在系统级需求或设计里做了软件标识的部分。
测试对象：运行在MCU或SOC上的集成软件。
测试设计：测试用例的设计可以选择如下方法，等价类划分（将输入数据划分为若干个等价类，从每个等价类中选取代表性的数据进行测试，以缩减测试用例）、边界值分析（重点关注输入值的边界条件，因为在这些边界附近，程序更容易出错）、决策表（用于描述在不同条件下的系统行为，帮助测试人员理解并测试复杂的逻辑条件）、状态转换测试（关注系统在不同状态之间的转换，确保系统在状态转换时能够正确工作）、错误猜测（基于测试人员的经验和直觉，猜测可能的错误并设计相应的测试用例）、负面测试（在某些情况下，测试人员需要考虑负面测试，即测试系统在不满足正常工作条件时的行为，如故障注入）。
测试环境：汽车软件开发中，我们常希望得到状态比较好的硬件，甚至实车环境，但软件需求测试并不追求于此，而且要尽量保证测试不受硬件的影响，因为要从理论逻辑层面保证软件需求被落实。比如，Matlab中基于模型的MIL测试环境、基于台架或虚拟ECU的SIL测试环境。当然，有时PC中无法模拟某些ECU或传感器，也只能使用真实硬件。
进入标准：完成必要的前序测试（如冒烟）且无重大问题、相关的测试设备（如线束、ECU、CANoe硬件）就位、已review并发布的软件需求测试用例与计划。
退出标准：已执行对应的测试用例、测试报告已完成、缺陷已录入工具链。除了常规的退出外，出于成本的考虑，还会有测试中止，比如，基本功能确认失效、发现的缺陷会影响其他功能测试结果有效性、对于发现的缺陷被修复后需重新测试的范围，或者在测试过程中，得知新的软硬件即将释放，也应综合评估后中止。
负责角色：软件测试人员。
完整的软件需求测试会消耗大量的时间和资源，所以，我们需要在用例选择上做一个平衡，不全测，或者不是每次交付全测。一般有如下关注点。
产品风险大小：对于功能安全等级较高或者涉及到法律法规认证等高风险软件，通常，需要投入更多的资源在影响分析与测试量上，这是一个理所当然的决定。
不同配置下的功能是否适用：这需要我们有一个清晰的feature list或配置表，不适用的功能自然不需要测试。
功能是否实现：即便本配置有该功能，功能的成熟度也得达到可测水平。
变更的范围：结合接口文档、模型、追溯关系等，对软件组件自身的变更及其对未变更组件的影响进行评估，并进一步确认测试范围。有时，软件外部的系统环境或者车辆的变更都会影响到测试用例的选择。
历史测试状态：旧的版本、相近配置、相近分支或者平台主线的测试结果可能可以被当前软件沿用。一般在这里，也是基于变更来评估。
持续集成：为了确保基础功能没问题，我们可以设定一些关键的必测项，也就是不管什么修改，都至少运行这一套用例。结合自动化测试脚本，可以将其部署在持续集成流水线中。
全量测试：Delta测试很必要，但全量测试也不应舍弃，我们可以根据产品和项目特点制定一些执行全量测试的规则，比如，一年至少一次、切换分支基线后至少一次、发布D样件之前至少测试一次、软件上路试车前至少一次、发布10版软件后至少一次等。
所有软件级别的可测试需求必须至少被一个测试用例覆盖。
而为了检查测试覆盖率，必须能够通过工具实现测试报告、测试规范与相应需求之间的可追溯性，比较典型的是建立链接。
如果要发布的软件版本的测试覆盖率不完整，测试团队应向项目经理或客户汇报，并记录偏差原因和进行风险评估。
一致性呢，一般也只能通过评审来尽量保证。比如，软件测试人员应该参与软件需求的评审，而软件需求开发人员则参与软件测试的测试用例评审。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。
完
