历史：

　　加入公司后先后做过UI自动化测试（基于Selenium），HTTP接口测试（基于DWR）和自动化的测试数据准备，面向的产品都是Web应用。

　　现状：

　　UI自动化：为P项目投入的时间和精力多，但使用频度和收益小，早已不再维护用例了。后续加入P项目组参与日常测试，发现P项目的开发相当敏捷，频繁提交和部署，而跑一轮UI自动化用例须要一个半小时，实在是等不起啊==！为A项目搭建的UI自动化个人认为是比较成功的，先是在A项目组做了2周左右的功能测试，熟悉产品。再来写用例得心应手了，也容易抽取主要功能点，把自动化用例运行时间控制在30分钟以内。这套用例在每次上线前都会跑，效果不错，后续是由功能测试人员在维护。

　　HTTP接口测试：P项目组前段时间投入了部分人力写出为数不少的接口测试用例，目前，只有W业务相关用例完善，使用频率高，其他的用例虽然写出来了，但用的比较少，这一点后续要好好改进。

　　自动化数据准备：同样用于P项目，主要通过看开发代码 or 使用在写HTTP接口测试中积累起来的API写一些准备数据的脚本。从目前看，确实可以节约不少人肉测试时间。

　　思考和展望：

　　结合我在P项目组的功能测试经验，有以下想法：

　　一：Web产品常见的是前端页面错误（页面排版错误，JS错误，链接跳转错误。。。），这种错误要么依靠人肉发现，要么依靠UI自动化发现，接口测试是发现不了的。而且，这一层是产品用户直接接触的层级，上线前好做一次全面回归，但单凭人肉是很枯燥的，而且容易遗漏。这时候，UI自动化很有用了！但，UI自动化用例应该少而精，专注于关键的核心功能，把执行时间尽量压缩，至多不超过半小时吧。

　　二：HTTP接口测试运行速度快，稳定性高，可以设计复杂的业务流程，检验一些使用UI自动化无法触及（如：绕过前端JS限制输入非法字符）或很难触及（运行耗时长又不稳定）的功能点。另一方面，一个附带的结果，在写接口测试用例的时候往往可以发现一些隐蔽的历史遗留bug。

　　三：开发和测试是有节奏，总有一段时间是开发很忙而测试在等待提交测试的。我认为可以把这段时间利用起来，或阅读开发代码，或编写测试用例，或写数据准备的脚本。测试开始以后，一方面使用之前准备的自动化脚本准备测试数据，方便手动测试，一方面，每隔一段时间（若干小时，根据开发提交代码的频度）执行HTTP接口测试，跑一轮控制在15分钟，保证功能不出问题（功能出问题，改Bug相对比较麻烦，尽量做到早发现早解决）。接近上线的时候，跑1-2轮UI自动化，单轮时间控制在30分钟，比较全面地回归一下主干功能（这个时候如果还出问题，很可能只是页面显示问题，改Bug也比较快）。结合手动测试，自动化数据准备，UI测试和HTTP测试，发挥各自的长处，把自动化用起来。效果未必立竿见影，但我相信长久坚持在潜移默化间是有效果的！另外，无论是UI自动化还是HTTP自动化，它们积累的API稍加改造可以拿来准备数据，呵呵：）

　　更多话：

　　对于自动化，我的路还很长，接触的东西也还很少，经验也少，也只能在我接触和经历过的范围和深度内提出我认为的佳方案。对于将来，一方面要多调研，多尝试，这一点小云的安卓自动化很好，开辟一条新路出来。走过的路多了，才更知道什么是合适自己的路；一方面要和自动化针对的产品亲密接触，多多了解，贴合项目需求的自动化更容易取得较高的收益。