经过一段时间的学习，目前正参与OAM项目的自动化脚本开发与测试，谈谈对自动化脚本开发与测试的一些感受，以期同大家探讨。

　　困于心，而后作。因此，先谈谈我对自动化测试的作用和意义的认识。然后，谈谈在实际项目过程中的一点感受。

　　对自动化测试的作用和意义的认识

　　自动化测试是相对手工测试而存在的，虽然具有很多优点，但它只是测试工作的一部分，是对手工测试的一种补充，如许多与时序、死锁、多线程、需要模拟大量数据或大量并发用户等的应用场合，很难通过手工测试来进行，而采用自动化测试。

　　此外，自动化测试绝对不能代替手工测试，它们各有各的特点，其测试对象和范围都有可能不一样。对不稳定、一次性或开发周期较短等的目标系统，一般不适合自动化测试。

　　最后，进行自动化测试，绝不是因为厌烦了重复的手工测试，而是因为测试工作的需要，更准确地说是回归测试和系统测试的需要。此时，不能发现更多的新Bug，但可以保证对已经测试过部分的准确性和客观性。

　　实际项目中自动化脚本开发与测试的管理流程

　　从软件工程上看，自动化脚本的测试执行处于软件生命周期中的综合测试阶段，更确切的说是在通过了目标系统的非渐增式集成测试（也可称为冒烟测试）与第一轮手工测试完成之后而开始执行。也就是说，自动化测试脚本的开发全部完成，需要依赖真实的环境，则是在第一轮手工测试完成之时，而自动化脚本的测试执行则是从第二轮手工测试开始。此时（第一轮手工测试完成之时），从开发流程上看，开发者RD正在Debug冒烟测试与第一轮手工测试中测试出的Bug。这里会出现如下一个问题：

　　在自动化脚本开发之前需要事先确定好自动化测试功能点，如果出现自动化测试功能点在第一轮手工测试时，开发者RD正在Debug该功能点，这有可能导致该功能点相关的自动化脚本在第一轮手工测试完成后还没有完全实现。

　　因此，应当在每一轮手工测试完成后再次确定好自动化测试功能点，以作为下一个阶段自动化脚本开发与测试的对象和范围，避免同项目开发者RD所产生的冲突。这是因为自动化测试，主要是以回归测试和系统测试为需求，只是加强已经手工测试过部分的准确性和客观性。

　　最后，自动化脚本开发还是应当遵循数据或关键字驱动脚本的原则。