发表于 更新于 分类于 ，

在刚开始实现ApiTestEngine的时候，卡斯（kasi）提议做一个Java版的。对于这样的建议，我当然是拒绝的，瞬即回复了他，“人生苦短，回头是岸啊”。

当然，我没好意思跟他说的是，我不会Java啊。不过最主要的原因嘛，还是因为Python的语法简洁，可以采用很少的代码量实现丰富的功能。

有多简洁呢？

刚在coveralls上看了下ApiTestEngine框架的代码统计行数，总行数只有268行，还不足300行。

当然，这个行数指的是框架本身的Python代码行数，不包括示例注释的行数。从上图可以看出来，LINES列是文件总行数，RELEVANT列是实际的Python代码行数。例如ate/runner.py文件，注释的行数是远多于实际代码行数的。

最极端的一个例子是，ate/testcase.py文件中的parse函数，示例注释行数35行，Python代码只有2行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
def parse(self, testcase_template):
   """ parse testcase_template, replace all variables with bind value.
   variables marker: ${variable}.
   @param (dict) testcase_template
       {
           "request": {
               "url": "http://127.0.0.1:5000/api/users/${uid}",
               "method": "POST",
               "headers": {
                   "Content-Type": "application/json",
                   "authorization": "${authorization}",
                   "random": "${random}"
               },
               "body": "${data}"
           },
           "response": {
               "status_code": "${expected_status}"
           }
       }
   @return (dict) parsed testcase with bind values
       {
           "request": {
               "url": "http://127.0.0.1:5000/api/users/1000",
               "method": "POST",
               "headers": {
                   "Content-Type": "application/json",
                   "authorization": "a83de0ff8d2e896dbd8efb81ba14e17d",
                   "random": "A2dEx"
               },
               "body": '{"name": "user", "password": "123456"}'
           },
           "response": {
               "status_code": 201
           }
       }
   """
   return self.substitute(testcase_template)

另外，如果算上单元测试用例的行数（731行），总的Python代码行数能达到1000行的样子。嗯，代码可以精简，但是单元测试覆盖率还是要保证的，不达到90%以上的单元测试覆盖率，真不好意思说自己做了开源项目啊。

那这不足300行的Python代码，实际实现了哪些功能呢？

对比下《接口自动化测试的最佳工程实践（ApiTestEngine）》中规划的特性，已经实现了大半（前六项），至少已经算是一个有模有样的接口测试框架了。

  • 支持API接口的多种请求方法，包括 GET/POST/HEAD/PUT/DELETE 等
  • 测试用例与代码分离，测试用例维护方式简洁优雅，支持YAML/JSON
  • 测试用例描述方式具有表现力，可采用简洁的方式描述输入参数和预期输出结果
  • 接口测试用例具有可复用性，便于创建复杂测试场景
  • 测试执行方式简单灵活，支持单接口调用测试、批量接口调用测试、定时任务执行测试
  • 具有可扩展性，便于扩展实现Web平台化
  • 测试结果统计报告简洁清晰，附带详尽日志记录，包括接口请求耗时、请求响应数据等
  • 身兼多职，同时实现接口管理、接口自动化测试、接口性能测试（结合Locust）

后面剩下的特性还在实现的过程中，但是可以预见得到，最后框架本身总的Python代码行数也不会超过500行。

当然，单纯地比代码行数的确是没有什么意义，写得爽写得开心才是最重要的。

最后引用下Guido van Rossum的语录：

Life is short, go Pythonic!

阅读更多

最后的最后

《ApiTestEngine 演进之路》系列文章还在继续写，只是前几天主要精力在编码实现上，博客方面没有同步更新，接下来我会整理好思路，继续完成余下的部分。

另外，如果大家对Python编程感兴趣，给大家推荐一个专注Python原创技术分享的公众号，⎡Python之禅⎦（VTtalk），里面关于Python的干货非常多，讲解也很通俗易懂，现在我如果有理解得不够透彻的概念，基本都会先到这个公众号里面去搜索下。

发表于 更新于 分类于 ，

在《ApiTestEngine 演进之路（0）开发未动，测试先行》一文中，我对ApiTestEngine项目正式开始前的准备工作进行了介绍，包括构建API接口服务（Mock Server）、搭建项目单元测试框架、实现持续集成构建检查机制（Travis CI）等。

接下来，我们就开始构建ApiTestEngine项目的基础框架，实现基本功能吧。

接口测试的核心要素

既然是从零开始，那我们不妨先想下，对于接口测试来说，最基本最核心的要素有哪些？

事实上，不管是手工进行接口测试，还是自动化测试平台执行接口测试，接口测试的核心要素都可以概括为如下三点：

  • 发起接口请求（Request）
  • 解析接口响应（Response）
  • 检查接口测试结果

这对于任意类型的接口测试也都是适用的。

在本系列文章中，我们关注的是API接口的测试，更具体地，是基于HTTP协议的API接口的测试。所以我们的问题就进一步简化了，只需要关注HTTP协议层面的请求和响应即可。

好在对于绝大多数接口系统，都有明确的API接口文档，里面会定义好接口请求的参数（包括Headers和Body），并同时描述好接口响应的内容（包括Headers和Body）。而我们需要做的，就是根据接口文档的描述，在HTTP请求中按照接口规范填写请求的参数，然后读取接口的HTTP响应内容，将接口的实际响应内容与我们的预期结果进行对比，以此判断接口功能是否正常。这里的预期结果，应该是包含在接口测试用例里面的。

由此可知，实现接口测试框架的第一步是完成对HTTP请求响应处理的支持。

HTTP客户端的最佳选择

ApiTestEngine项目选择Python作为编程语言，而在Python中实现HTTP请求，毫无疑问，Requests库是最佳选择，简洁优雅，功能强大，可轻松支持API接口的多种请求方法，包括GET/POST/HEAD/PUT/DELETE等。

并且，更赞的地方在于，Requests库针对所有的HTTP请求方法，都可以采用一套统一的接口。

1
requests.request(method, url, **kwargs)

其中，kwargs中可以包含HTTP请求的所有可能需要用到的信息，例如headers、cookies、params、data、auth等。

这有什么好处呢？

好处在于，这可以帮助我们轻松实现测试数据与框架代码的分离。我们只需要遵循Requests库的参数规范，在接口测试用例中复用Requests参数的概念即可。而对于框架的测试用例执行引擎来说，处理逻辑就异常简单了，直接读取测试用例中的参数，传参给Requests发起请求即可。

如果还感觉不好理解，没关系，直接看案例。

测试用例描述

在我们搭建的API接口服务（Mock Server）中，我们想测试“创建一个用户，该用户之前不存在”的场景

在上一篇文章中，我们也在unittest中对该测试场景实现了测试脚本。

1
2
3
4
5
6
7
8
9
10
11
12
def test_create_user_not_existed(self):
   self.clear_users()

   url = "%s/api/users/%d" % (self.host, 1000)
   data = {
       "name": "user1",
       "password": "123456"
   }
   resp = self.api_client.post(url, json=data)

   self.assertEqual(201, resp.status_code)
   self.assertEqual(True, resp.json()["success"])

在该用例中，我们实现了HTTP POST请求，api_client.post(url, json=data)，然后对响应结果进行解析，并检查resp.status_code、resp.json()["success"]是否满足预期。

可以看出，采用代码编写测试用例时会用到许多编程语言的语法，对于不会编程的人来说上手难度较大。更大的问题在于，当我们编写大量测试用例之后，因为模式基本都是固定的，所以会发现存在大量相似或重复的脚本，这给脚本的维护带来了很大的问题。

那如何将测试用例与脚本代码进行分离呢？

考虑到JSON格式在编程语言中处理是最方便的，分离后的测试用例可采用JSON描述如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
   "name": "create user which does not exist",
   "request": {
       "url": "http://127.0.0.1:5000/api/users/1000",
       "method": "POST",
       "headers": {
           "content-type": "application/json"
       },
       "json": {
           "name": "user1",
           "password": "123456"
       }
   },
   "response": {
       "status_code": 201,
       "headers": {
           "Content-Type": "application/json"
       },
       "body": {
           "success": true,
           "msg": "user created successfully."
       }
   }
}

不难看出，如上JSON结构体包含了测试用例的完整描述信息。

需要特别注意的是，这里使用了一个讨巧的方式，就是在请求的参数中充分复用了Requests的参数规范。例如，我们要POST一个JSON的结构体，那么我们就直接将json作为request的参数名，这和前面写脚本时用的api_client.post(url, json=data)是一致的。

测试用例执行引擎

在如上测试用例描述的基础上，测试用例执行引擎就很简单了，以下几行代码就足够了。

1
2
3
4
5
6
7
8
9
10
11
12
13
def run_single_testcase(testcase):
   req_kwargs = testcase['request']

   try:
       url = req_kwargs.pop('url')
       method = req_kwargs.pop('method')
   except KeyError:
       raise exception.ParamsError("Params Error")

   resp_obj = requests.request(url=url, method=method, **req_kwargs)
   diff_content = utils.diff_response(resp_obj, testcase['response'])
   success = False if diff_content else True
   return success, diff_content

可以看出，不管是什么HTTP请求方法的用例，该执行引擎都是适用的。

只需要先从测试用例中获取到HTTP接口请求参数，testcase['request']：

1
2
3
4
5
6
7
8
9
10
11
{
  "url": "http://127.0.0.1:5000/api/users/1000",
  "method": "POST",
  "headers": {
      "content-type": "application/json"
  },
  "json": {
      "name": "user1",
      "password": "123456"
  }
}

然后发起HTTP请求：

1
requests.request(url=url, method=method, **req_kwargs)

最后再检查测试结果：

1
utils.diff_response(resp_obj, testcase['response'])

在测试用例执行引擎完成后，执行测试用例的方式也很简单。同样是在unittest中调用执行测试用例，就可以写成如下形式：

1
2
3
4
5
def test_run_single_testcase_success(self):
   testcase_file_path = os.path.join(os.getcwd(), 'tests/data/demo.json')
   testcases = utils.load_testcases(testcase_file_path)
   success, _ = self.test_runner.run_single_testcase(testcases[0])
   self.assertTrue(success)

可以看出，模式还是很固定：加载用例、执行用例、判断用例执行是否成功。如果每条测试用例都要在unittest.TestCase分别写一个单元测试进行调用，还是会存在大量重复工作。

所以比较好的做法是，再实现一个单元测试用例生成功能；这部分先不展开，后面再进行详细描述。

结果判断处理逻辑

这里再单独讲下对结果的判断逻辑处理，也就是diff_response函数。

1
2
3
4
5
6
7
8
9
def diff_response(resp_obj, expected_resp_json)
    diff_content = {}
    resp_info = parse_response_object(resp_obj)

    # 对比 status_code，将差异存入 diff_content
    # 对比 Headers，将差异存入 diff_content
    # 对比 Body，将差异存入 diff_content

    return diff_content

其中，expected_resp_json参数就是我们在测试用例中描述的response部分，作为测试用例的预期结果描述信息，是判断实际接口响应是否正常的参考标准。

而resp_obj参数，就是实际接口响应的Response实例，详细的定义可以参考requests.Response描述文档。

为了更好地实现结果对比，我们也将resp_obj解析为与expected_resp_json相同的数据结构。

1
2
3
4
5
6
7
8
9
10
11
def parse_response_object(resp_obj):
    try:
        resp_body = resp_obj.json()
    except ValueError:
        resp_body = resp_obj.text

    return {
        'status_code': resp_obj.status_code,
        'headers': resp_obj.headers,
        'body': resp_body
    }

那么最后再进行对比就很好实现了，只需要编写一个通用的JSON结构体比对函数即可。

1
2
3
4
5
6
7
8
9
10
11
12
def diff_json(current_json, expected_json):
    json_diff = {}

    for key, expected_value in expected_json.items():
        value = current_json.get(key, None)
        if str(value) != str(expected_value):
            json_diff[key] = {
                'value': value,
                'expected': expected_value
            }

    return json_diff

这里只罗列了核心处理流程的代码实现，其它的辅助功能，例如加载JSON/YAML测试用例等功能，请直接阅读阅读项目源码。

总结

经过本文中的工作，我们已经完成了ApiTestEngine基础框架的搭建，并实现了两项最基本的功能：

  • 支持API接口的多种请求方法，包括 GET/POST/HEAD/PUT/DELETE 等
  • 测试用例与代码分离，测试用例维护方式简洁优雅，支持YAML/JSON

然而，在实际项目中的接口通常比较复杂，例如包含签名校验等机制，这使得我们在配置接口测试用例时还是会比较繁琐。

在下一篇文章中，我们将着手解决这个问题，通过对框架增加模板配置功能，实现接口业务参数和技术细节的分离。

阅读更多

发表于 更新于 分类于 ，

在《接口自动化测试的最佳工程实践（ApiTestEngine）》一文中，我详细介绍了ApiTestEngine诞生的背景，并对其核心特性进行了详尽的剖析。

接下来，我将在《ApiTestEngine演进之路》系列文章中讲解ApiTestEngine是如何从第一行代码开始，逐步实现接口自动化测试框架的核心功能特性的。

