测试执行器做了什么
这一节介绍下测试执行器
最开始是没有测试执行器的，这时的自动化测试是这样子的：
这种形式有很多问题：
- 测试执行比较麻烦，因为有很多个脚本，需要一个一个去执行。
- 测试报告的生成比较麻烦，因为会产生很多个测试结果1234..，需要汇总成一个总的测试结果，才能得到测试报告。
- 测试用例的结构调整很麻烦，比如第一次冒烟测试要跑脚本123，第二轮测试要跑脚本125679，第三轮要跑脚本14678。此时对执行脚本的人来说是一个挑战，当有些用例需要频繁重跑，有些需要偶尔重跑时，我们也很难调整测试用例的结构。
于是很快就有人开发出了测试执行器，测试执行器们被称之为Xunit系列，这个Xunit系列的家族成员有Junit，Cunit，Nunit，Cppunit等等，其他常见的如TestNg，ruby testunit，python unittest之类的也都可以看做是Xunit 系列的。Xunit 是做什么的呢？引入了Xunit 测试执行器之后，自动化测试变成了这样：
用户给Xunit一个命令，比如：我要执行脚本1、2、3，然后用户就可以等结果了。
Xunit会按照一定规则去寻找测试脚本，然后执行脚本，并记录对应脚本的执行时间、执行结果、出错日志等信息，然后返回一个汇总的测试结果。这样就解决了之前的三个问题：
- 测试执行有了统一入口。
- 测试报告能自动生成。
- 通过给Xunit不同命令来决定执行不同脚本。
其他测试执行器
这里值得一提的是，最初大部分测试执行器都是类似于Xunit的形式来做的，但后来，又有一些新的框架工具出来，也就有了其他类型的测试执行器，比如：
- 关键宇驱动类型的测试执行器，代表为robotframework除了Xunit以外，只有关键字驱动型使用最广泛。另外，robot 框架本身的设计虽然有一些缺点，但也有很多值得借鉴的点。比如robot中的等待，是做的非常好的，相比selenium 里令人困惑的显式等待和隐式等待，robot 提供了更普适的等待方法。robot的数据驱动模板，也是一种不错的数据驱动开形式。
- 业务驱动类型的测试执行器，代表为cucumber这种类型的特点是，有一层伪代码。伪代码试图用接近自然语言的方式来描述测试用例，但实际上，却根本不接近于自然语言。cucumber的伪代码标志性的 given when then根本不符合一般人说英语的习惯。然后cucumber使用正则表达式来翻译这些伪代码中的关键字，找到代码中对这些关键字定义的方法，来执行伪代码想要执行的真正代码。不得不说，这是一种十分麻而别扭的做法。大多数人既不熟悉伪代码编写形式，也不想熟悉这种没用的东西。只有在一些重视业务的或者领导不懂技术听别人瞎吹一通就信了的项目中，会使用这种工具。如果你的工作是写伪代码或类似伪代码的东西，美其名日自动化测试的，那请你尽早考虑跳槽吧。写伪代码是没有前途的。
- 其他稀奇古怪的测试执行器，比如用wiki页面来驱动的测试执行器fitness。这些奇葩工具的代表是fitness，特色是连版本控制系统都没有办法使用。这种完全是历史长河下遗留的破烂玩具。这类工具从被创造出来起，就没有什么真实项目中会去用。一般只有学校里拍脑袋胡思乱想的老师和公司里完全不懂技术的领导会决定让底下的人去用这类执行器。比上面那种更没前途。如果说业务驱动型测试执行器在特定场景下（让业务人员或需求人员写伪代码的场景下）可能还是适用的，那这一类就是根本不适用于任何场景。
- 商业工具自带的测试执行器。最后是商业工具比如QTP（现在叫UTF了）自己带了个测试执行器。这种比上面那种还要失败。这种仅仅是给非测试技术人员用的。我们作为测试技术人员，根本不屑于去使用商业工具。因为这类商业工具就是设计给不懂技术的人用，以让不懂技术的人也能做某种程度上的自动化测试为卖点的。一般只有二十年前的项目和完全不懂测试的领导会选这种测试执行器。如果你的工作是使用商业工具做测试，那会严重损害你的技术路线成长可能性，建议你尽早换工作，否则过几年跳槽你连应届生都不如。
