作者：散步的SUN
昨天，有幸参加了spirent的北京的全球研讨会，主要关注其的自动化解决方案，后来与其公司自动化专家经理长谈了一次，颇有收获.
其自动化测试主要是面向于通信网络测试的自动化测试，其框架与流程很值得借鉴。
网络自动化测试与单纯的软件自动化测试不同的是，其物理拓扑环境的搭建，以及对一系列网络设备和仪器的自动化控制，其难度之大，有甚于软件自动化测试。
思博伦通信从收购FanFare之后，就出了这套整体的自动化测试流程，即一个全局的自动化测试Lab。以前的网络测试仪的自动化测试方案，无非就是基本三层—硬件设备层、适配层（脚本调用接口参数）、二次封装层（对适配层的脚本的二次封装），然后通过自动化测试人员根据API自行编写脚本控制其测试仪进行测试。
现在其提出的整体方案称为：NoCode自动化解决方案，其分为物理架构、应用环境、测试例以及测试周期。物理架构说白了就是利用一个物理交换机来控制自动化测试环境的插拔线以及断上电过程，进而控制测试拓扑；应用环境即集成了一个测试用例的编辑工具；测试例即集成了图形的脚本编辑；测试周期则是对测试结果的管理等。
后来，与其自动化测试经理进行交谈的时候，主要从针对现在中小型公司的自动化测试流程与架构的问题进行了交流，像华为和中兴、思科等这些大型的企业，因为其研发水平和投资的缘故，其自动化测试做的都比较成功，成功在于其从平台的角度上把握了整个自动化测试，其实道理很简单，为什么很多中小型公司自动化测试并不很成功，原因在于其只是将自动化测试当成了一个简单的工具，其自动化测试只是发生在执行流程上，而不是从整个流程上把握自动化测试；真正要做到自动化测试，则需要从很早开始就要从整体上进行把握，不一定要做到很大，但是要从整个流程出发，关键在于
1、自动化测试用例的管理流程
2、自动化测试用例的执行流程
3、自动化测试用例的结果管理流程
而我们很多公司只是单存的将用例编程自动化脚本就觉得OK了，孰不知一堆的维护量在等着你（因为自动化用例的更新问题，因为通信产品命令行或者功能的更新问题）
因此，个人觉得，对于中小型公司做自动化测试而言
1、刚开始，以需求分析为主，不要急着为了做自动化测试而做自动化测试，而是要从整体上进行分析，例如：产品自动化测试的比率（其成本价值），产品自动化测试的定位以及更重要的是自动化测试与人工测试的关系（如何均衡和使这两个部分配合达到最佳的效果）。
2、中期，等自动化测试用例达到一定数量后。可以先做到将其自动化测试执行分层次，典型的可以分为测试方法层、测试配置层以及界面层（界面层可以适当而做，像华为自动化测试平台，其界面与逻辑层做到了很好的分开）
2、中后期，当测试用例进行添加到一定数量后，开始需要从整个流程上进行把握，其实最重要的开发一个平台，集中管理自动化测试用例、集中管理自动化测试脚本以及集中管理自动化测试结果，可以专门负责对自动化测试用例的修改和完善，然后直接作用到自动化脚本的修改，以及对结果的输出与查看分析等。
这样的话，从整体上进行把握整个自动化测试流程，则会将自动化测试真正应用到实处。
总之，无平台与流程管理，那么自动化测试只能流于一种业余形式；而平台并不见得多大，而是一种思想；流程管理，也不见得多难，而是一种把控；
因此，做好自动化测试难点就在于既要从整体大局出发进行把握，还得需要从细节出发进行分析调控。