相信大家都有听说过TDD（测试驱动开发）这种开发模式，虽然网络上对该种开发模式存在异议，但我个人是非常推荐使用该种开发方式的。关于TDD的优势，我就不在此赘述了，我就只说下自己受益最深的两个方面。

  • 测试驱动，其实也是需求驱动。在开发正式代码之前，可以先将需求转换为单元测试用例，然后再逐步实现正式代码，直至将所有单元测试用例跑通。这可以帮助我们总是聚焦在要实现的功能特性上，避免跑偏。特别是像我们做测试开发的，通常没有需求文档和设计文档，如果没有清晰的思路，很可能做着做着就不知道自己做到哪儿了。
  • 高覆盖率的单元测试代码，对项目质量有充足的信心。因为是先写测试再写实现，所以正常情况下，所有的功能特性都应该能被单元测试覆盖到。再结合持续集成的手段，我们可以轻松保证每个版本都是高质量并且可用的。

所以，ApiTestEngine项目也将采用TDD的开发模式。本篇文章就重点介绍下采用TDD之前需要做的一些准备工作。

搭建API接口服务（Mock Server）

接口测试框架要运行起来，必然需要有可用的API接口服务。因此，在开始构建我们的接口测试框架之前，最好先搭建一套简单的API接口服务，也就是Mock Server，然后我们在采用TDD开发模式的时候，就可以随时随地将框架代码跑起来，开发效率也会大幅提升。

为什么不直接采用已有的业务系统API接口服务呢？

这是因为通常业务系统的接口比较复杂，并且耦合了许多业务逻辑，甚至还可能涉及到和其它业务系统的交互，搭建或维护一套测试环境的成本可能会非常高。另一方面，接口测试框架需要具有一定的通用性，其功能特性很难在一个特定的业务系统中找到所有合适的接口。就拿最简单的接口请求方法来说，测试框架需要支持GET/POST/HEAD/PUT/DELETE方法，但是可能在我们已有的业务系统中只有GET/POST接口。

自行搭建API接口服务的另一个好处在于，我们可以随时调整接口的实现方式，来满足接口测试框架特定的功能特性，从而使我们总是能将注意力集中在测试框架本身。比较好的做法是，先搭建最简单的接口服务，在此基础上将接口测试框架搭建起来，实现最基本的功能；后面在实现框架的高级功能特性时，我们再对该接口服务进行拓展升级，例如增加签名校验机制等，来适配测试框架的高级功能特性。

幸运的是，使用Python搭建API接口服务十分简单，特别是在结合使用Flask框架的情况下。

例如，我们想实现一套可以对用户账号进行增删改查（CRUD）功能的接口服务，用户账号的存储结构大致如下：

1
2
3
4
5
6
7
8
9
10
users_dict = {
   'uid1': {
       'name': 'name1',
       'password': 'pwd1'
   },
   'uid2': {
       'name': 'name2',
       'password': 'pwd2'
   }
}

那么，新增（Create）和更新（Update）功能的接口就可以通过如下方式实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
import json
from flask import Flask
from flask import request, make_response

app = Flask(__name__)
users_dict = {}

@app.route('/api/users/<int:uid>', methods=['POST'])
def create_user(uid):
    user = request.get_json()
    if uid not in users_dict:
        result = {
            'success': True,
            'msg': "user created successfully."
        }
        status_code = 201
        users_dict[uid] = user
    else:
        result = {
            'success': False,
            'msg': "user already existed."
        }
        status_code = 500

    response = make_response(json.dumps(result), status_code)
    response.headers["Content-Type"] = "application/json"
    return response

@app.route('/api/users/<int:uid>', methods=['PUT'])
def update_user(uid):
    user = users_dict.get(uid, {})
    if user:
        user = request.get_json()
        success = True
        status_code = 200
    else:
        success = False
        status_code = 404

    result = {
        'success': success,
        'data': user
    }
    response = make_response(json.dumps(result), status_code)
    response.headers["Content-Type"] = "application/json"
    return response

限于篇幅，其它类型的接口实现就不在此赘述，完整的接口实现可以参考项目源码。

接口服务就绪后，按照Flask官方文档，可以通过如下方式进行启动：

1
2
3
4
$ export FLASK_APP=tests/api_server.py
$ flask run
 * Serving Flask app "tests.api_server"
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

启动后，我们就可以通过请求接口来调用已经实现的接口功能了。例如，先创建一个用户，然后查看所有用户的信息，在Python终端中的调用方式如下：

1
2
3
4
5
6
7
8
9
$ python
Python 3.6.0 (default, Mar 24 2017, 16:58:25)
>>> import requests
>>> requests.post('http://127.0.0.1:5000/api/users/1000', json={'name': 'user1', 'password': '123456'})
<Response [201]>
>>> resp = requests.get('http://127.0.0.1:5000/api/users')
>>> resp.content
b'{"success": true, "count": 1, "items": [{"name": "user1", "password": "123456"}]}'
>>>

通过接口请求结果可见，接口服务运行正常。

在单元测试用例中使用 Mock Server

API接口服务（Mock Server）已经有了，但是如果每次运行单元测试时都要先在外部手工启动API接口服务的话，做法实在是不够优雅。

推荐的做法是，制作一个ApiServerUnittest基类，在其中添加setUpClass类方法，用于启动API接口服务（Mock Server）；添加tearDownClass类方法，用于停止API接口服务。由于setUpClass会在单元测试用例集初始化的时候执行一次，所以可以保证单元测试用例在运行的时候API服务处于可用状态；而tearDownClass会在单元测试用例集执行完毕后运行一次，停止API接口服务，从而避免对下一次启动产生影响。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# tests/base.py
import multiprocessing
import time
import unittest
from . import api_server

class ApiServerUnittest(unittest.TestCase):
    """
    Test case class that sets up an HTTP server which can be used within the tests
    """
    @classmethod
    def setUpClass(cls):
        cls.api_server_process = multiprocessing.Process(
            target=api_server.app.run
        )
        cls.api_server_process.start()
        time.sleep(0.1)

    @classmethod
    def tearDownClass(cls):
        cls.api_server_process.terminate()

这里采用的是多进程的方式（multiprocessing），所以我们的单元测试用例可以和API接口服务（Mock Server）同时运行。除了多进程的方式，我看到locust项目采用的是gevent.pywsgi.WSGIServer的方式，不过由于在gevent中要实现异步需要先monkey.patch_all()，感觉比较麻烦，而且还需要引入gevent这么一个第三方依赖库，所以还是决定采用multiprocessing的方式了。至于为什么没有选择多线程模型（threading），是因为线程至不支持显式终止的（terminate），要实现终止服务会比使用multiprocessing更为复杂。

不过需要注意的是，由于启动Server存在一定的耗时，因此在启动完毕后必须要等待一段时间（本例中0.1秒就足够了），否则在执行单元测试用例时，调用的API接口可能还处于不可用状态。

ApiServerUnittest基类就绪后，对于需要用到Mock Server的单元测试用例集，只需要继承ApiServerUnittest即可；其它的写法跟普通的单元测试完全一致。

例如，下例包含一个单元测试用例，测试“创建一个用户，该用户之前不存在”的场景。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# tests/test_apiserver.py
import requests
from .base import ApiServerUnittest

class TestApiServer(ApiServerUnittest):
    def setUp(self):
        super(TestApiServer, self).setUp()
        self.host = "http://127.0.0.1:5000"
        self.api_client = requests.Session()
        self.clear_users()

    def tearDown(self):
        super(TestApiServer, self).tearDown()

    def test_create_user_not_existed(self):
        self.clear_users()

        url = "%s/api/users/%d" % (self.host, 1000)
        data = {
            "name": "user1",
            "password": "123456"
        }
        resp = self.api_client.post(url, json=data)

        self.assertEqual(201, resp.status_code)
        self.assertEqual(True, resp.json()["success"])

为项目添加持续集成构建检查（Travis CI）

当我们的项目具有单元测试之后，我们就可以为项目添加持续集成构建检查，从而在每次提交代码至GitHub时都运行测试，确保我们每次提交的代码都是可正常部署及运行的。

要实现这个功能，推荐使用Travis CI提供的服务，该服务对于GitHub公有仓库是免费的。要完成配置，操作也很简单，基本上只有三步：

  • 在Travis CI使用GitHub账号授权登录；
  • 在Travis CI的个人profile页面开启需要持续集成的项目；
  • 在Github项目的根目录下添加.travis.yml配置文件。

大多数情况下，.travis.yml配置文件可以很简单，例如ApiTestEngine的配置就只有如下几行：

1
2
3
4
5
6
7
8
9
10
11
12
sudo: false
language: python
python:
  - 2.7
  - 3.3
  - 3.4
  - 3.5
  - 3.6
install:
  - pip install -r requirements.txt
script:
  - python -m unittest discover

具体含义不用解释也可以很容易看懂，其中install中包含我们项目的依赖库安装命令，script中包含执行构建测试的命令。

配置完毕后，后续每次提交代码时，GitHub就会调用Travis CI实现构建检查；并且更赞的在于，构建检查可以同时在多个指定的Python版本环境中进行。

下图是某次提交代码时的构建结果。

另外，我们还可以在GitHub项目的README.md中添加一个Status Image，实时显示项目的构建状态，就像下图显示的样子。

配置方式也是很简单，只需要先在Travis CI中获取到项目Status Image的URL地址，然后添加到README.md即可。

为项目添加单元测试覆盖率检查（coveralls）

对项目添加持续集成构建检查以后，就能完全保证我们提交的代码运行没问题么？

答案是并不能。试想，假如我们整个项目中就只有一条单元测试用例，甚至这一条单元测试用例还是个假用例，即没有调用任何代码，那么可想而知，我们的持续集成构建检查总是成功的，并没有起到检查的作用。

因此，这里还涉及到一个单元测试覆盖率的问题。

怎么理解单元测试覆盖率呢？简单地说，就是我们在执行单元测试时运行代码的行数，与项目总代码数的比值。

对于主流的编程语言，都存在大量的覆盖率检查工具，可以帮助我们快速统计单元测试覆盖率。在Python中，用的最多的覆盖率检查工具是coverage。

要使用coverage，需要先进行安装，采用pip的安装方式如下：

1
$ pip install coverage

然后，我们就可以采用如下命令执行单元测试。

1
$ coverage run --source=ate -m unittest discover

这里需要说明的是，--source参数的作用是指定统计的目录，如果不指定该参数，则会将所有依赖库也计算进去，但由于很多依赖库在安装时是没有包含测试代码的，因此会造成统计得到的单元测试覆盖率远低于实际的情况。在上面的命令中，就只统计了ate目录下的单元测试覆盖率；如果要统计当前项目的覆盖率，那么可以指定--source=.（即当前目录下的所有子文夹）。

采用上述命令执行完单元测试后，会在当前目录下生成一个统计结果文件，.coverage，里面包含了详细的统计结果。

1
2
3
4
5
6
7
8
9
10
cat .coverage
!coverage.py: This is a private format, don't read it directly!{"lines":{"/Users/Leo/MyProjects/ApiTestEngine/ate/__init__.py":[1],"/Users/Leo/MyProjects/
ApiTestEngine/ate/testcase.py":[1,2,4,6,9,15,42,7,12,40,46,64,67,68,69,70,48,49,62,72,74,13,65,51,52,53,56,60,58,54,55],"/Users/Leo/MyProjects/ApiTestEngi
ne/ate/exception.py":[2,4,5,9,12,15,16,6,7],"/Users/Leo/MyProjects/ApiTestEngine/ate/utils.py":[1,2,3,4,5,7,9,11,12,14,15,18,22,25,47,51,55,65,77,90,129,1
41,27,31,32,19,20,23,34,41,43,45,56,57,59,60,48,49,154,163,166,170,172,173,174,176,177,181,182,183,186,187,189,91,92,66,67,72,73,74,94,95,97,98,101,102,78
,80,81,82,84,85,88,103,104,106,108,110,115,121,122,124,125,127,58,52,53,184,185,109,116,118,119,112,113,132,134,135,136,137,139,63,164,155,157,158,159,161
,167,168,192,68,69],"/Users/Leo/MyProjects/ApiTestEngine/ate/context.py":[1,3,5,6,10,16,30,45,7,8,25,26,28,41,42,43,49,55,58,59,63,64,56,74,65,68,69,72,66
,27,13,14,50,53,52,70],"/Users/Leo/MyProjects/ApiTestEngine/ate/main.py":[1,2,4,7,9,10,15,21,38,51,25,27,28,29,30,32,33,11,12,13,34,36,42,43,45,46,47,49],
"/Users/Leo/MyProjects/ApiTestEngine/ate/runner.py":[1,3,4,5,8,10,15,46,68,97,135,11,12,13,35,36,38,39,41,42,44,82,63,65,66,84,86,87,88,92,93,94,95,124,12
6,127,128,129,130,131,133,154]}}%

但是，这个结果就不是给人看的。要想直观地看到统计报告，需要再执行命令coverage report -m，执行完后，就可以看到详细的统计数据了。

1
2
3
4
5
6
7
8
9
10
11
12
➜  ApiTestEngine git:(master) ✗ coverage report -m
Name               Stmts   Miss  Cover   Missing
------------------------------------------------
ate/__init__.py        0      0   100%
ate/context.py        35      0   100%
ate/exception.py      11      2    82%   10, 13
ate/main.py           34      7    79%   18-19, 54-62
ate/runner.py         44      2    95%   89-90
ate/testcase.py       30      0   100%
ate/utils.py         112      8    93%   13, 29, 36-39, 178-179
------------------------------------------------
TOTAL                266     19    93%

通过这个报告，可以看到项目整体的单元测试覆盖率为93%，并清晰地展示了每个源代码文件的具体覆盖率数据，以及没有覆盖到的代码行数。

那要怎么将覆盖率检查添加到我们的持续集成（Travis CI）中呢？

事实上，当前存在多个可选服务，可以与Travis CI配合使用。当前，使用得比较广泛的是coveralls，针对Public类型的GitHub仓库，这也是一个免费服务。

