可选项正朝着必选项转变的是仿真测试自动化，它并非单纯让脚本运行取代鼠标点击，而是凭借构建具备可重复特性、可扩展性质的虚拟测试环境，把测试向左移动，于更早阶段发……
可选项正朝着必选项转变的是仿真测试自动化，它并非单纯让脚本运行取代鼠标点击，而是凭借构建具备可重复特性、可扩展性质的虚拟测试环境，把测试向左移动，于更早阶段发觉缺陷。然而不少团队在把自动化引入时，常常只是将目光聚焦于工具，却忽视了策略、维护以及流程集成，致使投入产出比难以达到理想状态。本文会从实战层面，谈谈做好仿真测试自动化的数个关键问题。
如何选择仿真测试自动化工具
选择工具如同挑选战友那般，不能够只去看名气，而更是要看是不是适配你的战场。首先，要明确你的测试对象究竟是单个的ECU，又或者是复杂的整车系统？要是进行硬件在环HIL测试，那么dSPACE、NI等老牌厂商所拥有的工具在实时性、IO精度方面更具备保障；要是开展软件在环SIL或者模型在环MIL测试，MATLAB/Simulink自身携带的测试框架或者一些开源方案或许更具有成本效益。
并非仅功能匹配应予以关注，工具的开放性以及脚本语言更需着重留意。若工具是封闭的，且只能运用厂商自行创造的语言，那么会致使你在未来举步维艰。应当优先挑选支持Python或者C++等主流语言的产品，这表明你能够轻松借助极其庞大的社区资源，而且更易于招聘到契合要求的人才。强烈建议向供应商提出提供试用的要求，运用你真切的模型使一个完整流程得以顺利运行，亲自去感受其易用性以及稳定性。
仿真测试自动化脚本维护难吗
脚本维护的确是自动化的最为头号的杀手，然而问题主要是出在脚本的架构设计之上吧。好多团队刚开始仅仅只求脚本能畅通运行，将测试逻辑以及具体操作全都生硬地编码到一起了。结果项目进行迭代时，界面发生了变化或者需求有所更改，脚本就必须得全部重新返工。正确的做法乃是采用分层设计，把底层驱动、业务操作以及测试用例区分开来，如此一来底层出现变化时，上层的测试用例只需少许修改甚至不用修改。
实现能够被维护的另外一个关键要点是由数据来驱动，不要把测试数据书写在脚本代码内部，而是要将输入参数、预期结果等放置到外部的Excel或者YAML文件当中，脚本仅仅负责读取数据以及执行流程，如此一来，当你需要增添上百个类似测试用例的时候，只需要添加数据行，脚本自身不需要进行任何改动，配合代码审查与版本控制，把脚本当成产品代码那样严谨地对待，维护成本就会大幅度地降低。
仿真测试自动化如何与CI/CD集成
把那仿真测试联接到 CI/CD 流水线这一行为哩，乃是促使它发挥出最大价值那般的关键一步。其具备的核心目标，是达成无人在旁值守状态下的自动触发以及快速反馈情形。你得去搭建一个能够被 CI 服务器呀其中是像 Jenkins、GitLab Runner 这些玩意能远程进行调用的自动化测试环境，这个环境呢它既可以是实验室内部的机柜，又可以是云端那儿的仿真集群。每当开发人员把代码提交上来之时，流水线会自动去拉取最新样子的模型以及相关脚本哩，接着部署环境随后就开启测试。
执行测试结束之后，结果得能够自行去解析，而后推送给团队。比如说，生成具备标准格式的测试报告，使得CI页面直接呈现通过率；要是测试失败了，系统能够自行截取关键仿真波形，发送邮件予以通知，甚至在项目管理工具里头创建缺陷任务。最为关键的是要设置“质量门禁”，像“核心回归测试通过率一定要达到100%才可以合并代码”，让自动化测试变成保障代码质量的硬性关卡。
身处你们那个团队，于推动仿真测试自动化进程里碰到的最为巨大的阻力究竟是什么？是工具挑选时遭遇困难，是脚本维护得令人头疼纠结，又或者是简直难以融入既有的开发流程？欢迎在评论区域分享你自身的经验以及内心的困惑，我们一块儿展开交流探讨一番，要是觉着这篇文章具备价值，可千万别忘记点赞并且分享给更多的朋友。
微信扫一扫 
