随着项目逐步迭代，自动化覆盖率提升，自动化测试的脚本会变得越来越复杂，我们需要在脚本中引入版本控制。

这里我举几个遇到过的例子：

• 某项目需要同时测试多个app，并且最终的数据要汇总到一起。因为不同的app（的测试代码）由不同的人员去维护，经常会导致负责公共模块的同学更新后，某些app没有及时更新，最终执行时需要人为去调查和解决冲突问题。
• 有这样一家公司，为了整合测试资源，在内部搭建了一个云测试平台，把部署在全国各地多个节点统一进行调度。但是由于平台不够稳定，经常是在平台测试不通过，但是相关同学在本地跑一样的代码却完全没有问题。经过一番调查，发现某个节点磁盘满了导致脚本没有更新。
• 小A是某公司的测试开发，在内部作为多个项目公共资源，主要负责各项目核心自动化脚本的编写。因为各个项目的发布频率不同，有的项目设置需要两个月才需要维护一次。每次到这个项目上时，小A都要花很久时间回忆之前有什么改动，本次需要做什么。公司也面临着人员离职或者磁盘损坏导致代码丢失的风险。

所以，为了解决这些复杂的问题，我们尝试在测试代码上也引入版本控制，并且参考了《语义化版本控制规范》，为每一次交付的产物都制定一个版本。

关于版本控制的工具，首先推荐 git（与svn的优劣对比，不是本文重点，这里不展开）。要明确一点的是，git 不等于 github，即使不涉及多人协作，不借助各种托管平台，也可以作为本地仓库使用。

这里存在一个小小的问题，实际应用中怎么打包、确定版本号、有了版本号怎么快速找到对应代码，下文就逐步剖析我目前采用的方案和流程。

ps：下文主要以 python 为例。

今天在实践pytest过程中，有这么一条需求：

用例描述写在test_xxx函数的docstring（文档字符串）中，如何在代码中获取该字符串？

开始想到的笨办法，是通过 request 这个 fixture，拿到执行的case所在文件、行数等，去解析文件读取。

翻了半天 pytest 文档中没有找到有用的信息，最后经过调试发现可以通过以下代码实现：

1

request._pyfuncitem._obj.__doc__

下一篇，分享向 xml 中添加字段、属性。

Homebrew 是一款自由及开放源代码的软件包管理系统，用以简化macOS系统上的软件安装过程。
其核心是一个托管在 GitHub上 的 git 版本库，由于某些原因，国内访问速度不快，并且稳定性堪忧。

为了提高体验，我们可以用腾讯软件源对其进行加速，打开“终端”，依次执行以下命令即可：

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

# 替换 Homebrew 的 formula 索引的镜像（即 brew update 时所更新内容）
git -C "$(brew --repo)" remote set-url origin https://mirrors.cloud.tencent.com/homebrew/brew.git
git -C "$(brew --repo homebrew/core)" remote set-url origin https://mirrors.cloud.tencent.com/homebrew/homebrew-core.git

# 替换 Homebrew 二进制预编译包的镜像
echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.cloud.tencent.com/homebrew-bottles' >> ~/.bash_profile
source ~/.bash_profile

#（可选）禁用“自动更新” —— 执行`brew install xxx`时会自动执行`brew update`，导致安装过程比较慢。
# 通过此方法禁用后，选择合适时机手动执行`brew update`
echo 'export HOMEBREW_NO_AUTO_UPDATE=1' >> ~/.bash_profile
source ~/.bash_profile

# 更新
brew update
```  

复原：
```bash
git -C "$(brew --repo)" remote set-url origin https://github.com/Homebrew/brew.git

git -C "$(brew --repo homebrew/core)" remote set-url origin https://github.com/Homebrew/homebrew-core

brew update

# Homebrew-bottles: 需要去`~/.bash_profile`中删除'HOMEBREW_BOTTLE_DOMAIN'

本博客目前是使用 hexo + Next 主题搭建在 GitHub Pages 上的，使用 git 管理，并接入了 Travis-CI 自动发布。一直以来，对于图片的处理是我的一块心病。虽然hexo官方提出了资源文件夹的概念，但是{% asset_img example.jpg This is an example image %}这种方式几乎不被任何 Markdown 编辑器支持。

个人习惯是使用 Typora 码字，然后再用 vscode 的 markdownlint 扩展进行语法检查（代码格式上的洁癖）—— vscode 用得顺手，甚至可以放弃 Typora。

为了不滥用GitHub仓库、节省空间和提高访问速度，可以使用腾讯云的对象存储（COS） + 内容分发网络（CDN）。良心云每个月都赠送了一定的免费额度，对于个人博客来讲一般是够用的。

最近CDN也不能满足我的胃口了，在尝试极限优化的路上，我又发现了一个更有想象力的方案，那就是借助腾讯云的数据万象（原万象优图）服务，对图片进行预处理或者实时处理，从而减小图片体积、提高打开速度。

