懒人的自动化测试之路-框架概念篇

接触自动化大约有两年的时间了，作为这一领域的入门级选手，却时常会被一些同学们问起：

你是如何接触到自动化的？

你们平常主要是做哪些工作？

你们还做系统的功能测试吗，写代码多吗？

你们用什么工具？

你们用录的还是自己写？

什么是框架？

….

问的多了，自然会习惯性的去总结这些问题的答案。其实，在我看来，自动化不仅是一项技术，一个工具。它是一种概念，一种解决方案，它无处不在。

案例一，我的第一个自动化脚本

有些同学在认为自动化测试领域高级，神奇的同时，又往往抱怨自己平常琐事太多，没有时间，没有机会学习这些高大上的技术。其实恰恰相反，自动化测试之所以诞生，就是为了给测试人员节省时间。

在我所就职的公司，每天上班第一件事，就是打开电脑，登陆网络认证系统。验证往往需要1-2分钟时间左右。

久而久之，我开始犯懒。于是，我的第一套自动化脚本诞生了：

如右图示意：

首先，我去除了系统登陆验证，为机器设定了自动开机任务

其次，我用qtp完成了对上网验证系统的一系列操作，然后为我的系统设定了开机后自动调用我的qtp脚本。

最后，为了安全起见，我设定了自动调用某个锁屏工具。

从此，每天早晨一到公司，就可以看到一个已经整装待发的win7界面对我笑脸相迎。

【总结】：很多先进的东西，都是懒人想出来的，本人很荣幸的成为懒人一族。所以，行动起来吧，让公司的上网认证系统成为你的自动化之路的第一只小白鼠吧！

案例二，我的第一批自动化脚本

大多数公司的核心业务系统，都承载着太多的测试数据生成功能。这个艰巨的任务往往会理所应当的降临到该系统的测试人员身上。很不幸的，我就是这样一个系统的测试人员。

为别人造数据，大概经历了这样一个过程

在脚本生成的初期，我一直采用录制的方式。然而，当一套脚本需要兼顾多个业务类型的数据，录制功能的弊端开始显现。因此，我需要借助代码自身的优势以便让我的脚本顺利的按照指定的要求跑出合理的数据。与此同时，为了让我的脚本同时在造数据的同时兼顾测试的攻效，我需要处理一些基本的逻辑。代码的加入解决了从输入到输出过程中一些根本性的问题，例如：

1， 输入数据的参数个性化读取。

2， 业务逻辑的个性化配置和工作流走向。

3， 功能验证点的定制化要求。

从此，当别人再索要数据时，我只需要修改相关的配置文件，点一个按钮，喝一杯茶。

【总结】： 解决一个问题的方法有很多种，但人们往往喜欢最能让你犯懒的那一种。

案例三，我的第一套自动化测试框架

到底什么是自动化测试框架？这是每个初学者貌似都很难理解的问题。因为他们发现，很多貌似强悍的高手们，都是以搭建框架为一个自动化测试项目的入口，以至于很多人在还没有了解自动化测试基本理论时，就在研究什么是框架，甚至讨论我们应该选择什么思想的框架。其实，这对于学习自动化测试的同学来说是本末倒置的。

举一个形象的例子，如果把用于自动化测试的测试用例比作两个轮胎，那么自行车就好比手工测试，是人工驱动轮子前进的方式。

当懒人们厌倦了骑行，便产生了一种叫做“发动机”的东西，我们常见的自动化测试工具QTP，Selenium就负责担任这样一种角色。

有了发动机，人们很自然的开始探索如何将座椅，外壳，窗户，甚至导航等等一系列的组件和发动机有机的结合，让自己更加

的舒适，方便。一个具备驱动发动机执行测试用例功能自动化脚本，就好比一辆小型汽车。