一个实际案例
N年前某大型通信设备公司的测试部门发起一场轰轰烈烈的测试转型运动，驱动转型的动力非常简单：人手太紧了，要释放人力，当时该部门有95%以上的测试精力都投入系统测试上，导致其它测试，比如组网测试、协议测试一致性测试、性能测试，还有白盒测试根本顾不上。部门经理贾XX决心很大，先部门总动员，历经艰难，后来终于从各产品测试组抽调20多位骨干来研发自动测试工具。
半年过去，终于有一两个自动工具的初始版本做出来了，选测试组进行试验，为让自动测试跑起来，测试组额外多投了20%的精力饲候这个脆弱系统，后来工具研发人员几经努力，又用了半年时间，自动系统终于能稳定的跑起来了。大家舒了一口气，都指着这个系统能帮他们节约出几个人来，结果，两个版本测试周期过去了，人力没节省，反倒多搭进50%的人力写测试脚本，维护测试脚本。部门经理贾XX并不因此灰心，他认为这是测试自动化推行初期必然要经历的。
这次，他们调整策略，只从所有产品中选择1/3容易做自动化的测试组，给每个测试组指定一个测试自动化率指标，拿这个指标考核测试经理。如此又坚持了一年半，最后统计发现，这1/3测试组中又只有1/3是出效果，自动化测试有助于减少测试工作量，而见到显著效果的，却只是个别产品。
问题到底出在哪儿呢？
不适合自动化测试的产品领域
业务自动化测试是个香孛孛，看起来很诱人，尝一口苦涩得很。并不是所有产品都适合推行自动化测试，尤其是具有如下特点的产品。
1. 一次性产品
这类产品生命周期不长，客户需求比较确定，做出产品测稳定后，就很少升级，不会一个接一个的升级版本。
此类产品不宜做自动化的主要原因是，首次自动化的成本远高过投入，实现自动化后重用性差，自动测试是不大可能在前一两轮测试就产生效益的。
2. 接口原型或业务模式尚不稳定的产品
当产品业务的模型还不成熟，经常会变，或者子系统之间接口不稳定，经常变来变去。这样的系统不大适合做自动化。
3. 涉及过过物理设备交互
测试自动化的基础是设备仿真，如果被测产品与众多物理设备打交道，而又缺乏恰当的软件仿真或硬件工具仿真（缺少测试仪表或模拟器）时，自动化测试是难以为继的。
4. 项目周期很短的项目
自动化测试是一项长期投入，项目周期短往往只看到为自动化做投入，而等不到它产生效益。
5. 在用户界面操作表现复杂业务的产品
业务复杂意味着针对界面操作实现自动测试的代价很高，业务越复杂涉及的界面元素就越多，业务越复杂也意味它越容易变化，这对于自动测试，实现一次测试的自动化尚不轻松，更别说长期维护它了。
解决此类产品的业务自动测试，只一条途径：优化产品结构，进行抽象分层，让复杂的业务逻辑集中某几个规格化的接口（比如命令行接口、MML接口，数据驱动或表格驱动接口）来处理。
6. 涉及过多界面美观，图像质量、音频质量等可用性与易用性的产品
文章来源于领测软件测试网 https://www.ltesting.net/