coveralls的使用方式与Travis CI类似，也需要先在coveralls网站上采用GitHub账号授权登录，然后开启需要进行检查的GitHub仓库。而要执行的命令，也可以在.travis.yml配置文件中指定。

增加覆盖率检查后的.travis.yml配置文件内容如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
sudo: false
language: python
python:
  - 2.7
  - 3.3
  - 3.4
  - 3.5
  - 3.6
install:
  - pip install -r requirements.txt
  - pip install coverage
  - pip install coveralls
script:
  - coverage run --source=. -m unittest discover
after_success:
  - coveralls

如上配置应该也很好理解，要使用coveralls的服务，需要先安装coveralls。在采用coverage执行完单元测试后，要将结果上报到coveralls网站，需要再执行coveralls命令。由于coveralls命令只有在测试覆盖率检查成功以后运行才有意义，因此可将其放在after_success部分。

配置完毕后，后续每次提交代码时，GitHub就会调用Travis CI实现构建检查，并同时统计得到单元测试覆盖率。

下图是某次提交代码时的覆盖率检查。

另外，我们在GitHub项目的README.md中也同样可以添加一个Status Image，实时显示项目的单元测试覆盖率。

配置方式也跟之前类似，在coveralls中获取到项目Status Image的URL地址，然后添加到README.md即可。

最后需要说明的是，项目的单元测试覆盖率只能起到参考作用，没有被单元测试覆盖到的代码我们不能说它肯定有问题，100%覆盖率的代码也并不能保证它肯定没有问题。归根结底，这还是要依赖于单元测试的策略实现，因此我们在写单元测试的时候也要尽可能多地覆盖到各种逻辑路径，以及兼顾到各种异常情况。

写在后面

通过本文中的工作，我们就对项目搭建好了测试框架，并实现了持续集成构建检查机制。从下一篇开始，我们就将开始逐步实现接口自动化测试框架的核心功能特性了。

阅读更多

发表于 更新于 分类于 ，

背景

当前市面上存在的接口测试工具已经非常多，常见的如Postman、JMeter、RobotFramework等，相信大多数测试人员都有使用过，至少从接触到的大多数简历的描述上看是这样的。除了这些成熟的工具，也有很多有一定技术能力的测试（开发）人员自行开发了一些接口测试框架，质量也是参差不齐。

但是，当我打算在项目组中推行接口自动化测试时，搜罗了一圈，也没有找到一款特别满意的工具或框架，总是与理想中的构想存在一定的差距。

那么理想中的接口自动化测试框架应该是怎样的呢？

测试工具（框架）脱离业务使用场景都是耍流氓！所以我们不妨先来看下日常工作中的一些常见场景。

  • 测试或开发人员在定位问题的时候，想调用某个接口查看其是否响应正常；
  • 测试人员在手工测试某个功能点的时候，需要一个订单号，而这个订单号可以通过顺序调用多个接口实现下单流程；
  • 测试人员在开始版本功能测试之前，可以先检测下系统的所有接口是否工作正常，确保接口正常后再开始手工测试；
  • 开发人员在提交代码前需要检测下新代码是否对系统的已有接口产生影响；
  • 项目组需要每天定时检测下测试环境所有接口的工作情况，确保当天的提交代码没有对主干分支的代码造成破坏；
  • 项目组需要定时（30分钟）检测下生产环境所有接口的工作情况，以便及时发现生产环境服务不可用的情况；
  • 项目组需要不定期对核心业务场景进行性能测试，期望能减少人力投入，直接复用接口测试中的工作成果。

可以看到，以上罗列的场景大家应该都很熟悉，这都是我们在日常工作中经常需要去做的事情。但是在没有一款合适工具的情况下，效率往往十分低下，或者就是某些重要工作压根就没有开展，例如接口回归测试、线上接口监控等。

先说下最简单的手工调用接口测试。可能有人会说，Postman就可以满足需求啊。的确，Postman作为一款通用的接口测试工具，它可以构造接口请求，查看接口响应，从这个层面上来说，它是满足了接口测试的功能需求。但是在具体的项目中，使用Postman并不是那么高效。

不妨举个最常见的例子。

某个接口的请求参数非常多，并且接口请求要求有MD5签名校验；签名的方式为在Headers中包含一个sign参数，该参数值通过对URL、Method、Body的拼接字符串进行MD5计算后得到。

回想下我们要对这个接口进行测试时是怎么做的。首先，我们需要先参照接口文档的描述，手工填写完所有接口参数；然后，按照签名校验方式，对所有参数值进行拼接得到一个字符串，在另一个MD5计算工具计算得到其MD5值，将签名值填入sign参数；最后，才是发起接口请求，查看接口响应，并人工检测响应是否正常。最坑爹的是，我们每次需要调用这个接口的时候，以上工作就得重新来一遍。这样的实际结果是，面对参数较多或者需要签名验证的接口时，测试人员可能会选择忽略不进行接口测试。

除了单个接口的调用，很多时候我们也需要组合多个接口进行调用。例如测试人员在测试物流系统时，经常需要一个特定组合条件下生成的订单号。而由于订单号关联的业务较多，很难直接在数据库中生成，因此当前业务测试人员普遍采取的做法，就是每次需要订单号时模拟下单流程，顺序调用多个相应的接口来生成需要的订单号。可以想象，在手工调用单个接口都如此麻烦的情况下，每次都要手工调用多个接口会有多么的费时费力。

再说下接口自动化调用测试。这一块儿大多接口测试框架都支持，普遍的做法就是通过代码编写接口测试用例，或者采用数据驱动的方式，然后在支持命令行（CLI）调用的情况下，就可以结合Jenkins或者crontab实现持续集成，或者定时接口监控的功能。

思路是没有问题的，问题在于实际项目中的推动落实情况。要说自动化测试用例最靠谱的维护方式，还是直接通过代码编写测试用例，可靠且不失灵活性，这也是很多经历过惨痛教训的老手的感悟，甚至网络上还出现了一些反测试框架的言论。但问题在于项目中的测试人员并不是都会写代码，也不是对其强制要求就能马上学会的。这种情况下，要想在具体项目中推动接口自动化测试就很难，就算我可以帮忙写一部分，但是很多时候接口测试用例也是要结合业务逻辑场景的，我也的确是没法在这方面投入太多时间，毕竟对接的项目实在太多。所以也是基于这类原因，很多测试框架提倡采用数据驱动的方式，将业务测试用例和执行代码分离。不过由于很多时候业务场景比较复杂，大多数框架测试用例模板引擎的表达能力不足，很难采用简洁的方式对测试场景进行描述，从而也没法很好地得到推广使用。

可以列举的问题还有很多，这些也的确都是在互联网企业的日常测试工作中真实存在的痛点。

基于以上背景，我产生了开发ApiTestEngine的想法。

对于ApiTestEngine的定位，与其说它是一个工具或框架，它更多的应该是一套接口自动化测试的最佳工程实践，而简洁优雅实用应该是它最核心的特点。

当然，每位工程师对最佳工程实践的理念或多或少都会存在一些差异，也希望大家能多多交流，在思维的碰撞中共同进步。

核心特性

ApiTestEngine的核心特性概述如下：

  • 支持API接口的多种请求方法，包括 GET/POST/HEAD/PUT/DELETE 等
  • 测试用例与代码分离，测试用例维护方式简洁优雅，支持YAML
  • 测试用例描述方式具有表现力，可采用简洁的方式描述输入参数和预期输出结果
  • 接口测试用例具有可复用性，便于创建复杂测试场景
  • 测试执行方式简单灵活，支持单接口调用测试、批量接口调用测试、定时任务执行测试
  • 测试结果统计报告简洁清晰，附带详尽日志记录，包括接口请求耗时、请求响应数据等
  • 身兼多职，同时实现接口管理、接口自动化测试、接口性能测试（结合Locust）
  • 具有可扩展性，便于扩展实现Web平台化

特性拆解介绍

支持API接口的多种请求方法，包括 GET/POST/HEAD/PUT/DELETE 等

个人偏好，编程语言选择Python。而采用Python实现HTTP请求，最好的方式就是采用Requests库了，简洁优雅，功能强大。

测试用例与代码分离，测试用例维护方式简洁优雅，支持YAML

要实现测试用例与代码的分离，最好的做法就是做一个测试用例加载引擎和一个测试用例执行引擎，这也是之前在做AppiumBooster框架的时候总结出来的最优雅的实现方式。当然，这里需要事先对测试用例制定一个标准的数据结构规范，作为测试用例加载引擎和测试用例执行引擎的桥梁。

需要说明的是，测试用例数据结构必须包含接口测试用例完备的信息要素，包括接口请求的信息内容（URL、Headers、Method等参数），以及预期的接口请求响应结果（StatusCode、ResponseHeaders、ResponseContent）。

这样做的好处在于，不管测试用例采用什么形式进行描述（YAML、JSON、CSV、Excel、XML等），也不管测试用例是否采用了业务分层的组织思想，只要在测试用例加载引擎中实现对应的转换器，都可以将业务测试用例转换为标准的测试用例数据结构。而对于测试用例执行引擎而言，它无需关注测试用例的具体描述形式，只需要从标准的测试用例数据结构中获取到测试用例信息要素，包括接口请求信息和预期接口响应信息，然后构造并发起HTTP请求，再将HTTP请求的响应结果与预期结果进行对比判断即可。

至于为什么明确说明支持YAML，这是因为个人认为这是最佳的测试用例描述方式，表达简洁不累赘，同时也能包含非常丰富的信息。当然，这只是个人喜好，如果喜欢采用别的方式，只需要扩展实现对应的转换器即可。

测试用例描述方式具有表现力，可采用简洁的方式描述输入参数和预期输出结果

测试用例与框架代码分离以后，对业务逻辑测试场景的描述重任就落在测试用例上了。比如我们选择采用YAML来描述测试用例，那么我们就应该能在YAML中描述各种复杂的业务场景。

那么怎么理解这个“表现力”呢？

简单的参数值传参应该都容易理解，我们举几个相对复杂但又比较常见的例子。

  • 接口请求参数中要包含当前的时间戳；
  • 接口请求参数中要包含一个16位的随机字符串；
  • 接口请求参数中包含签名校验，需要对多个请求参数进行拼接后取md5值；
  • 接口响应头（Headers）中要包含一个X-ATE-V头域，并且需要判断该值是否大于100；
  • 接口响应结果中包含一个字符串，需要校验字符串中是否包含10位长度的订单号；
  • 接口响应结果为一个多层嵌套的json结构体，需要判断某一层的某一个元素值是否为True。

可以看出，以上几个例子都是没法直接在测试用例里面描述参数值的。如果是采用Python脚本来编写测试用例还好解决，只需要通过Python函数实现即可。但是现在测试用例和框架代码分离了，我们没法在YAML里面执行Python函数，这该怎么办呢？

答案就是，定义函数转义符，实现自定义模板。

这种做法其实也不难理解，也算是模板语言通用的方式。例如，我们将${}定义为转义符，那么在{}内的内容就不再当做是普通的字符串，而应该转义为变量值，或者执行函数得到实际结果。当然，这个需要我们在测试用例执行引擎进行适配实现，最简单方式就是提取出${}中的字符串，通过eval计算得到表达式的值。如果要实现更复杂的功能，我们也可以将接口测试中常用的一些功能封装为一套关键字，然后在编写测试用例的时候使用这些关键字。

接口测试用例具有可复用性，便于创建复杂测试场景

很多情况下，系统的接口都是有业务逻辑关联的。例如，要请求调用登录接口，需要先请求获取验证码的接口，然后在登录请求中带上获取到的验证码；而要请求数据查询的接口，又要在请求参数中包含登录接口返回的session值。这个时候，我们如果针对每一个要测的业务逻辑，都单独描述要请求的接口，那么就会造成大量的重复描述，测试用例的维护也十分臃肿。

比较好的做法是，将每一个接口调用单独封装为一条测试用例，然后在描述业务测试场景时，选择对应的接口，按照顺序拼接为业务场景测试用例，就像搭积木一般。如果你之前读过AppiumBooster的介绍，应该还会联想到，我们可以将常用的功能组成模块用例集，然后就可以在更高的层面对模块用例集进行组装，实现更复杂的测试场景。

不过，这里有一个非常关键的问题需要解决，就是如何在接口测试用例之前传参的问题。其实实现起来也不复杂，我们可以在接口请求响应结果中指定一个变量名，然后将接口返回关键值提取出来后赋值给那个变量；然后在其它接口请求参数中，传入这个${变量名}即可。

测试执行方式简单灵活，支持单接口调用测试、批量接口调用测试、定时任务执行测试

通过背景中的例子可以看出，需要使用接口测试工具的场景很多，除了定时地对所有接口进行自动化测试检测外，很多时候在手工测试的时候也需要采用接口测试工具进行辅助，也就是半手工+半自动化的模式。

而业务测试人员在使用测试工具的时候，遇到的最大问题在于除了需要关注业务功能本身，还需要花费很多时间去处理技术实现细节上的东西，例如签名校验这类情况，而且往往后者在重复操作中占用的时间更多。

这个问题的确是没法避免的，毕竟不同系统的接口千差万别，不可能存在一款工具可以自动处理所有情况。但是我们可以尝试将接口的技术细节实现和业务参数进行拆分，让业务测试人员只需要关注业务参数部分。

具体地，我们可以针对每一个接口配置一个模板，将其中与业务功能无关的参数以及技术细节封装起来，例如签名校验、时间戳、随机值等，而与业务功能相关的参数配置为可传参的模式。

