D、集成测试方法是否基于接口。
E、是否采用覆盖工具，工具的使用效果如何。
F、测试者是否具备一定的技术水平，是否已有集成测试经验。 G、测试中是否有足够的技术支援
风险分析报告需经过专家评审，一般情况下风险分析与集成测试方案一同递交评审，评审结论还要有跟踪解决。 3.3 集成测试方案设计
集成测试方案要实现集成测试的3个关键目标，即：实现可重复测试、基于接口测试、以覆盖指标衡量测试质量，集成测试方案围绕这三个目标来构造。
一个典型的集成测试系统，如图1所示，测试管理系统位于被测系统之外的独立系统，它与被测单板通过网口（或串口或其它通道）联接，测试用例管理模块主要完成测试用例设计与维护，测试过程控制模块通过脚本完成测试过程控制。测试管理系统下发测试驱动命令，发送到被测单板的驱动模块，再由驱动模块驱动被测系统正常运行，运行结果的采集也通过驱动模块完成，采集的结果发送到测试管理系统用于判断测试结果是否正确。 图 1 集成测试系统示例 驱动模块测试用例管理模块测试过程控制模块被测系统网口 或桩函数桩函数串口 或其它连接被测单板测试管理系统 采集运行结果需要设置监测点，监测点数量多少要视被测对象的接口特性，接口简单的，监测点就少，反之监测点多。一般情况下，一个监测点就是一个全局变量或一个消息，我们不建议把局部变量作为监测点，因为局部变量在函数内定义，也只在函数内生效，监测局部变量是单元测试的范畴，此外，要监测局部变量需修改被测试系统，这不是我们所希望的，我们应尽可能保证被测系统的真实性。对消息的监测，往往需要修改接收消息函数，我们需要捕获特定队列、特定特性的消息，实现起来较为容易。因为监测的对象是变量或消息，测试结果比较相对简单（不象系统测试，监测对象是GUI界面或一段文字输出或特定设备特定动作），集成测试的自动化还是比较容易实现的。
被测代码还需要插装以支持覆盖率统计，这部分工作最好用商用工具实现。覆盖指标中我们主要关心两项：语句覆盖与分支覆盖。路径覆盖与数据流覆盖因测试难度较大，一般情况下可不作要求。进行覆盖测试还需注意插装对代码运行效率的影响，缺少硬件支持打点取样的系统在插装前与插装后的运行效率能有数倍或数十倍的差异，这一点需注意，对运行效率有要求的被测系统，插装范围应有所控制。对运行效率有严格要求的系统，应采用硬件支持打点取样的工具，如CodeTEST。
制定集成测试方案需要审核被测系统的真实性，因为驱动模块、桩函数设计，驱动命令发送与监测点捕获都需修改程序，修改前后可能会给被测对象带来差异，尤其是加入被测代码，调度方式可能会产生改变，规划集成测试方案时需对这些差异进行祥细的评估，否则，差异过大的测试最终可能导致无效的劳动。
制定集成测试方案还需对测试范围界定，集成是某一层次的集成，处于被测对象下层与上层的代码测不到，需明确的作出说明或评估，为更上一层的集成测试或系统测试提供服务。
集成测试应考虑为性能测试提供方便，某些情况下，集成测试的构造与性能测试是相同的，采用不同的脚本即能完成这两项测试。 3.4 集成测试工具设计和调研
根据上述测试框架，集成测试有两类测试工具需考虑，一类是驱动被测系统以及截取结果分析的工具，另一类是覆盖率测试工具。
第一类工具因被测试系统是千变万化的，驱动模块、桩函数和监测点的捕获没有现成的商用工具可用，但后台的测试管理系统只要接口兼容性好，多数情况可重用。值得一提的是，利用商用脚本语言（如 TCL）构造驱动模块与桩函数能提高测试效率。
第二类工具我们有许多商用工具可调研，覆盖工具应用不同的被测系统有不同的选择，我们应优先调研商用工具，如没有合适的才考虑开发。调研覆盖工具需关注工具的易用性与健壮性，因插装打点过程较复杂，还依赖特定的语法分析器，许多商用工具较难用或不稳定。 3.5 集成测试接口分析与测试用例设计
测试用例设计是开展集成测试的基础，而测试接口分析是测试用例设计的基础。我们以接口特性考察被测对象，接口特性又从需求分析派生，所以接口分析时，我们要关注接口特性对需求描述的符合度，即，我们把所分析的接口特性叠加就能较完整的表达需求（或该需求的某一子项）。 接口分析需要罗列我们关心的接口，给出程序中对应的变量名，然后考虑如何驱动或监测。如表1所示： 表1：接口分析表样例 类别 属性 对应变量 驱动或监测试方法 表1中类别用来概括一种接口，如网接续集成测试中，应用层发起连网、拆网命令，这是一个接口类，假设链路层已仿真掉，对被测系统链路接口也是一个接口类。表1中属性是指一个接口类下的各种属性，如网接续接口下有：连网申请、拆网申请、成功或失败指示，控存值等属性，这些属性在程序中都有对应变量，这些变量是我们用以驱动测试或监测运行状态的对象。驱动或监测方法用来描述测试中如何使用该变量，如对于连网申请，我们可以在模拟一个时隙申请的消息放到指定队列，时隙是否申请成功，我们可以察看标识控存的变量。
分析完接口特性，我们就对如何驱动被测对象与如何捕获动行结果有着清晰认识，这时可以开始设计测试用例了。测试用例应以规范的脚本描述，设计时应充分考虑用例的可扩展性，并考虑将来接口的可能变化。至于如何设计完善的测试用例不在本文描述之列，但提供覆盖分析的测试对测试用例设计有直接的指导，哪个分支没覆盖到，就针对的设计用例让它覆盖到。 3.6 集成测试操作
集成测试的主要工作量应在测试代码编写以及测试用例设计与调试上，实际的集成测试操作应占很小一部分时间，因为测试过程是自动执行的。 因为集成测试发现问题后定位是直接的，更改流程应支持较快的版本更新，因为覆盖率的上升最终取决于正确执行测试用例后的结果，而且，某种情况下，程序中有不可达代码，需删除该代码才能提高覆盖率。集成测试不能象系统测试那样一个版本结束才出下一版本，是因为集成测试是对局部功能集成，版本基线较少受之影响，此外，不象系统测试，集成测试主要过程不在测试操作，不提高版本更新频度将影响测试效率。
集成测试也并非全部完成测试代码或用例设计才可以上手操作，实际上能让部分测试用例转起来，测试操作就可以开始了，测试代码编写、测试用例设计、测试操作可以并行着做。实际上，不停的调试测试用例同时就是一个测试过程，而且这部分时间占整个操作过程的大部分。因为插装过程较为繁琐，调试时我们可不必插装代码。
与其它测试类似，集成测试需要随时记录异常情况，定期汇报总结以期改进。
3.7 集成测试报告评审
集成测试报告评审是对整个测试过程进行审核，对测试结果的正确性、测试覆盖率作评价，此外，评审还对集成测试执行过程、计划完成情况以及集成测试方案、方案等进行确认。需要确认的内容参见《集成测试报告评审CheckList》。
4、方法和工具
TCL 语言，参考相关工具说明。 LogiScope ，参考相关工具说明。 CodeTEST ，参考相关工具说明。 HindSight ，参考相关工具说明。
5、出口准则
完成集成测试报告 通过集成测试报告评审
完成《集成测试任务总结报告》