QA 测试工程 | Shrimp Jetton

一、概述

QA（Quality Assurance）测试工程是软件开发生命周期中的关键环节，涵盖从需求分析到发布验证的全流程质量保障。本技能整合自动化代码检查与手动测试执行能力，提供完整的测试解决方案。

                QA vs QC vs 测试
                QA（质量保证）：预防缺陷的过程导向活动
QC（质量控制）：发现缺陷的产品导向活动
测试：QC的一种手段，通过执行来发现缺陷

            

二、核心能力

2.1 测试规划

测试计划制定：根据项目需求制定测试策略和计划
测试用例设计：功能测试、边界测试、异常测试用例编写
测试范围界定：确定测试优先级和覆盖范围

2.2 自动化代码检查

静态分析游戏代码，检测常见问题：

检查项	说明
`HTML结构`	检查DOCTYPE声明、基本HTML结构
`Canvas初始化`	检测2D上下文是否正确获取
`游戏循环`	检查requestAnimationFrame是否存在
`事件监听`	检测键盘/鼠标事件监听
`音频系统`	检查AudioContext配置
`代码安全`	检测未定义变量风险、无限循环风险

检查结果级别

✅ 通过 - 无明显代码问题
⚠️ 警告 - 潜在问题需人工判断
❌ 失败 - 严重问题需立即修复

使用方法

cd /root/.openclaw/workspace/skills/bug-checker
./check-games.sh

已知的设计选择（非BUG）

部分警告是正确的设计选择，而非Bug：

游戏	警告	实际	状态
编程机器人	可能缺少游戏循环	回合制编程游戏，使用事件驱动渲染	✅ 设计正确
六指迷笛	可能缺少Canvas初始化	使用DOM元素构建界面	✅ 设计正确

2.3 手动测试执行

核心测试项

测试项	说明
加载测试	游戏能否正常加载，无报错
第一关验证	第一关能否正常开始和完成
控制响应	键盘/鼠标/触摸是否响应
游戏逻辑	核心玩法逻辑是否正常
音频测试	音效和背景音乐是否正常播放
视觉检查	UI显示、动画、特效是否正常

测试清单（20款游戏）

                重力反转跑酷
记忆迷宫
颜色匹配射击
链式反应
时间回溯
编程机器人
资源塔防
光影谜题
卡牌合成
量子分裂
磁力吸附
波形战士
镜像迷宫
热胀冷缩
电路连接
声波迷宫
像素画
节奏跑酷
引力弹弓
六指迷笛

            

测试记录模板

游戏名称: [填写]
测试日期: [填写]
浏览器: [填写]

测试结果:
  [ ] 能正常加载
  [ ] 第一关正常
  [ ] 控制响应
  [ ] 逻辑正常
  [ ] 能完成第一关
  [ ] 音频正常

发现问题:
  [填写具体问题]

严重程度: [ ]轻微 [ ]中等 [ ]严重

2.4 Bug跟踪与管理

Bug报告编写：复现步骤、预期结果、实际结果、环境信息
严重程度分级：致命/严重/一般/轻微
回归测试：修复验证和回归测试执行

严重程度分级标准

级别	说明	示例
致命	系统崩溃/数据丢失	游戏启动即崩溃
严重	核心功能不可用	无法保存进度
一般	次要功能异常	UI显示错位
轻微	不影响使用的瑕疵	文字拼写错误

三、测试基础理论

3.1 核心原则

3.2 Shift-Left Testing（左移测试）

尽早开始测试

在需求阶段就介入，发现越早修复成本越低。发布后发现问题的修复成本是开发阶段的 100倍。

其他重要原则：

穷尽测试是不可能的：必须基于风险进行优先级排序
缺陷集群性：80%的缺陷集中在20%的模块中
杀虫剂悖论：相同的测试用例多次执行会失效，需要不断更新
测试依赖于上下文：安全关键软件 vs 游戏应用，测试策略完全不同

四、测试类型

4.1 功能测试

验证软件功能是否符合需求规格说明。

4.2 兼容性测试

跨浏览器测试（Chrome、Firefox、Safari、Edge）
跨设备测试（桌面、平板、手机）
跨操作系统测试

4.3 性能测试

加载时间测试
帧率稳定性测试
内存占用监控

4.4 用户体验测试

UI/UX一致性检查
交互流畅度评估
可访问性测试

五、游戏QA专项

5.1 游戏测试用例框架

🔹 基于场景的测试框架

模拟真实玩家可能遇到的各种情况来设计测试用例。

示例场景：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
场景：玩家在高山顶端遇到敌人
前提：角色HP>50，装备近战武器
步骤：
  1. 角色攀登至最高点
  2. 触发敌人遭遇战
  3. 在狭窄地形进行战斗
预期：
  ✓ 角色移动不受地形阻挡
  ✓ 战斗判定正常
  ✓ 跌落检测生效

🔹 关键路径测试框架

专注于验证游戏中最重要和最常用的功能，确保游戏基本可玩性。

关键路径清单：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□ 游戏启动 → 主菜单 → 开始游戏
□ 角色创建/选择
□ 新手教程完成
□ 第一个任务/关卡完成
□ 存档功能
□ 读档功能
□ 核心玩法循环验证

