光の技术屋

前言

rpc（远程过程调用），是不同主机间的交互的机制之一。好比说，我们想要获取服务器的某个资源，我们就可以发送一条讯息给服务器，然后服务器解析信息，再返回推送资源的信息，这样，便实现了我们客户端跟服务器的相互的“远程调用”。

为了让不同主机之间能够相互理解发送的讯息，我们需要约定统一的信息格式标准，使得不同的主机可以发送基于这个信息格式的讯息，也可以解析这个格式。这种标准，我们称之为协议（protocol）。

Lua中协议选择有许多种，protobuf、json均可。但是今天，就稍微介绍一下云风同志当年为lua量身设计的sproto协议以及其用于协议测试的二次开发。So, let the party begin~

sproto协议描述

sproto是专用于lua的协议框架，相对于protobuf跟json，sproto在数据的序列化/反序列化效率上有极大的优势。rpc中为了快速效率地传送协议数据，会将数据组装压缩发送，接收端再解压拆解数据识别消息，从而减小了网络传输的开销。这个数据处理过程便可称之为序列化/反序列化。

sproto的设计类似于protobuf，基本类型为string、binary、integer以及boolean四种。对于array序列的支持，则加上引用星号*即可；对于非整数的支持方面，用户可以parse string来处理实数，或者指定integer的小数位数来处理小数（decimal）。除此之外，用户也可以像编程里面strcut那样自定义类型，类型与类型之间也可以嵌套。

我们可以从readme中寻找各种例子。数据类型的例子如下：

前言

Github传送门

最近回忆起了在学校那会儿趣事：刚开始上数据库原理课程，一开始装Microsoft SQL Server，全班同学都在吐槽，怨声载道——这个说数据库咋启动不了，那个说数据库咋卸载不干净，个个焦头烂额，实在是好一番风景。唉，那时候就在想，要是有一个类似于软件管家的东西托管Microsoft SQL Server，让我们一键安装/卸载，可不就好了。

进入工业界，接触了运维方面的知识，才了解到docker的存在。不同于当年常用的虚拟机软件（VMWare WorkStation），docker并未对操作系统的硬件支撑做虚拟化，只是操作系统的进程，但却模拟了一个操作系统的环境，因此相对于虚拟机而言，docker更加轻量。轻量的运行环境意味着基于docker的部署，在管理与调度上会更加容易。看，kubernetes！

再回到我们的学习生活，拿MySQL为例吧——有了docker，安装卸载MySQL，就会变得无比容易。首先docker pull mysql；而后整理一下配置——通过-v映射数据在本地的存储路径，通过-p暴露出来mysql容器的端口，通过-e设置MySQL密码等环境变量；之后docker run带上上面的设置，我们的MySQL就启动了！要彻底卸载的话，只需要三行命令：docker stop ${MySQL容器ID}、docker rm ${MySQL容器ID}与docker image rm ${MySQL镜像ID}，就ok了，是不是EZPZ？

正好，docker是基于Golang编写。因此本期从零单排，我们就用Golang来挑战一下如何与docker交互吧~

编写Golang程序部署MySQL

首先，我们研究一下相关的技术栈：官方提供的Golang客户端库docker client为Golang与docker间搭建了桥梁，其实质是对docker engine api的抽象；而docker engine api实质则是一个HTTP后端，是对docker内部镜像与容器管理功能的抽象。

通过docker client库，我们只需关心相关的参数输入。库中的方法会自动拼装参数，发送至docker engine api，从而实现交互。docker client的一些小例子，可以参考这里。

接下来，我们必须研究一下，要部署MySQL容器，需要有哪些步骤：

前言

提到lua，就不得不提协程coroutine。coroutine是lua的一种内在机制，为lua提供了原生的异步支持。从用户层面来看，用户不需关心coroutine的内在实现，而只需要用coroutine调度function即可，因此非常方便。

对于一个function而言，coroutine可以将function的代码分片，使得一个function可以分阶段运行。在实现上，function的状态管理会与CPU的机制相似。如果把一个function当做一个任务来看待的话，在coroutine的封装下，这个任务会被分解成多个阶段的子任务。这样，我们就可以把多个任务的子任务相互协调调度，实现更加灵活的功能交互。

