在很多仍采用Automotive SPICE 3.1术语的项目中，SWE.5指软件集成和集成测试，核心关注软件单元、软件项逐步集成后，接口和动态交互是否符合软件架构。现行Automotive SPICE 4.0已经将SWE.5调整为“软件组件验证和集成验证”，但对集成顺序、接口交互、验证措施、回归选择和双向追溯的关注仍然延续。处理“ASPICE SWE.5软件集成测试怎么开展，ASPICE SWE.5集成测试覆盖范围怎么确定”时，应围绕软件架构和发布范围建立完整证据链，而不是单纯统计执行了多少条测试用例。

　　一、ASPICE SWE.5软件集成测试怎么开展

　　SWE.5的测试对象是逐步集成后的软件，而不是单个函数或单个软件单元。Automotive SPICE 3.1要求先确定集成策略和集成测试策略，再按照集成顺序执行测试；4.0则进一步强调验证措施、进入退出准则、通过失败准则以及验证环境。

　　1、先确定软件集成顺序

　　①从软件架构中整理需要集成的软件组件、软件单元及其接口关系。

　　②根据依赖关系确定【集成顺序】，避免上层组件已经进入测试，但底层服务仍未准备完成。

　　③对基础软件、中间件、应用组件和接口适配层分别标明进入集成的前置条件。

　　④明确每个集成阶段形成什么软件版本，以及该阶段准备验证哪些接口和交互。

　　⑤把集成顺序与项目发布计划对应，后续测试结果能够明确关联到具体软件版本。

　　Automotive SPICE 3.1明确要求集成策略与项目计划、发布计划和软件架构保持一致，并定义软件项的集成顺序。4.0同样要求软件元素按照已定义的顺序和前置条件完成集成。

　　2、编写集成测试规格

　　①针对每个集成阶段，从软件架构中提取需要验证的接口和组件交互。

　　②为每项验证内容定义【测试前置条件】、【输入数据】、【操作或激励】和【预期结果】。

　　③补充【通过/失败准则】，避免执行完成后只能依靠测试人员主观判断结果。

　　④涉及时序要求时，把响应时间、任务周期、调用顺序等写入检查条件。

　　⑤需要SIL、目标板、调试接口或其他环境时，在测试规格中明确对应环境。

　　3.1给出的典型集成测试关注点包括软件项之间的数据流、数据流时序、接口数据解释、动态交互和接口资源消耗；4.0继续把这些内容作为软件集成验证措施的重要示例。

　　3、按照集成阶段执行测试

　　①完成当前阶段软件集成后，先确认软件版本、配置和测试环境与计划一致。

　　②从集成测试规格中选择当前阶段需要执行的用例。

　　③执行接口调用、数据传递、状态切换、异常交互和时序相关测试。

　　④记录【实际结果】、【通过/失败状态】以及对应测试日志。

　　⑤出现偏差时建立问题记录，不直接通过修改预期结果让测试通过。

　　⑥修复软件后，根据影响范围执行相应的回归测试，再进入下一阶段集成。

　　Automotive SPICE要求测试或验证结果能够保存实际执行证据，并对偏离预期的结果进行后续处理。

　　4、建立架构到结果的追溯关系

　　①把软件架构中的组件、接口和交互关系关联到对应集成测试用例。

　　②再把测试用例关联到实际执行结果。

　　③架构发生变更时，通过追溯关系快速识别受影响的集成测试。

　　④评估前检查是否存在架构接口没有对应测试，或者测试结果无法追溯到测试规格的情况。

　　SWE.5要求验证措施与软件架构、详细设计之间保持一致并建立双向追溯，同时测试或验证结果也要能够追溯回对应措施。

　　二、ASPICE SWE.5集成测试覆盖范围怎么确定

　　SWE.5中的“覆盖”不能简单理解成代码覆盖率。集成测试更关注软件架构定义的组件边界、接口、数据流和动态交互是否已经获得足够验证，同时还要结合本次Release到底改变了什么。3.1要求测试用例选择对集成测试策略和发布计划具有充分覆盖，4.0则明确提出按照Release Scope选择验证措施。

　　1、从软件架构确定基础覆盖范围

　　①列出本次集成涉及的软件组件和接口。

　　②对每条接口检查正常数据、边界数据、错误数据以及接口状态变化。

　　③存在调用顺序或状态依赖时，把组件之间的【动态交互】纳入范围。

　　④接口具有时间约束时，增加【时序依赖】和响应时间验证。

　　⑤接口存在CPU、内存、通信带宽等目标时，再增加资源消耗检查。

　　这样得到的覆盖范围直接对应软件架构，而不是为了增加测试数量机械增加用例。

　　2、按照发布范围选择实际执行内容

　　①整理本次版本新增、修改和删除的软件组件。

　　②根据追溯关系找出受影响的接口以及与其存在交互的其他组件。

　　③新增接口执行完整验证，修改接口同时检查上下游影响。

　　④没有直接修改但可能受到影响的区域纳入【回归验证】。

　　⑤把不执行的测试项记录排除依据，确保测试选择能够解释。

　　Automotive SPICE 4.0的SWE.5.BP3明确要求，对每个集成阶段记录验证措施的选择，并结合回归准则确保对发布范围具有充分覆盖。

　　3、用覆盖矩阵检查是否存在遗漏

　　①以软件组件、接口或架构元素作为一侧，以集成测试用例作为另一侧建立覆盖矩阵。

　　②检查每个本次发布涉及的接口是否至少有对应验证措施。

　　③对安全相关、关键时序和高风险接口增加更深入的异常与边界场景。

　　④发现只有用例没有架构来源，或只有架构元素没有测试覆盖时，分别补充追溯或测试内容。

　　覆盖矩阵的价值不在于达到一个固定百分比，而在于能够说明本次Release为什么选择这些验证内容，以及哪些软件交互已经获得证据支持。

　　三、项目评估前还要检查哪些SWE.5证据

　　项目真正接受ASPICE评估时，评估人员通常不会只查看测试报告，而会结合集成顺序、验证规格、选择依据、执行结果和追溯关系判断整个过程是否成立。因此，测试做完以后还要从证据完整性角度再检查一次。

　　1、检查测试结果是否能够支撑结论

　　①随机选择几条已通过的集成测试，确认能够找到对应规格、执行记录和实际结果。

　　②随机选择失败项，确认问题已经记录，并能够看到后续处理状态。

　　③检查回归测试是否与软件变更及影响分析对应。

　　④确认最终汇总中能够区分已执行、未执行、失败和受限项目。

　　2、注意3.1与4.0项目的过程名称差异

　　如果客户基线仍采用Automotive SPICE 3.1，可以继续按照软件集成和集成测试的过程名称组织SWE.5证据；如果项目已经切换到4.0，则需要同时体现软件组件行为验证以及软件元素集成验证，不能只保留原来“集成测试”的一部分内容。VDA QMC在4.0中已经正式把SWE.5更名为Software Component Verification and Integration Verification。

　　总结

　　“ASPICE SWE.5软件集成测试怎么开展，ASPICE SWE.5集成测试覆盖范围怎么确定”的核心，是证明软件组件在逐步集成后能够按照架构定义正确协同，并且本次发布涉及的接口、交互和风险已经获得充分验证。覆盖范围应由软件架构、变更影响和发布范围共同决定，而不是单纯追求测试数量。希望本文对大家开展ASPICE SWE.5工作有所帮助，如果在集成测试策划、覆盖范围划分、追溯关系或ASPICE 3.1与4.0过程衔接方面还有疑问，欢迎联系咨询。