自动化测试脚本的质量有很多方面，我今天直说我觉得最重要的几个方面：
· 自动化测试脚本互不影响的，隔离的。
· 自动化测试中被测功能是互不影响的
· 自动化测试能够快速定位bug位置
· 自动化测试脚本是易于阅读的，能帮助我们理解产品的
· 自动化测试脚本是易于编写的，易于维护的以及易于扩展的
· 自动化测试脚本互不影响的，隔离的。
我们先说这一点吧，为什么我们的脚本要是互不影响的，隔离的呢。因为我们所有的脚本都是运行在同一个环境的，每个脚本可能都会在这个环境上造成痕迹，这些痕迹可能是数据库的，可能是文件系统的。而这些痕迹造成了case之间互相的影响。举个最常见的例子，本来我们运行的脚本们都很成功，没有什么异常。但是突然有有一天，测试删除数据的脚本由于产品的bug失败了，数据没有真正的被删除。于是乎间接的造成了之后的查询所有数据的脚本失败了。因为之前的脚本没有删除掉数据，现在预期值和返回值不一样了----多了一条数据。这种情况发生在很多场景，可能是case中设置了产品的全局变量，语言的信息等等。下面我们说解决方案。
我最不推崇的做法也是所有人都最喜欢的做法，因为这种做法最简单----严格控制测试数据的使用。例如规定所有脚本不准许更改系统变量；测试某种语言或场景的时候新创建一个项目，不用已有的；维护一个user列表，不准许脚本使用重复的user以免互相影响等等。case量不多的情况很实用
我推崇的做法也是《google 软件测试之道》一书中的做法：任何脚本都不做任何持久化的操作，也就是说测试脚本执行前数据库和文件系统是什么样子，执行之后也是什么样子。环境始终是干净的，对每个测试脚本都是一样的。怎么做呢？ 很简单，你再测试脚本运行中创建的什么数据。你再结束后就删除什么数据。
下面我们分别说说吧，我把第一点称作我最不推崇的，虽然它看起来貌似没什么实现成本。但是这种纯靠所有QA之间的约定和个人的自觉其实很不靠谱。即便我之前在外企的时候有严格的code review流程也很难保证case之间互不影响，更别说国内的测试我基本就没怎么见过有code review这个流程。case数量变多的时候，就慢慢的发现以前埋的坑有多大，很典型的情况就是，测试用例在单独跑的时候怎么跑怎么过。放到server上所有case一起跑的时候怎么跑怎么不过。这时候你还不知道到底是哪个case造成的痕迹导致你的脚本跑不过去的。一出现这种情况一般没个半天一天的根本查不出来到底是以前哪个case造成的痕迹破坏了你的脚本。当然了，如果你说你们项目一共也就一百两百的case量，那就当我没说吧。这种方式很好。
第二种方式我比较推崇，很黄很暴力。绝对杜绝了任何互相影响的可能性。成本比较高，但是可以从框架的角度解决这个问题，这样成本就降低到了一个可以接受的程度了。具体实现可以参考我以前的两个帖子，如下：
1、框架中测试数据的管理策略
2、框架中测试数据的恢复策略
很多人可能会喷我的这个观点，仁者见仁智者见智吧。UI自动化和接口自动化我都用这种方式。
自动化测试中被测功能是互不影响的，隔离的&& 自动化测试能够快速定位bug位置
我把这两点写在一块了，因为解决这两点的方案是一样的。我们以前一定碰见过很多次这样的情况，由于下单这个功能bug了，导致所有依赖下单这个功能的脚本全都失败了。为什么呢？因为用例都是流程性的测试，都是先下单，再查询订单，再更新订单，再评论订单等等。我们把相似的功能都放在数个脚本里测试了。这样的结果有两个，第一是可能因为一个bug导致N个脚本的fail。你需要挨个排查很影响效率。第二是以QA的能力很难定位bug到底出现在哪。举例说明一下，假如脚本在查询订单的时候失败了，你能确定一定是查询订单这个feature出bug了么？不一定吧，可能下单的时候就没入库正确。当然了我只是举个最简单的例子，下单和查询其实还是很容易定位的，但实际情况很复杂。很可能入库的时候的错误在脚本最后的某个功能上才体现出来。例如运行某些task，需要在入库时的一些元数据等等。
解决方案----就是减少流程性的测试。把被测的产品功能打碎了，切成一块一块的个体。一个脚本中只测试一个feature。杜绝了互相影响的同时也简化的bug定位的成本，因为你脚本里只测试了这个feature，失败了就肯定是这个feature的问题了。只要你代码能力还行，直接去看产品源码就能找到bug到底出现在哪一行代码中了，我用这种方式fix过很多个bug。有些同学一定会问，这不可能实现，因为测试当前功能一定要其他功能创建数据啊？那到底怎么做呢？ 方案也很简单--直接在数据库，文件系统，索引等等中插入数据，不使用产品本身的feature创建数据，我们仔细想想，除了单元测试之外，我们的这些功能之间真的有依赖么？ 答案是没有，功能依赖的是数据，是数据库中的数据。你再UI上走一遍流程也就是在数据库中创建了一系列的数据而已。so，如果有同学疑虑说没有流程性测试其实是不完整的测试的话。那你大可不必担心。因为这跟流程性测试根本没区别，有什么流程性测试的数据是你用sql模仿不了的？所以有区别的只是造数据的方式而已。这种方式的脚本成本一般也比较高，因为要清楚产品数据库的结构，要写sql。但是我们同样可以在框架上解决这个问题，同样看我上一点发的两个链接。里面有提及。