这样做的好处在于，与业务功能无关的参数以及技术细节我们只需要封装配置一次，而且这个工作可以由开发人员或者测试开发人员来实现，减轻业务测试人员的压力；接口模板配置好后，测试人员只需要关注与业务相关的参数即可，结合业务测试用例，就可以在接口模板的基础上很方便地配置生成多个接口测试用例。

测试结果统计报告简洁清晰，附带详尽日志记录，包括接口请求耗时、请求响应数据等

测试结果统计报告，应该遵循简洁而不简单的原则。“简洁”，是因为大多数时候我们只需要在最短的时间内判断所有接口是否运行正常即可。而“不简单”，是因为当存在执行失败的测试用例时，我们期望能获得接口测试时尽可能详细的数据，包括测试时间、请求参数、响应内容、接口响应耗时等。

之前在读locust源码时，其对HTTP客户端的封装方式给我留下了深刻的印象。它采用的做法是，继承requests.Session类，在子类HttpSession中重写覆盖了request方法，然后在request方法中对requests.Session.request进行了一层封装。

1
2
3
4
5
6
7
8
9
10
11
12
request_meta = {}

# set up pre_request hook for attaching meta data to the request object
request_meta["method"] = method
request_meta["start_time"] = time.time()

response = self._send_request_safe_mode(method, url, **kwargs)

# record the consumed time
request_meta["response_time"] = int((time.time() - request_meta["start_time"]) * 1000)

request_meta["content_size"] = int(response.headers.get("content-length") or 0)

而HttpLocust的每一个虚拟用户（client）都是一个HttpSession实例，这样每次在执行HTTP请求的时候，既可充分利用Requests库的强大功能，同时也能将请求的响应时间、响应体大小等原始性能数据进行保存，实现可谓十分优雅。

受到该处启发，要保存接口的详细请求响应数据也可采用同样的方式。例如，要保存Response的Headers、Body只需要增加如下两行代码：

1
2
request_meta["response_headers"] = response.headers
request_meta["response_content"] = response.content

身兼多职，同时实现接口管理、接口自动化测试、接口性能测试（结合Locust）

其实像接口性能测试这样的需求，不应该算到接口自动化测试框架的职责范围之内。但是在实际项目中需求就是这样，又要做接口自动化测试，又要做接口性能测试，而且还不想同时维护两套代码。

多亏有了locust性能测试框架，接口自动化和性能测试脚本还真能合二为一。

前面也讲了，HttpLocust的每一个虚拟用户（client）都是一个HttpSession实例，而HttpSession又继承自requests.Session类，所以HttpLocust的每一个虚拟用户（client）也是requests.Session类的实例。

同样的，我们在用Requests库做接口测试时，请求客户端其实也是requests.Session类的实例，只是我们通常用的是requests的简化用法。

以下两种用法是等价的。

1
2
3
4
5
resp = requests.get('https://debugtalk.com')

# 等价于
client = requests.Session()
resp = client.get('https://debugtalk.com')

有了这一层关系以后，要在接口自动化测试和性能测试之间切换就很容易了。在接口测试框架内，可以通过如下方式初始化HTTP客户端。

1
2
def __init__(self, origin, kwargs, http_client_session=None):
   self.http_client_session = http_client_session or requests.Session()

默认情况下，http_client_session是requests.Session的实例，用于进行接口测试；当需要进行性能测试时，只需要传入locust的HttpSession实例即可。

具有可扩展性，便于扩展实现Web平台化

当要将测试平台推广至更广阔的用户群体（例如产品经理、运营人员）时，对框架实现Web化就在所难免了。在Web平台上查看接口测试用例运行情况、对接口模块进行配置、对接口测试用例进行管理，的确会便捷很多。

不过对于接口测试框架来说，Web平台只能算作锦上添花的功能。我们在初期可以优先实现命令行（CLI）调用方式，规范好数据存储结构，后期再结合Web框架（如Flask）增加实现Web平台功能。

写在后面

以上便是我对ApiTestEngine特性的详细介绍，也算是我个人对接口自动化测试最佳工程实践的理念阐述。

当前，ApiTestEngine还处于开发过程中，代码也开源托管在GitHub上，欢迎Star关注。

GitHub项目地址：https://github.com/debugtalk/ApiTestEngine

参考

发表于 更新于 分类于

近期公司新来了一批实习生，公司也组织了大量的人力物力对实习生的进行培训。不得不说，公司的确在朝”大公司“的方向发展，各项制度福利也在逐步完善。以前别说是实习生了，不管是社招还是校招来的人，都是入职后就直接上岗，哪有这么多培训机会。

分配给我的任务是对我们质量部的岗位进行介绍，给实习生们讲解下我们测试工程师的工作日常情况。由于面向的都是新人，而且各种岗位的都有，因此也只能是科普介绍了。当时也没有准备PPT，就是提前想了几个主题点，然后就简单展开讲了下。

培训结束后感觉这个科普可能对于刚毕业或者还没有毕业的同学还是有一些价值的，因此就将今天讲的内容整理为文字。老司机们就不用看了，我们后续再聊。

——— 分割线 ———

大家好，我是李隆，当前在互联网事业部的质量部做测试开发岗位。在之前的培训中，大家应该知道了，当前我们质量部共分为三类岗位，分别是QA、测试和测试开发。不知道大家有没有想过，为什么要这么划分？这三类岗位的区别和联系在哪里？

这就要从质量部的名称说起了。在日常工作中，通常我们都是说产品、开发、测试、运维，那为什么我们不是叫做测试部，而是叫质量部呢？这是因为，站在软件工程的角度，测试只是手段，而保障项目质量才是我们的最终目的。

那么，”质量“这两个字要怎么理解呢？这是一个非常大的问题，我的确也没法单纯从字面上给大家解释它的完整含义。那我们不妨换个角度，先来看下日常工作中哪些情况会对项目质量造成影响，或者说当出现哪些现象时，就可以说明我们的项目质量存在问题。

  • 开发提交的代码里面有bug。这个应该是最常见的，也是大家最熟悉的质量问题了。
  • 产品的需求描述不清楚，或者需求里面有隐藏的业务逻辑问题，甚至压根就没有需求文档，完全是”一句话需求“。可以想象，这种情况通常造成的后果就是开发到后期才会发现与预期需求不符，严重的甚至造成返工的后果。
  • 开发人员没有写单元测试，项目没有版本规划，提测比较随意并且没有自测。这种情况通常就会造成所有人员都很忙，天天加班，但是项目质量问题越来越多。
  • 运维人员操作没有规范指引，也没有风险预案机制，说不定哪天某个运维人员没睡醒，一不小心就”删库“然后”跑路“了。
  • 测试人员没有测试策略，设计的测试用例仅局限于UI功能层面，难以实现核心业务逻辑的覆盖，也无法发现深层次的问题。
  • 测试人员需要做大量的重复性回归测试，也没有引入自动化测试机制，造成要么没有回归测试，要么测试耗费大量人力和时间成本。

还可以列出来的内容还有很多，不难看出，以上每一种情况都会造成项目质量出现问题，而且很多看似跟测试不直接相关的情况，往往造成的质量问题比单纯的代码bug更严重。而如果我们只是单纯地从软件测试的角度去考虑的话，我们会遗漏很多问题，项目整体质量也没法得到保障。相信你们这时应该会明白，质量部这个名称的真正含义了。

通过以上实例，可以看出质量部可以做的事情，以及必须要去做的事情非常多，但是这个范围又这么广，毕竟术业有专攻，不可能要求每个人都能做到那么多，所以我们质量部才有了岗位划分。

先来说下QA这个岗位，这个岗位主要是做什么的呢？还是回到前面提到的案例，当项目团队没有规范流程的时候，项目质量是很难保障的，往往都会有事倍功半的情况。当团队处于这种状态的时候，QA应该是第一个站出来，让项目组的所有人员认识到流程规范的重要性，并且牵头来制定和梳理流程，包括产品需求应该写成什么样才算规范，版本发版周期定为怎样才算合适，测试人员的用例规范，验收标准，以及运维人员应该有怎样的操作规范，等等。当规范建立起来后，QA也会参与到日常的测试工作中去，除了单纯的测试工作外，QA还需要对项目规范流程进行监督，发掘在实际工作中有哪些是不符合流程规范的，或者哪些流程规范是可以改进的，然后再协同各方人员来一起优化。可以看出，QA这个岗位可能并不是要特别精通于某项测试技术，但是TA一定是要对项目质量有非常灵敏的嗅觉，总是能及时地发现当前项目中可能会影响项目质量的”坏味道“，及时地暴露问题，并且跟进问题的解决。

然后再来说下测试岗位。测试这个岗位应该是大家从感觉上最直观，也是业界大众普遍认知里负责软件测试的岗位。可能有人会觉得，测试这个岗位是产品开发周期的末端，只有等到研发开发完毕，提测以后才开始工作。其实不是这样的。一个好的测试人员，应该是关注项目开发周期的整个流程的。在产品需求出来后，测试就应该要参与产品需求评审，并利用自身在业务方面的测试经验积累，充分挖掘新版本需求可能存在的业务逻辑漏洞。在开发设计技术方案的时候，测试人员也要参与到技术评审，从软件测试的角度，挖掘技术方案中可能存在的技术漏洞。评审完成后，在开发还在编码实现的时候，就需要根据当前版本需求设计测试策略，编写测试用例。等到开发提交测试以后，才是开始大家普遍认知上的测试工作。具体地，对于测试岗位来说，这本来就是一个技术性的岗位，除了需要掌握多种测试理论方法外，还需要根据系统类型的实际测试需要，熟练使用对应的测试工具。测试类型也会很多，除了最基础的功能测试外，也会根据实际情况，对Web前端进行页面兼容性测试、对app进行客户端性能专项测试（启动时间、启动内存、流畅度、包大小等），对后台服务器端进行性能测试（响应时间、吞吐量等），对系统安全进行测试，等等。

最后再来说下测试开发，也就是当前我所在的这个岗位。那么测试开发要做什么呢？可能我讲一个之前的经历大家就清楚了。

我上一家公司在阿里巴巴，当时也是做测试开发岗位。刚进公司的时候，组里的同事跟我说，欢迎来到”生促（畜）组“，看到我一脸懵逼，同事解释到，生产力促进组嘛。我说，这名字也太难听了吧。同事说，这还算好的了，知道以前其它组的叫我们什么吗？促（畜）生组，促进生产力组。
这么一对比，”生促组“听上去的确是优雅多了。

可以看到，不管是”生促“还是”促生“，测试开发这个岗位的核心都是围绕着如何提升生产力，也就是工作效率上面。当然，提高生产力也分为两个层面。第一个层面是提高质量部内部测试人员的测试效率，当前我们也主要还停留在这个层面。前面的例子也说道，当测试人员需要进行大量的重复性回归测试的时候，或者在日常工作中存在简单重复低效的工作内容的时候，这个时候就需要测试开发人员来辅助开发相应的工具平台，常见的包括实现接口测试自动化、UI自动化、持续集成等，将测试人员从重复性的工作解放出来，从而能有更多的时间精力投入到探索性测试当中去。第二个层面呢，也是我们后续的工作目标，那就是提高整个研发团队的工作效率。当然这可能不是测试开发岗位就能独立完成的，这也需要联合开发和运维同学，一起梳理整个研发测试运维流程，然后从技术的角度去开发实现一些工具平台，从而让整个项目团队能更高效的运作。

当然，虽然存在着QA、测试、测试开发的岗位划分，但是在实际工作中并不会有特别严格的界限，只是相对来说工作重心有所侧重而已。就比如说，QA和测试开发岗位也是会参与到测试工作中的，因为如果你不熟悉测试，你怎么知道测试过程中存在哪些不规范的地方，你怎么知道测试在哪些地方存在低效的痛点？同样的，测试人员要更好地理解流程和规范，也需要参与到流程规范的制订讨论工作中；而要更好地实现对系统的测试，必定需要用到一些技术手段，甚至自身具备足够的编码能力，来开展专项测试、性能测试等测试工作，从而能更好地应用技术手段来保障项目质量。

以上便是我对质量部各个岗位工作内容的介绍，也非常欢迎各位到质量部来轮岗。

其实也可以毫不夸张地说，测试岗位对于一个刚接触互联网行业的新人来说，的确是一个非常适合从整体上快速了解行业的岗位。为什么这么说？因为从前面的介绍也可以看出来，测试岗位需要参与项目的整个流程，也需要跟各种角色的人员进行沟通交流，只要用心，就能快速地得到成长，并对各个岗位能有一个较清晰的认识，这对你们后续选择职业方向和岗位的时候也是非常有帮助的。

——— 分割线 ———

最后再发点小感悟。这次也算是第一次大量接触”95后“，直观的印象，的确是一个非常活跃的群体。一方面的体现，就是参与度很强，在每个主题讲解完成后，都有大量的提问，交流十分活跃；而另一方面，就是思维活跃，虽然实习生大多都是才大三，但是从提问的问题来看，他们的知识面很广，很多问题都可以看出是经过认真思考的，而且有些问题还很有深度。

不得不佩服的同时，再想想自己的年龄，不禁黯然神伤，啥也不说了，搬砖去了。

发表于 更新于 分类于

背景

从接触Python以来，一直都是采用virtualenv和virtualenvwrapper来管理不同项目的依赖环境，通过workon、mkvirtualenv等命令进行虚拟环境切换，很是愉快。

然而，最近想让项目能兼容更多的Python版本，例如至少同时兼容Python2.7和Python3.3+，就发现采用之前的方式行不通了。

