前言测试术语很多单看定义容易混淆。本文继续用上次的小游戏《勇者打怪》做例子看看一个新版本从写代码到上线要经过哪些测试每种测试叫什么、测什么。假设这次版本要上线一个新功能“打怪升级 组队副本”。一、按测试阶段划分从小到大这是最常用的一组术语按被测对象的大小来划分。1. 单元测试Unit Testing测什么代码中最小的单位通常是一个函数或一个类。谁来做开发者自己。游戏例子只测“计算经验值”这一个函数是否算对不启动游戏也不连接数据库。# game.pydefcalc_exp(base_exp,exp_rate):ifbase_exp0:raiseValueError(经验不能为负数)returnint(base_exp*exp_rate)# test_game.py使用 pytest 运行pytest test_game.pyimportpytestfromgameimportcalc_expdeftest_普通经验():assertcalc_exp(100,1)100deftest_双倍经验():assertcalc_exp(100,2)200deftest_负数经验报错():withpytest.raises(ValueError):calc_exp(-1,1)assert叫做断言判断结果是否符合预期不符合就算测试失败。2. 集成测试Integration Testing测什么多个模块组合在一起后能否正确协作。游戏例子玩家打死怪物后“战斗模块”算出经验交给“角色模块”升级再由“存档模块”写入数据库。单个模块都没问题连起来可能出错比如经验值传过去时单位不一致。3. 系统测试System Testing测什么把整个系统部署起来像真实用户一样完整地使用。谁来做通常是测试工程师QA。游戏例子在测试服上完整走一遍流程注册 → 创建角色 → 打怪 → 升级 → 组队进副本 → 掉落装备 → 下线 → 重新登录检查数据是否还在。4. 验收测试Acceptance Testing测什么软件是否满足用户或需求方的要求决定“能不能上线”。游戏例子策划和运营亲自体验确认副本难度、掉落率是否符合设计。验收测试中有两个常见术语游戏行业里尤其常见术语含义游戏中的叫法Alpha 测试在公司内部由内部人员测试内部测试Beta 测试发给一部分真实用户测试删档内测、不删档测试、公测测试金字塔Test Pyramid/\ /UI\ 端到端/系统测试少量慢成本高 /----\ / 集成 \ 集成测试适量 /--------\ / 单元 \ 单元测试大量快成本低 /------------\意思是底层的单元测试应该写得最多因为运行快、出错时容易定位越往上的测试越慢、越贵数量应该越少。二、按是否看代码划分黑盒、白盒、灰盒术语含义游戏例子黑盒测试不看代码只看“输入什么、输出什么”测试员不知道代码怎么写只检查“打死史莱姆是否得到 100 经验”白盒测试看着代码测确保每条分支都被执行到开发者发现代码中有if 暴击:的分支专门写一个触发暴击的用例灰盒测试了解部分内部结构但主要从外部测试测试员知道经验存在数据库的exp字段打完怪后直接查数据库核对和白盒测试相关的一个术语是代码覆盖率Code Coverage测试运行时执行到的代码占全部代码的比例。比如覆盖率 80%说明还有 20% 的代码从未被测试执行过。覆盖率高不代表没有 Bug但覆盖率低一定说明测得不够。三、按测试内容划分功能与非功能1. 功能测试Functional Testing测“对不对”功能是否按需求实现。游戏例子组队后副本里能否看到队友Boss 死后是否掉落装备2. 非功能测试Non-functional Testing测“好不好”速度、稳定性、安全性、兼容性等。术语测什么游戏例子性能测试响应快不快释放技能后多少毫秒内能看到效果负载测试在预期人数下表现如何模拟 5000 人同时在线服务器是否流畅压力测试超出极限时会怎样模拟 2 万人同时涌入服务器是崩溃还是排队并发测试多人同时操作同一资源两名玩家同一瞬间拾取同一件装备会不会两人都拿到刷装备漏洞稳定性测试耐久测试长时间运行是否出问题服务器连续运行 72 小时内存是否持续上涨安全测试能否被攻击修改客户端发送的数据能否把金币改成 999999兼容性测试不同设备、系统能否正常运行在不同品牌手机、iOS/Android、不同分辨率上运行易用性测试用户是否容易上手新玩家能否在没有提示的情况下找到组队按钮本地化测试不同语言地区是否正常英文版界面文字是否超出按钮游戏开服当天“服务器爆满、排队几小时”通常就是负载测试和压力测试没做充分。四、按测试时机和目的划分1. 冒烟测试Smoke Testing含义拿到新版本后先花几分钟检查最核心的功能能否运行。如果连这一步都过不了就退回给开发不再进行后续测试。名字来源硬件工程师给新电路板通电如果冒烟了后面就不用测了。游戏例子新版本能否启动、能否登录、能否进入地图、能否打一只怪。2. 回归测试Regression Testing含义修改代码后重新测试原有的功能确保没有被改坏。游戏例子开发者为组队副本修改了战斗代码结果单人打怪不掉经验了。回归测试就是为了发现这种“修好一个弄坏另一个”的问题。回归测试需要反复执行所以最适合自动化。3. 探索性测试Exploratory Testing含义不按预先写好的步骤由测试员凭经验边玩边找问题。游戏例子测试员故意在 Boss 释放大招的瞬间退出队伍、断网、切换地图看看会发生什么。很多游戏的“卡墙”“穿模”漏洞就是这样发现的。4. 随机测试 / 猴子测试Monkey Testing含义像猴子一样乱点乱按用随机输入检测程序会不会崩溃。游戏例子用工具在手机上每秒随机点击屏幕 100 次持续一小时看游戏会不会闪退。Android 自带的adb shell monkey就是这类工具。五、按执行方式划分术语含义适合场景手工测试人工操作并观察结果手感、画面、新功能体验、探索性测试自动化测试用脚本自动执行并判断结果回归测试、单元测试、性能测试等需要重复执行的测试和自动化测试相关的术语CI持续集成每次提交代码系统自动运行全部测试。测试不通过代码就不能合并。测试脚本自动执行测试步骤的代码比如上面的test_game.py。六、测试用例设计方法测试用例Test Case一条测试的完整描述包括前提条件、操作步骤、输入数据和预期结果。问题是可以输入的值有无数种不可能全部测试。下面这些方法用来用最少的用例发现最多的问题。假设需求是角色名长度必须为 28 个字。1. 等价类划分Equivalence Partitioning把输入分成几类同一类中挑一个代表即可。类别例子预期有效28 个字“勇者小明”4 个字创建成功无效少于 2 个字“明”1 个字提示错误无效多于 8 个字“天下第一无敌勇者小明”10 个字提示错误2. 边界值分析Boundary Value AnalysisBug 特别喜欢出现在边界上比如开发者把写成。所以要专门测试边界附近的值长度123789预期失败成功成功成功成功失败同理等级上限 100 级就要测 99、100、101 级时获得经验会怎样。3. 错误推测Error Guessing凭经验猜测容易出错的地方空名字、全是空格、含表情符号、含 SQL 语句如; DROP TABLE players;--、和已有玩家重名。4. 场景法Scenario Testing按用户的真实使用流程设计用例。游戏例子“玩家组队 → 进入副本 → 中途掉线 → 重新连接 → 继续战斗 → 击败 Boss → 领取奖励”。5. 判定表Decision Table多个条件组合决定结果时把所有组合列出来。是否组队是否 VIP是否周末活动经验倍率否否否1是否否1.2否是是3…………这样就不会漏掉“组队 VIP 周末”这种组合。七、测试相关的开发方法1. TDD测试驱动开发Test-Driven Development先写测试再写代码。流程是红先写一个测试此时功能还没实现测试失败。绿写最少的代码让测试通过。重构在测试保护下优化代码。游戏例子先写assert calc_exp(100, 2) 200再去实现calc_exp函数。2. BDD行为驱动开发Behavior-Driven Development用接近自然语言的方式描述需求让策划、测试和开发都能看懂并且可以直接转成自动化测试功能: 组队经验加成 场景: 组队打怪获得额外经验 假如 玩家“小明”和“小红”组成了队伍 当 小明击败一只基础经验为 100 的史莱姆 那么 小明应获得 120 点经验八、测试中的常见辅助术语术语含义游戏例子Bug / 缺陷程序行为与预期不符打死 Boss 不掉装备复现步骤让 Bug 再次出现的操作步骤“组队后队长在 Boss 剩 1% 血时退队必现”严重级别Bug 的影响程度致命、严重、一般、轻微服务器崩溃是致命文字错别字是轻微Mock模拟对象用假的组件代替真实依赖测试经验计算时用假数据库代替真数据库Stub桩返回固定结果的简易替身让“随机掉落”函数固定返回“屠龙刀”方便测试测试环境专门用于测试的服务器上一篇讲的“测试服”通常用环境变量区分测试数据测试时使用的数据预先准备好的 99 级角色方便测试满级逻辑Mock 的例子fromunittest.mockimportpatchfromgameimportroll_drop# 假设这是一个随机掉落函数deftest_必定掉落屠龙刀():# 把随机数固定为 0.001让结果不再随机withpatch(game.random.random,return_value0.001):assertroll_drop(恶龙)屠龙刀真实的掉落是随机的测试无法确定结果。Mock 把随机数“固定住”测试就可以稳定重复运行。九、上线前后的测试方式术语含义游戏例子灰度发布 / 金丝雀发布新版本先给一小部分用户使用没问题再逐步扩大范围先在“正式三服”开放新副本观察两天没问题再开放到全部服务器A/B 测试把用户分成两组使用不同方案比较数据A 组玩家看到“首充送皮肤”B 组看到“首充送宠物”比较哪组充值率高线上监控上线后持续观察错误率、延迟等指标发现新版本上线后闪退率从 0.1% 升到 2%立即回滚“金丝雀”的名字来源于矿工带金丝雀下井金丝雀对毒气敏感它出现异常矿工就知道要撤离。十、串起来一个版本的完整测试流程以“组队副本”功能为例① 开发写代码同时写单元测试或先写测试即 TDD ↓ ② 提交代码CI 自动运行单元测试和集成测试 ↓ ③ 部署到测试服QA 先做冒烟测试能登录、能进副本吗 ↓ 通过 ④ 系统测试功能测试 用例设计边界值、场景法…… 探索性测试 兼容性测试各种手机 ↓ ⑤ 性能测试负载测试、压力测试、并发测试 ↓ ⑥ 修复 Bug 后执行回归测试确认旧功能没被改坏 ↓ ⑦ 验收测试策划确认 → 内部 Alpha → 玩家 Beta 测试 ↓ ⑧ 灰度发布到一个服 → 线上监控 → 全服上线 ↓ ⑨ 用 A/B 测试优化活动方案速查表分类术语按阶段单元测试、集成测试、系统测试、验收测试Alpha / Beta按是否看代码黑盒测试、白盒测试、灰盒测试、代码覆盖率按内容功能测试性能、负载、压力、并发、稳定性、安全、兼容性、易用性测试按目的冒烟测试、回归测试、探索性测试、猴子测试按执行方式手工测试、自动化测试、CI用例设计等价类划分、边界值分析、错误推测、场景法、判定表开发方法TDD、BDD辅助概念测试用例、断言、Bug、Mock、Stub、测试环境上线相关灰度发布、金丝雀发布、A/B 测试、线上监控一句话总结单元测试保证零件没问题集成测试保证零件能装在一起系统测试保证整台机器能用验收测试保证用户愿意用。冒烟测试决定“值不值得继续测”回归测试保证“改了新的没坏旧的”性能测试保证“人多了也不崩”。