2024年4月8日

十多年了，接口自动化测试越来越鸡肋？

引言

从《Google软件测试之道》到后来的敏捷开发、DevOps，10多年了，接口自动化测试一直是测试领域必谈的重点。各种自动化测试工具（Postman类）、自动化测试框架、自动化测试平台层出不穷，每个公司/部门甚至每个团队都有一套直接的自动化解决方案。但盲目投入后，反而会感觉越来越鸡肋，食之无用弃之可惜。

接口自动化的价值

不管你是 B/S 还是 C/S 架构，APP 还是小程序，还是什么协议，总体来说是由 GUI 和服务端 API 组成。通常一个迭代是 PM 需求、RD 开发/联调、QA 单功能测试、bugfix(穿插多轮)、合码 QA 集成/回归测试、发版。在这一套模式下，大家常说的接口自动化测试（暂不考虑 UI 自动化）的价值如下：

提高测试效率/降低人力成本？

因为自动化测试执行很快，所以引入接口自动化测试能提高测试效率。但有个很现实的问题，接口自动化只覆盖了服务端 API，GUI 这部分也有很多逻辑，RD 也是有大量工作量投入的，这部分的测试是少不了的。即使是偏服务端 API 的功能，你的手工 GUI 测试替代率是多少？接口自动化执行完了能不需要手工测试吗？这恐怕不敢打包票吧。所以对于一个端到端的测试团队，反而接口自动化 case 的编写和维护成了额外的负担。

降低人力成本也是无稽之谈，因为你手工 GUI 测试的成本并没有降下来，反而需要投入写接口自动化的人力。除非你之前就有一批人是使用 Curl 测接口的。

提高测试覆盖率？

这个理论上有道理，一些接口参数分支，UI 上无法走到，通过接口则可以直接覆盖到，提升了覆盖率，后面 UI 上增加了此分支能保证基本的质量，提升迭代效率。但事实上产品变化很快，还没等覆盖到新参数分支，需求又变了，接口甚至都得重写一遍。掉入了过早优化的陷阱。

持续集成和持续交付（CICD）✓

互联网大部分开发模式都是迭代开发、小步快跑。接口开发完成后还没到测试环节，这时候跑一遍自动化（回归测试），能保证基础功能没影响，代码就可以合入了，过几天就自动进入到测试环节。也能尽早发现问题，缩短交付周期。

同时还可以用作线上监控，保障服务稳定性。这是手工测试无法做到的。

保证结果的一致性和准确性✓

手工用例总是需要人理解然后执行，因为各种原因，不同的人可能对同一条 case 理解不一样，造成执行偏差。然后人总有惰性，偶尔还是会有因觉得执行过程偷懒而导致的漏测。而接口自动化执行的结果是可靠的。

总的来说，如果你是想只通过接口自动化这一种方式降本提效，那可能会事与愿违。而是应该把提质作为目的，即接口自动化作为质量保障的重要手段，尽早的写（左移），穿插到整个研发生命周期里面去，才能发挥更大的作用（特别是现在 DevOps 时代）。对此合适的度量指标：线上问题召回率、自动化 Bug 发现比率（含 CICD 过程中发现的）。

接口自动化的成本

在评估自动化收益的时候我们常用这样一个公式：自动化收益 = 迭代次数 x（手工执行成本 - 用例维护成本）- 用例编写成本。现在来看可能不太合适，如上所述，接口自动化和手工测试并不对等，并不是替代人工。不过自动化测试的成本倒是可以通过类似的公式计算：运行次数 x 用例维护成本 + 用例编写成本。这可能和大家想象的不一样，接口自动化通常被认为是边际成本很低，即用例编写成本会随着运行次数增加而摊薄。但事实上维护成本也不低，而且无法摊薄，因为不运行就不需要维护，只要运行就会出问题，就需要排查、维护。

维护成本的来源可能是多方面的，虽然都有一定的解决办法，但不能忽视这部分的成本，而且分散在日常中还是隐性成本（leader 看不见），如果做的不好，甚至会出现团队都很累，但质量又很差的情况。

维护成本来源	解决方案
接口参数不兼容改动，需要相关case都改动	接口适当封装，case使用封装后的模板或函数，方便使用和维护
前置变量失效导致case失败，比如商品id 或者说一个新环境的适配成本	一方面case里面不能写死id，需要变量化，数据和逻辑分离另一方面，case需要自给自足，相关依赖资源在前置操作中产生，并在后置操作中销毁
case间的量子纠缠	适当的执行用户隔离，一些资源操作加锁

很多测试框架/平台把重点放在写 case 这块，宣称功能更强大（比如流量录制导入）、体验更好。但拉长 case 周期来看，编写成本是一次性的，10分钟写完一条 case 和1小时写完一条差别不大。更多的应该放在如何写好 case（场景构造、数据准备等）、维护好 case，这才能降低最终的成本。（放心没广告）

总结

还是那句话：软件工程没有银弹。鸡肋不鸡肋要看目的，降本增效可能不是直接的收益。同时也要注意接口自动化维护成本也不小，需要重点投入解决这块的问题，才能使最终的 ROI 高。

当然，本文看着还是泛泛而谈，并没有说接口自动化该如何写，但我认为具体怎么写都是招式问题，先修一下内功心法总纲更重要。

