Wan的技术博客

上篇写了游戏测试第一章——基础理论部分。这篇进入教程第二章：人工测试。 这一章讲人工测试不只是”点点点”，有一整套测试思维工具可以学习。以下是我理解后的梳理。 一、探索性测试：有限时间内的创造性测试专业的探索性测试有严格的框架。教程管它叫会话式测试。 核心规则就一条：每次测试都是 45-90 分钟的时间盒，围绕一个”测试宪章”展开。 测试宪章不是测试用例。它更像一个任务声明：“在未来 60 分钟内，将探索商城系统的支付边界，重点关注货币换算和余额不足场景”。 宪章要满足 SMART 原则：具体、可衡量、可实现、相关、有时限。宪章最重要的记录就是量化工作，以及提醒自己主线任务 我们上一篇也说过游戏中永远不可能100%测试覆盖率，所以需要在有限时间内“聪明”的测试。 时间盒也不要求将所有东西都测完，只要求在规定时间内找到足够多的问题。 为什么越测发现的新问题越少教程给了一个覆盖率增长模型，用微分方程描述： 1dC/dt = k · (S - C) · exp(-αt) 其中 C 是已覆盖的功能，S 是总功能，k 是学习速率，α 是疲劳系数。 这个公式翻译成人话就是：刚开始测的时候， ...

上篇写了《全栈测试》的读书笔记——那是普通软件的测试方法论。这篇开始读一个专门讲游戏测试的教程，22 章。第一章是基础理论。 读之前我有个直觉上的问题：**”游戏测试和普通测试，不就差一个’测的东西是游戏’吗？”** 读完第一章发现游戏测试要更加复杂。以下是我理解后的梳理。 一、交互复杂性：游戏的状态爆炸普通软件的测试模型是清晰的：输入 A → 处理 → 输出 B。 但是，游戏的每一帧都在发生多系统的交叉作用。以我写的那个 Go 射击游戏为例（**使用GO做一个小游戏吧**），一帧里同时跑的东西有： 123帧 N: 玩家按空格 → 射击冷却检查 → 生成子弹 → 注册碰撞事件帧 N+3: 子弹撞到陨石 → 伤害计算 → 分数累加 → Combo 检查 → 陨石分裂帧 N+5: 小陨石生成 → 方向随机 → 检测出生位置是否与玩家重叠 这是一张复杂的网状交互。教程里给了个 MMO 战斗的复杂度公式： C*{combat} = N*{skills} _ N_{buffs} _ N*{targets} * N*{positions} * N_{timing} 每一项都是一个维度 ...

QQ水群时看到这么一个段子，虽然段子很老套，但这么工整的一段话看起来就让人手痒，就做一个代码练习吧。 写一个能随机生成这段话的代码。但是如果只是一模一样地生成就有点太无聊了，最好是能根据输入的词能够按这样的模板输出。 这段文本每行的结构非常规律：{动词}{数字}{量词名词}。比如 “喝100杯奶茶” → 动词=”喝”、数字=100、后缀=”杯奶茶”。把 100 句拆完，动词和名词短语各自去重，就有了一个可复用的词库，换个输入文本也能按同样模板生成。 解析文本结构先定义数据结构。每行拆成三部分：数字前的动词、数字本身、数字后的名词短语。 1234567891011121314151617181920212223242526272829303132333435type Entry struct { Prefix string // 动词部分 Suffix string // 量词+名词 Num int}func parse(text string) [ ...

GitHub 仓库: goTraining 前言2024 年夏天用 Go 做了个东西：一个能跑能玩的陨石射击游戏。最初动机很单纯——学了 Go 的语法，想做点不是命令行输出 Hello World 的东西。游戏是很好的选择：有状态管理、有实时循环、有碰撞检测、有资源加载。一个几十兆的小程序，碰了工程里的许多问题。 引擎选的是 Ebitengine（当时还叫 Ebiten），Go 原生的 2D 游戏库。没有 Unity 那么庞大的编辑器，库只要引进来就能写 main()，跑起来。对于做个小游戏来说，刚刚好。 这篇文章是一次完整的技术复盘。不是教程，是我做完之后回头看：每一块怎么做的，为什么这么做，有什么坑，以及如果再写一次会怎么改。 架构总览整个项目只有 8 个 .go 文件，没有第三方依赖（除了 Ebitengine 本身和 Go 标准库）： 12345678├── game.go # 游戏主循环，碰撞检测，分数管理├── player.go # 玩家飞船：移动、旋转、射击├── bullet.go # 子弹：生成、飞行、绘制├── meteor.go ...

本文将记录《how linux works》一书中的知识。 第一章 概述Linux层次Linux分为用户进程，Linux内核，硬件。内核在硬件之上管理硬件系统，是硬件系统和应用程序之间进行通信的接口 进程指计算机中运行的所有程序，组成了最顶层，称作用户空间或用户进程 用户进程与内核之间最主要的区别是内核在内核模式 kernel mode中运行，用户进程在用户模式运行。内核模式中运行不受任何限制访问处理器与内存。那些只有内核可以访问的空间叫做内存空间 kernel space，反之用户进程可以访问的为用户空间 user space。一般来说用户进程的影响范围被限制在用户空间内。 主内存与CPU频繁产生读取行为的内存。数据以特定排列的0与1 bit存储，这被称为状态 state。我们可以用状态的变化阶段来描述进程的执行过程（eg. 进程的执行阶段 ，进程正在执行启动任务阶段）。镜像 image 通常表示比特值在内存中的特定物理排列 内核内存负责管理以下四个方面： 进程：决定哪个进程可以使用CPU 内存：内存分配，管理进程间的共享内存与空闲内存 设备驱动程序：作为硬件系统和进程之间的接口 ...

为什么一个开发者要看测试书《Full Stack Testing》这本书不厚，但覆盖了从单元测试到探索性测试的整套方法论。以下不是书的内容摘要，是我读完后觉得真正有用、并且从开发者视角重新理解过的部分。 测试不是找 bug这是书里让我重新校准的第一个概念。 找 bug 是测试的结果，不是测试的目的。测试的目的是提供信息——这段代码在什么条件下正常工作，在什么条件下会出错，错了之后的表现是否可接受。这个信息服务于一个决策：现在能上线吗？ 把测试理解为”信息获取”而不是”质量检验”，会改变你做测试的方式。你不会问”这个功能有 bug 吗”，而是问”在所有我知道的边界条件下，这个功能的行为我都看清楚了吗”。前者只有一个答案（有/没有），后者会引导你系统地列出一组场景。 等价类划分与边界值分析这两个是测试理论里的基础，几乎是所有测试方法论的起点。 等价类假设有一个输入值 x，业务逻辑分三段处理：x < 500、500 ≤ x ≤ 1500、x > 1500。理论上三个区间里的任意值行为都应该一致。所以你不必测全部数值，只需要在每个区间挑一个代表。 等价类的核心思想： ...

混沌工程并不是在生产环境中搞破坏。搞破坏很容易但完成下述事情很难：减小爆炸半径，对安全性进行批判性思考，确定漏洞是否值得修复，决定是否应该进行实验。寻找做对的地方比寻找做错的地方提供的信息多得多，因为对于复杂系统而言，故障可能是因为熵增而导致的系统性错误，这些并不能被预测到。而混沌工程通过实验认识到系统的属性信息，从而可以通过测试的方法规避掉错误，让团队拥有更好韧性。 对与让系统更加健壮而言，一味的冗余只会掩盖问题的存在，同时冗余的同时引入了故障，发生了熵增。