光の技术屋

今天这篇文章，聊一下python在web开发上的一些基础实现，阐述下自己理解中的WSGI、ASGI，以及拿uvicorn+FastAPI的组合举个ASGI应用的例子。

WSGI

python的web服务的诞生，其实追溯到一种机制，叫做WSGI，全称Web Server Gateway Interface。WSGI的提案来源于PEP-333，可以理解为一种python-web-server和python-web-app的接口通信标准。在这种场景下，python的web服务呈现以下的工作模式：

• python-web-app，也就是web应用层，实现WSGI接口，用作web请求的handler
• 用户向python-web-server发送web请求
• python-web-server，又称作WSGI Server，解析请求数据，整理当前session的环境信息
• python-web-server加载python-web-app，调用python-web-app实例的WSGI接口，处理请求
• python-web-app处理完请求，返回结果给到python-web-server
• python-web-server写回返回结果，给回用户

代码上是这样的表现，以官方提案的例子为例：

要做游戏自动化测试，首先需要了解游戏自动化技术。因此，本文详细讲解下游戏自动化测试领域可能用到的一些技术以及对应的场景，为自动化测试落地的技术选型提供参考。

游戏自动化测试的测试对象是游戏本身。对于游戏这个概念，可以有以下几种：

• 客户端：我们实际玩到的游戏本体，比如说PC程序，手机App，Web-App。
• 服务器：在多人网络游戏中，用以模拟游戏世界的本体。
• 编辑器：包含未烘焙到OS平台的游戏程序以及资源。

我们在技术层面上所要做到的，就是通过某些方式访问这些程序运行环境产生的内容，改变游戏呈现以及玩家行为，操作玩家或游戏程序本身，达到我们的测试目的。在笔者的工作经验当中，主要做的是UE安卓客户端的自动化，应用场景主要在业务功能测试方面，因此本文会对客户端自动化做稍微详尽的解析。其他自动化的方案和叙述，如果其中描述有所纰漏，恳请指正。

客户端自动化

针对游戏客户端的自动化，在游戏测试里是最为广泛应用的，不仅是因为客户端是一个游戏必须有的成分，而更加因为我们在手工测试游戏的时候，实际是拿着客户端来测的。因此，客户端自动化会最贴合游戏功能测试的需求。

要实现客户端自动化，有以下的方法：

2022年的8月，结束了很长一段时间的犹豫，笔者决定开启新的文章系列：《Game Of AutoTest》，向外界公开自己近两年来在游戏自动化测试方面所沉淀的工作经验，以及许多关于自动化测试本身的思考跟想法。在先前的测试人生栏目中，曾经分享过许多关于游戏自动化测试的技术，但并没有一个比较系统化的输出。因此借这个机会，笔者也决定好好分享一下，从一个更加纯粹的技术人的角度，对于游戏自动化测试这一细分领域的理解。

自动化测试本身已经不是一个新鲜的名词，不论是游戏还是传统互联网行业，我们都能够见到自动化测试落地的身影。但是，自动化测试基础技术到底需要往怎样的方向搭建，业务应用需要覆盖哪些场景，这些话题其实很少被讨论，并且实际沉淀下来的知识分享和业务产出，也不尽然特别引人注目。尤其在游戏测试领域，自动化测试如何被应用到实际测试工作当中，相关的沉淀是少之又少，可以算是一片待开垦的荒地。

游戏自动化测试——这个名词本身都没有一个确切的定义。有些人认为，只有像自动驱动客户端玩游戏，测试场景物件是否正常交互，这种能够实际测到和测试用例相关的内容，才算是自动化测试；也有些人认为，像一些纯粹收集性能数据的场景，比如驱动玩家在地图里跑图，收集前后台数据，也算是自动化测试。这说明了，只要是用了程序化的手段，去完成游戏测试的整个或一部分的流程，那么就有可能被定义为一种游戏自动化测试的方案。但遗憾的是，正因为如此，很多测试工作者为了让自己的工作有技术含量，都会尝试沾自动化测试技术的光，为了技术而技术，用一些现成的自动化工具去做了个demo规模的东西，然后很阿里味地包装成富有技术含量的测试工作，但实际上相对于原来反倒增加了学习、维护、执行成本，是毫无价值的负优化。其中原因，归根到底，还是自动化测试这个工作被很多人小看了。如果你是个测试工作者，但业务经验、技术能力以及良师指导三者都很缺乏，并且业务环境上没啥落地场景，组织氛围也没啥支持的话，要做好自动化测试，那是非常困难的。

因此，我们有必要去重新认识游戏自动化测试这个概念。有几个准则：

在python面试里，多线程是避不开的话题，其中一个经典问题就是，多线程threading.Thread是不是并行运行。这个问题的答案，说是也不对，说不是也不对，得分情况讨论。本文就带领大家，分析并回答这个问题。