参考资料

迷雾中的自动化测试体系建设，https://cloud.tencent.com/developer/article/1927415

知识分享｜自动化测试首选接口自动化？https://v2ex.com/t/1020718

关于产品质量的思考 - 如何评估质量，https://mp.weixin.qq.com/s/PEeKEJ1FBwvVUOeEJkixQw

接口自动化不是救命稻草，https://testerhome.com/topics/38202

Apifox：API 接口自动化测试完全指南，https://apifox.com/blog/api-testing-guide/

Lego-美团接口自动化测试实践，https://tech.meituan.com/2018/01/09/lego-api-test.html

关于产品质量的思考 - 如何评估质量，https://mp.weixin.qq.com/s/PEeKEJ1FBwvVUOeEJkixQw

【QA&QE校招培训】浅谈自动化测试，https://bytetech.info/videos/6857809063481507847

2024年4月6日

Go“冷门”库之ohler55/ojg，兼容性更好持续维护的JSONPath库

现在用 Go 写业务的越来越多了，虽然没有干倒 JAVA，但抢占了很多 PHP、Node、Python Web 的份额。不过由于 Go 相对来说时间较短，在生态上差一点，有些场景一下找不到现成的库。因此我打算出个Go“冷门”库系列，介绍一些项目中实际验证过的、但鲜为人知的库。期望更多人了解到这些库，使用后多给开源社区反馈。

在 JAVA 时代，XmlPath 特别流行，对应的就有 JSONPath，方便直接获取 JSON 中的值。在 Go 里有个特别出名的库 gjson 就是这个用处，但它没有按 JSONPath 规范实现，单独用没有问题，但要和别的模块（非Go）交互时就得使用大家都有的。json-path-comparison 上倒是有几款 Go 的库，但很多都年久失修，就剩 ohler55/ojg 和 spyzhov/ajson 还在维护，当时选择了 ohler55/ojg，因为作者一直在做JSON相关的库，有成熟的 Ruby、C 的实现，看着经验非常丰富。

ojg 这个库，不仅仅只有 JSONPath 的功能还包含常规 JSON 库的 Marshal/Unmarshal，但这个赛道太卷了，后面有机会再介绍。这里主要介绍其 JSONPath 功能。使用上也很简单：

obj, err := oj.ParseString(`{

"a":[

{"x":1,"y":2,"z":3},

{"x":2,"y":4,"z":6}

]

}`)

x, err := jp.ParseString("a[?(@.x > 1)].y")

results := x.Get(obj)

// returns [4]

oj.ParseString 是将 JSON 字符串解析为 Go 内置结构，等价于 Unmarshal 为 any（你用其它库进行这一步也是可以的）。但和一般 JSON 库默认的行为不一样，会判断类型，特别是 int64（其它库默认是float64），转换为对应的数据类型：

bool

int64

float64

string

time.Time

[]any

map[string]any

jp.ParseString 则是生成提取规则（可以重复使用），应用于前面解析的 any 上，进行提取。用法可以说是非常简单。

特别的，按 JSONPath 设计，返回的结果是个数组，即使明确提取出来的是一个值，就像上面的例子，直觉的结果应该是4，不过所有库都这样。但如果就想返回4呢？不能直接取[0]，因为JSONPath是支持切片操作的，list[0:1]仍然需要返回一个list。那如何判断了，好在 jp.ParseString 的规则有类型，可以判断最后一步操作是不是切片等。

if len(results) == 1 && !isGetSlice(x) {

return results[0]

}

