江门交通部1076认证

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

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

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

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

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

5.压力不够。由于测试环境的搭建，都是基本单一的软硬件对测，再加上硬件测试环境搭建的成本和复杂性，难以模拟出真实大规模业务并发的环境，造成压力测试不够，很多都是测试人员骗**，走走过场，真实的问题往往较后在上线后，接入大规模业务时出现。

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

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

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

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

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

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

交通部：

为规范道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查（以下简称标准符合性技术审查）工作，确保标准符合性技术审查工作的顺利实施，根据《道路运输车辆动态监督管理办法》（交通运输部、公安部、监管总局2016年令*55号）及有关规定，制定《道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查工作规范》。

规范所称道路运输车辆卫星定位系统标准规范主要包括《道路运输车辆卫星定位系统车载终端技术要求》（JT/T 794）、《道路运输车辆卫星定位系统平台技术要求》（JT/T 796）、《道路运输车辆卫星定位系统终端通讯协议及数据格式》（JT/T 808）、《道路运输车辆卫星定位系统平台数据交换》（JT/T 809）、《机动车运行安全技术条件》（GB7258）、《汽车行驶记录仪》（GB/T 19056）以及相关技术规范。（其中交通部检测中心进行的检测为JT/T 794和JT/T 808两项标准的检测，而GB/T 19056属于CCC认证的检测标准）

企业确保产品满足交通部所要求的标准，且有对应的检测报告及认证证书，即可凭相关资料，向交通部符合性审查办公室进行符合性技术审查，审查通过后，对通过标准符合性技术审查的产品公告（即厂家可满足各省市交通部门针对此类产品的招标认证要求）。

由于交通部部标平台过检的标准信息相对不是很透明，大家对794标准和jt/t 808 协议、jt/t809协议都是通过文档的字面意思各自去理解的，误差难免，误差大的，到北京过检的时候，就要耽误的时间长，过的就非常不顺，花费的差旅费和检测费就很大，得不偿失。很多去过检的企业都不是北京公司，在北京检测要背负额外的时间成本和费用成本，所以要追求较高的成功率，不然遇到问题，要面临两难选择，要么回来，改完了再坐一趟飞机去检测，要么呆在酒店里，改完了，重新预约下次检测时间，一直到过了为止。过完检的人都会感慨良多，不过不知道，过了感觉里面全是大坑，仅靠理解简单的功能列表是不行的，差的太远。

为什么去检测的企业非常不顺呢？

这是由于打铁需要自身硬，去过检的企业有很大一部分都是自己，本身就一堆毛病，没有给大量用户用过，也没有经过时间的考验。内部测试是不可能代替用户各种长时间使用的。由于按照部标协议完整开发的GPS软件平台开发周期都是在一年多以上（为什么大家愿意自己开发，就是因为不相信会花费这么长时间，开发完回头一看二年都过去了），已经耗尽了**的耐心，按照计划，早该去过检测了，成为一个通过认证的部标平台是一个商务性质的，是需要配合市场竞争要求的，不可能在那里像温水煮青蛙一样慢慢搞的，所以很多平台都是迫于时间压力，仓促迎战。

如何才能快速的过检呢，很多事情都是前车之鉴，部标2011年推出，到现在已经四年，翻一翻部标过检名单，已经过了几千余家，别人已经走过的弯路，你还在那里用人民币铺路，使蛮劲吭哧吭哧的走，是不是有点滑稽，缺乏智慧。过检完全是一个经验主义的事情，你的能力再大，也不可能在一年内开发出一个部标平台并过检，前面有没有坑，和你的能力智商及公司团队的实力一毛钱关系都没有，要花时间和精力走过去才知道。如果能够给过检的企业提供专业全面的指导，从部标808和809协议测试、部标796功能测试、运行测试和压力测试，各个环节，在过检前，就填掉大坑，到北京再去过检测，就是直通车了，避免头撞南墙起大包后再修改，无疑是较大的提高检测效率，节省一大笔支出。

选择跟我们合作可以大幅降低成本，因为检测的功能、时间都是可以确定的，要是企业自己去申请时间就不好说了，成本就更难以控制。

我们给企业客户提供的服务：

1.检测指导服务，用较少的时间完成检测出具报告

2.企业只需要提供样品测试，提供相关技术资料，不需指派相关技术人员到北京配合现场测试。

3.我们在实验室全程配合实验室现场测试，实现全包服务。