脚本组成部分

这篇都是概念性的东西，不用记，了解即可，后面章节有更实际的内容和例子。

如果我们不用任何测试执行器，那么写出来的测试脚本，如果是用python写的，就是一个又一个的普通脚本文件，其执行顺序是从上往下。

而大多数的测试执行器普遍引入了自己独特的执行顺序，为了让我们理解他的执行顺序，这些测试执行器往往会给测试脚本的各个组成部分其一些名称：

比如最常见的：TestSuite-TestCase-TestMethod

像这样：

上图左边是测试套件，测试套件里包含很多测试用例，测试用例里又包含很多测试方法。

TestMethod：测试方法

这是真正定义测试业务逻辑的地方。有些测试执行器会对测试方法的命名有一些要求，比如以“test”开头的方法名。也有一些测试执行器用标签的形式，比如子啊方法名上用@testxxx之类的来表示这个方法是一个测试方法。

假设我们要测一个在线购物网站，那么测试方法的名字可能是：test_登录成功，test_把商品加入购物车，test_清空购物车，等等。（实际脚本一般不用中文测试方法名，这里只是为了介绍一下。。。）

TestCase：测试用例

这个级别比测试方法高一点。有些测试执行器对测试用例也会有命名要求和一些规范。比如有些测试执行器，会要求测试用例必须写成一个类，而且这个类要继承这个执行器提供的一个基类。也有一些执行器会限制地比较宽松，比如没有命名要求。

仍旧是在线购物网站的例子，那么可能会是：

用例1_测试登录登出

用例2_测试购物车功能

然后这些用例里分别放入对应的测试方法。
值得一提的是，测试用例写得大写得小的粒度，就像写作文分段落一样，不同的人都用不同的把握。所以以用例数量论英雄是很不靠谱。什么，你一天跑几百个case？你的几百个case说不定还没我十个case测的东西多。。。

另外，有很多时候，一个case就是一个文件，当然你也可以把很多case 写进一个文件里，不过我很少这么做。。。因为单个文件不宜过大，行数不宜过多。

TestSuite：测试套件

这个指的是一组测试用例。为什么要有这种东西，我就直接跑测试用例不就行了？因为，测试用例有时候需要分组，分了组就可以每次按需要跑用例。

举个例子，假如有一个软件，里面有八个模块，今天的新版本只在第八个模块上做了一个小改动，那么我可能只跑第八个模块的十几个case.如果这些case碰巧在一个套件里，那么只要运行这一个套件就可以啦。

也有一些测试执行器会淡化测试套件的概念（测试套件的概念在很多Java系的执行器里至关重要）。怎样淡化呢，比如通过分组标签功能来做到这一点，用户在自己的测试用例里打上不同标签，要执行的时候可以按照标签来执行。比如，我们给一堆属于不同套件的case打上“回归测试”、“冒烟测试”之类的标签，也可以打上作者标签，比如“team_1″，“陨石小队”，亦或者模块名的标签，如“管理后台模块”、“登录模块”，然后在执行的时候，可以自由组合不同的标签来个性化定制这次执行要跑的用例。

脚本执行顺序

说回到执行顺序上来，当我们一次要跑很多个测试用例或者测试套件，测试方法时，测试执行器会以怎样的顺序来执行这些东西呢？

有以下几种主流做法：

1.随机

第一个流派就是很奇葩的随机流派。很多新人的脚本跑不通就是因为在第一个case里做了登录，第二个case里做了业务逻辑，结果测试执行器随机执行，先跑了第二个case。..
但随机流是有其意义的，它的设计思路上的大前提是：所有测试用例或者测试方法，同一级别的东西之间是互相独立的。也就是说，你的几百个case之间都是没有相互依赖的，不存在必须第一个跑完才能跑第二个，如果存在，说明你用法错了，比如前面提过的登录，按照随机流的测试执行器的设计思路，每个需要登录的case里都得包含自己的登录步骤。

这种流派是应用最广泛的，因为测试执行器的另一个名字叫单元测试框架，这些测试执行器最初被设计用于执行单元测试，而单元测试往往是互相没有依赖的。

2.按名字顺序

有一些执行器并不是随机执行的，而是很单纯的按照命名的字母顺字执行用例或方法。这种测试执行器也有不少。也有一些看似是按名字顺序的，但实际是随机的，或者用例是按名字顺序执行，方法随机顺序。..这种就请大家注意分辨了。但最好，最好还是实现出互相不依赖的用例，互相之间不依赖的用例好处很多，以后可以通过修改测试执行器等方式，来实现并行或者分布式执行测试用例，大大提高测试执行速度。

特别提一下，在测试执行器层面做分布式或并行，比在测试脚本内部做更好。在测试脚本内部做这种事情，会让调试和日志收集变得很麻烦。没错，这类在脚本内部做分布式的框架的一个代表就是selenium Grid这种奇怪的东西…不建议用。