【原】对工作中ASPICE的一些理解

为了应对外部A客户的迎审，最近包括去年都做了比较久的ASPICE准备工作，作为一个软件研发，我的任务主要集中在软件详细设计，软件单元测试，软件集成测试，也涉及了一点软件合格性测试。但是前几天得知迎审取消了，有喜有忧，喜的是终于迎来一个双休，不用每天听英语听力了；忧的是这些工作要搁置了。所以，整理一下我在做ASPICE与准备迎审过程中的一些总结和感悟吧。

ASPICE，全称“Automotive Software Process Improvement and Capacity Determination” ，汽车软件过程改进及能力评定。听起来很抽象，解释起来也挺难，我之前看过一个讲解敏捷开发与ASPICE开发之间的关系的视频，**讲到ASPICE是告诉你做什么，敏捷(Agile)则是告诉你怎么做！**感觉颇有道理，ASPICE主要就是对诸如项目管理、供应商管理、系统域、软件域等共15个过程域进行了结果上的要求，比如说在软件详细设计过程中，必须要定义接口函数，描述动态行为，进行详细设计评估等等，比如下图就是详细设计过程SWE3要求的BP和Outcomes。

下面整理几点自己的一些小见解：

1、有一个好的模板

成熟的文档模板是做好ASPICE的重要一环，这会让工作变得简单，变成填鸭式的，而且能保证各项要求不被遗漏。但是有一个好的模板并不容易，因为这通常是一个公司的核心资产。一般的ASPICE咨询公司会卖模板，但是通常只能提供一个基础版本，需要经过QA在迭代开发中，在迎审准备中，在专家辅导中不断改进。

2、讲究真凭实据

“真凭实据”在我认为有两个方面。一个是要“真”，在ASPICE实施过程中，只靠作假，通过编文档、撒谎等方式是绝不可能通过迎审的，我们在迭代一的开发过程中，由于一开始对流程不熟悉，对有的环节不重视，导致后补了不少文档，就遭到了辅导专家的质疑。但是这个真当然也有一个度，有的不重要的适当地使用话术来解释也并非不可。

第二个就是“据”，ASPICE的世界里非常讲求证据。换言之，你说的话别人都有不信的可能。你说我们每次上库都会进行静态扫描，那就要展示每次扫描的记录；你说我们每次文档基线都会评审，那就展示评审的记录，“什么？参与评审的总共8个人，只有一个人提了意见？”可以看到，证据是用来佐证“真”的。不管实施什么流程，务必保存有效的证据。

3、ASPICE有没有用？

先说结论，由于我现在还在项目开发初期，所以我的体会是：不仅没用，还费劲。看过别人专家的说法，ASPICE在项目早期甚至是单个项目中确实成本大于收获，但是当项目变得庞大的时候会带来帮助。正是因为这样，我觉得ASPICE在实施的时候必然会导致下面搬砖员工的积极性很低，动辄上百页的文档让人写得想吐。所以，ASPICE也必须是一个自上而下的推行，项目经理+QA施压和审查，才能保证流程的完整和质量。

4、双向可追溯

双向可追溯，听起来就很厉害的词，其实是ASPICE中最常用到的词之一。它指的是两个过程的元素之间能够互相关联。比如下图中蓝色线指向的双方就需要可追溯，举例，软件详细设计与软件单元测试涉及的双向可追溯体现在：

• 每个测试用例都能对应到软件详细设计中的函数；

• 每个单元测试用例都能对应到单元测试用例执行结果。

要实现双向可追溯并不难，最简单的方法就是通过Excel管理，更好的方式则是通过专用的软件来建立。

除了上述的追溯，还有系统需求与软件需求追溯、软件详细设计与软件架构之间的追溯、软件架构与软件集成测试的追溯、软件需求与软件合格性测试的追溯等等，这些都是每个过程域审查的重中之重！

ASPICE是一个方法论，指导OEM或者Tier One的供应商怎么把软件开发做得规范、质量可保证，说难也难，说不难也简单。

下面在理一理软件详细设计和软件测试过程。

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

1、软件详细设计