最大的问题在于，在本地计算机同时安装Python2.7和Python3后，即使分别针对两个Python版本安装了virtualenv和virtualenvwrapper，也无法让两个Python版本的workon、mkvirtualenv命令同时生效。另外一方面，要想在本地计算机安装多个Python版本，会发现安装的成本都比较高，实现方式也不够优雅。

幸运地是，针对该痛点，已经存在一个比较成熟的方案，那就是pyenv。

如下是官方的介绍。

pyenv lets you easily switch between multiple versions of Python. It’s simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well.

This project was forked from rbenv and ruby-build, and modified for Python.

本文就针对pyenv最核心的功能进行介绍。

基本原理

如果要讲解pyenv的工作原理，基本上采用一句话就可以概括，那就是：修改系统环境变量PATH。

对于系统环境变量PATH，相信大家都不陌生，里面包含了一串由冒号分隔的路径，例如/usr/local/bin:/usr/bin:/bin。每当在系统中执行一个命令时，例如python或pip，操作系统就会在PATH的所有路径中从左至右依次寻找对应的命令。因为是依次寻找，因此排在左边的路径具有更高的优先级。

而pyenv做的，就是在PATH最前面插入一个$(pyenv root)/shims目录。这样，pyenv就可以通过控制shims目录中的Python版本号，来灵活地切换至我们所需的Python版本。

如果还想了解更多细节，可以查看pyenv的文档介绍及其源码实现。

环境初始化

pyenv的安装方式包括多种，重点推荐采用pyenv-installer的方式，原因主要有两点：

  • 通过pyenv-installer可一键安装pyenv全家桶，后续也可以很方便地实现一键升级；
  • pyenv-installer的安装方式基于GitHub，可保证总是使用到最新版本的pyenv，并且Python版本库也是最新最全的。

install && config

通过如下命令安装pyenv全家桶。

1
$ curl -L https://raw.githubusercontent.com/pyenv/pyenv-installer/master/bin/pyenv-installer | bash

内容除了包含pyenv以外，还包含如下插件：

  • pyenv-doctor
  • pyenv-installer
  • pyenv-update
  • pyenv-virtualenv
  • pyenv-which-ext

安装完成后，pyenv命令还没有加进系统的环境变量，需要将如下内容加到~/.zshrc中，然后执行source ~/.zshrc。

1
2
3
export PATH=$HOME/.pyenv/bin:$PATH
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

完成以上操作后，pyenv就安装完成了。

1
2
$ pyenv -v
pyenv 1.0.8

如果不确定pyenv的环境是否安装正常，可以通过pyenv doctor命令对环境进行检测。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ pyenv doctor
Cloning /Users/Leo/.pyenv/plugins/pyenv-doctor/bin/.....
Installing python-pyenv-doctor...

BUILD FAILED (OS X 10.12.3 using python-build 20160602)

Last 10 log lines:
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no
configure: error: OpenSSL development header is not installed.
make: *** No targets specified and no makefile found.  Stop.
Problem(s) detected while checking system.

通过检测，可以发现本地环境可能存在的问题，例如，从以上输出可以看出，本地的OpenSSL development header还没有安装。根据提示的问题，逐一进行修复，直到检测不再出现问题为止。

update

通过pyenv update命令，可以更新pyenv全家桶的所有内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
$ pyenv update
Updating /Users/Leo/.pyenv...
From https://github.com/yyuu/pyenv
 * branch            master     -> FETCH_HEAD
Already up-to-date.
Updating /Users/Leo/.pyenv/plugins/pyenv-doctor...
From https://github.com/yyuu/pyenv-doctor
 * branch            master     -> FETCH_HEAD
Already up-to-date.
Updating /Users/Leo/.pyenv/plugins/pyenv-installer...
From https://github.com/yyuu/pyenv-installer
 * branch            master     -> FETCH_HEAD
Already up-to-date.
Updating /Users/Leo/.pyenv/plugins/pyenv-update...
From https://github.com/yyuu/pyenv-update
 * branch            master     -> FETCH_HEAD
Already up-to-date.
Updating /Users/Leo/.pyenv/plugins/pyenv-virtualenv...
From https://github.com/yyuu/pyenv-virtualenv
 * branch            master     -> FETCH_HEAD
Already up-to-date.
Updating /Users/Leo/.pyenv/plugins/pyenv-which-ext...
From https://github.com/yyuu/pyenv-which-ext
 * branch            master     -> FETCH_HEAD
Already up-to-date.

pyenv的核心使用方法

pyenv的主要功能如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ pyenv -h
Usage: pyenv <command> [<args>]

Some useful pyenv commands are:
   commands    List all available pyenv commands
   local       Set or show the local application-specific Python version
   global      Set or show the global Python version
   shell       Set or show the shell-specific Python version
   install     Install a Python version using python-build
   uninstall   Uninstall a specific Python version
   rehash      Rehash pyenv shims (run this after installing executables)
   version     Show the current Python version and its origin
   versions    List all Python versions available to pyenv
   which       Display the full path to an executable
   whence      List all Python versions that contain the given executable

