对于一些协议或接口相关的功能测试(比如：XML或socket接口等)，是较为容易实现自动化测试的，封装好底层的协议提供给自动化测试脚本调用，即使是协议会有变化，改动起来还是很简单的，维护的成本相对较低。
总的来说，在软件功能达到相对的稳定，没有严重错误和逻辑错误后开始自动化测试，性价比是比较高的。
2.3 自动化测试的覆盖率
自动化测试的覆盖率是很多管理层所关心的，很多项目或产品的自动化测试目标之一就是自动化测试的覆盖率。从管理的角度来说，100% 的自动化目标只是一个从理论上可能达到的，但是实际上达到 100% 的自动化的代价是十分昂贵的。自动化测试覆盖率越高，测试脚本的维护成本也就越大。由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。
自动化测试的覆盖率的大小与自动化测试的成本有着很大的联系。自动化测试的覆盖率为多少比较恰当，也要看被测试系统的性质和测试的阶段。
在自动化测试设计的阶段，可以考虑先实现冒烟测试的测试用例自动化，冒烟测试的功能一般是系统的主要功能，是自动化测试设计必须首先实现的，而且通过实现这些功能，也可以检验自动化测试的架构是否合理。
在功能测试的前期，自动化测试脚本的覆盖率最好只是一些关键的并且是相对稳定的功能的测试自动化，用于冒烟测试或关键功能测试。
系统稳定后，如果系统是一个生命周期很长的系统，且测试的功能很容易实现自动化测试，这样的系统的自动化测试覆盖率可以考虑在80%以上。
但如果是一些时间很赶的项目，或者是一些比较难实现自动化测试的功能，也就没有追求高的自动化测试的覆盖率的必要。随着测试案例的增加，维护的成本也会相应增加，特别是一些GUI的测试，自动化比率越高，维护脚本的成本也就越高。
不要追求在很短的时间实现自动化测试，也不要追求100%的自动化测试覆盖率，积累经验循序渐进的自动化测试，效果会更好。
第3章 自动化测试实现基本策略
自动化测试与软件开发本质上是一样的，利用自动化测试工具，经过测试需求分析，设计出自动化测试用例，从而搭建自动化测试的框架，设计与编写自动化脚本，验证测试脚本的正确性，最终完成自动化测试测试脚本(即主要功能为测试的应用软件)。
3.1 测试系统需求分析
任何测试的基础都是被测系统的功能，不管是手工的功能测试还是自动化测试或者是性能测试，都是基于系统的功能展开的。当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。
很多公司都是将自动化测试和功能测试划分成两个不同的team，自动化测试team的同事实现自动化测试工具的开发，功能测试team的同事向自动化测试team的同事提需求，自动化测试team的同事编写代码实现自动化测试工具的功能后提交给功能测试team的同事使用，这是当前非常常见的自动化测试的模式，毕竟每个人都有自己擅长的技能，某个人也不可能面面俱到，通过这样的一种方式可能使自动化测试的门槛变得更低一些。自动化测试工具的开发和自动化测试的使用的确是可以由不同的角色去承担，不过作为自动化架构设计的人员，应该是对系统的功能或需求非常熟悉，同时具有良好的设计和开发能力，才可以设计出适合测试系统的自动化测试架构，否则开发出来的自动化测试工具就只是简单的一个工具，某种程度上会增加维护的成本。
文章来源于领测软件测试网 https://www.ltesting.net/