func isGetSlice(expr jp.Expr) bool {

if len(expr) > 0 {

switch expr[len(expr)-1].(type) {

case jp.Slice, jp.Union:

return true

default:

return false

}

return false

}

另外，因为 JSONPath 设计比较粗糙或者说很多细节不清晰，所有很多库可能会不一致，比如我提的这个 issue，JSON key 中有 - 就必须用[]方式(["foo-bar"])提取了，不能用 .foo-bar。

func Test_parse(t *testing.T) {

//jsonStr := `{"foo-bar": "test"}`

_, err := jp.ParseString(`["foo-bar"]`)

if err != nil {

t.Error(err)

}

所以相对 JSONPath 我更推荐 jmespath，它除了功能更强大，另外一个优点就是规范定义比较清晰，各个语言的库都是官方主导实现，这样更方便跨语言交互。不过 Go 的实现推荐使用 jmespath-community/go-jmespath 版本，还在持续维护。

2024年4月5日

Python RSA公钥解密 RSA_public_decrypt

我们一般使用 RSA 的时候，都是公钥加密，私钥解密。

因为从设计上来说公钥大家都有，私钥只有一方有，这样更安全，但实际来说也可以私钥加密，公钥解密。openssl有对应实现，但Python没有，项目中需要用到，所以还得尝试实现下。

Python的rsa库虽然没有提供公钥解密但提供了公钥verification方法，里面有使用公钥解密signature的代码，可以依样画葫芦。

keylength = common.byte_size(pub_key.n)

encrypted = transform.bytes2int(signature)

decrypted = core.decrypt_int(encrypted, pub_key.e, pub_key.n)

clearsig = transform.int2bytes(decrypted, keylength)

def decrypt_int(cyphertext: int, dkey: int, n: int) -> int:

"""Decrypts a cypher text using the decryption key 'dkey', working modulo n"""

assert_int(cyphertext, "cyphertext")

assert_int(dkey, "dkey")

assert_int(n, "n")

message = pow(cyphertext, dkey, n)

return message

同时也支持了长文本解密（分段）。

import Crypto.PublicKey.RSA

from rsa import transform, core, common, PublicKey

def rsa_public_decrypt(cls, pub_key: bytes, data: bytes) -> bytes:

pub_key = Crypto.PublicKey.RSA.import_key(pub_key)

block_size = common.byte_size(pub_key.n)

def decrypt(data):

# 解密

cypher_text = transform.bytes2int(data)

decrypted = core.decrypt_int(cypher_text, pub_key.e, pub_key.n)

clear_text = transform.int2bytes(decrypted, block_size)

try:

# Find the 00 separator between the padding and the message

sep_idx = clear_text.index(b'\x00', 2)

except ValueError:

raise RuntimeError('rsa_public_decrypt failed, clear_text=%s' % clear_text)

clear_text = clear_text[sep_idx + 1:]

return clear_text

# 分段解密

total_length = len(data)

default_length = 128

res = []

offset = 0

while offset < total_length:

res.append(decrypt(data[offset:offset + default_length]))

offset += default_length

return b''.join(res)

不过在实际使用过程中，发现rsa_public_decrypt特别慢，起初认为是rsa算法的问题，因为rsa设计上也不是用来加解密较长的文本。一番定位发现是PublicKey.load_pkcs1比较慢，在我Mac上需要3061000 ns，当然一般来说不需要每次都导入公钥，但我实际场景有点特殊，每次公钥都不一样，这个导入操作需要再优化下。

一番定位发现是底层返回public key对象时有个consistency_check参数写死了True，表示会校验n和e是否互为质数，但n和key的位数有关，一般特别大，一般求GCD（最大公约数）使用辗转相除法，即非常耗CPU，这也是Python的弱势，所以比较慢。

但我的场景可以确定rsa key是合法的，因此可以不校验。在我本地测试仅需290000 ns，提高了一个数量级。

def _import_pkcs1_public(cls, pub_key: bytes):

der = DerSequence().decode(pub_key, nr_elements=2, only_ints_expected=True)

return RSA.construct(der, consistency_check=False)

后记：

这个问题是早些年解决的，那时候还没有ChatGPT，不断搜资料，也搞了好久。不过这个问题ChatGPT现在还是不能直接给出答案，会使用rsa.decrypt(encrypted_message, public_key)，但相关库并不支持这样。如果你了解 RSA 原理的话，稍加引导，它最终还是能给出一个非常接近的答案，调一调其实就能用了，不得不感叹科技的进步。

2021年8月30日

N天学会Go语言

之前一直有了解 Go 语言，但没系统的学习，最近~~兴趣盎然~~生计所迫，得学一学了。整体来说 Go 语法很简洁，有其它语言基础的话学起来很快的。本文记录了一些学习笔记，加深理解。

基础语法

学语言，最重要的就是官方教程（https://go.dev/tour/list），建议不要一开始就跟着杂七杂八的教程学习。

变量

我们都知道 Go 语言是强类型的语言，所以定义变量的时候需要定义其类型，但像 C、Java，都是把类型放在前面：

// C

int i = 1;

// Java

int i = 1;

// Go

var i int = 1

咋一看有些别扭，但这有讲究的，比如符合英语系自然语言习惯，还有写起来就很方便，更突出变量名而不是类型（而且类型可以省略），官方博客有更多的介绍：Go's Declaration Syntax。还有，Go 和 Python一样，不需要写分号。

也还有简写的方式，因为定义变量的时候其实类型是确定的，编译器很容易推导，可以不用写类型。

var i int = 1

// 去掉类型

var i = 1

// 进一步简写

i := 1

看到var i = 1是不是有 JS 和 Java lombok/JDK10 的感觉，这样就很亲切了。

Methods are functions

一个函数定义：func add(x int, y int) int {}，参数类型，返回值类型一目了然，这里可以看出还是类型后置，这点其实后面 Python 3.5 加入类型提示（限制）也是这样：def add(x: int, y: int) -> int:。这里顺带提一下，Python、PHP 这些无类型声明的语言并不是真的无类型（动态类型，运行时检查），而且新版都增加了类型检查的语法，解决了重构等痛点问题。

方法和函数其实一样，只是接收方参数不一样。

type Vertex struct {

X, Y float64

}

// 方法

func (v Vertex) Abs() float64 {

return math.Sqrt(v.X*v.X + v.Y*v.Y)

}

func main() {

v := Vertex{3, 4}

fmt.Println(v.Abs())

}

// 函数

func Abs(v Vertex) float64 {

return math.Sqrt(v.X*v.X + v.Y*v.Y)

}

func main() {

v := Vertex{3, 4}

fmt.Println(Abs(v))

}

不过 Go 的函数没有 Python 的那么强大，没有默认参数、关键字参数等，虽然说 Go 讲究简洁，但这些语法糖还是很有用的，典型场景就是 Python requests 库：https://docs.python-requests.org/en/latest/api/#requests.request。

Defer

延迟调用，这个比较特殊，defer定义的操作会在方法 return 后执行，但比如传的参数就是定义时那样，官方例子修改下：

package main

import "fmt"

func main() {

var i = 0

defer fmt.Println(i)

i = 1

fmt.Println("hello")

}

输出

hello

这个有什么作用呢，其实类似 Java 中 try/catch 中的 finally，可以用于资源的清理（经典应用就是释放锁）。官方博客有介绍：Defer, Panic, and Recover。

Pointers

Go 的指针语法上来看，比 C 简单些，没有特殊的指针变量，&就是取地址，*就是取值（或者定义指针类型），也没有指针运算（其实也可以）。说到指针，又会牵扯到一个话题，传值还是传引用，简单来说 Go 传的是值，但并不代表改动不影响原数据，因为 map、slice等，可以理解本身数据结构就是指针，这些类型修改会影响原有数据，表现和其它语言一致。还有一个就是性能问题，本能的觉得传引用（指针）性能更高（其实还会带来 GC 等问题），比如字符串。

package main

import "fmt"

func main() {

s1 := "abc"

s2 := "abc"

s3 := s1

s4 := &s1

fmt.Println(s1, s2, s3, *s4)

fmt.Printf("%p %p %p %p", &s1, &s2, &s3, s4)

}

输出为：

1 2	abc abc abc abc 0xc00018a050 0xc00018a060 0xc00018a070 0xc00018a050

咋一看 s2, s3 都是一个新的内存地址，这不影响性能嘛。但再看看：

package main

import "fmt"

import "unsafe"

import "reflect"

func main() {

s1 := "abc"

s2 := "abc"

s3 := s1

s4 := &s1

fmt.Println(s1, s2, s3, *s4)

fmt.Printf("%p %p %p %p\n", &s1, &s2, &s3, s4)

fmt.Printf("%p %p %p %p\n",

(*reflect.StringHeader)(unsafe.Pointer(&s1)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s2)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s3)).Data,

(*reflect.StringHeader)(unsafe.Pointer(s4)).Data

)

s1 = "abcd"

fmt.Printf("%p %p %p %p\n",

(*reflect.StringHeader)(unsafe.Pointer(&s1)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s2)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s3)).Data,

