2、适合做测试化测试的系统

　　适合做自动化测试的系统，通常是一些生命周期比较长的项目或产品，且系统功能实现自动化测试也较为容易，这样的项目使用自动化测试必然可以节省很多的资源和成本。特别是一些在今后的几年间需要不断开发和维护的项目，需要重复的进行大量的回归测试，如果有完善的自动化测试脚本，回归测试就可以节省大量的时间和精力了。对于一些增量式的产品，白天手工测试新功能，晚上或周末利用自动化测试脚本回归测试，可以达到资源使用的最优化，用很少的时间和很少的资源做很多的事情。

　　简而言之，是否值得使用自动化测试，就要看它是否具有自动化测试的特点和高的投资回报率。

　　开始自动化测试的时机

　　如果是新的自动化测试工具的开发或研究，最好预留一个比较充裕的时间，时间太赶很难设计出精品。如果想在功能测试阶段使用自动化测试，那么自动化测试架构的设计最好能够与代码实现同步，否则如果等代码实现提交测试之后再做自动化测试工具的开发或研究，在功能测试或回归测试的过程中就被动了很多。

　　关于在项目的什么阶段开始自动化测试，由项目决定，对于需求相对稳定并且是基于成熟的架构上开发的系统，自动化测试脚本最好在功能测试开始之前编写，在功能测试阶段就可以使用已经编写好的脚本做功能测试了。

　　但我们平时遇到的项目，有很多是需求变化比较大的，或者是一些不够成熟的系统，这样的系统如果在功能测试之前编写好的脚本，很有可能不能在系统上正确运行，大多还是需要手工执行才可以测试，甚至会在功能测试完后系统跟功能测试之前的系统会有非常大的区别。对于这样的项目，自动化测试开始得越早项目的成本就越大，最好在系统的架构或需求相对稳定后再做自动化测试。

　　对于一些需要录制GUI界面的功能的自动化测试，在页面的功能相对稳定之后再做自动化测试性价比会比较高，因为页面是最容易变动的部分，而且任何一个控件的修改都会导致自动化工具不能识别控件，导致很多自动化测试脚本会跟着做大量的修改，增加了维护的成本。当然，因为页面变化而引起的脚本的改动的大小，也跟自动化测试的架构和写脚本的功力有密切的关系。

　　对于一些协议或接口相关的功能测试（比如：XML或socket接口等），是较为容易实现自动化测试的，封装好底层的协议提供给自动化测试脚本调用，即使是协议会有变化，改动起来还是很简单的，维护的成本相对较低。

　　总的来说，在软件功能达到相对的稳定，没有严重错误和逻辑错误后开始自动化测试，性价比是比较高的。

　　自动化测试的覆盖率

　　自动化测试的覆盖率是很多管理层所关心的，很多项目或产品的自动化测试目标之一就是自动化测试的覆盖率。从管理的角度来说，100% 的自动化目标只是一个从理论上可能达到的，但是实际上达到 100% 的自动化的代价是十分昂贵的。自动化测试覆盖率越高，测试脚本的维护成本也就越大。由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。

　　自动化测试的覆盖率的大小与自动化测试的成本有着很大的联系。自动化测试的覆盖率为多少比较恰当，也要看被测试系统的性质和测试的阶段。

　　在自动化测试设计的阶段，可以考虑先实现冒烟测试的测试用例自动化，冒烟测试的功能一般是系统的主要功能，是自动化测试设计必须首先实现的，而且通过实现这些功能，也可以检验自动化测试的架构是否合理。

　　在功能测试的前期，自动化测试脚本的覆盖率最好只是一些关键的并且是相对稳定的功能的测试自动化，用于冒烟测试或关键功能测试。

　　系统稳定后，如果系统是一个生命周期很长的系统，且测试的功能很容易实现自动化测试，这样的系统的自动化测试覆盖率可以考虑在80％以上。

　　但如果是一些时间很赶的项目，或者是一些比较难实现自动化测试的功能，也就没有追求高的自动化测试的覆盖率的必要。随着测试案例的增加，维护的成本也会相应增加，特别是一些GUI的测试，自动化比率越高，维护脚本的成本也就越高。

　　不要追求在很短的时间实现自动化测试，也不要追求100％的自动化测试覆盖率，积累经验循序渐进的自动化测试，效果会更好。