软件详细设计要准备的第一份交付件就是：软件详细设计文档！文档的输入是软件的需求，内容应该涵盖数据结构定义，全局变量和宏定义描述，动态行为描述（任务/中断/需求方案分析等），每个函数的实现（输入/输出/返回/伪码等）,详细设计评估（关键性、复杂性、交互性等维度）。严格意义上来讲，应该是先做好详细设计，再写实际的代码。但是！其实我们是先代码后详设，或者说两者融为一体的，因为人力不够，时间也不够，只能走捷径。需要注意的就是写伪码的时候别写的跟源码一样，别露馅了。对于这一点，其实各OEM应该也心里有数，不会揪着不放。

在软件详细设计写完并进行了评审之后（评审记录要留好），就可以进行代码相关的一系列动作了。

首先，写代码的时候就要注意对编程规范的遵循，如果OEM还有KGAS的要求，那就尤其要上心了：代码圈复杂度要小于等于10，嵌套层数不大于4等等。多提一句，KGAS中的编码规范非常苛刻以至于很多都违反人性，比如一个函数只能一个return等，但是这些是可以跟OEM沟通协商的，达成书面协议哪些可以不遵循。

代码写完的写一个动作是静态代码扫描。一般采用持续集成工具（如Jenkins等）实现自动扫描，在汽车领域一个重要的扫描项就是MISRA C编码规范的扫描。如果有违规的特殊情况，可以进行备注。实际上从静态扫描已经开始属于单元验证部分的内容了，单元验证一般来说包括几个行为：静态代码扫描，代码检视，单元测试，静态代码扫描和代码检视的结果也应该在单元验证报告中体现，但是由于其与代码紧密相关，所以一并叙述。每次静态代码扫描的结果同样需要保存作为“呈堂证供”。

下一趴，代码检视。单元验证计划里应该有代码检视的checklist，最后需要有代码检视报告。比较easy的一个环节。代码检视完成后，就可以将代码上库了，我们采用的是git管理。

2、测试计划

叫测试计划也行，叫测试策略也中（河南口音）。内容有点多，本文先不写，下次找机会。

3、单元测试

单元测试属于白盒测试，也就是说可以参考代码的。但是KGAS要求设计用例的时候不能看代码！要先黑盒后白盒！就是说测试用例设计的一开始要参照详细设计文档来设计，如果发现有分支或语句覆盖率满足不了，那再来参照代码。说是这么说，做呢…有可能不是这么做哈哈哈，实际上我设计用例的时候都是对着代码设计的。

再来赘述一句没用的，KGAS要求单元测试用例设计人员与开发人员不能是同一个，用例执行人员和用例设计人员不能是同一个，要交叉。说是这么说，做呢…我就不说了。

测试用例设计文档要指明每个测试用例使用的设计方法，是等价类，边界值，需求分析还是错误猜测；还有用例的设计人员，用例的预置条件，用例的目的，用例的输入和预期输出。我觉得测试用例设计是让我头最大的一步，主观上相当排斥。

单元测试用例整体来说设计还是比较简单的，用例数目主要是取决于函数中if语句的数目。单元测试用例评审要重点评一下用例是否设计完整等，最后同样要保留评审记录（别嫌我烦，评审记录真的很重要）。

用例评审完就开始执行，执行就有可能出错，出错你就惨了哈哈哈。首先要针对错误提单，要解决这个BUG，你得从详细设计开始改，改完详设做评审，改完代码做扫描检视+评审，最后再来一波回归测试，一套组合拳下来，保准你这辈子再也不想发现BUG。你以为这是最惨的吗？不是的，集成测试发现问题才叫惨，那集成测试发现问题是最惨的吗？你又错了，合格性测试发现问题更惨？还有吗？还有吗？系统集成测试，系统合格性测试，一级更比一级惨！总而言之，越往后越惨，要是问题到客户那里、上车了才发现，饭碗可能就丢了。It’s never too late to discover BUGs!

最后，写单元测试报告，把测试过程，测试时间/活动等进行总结，子过程的结果汇总起来，进行缺陷与遗留问题分析。然后，单元测试报告评审（别忘了保留记录）。

————————————————

版权声明：本文为CSDN博主「隋边边」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明，已获作者转载权限。