(*reflect.StringHeader)(unsafe.Pointer(s4)).Data

)

}

输出：

abc abc abc abc

0xc000010240 0xc000010250 0xc000010260 0xc000010240

%!p(uintptr=4966888) %!p(uintptr=4966888) %!p(uintptr=4966888) %!p(uintptr=4966888)

%!p(uintptr=4967058) %!p(uintptr=4966888) %!p(uintptr=4966888) %!p(uintptr=4967058)

可以看出 Go 对字符串等有两个优化：

1. 定义变量 literals（字面量）一致时（s1 和 s2），会指向同一个地址。

2. 变量传值时（s3 := s1）复制的是 string 这个数据结构。

struct String {

char *data;

int length;

};

data 指针指向的内容没有复制。因为要存储这个新的结构体，所以 &s3 是这个结构体的内存地址，而 s1，s3 结构体中 data 指向的地址是一样的。

指针这块细节可能理解不是太准确，但意思是语言层面已经做了很多优化，正常使用即可，不要过度优化到处使用指针。 Continue Reading...

2021年7月7日

Python import机制探究

最近遇到一个需求，需要动态加载一堆 Python 模块，但是这些 .py 是 pb 文件生成的，无法控制命名，导致导入的时候各种报错。

目录结构

├── main.py

└── temp_dir

├── __init__.py

├── basic

│ ├── __init__.py

│ └── package1.py

├── calendar

│ ├── __init__.py

│ └── package2.py

└── math

├── __init__.py

└── package3.py

package1.py 内容

from calendar import package2

from math import package3

print("import package1")

package2.py 内容

1	print("import package2")

package3.py 内容

1	print("import package3")

可以看见在 basic.package1 中导入了 package2、package3。我们在 main 文件中导入 basic 包。

import importlib

if __name__ == '__main__':

print(importlib.import_module("basic.package1"))

这样肯定不行，报错了：ModuleNotFoundError: No module named 'basic'

sys.path

Google 一下或者稍微了解 Python 的就会知道，Python 导入非系统库需要指定 PYTHONPATH，Python 启动时会读取此环境变量并加入到 sys.path 中。我们可以打印下：

['/mnt/c/Users/PycharmProjects/python-import-test',

'/usr/lib/python38.zip',

'/usr/lib/python3.8',

'/usr/local/lib/python3.8/dist-packages']

可以看到默认加载了当前项目目录、Python系统目录以及 dist-packages（通过 pip 安装的），我们把 temp_dir 目录加进去就行了。代码增加：

1 2	temp_dir = "%s/temp_dir" % os.path.dirname(__file__) sys.path.append(temp_dir)

但还是会报错：ImportError: cannot import name 'package2' from 'calendar' (/usr/lib/python3.8/calendar.py)，不过至少说明，加载路径是设置成功了，basic 包本身导入成功了，只是 from calendar import package2 执行失败了。

这个是一个经典错误，搞 Python 的都会遇到，那就是自己定义的包名不能和系统的重复，一般是改个名字或者加上命名空间，但是我们这个场景中，Python 文件是 pb 生成的，无法修改源文件，修改生成的文件也比较麻烦。也能解决，就是提高我们路径的优先级，改成 sys.path.insert(0, temp_dir) 加载完了再改回来。

