信创项目启动后，应用能否在国产芯片上跑起来？

近日, 北京的某个金融机构, 在信创迁移期间遭遇了极具典型性的困境, 团队把 OA 系统直接部署到飞腾服务器之后, 流程审批界面呈现白屏状况, 花费两周时间才发觉是前端框架跟 ARM 架构的渲染引擎不兼容, 适配测试的聚焦点极为狭窄, 仅仅关注技术栈的兼容性, 却不验证业务逻辑是不是完备。

针对OA系统的审批流程而言, 适配测试仅仅需要去验证流程在国产操作系统之上能不能正常地流转, 页面可不可以进行渲染, 接口能不能够做出响应, 然而并不需要去检查审批规则是不是准确。业务逻辑验证属于回归测试的范畴, 需要等待适配测试通过之后单独去开展, 这两者是不可以相互混淆的。

细节测试项目起码包含应用程序安装卸载、基础操作响应、数据库增删改查、文件读写、网络通信、打印输出等基础能力, 客户时常忽略打印功能, 致使进入信创环境后发觉驱动不兼容，这是高频踩坑点, 提议在适配测试用例里, 把打印机 Scanner UKey 等外部设备兼容性单独罗列出来。

客户常常会问, 业务系统在X86上面运行了三年时间, 要是更换成为鲲鹏或者飞腾之后直接进行部署可不可以呢, 答案是不行的。一定要通过适配测试去排查三层的差异, 分别是CPU指令集的差异, 操作系统内核以及库版本的差异, 还有中间件与数据库兼容性的差异。

一家位于深圳的科技公司, 于迁移进程当中, 因对操作系统内核版本差异有所忽略, 致使原本于CentOS上能够良好运行的Java应用, 在麒麟V10上频繁地出现崩溃状况, 经过仔细排查后发现, 系统所调用的内存管理接口, 在不同的内核版本里存有行为差异, 最终借助内核参数的调整将问题予以解决。

于某政府项目的适配测试里, 应用所采用的MySQL驱动版本, 和达梦数据库出现了协议不匹配的状况, 进而致使批量插入操作出现超时现象, 这表明中间件与数据库兼容性此点极其关键, 而这类问题唯有在真实信创环境里开展适配测试方可被及时识别出来。

令人最为头疼的并非测试内容, 而是环境搭建的方式, 好多项目都要同时对麒麟以及统信予以支持, 并且要兼容ARM跟x86架构, 要是针对每个版本借助手动来搭建物理机, 那么周期将会极为漫长。

在实际项目当中, 推荐采用容器化方案去模拟信创环境而并非其他, 举例来说, 是基于统信UOS或者麒麟V10来构建镜像的, 随后要将应用部署进去并运行, 以此来进行适配验证。值得注意的是, 容器化却仅仅只能被用于初步筛选阶段, 可最终验收的时候必须要在物理机或者物理服务器上去运行才行, 这是由于容器对于硬件特性的模拟存在不精准的状况。

从工具的角度来看, 可以思索采用开源的全链路监控工具去搭配日志分析。在适配测试期间, 常常会出现崩溃或者卡顿的情况, 其缘由一般并非是单点出现错误造成的, 而是底层的接口调用存在不匹配。有一个Java应用, 在ARM环境当中调用x86原生的JNI库, 这直接致使进程退出了, 像这样的问题唯有借助链路监控才能够精准地定位。

某银行于信创适配测试里, 别的功能统统通过, 只是打印模块于统信UOS上没法输出。历经三天排查, 发觉打印机驱动仅对x86架构予以支持，然而飞腾服务器的ARM架构下全然没有相应驱动, 致使最终只能去更换打印机型号的。

信创适配里轻易易被忽略掉的盲区是外部设备兼容性方面的问题。除开打印机之外, 扫描仪、UKey、读卡器这类外设都有可能出现驱动或者协议不具备兼容性的状况。提议在适配测试用例当中单独去设立设备兼容性测试模块, 并且预先和设备厂商确认信创环境支持情形。

一家位于杭州的医疗信息化企业, 在面向医院所使用的多合一读卡器开展适配测试期间, 察觉到该读卡器于麒麟操作系统之上无法达成识别功能, 究其实质缘由在于, 生产厂商所提供的USB驱动, 仅仅针对Windows系统进行了适配。最终, 不得不协调生产厂商去开发Linux版本的驱动程序, 如此一来, 整个适配的周期被延长了一个月。

适配测试并非做一回便一劳永逸不再进行的工作, 每当应用版本有所升级, 每当国产操作系统补丁出现更新, 每当中间件版本向前迭代时, 均须再度执行适配验证, 建议把适配测试归入CI / CD流程, 每次构建宣告完成之后于信创环境里自动运行冒烟用例。

存有一份标准化适配测试报告模板非常关键 , 这份模板的内容要涵盖测试环境 , 还有用例清单 , 以及通过率 , 另外要包含失败原因以及修复建议。当客户提出要提供适配证明时 , 能够直接给出专业报告 , 而不是临时去进行补测。

被建议去选择那种拥有CMA以及CNAS这双检测资质的第三方软件测试机构诸如安畅检测来办理适配测试报告, 其经验是丰富的, 对于大多数招标以及验收场景而言是适用的。某央企在信创项目迎来验收的时候, 因为提供出了第三方专业适配报告, 所以顺利地通过了评审, 省掉了接近两个月的沟通成本。

要实际地将适配测试构建成为一种体系, 而不是一次性的任务, 建议团队成立专门的信创适配小组, 制定统一的测试标准以及流程, 还应当建立常见问题知识库, 以便后续项目能够快速进行排查。

一家位于广州的软件公司, 在做完首次适配测试之后, 归纳出20多项常见问题以及解决方案, 进而形成标准化检查清单。后续当接到新项目之时, 团队只要依照清单一项一项检查, 适配效率提高60%以上。

适配测试报告的模板里, 除去基础信息之外, 还应当涵盖失败原因的详细分类事项以及修复的建议。如此一来, 就算存在人员变动的情况, 新加入的成员也能够迅速理解问题的实质所在并且采取相应行动。建议运用Markdown格式去维护这份报告, 以便于进行版本管理以及促进团队协作。

你所在的团队于信创适配测试期间碰到过什么样稀奇古怪的问题, 赶忙在评论区去分享你遭遇的踩坑经历, 点赞并收藏这篇文章, 转发给正为适配测试头疼不已的同事！