光の技术屋

在应用日常开发的过程中，不论是在测试、开发联调，还是实际构建发布的时候，我们都需要一定的指标去衡量技术产物的质量，从而判断技术产物是否符合质量标准，是否能够继续发布投产，如果不符合投产标准则拦截发布。从发布过程的角度，由于一般发布过程会收口到特定的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大世界游戏中，寻路效果自动化测试的方案。

《Game Of AutoTest》的最后一篇文章，聊一下游戏自动化测试的价值。

一千个人心中有一千个哈姆雷特。仅以笔者的角度，游戏自动化测试的价值，可以体现在这几个方面：

• 效率提升
• 缺陷发现
• 质量监控
• 技术支持

做好自动化测试的价值分析，不仅能够自动化测试技术落地做足理论基础，而且也能在任意时候指引自动化技术落地者做好当下的决策，从而逐渐把自动化测试做出更大的规模跟成果。

近期装Ubuntu22.04虚拟机，发现侧边菜单栏多了个Floppy Disk图标。软驱这东西毕竟是上世纪的了，2022年也没什么用，但就是找不到入口去掉这个冗余的图标。

今天偶然之间发现去掉图标的方式，供大家参考：

• 右上角点电源/声音/网络按钮，选择Settings设置
• 选择Appearance，就是能调Light/Dark风格的页签
• 下拉，在Dock栏目下，点击Configure dock behavior
• 里面的Show Volumes and Devices下，有一个Include Unmounted Volumes项。反正软驱一般也不会挂载，所以取消点选这个项，Floppy Disk图标就没了。

正值十一假期，近期准备把自己的python笔记精编整理，做一个pdf电子书。在调研如何把多个markdown文档转化为单个pdf的时候，试了很多种方法。最后找到了最佳方案，也就是本文的主角，由phodal前辈整理的电子书生成项目ebook-boilerplate。这个项目不仅支持批量转markdown为pdf，而且还支持转成ebook等多种格式。

使用这个项目的时候，也踩了一些坑，需要做一些额外的配置。以笔者的场景为例，电子书生成环境是Ubuntu22，需要转化一堆中文的markdown。clone了这个项目之后，除了ebook-boilerplate本身README.md里描述的内容之外，实际还需要留意以下环节：

在游戏自动化测试技术落地过程当中，如何保证自动化测试的稳定性，是一个需要重点优先解决的困难问题。

以手机游戏客户端自动化测试为例，和一般服务架构的自动化单元测试或集成测试不同，自动化驱动的过程，其本质更加类似于网络爬虫，每次测试执行都是一个时间较长的过程，而流程一长，不稳定因素则随之而来。游戏自动化的整个过程，大致是这样的：

• 前置环境准备（setup）：设置用例运行环境、设备状态与玩家状态，保证用例运行的条件
• 用例脚本执行（run）：执行自动化用例脚本
• 后置恢复操作（teardown）：恢复测试环境、设备状态与玩家状态
• 测试报告输出（report）：整合跑测期间游戏的运行数据与用例脚本收集/导出的数据，生成测试报告

要分析如何保障整个自动化过程的稳定性，我们可以根据这几个步骤进行细节切分，对每一个环节影响稳定性的因素逐个理顺，从而最终，我们就可以得到一整套自动化稳定性保障的解决方案。在这四个步骤当中，前置环境准备和用例脚本执行这两步，对自动化流程稳定性的影响面最大，而最后面两步的影响程度，则相对较低。