BuiltinImporter

不过又有新的报错：ImportError: cannot import name 'package3' from 'math' (unknown location)，有输出 import package2，看着还是导入了系统的 math 库，没有导入自己的，还没有显示路径。这里匪夷所思，卡了很久，继续单步调试代码和查阅资料，发现 Python 其实是支持多种导入方式，甚至可以自定义。importlib._bootstrap._find_spec 中，是循环 sys.meta_path 中的 Importer 哪个找到算哪个。我们可以打印下 sys.meta_path：

1	[<class '_frozen_importlib.BuiltinImporter'>, <class '_frozen_importlib.FrozenImporter'>, <class '_frozen_importlib_external.PathFinder'>]

可以看见最前面有个 BuiltinImporter（具体是在 importlib._bootstrap._install 时注入的），唉，灵光一闪，math 就是一个内建库呀，这里结合源码猜测，C 的库（详见 sys.builtin_module_names）都是通过这个导入的。去掉这个就能导入成功了（记得加载完了还原回来）。

builtin = None

get_class_name = lambda _class: _class.__name__ if hasattr(_class, '__name__') else type(_class).__name__

for importer in sys.meta_path:

if get_class_name(importer) == 'BuiltinImporter':

builtin = importer

break

if builtin:

sys.meta_path.remove(builtin)

终于成功了：

import package2

import package3

import package1

sys.modules

不过，这里只是个 demo。实际情况比这个复杂，还是会报 ImportError: cannot import name 'package2' from 'calendar' (/usr/lib/python3.8/calendar.py)，这里很奇怪，已经保证了加载的优先级，但为什么还不行呢？没办法，扒一下源码，终于找到了一点端倪。importlib._bootstrap._find_and_load 方法中，会先在 sys.modules 里面找，如果有则直接返回，官方文档也有相应说明。

def _find_and_load(name, import_):

"""Find and load the module."""

with _ModuleLockManager(name):

module = sys.modules.get(name, _NEEDS_LOADING)

if module is _NEEDS_LOADING:

return _find_and_load_unlocked(name, import_)

所以还得排除已加载的情况

for exclude in ["calendar", "math"]:

if exclude in sys.modules:

del sys.modules[exclude]

最终到此才彻底解决，完整 demo 代码：https://github.com/iyaozhen/python-import-test

参考资料

https://docs.python.org/3/library/importlib.html

妙用Hook来研究Python的Import机制，https://www.51cto.com/article/527713.html

Python3.7源码剖析之import，https://zhuanlan.zhihu.com/p/361720373

2021年4月2日

工作5年，后3年都重复着前2年？写在离职百度之际（QA篇）

最近各种原因换了个工作，回想起来校招（实习）就进百度了，一晃5年多了。最近又宣传“十四五”，也想着自己确实得好好总结下这五年，而且市面上做 QA 的比较少，希望能对新同学有些帮助。

重新review下工作

做程序员这一块，可能都会遇到第一个瓶颈，工作前2两年成长很快（特别是 QA，都是现学），但后面就慢了，感觉重复着之前的工作。这里以“捕鼠器案例”为引子（杨震原字节内部分享，来源王梦秋百度的内部分享），重新捋一下 QA 的工作：

工作第1年

刚工作接到的任务一般比较简单、直接，比如导师可能叫你去放一下捕鼠器。这个时候你一般看看文档，多观察下，就知道捕鼠器是用来捕老鼠的，你只要不给它挂在墙上就行。甚至前人已经放过捕鼠器了，你只要依样画葫芦隔一段距离放一下就行了。

这个时候你就要稍微总结下了，放捕鼠器为什么有时没捕到老鼠，你可以会观察录像，看别人的捕鼠器怎么做的，这个时候稍作改进就会效果明显。具体的到QA的工作，你现在已经非常熟悉这块的业务，每次小功能的测试都游刃有余，而且通过学习你还会了 API/UI 自动化测试，效率也变高了。

工作第2年

由于表现还不错，你已经晋升为 T4 了。这个时候你会发现只放好老鼠夹子效果还是不好，具体到工作可能会发现线上还是有很多问题。你一想，捕鼠器是干啥，消灭老鼠，但消灭老鼠，不仅仅只有捕鼠器一种方法，或者说一种方法不够。

当一个人从完成任务到解决问题，能够再问一步，这个问题关联的问题是什么，进而去提出新的问题，这就是关键的突破点。

你可能会发现老鼠药更管用。类比测试工作上来说，你引入了更多的测试方法：diff 测试、性能测试、稳定性测试、兼容性测试、安全测试、ET测试等，工作开始变的顺风顺水。

工作第3-5年

这个时候你测试环节已经做的很不错了，能负责一个系统或者业务方向的测试了，一般的话也晋升为 T5（高级测试工程师）之列了。但这个时候就开始重复之前的工作了，项目不停迭代、新功能测也测不完。而且随着需求积累，回归测试也很多了，因此对于 QA 来说这种重复的感觉比 RD、FE 更强烈。

这个时候还得回到原点来，捕老鼠是为了什么？为了保护粮食。那 QA 找 Bug 是为了什么？是为了“质量”。

