汽车软件测试专栏—汽车自动化测试（第四期）

一、自动化测试的含义

自动化测试是通过自动化测试工具来验证各种软件测试的需求，它包括测试活动的管理与实施、测试脚本的开发与执行。

二、自动化测试的优势

敏捷开发的关键测试技术，敏捷开发需要大量的回归测试。

例如进行驱动芯片的可靠性测试时，长时间持续测试，开关数千次，这也是手工测试无法承受的。

时序有关的逻辑错误（例如上下电流程），通过手工测试很难发现。

提高软件测试的准确度和精确度，增加软件信任度。

如果有大量的测试用例，需要在短时间内完成，手工测试无法完成。

自动化测试能够实现所有测试条件的覆盖，能够在某些用例上穷举所有的测试输入数据，手工测试很难做到。

节省人力资源，降低测试成本，缩短软件开发测试周期

三、高度自动化测试的必备条件

1、需求变动不频繁

如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

2、完整的项目开发周期

自动化测试的设计到执行是一个测试软件的开发过程，需要相当长的时间来完成。项目周期太短，则没有必要。

3、平台化的项目

如果项目是非平台化的测试项目，大部分测试需求都是不同的，花费了大量的时间开发的自动化测试脚本使用率低，也是没有必要的。

4、手工测试无法完成的测试

个人观点：如果是以上条件有些条件满足，有些条件不满足，那么可以考虑低度自动化测试，把部分测试用例进行自动化测试，作为对手工测试的补充，就汽车行业来说，自动化测试不可能完全代替手工测试，最优解是手工测试和自动化测试手段结合起来使用，将稳定的测试需求模块作为自动化测试的目标，将经常变更的模块作为手动测试的目标，变更后的模块如果长时间不修改，可以考虑加入到自动化测试中去，是一个循序渐进的过程，自动化的测试脚本也不是一成不变的，也要根据项目的需求进行维护，将测试脚本作为一个软件产品看待，就是对待自动化测试的最好的观点。

四、自动化测试环境架构

自动化测试环境能够实现测试的自动化以及测试数据的自动化分析，用于测试用例的编辑、实现、执行以及测试报告的生成。简单的画了一下架构，给大家建立一个大体的框架开发思路。常用的自动化测试框架有线性模型测试、模块化驱动测试、数据驱动测试、关键字驱动测试等，具体的大家可以自己查阅相关资料。

五、自动化测试的流程

对于MIL来说，测试脚本可以直接开发，但是对于HIL来说，测试脚本是基于现有的手工测试的环境来进行开发的，只有经过了调试的HIL测试环境才能够满足自动化测试脚本的开发。

重点分析以下几个与手工测试流程有差异的子流程。

(1)设计测试用例

自动化测试用例的来源：手工测试用例设计时，标注哪些作为自动化测试用例，不需要专门设计自动化测试用例。并在设计变更过程中，不断筛选、删除、添加、优化、维护自动化测试用例。挑选自动化用例的原则是：清晰、简单、基础、改动小的功能。

(2)建立测试环境

对于自动化测试，建立测试环境就是开发自动化的测试脚本，目前有2种方案，一种是基于第三方软件公司的自动化测试工具，针对项目的测试需求，开发测试用例的脚本就可以，还有一种是开发自动化的测试工具，开发自动化测试脚本的方式，对于测试人员的软件能力要求很高，首先在开发测试脚本之前应该先开发自动化测试框架，同时还有考虑到数据库、日志文件、配置文件等方面的内容。

(3)执行测试

执行测试即执行自动化测试，是与手动测试最大的差别点，只需要一键即可等待测试的结束，大大提高了测试效率和人工成本。

(4)分析测试结果

运行结束后需要对测试结果进行评估、分析，分析结果是否正确，当结果不正确时需要分析产生结果的原因，手动测试测试考虑是不是测试步骤错了或者功能缺陷，自动化测试需要考虑的是测试脚本出错或者软件功能的缺陷。自动化测试的报告更具有说服力和可信度，这也是很多认证审核公司要求出局自动化测试报告的原因。

六、为什么新能源汽车行业自动化测试发展缓慢？

需求开发迭代速度太快，需求改动很频繁

缺乏有经验的测试人才，测试人才都集中在IT行业，主要是行业的积累比较久，同时IT转汽车行业很多知识又不是很相通。

测试工具本身的问题，测试环境自带的工具太难开发测试脚本，采购的第三方工具成本和效益可能又不对等。

技术问题和组织问题，没有形成一个良好的测试工具使用环境。