1.允许测试脚本里调用api。
我们经常在测试时要做一些准备活动，比如注册一个新用户。这一步骤可能每次花费几分钟时间，那么这时候建议直接调用注册用户的api来生成新用户。每个场景节约几分钟，加起来就多了。
2.允许测试脚本里访问数据库。
虽然我们做测试可以说重点在界面上，但是业务逻辑上如果出错了最好也要能找出来。也就是说，我的检查点不止检查页面元素，更先去检查对应数据在数据库里是否正确。好处是数据库里不正确的时候，脚本就不用傻乎乎等个几十秒才报出来页面上的错误。
3.为测试准备独立干净的测试环境。
测试如果针对网站，很多时候要考虑在windows系统上跑脚本。一般建议和工作用的电脑分开。如果有条件，还可以自动化搭建这样的测试环境，我们以前是通过云自动搭建符合要求的虚拟机来做。
4.考虑测试逻辑的重用性。
通常采用页面对象建模，详见selenium官网。如果是商业工具则一般已经自带对象库，如QTP等都自带了。简单来说就是同样的测试逻辑封装在一起，用的时候直接调，改的时候只改一个地方。
5.在开发阶段考虑可测性。
有的app就是不可测，这也动态那也动态，控件各种不标准，自定义。这种是没法做自动化的。比如用selenium去测gmail的网页版，一切都是动态的，那简直疯了也做不成功。相反比如说去看京东的网页，各种标准，再没有比它更适合用selenium测试的了。可测性每提升一丁点儿，自动化测试效率提升一大截。质的改变。
6.采用统一的设计和分层次的设计。
有一个经典问题，在我去一些公司面试时被反复问到，有一个测试场景会用到网站、桌面app、手机app，如何做自动化？
具体点我举个例子，你在手机端拍了一张照片，上传到了网盘上，放下手机在桌面端打开这个照片并做了一些修改和美化，然后在网页端把他展示出去。这个场景如何自动化测试？
如果采用统一的自动化测试设计应当可以解决。不管是桌面的网页的还是手机的，对测试脚本来说都是执行测试的库去负责的，也就是说我写测试只是写业务逻辑，如何执行是那些库的事情。第一层是测试逻辑层，第二层是测试实现层。
这样分开的好处是：1.实现层的工具可能会换，2.可以测试复杂的场景，3，维护人员可以分开，降低测试逻辑层维护人员的技术要求，4，便于大团队的协作。
7.允许半自动化测试
我曾经这么做：脚本负责截图，我事后肉眼人工检查截下来的图，来判断是否有界面错乱之类的问题。好处是实现方便，不用搞什么鬼的图像比对。图像比对完了之后你还是要瞄一眼截图，不然你不放心图像比对的结果，事实上我自己光瞄几眼就看完了所有图片，每种界面截个一两张就够了。