（图来源百度王梦秋分享 PPT）

这个时候介绍一个在百度内部非常重要的概念：全流程质量保障。作为 QA（Quality Assurance，质量保障），自己把自己定位成测试是不行的。

全流程质量保障

可能每个公司的项目流程都不一样，但都会包含以下几部分，当你跳出“测试”来看，就会发现能做的事情还有很多： Continue Reading...

2021年3月29日

Python使用logging为Flask增加logid

我们为了问题定位，常见做法是在日志中加入 logid，用于关联一个请求的上下文。这就涉及两个问题：1. logid 这个“全局”变量如何保存传递。2. 如何让打印日志的时候自动带上 logid（毕竟不能每个打日志的地方都手动传入）

logid保存与传递

传统做法就是讲 logid 保存在 threading.local 里面，一个线程里都是一样的值。在 before_app_request 就生成好，logid并放进去。

import threading

from blueprint.hooks import hooks

thread_local = threading.local()

app = Flask()

app.thread_local = thread_local

import uuid

from flask import Blueprint

from flask import current_app as app

hooks = Blueprint('hooks', __name__)

@hooks.before_app_request

def before_request():

"""

处理请求之前的钩子

:return:

"""

# 生成logid

app.thread_local.logid = uuid.uuid1().time

因为需要一个数字的 logid 所以简单使用 uuid.uuid1().time 一般并发完全够了，不会重复且趋势递增（看logid就能知道请求的早晚）。

打印日志自动带上logid

这个就是 Python 日志库自带的功能了，可以使用 Filter 来实现这个需求。

import logging

# https://docs.python.org/3/library/logging.html#logrecord-attributes

log_format = "%(asctime)s %(levelname)s [%(threadName)s-%(thread)d] %(logid)s %(filename)s:%(lineno)d %(message)s"

file_handler = logging.FileHandler(file_name)

logger = logging.getLogger()

logid_filter = ContextFilter()

file_handler.addFilter(logid_filter)

file_handler.setFormatter(logging.Formatter(log_format))

logger.addHandler(file_handler)

class ContextFilter(logging.Filter):

"""

logging Filter

"""

def filter(self, record):

"""

threading local 获取logid

:param record:

:return:

"""

log_id = thread_local.logid if hasattr(thread_local, 'logid') else '-'

record.logid = log_id

return True

log_format 中我们用了很多系统自带的占位符，但 %(logid)s 默认没有的。每条日志打印输出前都会过 Filter，利用此特征我们就可以把 record.logid 赋值上，最终打印出来的时候就有 logid 了。

虽然最终实现了，但因为是通用化方案，所以有些复杂了。其实官方教程中介绍了一种更加简单的方式：injecting-request-information，看来没事还得多看看官方文档。

2021年3月19日

iTerm2进阶使用技巧

iTerm2 的优点这里不做赘述了，第一次使用的话可以先看看官网的介绍：features、Highlights for New Users。本文主要是结合实际使用场景，介绍一些进阶使用技巧（基本的 Oh My Zsh、rzsz 等配置就不重复说明了）。

跳板机自动登录

现在很多公司登录服务器都需要先登录到一个跳板机然后再登录到目标机器，每次输入密码（一般还是动态的）很麻烦。一般的教程推荐使用 expext 解决这个问题，这里介绍一个更简单、直接的办法。

首先，要先解决登录到跳板机的连接复用问题，这个输入 ssh 本身的范畴，一般教程都是说在 ~/.ssh/config 增加下面的配置：

host *

ControlMaster auto

ControlPath ~/.ssh/master-%r@%h:%p

但这样有个问题，iTerm2 第一次登录的 tab 关闭后，就失效了，再登录就又要密码了。其实再增加一个配置即可。

1 2	ControlPersist yes ServerAliveInterval 60

之前的设置只是实现了连接复用，但 tab 关闭 ssh 进程结束后，连接也被销毁了，ControlPersist 项的意思是进程结束后连接还保持，再有相同的（ControlPath配置）连接，还能继续使用此连接。

再者，每次输入 ssh xxx 很麻烦（而且跳板机登录后还得输入 ssh xxx），当然你可以配置 alias+expext 但也不是太方便，特别是 Windows 转过来的。对此，iTerm2 本身也提供了很强大的 Profiles 功能，能一键登录目标机器（还可以设置快捷键）。

有些自己的常用机器，还可以复制一下这份基础的 relay 配置。

再加一行（Send text at start处）。

还可以把机器打个标签，然后页面上就能分组，方便选择。

还有一个，有时候会发现，有些机器一会儿没操作就会被断开 ssh，一方面可以设置 ServerAliveInterval，但作用不大，因为实际连接服务器的是 relay 跳板机。iTerm2 其实没有可以显式设置这个功能的地方，有些同学可能找到个这个配置： Continue Reading...

2020年3月28日

Python进/线程池使用

在 Python 中，进程/线程是个非常重要的概念，特别是 Python 还有 GIL（同一时刻只有一个线程在执行 Python bytecode）限制，使得 Python 线程并不那么好用。但 GIL 更多的是影响 CPU 密集型任务，实际业务场景更多的是 IO 密集型任务，多线程还是适用绝大多数场景。不过话又说回来，很多时候不太好判断是 IO 密集型多还是 CPU 密集型多，需要在多进程、多线程环境下分别验证。

