4月26日，为期两天的开发者盛会Gopher China完美闭幕。在此次会议上，开发者们除了见到Go语言创始人Robert Griesemer，穿上了神气的“中国版土拨鼠T-shirt”外，还收获到了满满的技术干货。作为Go语言在国内的践行者，七牛云CEO许式伟在Gopher China上为开发者们分享了七牛如何做HTTP服务测试的经验。
基于HTTP协议来提供服务的好处是显然的。除了HTTP服务有很多现成的客户端、服务端框架可以直接使用外，在HTTP服务的调试、测试等工程领域都有现成的相关工具支撑。七牛大量的服务都基于HTTP，所以需要思考如何更有效地进行HTTP服务的测试。
七牛早期HTTP服务的测试方法是先写好服务端，然后写一个客户端SDK，再基于这个客户端SDK写测试案例。这种方法多多少少会遇到一些问题。首先，客户端SDK的修改可能会导致测试案例编不过。其次，客户端SDK通常是使用方友好，而不是测试方友好。服务端开发过程和客户端SDK耦合容易过早地陷入“客户端SDK如何抽象更合理”的细节，而不能专注于测试服务逻辑本身。我的核心诉求是服务端开发过程和客户端开发过程解耦，因为网络协议定好了以后，整个系统原则上就可以编写测试案例，而不用等客户端SDK的完成。
不写客户端SDK而直接做HTTP测试，一个直观的思路是直接基于http.Client类来写测试案例。这种方式的问题是代码比较冗长，而且它的业务逻辑表达不直观，很难一眼看出这句话想干什么。虽然可以写一些辅助函数来改观，但是会逐渐有写测试专用SDK的倾向。这种写法看起来也不是很可取，毕竟为测试写一个专门的SDK，看起来成本有些高了。
七牛当前的做法是引入一种httptestDSL文法。这是七牛为测试写的领域专用语言。这个语言的文法大概在2012年就已经被加入到七牛的代码库，后来有个同事根据这个DSL文法写了第一版本qiniutest程序。在决定推广用这个DSL来进行测试的过程中，我们对DSL不断地进行了调整和加强。虽然总体思路没有变化，但最终定稿的DSL与最初版本有较大的差异。目前来说，我已经可以十分确定地说，这个DSL可以满足90%以上的测试需求。现在所有新写的模块全部基于这套测试案例进行测试，它被推荐做为七牛内部的首选测试方案。
上图是这套DSL的“hello world”程序。执行预期：下载www.qiniu.com首页，要求返回的HTTP状态码为200。如果返回非200，测试失败;否则则测试通过，打印返回包的正文内容(resp.body变量)。打印resp.body通常是调试需要，而不是测试需要。自动化测试是不需要去打印什么的。
我们再看该DSL的一个“quick start(快速入门)”样例。以#开始的内容是程序的注释部分。这里有一个很长很长的注释，描述了一个基本的HTTP请求测试的构成。后面我们会对这部分内容进行详细展开，这里暂时跳过。这段代码的第一句话是定义了一个auth别名叫qiniutest，这只是为了让后面具体的HTTP请求中授权语句更简短。紧接着是发起一个POST请求，创建一个内容为 {"a":"value1", "b": 1}的对象，并将返回的对象id赋值给一个名为id1的变量。后面我们会详细解释这个赋值过程是如何进行的。接着我们发起一个获取对象内容的GET请求，需要注意的是我们GET的URL中引用了id1的值，这意味着我们不是要取别的对象的内容，而是取刚刚我们创建成功的对象的内容，并且我们期望返回的对象内容和刚才我们POST上去的一样，也是{"a":"value1", "b": 1}。这就是一个最基础的HTTP测试，它创建一个对象，确认创建成功，并且尝试去取会这个对象，并确认内容与预期的一致。这里上下两个请求是通过一个变量来关联的。
对我们的DSL文法有了一个大概的印象后，我们开始解剖这套DSL。我们先来看看它的语法结构。首先我们这套httptest DSL基于命令行文法：
command switch1 switch2 …arg1 arg2…
整个命令行先是一个命令，然后紧接着是一个个开关(可选)，最后是一个个的命令参数。和大家熟悉的命令行比如LinuxShell一样，它也会有一些参数需要转义，如果参数包含空格或其他特殊字符，则可以用'\'转义，如'\'表示''，'\t'表示TAB等。另外我们也支持用'…'或者"…"去引用一个比较复杂的文本作为参数，比如json格式的多行文本。同LinuxShell类似，'…'里面的内容没有转义，'\'就是'\'，'\t'就是'\t'，而不是 TAB。而"…"则支持转义。
和Linux Shell 不同的是，我们的httptest DSL虽然基于命令行文法，但是它的每一个参数都是有类型的，也就是说这个语言有类型系统，而不像Linux Shell只有字符串。我们的httptest DSL支持切仅支持所有json支持的数据类型，包括：
string (如："a"、application/json)，在不引起歧义的情况下，可以省略双引号
number (如：3.14159)
boolean (如：true、false)
array (如：["a", 200, {"b": 2}])
dictionary/object (如：{"a": 1, "b": 2})
另外，我们的httptest DSL也有子命令的概念，它相当于一个函数，可以返回任意类型的数据。比如 `qiniu f2weae23e6c9f jg35fae526kbce` 返回一个auth object，这用字符串无法表达。
理解了httptest DSL后，我们来看看如何表达一个http请求。它的基本形式如下：
req<http-method><url>
header<key1><val11><val12>
header<key2><val21><val22>
auth<authorization>
body<content-type><body-data>
第一句是req指令，带两个参数：一个是http method，即http请求的方法，另一个是要请求的URL。，接着是一个个自定义的header(可选)，每个header指令后面跟一个key(键)和一个或多个value(值)。然后是一个可选的auth指令，用来指示这个请求的授权方式。如果没有auth语句，那么这个http请求是匿名的，否则这就是一个带授权的请求。最后一句是body指令，顾名思义它用来指定http请求的正文。body指令也是两个参数，一个是content-type(内容格式)，另一个是body-data(请求正文)。
这样说比较抽象，我们看下实际的例子：
无授权的GET请求：
req GET http://www.qiniu.com/
带授权的Post请求：
req POST http://foo.com/objects
auth'qiniu f2weae23e6c9f jg35fae526kbce'
body application/json'{"a": "hello1", "b":2}'
也可以简写成：
无授权的GET请求：
gethttp://www.qiniu.com/
带授权的Post请求：
posthttp://foo.com/objects
auth'qiniu f2weae23e6c9f jg35fae526kbce'
json'{"a": "hello1", "b":2}'
发起了http请求后，我们就可以收到http返回包并匹配。http返回包匹配的基本形式如下：
ret<expected-status-code>
header<key1><expected-val11><expected-val12>
header<key2><expected-val21><expected-val22>
body<expected-content-type><expected-body-data>
我们先看ret指令。实际上，请求发出去的时间是在ret指令执行的时候。前面req、header、auth、body指令仅仅表达了http请求，但是如果没有调用ret指令，那么系统什么也没有发生。
ret指令可以不带参数。不带参数的ret指令，其含义是发起http请求，并将返回的http 返回包解析并存储到resp的变量中。而对于带参数的ret指令：
ret<expected-status-code>
它等价于：
ret
match<expected-status-code>$(resp.code)
这里我们引入了一个新的指令—— match指令：
七牛所有http返回包匹配的匹配文法，都可以用这个match来表达：
所以本质上来说，我们只需要一个不带参数的ret，加上match指令，就可以搞定所有的返回包匹配过程。这也是我们为什么说match指令是这套DSL中最核心的概念的原因。
和其他自动化测试框架类似，这套DSL也提供了断言文法。它类似于CppUnit或JUnit之类的测试框架提供assertEqual。具体如下：
equal<expected><source>
与match不同，<expected>、<source>中都不允许出现未绑定的变量
与match不同equal要求<expected>、<source>的值精确相等
equalSet<expected><source>
SET是指集合
与equal不同，equalSet要求<expected>、<source>都是array，并且对array的元素进行排序后两者精确相等
equalSet的典型使用场景是list类的API，比如列出一个目录下的所有文件，你可能预期这个目录下有哪些文件，但是不能预期他们会以什么样的次序返回
以上介绍基本上就是这套DSL最核心的内容了。内容非常精简，但满足了绝大部分测试场景的需求。下面我们谈谈最后一个话题：测试环境的参数化。
为了让测试案例更加通用，我们需要对测试依赖的环境进行参数化。比如，为了让测试脚本能够同时用于stage环境和product环境，我们需要把服务的Host信息参数化。另外，为了方便测试脚本入口，我们通常还需要把用户名/密码、AK/SK(公私钥对)等敏感性信息参数化，避免直接硬编码到测试案例中。
为了把服务器的Host信息(也就是服务器的位置)参数化，我们引入了host指令。例如：
host foo.com 127.0.0.1:8888
get http://foo.com/objects/a325gea2kgfd
authqiniutest
ret 200
json '{"a": "hello1", "b": 2}'
这样，后文所有出现请求foo.com地方，都会把请求发送到127.0.0.1:8888这样一个服务器地址。要想让脚本测试另一个测试服务器，那么我们只需要调整host语句，将127.0.0.1:8888调整成其他即可。
除了服务器Host需要参数化外，其他常见的参数化需求是Username/Password、AK/SK(公私钥对)等。AK/SK这样的信息非常敏感，如果在测试脚本里面硬编码这些信息，将非常不方便测试脚本的入库。一个典型的测试环境参数化后的测试脚本样例如下：
其中，env指令用于取环境变量对应的值(返回值类型是string)，envdecode指令则是先取得环境变量对应的值，然后对值进行jsondecode得到相应的object/dictionary。有了$(env)这个对象(object)，就可以通过它获得各种测试环境参数，比如 $(env.FooHost)、$(env.AK)、$(env.SK) 等。
写好了测试脚本后，在执行测试脚本之前，我们需要先配置测试环境：
exportQiniuTestEnv_stage='{
"FooHost":"192.168.1.10:8888",
"AK":"…",
"SK":"…"
}'
exportQiniuTestEnv_product='{
"FooHost":"foo.com",
"AK":"…",
"SK":"…"
}'
这样我们就可以执行测试脚本了：
测试 stage 环境：
QiniuTestEnv=stage qiniutest ./testfoo.qtf
测试 product 环境：
QiniuTestEnv=product qiniutest ./testfoo.qtf
测试是软件质量保障至关重要的一环。一个好的测试工具对提高开发效率的作用巨大。如果能够让开发人员的开发时间从一小时减少到半小时，日积月累你就会得到一个惊人的数据。七牛非常乐意去关注开发人员日常工作过程中的不爽和低效率，我们认为，任何开发效率提升相关的工作，其收益都是指数级的。这也是七牛团队所推崇的做事风格。
本文来源：IT168
责任编辑：
王晓易_NE0011
