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