0. 不讨论什么
我们不讨论那种简单的自动化脚本，用来帮助QA对某个，或某几个testcase进行测试；这样的脚本往往用来代替手工执行testcase里的某些步骤，比如一个在数据库里产生数据的SQL脚本。又比如根据testcase录制了10个Robot脚本，通过replay这些脚本就能完成这个testcase的测试。这种自动化脚本几乎没有任何弊端，它短小和贴近testcase，没有多大的开发开销，它几乎总是能带来测试效率的提高，如果有可能，完全应该去做。
我们也不讨论性能测试。性能测试几乎总是要自动化的，但它和功能测试有太多的不一样。
当然，也不要包括单元测试(white-box)，虽然它的概念可以在功能测试中借鉴，也就是功能单元测试。
下面说到自动化测试框架，都指针对功能的自动化测试框架。
1. 定义
如果让我来定义自动化测试框架，那么它的核心应该是这样一个东西：它提供一套API，这套API对产品的操作做一个包装并提供一个的精简的集合。通过这套操作集合，几乎所有（当然不可能100%)的testcase对产品的操作步骤都可以对应到对这套API的调用。也就是框架提供了一个 ‘产品’ 和 ‘测试脚本’ 的中间层，。一个好的测试框架，可以让自动化脚本看起来象人类语言描述的testcase一样清晰。
2. 好处
假设我们已经有了这样一个测试框架，我们来看它能带来那些好处
1) 首先得益的是smoke test, smoke test总是和DailyBuild联系起来。有严重问题的build当天早上就能发现，不会release给QA。
2) 如果大部分的功能测试都可以被自动化。那么regression test就可以自动化起来。regression test其实是非常非常枯燥但有不得不做的。也许一整天的测试，只是验证了“新的build通过了所有的这些testcase”。如果以bug的数量来衡量QA的工作的话，那么就更令人伤心了。
3) 新功能的测试被翻译为自动化脚本，并加入regression test suite中。庞大的regression test会给QA巨大的信心。
3. 自动化永远不能代替手工测试
一定要认识到： 自动化永远不能代替手工测试。
1) 有些验证根本没法通过程序来验证，或验证起来非常困难，比如程序启动的速度。
2) 在新feature的测试阶段，testcase只能发现30%的defect。但自动化脚本只能基于testcase，所以对新feature的测试，我觉得应该禁止自动化测试。
4. 你需要自动化测试框架吗？
我认为，只要是做产品，都需要这样一个测试框架。测试框架连同它的测试脚本和产品一样都有一个一个的release。好的测试框架会一直伴随产品，为它保驾护航。
5. 失败
有很多搞自动化测试最后失败的公司，这里的失败是指最后放弃了自动化测试。我看到的原因一般是
1) 测试员抱怨框架太难用，在上面开发自动化脚本很耗时
2) 产品变化太大(GUI衰退，学术名字*_~)，要花很多精力和时间来改写测试框架
3) 产品变化太大，很多辛苦开发的自动化脚本在下一个release的产品中不能跑起来
6. 避免失败
那就是高质量的自动化测试框架。
好的框架必须是易于使用的。
好的框架，作为中间层，会尽量减少产品UI的变化对测试脚本的影响。有一句话说在自动化框架的设计中：即使点击一个button都需要写一个函数来包装。这种极端的指导思想来源于下面的考虑：也许这个button会再下一个版本会改成一个link。
好的框架，自身抵抗变化的能力也很强，这要求框架本身是一个设计优良的软件。
7. 如何才能获得高质量的自动化测试框架
如果我们准备开发一个自动化测试框架，我认为需要注意
1） 选择一位精通程序设计和软件测试的开发人员。
一种误解是自动化测试开发只需要普通的测试人员参与就可以了。我不是否定测试人员的能力，而是测试框架开发完完全全是软件的开发。甚至更高一级，相对于软件库的开发，比如它对接口设计和易用性上的要求就相当高。
然后这位开发人员还必须是本软件测试方面的专家，也就是领域专家。有很多软件失败于需求分析，你当然不希望这种事再这里重演。
2） 合适的开发工具
现在商业和开源的开发工具都为数不少。不过我认为在选择的时候要注意两点1）用record&replay来鼓吹易用性的软件。他们也许是好软件，但不是开发测试框架的好软件。框架开发要求工具有强大的功能和灵活性。2）最好选用使用通用语言来开发的软件。通用语言一般都有各种各样的库。我就为用robot的scrīpt来访问mysql的问题相当恼火。
8. 开发自动化测试框架的一些建议
下面是我在开发框架核心API部分中的一些经验
1) 尽量把让测试脚本访问你的API而不是直接操控UI元素。
这即使不是绝对的，也要尽力避免。把变化留给框架。因为我们注意到，产品UI的变化频率和程度都超过功能的变化。UI变化，功能测试的逻辑不会变化，而功能测试在所有的测试中一般是占主要的部分。
2) 针对不同类型的测试，提供多套API
前面说过最好把测试脚本和UI操作完全隔离开来，但考虑到测试的多样性，这往往导致存在多套不同层次的API。
比如一个添加用户的web 页面。针对这个页面的基本功能需要提供一个方法: addUser(name, pswd)。大多数testcase都会调用这个方法作为一个其中的步骤。
假如输入的name具有非法字符检查功能,系统会用javascrīpt及时检查用户输入并在某个页面某个位置把错误信息显示出来。要测试这个功能，上面的方法就不够了。这个时候就需要针对这个页面封装一个页面模型(page model),通过这个页面模型可以访问页面的元素比如
getNameInputBox
getErrorMessage
显然这是两套不同的API，应该分别属于不同的集合。而且最好两套API不要有依赖。
3) 保持框架和测试逻辑分离
API不要包含任何测试逻辑的代码。API是精简，正交的。不要试图提供一些和测试逻辑相关的功能来使得某几个测试脚本更好开发，它反而真正伤害了API。
比如我曾经把验证from里各项数据的方法加到了API里。其实我应该做的是把form里的数据收集出来，以Map的形式返回给调用者。
4) 最好边开发框架，边开发一个精简的regression test suite。
这样能让你早发现框架存在的问题
5) 在release你的API之前，一定要给QA 小规模试用
API发布后就不能更改，所以发布API要谨慎小心。
8. 提外话：关键字驱动的自动化测试
套用一句话是：
Make everything as simple as possible, but not simpler. -- Albert Einstein 我曾经开发过一个测试框架，试图提供一种能力把测试逻辑用xml的tag表达出来。我做了大量的工作来把测试中的action用tag封装起来，在给team member使用后发现，它并不那么受欢迎。原因是
1）熟悉tag是一个负担，特别是tag多了以后，
2）tag的表达能力有限，有些情况不能满足需要，如果要满足需要，tag变得非常复杂。甚至需要引入条件判断的tag。后来我想，如果要使用一个<if> tag，为什么不直接使用编程语言呢？
所以，我认为一门高效易学的脚本语言来写测试脚本是在灵活性和易用性之间的最佳平衡点,python, ruby都是上上之选。关键字驱动？太过了，且不说实现它需要而外的投入，学习这些越来越多的关键字会让QA失去对他最后的耐性。
数据驱动是一个非常棒的测试方法。但要在数据里加上 关键字或者流程控制。。。过犹不及也。
