一.为什么要搞自动化
1.做回归测试，减少手工量：这样就避免了测试人员重复的劳动，也可以让我们有更多的精力去做更有意义的事情，也可以让我们减少一些乏味的感觉。
2.测试手工测试无法实现或是较难实现的功能：比如说模拟一千万条http并发请求，如果是手工测试，这个是实现不了的。
3.为了方便工作，编写一个小工具：
比如说我在做某些操作时，想实时从后台日志中获取我想要的信息，但是后台日志信息太多，很多都不是我想要的。
这样为了方便我查看日志，可以写一个小工具，实时从日志提取我想要的内容。
二.什么时候适合搞自动化测试
1. 敏捷项目：项目走敏捷模式的话，由于迭代周期太短，测试无法对以往功能全部回归，所以必然要用自动化测试来做回归测试。
2. 系统周期比较长的时候。
如果系统周期太短，那么花费了很长时间写好的自动化测试可能只被使用了很短时间或有限次数，那么这样就不值得了。
3. 项目比较稳定，需求不会变更的太迅速的时候。
需求变更的太快，会导致自动化测试老是失败。自动化维护成本太高，甚至由于太忙，测试人员没有时间去维护，导致之前写的自动化用例一直闲置，浪费时间。
三.自动化测试的成本
1.时间成本
A.培训成本：如果在一个项目中想实施自动化，前期肯定需要给大家做相关的培训(基础理论，编程语言)
B.编写成本
C.维护成本:
维护自动化测试环境一直正常可用
新增功能或修改bug后，可能导致某些旧功能自动化测试不能正常运行(比如出新的bug或是前端自动化测试时，某个元素的路径发生了改变等等)
2.金钱成本：有些不是开源的自动化测试工具还是挺贵的，比如说QTP
四.怎样选择自动化测试框架(工具)
测试框架就是把一些常用的方法进行了封装，方便我们使用，且减少代码的重复。
你可以选择自己写测试框架，也可以选择一些常用的自动化测试框架。
接口测试比较常见的有：robot framework,fitnesse等等
单元测试：junit，testng，Nunit等等
前端页面测试：selenium, Watir等等
当然很多时候我们也可以根据需要结合多种测试框架使用
那么我们在选择使用哪种自动化测试框架的时候一般考虑哪些因素呢？
1.支持的编码语言。
2.支持的运行环境。linux还是windows？
3.比较成熟，比较流行的框架。
要选择成熟的版本，如果不是使用最新的函数，还是使用稳定的版本比选择最新的版本好。那么这个框架可能本身的bug会比较少。我们是在使用这个框架，自然不想因为它本身的bug干扰我们的测试结果。
其次是用的人多的话，你使用中遇到问题，在网上查资料解决也比较容易。
五.自动化测试的缺点
1.不能完全代替手工测试：
有的情况自动化是无法实现的(比如断网断电)，或是编写自动化的成本太高；
自动化脚本不灵活，有些手工测试显而易见的问题，容易被忽略，因为不在脚本的测试范围；
还有就是自动化测试很难发现新的bug。
所以说自动化测试还是无法完全代替手工测试，我们可以用它来辅助测试，看新增功能后或bug修改后，原有的功能是否能正常运行。
2.编写和维护成本高
六.测试人员在自动化测试过程中容易陷入的误区
1.盲目追求自动化测试的覆盖率，而忽略了自动化测试的实际意义。
有些功能手工测试很简单，但是要实现自动化测试难度比较大，费时多，性价比低；有些功能可能只是一个暂时的功能，就没有必要写自动化。
2.为了实现自动化而去写自动化，而不考虑这是否真的对我们的系统测试有帮助，或是没有考虑到我们项目是否真的适合做自动化。
3. 有自动化测试不再需要手工测试
4.自动化测试仅仅只能做回归测试：其实自动化测试不只是可以做回归测试，也可以来处理数据(比如说刚才说的模拟一千万条http并发请求)，或是做一些小工具来辅助日常工作
另外：其实我觉得做好自动化测试的关键不是说你技术有多牛，而是你的自动化测试用例是否覆盖了那些测试的重点。所以我觉得做好自动化最关键的还是你自动化测试用例的设计。