我们用一段代码来做实验：

在python开发期间，很多时候我们会需要执行一段cmd终端命令，或者是执行其他程序返回stdout或者文件输出结果。这种时候，我们就需要用到subprocess模块。虽然我们用os.system也可以达到执行命令的需求，但用os.system只是干发一段命令，对于执行命令的程序，我们没有办法跟踪它的内部状态以及执行结果，因此从稳定性的角度来讲不是一个好的选择。因此，本篇文章讲解下subprocess子进程模块的的基础应用，让没用过这个模块或是经常踩坑的同学都避避坑。

subprocess模块的官方文档在这里，最核心的单位是subprocess.Popen类，它描述了一个正在运行中的进程。subprocess最基础的用法是subprocess.run，我们入参一段cmd终端命令，run方法内部就会启动一个Popen对象执行这个命令，等待命令执行结束后，返回这个命令执行的退出码retcode，标准输出流内容stdout以及标准错误流内容stderr。我们可以从源码中详细捋一下subprocess.run的流程：

近期由于工作原因，开始了解vue3的内容。vue3相对于vue2采用了组合式的描述，原来的写法是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

export default {
    name: 'HelloWorld',
    data() {
        return {
            a: 1,
            b: 2,
        }
    },
    mounted() {
        this.a = 3
    },
    methods: {
        onConfirm() {
            console.log(this.a)
        }
    }
}

而到了vue3，提倡的写法变成了：

近期准备开始做electron相关的开发工作，因此借着这个机会就再去了解下electron。在很久以前的文章中有稍微玩过electron+react+antd的脚手架，但也只限于快速开发electron应用，并没有去剖析整个项目结构。因此这次，还是得深入一下。

先前一段时间特别喜欢用开源的Motrix下载器，就是基于electron+vue+aria2去实现的，所以索性就把源码给clone了下来。本文就从最基础的开始，以Motrix的启动逻辑为入口，来研究下一个electron应用是如何打开的。

首先看一下Motrix的目录结构，源码基本在src下，呈现这样的层级关系：

正则表达式是文本处理中的重要部分，通过匹配特定的正则表达式，能够很方便地编写提取特定文本的代码。在python中，同样也已经拥有了正则表达式库re，为各位开发者提供了正则表达式的支持。

在python官方文档中，已经对正则表达式模块接口、词法和用法做了详细的介绍：

• re——正则表达式操作
• 正则表达式HOWTO

正则表达式常见的用法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import re


def test_pattern():
    pat = re.compile('[0-9]{2,3}')
    print(pat.match('a'))
    print(pat.match('1'))
    print(pat.match('111'))


def test_matches():
    s = '123abc456def789xyz007ddc'
    pat = re.compile('([0-9]+)([a-z]+([0-9]+))')
    for match in pat.finditer(s):
        print(match.groups())


if __name__ == '__main__':
    test_pattern()
    test_matches()

test_pattern中，compile了一个只匹配2~3个数字字符的正则对象，test_matches中，则匹配了数字+小写字母+数字的正则对象，并且用括号分了三个组。两个函数打印出来的结果是：

1
2
3
4
5

None
None
<re.Match object; span=(0, 3), match='111'>
('123', 'abc456', '456')
('789', 'xyz007', '007')

接下来我们就深入其中，看下源码怎么实现的。

python的字符串实质到底是什么类型的数据，这个可是困扰着很多编程者的话题。在python2我们已经被中文编码相关的问题折磨的不轻，那到了python3之后为什么又解决了这个问题呢？今天这篇文章就带大家详细剖析python3的字符串实现。

我们首先看一段代码：

1
2
3

def test_str_basic():
    s = '123456789'
    print(type(s))

这段代码打印了一个字符串对象的类型，其结果为<class 'str'>。str类型从哪里来？从C源码中我们可以搜索到，其来源于unicodeobject.c的PyUnicode_Type

在上篇文章里说完了日志实例Logger和日志管理Manager，现在该提到Handler了。Handler是日志信息的消费者，单个Logger实例注册多个Handler，每生成一个LogRecord，就会被合法的Handler消费，在不同地方打印出日志信息。

要研究Handler，首先需要看下基类的实现：

1
2
3
4
5
6
7
8
9
10

class Handler(Filterer):
    def handle(self, record):
        rv = self.filter(record)
        if rv:
            self.acquire()
            try:
                self.emit(record)
            finally:
                self.release()
        return rv

Handler会通过自带的重入锁限制日志记录被串行处理。Handler也是继承Filterer，首先会通过filter过滤日志是否满足Handler的要求，如果合法，然后调用emit方法处理日志。

emit方法在基类是NotImplemented，需要子类加以实现。因此接下来我们具体抽几个例子来看。