集成测试是为了构建一个更大的系统或平台，这个系统的几个部分通常是由不同的团队或甚至不同的公司开发的，以前在做信息化的软件开发时，面临的集成测试通常是不同软件子系统之间的集成测试，往往被这一阶段的测试搞得人仰马翻的，在从事了四年的视频监控和GPS软件开发之后，才知道，软硬件系统之间的集成测试更加折磨人的脆弱的神经。虽然两者本质上都是一样，软硬件系统集成实际上是嵌入式软件系统和常规的PC软件系统直接的集成。集成测试常常成为压垮复杂项目的最后一根稻草。主要存在的问题如下：

　　1、嵌入式软件开发团队和常规的软件开发团队，风格差别很大，从开发语言和技术，到思考处理问题的方式都有很大区别。从一开始，如何保证两个团队之间的充分沟通并相互信任是个问题，团队之间互相推诿，不担当的情况常常发生；

　　2、系统集成必然基于同一个约定，如软件接口，通信协议或规约，如果是第一次的合作开发，那么如何制定并保证接口和通信规约的稳定性，这个其实很难除非是我们都遵循成熟的国家标准或通用行业标准，如GPS通信协议JT/T808标准，否则研发初始自制的API和协议都是简单甚至是弱智的，随着软件开发的深入，对于功能和需求理解的越来越透彻，接口和协议不断的膨胀和变化，这种变化是那个团队发起的，如何和另一个团队进行协商，对于另外一个团队是否可行，在嵌入式系统上增加一个功能和在后端平台上增加一个功能所面临的的难度是一个天上一个地下，如何及时的固化到文档中去，如何制定一个合理有效的协商机制，都是在项目初始要确定下来的。

　　3、两个团队往往是并行开发，因为同属于一个大系统，所以有一个共同的项目计划和进度，大家在竭力完成自己的任务的时候，往往顾不得那边的情况，在节点汇合的时候，大家都声称自己完成了计划上的任务，开始测试了，实际情况是大家根本没有准备好，各自的单元测试和功能测试，进行的非常不充分，而留给双方共同的集成测试时间又非常的乐观。没有充分测试过的子系统在进行集成测试的时候，必然会暴露大量的问题，虽然这显得集成测试很必要，但是这些问题暴露的有点晚了，再返工修改，Rework的工作量很大，进度更加吃紧，而且有些问题本来可以避免掉，无须拿到成本昂贵的集成测试上进行。

　　4、集成测试并不意味着测试更充分或者覆盖面加大，我们拿到一个硬件系统，并不能像软件一样可以随心所欲的制造出一个有效用例来并且进行大量重复使用，例如要测试一个GPS软件的超速报警的功能，那测试用例设计时，必须要创造出一个车辆超速的动作环境，并触发终端报警上传到软件平台，这样一个用例还需要能够供测试人员反复调用。其他还有很多复杂的测试，如视频监控功能等测试。

　　如何能够做好软硬件集成测试呢？

　　1、多个开发团队要选择一些逻辑清晰有担当、能沟通的人来充当联络人，这个虽然有点滑稽，但是在出问题的时候，起的作用很大，没有逻辑，不敢担当的人，总是死咬着一句话，“我这边没问题”。出了问题不可怕，为什么要推诿老是找借口呢？ 耽误其他团队时间，浪费口舌。

　　2、及早Mock， 模拟测试可以让我们在单元测试阶段，就可以进行便利的接口调用，保证我们的测试路径和测试面的充分覆盖，只不过硬件的Mock难度比较大，有一定的开发工作量。例如在GPS软件开发的时候，我们需要开发一个完整的GPS模拟终端，模拟GPS终端的数据发送和接收各种指令并进行应答的行为。很多人不用模拟终端，是因为开发一个完整808协议的模拟终端，实现录音、拍照、参数设置、媒体检索等Mock功能，没有一两个月搞不定。硬件测试的时候，也需要不断的检测自己的硬件发送的数据或指令是否正确，也需要Mock一个后端服务器来进行检验。

　　3、集成测试的用例设计起来，往往贯穿终端、无线网络、服务器软件、PC客户端软件，是一个复杂的流程测试，所以对于用例设计的是否充分，需要花点时间进行评审和讨论理解。这种测试用例，应当及早设计，成为照亮各个开发团队行进道路的航标。

　　4、充分估计测试的工作量，上面说到测试用例的设计，如果认真设计用例，这个测试的工作量其实很大。不要为了项目计划而压缩集成测试的周期。

　　总之，不要埋地雷，没有侥幸，问题总是会出现的，何不让它出现的早一点，代价小一点。