大家好，又见面了，我是你们的朋友全栈君。
软件详细设计在ASPICE中代号是SWE3,处于V模型的左侧； 软件测试则包含软件单元测试（SWE4）,软件集成测试（SWE5）以及软件合格性测试（SWE6）三部分，处于V模型的右侧。下面我会比较详细地介绍一下各过程域的实施要点和迎审会面对的主要问题。
- 软件详细设计
软件详细设计要准备的第一份交付件就是：软件详细设计文档！文档的输入是软件的需求，内容应该涵盖数据结构定义，全局变量和宏定义描述，动态行为描述（任务/中断/需求方案分析等），每个函数的实现（输入/输出/返回/伪码等）,详细设计评估（关键性、复杂性、交互性等维度）。严格意义上来讲，应该是先做好详细设计，再写实际的代码。但是！其实我们是先代码后详设，或者说两者融为一体的，因为人力不够，时间也不够，只能走捷径。需要注意的就是写伪码的时候别写的跟源码一样，别露馅了。对于这一点，其实各OEM应该也心里有数，不会揪着不放。
在软件详细设计写完并进行了评审之后（评审记录要留好），就可以进行代码相关的一系列动作了。
首先，写代码的时候就要注意对编程规范的遵循，如果OEM还有KGAS的要求，那就尤其要上心了：代码圈复杂度要小于等于10，嵌套层数不大于4等等。多提一句，KGAS中的编码规范非常苛刻以至于很多都违反人性，比如一个函数只能一个return等，但是这些是可以跟OEM沟通协商的，达成书面协议哪些可以不遵循。
代码写完的写一个动作是静态代码扫描。一般采用持续集成工具（如Jenkins等）实现自动扫描，在汽车领域一个重要的扫描项就是MISRA C编码规范的扫描。如果有违规的特殊情况，可以进行备注。实际上从静态扫描已经开始属于单元验证部分的内容了，单元验证一般来说包括几个行为：静态代码扫描，代码检视，单元测试，静态代码扫描和代码检视的结果也应该在单元验证报告中体现，但是由于其与代码紧密相关，所以一并叙述。每次静态代码扫描的结果同样需要保存作为“呈堂证供”。
下一趴，代码检视。单元验证计划里应该有代码检视的checklist，最后需要有代码检视报告。比较easy的一个环节。代码检视完成后，就可以将代码上库了，我们采用的是git管理。 - 测试计划
叫测试计划也行，叫测试策略也中（河南口音）。内容有点多，本文先不写，下次找机会。 - 单元测试
单元测试属于白盒测试，也就是说可以参考代码的。但是KGAS要求设计用例的时候不能看代码！要先黑盒后白盒！就是说测试用例设计的一开始要参照详细设计文档来设计，如果发现有分支或语句覆盖率满足不了，那再来参照代码。说是这么说，做呢…有可能不是这么做哈哈哈，实际上我设计用例的时候都是对着代码设计的。
再来赘述一句没用的，KGAS要求单元测试用例设计人员与开发人员不能是同一个，用例执行人员和用例设计人员不能是同一个，要交叉。说是这么说，做呢…我就不说了。
测试用例设计文档要指明每个测试用例使用的设计方法，是等价类，边界值，需求分析还是错误猜测；还有用例的设计人员，用例的预置条件，用例的目的，用例的输入和预期输出。我觉得测试用例设计是让我头最大的一步，主观上相当排斥。
单元测试用例整体来说设计还是比较简单的，用例数目主要是取决于函数中if语句的数目。单元测试用例评审要重点评一下用例是否设计完整等，最后同样要保留评审记录（别嫌我烦，评审记录真的很重要）。
用例评审完就开始执行，执行就有可能出错，出错你就惨了哈哈哈。首先要针对错误提单，要解决这个BUG，你得从详细设计开始改，改完详设做评审，改完代码做扫描检视+评审，最后再来一波回归测试，一套组合拳下来，保准你这辈子再也不想发现BUG。你以为这是最惨的吗？不是的，集成测试发现问题才叫惨，那集成测试发现问题是最惨的吗？你又错了，合格性测试发现问题更惨？还有吗？还有吗？系统集成测试，系统合格性测试，一级更比一级惨！总而言之，越往后越惨，要是问题到客户那里、上车了才发现，饭碗可能就丢了。It’s never too late to discover BUGs!
最后，写单元测试报告，把测试过程，测试时间/活动等进行总结，子过程的结果汇总起来，进行缺陷与遗留问题分析。然后，单元测试报告评审（别忘了保留记录）。
写到这，我已经不想继续敲下去了，因为今天敲够了。测试计划，集成测试与合格性测试，改天吧。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/129389.html原文链接：https://javaforall.net
