手动测试台架搭建，让你的车载测试更轻松_台架怎么测车窗

引言

如果你也在经常进行车载测试，就知道有时候手头的设备并不能完全满足需求。

在我之前的测试中，发现了一些问题，但是却找不到根本原因。于是，我开始思考如何打造一个更为完美的手动测试台架，让测试变得更加轻松。

经过不断地实践和调试，我终于成功搭建出了一个能够满足自己需求的测试台架。现在，我想和大家分享这个搭建的经验，希望能够帮助到在车载测试领域工作的小伙伴们，让你们的测试更加准确、高效！

1、概述

在做汽车软件测试的时候﹐实车测试是有限的的﹐很难覆盖所有的功能点﹐此时就需要进行台架测试。

测试台架的搭建也是测试工程师的必备技能

2、主要内容

（1）汽车测试台架分类台架测试输人

（2）台架硬件搭建CANoe台架搭建

3、汽车测试台架分类

为了验证汽车各个功能和各方面的工况﹐为了节省成本和缩短研发周期﹐在汽车的研发阶段都会搭建各种各样的台架进行功能﹑性能﹑可靠性﹑安全性的测试和验证。

4、汽车测试台架分类

汽车功能测试台架主要分∶

（1）简单的单个控制器的是台架

单个控制器的功能测试台架也分很多种﹐最简单的就是只需要被测的ECU,接通电源﹐通过CAN工具模拟总线节点﹐发信指令或者诊断功能测试

（2）单个控制器的专项测试台架

单个控制器的专项测试一般是指压力测试台架或者HIL测试等

（3）整车测试台架

整车测试台架是指，按车的模型将所有的控制器放在一个台架中，去模拟实车无法完成的测试用例

其他尖于性能﹑可靠性和安全性测试台架基本都是相通的﹐比如那就测试台架﹐环境测试台架等等

5、汽车测试台架分类台架测试输人台架硬件搭建CANoe台架搭建

 

 6、台架测试输入？

需求规范

数据库

刷写工具和刷写软件以及测试版本信息

配置文件

供应商自测报告

网络拓扑图

7、需求规范是功能测试用例设计来源测试结果的判断﹔包括∶客户需求(功能规范)·需求分析﹑概要设计﹑详细设计等

 数据库︰测试数据解读;包括︰通讯协议（矩阵）、DBC、CDD/DLL、UDS诊断调查表DTC表等

 刷写工具和刷写软件：

 刷写工具和刷写软件︰刷写测试需求的提供刷写工具和刷导文件( driver文件和APP文件）

测试版本︰便于测试前的版本核实﹔包括︰软件版本﹑硬件版本·BOOT版本

配置文件∶不同车型配置文件﹔包括∶功能配置文件和网络配置文件以及其他配置文件等

 

 供应商自测报告∶作为参考和功能实现参考﹐包括性能和功能自测报告（由供应商提供﹐功能测试无法实现的以供应商自测报告为准)

 

网络拓扑图∶在搭建台架的时候,通过网络拓扑图了解被测ECU在哪路通讯上,与哪些控制器有交互﹐需要仿真模拟哪些控制器等﹐包含所有节点和ODB接口定义的网络拓扑图

 重要电路图和引[脚定义∶有电路图和弓引[脚定义我们才知道相尖线束分别是什么,有什么用

被测件和相尖线束︰必须要有被测件和相尖线束我们的台架才能搭得超来﹔

 汽车测试台架分类

(1)台架测试输入

(2)台架硬件搭建

(3)CANoe台架搭建

在台架搭建之前﹐我们还需要一个12V的低压直流电源,电脑一台，CAN工具,还有相尖测试平台等 在台架搭建之前，我们还需要一个12V的低压直流电源，电脑一台，CAN工具，还有相尖测试平台等 

 

台架硬件搭建通过提供的电路图找到低压电源的正负极（一般正极至少有两个分别是KL30和KL15，负极可能有多个,至少有个KL31) ，连接上12V电源（如果是自动化最好是可编程电源﹐至少有继电器) 台架硬件搭建通过提供的电路图找到低压电源的正负极(一般正极至少有两个分别是KL 30和KL 15，负极可能有多个，至少有个KL 31)，连接上12V电源(如果是自动化最好是可编程电源，至少有继电器)

连接上低压电源后﹐找到控制器的通讯CAN线，分别是高和低辆跟﹐连接上CAN工具查看是否有报文发送出来﹐被测件是否被唤醒（般情况接上KL15后,就会被唤醒，如果不能唤醒﹐需要模拟发送网络管理报文)

通过CAN工具模拟相尖节点,发送需要的报文信息和指令,根据设计好的测试用例进行此相尖测试﹐一般需要模拟多个节点﹐发送多个信号

如果是多个ECU的台架搭建,都需要连接电源线﹐此时同一个域的CAN通讯线要接到一起,如果有网尖﹐安网尖的脚位连接﹐有需要时需要模拟多路CAN总线

CANoe台架搭建

连接CAN线﹐有的控制器不止一路CAN，可能有内部CAN ’T白月,根据结构图找到需要用的CAN线，不需要用的可以不连接

连接线上后﹐打开 CANoe软件创建工程一导人DBC,通过IG或者脚本﹐发送必须要发送的信号﹐如ON档信号,档位信号等等

创建节点﹐根据网络拓扑图或者需求规范﹐找到与哪些ECU有交互,创建各个控制器的节点信号﹐并发送信号

查看ECU是否被唤醒﹐正常通讯﹐是否有不应该的故障报出,然后通过测试用例进行仿真测试

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取