因此，本期Lua杂谈，就来小试一抔coroutine的使用吧。

coroutine的基本用法

官方5.3.5版本的coroutine库，提供了如下的接口：

1
2
3
4
5
6
7
8
9
10
11

// lcorolib.c
static const luaL_Reg co_funcs[] = {
  {"create", luaB_cocreate},
  {"resume", luaB_coresume},
  {"running", luaB_corunning},
  {"status", luaB_costatus},
  {"wrap", luaB_cowrap},
  {"yield", luaB_yield},
  {"isyieldable", luaB_yieldable},
  {NULL, NULL}
};

用户可以通过coroutine.wrap与coroutine.create两种方式封装一个function（任务）。通过wrap封装任务会返回一个纯粹的lua函数（type为function），而用create封装则返回的是一个封装好的线程。

在Lua中，线程thread与协程coroutine的概念内涵有较多相似之处，但我们可以认为，线程是更加宏观广泛的概念，协程则是一种特殊的线程。线程强调的不同的routine之间运行是否独立；而协程强调的则是不同routine之间具有相互co的协作功能。

基于这两种方式调度任务的代码写法大同小异。以下以create封装任务为例，我们一起看看会是怎样的进行——

我们的日常生活离不开手机，有些同学喜欢用国产的安卓机，而另一些同学喜欢用简约的iPhone。

对比安卓和iOS的软件生态，我们可以发现：安卓软件的投放渠道繁多，题材花样繁复，质量大小不一，而iOS的投放渠道则为App Store独家，相对安卓软件来讲，不仅质量均衡，而且用户不必担心手机病毒的困扰。这一点，就归功于App Store严格的审核制度。

前言

随着MTSC2019的召开，八月份各种测试工具相继开源，其中一款名为SoloPi的安卓自动化测试在月trending榜中排位靠前。移动App自动化测试是当前测试领域的风口之一，并且要开发一款兼容性好、需求适应多样的App，也并非三日之寒。为此，欢迎本期GitHub探索的主角——SoloPi！

测试环境为华为P20Pro，安卓版本8.1.0，SoloPi版本为0.9.1，下载地址可进入GitHub Release查看。由于只有一个测试机，所以本次仅测试SoloPi的性能测试以及录制回放功能。下面，让我们开始试水吧~

前言

Github传送门

学一门新语言，如果太专注于语法，那肯定学的不够快。如果有一定的需求目标，带着这个目标去学习一门新语言，这样才能学得快。

工作中写后端的时间比例不在少数，而且传闻Go也因其适用于服务端而著名。在Go社区中最为火热的服务端框架跟数据库抽象ORM层当属gin跟gorm了，因此本期单排的目标便是用gin+gorm打一个简易的框架，实现基本CRUD的目标。走你~

准备工作

在第一话中已经大致了解了Go项目的生成，故本次gin+gorm的搭建也以此为基础。

服务端领域的各种术语在不同的场景跟技术栈下有不同的含义。但总体来讲，一个简单的服务端App都会有以下的层次：

• 校验层：预处理请求，校验请求是否合法（大小、字段、cors、oauth之类），并判断是否拦截。通常也被称作中间层middleware
• 控制层：处理合法请求的起点——收集整理相应服务模块的结果，判断请求是否合理，决定返回的数据，遵循宽进严出原则。一般叫做Controller，gin里面叫做handler。
• 业务层：处理真实的业务逻辑，通过和数据层以及各个业务模块的交互从而校验并构建业务数据，交由控制层决策，一般可称之为service
• 数据层：抽象持久化数据（数据库）到代码层面并提供一系列交互访问的方法，ORM与DAO层都算在内

基于以上结构，大致构建了以下的目录结构：

近几天一直在思考什么是用户思维，决定结合这一年的工作，把自己的想法记录下来。

在这之前，自己一直秉持一种观念——测试开发从工作内容上，更加符合“开（码）发（农）”的定义，因此应当更加着重于技术深耕，并且在业务对接时，也尽可能地从从技术实现的角度去阐述观点与想法。但是在经过同事伙伴们的提点，以及和家中领导激烈讨（吵）论（架）了一番之后，这个观念就慢慢地改变了。

