在软件开发评审的时候，有两个问题经常是连在一块儿出现的，一个是怎么去策划ASPICE的集成测试，另一个是在测试做完之后，那些用来证明测试确实被执行了、而且结果有效的证据，又要怎么去保存下来，集成测试这件事，并不是简单地把一堆模块拼到一起去跑上一遍，看见没报错就算结束了，它需要我们能够说清楚，模块之间到底应该按照一个什么样的顺序去集成、它们之间的接口关系是怎样的、测试的依据又是什么、测试是在什么环境里跑的，还有最后出来的结果，有没有形成一个完整的闭环，而保存证据，也不是随随便便地把截下来的图往文件夹里一塞就行了的，它的目的是要让后面来做评审的人，能够顺着需求、设计、测试用例、执行时候的记录，还有对缺陷的处理，这一整条线，一路顺畅地查下去。

　　一、ASPICE集成测试怎么策划

　　对ASPICE的集成测试进行策划，不能等到代码都已经合并完了，才急急忙忙地去补一份测试的计划，策划的这个阶段，需要我们提前就把要测些什么、按照一个什么样的顺序去测、在什么样的环境里面去测、还有具体由谁来执行，这些都给讲清楚，而这个策划的起点，应该是软件的架构，还有各个模块之间的接口关系。

　　1、先把集成的对象给明确下来

　　我们需要把软件的那些组件、基础软件的模块、中间层的接口、通信的接口，还有诊断的接口这些对象，都给一个一个地列出来，然后去说明，哪些模块是要放在一起进行集成的，又有哪些接口是需要被重点拿出来验证的，在这里，不要只是在纸上写下一个模块的名字就算完事了，还要把它的输入是什么、输出是什么、它跟谁之间有调用的关系，还有它的运行都依赖了哪些别的条件，都给写清楚。

　　2、把集成的顺序给确定下来

　　集成的顺序，是需要和软件的架构对应着来看的，我们可以按照从底下往上面走、从顶上往下面走，或者是沿着某一条关键功能的链路，这几种方式来安排，比方说，我们可以先把底层的驱动和服务层给集成起来，然后再去集成应用层的那些功能；或者，也可以按照某一条关键功能的实现链路，把信号的输入、逻辑的处理，还有控制的输出，串在一起去测。

　　3、把测试的范围给界定清楚

　　在每一轮的集成测试里，我们都需要把这次测试的范围给写得清清楚楚，具体来说，就是哪些功能是进入了这一轮测试的，哪些功能是暂时还没有被覆盖到的，而那些暂时没被覆盖到的原因又是什么，如果测试的范围在一开始是含糊不清的，那么到了后面，对于测试得出来的结果，就很容易解释不明白，在评审的时候，评审的人也会不停地追问，那些被遗漏的项到底是为什么没有做。

　　4、去把测试的环境给准备好

　　对于测试的环境，我们需要把硬件的版本、软件的版本、编译时候的配置、用来刷写的文件、测试的脚本、仿真的工具，还有台架的状态这些信息，都给记录下来，在做集成测试的时候，最怕遇到的情况就是，环境明明发生了一些变化，却没有被记录下来，结果，同一个问题今天一跑就复现了，明天再一跑又复现不了了，弄到最后，大家很难去判断，这到底是代码本身的问题，还是测试环境在背后捣的鬼。

　　二、ASPICE集成测试证据怎么留存

　　ASPICE集成测试的证据，要能够用来证明，测试确实是按照事先的计划去执行过的，同时，也要能证明，那些在执行过程中被发现的问题，是已经被妥善处理掉了的，这里的证据，说的并不只是一份干巴巴的结果表格，它还要包括测试的依据、执行的过程、异常的记录，还有能让问题闭环的那些材料。

　　1、把测试的计划和用例给留存下来

　　在测试的计划里面，要去写清楚测试的目标、范围、环境、入口需要满足什么条件、出口又要达到什么标准，还有每一项工作的责任人是谁，而测试的用例，是要能够对应到软件的架构、接口的设计，或者是软件的需求上面去的，不能只是在用例里写上一句“验证功能是否正常”就完了，每一条用例，都应该有自己明确的输入条件、操作的具体步骤、期望看到的结果，还有用来判定它到底是通过还是不通过的标准。

