在一次会议中，我听到了自动化测试脚本这个东西，我自己对这个不是很理解。后来就去了解一下。首先理清自动化测试的概念，广泛的说，自动化包括一切通过工具（程序）的方式来代替或辅助手工测试的行为都可以看做自动化，包括性能测试工具（loadrunner、jmeter）,或自己所写的一段程序，用于生成1到100个测试数据。狭义上来讲，通工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。当然，我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。
如果说到这，你还不知道什么是自动化测试，那我就给大家举个例子。自动化测试到底是什么？我们可以简单的理解为前期通过人工编码完成框架，后期来解放人力并自动完成规定的测试。更通俗点可以这么理解：现在有小强1号和2号两个机器人，你对其中的小强1号机器人进行编码告诉他“在每天中午12点的时候给小强2号机器人一巴掌”，那么当到了中午12点的时候小强1号机器人就会按照你的编码要求执行，并给小强2号机器人一巴掌，这样你就可以干其他事情去了，不需要自己来做，解放了人力，提升了效率（莫名的感觉到自己的脸被打了一巴掌啊）。讲到这里大家应该大致明白什么是自动化测试了吧。
什么项目适合做自动化测试？
假如你已经决定要学习自动化测试了，如何学习是要面临的下一个问题？这个问题以被测试产品为出发点进行分析，假如你所学的技术不能得到应用（验证），将会使你的学习过程寸步难行。首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。
软件需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
项目周期较长
由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
自动化测试脚本可重复使用
自动化测试脚本的重复使用要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；所选择的测试工具是否适应这种差异；最后，测试人员是否有能力开发出适应这种差异的自动化测试框架。