但多线程和多进程手写起来还是有点差别，好在 multiprocessing.Pool 提供了统一的接口，可以无缝切换：

# 进程池

from multiprocessing import Pool

# dummy（假）的进程，线程池

from multiprocessing.dummy import Pool as ThreadPool

下面介绍下 Pool 类如何使用。

首先是构造函数：

class multiprocessing.Pool([processes[, initializer[, initargs[, maxtasksperchild]]]])

接收 processes initializer initargs maxtasksperchild 4个参数：

processes，就是池里有多少个进程，可以不传，默认 CPU 个数，可以按需多设置几倍

initializer、initargs，如果设置了参数，则会在每个进程初始化的时候调用 initializer(*initargs)。这个非常有用，比如可以在初始化的时候建立连接，连接重用。

maxtasksperchild，用于设置每个子进程执行多少个任务后重启。虽然很简单粗暴，但这是防止内存溢出、资源未释放等问题的常见手段，类似 PHP-FPM 的 pm.max_requests 参数。线程池无此参数。

def _send_request(sql):

"""

发送单个请求

:param request:

:return:

"""

# 取出绑定的数据库连接

db_conn = _send_request.db_conn

db_conn.execute(sql)

def _initializer(func):

"""

线程初始化工作

:param func:

:return:

"""

# 绑定建立的数据库连接到请求函数的属性上

func.db_conn = mysql.connector.connect()

pool = ThreadPool(10, initializer=_initializer, initargs=(_send_request))

result = pool.map(func=_send_request, request_list)

pool.close()

pool.join()

这里有一个 hack 技巧，将初始化的数据库连接，绑定在了请求函数上，这样调用请求函数发送请求时，就不用重新建立连接，直接使用即可。

我们一般使用线程池有两个场景，一是关注执行结果，比如我们并行去 redis mysql 各个地方请求数据，然后整合这些数据，二是不关注执行结果，比如新开一个线程打印一个请求的审计日志，不阻塞主进程返回数据。这里主要是介绍下 apply 和 apply_async 的区别，其它的都类似。

apply(func[, args[, kwds]])，主要是传一个执行函数和参数，阻塞并得到返回结果。

apply_async(func[, args[, kwds[, callback]]])，也是主要传执行函数和参数，但返回的是一个 multiprocessing.pool.AsyncResult 对象，AsyncResult 主要有 get([timeout])、wait([timeout])、ready()、successful() 4 个方法，都很好理解，用的比较多的是 get 方法，给定超时时间内获取执行的结果，如果超时抛出 multiprocessing.TimeoutError 异常。如果 timeout 是 None，则一直就等待，行为就和 apply 一致了，实际上 apply 也是调用的 apply_async get：

apply_async 还有一个有用的参数 callback，相对于异步回调了，一般用于上述的场景二。下面是一些示例：

#!/usr/bin/env python

# -*- coding: utf-8 -*

from multiprocessing.dummy import Pool

import time

callback_start_time = 0

def f_sleep(x):

time.sleep(3)

return x*x

def callback_func(result):

print 'callback result:%s use:%s' % (result, current_time_millis() - callback_start_time)

def current_time_millis():

"""

当前时间戳 ms

:return:

"""

return int(round(time.time() * 1000))

if __name__ == '__main__':

pool = Pool(processes=10)

t1 = current_time_millis()

result = pool.apply(f_sleep, (10,))

t2 = current_time_millis()

print 'apply result:%s use:%s' % (result, t2 - t1)

result = pool.apply_async(f_sleep, (10,))

t3 = current_time_millis()

print 'apply_async result:%s use:%s' % (result, t3 - t2)

result = result.get(timeout=4)

t4 = current_time_millis()

print 'apply_async result2:%s use:%s' % (result, t4 - t3)

callback_start_time = current_time_millis()

result = pool.apply_async(f_sleep, (10,), callback=callback_func)

time.sleep(4) # 看回调结果

运行结果：

apply result:100 use:3001

apply_async result:<multiprocessing.pool.ApplyResult object at 0x10876dc50> use:0

apply_async result2:100 use:3041

callback result:100 use:3002

注意代码的最后一行，这里不仅仅是为了看回调结果，还因为回调是回调到主进程执行，如果主进（线）程已经退出了，那就处理不到回调了，实际使用需要注意运行环境。

最后，multiprocessing 模块的 pool 功能只是其中很小的一部分，但比较实用，后面有新的心得再介绍其它功能。

参考资料：

https://docs.python.org/2.7/library/multiprocessing.html#module-multiprocessing.pool

2019年11月24日

Python Requests Session set-cookie不生效的坑

我们知道 Python Requests库中的 Session 模块有连接池和会话管理的功能，比如请求一个登录接口后，会自动处理 response 中的 set-cookie，下次再请求时会自动把 cookie 带上。但最近出现了一个诡异的事情，cookie 没有自动带上，导致请求 403。

一开始怀疑是登录接口错误了，没有 set-cookie，但抓包发现 response header 中有 set-cookie，打印请求的 response.cookies 也有需要的 cookie。又怀疑是 set-cookie 的格式不对或者其它问题，但用浏览器实际跑了下流程，发现系统一切正常，那基本就是 requests 库的问题了。

