光の技术屋

在很久以前的Easy Python系列中，介绍了通过爬虫手段爬取豆瓣电影信息的一种技术套路。今天故技重施，为了迎合先前做SQL语句分析的需要，决定爬取w3schools网站上面所有SQL案例，用作测试用例。

本文就来详细讲述，爬取w3schools网站的实现方式，以及里面需要注意的一些点。代码统一放在这里。

在Golang的实战中，总会遇到一些场景，比如抓包分析sql指纹，或者是输入sql时检查sql的风险，这类操作都需要解析sql的工具才能够生效。今天，就来介绍一些Golang当中解析sql的工具包和使用方法。

本文介绍的工具是vitess-sqlparser，主要结合了两个sql解析工具：

• xwb1989/sqlparser
• tidbparser

其中，xwb1989/sqlparser项目支持的功能有限，尤其对于DDL没有很好的支持，而tidbparser则功能比较全面。下面以tidbparser为例，讲述一下解析以及分析sql里DDL语句的一种方式。

代码相关写法可以查看这篇文章。首先，我们先自定义一个要验证的DDL语句：

和许多面向对象的编程语言一样，Golang也存在interface接口这样的概念。interface相当于是一个中间层，下游只需要关心interface实现了什么行为，利用这些行为做些业务级别事情，而上游则负责实现interface，把这些行为具象化。本文就来通过一个简单的缓存cache模块的实现，来示范一下Golang的interface该怎么用。

首先，从业务service角度而言，一个cache模块可能需要以下几种方法：

• 获取缓存中的某个值
• 缓存数据，加缓存时效
• 删除缓存内容

那么这些个方法，就可以用一类叫Cache的interface来表示：

很多同学在自己机器上玩开发的时候，都会用到VMWare、VirtualBox之类的虚拟OS容器装一个带GUI的Linux OS，然后在里面另外安装开发工具做开发。这里面遇到的最经典问题，就是比如我在虚拟机里面起了个MySQL、Redis之类的服务，如果DB的客户端/GUI工具是放在主机里面，不在虚拟机里，那怎么连进去？这个问题，本文提供一种解决方案。

本文采取的虚拟机环境如下：

• 主机：Win11
• 虚拟机容器：VMWare Workstation 16
• 虚拟机：Ubuntu 22.04

首先需要了解到，VMWare场景下，我们通常用NAT模式新开一个网段来管理虚拟机的网络配置，而虚拟机内部，假设使用IPV4，会默认采取DHCP机制，自动设置一个IP跟相应的网络配置。相关资料可以看这几篇文档：

• 网络中的NAT模式
• DHCP百度百科

而为了让我们主机能连到虚拟机内部，实际上是满足下面两个条件之一即可：

在应用日常开发的过程中，不论是在测试、开发联调，还是实际构建发布的时候，我们都需要一定的指标去衡量技术产物的质量，从而判断技术产物是否符合质量标准，是否能够继续发布投产，如果不符合投产标准则拦截发布。从发布过程的角度，由于一般发布过程会收口到特定的CI流水线上，因此在做这类能力的时候，通常是采用开发一个特殊的质量红线原子的方案，集成到CI流水线当中，实现发布准入准出的原子能力。

准入准出质量红线能力的开发者，通常是DevOps中台，中台提供原子能力以及配置化的能力，用户可以根据自己的业务去配置相应的指标产出与拦截规则，也可以直接套用特定的模板来快速实现准入准出的效果。本文就来讨论，这类能力要开发出来，在技术实现上，需要做怎样的考虑跟设计。

首先，针对真实业务，要用到准入准出质量红线的话，可能会考虑以下场景：

• 日常开发提测，在代码提交MR时，通过MR的hook触发对最新代码的规范检查
  • 代码检查需要关心一系列指标，包括：代码缺陷、代码安全、编码规范、重复代码、复杂度
  • 不符合指标的情况下，显示被质量红线拦截，MR被阻止
