1、什么是自动化测试
以程序测试程序，以代码代替思维，以脚本的运行代替手工测试。自动化的测试涵盖了：功能（黑盒）自动化测试，功能（白盒）自动化测试，性能测试，压力测试，GUI（Graphical User Interface）测试，安全性测试等。
2、自动化测试的优势
回归测试更方便可靠 ；可运行更多，更繁琐的测试，且快速高效；可执行一些手工测试执行相当困难或者做不到的测试，如大量的用户并发；更好的利用资源，具有一致性和可重复性的特点，自动化测试脚本完全可复用；提升了软件的可信度；多环境下测试等。
3、自动化测试无法做到的事以及劣势
永远不可能完全替代手工测试，自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合做成自动化，如建议一个页面的布局是否正确。
手工测试发现的缺陷远比自动化多。自动化测试是几乎无法发现新缺陷的，最大的用途是用来回归，确保曾经的bug没有在新的版本上重新出现。
自动化测试工具是死的，它不具备任何想象力。自动化测试的好坏，完全取决于测试工程师。
成本投入高，风险大。对测试人员的技术要求高，对测试工具同样有要求。
4、合适引入自动化
项目周期长，系统版本不断，并且需求不会频繁变更，此时是适合引入自动化测试的。
系统的测试对象基本可以正常识别，以及对无法识别的控件能否提供一个解决方案。
系统中不存在大量的第三方控件。
需要反复测试，如可靠性测试需要进行上千次的系统测试。
5、不适合自动化
项目周期短，需求频繁变更。即使是周期长的项目，如果经常需求变更，也不适合做自动化。
软件版本还没有稳定的情况下，主功能或大量功能有被重新更改的可能话，也不适合做自动化。
没有明确的项目测试自动化计划，措施和管理。
多数对象无法识别，以及脚本维护频繁与艰难，二者有其一，自动化必定失败。
6、自动化测试的流程
合理的自动化切入点：通常，项目只有经历了完整的系统测试之后才算具备了基本的引入测试自动化的条件。
（2）抽样demo分析，demo一般选取冒烟测试用例，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行
测试计划定制：自动化测试计划越全面，后期越能循规蹈矩的去实施，自动化测试的成功率越高
自动化测试设计阶段：主要分为自动化测试框架和自动化测试用例。
（2）自动化测试用例设计三部曲：手工测试用例是从无到有，然后自动化测试用例是根据手工测试用例来写的。首先，筛选手工测试用例。然后转换手工测试用例，最后新增&补充自动化测试用例。
（3）可共享脚本：可以被多个测试用例使用，被其他脚本调用的脚本
（4）数据驱动脚本：测试数据跟业务流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本
（5）关键字驱动脚本：脚本，数据，业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。关键字驱动的特点是，它更像是描述一个测试用例在做什么，而不是如何做。
（1）无人值守的测试：环境搭建，部署与配置；自动化测试用例与测试脚本相互绑定；自动化测试用例执行顺序排列与组合
提交自动化测试产物：大致需要提交执行情况，测试结果，分析报表，测试报告，质量情况等。
测试脚本维护：严格来讲，每个阶段都在做测试脚本维护。一个不值得维护的自动化测试项目是不值得立项的。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/