自动化测试以程序测试程序、以代码代替思维、以脚本的运行代替手工测试；
只要是一种程序，那么它一定能用程序测试程序、用代码代替思维、用脚本的运行为手工测试代劳；
自动化测试同时涵盖各种各样的测试种类，如：功能（黑盒）自动化测试、功能（白盒）自动化测试、性能测试、压力测试、GUI测试、安全性测试等都可以由测试自动化技术来代替手工测试。
提高回归测试效率：将回归测试交给计算机自动运行，可以极大提高测试效率，缩短回归测试时间，特别是程序修改比较频繁时，效果是非常明显的。这里说的程序修改比较频繁指的是新功能的不断加入，而老功能的逻辑是不变或者很少变化的；
测试更加快速、高效：有很多业务功能由于业务逻辑极其繁琐，使用手工测试往往耗费大量的时间，当一个测试人员测试同一个业务功能10次以上，几乎可以断定，没有一个测试人员会继续耐心的测试下去。此时自动化测试就能发挥作用，自动化测试的耐性是无限大的，而且计算机的执行速度远比人工快；
更好的利用资源：人工不可能24小时不眠不休的进行测试，但是计算机则不用休息。将繁琐的任务自动化还可以将测试技术人员解脱出来，投入更多的精力设计更好的测试用例来提高测试质量。
测试结果有保障：由于测试是机器自动执行的，每次测试的结果和执行的内容与操作的一致性是可以得到保障的，机器可以按照相同的轨迹不断地执行测试并丝毫没有差错；
无法达到手工测试的覆盖率：不是每个测试用例都适合转换成自动化测试用例，比如验证页面上的布局是否合理；
几乎无法发现新的缺陷：自动化测试大多是用它来发现曾经发现过的缺陷在每个版本下有没有重新出现，更适合缺陷预防而不是发现更多缺陷；
对测试质量的依赖性极大：如果当前版本的测试质量不够稳定，运行自动化测试将会非常不顺利，几乎是一种无用功和白白浪费时间的行为；
自动化测试工具没有想象力：自动化测试的好坏完全取决于自动化测试负责人和测试开发工程师的思想与技术，自动化测试工具是没有思想的；
成本高、要求高：自动化测试需要较大的成本投入，自动化测试对测试人员的技术要求较高，对测试工具同样有一定要求。
1.项目周期长，系统版本不断迭代：如果你目前所在的项目（或系统）是属于一个周期比较长的项目的时候，则非常适合引入自动化测试，把大量的回归测试托付给测试自动化是一个比较明智的选择。需要测试的版本越多，自动化测试越能发挥它最大的作用，给企业带来各方面的利益。
2.需求变更不频繁：当项目的需求非常稳定，不经常出现变更的时候也很适合引入测试自动化；
3.系统中不存在大批量的第三方控件：如果第三方控件数量不多的话，经过详细的计划与评估后，完全可以引入测试自动化；
4.需要反复测试：如可靠性测试需要进行上千次的系统测试。
项目周期短：当你的项目周期不是很长的情况下，请不要引入测试自动化，因为这样的话，不但收不回成本，反而会延长产品的发布时间；
需求变更频繁：如果客户经常性地更改需求，甚至时常更改老功能的业务逻辑，这种情况下，即使周期再长的项目也最好别引入测试自动化。因为，即使你有再好的自动化测试方案和执行技术，也始终赶不上客户变更的速度，最终仍然还是会放弃，因为永远在收拾“烂摊子”；
软件版本还没有稳定：如果版本功能还不是很稳定，主功能或大量的功能有被重新更改的可能性的话，务必暂时缓上一缓，不要随意的开始自动化测试；
项目中存在大量的第三方控件：如果项目中存在大量无法识别的控件（这种情况基本是发生在系统中存在大量的第三方控件），是没有办法写出自动化测试脚本的。
信息来源：易迪森技术部
END
