思考自动化测试-框架(二)

思考自动化测试--框架（二）

自动化测试工具其实是千万种的，一般青年，上手就用工具，弄点小工具执行执行脚本，出出报告。文艺青年，写个自动化测试框架把脚本，数据，GUI，结果等组织起来，便于执行管理。好吧2X青年，就是回放录制，回放录制。
自动化测试工具，商业的，开源的，有好多。很多工具主要完成的是执行本身，而自动化测试框架是一种组织方式，更多的是使用自动化测试的人怎么使用自动化测试的方式。自动化测试框架是由不同部分综合而成，在于你在每个点怎么看待怎么用自动化测试测试自己的系统，工具与被测系统不同，可能答案不同。下面我就简单说说自动化测试的框架各个部分：（PS：其实，有的人已经发现了，我上面说的自动化测试，已经专指根据界面进行end-to-end的测试了。）

测试脚本（GUI+操作+数据）

很多自动化测试框架，都在沿用传统的关键字驱动方式，通过维护一张（GUI+操作+数据）为记录的表，来根据这张表执行自动化测试。为什么要这么做呢？乍一看，维护简单，心一想，这么简单手工测试也可以搞。多好啊。来看个例子：

操作对象	操作	数据
browser	open	http://www.baidu.com
id=kw	type	automation
id=su	click
page	assertContain	automation

其实我并不推荐这种方式，被测系统千遍万化，测试流程，校验方式不尽相同，简单的一张表很难涵盖所有内容，反而束缚了自动化测试脚本的灵活性。测试脚本就是测试脚本，可能就是一个代码文件，没有必要把他整理出来，弄得只是好看而不实用。(PS:不过如果你的自动化测试本来就不复杂，那么这个方式也是可以考虑的，还是要记住原则只是多数情况，遇到问题要具体问题具体分析)

准备测试数据

自动化测试的优点就是程序可以不知疲惫的进行测试，那么一个测试脚本，给他不断输送数据，不就能做更多的测试嘛。思路简单，难点在测试数据怎么来，有几种方法，我也简单分析一下：

• 静态数据：

  • 写在脚本里，这样数据不太灵活，也不好维护，一般不推荐这样。
  • 写到文件或者数据库里，有的时候自动化测试会使用一批数据，或者批量的设计数据，可以将这些数据写到文件或者数据库里，脚本读取文件或者数据，这样便于维护。
  • 初始化数据状态，不论使用上述哪种静态数据的方式都可以在加上对静态数据状态的初始化，而达到数据准备的目的。

• 动态数据：

  • 随机生成数据，有些数据可以是使用随机发生器生成随机数据，这样测试有一定的随机性有利于测试，并且可以降低一些数据准备的成功
  • 随机抽取数据：可以从数据库中随机抽取可用的数据。这种方式需要保证数据库里有足量可用数据
  • 枚举生成数据，一般这种数据生成，主要是为了测试全面，保证各种情况下的数据都可通过，穷举所有参数的不同枚举值，然后排列组合所有情况形成大量的数据，进行自动化测试。

这么多方法，在实际使用中，可能不能单一使用一种方法，而是上述方法组合使用，在不同的场景下使用不同的方式，框架需要尽量多的支持这些数据准备方式。

执行方式

上面说了，测试执行使用的脚本，说了测试数据的准备，下面就直接说说怎么执行脚本。是不是就是直接运行就好了？自动化测试的特点是可以低成本的执行，所以要充分利用这个特点，执行方式越灵活越好，可以轻便地组织测试用例集，手工执行，手工定时执行，周期执行，最好还能和CI工具融合起来在日常构建项目后执行测试。当然，大量的执行脚本也可以通过分布式的方式，分布执行，从而通过增加设备来提高执行效率。

测试结果整理

测试执行完，会受到大量的结果报告，自动化测试结果是一定要需要分析的，有些可能是测试环境的问题，而不是程序本身的问题，甚至有可能是自动化测试脚本本身的问题，这些需要分析记录（包括：提交缺陷）。这里建议在进行测试结果收集的时候，获取程序的一些性能数据，比方说响应时间了，打开速度了，把这些性能数据也保存下来。虽然测试环境的性能数据不能保证指标的完全真实可靠，但是也是一种参考，在项目不断迭代，可以从这些细小的性能数据发现迭代导致程序的性能下降的问题。

Mock测试环境

Mock是什么？Mock，我这里只是借用了单元测试里的概念。这里所说的Mock测试环境，包括被测系统内部模块的Mock，也包括外围系统的Mock。Mock简单的说，就是个模块（程序）或者系统，我用测试代码去代替，测试执行中，并没有去执行实际的代码，而是执行的测试代码。而这些测试代码一般都是比较简单的返回，并没有具体的逻辑处理。这里举两个例子，比方说我们写了一个电商网站，然后支付使用的是支付宝，那么做支付测试的时候，那么我们就用一个模拟的支付宝接口（可以接受付款请求并返回付款完成消息）来代替真实的接口，测试的时候，使用“假”接口，来主要测试我们自身系统中是否有问题，而减少了联调测试的消耗；还有，就是比较常见的在Web项目里，我们测试前台的时候（可能后台都没有开发完），我们在测试里，可以写Mock方法让后台返回我们指定的结果，而并不做逻辑操作更不会读取数据库。从上面的例子我们看出来了，其实Mock测试就很有利于分层测试，而且本身在单元测试中也使用的的非常的多。但是，要明确这种方式不是end-to-end的测试，测试不够全面，与真实环境有差异，那么要用，可不要乱用（Mock虽好，可不要贪用哦）。

总的来说，自动化测试框架其实更多的是基于在自动化测试认识的基础上的一种管理维护方法，只是可能这种框架需要写代码支持而已。根据不同的被测系统，不同的测试方法，不同的测试工具，根据实际情况选择不同的方法，是做自动化测试框架最好的思路。因地制宜，切记不要老是想做臃肿的自动化测试产品最后发现根本用不起来。