　　2、把执行时候的记录给留存下来

　　关于执行的记录，需要包含执行的时间、由谁来执行的、是在哪一个软件版本上跑的、用的是什么测试环境、对应的是哪一条用例的编号、实际跑出来的结果是什么，还有最后的判定结论是什么，如果是用自动化的方式去跑的测试，那就可以把日志、报告，还有脚本的版本都给保存下来；如果是靠手工去做的测试，那就可以把记录的表格、截下来的图、台架上采集到的数据，还有通信的报文，都给保留好。

　　3、把缺陷的闭环情况给留存下来

　　当测试跑出失败的结果时，不能只是简简单单地写上一个“不通过”就丢在那里不管了，我们需要去记录下这个缺陷的编号、问题的描述、它会影响到多大的范围、由谁来负责处理、在哪一个修改的版本里被修复了、回归测试跑出来的结果怎么样，还有最终关闭它的结论是什么，一个缺陷，从它被发现的这一刻起，一直到它最终被关闭掉，这中间的过程，是要能够串得起来的，不能让别人只看到一张当初报错时的截图，却怎么也找不到后面是怎么去处理它的。

　　4、把追踪的关系给留存下来

　　集成测试的证据，是需要和需求、设计、接口、用例，还有测试的结果，建立起一套清晰的追踪关系的，一种比较常见的做法是，去建立一张追踪的矩阵表，把软件架构里的元素、接口的条目、测试的用例，还有执行出来的结果，都放在同一条链路里面，这样做完以后，到了评审的时候，评审的人就能从一个接口出发，一路追到它对应的测试结果上面去，到了那个时候，这份证据就比较稳当了。

　　三、ASPICE集成测试怎样避免返工

　　在ASPICE的集成测试里，之所以会出现返工，一个很常见的原因，倒不是测试本身没有去做，而是做完了以后，却发现很多事情根本就说不清楚，只要我们在前期的时候，把该搭的结构都给搭好了，那么到了后期，这些证据才不会散落得到处都是。

　　1、不要把单元测试，当成了集成测试来用

　　单元测试，它关注的是一个函数、一个模块内部的逻辑到底对不对；而集成测试，它关注的是模块和模块之间的那些接口，还有功能串起来的链路是不是通的，虽然这两者之间，有一部分的数据是可以被重复利用的，但是它们彼此之间，是不能够互相替代的，到了评审的时候，如果只是拿着一份单元测试的报告，就想把集成的关系给解释清楚，通常是站不住脚的。

　　2、不要只把那些通过的记录给保留下来

　　失败时候留下的那些记录，和通过的记录，其实是同样重要的，因为一次真实的测试过程，是肯定会碰到接口不通、信号出现异常、版本对不上，或者脚本报错这类情况的，把这些记录留下来，正好能够说明，测试的这个过程，是真实的、是在认真地做的，反过来，如果只是挑那些通过了的截图保留下来，反而容易让证据链显得很单薄，经不起推敲。

　　3、不要忽略了版本的基线

　　集成测试拿到的证据，是一定要能够对应到一个非常明确的软件版本和配置状态上去的，如果我们的用例、代码、测试脚本，还有台架的配置，这些东西全都没有版本的记录，那么到了后面，要针对缺陷去做回归测试的时候，整个局面就会变得非常混乱，所以，在每一次正式开始执行测试之前，都要先把版本的基线给确认下来，然后再动手去测。

　　总结

　　总地来说，ASPICE的集成测试要怎么去策划，还有测试的证据又要怎么去保存，这里面最关键的地方，就是要把集成的对象、接口的关系、测试的范围、环境的版本，还有最后结果的闭环，这些事情都提前给安排好了，在策划的阶段，要紧紧地围绕着软件的架构和接口去展开；在留存证据的阶段，则要围绕着计划、用例、执行的记录、缺陷的处理，还有追踪的关系，去留下清晰的痕迹，这样做了之后，集成测试才不会只是一堆零零散散的报告，而是能够变成一条，经得起评审、经得起复查，也能够支撑起对质量的判断的证据链。