自动化测试的成本高，效果差，是一个相对的，而针对某些具体项目，是必须要接入自动化测试的。

首先说一些什么时候会需要自动化测试

首先咱们讨论这个问题之前要带着一个疑问：决定要不要做自动化测试的因素有哪些？

应该说时间才是一个衡量比重比较大的因素。

假如一个项目从立项到结束只有一个月的时间，而这一个月的时间可能相当长的时间都是用来看需求文档，改需求文档，编写测试用例等，真正留给测试的时间是不多的。所以这个时候如果强行要做自动化测试，可能用例设计还没有完成，后面跟随改动头就更大了。

所以对于时间成本和工作效率而言，手工测试绝对是第一选择。

但是呢，一旦项目稳定下来，就要考虑接入自动化测试了。因为这个时候项目比较稳定，做自动化就可以参照着手工用例去做了。

抛去了时间，就要考虑成本和效率了。

那么讲到这里，也就明白了自动化测试的一些特点：

1、自动化测试是为了确保项目可以正常上线，项目的主流程没有bug，而手工测试就是为了发现很多很多的bug。

2、从理论上来说，自动化是可以覆盖到所有的手工测试的流程的，但是相应的如果每一次测试都用自动化，靠着公司的一到两个自动化工程师，成本和效率反而会打折扣，跟不上迭代的速度。这也就是题主说的自动化成本高，效果差的反映。

3、如果是一名自动化测试人员，自身的价值绝对不是简单用脚本来体现的。无论搭建环境、搭建web框架、开发应用程序，都是能力的体现，说白了，自动化测试工程师是要发挥创造力的工作。

那么说什么样的项目直接就可以拿来做自动化测试呢？

自动化测试之所以能在很多大公司实施起来，就是有它适合自动化测试的特点和高的投资回报率。

• 产品型项目。产品型的项目，每个项目只改进少量的功能，但每个项目必须反反复复的测试那些没有改动过的功能。这部分测试完全可以让自动化测试来承担， 同时可以把新加入的功能的测试也慢慢地加入到自动化测试当中。

• 增量式开发、持续集成项目。由于这种开发模式是频繁的发布新版本进行测试，也就需要频繁的自动化测试，以便把人从中解脱出来测试新的功能。

• 能够自动编译、自动发布的系统。要能够完全实现自动化测试，必须具有能够自动化编译，自动化发布系统进行测试的功能。 当然，不能达到这个要求也可以在手工干预的情况下进行自动化测试。

• 回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。

• 多次重复、机械性动作，将烦琐的任务转化为自动化测试。自动化测试最适用于多次重复、机械性动作，这样的测试对它来说从不会失败。比如要向系统输入大量的相似数据来测试压力和报表。

• 需要频繁运行测试。在一个项目中需要频繁的运行测试，测试周期按天算，就能最大限度的利用测试脚本

那么说不适合做自动化测试的项目是什么特点呢？

• 定制型项目（一次性的）。为客户定制的项目，维护期由客户方承担的，甚至采用的开发语言、运行环境也是客户特别要求的，即公司在这方面的测试积累就少，这样的项目不适合作自动化测试。

• 项目周期很短的项目。项目周期很短，测试周期很短，就不值得花精力去投资自动化测试，好不容易建立起的测试脚本，不能得到重复的利用是不现实的。

• 业务规则复杂的对象。业务规则复杂的对象，有很多的逻辑关系、运算关系，工具就很难测试。

• 美观、声音、易用性测试。人的感观方面的：界面的美观、声音的体验、易用性的测试，也只有人来测试。

• 测试很少运行。测试很少运行，对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反复复的运行才有效率。

• 软件不稳定。软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳定，没有界面性严重错误和中断错误才能开始自动化测试。

• 涉及物理交互。工具很难完成与物理设备的交互，比如刷卡的测试等。

相信讨论到这里，题主的疑惑肯定是解决的非常清晰了。

1.测试自动化类似于软件开发的过程
录制/回放脚本的开发方式是不可能应付所有自动化测试的需求的，因此，需要测试人员掌握必要的开发知识和编码知识。
2.测试自动化是一个长期的过程
首先，不能期望自动化测试在短期内找到很多Bug，自动化测试只有在长期的多次运行后磁能体现它的价值。其次，不要认为只要购买了工具，录制一些脚本，然后就可以安枕无忧的看着自动化测试实现想要的效果，需要考虑自动化测试脚本维护成本，随着被测试应用程序功能的增加和修改，测试脚本的维护工具量会急剧的增加。
3.确保测试自动化的资源，包括人员和技能
最好有专门的自动化测试工程师来保证测试自动化持续，顺利的进行下去，自动化测试工程师需要对项目测试自动化负责，设计测试框架和脚本结构，解决各种测试脚本的开发问题，确保自动化测试得以计划，设计和有序的开发，维护。
4.循序渐进的开展自动化测试
不要一开始就把自动化设想的很大，这往往是不可实现的，应该从小开始，先熟悉工具和自动化测试的基本技能，然后，整合资源开始实现一些基本的自动化测试用例，例如：冒烟测试类型的自动化测试脚本，先实现那些容易实现的，且相对稳定的功能模块的自动化测试，然后再考虑逐步扩展和补充其他相对难实现，或者是比较不稳定的功能模块。
5.确保测试过程的成熟度
如果软件企业的测试过程和项目管理过程的能力成熟度比较低，则实现自动化测试的成功率也比较低，在开展自动化测试之前，先考察一下软件企业各方面的管理能力，；例如：测试是否独立进行？有无配置管理？进度控制能力如何？如果各方面的能力成熟度都比较差的话，则不要盲目的引入测试自动化