• 版本转测时，保证代码质量与单元测试代码覆盖率符合要求
  • 不符合指标的情况下，终止归档构件
• 用户采用脚本等方式，自定义发布红线指标与生成过程，不符合指标的，阻止发布流程

因此，从技术实现角度上，这里可以拆解成几个维度：

Golang的反射功能，在很多场景都会用到，最基础的莫过于rpc、orm跟json的编解码，更复杂的可能会到做另外一门语言的虚拟机。通过反射模块，我们可以在编程语言的runtime运行时期间去访问内部产生对象的信息。了解反射模块的实现，对我们了解Golang对象机制本身，也是莫大的帮助。

今天，恰逢阳康+新年，就决定来探究一下Golang的反射模块——reflect。

从最基础的开始，reflect模块，以获取整数对象的类型信息为例，我们可以这么用：

在以前写过的一篇关于游戏策划配置检查工具设计的文章里，笔者讲述了一种表格检查工具的分层设计方法，简而言之也就是两部分：

• 配置数据源服务：管理本地策划配置repo，通过自定义脚本解析repo中文件，提供实际的配置数据
• 配置数据处理服务：处理实际的配置测试业务，比如表格检查、excel-diff等等

其中，配置数据源服务，在许久以前写过一个样例的版本repomaster，
实际也就是一个管理git-repo的小服务，在这篇博客里有详细阐述实现内容。

而今天的主题则是配置数据处理服务方面的内容，笔者采纳通过配置化方式声明数据处理过程的设计，编写了一个数据聚合工具：daggre，全称为DAta-AGGREgator，专门用于处理数据的联表视图、过滤检查相关的需求。

以游戏业务测试为例，daggre的使用场景，我们可以看两个例子：

《从零单排Golang》系列，又重新开张了。后续会不定期更新自己学习Golang的笔记跟心得。

这次的话，就介绍一款名为奎爷kratos的微服务框架，以及讲述一下基础的使用机理。

kratos是B站开源的微服务框架，不仅提供了grpc、http协议支持，而且有较为完善的层级架构、微服务中间件以及第三方组件的编写约定，可以说是非常方便上手跟扩展。

要上手kratos，我们可以从两个地方入手：

• kratos-github
• kratos官方文档

通过kratos的quickstart文档，我们可以创建一个名为kratostest的项目。项目的目录结构遵循kratos-layout，具体如下：

在互联网上，关于游戏测试（开发）领域的技术分享，实际是非常稀少。尤其针对游戏功能测试领域，很多文章的思想维度仍然停留在很久以前，关注的更多是测试用例设计以及质量管理这些更加偏向业务方面的内容。很多同学认为游戏业务测试缺乏技术含量，其实本质上是因为，很少同学愿意投入精力去研究这个领域的技术，以及研究这些技术如何更好地契合到实际的业务当中。

为此，针对游戏测试（开发）的工作特性，笔者根据自己以前的博客整合了两个文集，分别是：

在一些无缝大世界的游戏当中，我们通常能够体验到游戏的自动寻路功能，通过自动寻路，玩家可以不用任何操作就到达任务或者玩法的目的地，从而让游戏过程更加轻松。在测试寻路功能时，不仅需要检查寻路是否成功到达，而且也需要关注寻路路径呈现的效果，从而确定玩家是否走在策划预想的路径上。

由于寻路起点、终点选择的随机性，人工执行寻路测试时，往往需要根据自定义的规则遍历多个特定的起点终点，这样操作起来不仅非常耗费人力，而且针对再后台存储navmesh数据、做动态烘焙以及计算寻路路径的场景，在验收寻路效果时，测试人员还需要多次手动从后台拉取一定范围的navmesh数据并绘制在客户端的路面上，才能知道玩家是走在什么样的路面。为了解决寻路效果测试的效率问题，引入自动化技术显得非常有必要。

因此，笔者将结合自己实际的工作经验，分享一种在UE4大世界游戏中，寻路效果自动化测试的方案。