没办法，只能 debug 了，单步调试了几轮，基本了解了 requests 的处理方式，首先把请求参数转变为 Request 对象，然后对使用 prepare_request 对 Request 进行预处理，其中有一步 merge_cookies 的操作（还有各种其它处理），把传入的 cookies 和 self.cookies merge 到 RequestsCookieJar 对象上去，这一步也没啥问题，merged_cookies 变量也是对的。后续将预处理过的请求，通过内置的 http adapter 发送出去。http adapter 底层是通过 urllib3.poolmanager 获取到 urllib3.connectionpool 连接（这里是连接池的核心部分），再通过 conn.urlopen 实际发送请求。虽然跟踪了解到了整个请求逻辑，但最终发出的请求还是没有带上需要的 cookie。

问题定位一度陷入僵局，只能再回顾上面的流程，cookie 肯定就是在 merged_cookies 和 conn.urlopen 之间没的，再仔细观察发现，conn.urlopen 请求参数里面压根没有 cookie 字段。

# https://github.com/psf/requests/blob/master/requests/adapters.py#L439

resp = conn.urlopen(

method=request.method,

url=url,

body=request.body,

headers=request.headers,

redirect=False,

assert_same_host=False,

preload_content=False,

decode_content=False,

retries=self.max_retries,

timeout=timeout

)

查阅资料发现，urllib3 的作者说，连接池只处理底层连接，cookie 跟踪等事情应该上层来做。大胆猜测，那 cookie 应该是放在 header 里了，往前捣看看 request.headers 是怎么变动的（此时里面的 Cookie 字段确实不正确）。

再走查代码发现 prepare_request 里面是调用了 PreparedRequest.prepare，其中有一步 prepare_cookies，主要是调用了 cookielib.CookieJar.add_cookie_header 最终将 cookie 放到了 self.headers['Cookie']。但里面有个 request.has_header("Cookie") 的判断，header 中没有 Cookie 字段才会放，不知道为什么这么考虑（最新版 3.8 还是这样），估计是 merge cookie 比较麻烦，但问题确实就出在这里，这次请求之前，Requests Session 已经直接通过 headers['Cookie'] 设置了 cookie。复现代码（修改自官方示例）：

import requests

s = requests.Session()

s.headers.update({

'Cookie': 'k=v'

})

s.get('https://httpbin.org/cookies/set/sessioncookie/123456789')

r = s.get('https://httpbin.org/cookies')

print(r.text)

# 预期：{"cookies":{"k":"v"},"cookies":{"sessioncookie":"123456789"}}

# 实际：{"cookies":{"k":"v"}}，未包含sessioncookie

虽然找到了问题的原因，但又不好解决，总不能不让直接操作 headers['Cookie'] 吧，先不说无法限制使用者，而且之前的代码已经这样做了，改动量非常之大。不过好在，现在自己用的框架是在 Requests Session 上封装了一层，操作 header 都是调用的统一的 update_headers 方法：

def update_headers(self, headers):

"""

更新当前会话的header

:param headers: header字典

"""

self.headers.update(headers)

对 headers['Cookie'] 的操作拦截一下，变成对 cookies 的操作：

def update_headers(self, headers):

"""

更新当前会话的header

:param headers: header字典

"""

for header_key, header_value in headers.items:

if header_key == 'Cookie' or header_key == 'cookie':

c = Cookie.SimpleCookie()

c.load(header_value)

cookies = {}

for key, morsel in c.items():

cookies[key] = morsel.value

requests.utils.add_dict_to_cookiejar(self.cookies, cookies)

del headers[header_key]

self.headers.update(headers)

这样即不用改之前的调用方代码，也防止了后人掉坑。

参考资料

https://requests.readthedocs.io/en/master/user/advanced/#session-objects

https://stackoverflow.com/questions/2422922/python-urllib3-and-how-to-handle-cookie-support

https://urllib3.readthedocs.io/en/latest/reference/index.html#module-urllib3.poolmanager

https://urllib3.readthedocs.io/en/latest/reference/index.html#urllib3.connectionpool.HTTPConnectionPool.urlopen

https://docs.python.org/2/library/cookie.html

本 Blog 不支持评论，如有疑问或建议请联系我，以完善内容，期望帮助到更多的同学

我的编程人生

yaozhen's blog

十多年了，接口自动化测试越来越鸡肋？

引言

接口自动化的价值

提高测试效率/降低人力成本？

提高测试覆盖率？

持续集成和持续交付（CICD）✓

保证结果的一致性和准确性✓

接口自动化的成本

总结

参考资料

Go“冷门”库之ohler55/ojg，兼容性更好持续维护的JSONPath库

Python RSA公钥解密 RSA_public_decrypt

N天学会Go语言

基础语法

变量

Methods are functions

Defer

Pointers

Python import机制探究

目录结构

sys.path

BuiltinImporter

sys.modules

参考资料

工作5年，后3年都重复着前2年？写在离职百度之际（QA篇）

重新review下工作

工作第1年

工作第2年

工作第3-5年

全流程质量保障

Python使用logging为Flask增加logid

logid保存与传递

打印日志自动带上logid

iTerm2进阶使用技巧

跳板机自动登录

Python进/线程池使用