对于数据万象我在之前的一篇文章薅羊毛党的胜利 —— 合理利用腾讯云搭建服务 提到过。

市面上有什么好用的从服务器推报警和日志到手机的工具？之前私下用的是[Server酱]的服务，非常方便。
但是考虑到安全原因，这个服务如果用在生产环境心里还是有点慌（虽然我相信[Server酱]是很有节操的）。

另外，出于想把工作和生活分开的私心（并不能），所以一直在探索使用企业微信来实现通知的方案（自建应用的话还要考虑通知的到达率，实在有心无力）。

之前已经基于企业微信的自建应用API，开发和部署了一个服务，技术方案是 docker + django + mysql + celery + redis。开发时要达到高可用，涉及 access_token 的刷新，还要考虑任务队列、分布式锁等等，真是折腾。

今天（2019-6-28）在更新企业微信时，发现增加了个群机器人的功能，赶紧查了一下文档发现挺符合需求的。群机器人的优点是，通知基于群组，有问题时直接可以在群内沟通，也不会存在重新拉群还需要介绍背景，人员发生变动时拉新人进群即可。

监控报警的脚本可以放在自己的服务器上，但是一旦遇到光纤被挖断了、停电这种外部因素，就需要一些外部手段来监控了。这里我推荐一下腾讯云无服务器云函数（Serverless Cloud Function，SCF），免费，如果用腾讯云的其它服务还有各种加成，现在还有【活动链接】（写个简单的demo就行）送腾讯云的通用代金券、公仔等。

这里我就写个简单的天气小助手，来演示一下整个流程。

浅析 ADB 原理和优化

最近研究小程序自动化的时候，拜读了几篇关于小程序原理的文章，其中提到了一个词”管控”。作为平台方，必须保证提供的服务是可控的（细节与主题无关，这里不再展开）。受此启发，对于我们的平台来说，如果希望对外提供自动化能力，就必须对执行环境做一定的保护。如果具体到 android 平台，那首先要研究的就是 ADB（Android Debug Bridge）。

具体要管控什么？举个例子，执行adb kill-server 会使 adb server 退出——因为是 adb server 提供的接口，所以不涉及权限问题（即使 adb server 是通过 root 权限启动，普通用户通过 adb client 调用此接口，adb server 也会退出。）。

Uiautomator2 源码分析

引言

关于著名的软件测试金字塔理论，可以看一下 The Practical Test Pyramid 这篇文章，译文在这里。

对于UI自动化测试，根据其实现原理可以大致分为：基于坐标的（monkeyrunner）、基于控件的（uiautomator）、基于图像识别的（sikuli）等。针对不同的测试场景，不同方案各有其用武之地。

Android Uiautomator2 Python Wrapper 是基于 Google uiautomator2 库实现的自动化测试框架。该框架主要解决了两大痛点：

1. 测试脚本只能使用Java语言
2. 测试脚本必须每次被上传到设备上运行

其实现原理就是在手机上运行了一个 http 服务器，将 uiautomator 中的功能开放出来，然后再将这些 http 接口，封装成 Python 库。

几种常见的身份认证方案和接口测试中的应用

最近做了几个项目的接口测试接入工作，主要是结合星海（内部的统一接口测试平台）完成各个项目基础框架的搭建，并结合项目实际情况混合普通（通过网页编辑）和高级模式（直接编写代码），来提升接口测试的整体效率。

身份认证

几乎所有项目遇到的首个问题就是身份认证。因为大部分接口都不允许、也不应该匿名使用，所以一般都会通过HTTP Header或URL中的Query String携带一个令牌（token），来表明用户身份。

一般来讲，token 如果根据有效期来分类的话，有永久有效（当然可以后台手动吊销）和一定时间内有效两类。根据权限又可以分为完全权限和指定作用阈。根据项目实际情况，可能还有更多的划分。

一个典型的认证流程：

1. 用户向服务器发送用户名和密码。
2. 服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3. 服务器向用户返回一个 session_id，写入用户的 Cookie。
4. 用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
5. 服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。

所以，后来又有了 JWT(JSON Web Token) 方案。详细的原理和用法这里就不展开了，可以读一下阮一峰的《JSON Web Token 入门教程》，或 Auth0 出品的《JWT Handbook》。

另外，前面提到的典型认证流程，第一步是通过用户名和密码认证。但是对于第三方服务（例如饿了么之于微信），还会用到 OAuth2.0的标准。简单描述就是，用户点击“同意”授权，由微信和饿了么在后台完成鉴权，最后颁发一个短期有效的令牌。具体的原理也可以通过阮一峰的《理解OAuth 2.0》了解。

身份认证与接口测试

一种评估接口测试用例编写效率的办法

2018最新 Hexo + GitHub Pages + Travis CI 自动化部署静态博客最佳实践。