何时应使用自动化测试？

1、执行频率

如果测试会在应用程序的每一个新版本下运行，则该测试非常适合自动化。这包括在整个应用程序中检查基本功能的那些测试。每当应用程序有了新版本，在进行深度测试前，应当运行这些测试来检查新版本的稳定性。

数据驱动测试（测试中对同样的操作使用了多重的数据值）也是非常适合自动化的测试类型。每次对不同的 输入数据集通过手工方式运行测试既单调乏味也效率低下。通过创建一个自动化的数据驱动测试，能够在一个测试中使用多重的数据集。

2、压力 /负载测试

同样推荐将压力测试和负载测试进行自动化。举例来说，假设一个测试必须重复1000次，手工运行测试将会非常不切实际。使用WinRunner，则能够创建一个循环来运行测试1000个来回。

何时不要使用自动化测试？

 1）可用性测试－提供可用的模块来检查应用程序的易用性的测试；

 2）只运行一次的测试；

 3）需要立即运行的测试；

 4）基于用户对于应用程序的直觉和知识的测试；

 5）没有可预测结果的测试。

1、执行频率

如果测试会在应用程序的每一个新版本下运行，则该测试非常适合自动化。这包括在整个应用程序中检查基本功能的那些测试。每当应用程序有了新版本，在进行深度测试前，应当运行这些测试来检查新版本的稳定性。

数据驱动测试（测试中对同样的操作使用了多重的数据值）也是非常适合自动化的测试类型。每次对不同的 输入数据集通过手工方式运行测试既单调乏味也效率低下。通过创建一个自动化的数据驱动测试，能够在一个测试中使用多重的数据集。

2、压力 /负载测试

同样推荐将压力测试和负载测试进行自动化。举例来说，假设一个测试必须重复1000次，手工运行测试将会非常不切实际。使用WinRunner，则能够创建一个循环来运行测试1000个来回。

3、何时不要使用自动化测试？

下面描述了不应当被自动化的测试用例：

 1）可用性测试－提供可用的模块来检查应用程序的易用性的测试；

 2）只运行一次的测试；

 3）需要立即运行的测试；

 4）基于用户对于应用程序的直觉和知识的测试；

 5）没有可预测结果的测试。

4、自动测试的优点

其优点是能够很快、很广泛地查找Bug，缺点是它们只能检查一些最主要的问题，如崩溃、死机，但是却无法发现一些一般的日常错误，这些错误通过人眼很容易找到，但机器却往往找不到。

另外，在自动测试中编写测试工作量也很大，因此在实际测试中通常是手工测试和自动测试相结合，而且手工测试往往是主要的，占了1/2－2/3。而自动测试只占1/3－1/2。在不同的开发队伍中，这个比例会有所不同，但总体趋势是这样。

1.测试自动化类似于软件开发的过程
录制/回放脚本的开发方式是不可能应付所有自动化测试的需求的，因此，需要测试人员掌握必要的开发知识和编码知识。
2.测试自动化是一个长期的过程
首先，不能期望自动化测试在短期内找到很多Bug，自动化测试只有在长期的多次运行后磁能体现它的价值。其次，不要认为只要购买了工具，录制一些脚本，然后就可以安枕无忧的看着自动化测试实现想要的效果，需要考虑自动化测试脚本维护成本，随着被测试应用程序功能的增加和修改，测试脚本的维护工具量会急剧的增加。
3.确保测试自动化的资源，包括人员和技能
最好有专门的自动化测试工程师来保证测试自动化持续，顺利的进行下去，自动化测试工程师需要对项目测试自动化负责，设计测试框架和脚本结构，解决各种测试脚本的开发问题，确保自动化测试得以计划，设计和有序的开发，维护。
4.循序渐进的开展自动化测试
不要一开始就把自动化设想的很大，这往往是不可实现的，应该从小开始，先熟悉工具和自动化测试的基本技能，然后，整合资源开始实现一些基本的自动化测试用例，例如：冒烟测试类型的自动化测试脚本，先实现那些容易实现的，且相对稳定的功能模块的自动化测试，然后再考虑逐步扩展和补充其他相对难实现，或者是比较不稳定的功能模块。
5.确保测试过程的成熟度
如果软件企业的测试过程和项目管理过程的能力成熟度比较低，则实现自动化测试的成功率也比较低，在开展自动化测试之前，先考察一下软件企业各方面的管理能力，；例如：测试是否独立进行？有无配置管理？进度控制能力如何？如果各方面的能力成熟度都比较差的话，则不要盲目的引入测试自动化.

何时不要使用自动化测试？

 1）可用性测试－提供可用的模块来检查应用程序的易用性的测试；

 2）只运行一次的测试；

 3）需要立即运行的测试；

 4）基于用户对于应用程序的直觉和知识的测试；

 5）没有可预测结果的测试。

自动化测试场景

1. 解决回归测试

   回归测试：复测，针对此前开发已经修复的bug，再次进行测试

2. 解决压力测试

   长时间使用一个软件或者同一时间并发访问同一个软件的服务器

3. 解决兼容性测试

   同时运行在不同浏览器和不同手机设备上

4. 提高测试效率，保证产品质量

5. 解决随机bug

   用自动化脚本多次跑一条测试用例，看bug出现的次数

6. 解决主功能测试

   测试迭代版本，主要测试修复的bug，以及优化新增的功能，还有版本的主功能