🔹 数据驱动测试框架

使用大量预定义数据验证数值系统、平衡性和性能。

角色属性测试数据示例：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| 等级 | 经验值 | 预期HP | 预期攻击 | 状态 |
|------|--------|--------|----------|------|
| 1    | 0      | 100    | 10       | 通过 |
| 50   | 125000 | 2500   | 150      | 通过 |
| 99   | 999999 | 9999   | 500      | 通过 |
| 100  | MAX    | ?      | ?        | 边界测试 |

🔹 探索性测试框架

自由探索游戏，根据经验和直觉发现潜在问题。

测试人员扮演"破坏者"角色：尝试设计者没预料到的操作，比如在不改跳跃的地方跳跃、以意外顺序完成任务。

🔹 兼容性测试框架

确保游戏在各种硬件、软件环境下正常运行。

测试维度	测试项	优先级
硬件	GPU型号、内存大小、CPU性能	P0
操作系统	Windows 10/11, macOS, Linux	P0
分辨率	1080p, 2K, 4K, 超宽屏	P1
外设	手柄( Xbox/PS/Switch ), 键鼠, 触屏	P1

5.2 游戏测试类型

测试类型	测试内容	常用工具
功能测试	核心玩法、UI交互、任务系统	TestRail, Xray
性能测试	帧率、加载时间、内存使用	Unity Profiler, RenderDoc
兼容性测试	多平台、多配置适配	BrowserStack, 真机
本地化测试	翻译质量、文本适配、文化合规	Lokalise, Crowdin
安全性测试	反作弊、数据安全、API安全	Burp Suite, Cheat Engine
用户体验测试	难度曲线、操作流畅度、趣味性	问卷、访谈、数据分析

六、软件QA通用

6.1 测试流程

需求分析 - 理解用户故事、验收标准
测试计划 - 范围、资源、排期、风险
测试设计 - 编写测试用例、准备测试数据
测试执行 - 手动/自动化测试
缺陷报告 - 记录、分类、跟踪
回归测试 - 修复后验证
发布验证 - 最终确认
持续监控 - 线上质量跟踪

6.2 Bug报告标准

                高质量Bug报告要素
                标题：简明扼要描述问题
环境：版本、系统、配置
重现步骤：精确到每一步操作
预期结果：应该发生什么
实际结果：实际发生了什么
附件：截图、录屏、日志
严重级别：Blocker/Critical/Major/Minor
优先级：P0/P1/P2/P3

            

Bug报告示例：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
标题：结算界面金币数值显示为负数

环境：
  - 版本：v1.2.3
  - 平台：Windows 11
  - 分辨率：1920x1080

重现步骤：
  1. 进入第5关
  2. 收集所有金币（共150枚）
  3. 完成关卡进入结算界面
  4. 快速连续点击"下一关"按钮

预期结果：
  金币显示为150，点击下一关正常跳转

实际结果：
  金币显示为-4294967146（溢出）
  点击下一关无响应

附件：screenshot_01.png, game_log.txt

严重级别：Major
优先级：P1
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

6.3 测试设计技术

等价类划分

将输入数据划分为若干等价类，每类选取一个代表值测试。

示例：年龄输入框（要求18-60岁）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
有效等价类：18-60岁 → 选30岁测试
无效等价类：
  - 小于18 → 选10岁测试
  - 大于60 → 选70岁测试
  - 非数字 → 选"abc"测试
  - 空值 → 选""测试

边界值分析

边界是最容易出错的地方，重点测试边界值及其附近值。

接上例：年龄输入框（18-60岁）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
边界值测试：17, 18, 19, 59, 60, 61

状态转换测试

适用于有明确状态流转的系统（如订单、任务）。

四、自动化测试

4.1 自动化策略

                什么应该自动化？
                ✅ 重复执行的回归测试
✅ 数据驱动的大量组合测试
✅ 性能/负载测试
✅ API接口测试

                什么不应该自动化？
                ❌ 只执行一次的测试
❌ UI频繁变化的功能
❌ 需要主观判断的UX测试
❌ 探索性测试

            

4.2 常用工具

用途	工具	适用场景
UI自动化	Selenium, Playwright, Cypress	Web应用
移动端	Appium, Espresso, XCUITest	iOS/Android App
API测试	Postman, REST Assured, JMeter	接口验证、性能测试
单元测试	Jest, pytest, JUnit	代码级测试
游戏专用	Unity Test Framework, Unreal Automation	Unity/Unreal项目

五、质量指标

5.1 常用度量

测试覆盖率：代码/需求/用例覆盖百分比
缺陷密度：每千行代码的缺陷数
缺陷逃逸率：发布后发现的缺陷占比
平均修复时间：MTTR (Mean Time To Repair)
测试执行率：计划用例的执行完成度
通过率：执行用例的通过百分比

六、最佳实践

测试即文档：清晰的测试用例就是最好的功能文档
可重复性：任何人按步骤执行都能复现结果
独立性：一个测试失败不影响其他测试
原子性>/strong>：一个测试只验证一个概念

及时反馈：发现问题立即报告，不要等待

持续学习：每个缺陷都是改进测试的机会