ASPICE总结2——软件详细设计与软件测试过程

软件详细设计在ASPICE中代号是SWE3,处于V模型的左侧； 软件测试则包含软件单元测试（SWE4）,软件集成测试（SWE5）以及软件合格性测试（SWE6）三部分，处于V模型的右侧。下面我会比较详细地介绍一下各过程域的实施要点和迎审会面对的主要问题。

1. 软件详细设计
   软件详细设计要准备的第一份交付件就是：软件详细设计文档！文档的输入是软件的需求，内容应该涵盖数据结构定义，全局变量和宏定义描述，动态行为描述（任务/中断/需求方案分析等），每个函数的实现（输入/输出/返回/伪码等）,详细设计评估（关键性、复杂性、交互性等维度）。严格意义上来讲，应该是先做好详细设计，再写实际的代码。但是！其实我们是先代码后详设，或者说两者融为一体的，因为人力不够，时间也不够，只能走捷径。需要注意的就是写伪码的时候别写的跟源码一样，别露馅了。对于这一点，其实各OEM应该也心里有数，不会揪着不放。
   在软件详细设计写完并进行了评审之后（评审记录要留好），就可以进行代码相关的一系列动作了。
   首先，写代码的时候就要注意对编程规范的遵循，如果OEM还有KGAS的要求，那就尤其要上心了：代码圈复杂度要小于等于10，嵌套层数不大于4等等。多提一句，KGAS中的编码规范非常苛刻以至于很多都违反人性，比如一个函数只能一个return等，但是这些是可以跟OEM沟通协商的，达成书面协议哪些可以不遵循。
   代码写完的写一个动作是静态代码扫描。一般采用持续集成工具（如Jenkins等）实现自动扫描，在汽车领域一个重要的扫描项就是MISRA C编码规范的扫描。如果有违规的特殊情况，可以进行备注。实际上从静态扫描已经开始属于单元验证部分的内容了，单元验证一般来说包括几个行为：静态代码扫描，代码检视，单元测试，静态代码扫描和代码检视的结果也应该在单元验证报告中体现，但是由于其与代码紧密相关，所以一并叙述。每次静态代码扫描的结果同样需要保存作为“呈堂证供”。
   下一趴，代码检视。单元验证计划里应该有代码检视的checklist，最后需要有代码检视报告。比较easy的一个环节。代码检视完成后，就可以将代码上库了，我们采用的是git管理。
2. 测试计划
   叫测试计划也