场景

测试一些方法时, 可能会遇到该方法需要鉴权的情况(如login_required之类), 需要想办法绕过装饰器.

解决方案

1. 为装饰器加开关. 在装饰器中通过读取某个配置判断是否开启该装饰器;
2. mock掉装饰器.

前者操作起来方便, 但是在遇到不同装饰器都需要mock时, 为每个装饰器添加开关有些工作量;
而后者也有弊端, 即此次测试中, 所有测试都基于该装饰器不生效的情况下测试. 因此对于如权限等的测试, 需要添加其他测试手段(如接口测试)来完成.

本文讲述的是第二个解决方案的具体实现.

简介

本文针对后端服务初始化时，用户表的创建流程与具体实现做介绍。

Motor是一个异步非阻塞的MongoDB驱动程序，很好地支持了Tornado和asyncio的应用。
基于Tornado开发的后端server，为了提供优秀的系统性能通常会大量使用异步编程，因此Motor是此类系统操作MongoDB时的不二之选。
下面基于特定的场景，介绍系统初始化时涉及到的Motor操作MongoDB的方法：

设计

对于一个系统初始化，我设计为在首次访问系统时会自动创建一个admin用户用于后面的登录。

流程图：

环境

Ubuntu 18.04
Git

nodejs安装

官网下载最新的LTS版本的tar.xz包，我下载的是8.11.3

1

wget https://nodejs.org/dist/v8.11.3/node-v8.11.3-linux-x64.tar.xz

解压

1
2

xz node-v8.11.3-linux-x64.tar.xz    # 得到tar包
tar -xvf node-v8.11.3-linux-x64.tar    # 解压tar包

移动到常用应用目录/usr/local/lib

1

sudo mv node-v8.11.3-linux-x64 /usr/local/lib/node-v8.11.3

将node与npm可执行文件软链接到/usr/local/bin

1
2

ln -s /usr/local/lib/node-v8.11.3/bin/node /usr/local/bin/node
ln -s /usr/local/lib/node-v8.11.3/bin/npm /usr/local/bin/npm

测试场景

在MongoDB中存有上万个ID，某个接口需要带上ID参数，且每个ID只能使用一次，测试该接口的性能。

设计思路

思路一：一个线程组中完成数据库读ID操作，用ForEach逻辑控制器来遍历ID并发送请求。

这个过程听起来似乎能够完成这个场景，但是这需要一个很长的等待测试串行执行的时间：这可是上万个ID。

思路二：多线程并行执行。

并行执行测试用例的速度肯定要大于串行执行，并且这才符合用Jmeter的初衷。

更细化一些，我需要再建一个setUp线程组，在这个线程组中读取数据库中的ID信息并存为变量；然后，通过启动大于ID数量的线程数去执行这些用例。

为了覆盖到每一个ID，我在读取数据库后存为参数时，需要为每个ID赋上唯一的Key值，同时各个线程应该读到不同的ID，所以需要一个计数器Counter。

python3-fastunit是使用协程并发执行测试用例的测试库，能够极大提高测试执行效率！
更多关于python3-fastunit项目，参见我之前写的Python - 用协程并发执行测试用例

环境要求

Python 3.5/3.6
pip

安装

1

pip install https://github.com/ityoung/python3-fastunit/archive/master.zip

使用

使用方法与unittest库一致，仅需将import unittest改为import fastunit as unittest即可。

关于

项目地址（欢迎star/fork）：https://github.com/ityoung/python3-fastunit
作者：严北，加个人微信 shin-devops 拉你进群

简介

本文分享两个Docker镜像，能够：

1. 快速部署SonarQube静态代码分析平台；
2. 完整的SonarScanner Python环境用于快速使用。

根据这两个镜像，你可以设计合理的持续集成流程，让你的代码在提交时自动执行代码分析。

环境

• Docker
• Git
• Docker-compose

使用

1. 下载 SonarQube Docker镜像 项目

所谓师父领进门修行在个人，本文旨在介绍接口测试的学习路线，私下里，各位对每个工具都应更深入地了解一遍。同样的，在学习过程中可能会遇到一些问题，希望先自行搜索解决，要有解决问题的能力。

正文

HTTP接口测试主要工作可分为两部分：

• 发送HTTP请求（自动化部分）

• 判断响应内容是否符合预期（测试部分）

一般测试工作就是完成请求体的构造，然后根据开发给的接口文档，将构造好的请求体发送给服务端，再判断服务端返回的结果是否符合预期。然后通常会用一些测试框架，例如Python自带的unittest测试框架将零散的测试用例集中运行处理。

本文简单介绍的是第一部分，即如何用Python实现发送HTTP请求。以后可能会讲到unittest的用法，但建议先自行了解与使用。

Chrome调试工具

打开Chrome浏览器，按F12就可以打开开发人员调试工具（后面简称DT）。

借着公司代码库迁移到私有Gitlab的契机，我接下持续集成的工作，实现了对Python服务端代码的单元测试、静态代码分析和接口测试的持续集成。总体架构如下：

执行过程：

1. 开发提交代码后，自动触发gitlab-runner拉取executor镜像执行单元测试，单元测试代码中包含上传测试结果到x-utest测试平台；

2. 单元测试通过后，gitlab-runner拉取sonar-scanner镜像执行静态代码分析，分析结果评论在commit中或保存于sonarqube；

本文是目前最完整的locustfile编写指南中文版！
关注微信公众号: devintest 加入微信群，共同学习进步

locustfile就是一份Python代码文件. locustfile的唯一要求是至少要包含一个Locust类（或其派生类）, 例如测试HTTP请求时, 至少要包含一个HttpLocust类.

Locust 类

一个Locust类代表一类模拟用户。

一个Locust类 必须 定义一个 task_set 属性，用于指向一个TaskSet类。TaskSet类定义了一系列用户行为，具体内容在后面会介绍到。

另外还有一对常用属性就是 min_wait/max_wait，分别定义虚拟用户执行两个task之间的最小/最大等待时间，默认值1000，所以不声明这两个属性时，每个task之间默认会有1秒等待时间。

kill vs stop

两个命令都是停止docker，不同之处在于：

• docker stop: 先发SIGTERM信号给docker，允许其在一定时间（默认10s）内进行一些操作（例如资源回收），若这段时间内容器未停止，则发送SIGKILL信号强行杀死容器；
• docker kill: 直接发送SIGKILL信号杀死容器。

SIGTERM与SIGKILL的区别在于，前者是告知你的租期到了，请你赶紧收拾行李离开；后者是你的租期到了，直接将你扫地出门。

简而言之，相比kill，stop给了容器自行处理结束的时间，更为优雅。

run vs start

• docker run: 从镜像启动一个容器;
• docker start: 运行已停止的容器。