去年有个做智能水表网关的客户找到我们,项目组六个人,设备端、云端各占一半。他们的测试状态是这样的:硬件样机就三台,大家排队用;云端服务有时通有时不通;每次发版前全靠手点,点完心里还是没底。项目经理问我,这测试要怎么搞才像个样子。
这种场景我见太多了。工业物联网的测试,难就难在"两头都不稳"。设备端是嵌入式 C 代码,跑在资源受限的 MCU 上,调试手段有限;云端和协议层又是一套东西,Modbus、MQTT、OPC UA 混着来。中间还有个更麻烦的:软硬件联调要凑齐环境,硬件等软件、软件等硬件,时间就这么耗没了。
摔过跟头之后,我总结出几条能落地的做法,工具上主要靠 Parasoft 这套组合。
第一条,设备端代码别等上板了才测。C 代码在主机上跑单元测试,是成本最低的手段。我们用 C/C++test 给网关的协议解析模块做单元测试和静态分析,很多内存越界、栈溢出的问题,根本不需要真机,主机上就暴露了。有人会说,主机环境和目标板行为不完全一样啊。没错,但抓八成的问题只花两成的成本,这笔账划算。剩下的两成,才轮到硬件在环。
第二条,联调别死等硬件。这是我推 Virtualize 推得最凶的地方。云端服务没开发完,设备团队可以先对着虚拟出来的服务调;反过来,云端团队要测"设备上传异常数据"这种场景,难道真把一个水表拆了砸了?用 Virtualize 模拟设备行为,想要什么响应就给什么响应,异常流、超时、脏数据,随造随有。原来要三个部门约时间的联调,现在两个人对着虚拟环境就把主干流程跑完了。
第三条,协议层的测试要自动化,而且要往"场景"上靠。单发一条 MQTT 消息验证格式,这太浅了。真实场景是一串动作:设备上线、订阅、上报、断连、重连。我们用 SOAtest 把这些编成测试场景,还做了个狠的——把现场抓回来的真实报文直接回放。客户现场出了个诡异的断连问题,抓包拿回来回放,十分钟定位,现场排队复现至少得两天。
第四条,别让质量数据散在各处。设备端有一套测试结果,协议层一套,云端一套,谁也不知道整体状况。DTP 把这些数据收到一个平台上,哪个模块的静态分析违规在涨、哪个版本的测试通过率掉了,看板上一眼就能看到。项目经理后来跟我说,他每周例会就开着这个页面,争论少了,因为数摆在那。
最后说个心态问题。工业物联网的产品生命周期动辄十年,固件一改再改,今天省掉回归测试的力气,三年后会在某个客户的现场连本带利还回来。上面这套东西搭起来大概花了一个多月,看起来不便宜,但那个客户今年又发了三个新版本的网关,测试团队还是原来的人,加班反而少了。
工具是死的,场景是活的。这几条实践你要照搬也行,但更重要的是先想清楚:你的项目里,到底是硬件在卡测试,还是软件在卡测试。把最卡的那个环节先松开,后面的路就顺了。