测试，不仅仅是根据需求，利用各种工具，对开发交付的产品进行功能、性能、安全等测试，发现bug而后提交复现/解决方案，从而确保产品稳定（QC）。而另一些方面在于——如何确保研发计划完备进行，预防产品设计缺陷，从而保证产品体验；如何优化产品生命周期流程，从而使产品顺利上线运营（QA）。作为偏中台的测试开发，扮演的角色更像是“优化产品生命周期”的实现者，而前线上的QA与QC，则成为了我们的用户。因此在业务对接时，首先都需要尽可能满足前线同学的需求，让他们引领效率工具/平台的设计。

前言

Github传送门

当测试开发真不容易，入行第一年，就要在python、NodeJS、lua、C、Java等语言间无缝切换。为了快速响应需求，挺难抽出时间去深耕一门语言的特性（诶羡慕那些只搞Java的人= =）。在MTSC2019分享中也谈到，测试开发归属质量保障QA，作为一个中台角色，其终极任务保障研发效能，因此一大需求是打通产品研发运维的生产线。说到生产线就想到上云，说到上云就想到docker跟kube，说到跟容器的交互就想到了Golang。马蛋，又要学一门新语言了。

开这个坑，旨在展现以程序员的视角学习一门新语言的过程。希望大家看得欢乐。如果有启发，那就更棒啦！

安装与环境变量配置

家里的电脑是Windows，从官网即可下载Win的安装包。Go的版本为1.12。

下好后安装，安装完毕之后还需要设置环境变量（我的电脑——属性——高级系统设置）。GOROOT设置成Go的安装路径，还有一个关键的GOPATH，它表示你的工作目录，一般所有的Go项目，甭管第三方的还是你的，都统一放到这个目录下（从这点可以看出，Go的控制欲还是很强的）。GOPATH的一般结构如下：

安卓的fps测试，是我打开测试开发大门的一把钥匙。两年前的现在，安卓性能测试的相关资料甚少，以fps为例在网上也只有寥寥几篇文章讲述，但到了今年，已经有许多资料在各大技术论坛上供大家看到了。对于自己，一直想找一个机会把这一段技术探索写出来。所以，心动不如行动。

fps（frames per second），通常表示我们屏幕每秒展现的图片（帧）数，反映了一款应用在当前硬件下的性能消耗。比如我们抽CS的时候，就经常关注fps是否高，在高的情况下，就会有较好的流畅度。因此fps是应用性能测试中一个重要指标。

对于一个安卓app而言，为了测定fps数值，我们需要从安卓图形显示相关的模块入手。一个通用的方式是切入安卓的SurfaceFlinger服务，它是图形显示流程中软件层和硬件层的交互点，是极其关键的一环。SurfaceFlinger则是负责分析&合成各个app中的图层，而后将合成的图像数据交由硬件渲染。硬件渲染的机制复杂，因此安卓系统中，将硬件操作进行了抽象方便调用，我们将这一与SurfaceFlinger对接的层次，称之为硬件抽象层（HAL）。SurfaceFlinger与HAL在功能上有部分的耦合，一些Surface合成的工作，也会委托HAL进行。

那么我们该如何通过SurfaceFlinger获得fps数据呢？大体上，我们可以参考《Android性能测试之fps获取》一文。这种方式成功率高（虽然我家手机行不通），且不用root，较为方便

首先，通过adb，我们可以导出SurfaceFlinger服务的运行时信息。

“测试人生”第一篇文章，献给2019年的移动测试开发大会MTSC。这一次，非常荣幸能够来到北京国际会议中心参会，一睹国内质量保障工作的现状与未来的发展趋势。

在学校期间，我也参与过一些小型的学术会议，但并不如今年的MTSC这样声势浩大。工作一年以来参与的第一个讨论会，已然是全国顶会。借这个机会，能够了解到业内排头企业在质量保障业务上的解决方案，对于自己在业务理解上会颇有帮助。本次议程中，除了参与第一天主会场之外，第二天游戏测试专场也全程参与，收获颇丰，感悟良多，一言难尽。