See `pyenv help <command>' for information on a specific command.
For full documentation, see: https://github.com/yyuu/pyenv#readme

查看所有可安装的Python版本

1
2
3
4
5
6
7
8
9
10
11
12
$ pyenv install --list
Available versions:
  2.1.3
  ...
  2.7.12
  2.7.13
  ...
  3.5.3
  3.6.0
  3.6-dev
  3.6.1
  3.7-dev

需要注意的是，如果是采用brew命令安装的pyenv，可能会发现Python版本库中没有最新的Python版本。所以建议还是通过GitHub源码方式安装pyenv。

安装指定版本的Python环境

1
2
3
4
5
$ pyenv install 3.6.0
Downloading Python-3.6.0.tar.xz...
-> https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz
Installing Python-3.6.0...
Installed Python-3.6.0 to /Users/Leo/.pyenv/versions/3.6.0

查看当前系统中所有可用的Python版本

1
2
3
4
$ pyenv versions
* system (set by /Users/Leo/.pyenv/version)
  2.7.13
  3.6.0

切换Python版本

pyenv可以从三个维度来管理Python环境，简称为：当前系统、当前目录、当前shell。这三个维度的优先级从左到右依次升高，即当前系统的优先级最低、当前shell的优先级最高。

如果想修改系统全局的Python环境，可以采用pyenv global PYTHON_VERSION命令。该命令执行后会在$(pyenv root)目录（默认为~/.pyenv）中创建一个名为version的文件（如果该文件已存在，则修改该文件的内容），里面记录着系统全局的Python版本号。

1
2
3
4
5
6
7
8
9
10
11
$ pyenv global 2.7.13
$ cat ~/.pyenv/version
2.7.13
$ pyenv version
2.7.13 (set by /Users/Leo/.pyenv/version)

$ pyenv global 3.6.0
$ cat ~/.pyenv/version
3.6.0
$ pyenv version
3.6.0 (set by /Users/Leo/.pyenv/version)

通常情况下，对于特定的项目，我们可能需要切换不同的Python环境，这个时候就可以通过pyenv local PYTHON_VERSION命令来修改当前目录的Python环境。命令执行后，会在当前目录中生成一个.python-version文件（如果该文件已存在，则修改该文件的内容），里面记录着当前目录使用的Python版本号。

1
2
3
4
5
6
7
8
9
10
11
$ cat ~/.pyenv/version
2.7.13
$ pyenv local 3.6.0
$ cat .python-version
3.6.0
$ cat ~/.pyenv/version
2.7.13
$ pyenv version
3.6.0 (set by /Users/Leo/MyProjects/.python-version)
$ pip -V
pip 9.0.1 from /Users/Leo/.pyenv/versions/3.6.0/lib/python3.6/site-packages (python 3.6)

可以看出，当前目录中的.python-version配置优先于系统全局的~/.pyenv/version配置。

另外一种情况，通过执行pyenv shell PYTHON_VERSION命令，可以修改当前shell的Python环境。执行该命令后，会在当前shell session（Terminal窗口）中创建一个名为PYENV_VERSION的环境变量，然后在当前shell的任意目录中都会采用该环境变量设定的Python版本。此时，当前系统和当前目录中设定的Python版本均会被忽略。

1
2
3
4
5
6
7
8
9
$ echo $PYENV_VERSION

$ pyenv shell 3.6.0
$ echo $PYENV_VERSION
3.6.0
$ cat .python-version
2.7.13
$ pyenv version
3.6.0 (set by PYENV_VERSION environment variable)

顾名思义，当前shell的Python环境仅在当前shell中生效，重新打开一个新的shell后，该环境也就失效了。如果想在当前shell中取消shell级别的Python环境，采用unset命令重置PYENV_VERSION环境变量即可。

1
2
3
4
5
6
7
8
$ cat .python-version
2.7.13
$ pyenv version
3.6.0 (set by PYENV_VERSION environment variable)

$ unset PYENV_VERSION
$ pyenv version
2.7.13 (set by /Users/Leo/MyProjects/.python-version)

管理多个依赖库环境

经过以上操作，我们在本地计算机中就可以安装多个版本的Python运行环境，并可以按照实际需求进行灵活地切换。然而，很多时候在同一个Python版本下，我们仍然希望能根据项目进行环境分离，就跟之前我们使用virtualenv一样。

在pyenv中，也包含这么一个插件，pyenv-virtualenv，可以实现同样的功能。

使用方式如下：

1
$ pyenv virtualenv PYTHON_VERSION PROJECT_NAME

其中，PYTHON_VERSION是具体的Python版本号，例如，3.6.0，PROJECT_NAME是我们自定义的项目名称。比较好的实践方式是，在PROJECT_NAME也带上Python的版本号，以便于识别。

现假设我们有XDiff这么一个项目，想针对Python 2.7.13和Python 3.6.0分别创建一个虚拟环境，那就可以依次执行如下命令。

1
2
$ pyenv virtualenv 3.6.0 py36_XDiff
$ pyenv virtualenv 2.7.13 py27_XDiff

创建完成后，通过执行pyenv virtualenvs命令，就可以看到本地所有的项目环境。

1
2
3
4
5
$ pyenv virtualenvs
  2.7.13/envs/py27_XDiff (created from /Users/Leo/.pyenv/versions/2.7.13)
* 3.6.0/envs/py36_XDiff (created from /Users/Leo/.pyenv/versions/3.6.0)
  py27_XDiff (created from /Users/Leo/.pyenv/versions/2.7.13)
  py36_XDiff (created from /Users/Leo/.pyenv/versions/3.6.0)

通过这种方式，在同一个Python版本下我们也可以创建多个虚拟环境，然后在各个虚拟环境中分别维护依赖库环境。

例如，py36_XDiff虚拟环境位于/Users/Leo/.pyenv/versions/3.6.0/envs目录下，而其依赖库位于/Users/Leo/.pyenv/versions/3.6.0/lib/python3.6/site-packages中。

1
2
$ pip -V
pip 9.0.1 from /Users/Leo/.pyenv/versions/3.6.0/lib/python3.6/site-packages (python 3.6)

后续在项目开发过程中，我们就可以通过pyenv local XXX或pyenv activate PROJECT_NAME命令来切换项目的Python环境。

1
2
3
4
5
6
7
➜  MyProjects pyenv local py27_XDiff
(py27_XDiff) ➜  MyProjects pyenv version
py27_XDiff (set by /Users/Leo/MyProjects/.python-version)
(py27_XDiff) ➜  MyProjects python -V
Python 2.7.13
(py27_XDiff) ➜  MyProjects pip -V
pip 9.0.1 from /Users/Leo/.pyenv/versions/2.7.13/envs/py27_XDiff/lib/python2.7/site-packages (python 2.7)

可以看出，切换环境后，pip命令对应的目录也随之改变，即始终对应着当前的Python虚拟环境。

对应的，采用pyenv deactivate命令退出当前项目的Python虚拟环境。

如果想移除某个项目环境，可以通过如下命令实现。

1
$ pyenv uninstall PROJECT_NAME

以上便是日常开发工作中常用的pyenv命令，基本可以满足绝大多数依赖库环境管理方面的需求。

发表于 更新于 分类于

背景介绍

在使用GitHub的过程中，假如某次提交代码时不小心将密码或SSH-key提交进了公共仓库。当然，希望这种事情永远也不会发生，但是如果真遇到了，该怎么办呢？

如果发现得及时，本地提交后还没有推送到GitHub远程仓库的话，这种情况还好处理，直接修改代码后通过git commit --amend即可。

但如果发现时已经推送到了GitHub远程仓库，或者已过了许久，后续有了很多新的commits，这种情况就会比较复杂了。

错误的方式是，直接在当前代码中去除敏感信息，然后再提交到代码仓库中。这样的做法只能在最新的代码中去除了敏感信息，在git历史记录中仍然保存着敏感信息。

当然，也可以选择直接将整个仓库删除了。不过，看着昔日精心提交的代码记录，实在是难以下手。

要是可以只删除敏感信息部分，而不影响到其它提交记录就好了。事实上，GIT的确支持这种操作。

处理方式

实现的方式有两种，一是通过git filter-branch命令，另一种是采用一款开源的工具，BFG Repo-Cleaner。前者是GIT官方的实现方法，后者是一款采用Scala编写的工具，号称比git filter-branch更简单、更快捷。

git filter-branch

先来看下git filter-branch这种方式。假设要在所有历史提交记录中删除文件PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA，那么就可以采用如下命令：

1
2
3
4
5
6
$ git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA' \
--prune-empty --tag-name-filter cat -- --all

> Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (266/266)
> Ref 'refs/heads/master' was rewritten

正常情况下，通过执行上面的命令，就可以在所有历史提交记录中彻底删除指定文件。如果要进一步确定的话，可以在.git目录中进行全局搜索，确保已彻底清理干净。

然后，就可以通过如下命令将本地代码推送到GitHub上，并强制覆盖掉所有历史记录。

1
$ git push origin --force --all

可以看出，采用git filter-branch的操作命令十分复杂（复杂到我也不想理会每个参数的具体含义），这还只是选择粗暴地将整个文件进行删除的情况。如果不想删除文件，而是单独修改特定文件特定内容的话，操作会更加复杂，如有兴趣可查看git官方文档。

BFG Repo-Cleaner

估计也是因为官方的git filter-branch太过复杂，于是Roberto Tyley开发了BFG Repo-Cleaner这款工具。该工具是专门针对移除历史记录的需求而产生的，这可以从其简介中看出来。

Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala

使用BFG Repo-Cleaner之前，需要先下载BFG's jar(requires Java 7 or above)。

如果想实现前面例子中同样的功能，删除文件PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA，可以通过如下命令实现：

1
$ java -jar bfg.jar --delete-files PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA my-repo.git

如果不想删除文件，而是单独修改特定文件特定内容的话，就可以通过如下命令实现：

1
$ java -jar bfg.jar --replace-text replacements.txt my-repo.git

在replacements.txt文件中，应包含所有需要替换的内容，格式如下（不包含注释内容）：

1
2
3
4
5
PASSWORD1                       # Replace with '***REMOVED***' (default)
PASSWORD2==>examplePass         # replace with 'examplePass' instead
PASSWORD3==>                    # replace with the empty string
regex:password=\w+==>password=  # Replace, using a regex
regex:\r(\n)==>$1               # Replace Windows newlines with Unix newlines

通过执行上述命令，BFG Repo-Cleaner就会扫描代码仓库的所有历史提交记录，并按照replacements.txt文件中的映射进行替换操作。

通过对比可以看到，BFG Repo-Cleaner的确是更加简洁，这也是GitHub官方推荐的方式。不过，在BFG Repo-Cleaner的介绍文档中也说了，该工具的优势在于简单和快捷，从功能强大的角度来讲，它是比不上git-filter-branch的，有些操作也只能通过git-filter-branch完成。

如需了解BFG Repo-Cleaner的更多用法，可详细阅读其文档。

写在末尾

不要问我为啥写了这么一篇博客，让我再哭一会儿。我也真心地希望大家永远不会用到这些工具。

小心驶得万年船，共勉！

阅读更多

发表于 更新于 分类于 ，

在《【LocustPlus序】漫谈服务端性能测试》中，我对服务端性能测试的基础概念和性能测试工具的基本原理进行了介绍，并且重点推荐了Locust这一款开源性能测试工具。然而，当前在网络上针对Locust的教程极少，不管是中文还是英文，基本都是介绍安装方法和简单的测试案例演示，但对于较复杂测试场景的案例演示却基本没有，因此很多测试人员都感觉难以将Locust应用到实际的性能测试工作当中。

经过一段时间的摸索，包括通读Locust官方文档和项目源码，并且在多个性能测试项目中对Locust进行应用实践，事实证明，Locust完全能满足日常的性能测试需求，LoadRunner能实现的功能Locust也基本都能实现。

本文将从Locust的功能特性出发，结合实例对Locust的使用方法进行介绍。考虑到大众普遍对LoadRunner比较熟悉，在讲解Locust时也会采用LoadRunner的一些概念进行类比。

概述

先从Locust的名字说起。Locust的原意是蝗虫，原作者之所以选择这个名字，估计也是听过这么一句俗语，“蝗虫过境，寸草不生”。我在网上找了张图片，大家可以感受下。

而Locust工具生成的并发请求就跟一大群蝗虫一般，对我们的被测系统发起攻击，以此检测系统在高并发压力下是否能正常运转。

在《【LocustPlus序】漫谈服务端性能测试》中说过，服务端性能测试工具最核心的部分是压力发生器，而压力发生器的核心要点有两个，一是真实模拟用户操作，二是模拟有效并发。

在Locust测试框架中，测试场景是采用纯Python脚本进行描述的。对于最常见的HTTP(S)协议的系统，Locust采用Python的requests库作为客户端，使得脚本编写大大简化，富有表现力的同时且极具美感。而对于其它协议类型的系统，Locust也提供了接口，只要我们能采用Python编写对应的请求客户端，就能方便地采用Locust实现压力测试。从这个角度来说，Locust可以用于压测任意类型的系统。

在模拟有效并发方面，Locust的优势在于其摒弃了进程和线程，完全基于事件驱动，使用gevent提供的非阻塞IO和coroutine来实现网络层的并发请求，因此即使是单台压力机也能产生数千并发请求数；再加上对分布式运行的支持，理论上来说，Locust能在使用较少压力机的前提下支持极高并发数的测试。

脚本编写

编写Locust脚本，是使用Locust的第一步，也是最为重要的一步。

简单示例

先来看一个最简单的示例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
from locust import HttpLocust, TaskSet, task

class WebsiteTasks(TaskSet):
    def on_start(self):
        self.client.post("/login", {
            "username": "test",
            "password": "123456"
        })

    @task(2)
    def index(self):
        self.client.get("/")

    @task(1)
    def about(self):
        self.client.get("/about/")

class WebsiteUser(HttpLocust):
    task_set = WebsiteTasks
    host = "https://debugtalk.com"
    min_wait = 1000
    max_wait = 5000

在这个示例中，定义了针对https://debugtalk.com网站的测试场景：先模拟用户登录系统，然后随机地访问首页（/）和关于页面（/about/），请求比例为2:1；并且，在测试过程中，两次请求的间隔时间为1~5秒间的随机值。

那么，如上Python脚本是如何表达出以上测试场景的呢？

从脚本中可以看出，脚本主要包含两个类，一个是WebsiteUser（继承自HttpLocust，而HttpLocust继承自Locust），另一个是WebsiteTasks（继承自TaskSet）。事实上，在Locust的测试脚本中，所有业务测试场景都是在Locust和TaskSet两个类的继承子类中进行描述的。

那如何理解Locust和TaskSet这两个类呢？

简单地说，Locust类就好比是一群蝗虫，而每一只蝗虫就是一个类的实例。相应的，TaskSet类就好比是蝗虫的大脑，控制着蝗虫的具体行为，即实际业务场景测试对应的任务集。

这个比喻可能不是很准确，接下来，我将分别对Locust和TaskSet两个类进行详细介绍。

class HttpLocust(Locust)

在Locust类中，具有一个client属性，它对应着虚拟用户作为客户端所具备的请求能力，也就是我们常说的请求方法。通常情况下，我们不会直接使用Locust类，因为其client属性没有绑定任何方法。因此在使用Locust时，需要先继承Locust类，然后在继承子类中的client属性中绑定客户端的实现类。

对于常见的HTTP(S)协议，Locust已经实现了HttpLocust类，其client属性绑定了HttpSession类，而HttpSession又继承自requests.Session。因此在测试HTTP(S)的Locust脚本中，我们可以通过client属性来使用Python requests库的所有方法，包括GET/POST/HEAD/PUT/DELETE/PATCH等，调用方式也与requests完全一致。另外，由于requests.Session的使用，因此client的方法调用之间就自动具有了状态记忆的功能。常见的场景就是，在登录系统后可以维持登录状态的Session，从而后续HTTP请求操作都能带上登录态。

而对于HTTP(S)以外的协议，我们同样可以使用Locust进行测试，只是需要我们自行实现客户端。在客户端的具体实现上，可通过注册事件的方式，在请求成功时触发events.request_success，在请求失败时触发events.request_failure即可。然后创建一个继承自Locust类的类，对其设置一个client属性并与我们实现的客户端进行绑定。后续，我们就可以像使用HttpLocust类一样，测试其它协议类型的系统。

原理就是这样简单！

在Locust类中，除了client属性，还有几个属性需要关注下：

  • task_set: 指向一个TaskSet类，TaskSet类定义了用户的任务信息，该属性为必填；
  • max_wait/min_wait: 每个用户执行两个任务间隔时间的上下限（毫秒），具体数值在上下限中随机取值，若不指定则默认间隔时间固定为1秒；
  • host：被测系统的host，当在终端中启动locust时没有指定--host参数时才会用到；
  • weight：同时运行多个Locust类时会用到，用于控制不同类型任务的执行权重。

测试开始后，每个虚拟用户（Locust实例）的运行逻辑都会遵循如下规律：

  1. 先执行WebsiteTasks中的on_start（只执行一次），作为初始化；
  2. 从WebsiteTasks中随机挑选（如果定义了任务间的权重关系，那么就是按照权重关系随机挑选）一个任务执行；
  3. 根据Locust类中min_wait和max_wait定义的间隔时间范围（如果TaskSet类中也定义了min_wait或者max_wait，以TaskSet中的优先），在时间范围中随机取一个值，休眠等待；
  4. 重复2~3步骤，直至测试任务终止。

class TaskSet

再说下TaskSet类。

性能测试工具要模拟用户的业务操作，就需要通过脚本模拟用户的行为。在前面的比喻中说到，TaskSet类好比蝗虫的大脑，控制着蝗虫的具体行为。

具体地，TaskSet类实现了虚拟用户所执行任务的调度算法，包括规划任务执行顺序（schedule_task）、挑选下一个任务（execute_next_task）、执行任务（execute_task）、休眠等待（wait）、中断控制（interrupt）等等。在此基础上，我们就可以在TaskSet子类中采用非常简洁的方式来描述虚拟用户的业务测试场景，对虚拟用户的所有行为（任务）进行组织和描述，并可以对不同任务的权重进行配置。

在TaskSet子类中定义任务信息时，可以采取两种方式，@task装饰器和tasks属性。

采用@task装饰器定义任务信息时，描述形式如下：

1
2
3
4
5
6
7
8
9
10
from locust import TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def test_job1(self):
        self.client.get('/job1')

    @task(2)
    def test_job2(self):
        self.client.get('/job2')

采用tasks属性定义任务信息时，描述形式如下：

1
2
3
4
5
6
7
8
9
10
11
from locust import TaskSet

def test_job1(obj):
    obj.client.get('/job1')

def test_job2(obj):
    obj.client.get('/job2')

class UserBehavior(TaskSet):
    tasks = {test_job1:1, test_job2:2}
    # tasks = [(test_job1,1), (test_job1,2)] # 两种方式等价

在如上两种定义任务信息的方式中，均设置了权重属性，即执行test_job2的频率是test_job1的两倍。

若不指定执行任务的权重，则相当于比例为1:1。

1
2
3
4
5
6
7
8
9
10
from locust import TaskSet, task

class UserBehavior(TaskSet):
    @task
    def test_job1(self):
        self.client.get('/job1')

    @task
    def test_job2(self):
        self.client.get('/job2')
1
2
3
4
5
6
7
8
9
10
11
from locust import TaskSet

def test_job1(obj):
    obj.client.get('/job1')

def test_job2(obj):
    obj.client.get('/job2')

class UserBehavior(TaskSet):
    tasks = [test_job1, test_job2]
    # tasks = {test_job1:1, test_job2:1} # 两种方式等价

在TaskSet子类中除了定义任务信息，还有一个是经常用到的，那就是on_start函数。这个和LoadRunner中的vuser_init功能相同，在正式执行测试前执行一次，主要用于完成一些初始化的工作。例如，当测试某个搜索功能，而该搜索功能又要求必须为登录态的时候，就可以先在on_start中进行登录操作；前面也提到，HttpLocust使用到了requests.Session，因此后续所有任务执行过程中就都具有登录态了。

脚本增强

掌握了HttpLocust和TaskSet，我们就基本具备了编写测试脚本的能力。此时再回过头来看前面的案例，相信大家都能很好的理解了。

然而，当面对较复杂的测试场景，可能有的同学还是会感觉无从下手；例如，很多时候脚本需要做关联或参数化处理，这些在LoadRunner中集成的功能，换到Locust中就不知道怎么实现了。可能也是这方面的原因，造成很多测试人员都感觉难以将Locust应用到实际的性能测试工作当中。

其实这也跟Locust的目标定位有关，Locust的定位就是small and very hackable。但是小巧并不意味着功能弱，我们完全可以通过Python脚本本身来实现各种各样的功能，如果大家有疑问，我们不妨逐项分解来看。

在LoadRunner这款功能全面应用广泛的商业性能测试工具中，脚本增强无非就涉及到四个方面：

  • 关联
  • 参数化
  • 检查点
  • 集合点

先说关联这一项。在某些请求中，需要携带之前从Server端返回的参数，因此在构造请求时需要先从之前请求的Response中提取出所需的参数，常见场景就是session_id。针对这种情况，LoadRunner虽然可能通过录制脚本进行自动关联，但是效果并不理想，在实际测试过程中也基本都是靠测试人员手动的来进行关联处理。

在LoadRunner中手动进行关联处理时，主要是通过使用注册型函数，例如web_reg_save_param，对前一个请求的响应结果进行解析，根据左右边界或其它特征定位到参数值并将其保存到参数变量，然后在后续请求中使用该参数。采用同样的思想，我们在Locust脚本中也完全可以实现同样的功能，毕竟只是Python脚本，通过官方库函数re.search就能实现所有需求。甚至针对html页面，我们也可以采用lxml库，通过etree.HTML(html).xpath来更优雅地实现元素定位。

然后再来看参数化这一项。这一项极其普遍，主要是用在测试数据方面。但通过归纳，发现其实也可以概括为三种类型。

  • 循环取数据，数据可重复使用：e.g. 模拟3用户并发请求网页，总共有100个URL地址，每个虚拟用户都会依次循环加载这100个URL地址；
  • 保证并发测试数据唯一性，不循环取数据：e.g. 模拟3用户并发注册账号，总共有90个账号，要求注册账号不重复，注册完毕后结束测试；
  • 保证并发测试数据唯一性，循环取数据：模拟3用户并发登录账号，总共有90个账号，要求并发登录账号不相同，但数据可循环使用。

通过以上归纳，可以确信地说，以上三种类型基本上可以覆盖我们日常性能测试工作中的所有参数化场景。

在LoadRunner中是有一个集成的参数化模块，可以直接配置参数化策略。那在Locust要怎样实现该需求呢？

答案依旧很简单，使用Python的list和queue数据结构即可！具体做法是，在WebsiteUser定义一个数据集，然后所有虚拟用户在WebsiteTasks中就可以共享该数据集了。如果不要求数据唯一性，数据集选择list数据结构，从头到尾循环遍历即可；如果要求数据唯一性，数据集选择queue数据结构，取数据时进行queue.get()操作即可，并且这也不会循环取数据；至于涉及到需要循环取数据的情况，那也简单，每次取完数据后再将数据插入到队尾即可，queue.put_nowait(data)。

最后再说下检查点。该功能在LoadRunner中通常是使用web_reg_find这类注册函数进行检查的。在Locust脚本中，处理就更方便了，只需要对响应的内容关键字进行assert xxx in response操作即可。

针对如上各种脚本增强的场景，我也通过代码示例分别进行了演示。但考虑到文章中插入太多代码会影响到阅读，因此将代码示例部分剥离了出来，如有需要请点击查看《深入浅出开源性能测试工具Locust（脚本增强）》。

Locust运行模式

在开始运行Locust脚本之前，我们先来看下Locust支持的运行模式。

运行Locust时，通常会使用到两种运行模式：单进程运行和多进程分布式运行。

单进程运行模式的意思是，Locust所有的虚拟并发用户均运行在单个Python进程中，具体从使用形式上，又分为no_web和web两种形式。该种模式由于单进程的原因，并不能完全发挥压力机所有处理器的能力，因此主要用于调试脚本和小并发压测的情况。

当并发压力要求较高时，就需要用到Locust的多进程分布式运行模式。从字面意思上看，大家可能第一反应就是多台压力机同时运行，每台压力机分担负载一部分的压力生成。的确，Locust支持任意多台压力机（一主多从）的分布式运行模式，但这里说到的多进程分布式运行模式还有另外一种情况，就是在同一台压力机上开启多个slave的情况。这是因为当前阶段大多数计算机的CPU都是多处理器（multiple processor cores），单进程运行模式下只能用到一个处理器的能力，而通过在一台压力机上运行多个slave，就能调用多个处理器的能力了。比较好的做法是，如果一台压力机有N个处理器内核，那么就在这台压力机上启动一个master，N个slave。当然，我们也可以启动N的倍数个slave，但是根据我的试验数据，效果跟N个差不多，因此只需要启动N个slave即可。

脚本调试

Locust脚本编写完毕后，通常不会那么顺利，在正式开始性能测试之前还需要先调试运行下。

不过，Locust脚本虽然为Python脚本，但却很难直接当做Python脚本运行起来，为什么呢？这主要还是因为Locust脚本中引用了HttpLocust和TaskSet这两个类，如果要想直接对其进行调用测试，会发现编写启动脚本是一个比较困难的事情。因为这个原因，刚接触Locust的同学可能就会觉得Locust脚本不好调试。

但这个问题也能克服，那就是借助Locust的单进程no_web运行模式。

在Locust的单进程no_web运行模式中，我们可以通过--no_web参数，指定并发数（-c）和总执行次数（-n），直接在Terminal中执行脚本。

在此基础上，当我们想要调试Locust脚本时，就可以在脚本中需要调试的地方通过print打印日志，然后将并发数和总执行次数都指定为1，执行形式如下所示。

1
$ locust -f locustfile.py --no_web -c 1 -n 1

通过这种方式，我们就能很方便地对Locust脚本进行调试了。

执行测试

Locust脚本调试通过后，就算是完成了所有准备工作，可以开始进行压力测试了。

Locust是通过在Terminal中执行命令进行启动的，通用的参数有如下两个：

  • -H, --host：被测系统的host，若在Terminal中不进行指定，就需要在Locust子类中通过host参数进行指定；
  • -f, --locustfile：指定执行的Locust脚本文件；

除了这两个通用的参数，我们还需要根据实际测试场景，选择不同的Locust运行模式，而模式的指定也是通过其它参数来进行控制的。

单进程运行

no_web

如果采用no_web形式，则需使用--no-web参数，并会用到如下几个参数。

  • -c, --clients：指定并发用户数；
  • -n, --num-request：指定总执行测试；
  • -r, --hatch-rate：指定并发加压速率，默认值位1。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
$ locust -H https://debugtalk.com -f demo.py --no-web -c1 -n2
[2017-02-21 21:27:26,522] Leos-MacBook-Air.local/INFO/locust.main: Starting Locust 0.8a2
[2017-02-21 21:27:26,523] Leos-MacBook-Air.local/INFO/locust.runners: Hatching and swarming 1 clients at the rate 1 clients/s...
 Name                                                          # reqs      # fails     Avg     Min     Max  |  Median   req/s
--------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------
 Total                                                              0     0(0.00%)                                       0.00

[2017-02-21 21:27:27,526] Leos-MacBook-Air.local/INFO/locust.runners: All locusts hatched: WebsiteUser: 1
[2017-02-21 21:27:27,527] Leos-MacBook-Air.local/INFO/locust.runners: Resetting stats

 Name                                                          # reqs      # fails     Avg     Min     Max  |  Median   req/s
--------------------------------------------------------------------------------------------------------------------------------------
 GET /about/                                                        0     0(0.00%)       0       0       0  |       0    0.00
--------------------------------------------------------------------------------------------------------------------------------------
 Total                                                              0     0(0.00%)                                       0.00

 Name                                                          # reqs      # fails     Avg     Min     Max  |  Median   req/s
--------------------------------------------------------------------------------------------------------------------------------------
 GET /about/                                                        1     0(0.00%)      17      17      17  |      17    0.00
--------------------------------------------------------------------------------------------------------------------------------------
 Total                                                              1     0(0.00%)                                       0.00

[2017-02-21 21:27:32,420] Leos-MacBook-Air.local/INFO/locust.runners: All locusts dead

[2017-02-21 21:27:32,421] Leos-MacBook-Air.local/INFO/locust.main: Shutting down (exit code 0), bye.
 Name                                                          # reqs      # fails     Avg     Min     Max  |  Median   req/s
--------------------------------------------------------------------------------------------------------------------------------------
 GET /                                                              1     0(0.00%)      20      20      20  |      20    0.00
 GET /about/                                                        1     0(0.00%)      17      17      17  |      17    0.00
--------------------------------------------------------------------------------------------------------------------------------------
 Total                                                              2     0(0.00%)                                       0.00

Percentage of the requests completed within given times
 Name                                                           # reqs    50%    66%    75%    80%    90%    95%    98%    99%   100%
--------------------------------------------------------------------------------------------------------------------------------------
 GET /                                                               1     20     20     20     20     20     20     20     20     20
 GET /about/                                                         1     17     17     17     17     17     17     17     17     17
--------------------------------------------------------------------------------------------------------------------------------------

web

如果采用web形式，，则通常情况下无需指定其它额外参数，Locust默认采用8089端口启动web；如果要使用其它端口，就可以使用如下参数进行指定。

  • -P, --port：指定web端口，默认为8089.
1
2
3
$ locust -H https://debugtalk.com -f demo.py
[2017-02-21 21:31:26,334] Leos-MacBook-Air.local/INFO/locust.main: Starting web monitor at *:8089
[2017-02-21 21:31:26,334] Leos-MacBook-Air.local/INFO/locust.main: Starting Locust 0.8a2

此时，Locust并没有开始执行测试，还需要在Web页面中配置参数后进行启动。

如果Locust运行在本机，在浏览器中访问http://localhost:8089即可进入Locust的Web管理页面；如果Locust运行在其它机器上，那么在浏览器中访问http://locust_machine_ip:8089即可。

在Locust的Web管理页面中，需要配置的参数只有两个：

  • Number of users to simulate: 设置并发用户数，对应中no_web模式的-c, --clients参数；
  • Hatch rate (users spawned/second): 启动虚拟用户的速率，对应着no_web模式的-r, --hatch-rate参数。

参数配置完毕后，点击【Start swarming】即可开始测试。

多进程分布式运行

不管是单机多进程，还是多机负载模式，运行方式都是一样的，都是先运行一个master，再启动多个slave。

启动master时，需要使用--master参数；同样的，如果要使用8089以外的端口，还需要使用-P, --port参数。

1
2
3
$ locust -H https://debugtalk.com -f demo.py --master --port=8088
[2017-02-21 22:59:57,308] Leos-MacBook-Air.local/INFO/locust.main: Starting web monitor at *:8088
[2017-02-21 22:59:57,310] Leos-MacBook-Air.local/INFO/locust.main: Starting Locust 0.8a2

master启动后，还需要启动slave才能执行测试任务。

启动slave时需要使用--slave参数；在slave中，就不需要再指定端口了。

1
2
3
4
$ locust -H https://debugtalk.com -f demo.py --slave
[2017-02-21 23:07:58,696] Leos-MacBook-Air.local/INFO/locust.main: Starting Locust 0.8a2
[2017-02-21 23:07:58,696] Leos-MacBook-Air.local/INFO/locust.runners: Client 'Leos-MacBook-Air.local_980ab0eec2bca517d03feb60c31d6a3a' reported as
 ready. Currently 2 clients ready to swarm.

如果slave与master不在同一台机器上，还需要通过--master-host参数再指定master的IP地址。

1
2
3
4
$ locust -H https://debugtalk.com -f demo.py --slave --master-host=<locust_machine_ip>
[2017-02-21 23:07:58,696] Leos-MacBook-Air.local/INFO/locust.main: Starting Locust 0.8a2
[2017-02-21 23:07:58,696] Leos-MacBook-Air.local/INFO/locust.runners: Client 'Leos-MacBook-Air.local_980ab0eec2bca517d03feb60c31d6a3a' reported as
 ready. Currently 2 clients ready to swarm.

master和slave都启动完毕后，就可以在浏览器中通过http://locust_machine_ip:8089进入Locust的Web管理页面了。使用方式跟单进程web形式完全相同，只是此时是通过多进程负载来生成并发压力，在web管理界面中也能看到实际的slave数量。

测试结果展示

Locust在执行测试的过程中，我们可以在web界面中实时地看到结果运行情况。

相比于LoadRunner，Locust的结果展示十分简单，主要就四个指标：并发数、RPS、响应时间、异常率。但对于大多数场景来说，这几个指标已经足够了。

在上图中，RPS和平均响应时间这两个指标显示的值都是根据最近2秒请求响应数据计算得到的统计值，我们也可以理解为瞬时值。

如果想看性能指标数据的走势，就可以在Charts栏查看。在这里，可以查看到RPS和平均响应时间在整个运行过程中的波动情况。这个功能之前在Locust中一直是缺失的，直到最近，这个坑才被我之前在阿里移动的同事（网络IDmyzhan）给填上了。当前该功能已经合并到Locust了，更新到最新版即可使用。

除了以上数据，Locust还提供了整个运行过程数据的百分比统计值，例如我们常用的90%响应时间、响应时间中位值，该数据可以通过Download response time distribution CSV获得，数据展示效果如下所示。

总结

通过前面对Locust全方位的讲解，相信大家对Locust的功能特性已经非常熟悉了，在实际项目中将Locust作为生产力工具应该也没啥问题了。

不过，任何一款工具都不是完美的，必定都会存在一些不足之处。但是好在Locust具有极强的可定制型，当我们遇到一些特有的需求时，可以在Locust上很方便地实现扩展。

还是前面提到的那位技术大牛（myzhan），他为了摆脱CPython的GIL和gevent的 monkey_patch()，将Locust的slave端采用golang进行了重写，采用goroutine取代了gevent。经过测试，相较于原生的Python实现，他的这套golang实现具有5~10倍以上的性能提升。当前，他已经将该实现开源，项目名称为myzhan/boomer，如果大家感兴趣，可以阅读他的博客文章进一步了解，《用 golang 来编写压测工具》。

如果我们也想在Locust的基础上进行二次开发，那要怎么开始呢？

毫无疑问，阅读Locust的项目源码是必不可少的第一步。可能对于很多人来说，阅读开源项目源码是一件十分困难的事情，不知道如何着手，在知乎上也看到好多关于如何阅读开源项目源码的提问。事实上，Locust项目的代码结构清晰，核心代码量也比较少，十分适合阅读学习。哪怕只是想体验下阅读开源项目源码，或者说想提升下自己的Python技能，Locust也是个不错的选择。

在下一篇文章中，我将对Locust源码进行解析，《深入浅出开源性能测试工具Locust（源码篇）》，敬请期待！

发表于 更新于 分类于 ，

在《深入浅出开源性能测试工具Locust（使用篇）》一文中，罗列了编写性能测试脚本时常用的几类脚本增强的场景，本文是对应的代码示例。

关联

在某些请求中，需要携带之前从Server端返回的参数，因此在构造请求时需要先从之前的Response中提取出所需的参数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
from lxml import etree
from locust import TaskSet, task, HttpLocust

class UserBehavior(TaskSet):

    @staticmethod
    def get_session(html):
        tree = etree.HTML(html)
        return tree.xpath("//div[@class='btnbox']/input[@name='session']/@value")[0]

    @task(10)
    def test_login(self):
        html = self.client.get('/login').text
        username = 'user@compay.com'
        password = '123456'
        session = self.get_session(html)
        payload = {
            'username': username,
            'password': password,
            'session': session
        }
        self.client.post('/login', data=payload)

class WebsiteUser(HttpLocust):
    host = 'https://debugtalk.com'
    task_set = UserBehavior
    min_wait = 1000
    max_wait = 3000

参数化

循环取数据，数据可重复使用

所有并发虚拟用户共享同一份测试数据，各虚拟用户在数据列表中循环取值。
例如，模拟3用户并发请求网页，总共有100个URL地址，每个虚拟用户都会依次循环加载这100个URL地址；加载示例如下表所示。

\ vuser1 vuser2 vuser3
iteration1 url1 url1 url1
iteration2 url2 url2 url2
… … … …
iteration100 url100 url100 url100 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
from locust import TaskSet, task, HttpLocust

class UserBehavior(TaskSet):
    def on_start(self):
        self.index = 0

    @task
    def test_visit(self):
        url = self.locust.share_data[self.index]
        print('visit url: %s' % url)
        self.index = (self.index + 1) % len(self.locust.share_data)
        self.client.get(url)

class WebsiteUser(HttpLocust):
    host = 'https://debugtalk.com'
    task_set = UserBehavior
    share_data = ['url1', 'url2', 'url3', 'url4', 'url5']
    min_wait = 1000
    max_wait = 3000

保证并发测试数据唯一性，不循环取数据

所有并发虚拟用户共享同一份测试数据，并且保证虚拟用户使用的数据不重复。
例如，模拟3用户并发注册账号，总共有9个账号，要求注册账号不重复，注册完毕后结束测试；加载示例如下表所示。

\ vuser1 vuser2 vuser3
iteration1 account1 account2 account3
iteration2 account4 account6 account5
iteration3 account7 account9 account8
N/A - — - 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
from locust import TaskSet, task, HttpLocust
import queue

class UserBehavior(TaskSet):

    @task
    def test_register(self):
        try:
            data = self.locust.user_data_queue.get()
        except queue.Empty:
            print('account data run out, test ended.')
            exit(0)

        print('register with user: {}, pwd: {}'\
            .format(data['username'], data['password']))
        payload = {
            'username': data['username'],
            'password': data['password']
        }
        self.client.post('/register', data=payload)

class WebsiteUser(HttpLocust):
    host = 'https://debugtalk.com'
    task_set = UserBehavior

    user_data_queue = queue.Queue()
    for index in range(100):
        data = {
            "username": "test%04d" % index,
            "password": "pwd%04d" % index,
            "email": "test%04d@debugtalk.test" % index,
            "phone": "186%08d" % index,
        }
        user_data_queue.put_nowait(data)

    min_wait = 1000
    max_wait = 3000

保证并发测试数据唯一性，循环取数据

所有并发虚拟用户共享同一份测试数据，保证并发虚拟用户使用的数据不重复，并且数据可循环重复使用。
例如，模拟3用户并发登录账号，总共有9个账号，要求并发登录账号不相同，但数据可循环使用；加载示例如下表所示。

\ vuser1 vuser2 vuser3
iteration1 account1 account2 account3
iteration2 account4 account6 account5
iteration3 account7 account9 account8
iteration4 account1 account2 account3
iteration5 account4 account5 account6
… … … …

该种场景的实现方式与上一种场景基本相同，唯一的差异在于，每次使用完数据后，需要再将数据放入队列中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
from locust import TaskSet, task, HttpLocust
import queue

class UserBehavior(TaskSet):

    @task
    def test_register(self):
        try:
            data = self.locust.user_data_queue.get()
        except queue.Empty:
            print('account data run out, test ended.')
            exit(0)

        print('register with user: {}, pwd: {}'\
            .format(data['username'], data['password']))
        payload = {
            'username': data['username'],
            'password': data['password']
        }
        self.client.post('/register', data=payload)
        self.locust.user_data_queue.put_nowait(data)

class WebsiteUser(HttpLocust):
    host = 'https://debugtalk.com'
    task_set = UserBehavior

    user_data_queue = queue.Queue()
    for index in range(100):
        data = {
            "username": "test%04d" % index,
            "password": "pwd%04d" % index,
            "email": "test%04d@debugtalk.test" % index,
            "phone": "186%08d" % index,
        }
        user_data_queue.put_nowait(data)

    min_wait = 1000
    max_wait = 3000

发表于 更新于 分类于

今年春节没有像往常一样回家过年，而是到欧洲旅行（意大利和法国），算是蜜月游吧。第一次到欧洲，确切地说，第一次出国，新鲜感还是蛮大的，趁着返程飞机上的空闲时间，写篇博客记录下。

我这次旅行全程12天，游玩的城市有罗马、梵蒂冈、佛罗伦萨、米兰和巴黎，景点以历史名胜和城市风光为主。全程自助游，行程安排比较自由宽松。当然，这篇博客并不是旅行攻略，描述的内容也不会面面俱到，只是挑了几个感触较深的点，观点可能很是片面，如有偏颇还请留言讨论。

先说下总体印象吧。如果说要通过几个关键词来概括这次旅行的所见所闻，特别是跟国内（一二线城市）进行对比的话，我个人的印象是：自然环境优美、生活节奏舒缓、饮食类型单一、公共设施陈旧、公共安全紧张、工程师氛围稀缺。

自然环境优美没啥好说的，之前不管是通过网络，还是和朋友的聊天交流，对欧洲的印象就是自然环境特别好。实际情况也的确是这样的。空气质量这块儿我没啥特别的感觉，因为深圳的空气本来也挺好的。见过的河水湖泊很是清澈，完全没有污染的痕迹。绿化非常赞，除了街道的树木，在城市中有很多森林公园。印象最深的就是小动物了，虽然是在城市里，但是到处都能看到鸽子、海鸥，在公园里还能看到野鸡、野鸭、天鹅，而且好玩的是这些动物基本都不怕人，靠近它们的时候也不会躲避，我还趁天鹅把头钻进水里捕食时偷偷摸了它的屁股。想想在国内，能在城市中看见只麻雀就算稀罕了，这方面真是没法比。

在人文环境方面，最大的感触就是欧洲的生活节奏十分舒缓。店铺通常开得挺晚的，关得也特别早，特别是在罗马和佛罗伦萨，下午六七点天黑后，就基本很少看到人了。在我等天朝IT狗的眼里，他们的工作量真是极其的不饱和啊。可能也是这方面的原因，商家普遍的服务态度都挺好的，很有耐心。有一次在梵蒂冈的礼品店里，虽然语言交流不是很顺畅，但老太太还是很有耐心的一一介绍，最后由于感觉价格比较贵，不大好意思地说不买了，老太太也完全没有表现出任何不悦，而是笑盈盈地说了句Thank you, have a nice day。在欧洲街道上，如果是在没有红绿灯的情况下，司机都会挥手示意让行人先过马路。刚开始的时候还有些不习惯，站在路口等汽车先走，结果司机更有耐心，执意等行人先走。哦对，在欧洲马路上，基本上没有听到汽车喇叭声，有时候没有看到身后的车辆，司机会探出头来打招呼。另外，在欧洲街头经常会看见各种行为艺术，特别是在罗马斗兽场的一条街道上，一路走去，吹拉弹唱跳，形式各异，水准颇高，真是一道靓丽的风景。看到他们总会经不住感叹，人家这才是生活啊，我等只能叫活着。

说到语言交流，这跟我之前的预期不大一样。在没出国之前，原以为欧洲的英语应该普及度很高，结果到了这边后发现并非如此，好多本地人并不会英语，即使是警察这样的公务员，会说英语的也是少数，而且口音还特别重。不过语言也真是一个神奇的东西，可能同样的场景，做英语听力理解题时无法正确答题，但是在面对面交流时，加上简单的肢体动作和眼神，基本上只要不是太复杂的场景，都难很好的完成交流。最多为了保险起见，我再用英语复述一遍我的理解，跟对方进行确认即可。哦对了，在欧洲遇到的好多人虽然不会说英语，但是貌似听懂是没啥问题，只是可能有些词汇不理解，需要变换下说法。例如，在询问能不能飞无人机时，跟他们说drone他们都不知道是啥意思，但是说mini aircraft他们就会明白了。

然后说下差异最大的饮食吧。跟博大精深的中餐相比，欧洲的饮食真是单一乏味。当然，像法餐这样高逼格的不在讨论范围内，价格太贵，我相信即使是本地人也不至于天天这么吃吧。在意大利和法国，当地人吃得最多的应该就是披萨和汉堡了。在我看来，意大利人真是除了披萨意面就没啥别的了。虽然披萨被做出花儿了，各种馅儿的都有，但老是这么吃还是受不了。意面更别提了，我们吃了一次就不想再吃。有一次在披萨店惊奇地发现有米饭，结果还是半生的，完全没法吃，想想也是，微波炉哪能做出米饭来。因此我们后面每到一个城市，就到处找中餐馆。中餐的价格普遍比披萨店贵两倍，面条、炒饭、盖浇饭这类快餐，普遍在7~9欧的样子，如果点菜的话，人均消费差不多要十多欧，这还是在比较克制的情况下。即使是这样，中餐馆的生意还都特别好。在罗马的一家中餐馆给我们的印象尤其深刻，我们是通过大众点评找过去的，结果到了以后发现门口贴纸告知要五点半开门。我们还以为店家不会开门了，就先在旁边的一家披萨店先吃着。过一会儿后，发现那家店门口逐渐聚集了一波中国人，到了五点半的时候，还真准时开门了。进去之后，发现基本满座了，全是中国人。一会儿后，服务员领班说，要等一阵才能点菜，因为厨师们要先吃饭。然后，所有顾客就看着一大桌厨师和服务员在那儿吃。我们也真是长见识了，原来餐馆还能这么开的，牛逼，换成在国内试试？

除了饮食，公共基础设施方面跟国内也没法比。首先是公交地铁，普遍比叫陈旧。特别是巴黎的RER线，简直难以相信这就是号称时尚浪漫之都的巴黎，刷票的门坏了好几个，各种电线暴露在外面垂在半空中，好多通道没有电梯，地铁车厢特别脏，地面积了厚厚的泥土和水渍，估计是好久都没有打扫过了，让我们一度以为我们到了假巴黎。然后说下欧洲的公厕，上一次要1欧，即使是在有的麦当劳店里，上厕所也是要收费的，每次想上厕所时换算下，要七块多人民币，真是尿不起啊有木有！不过公厕收费也比较好理解，因为欧洲的人力成本本来就比较高，特别是清洁工这类工种。除了硬件类的基础设施，软件类的服务跟国内相比也落后太多。在国内的时候，基本上带个手机出门就行了，吃饭、购物、叫车全电子化，但是在欧洲都基本还是用现金，大额消费可以刷信用卡，出去一趟回来兜里就好多找零的硬币。当然，虽然欧洲本土的互联网服务不咋地，但是人家能用Google的各项服务啊，光这一项我大天朝就完全被秒杀了。

在安全方面，感觉氛围比较紧张，没有在国内那么踏实。在机场、车站以及各个旅游景点，到处都是全副武装的大兵，警察也都是配枪的。本来我还打算出国后多拍下风景，特地在出国前买了一台Mavic Pro，结果到那儿以后看到这阵势，又在网上看到各种禁飞条令，因此也不敢造次，要是一不小心被当做恐怖分子击毙就不值了。另外，在街头随处可见流浪汉，甚至好多一家四五口一起睡在路边，估计是从其它国家过来避难的。如果政府没有救助措施的话，估计也会形成一定的安全隐患，之前也听朋友说最好晚上不要出门，抢劫、行窃比较多，还好我们没有遇到。

最后再说下跟我们软件工程师的相关的吧。不像在国内，上下班时满眼的笔记本电脑背包，在意大利和法国我真是一个都没看到过。我在想，这里是没有程序员的么，还是说程序员的电脑也是装在意大利皮革的手提包里了？不过，在艺术气息如此浓厚的地方，本地人应该也很难对写代码感兴趣吧。在巴黎的Airbnb民宿中，虽然没看到房东本人，但是从房屋装饰、陈列书籍和CD碟片来看，房东应该也是个搞绘画或雕塑的。之前听朋友说欧洲的技术工种稀缺，过去比较好找工作，当时我还颇为心动的；现在看来，是否稀缺不好说，但估计需求也比较少，即使过去，感觉从技术氛围的角度来看，也不是一个好的选择。所以去欧洲工作的想法先暂时搁置吧，后面再找机会去其它国家转转。

以上便是我这次欧洲意法之行的见闻和感受了，收获还是蛮大的。之前可能是一直处于天朝的大环境中，多多少少会变得有些功利和急躁，大至职业发展薪酬涨幅，小至绩效考核分数排名，很难做到不那么在意。但是当我在欧洲街头看到各类艺人专注于技艺表演时，在阿诺河旁看到白发老人沉浸于绘画写生时，我不禁在想，专注于自己喜爱的事情已经就足够幸福了，何必被世俗的眼光所左右，被眼前的蝇头小利所蒙蔽呢。虽说人生短暂，但是即使从现在开始，也还有好几十年的时光，足够自己折腾了。

嗯，前提是永远不要为自己设限。

Keep learning and programming.