自动化测试的优势
能够极大地提升测试的效率，测试人员可以迅速地在指定平台部署测试脚本且对相应功能进行测试。
“弱化”了软件测试人员个体差异对测试结果的影响。
提高整个测试团队的技能水平。
自动化测试的缺陷
自动化测试的缺陷在于：总是按照既定的流程往下走，不能像人一样随机应变。一旦功能发生变动，就需要重新维护测试脚本。
自动化脚本的关键
要开发一套高质量的测试脚本，并不是简单的录制/回放，而是需要满足以下特点：
能够有效发现产品缺陷
有良好的可读性和错误日志，能够方便测试人员快速定位问题所在
能够稳定、重复、独立地运行，经过严格的审查流程
经过充分的脚本验收流程
在开发测试脚本的时候，需要时刻记得脚本的目的是暴露问题，任何在运行脚本时抛出的异常都有可能是产品问题产生的，因此需要避免在代码中隐藏问题。
一个好的自动化脚本的开发人员首先必须是一个好的测试人员，只有对需要测试的产品非常熟悉，才能够开发出真正有效的测试脚本。
如何提高测试脚本的可维护性？这就要求脚本有详细的错误日志和可读性。
如何提高测试脚本的稳定性？这就要求测试脚本能够具备运行独立性和可重复性。
当一个脚本运行失败后，可能的原因有如下几个方面：
由于产品本身的缺陷导致脚本执行失败
由于测试脚本本身存在的缺陷导致误报
由于测试环境搭建产生的问题导致失败
不幸的是，在一个项目中，真正由于产品缺陷导致的脚本执行失败所占的比率并不高，测试人员往往花费大量的时间去解决脚本缺陷和测试环境导致的失败。
因此，在开发测试脚本的时候，需要注意：
环境搭建和数据加载后，需要有明确验证步骤，如果数据加载失败，及时中断脚本运行且提示出错原因
对于每一个验证点，需要在日志里输出实际值和期望值，若验证失败，在日志里详细描述
尽量不要在程序里捕捉有可能出现的异常，应该将异常暴露给用户，使测试人员能够清楚地知道异常产生的位置
如何有效提高脚本的可读性？
通用的代码编程规范
充分利用测试代码中的注释
将测试描述和测试代码分离
如果没有保证测试用例执行的独立性，就可能产生如下问题：
由于所有用例之间的关系紧密，某一个用例执行失败导致了后续一系列用例的执行失败
增加了测试人员解决脚本问题的难度，用例失败，测试人员难快速定位问题原因
测试人员无法从中选取部分测试用例单独运行
自动化测试框架
一个设计良好的自动化测试框架，能够很方便地帮助测试人员开发高质量的自动化测试用例。
在开发一个自动化框架之前，首先需要考虑该框架需要满足什么样的要求。
一套自动化脚本的运行周期中主要完成了以下工作：
测试环境配置
执行待测试的用例
测试结果的记录
测试环境清除
测试报告生成
这些过程也构成了设计一个自动化框架的最原始的功能需求。
一个设计良好的自动化测试框架应该具备：
提高测试用例脚本开发效率--如何能够方便测试人员开发测试用例，能够做到数据和执行过程分离
具有完善的环境搭建的支持--让测试人员更加关注测试业务逻辑部分代码的开发
具有完善的测试结果汇报功能--让测试人员更好地测试业务逻辑
我们需要将环境准备的工作在测试自动化框架的层面进行实现，具体来说，需要实现以下功能：
测试环境的搭建和测试数据的清除
测试用例脚本的执行调用
执行结果报告的生成
在设计这样的自动化测试执行引擎时，首先需要考虑的是平台无关性。
制定自动化开发时间点时需要考虑的因素
不要在产品不稳定的时候开发自动化：初期缺陷较多，手动测试也可以熟悉产品，发现原有测试计划的不足和覆盖率缺失问题。
将测试脚本用于回归测试中：功能相对稳定，且计划也得到了较好的优化。
首先开发通用task：前期重点
测试自动化脚本应该基于一个相对稳定的测试环境下，且依照成熟的测试计划进行开发。如果初期开发大量自动化脚本，往往会导致后期大量的脚本返工量，反而降低了效率。
自动化测试的选取
自动化测试分为UI测试和API测试两大类，API测试属于更高层的测试方式，和单元测试相比，它更贴近用户的操作。
GUI测试往往采用录制/回放的方法，最大程度模拟用户操作，站在用户的角度去发现问题，和最终用户的行为联系紧密。但往往比预期要困难，因为UI设计变更会增加自动化测试复杂度，因此，GUI测试适用于当UI界面趋向于稳定的时候。
API测试通过直接调用软件产品的外部接口来验证返回是否符合预期，但无法覆盖到界面UI的显示正确性。API接口往往不会有频繁的变化，能够减少后期测试脚本维护的工作量。
根据产品特点，可以采取不同方式去实施API测试，既可以直接调用产品暴露的API，也可以通过模拟用户的HTTP请求来调用服务器端的Service。
测试脚本的验收
当完成脚本开发之后，为了保证脚本的高质量交付，需要制定高效的脚本评审流程和验收流程。
产品代码清晰描述了某个功能点，能够通过直观的检查确定功能是否完成。
自动化脚本明确描述了测试流程、需要检查的功能点，以及期望结果。
一套能够永远毫无差错运行的脚本不一定是高质量的脚本，因为这也有可能是由于脚本没有发现产品的问题。
自动化脚本评审分成代码评审和功能点评审两大方面。
代码评审：
代码是否符合代码规范
代码的扩展性如何
阅读代码是否能清楚知道每个测试用例的测试步骤
是否能很好地暴露脚本运行时发现的问题
功能点评审：
关注代码是否涵盖了所有的功能验证点，测试步骤和验证点是否和测试计划保持一致
测试脚本的验收就是为了确保脚本的用户能够顺利地运行这套脚本。
如果说评审是为了保证代码的质量和功能点的涵盖，验收流程确保了自动化脚本的运行稳定性和可重复性。
自动化脚本验收：
应当由非脚本开发者且具备中等技能的测试人员实施
支持跨平台的产品应覆盖到不同平台
不仅仅关注脚本的运行是否顺利，也要关注日志是否详细，是否有助于定位问题
验收中发现的任何问题应该由脚本开发者负责解决
自动化测试的稳定性
测试自动化脚本的稳定性直接决定了测试的效率。
影响自动化测试脚本的稳定性因素：
脚本中对某些输入参数的硬编码：这是影响脚本稳定性最重要的因素。
脚本等待时间硬编码：在开发脚本时机路的等待时间未必就是将来测试环境中的运行时间
跨平台问题：不同的操作系统或者数据库可能存在不同，因此必须在多个平台上进行测试。
如何权衡手动测试和自动化脚本开发的关系
对于比较稳定的测试项目，可以考虑在编写测试计划的时候同步编写脚本，测试计划的作者同时也是测试脚本的开发者，这将极大提高自动化开发的效率，但前提是每一个测试人员都具有自动化脚本开发的能力。
环境搭建和数据准备工作不会有频繁的变更，可以考虑在项目初期先完成这部分的自动化工作。
把握测试自动化的度。
用公式平谷自动化脚本开发的必要性
脚本开发执行成本=脚本开发工作量+(平均调试脚本工作量+平均执行脚本工作量)*每产品周期执行次数
手工执行成本=平均手工执行工作量*每产品周期执行次数
ROI=脚本开发执行成本/手工执行成本
如果这个ROI比例在5以内，则说明需要用5倍的工作量去开发自动化脚本。换句话说，这套脚本如果未来执行了5次，我们就把成本赚回来了，以后每运行一次，我们就能盈利一次。而如果某功能点的手动测试需要半天时间，而我们需要花费1个多月的时间去开发自动化脚本，这个比例就在60以上了，也就是说以后要运行60次以上才能收回成本。