自动化思考和展望

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

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

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