对于一个一次性开发、没有后续版本更新的软件而言，自动化测试是毫无意义的。但是现在很多软件都会不断推出新的版本，在推出新版本的过程中，每次除了测试新加或修改过的模块，相关联的旧模块同样需要测试，才能保证产品的质量，这样就需要做大量的重复工作，自动化测试此时就可以创建测试中的可重用模块，同时还可以覆盖大部分的功能测试，这样可以使测试人员从回归测试中解脱出来，专注于新模块的测试。所以可以说自动化测试的最大价值在于回归测试。

　　因此，对于一个软件或其中某些模块是否适合自动化测试必须要先进行可行性分析，以证明你所选的测试方法的正确性，通常可进行自动化测试的软件需要满足以下几点：

　　（1）手工测试复杂度高：

　　（2）所选测试用例，实现自动测试的难度低；

　　（3）软件用于自动化测试的模块界面变化相对不大；

　　（4）软件生命周期长，经常推出新的版本；

　　（5）软件开发已基本完成，主要用于测试升级版本；

　　（6）所选自动化测试框架必须对所测软件应用界面有有效的支持，且维护管理成本较低。

　　另外自动化测试前期需要投入时间和一定的成本投入，故不要一开始就期望有高的回报，其效应会在不断完善积累中显现。而且不要期待自动化测试可以发现每个版本中的大部分错误，因为自动化测试主要用于回归测试，而且产品中每个新版本的大部分bug会在新模块中出现，所以自动化测试在于长期效应，能保证每个版本产品质量的稳定。

　　1.2 需求分析

　　正如开发软件需要有需求分析一样，基于数据驱动的自动化测试本质上也是开发，所以在制定测试方案之前也需要收集测试需求，这样才能保证自动化测试的成功。

　　随着IT技术的发展，传统的开发人员兼任测试人员的模式已经不能满足需求，目前大多数较正规的软件公司均已采用独立的测试人员来对软件进行测试，所以形成了开发人员、开发管理者、测试人员、测试管理者的模式。如图2示。

　　规范的测试过程需要上述人员的通力配合，因此在做自动化测试之前应该有一份规范的文档，用来描述测试内容、人员安排、测试流程、缺陷管理等。其中开发管理人员和测试管理人员分别作为开发团队和测试团队的接口，协调两个团队的工作，一般来说开发人员需要在每次对软件更新后提供详细的功能文档，开发人员还需要提供自动化测试所需要的数据等相关资源，测试人员根据功能文档创建适合做自动化的测试用例，并建立基于数据驱动的自动化测试工程。