理解测试业务 03
Understanding the Test Operation /
04 测试设计与管理
Test Design and Management /
05 专项业务测试与实践
Special Testing Project /
神术妙策——质量保障方法和测试案例 理解测试业务
048
知己知彼百战不殆，想要做好测试工作，须先理解测试业务本身。对此，本章会向大家介绍测试
业务中不仅仅包含了基本的测试，同时还需要对用户相关体验负责、并且对整个开发过程进行质
量控制，只有这样才能更好地完成整个测试工作，保障每一次测试的外放质量。
理解测试业务
Understanding the Test Operation 03
之前作为导师参加过新人培训，发现很多新人测试点总结得很不错，但是具体细化到测试用例
上，就会有一大堆问题：或者用例冗余很多，效率不高；或者不具备可执行性或执行起来很麻
烦；或者设计的用例根本无法真正达到测试某个测试点的目的，这些问题对于测试工作的开展
是极其不利的。
我们的测试工作应该追求“快”“准”“狠”：效率要高；目的要明确，不枉不纵；要能切中各
种隐秘Bug。如何能达到测试的“快”“准”“狠”呢，我在多年的工作中积累了以下几点经验
教训，在这里分享给大家，希望可以抛砖引玉。
3 .1.1　要做精准的好“设”手
设计测试用例就好比射箭，一个好的射手，每一箭出去必有明确的目标，不会空放，也绝不会在
同一个目标上浪费多余的箭矢。那我们设计测试用例如何做到这一点呢？相信大家都知道要根据
策划文档来设计测试用例，而要设计精准的测试用例则需要依靠对程序实现的了解。不了解程序
3.1　测试工作“快”“准”“狠”
Understanding the Test Operation 02/03
049
实现写出的用例，很可能会是无的放矢或者浪
费箭矢。
比如一个活动NPC 有一个“领取任务”的选
项发放A、B、C 三种任务，任务的领取条件
有时间、等级、组队人数等要求，我们该如何
测试任务的领取条件呢？方案1 是不论领到什
么任务，我们只要做一次领取条件测试就够了；
方案2 是要针对A、B、C 三种任务都要做一
次领取条件的测试。方案1 和方案2 的测试点
都是一样的，我们在具体执行的时候到底要采
用哪一种方案呢？
拿我所在项目的情况来举例，之前的任务流程
都是程序员手写的，领取限制都调用了同一个
函数，因此采用方案1 就刚刚好，如果采用方
案2 就做了很多无用功，纯属浪费。但是之后
为了避免程序员的重复劳动，引入了任务编辑
器，组队人数、队伍等级、任务过期时间等等
都由策划填写在每个任务中。这个时候就需要
采用方案2，如果采用了方案1，就会产生遗漏，
完全达不到测试的目的。
3 .1.2　不走寻常路，适当“造假”
测试在运营中的产品，常常会觉得“压力山大”。
工作日程排得满满的，而且每个测试内容都是
有最后期限的，因此测试不“快”不行。
前段时间我所在项目的帮派联赛做出了修改。
帮派联赛是不同服务器之间的帮战，每个服务
器选出一个帮派参赛，传输数据到各个比赛服
进行比赛，同时当选的帮派可以获得宝象国特
产的奖励。原先这个特产都是保留到下一届联
赛选拔，后来策划提出了修改，要求未进入决
赛的帮派要立即取消宝象国特产，而进入决赛
的帮派可以继续保留特产直到下一届比赛选出
新帮派参赛。按照传统测试方法，测试这个修
改需要程序员搭建比赛中心服、比赛服、本地
服，然后开启比赛，产生进入决赛和未进入决
赛的情况。别的不说，光搭建服务器，就可能
耗去程序员大半天的时间，而这个修改只是一
条每周维护的内容，每周每个程序员和测试员
手头可能都会有十多条的每周维护，同时还有
数不清的继续制作内容，一般一周内我们分配
给每周维护的时间是2 天，如果用传统的测试
方法，时间必将严重不足。
幸好之前帮派联赛就是我测试的，我知道本地
服务器的选拔结果记录在一个变量中，如果本
服参赛帮派没有进入决赛，这个变量就会清空，
进入决赛则该变量不变直到下一届选拔产生新
的参赛帮派。因此我只要设置这个变量来模拟
是否进入决赛的情况就可，因此这个修改在几
分钟内就搞定了。很多时候，我们要用一些适
当的“造假”来代替常规测试步骤，让测试“快”
一些。
3 .1.3　合理分解测试模块，化繁为简
有的时候我们会接到一个非常复杂的项目，要
验证一个结果，可能要经过很多个步骤，时间
上要跨越好几个阶段。在当初走读mini 项目
用例的时候，就发现有些人的一条用例，测试
步骤有1，2，3，4，5…， 包含了所有达成
这个结果的正常游戏流程。这样做，不能说不
对，但是效率的确不高。有些用例不是执行一
次就够的，之后还可能要多次回归，执行效率
低下可不美。当然在很多情况下，我们可以
借助测试脚本，对于脚本来说1，2，3，4，
5 个步骤或许也只是瞬息的事，但是测试过程
中总有些地方是脚本无法检测的，况且编写脚
本和运行脚本本身都需要开销。因此无论对于
手动测试还是脚本辅助测试，我们都要合理地
分解测试模块，精简测试步骤，做到既“快”
又“准”。
假设我们测试一场玩家之间的PVP 比赛，就
整个比赛可以分为报名、分组、比赛、公布名次、
领奖几个阶段。按照常规方式来说，我们测试
后面的内容，肯定要经历前面的阶段，但是实
神术妙策——质量保障方法和测试案例 理解测试业务
050
际上各个阶段是相互独立的，程序员也会提供
在不同阶段跳跃的指令。在测试活动的主流程
时，我们当然需要完整地跑完整个流程，但是
在针对各个阶段单独测试时，应该好好地利用
这些跳跃阶段的指令。比如在测试比赛的时候，
就不需要真正经历报名和分组两个阶段，一般
这种情况下程序员都会提供加入某个ID 进入
某个阵营的指令，我们只要写脚本加自己常用
的ID 分别进入敌对阵营，然后使用指令跳跃
到比赛阶段。
前面的例子就是合理地精简测试步骤，那么如
何化繁为简呢？就以测试最终名次排列来举
例，我所在项目的比武大会排序的要素依次为
本次比赛积分、玩家等级、玩家总经验、历史
总积分。用来排序的数据中，玩家等级和总经
验是报名时存储下来的，本次比赛的积分和历
史总积分会在比赛时实时更新。所以测试比赛
名次排序可以拆分成3 个测试点：
（1）报名时正确存储玩家等级和玩家总经验；
（2）比赛时正确增加本次比赛积分和历史总
积分；
（3）排序的确是根据本次比赛积分、玩家等级、
玩家总经验、历史总积分进行。
这3 个测试点在流程上是有先后关系的，但是
这3 个测试点也是相互独立的，可以单独测试，
任何一处有Bug，只需要单独复查即可。在确
保测试点1、2 正确的前提下，如果我们要测
试第3 个测试点排序，并不需要经历1、2 阶段，
可以自己造一些数据，然后调用排序函数，检
查排序结果。同样的数据，写脚本来假造比写
脚本真的报名打比赛来产生要简单的多，执行
消耗也更低，而且这个测试脚本完全可以达到
回归第3 个测试点的目的。这样的做法将复杂
的测试点，拆分成相对简单的3 个测试点，同
时也简化了第3 个测试点的测试方法，这便是
化繁为简。
3 .1.4　透过表象，关注本质
一般一开始做测试工作的时候，我们验证测
试结果是否正确，都是通过一些可以直接观
察到的东西。比如我加了一个属性点，看到
我的属性面板上相应参数改变了，这样我就觉
得加点是没有问题的，这样的测试只关注表
象，很容易踩入陷阱，达不到“准”的目的。
就RPG 游戏来说，人物属性的根本作用是用
来战斗的，而不是为了摆在属性面板上好看
的。如果加点改变了属性面板，但是在战斗
中却没有起效，很显然这条测试用例应该是
失败的。
验证结果时越过表现关注本质，除了可以保证
测试质量外，也可以提高测试效率，让测试
“快”起来。多年前我测试一个PVE 的比赛活
动，该活动一天开3 次，每次前3 名有奖励，
本次比赛的奖励如果没有领取，那么到下次比
赛开始就不能再领取了。为了测试本次比赛奖
励下场比赛不能领取，我可费了老鼻子劲了，
先开启一场比赛用A、B、C 决出前3 名；然
后再开启下一场比赛，用D、E、F 获得前3 名，
之后用A、B、C 去领奖，确认无法领到。究其
本质，领奖凭借得是什么呢？无非是一个数据
里记录着A、B、C 是前3 名，其实我只要确
认在每次比赛开始之初，这个数据会被清空就
行了。
当然，我们要求测试透过表象，但是绝不能忽
略表象。还拿前面的加属性举例，在第一次
review 之后，大家检验加点的方法就变成了
验证服务端数据，去战斗中体验，有些人测试
用例的预期结果中“查看属性面板”这一点就
不见了。属性面板是玩家得知自己属性改变最
直接的方式，是加点验证中不可或缺的部分，
测试虽然要究其本质，但是一个表面上都有异
常的产品，无疑是更糟糕的。
Understanding the Test Operation 02/03
051
3 .1.5　耳闻不如眼见，眼见还要深思
大家可以看到，前面的几个测试方法，从根本
上来说就是要结合程序实现来做测试工作。在
平时测试工作中，程序员或主动、或被动多少
都会向QA 介绍自己的代码，否则很多测试工
作是无法展开的。他的介绍一般是如此：XX
路径下的XX 接口，是做XX 用途的，你可以
用来做XX 测试用；或者XX 改动涉及A，B，
C 方面，你可以做1，2，3……操作去验证。
这在一定程度上也算是遵照了结合程序实现来
测试的准则，但是程序员并不是专职的测试人
员，他设计的测试用例是不可能像测试员考虑
得这么周全的；而程序员提供的接口，本身就
是需要被测试的对象，是不能尽信的。
多年前测试一个活动的领奖流程，该奖励每个人
只能领取一次，不能重复领取。我按照正常游戏
流程测试了，领取了一次之后不能再领取了。同
时也用程序员告诉我的接口获取了领奖数据，确
认在一个玩家领取了奖励之后，他的ID 就不在
可领奖的列表里了。按理来说，这样应该万无一
失了，但是还是出现了玩家重复领奖的情况。因
为这个领奖数据是个中层数据，一般改动的都是
内存中的数据，需要主动存盘才可以被存储下来。
程序在有人获得领奖资格时存了档，但是在有人
领过奖清除领奖资格时并没有存档，只改变了内
存中的数据，而他提供的接口获取的也只是内存
中的数据，而不是存档文件中的数据。等到每周
服务器重启之后，可领奖的数据又恢复成存档的
数据，已经领过奖的又可以再次领奖了。由此可
见，了解程序实现不能只靠耳闻，而需要自己眼
见，只是见到还不够，还需要深入的了解透彻，
才能切中隐秘Bug，让测试“狠”起来。
3 .1.6　测试要“灰”起来
前面所讲述的内容，都和程序实现有关，有些
甚至是纯粹对于接口的白盒测试，是不是我们
为了测试的“快”“准”“狠”，就要一心扎
在代码中，走纯“白”路线呢？这显然也是不
对的。
我们测试游戏，不仅要保证其可用性，还要保
证其可玩性。一个游戏，如果运行起来是零
Bug，但是压根就不好玩，完全就违背了设计
出来让人“玩”的这个目的，可以说是离“准”
差了十万八千里。而游戏的可玩性，明显是白
盒测试无法完成的。
即使在可用性测试方面，黑盒测试也是白盒测试
的前提。如果我们针对了一个接口做了大量的测
试，保证这是一个完美的接口，但是游戏中实际
上压根没有用到这个接口，这个接口再完美也是
白搭。我们需要在游戏中走正常的游戏流程，保
证可以正常运行，并且正确的调用到了这个接
口，我们针对接口所做的测试才有意义。
有些时候，黑盒测试比白盒测试更“快”、更
“准”、更“狠”。老的项目组如有些语言中，
调用其他程序文件内中的函数，如果路径不存
在是会报错的，但是如果程序员写错了一个函
数名，是不会报错的，只是等于什么事都没做。
这种Bug，黑盒测试稍微一跑就能发现，如果
要去查询代码来验证的话，反而事倍功半。
无论黑猫、白猫，能抓老鼠的都是好猫。合理
的利用黑盒和白盒这两种手法，让我们的测试
“灰”起来，才能更好地完成测试工作。
3 .1.7　小结
经常有人说，测试时间非常紧，我要“快”，
因此我没有时间去了解程序实现来兼顾“准”
和“狠”。其实磨刀不误砍柴工，你的测试“准”
了，测试量就少了，自然也能达到“快”的目的。
如果测试不够“狠”，遗漏了严重Bug，就算
暂时“快”了，放出之后一堆收尾要收，到头
来还是拖慢了整个项目组的工作进度，得不偿
失。测试工作的“快”“准”“狠”是相辅相
成的，缺一不可。
神术妙策——质量保障方法和测试案例 理解测试业务
052
测试是QA 工作的起点，也是核心，但完美的
测试工作单靠做好功能测试本身是不够的。对
玩家体验的持续关注和思考同样是非常重要的
部分，为什么会有这些问题，QA 为什么要关
注这些，具体应该怎么做，本文希望可以与大
家一同探讨。
事情得从2012 年七夕节说起，那天，自己跟
进项目的客服经理哭笑不得地向策划抱怨，活
动开始后，陆续接到玩家铺天盖地的投诉，引
来客服同学的叫苦不迭。这是怎么回事呢？原
来按照惯例，七夕活动都是异性玩家双人组队
活动，打打小怪，挖挖羽毛，又得经验又增加
友好度，是男女玩家婚前婚后居家旅行必备的
活动，今年的设计大体也不例外，可为什么玩
家就这么不满呢？说起来也许觉得不可思议，
只是因为活动的一句对白！有一场小战斗，如
果战斗失败了，对白是：唉，你们果然还是不
合适。就因为这句对白，许多玩家纷纷投诉，
说自己战斗失败后，惨遭队友mm 抛弃，“她
说我连七夕的战斗都打不过，连GM 都说我
们不合适”。说来也特殊，今年的七夕活动是
新人数值做的，战斗难度比往年略有增加，这
样一种机缘巧合下，“悲剧”就发生了。姑且
不论玩家有借题发挥的嫌疑，作为以幸福美满
为主旋律的七夕活动出现这样的对白，多少有
些不合适。
3.2　测试，但不只是测试——关于测试中用户体验问题的思考
这个活动是我测试的，但是我更多的精力都放
到了功能测试方面，对于这个对白的不合时宜
我当时没有发现，事后我也有些愧疚，同时也
引发了我的思考，这个问题是否是我需要关注
的，这是否是我测试遗漏？
我们是QA——Quality Assurance，不仅需
要对产品的功能进行测试，同时也需要关注产
品的体验。尤其是网络游戏作为一种特殊的产
品，在用户体验方面有着特别的要求。而相信
大家都有体会，用户体验方面的问题无处不在，
大到一个新的系统，小到一条维护的修改。
3 .2.1　用户体验问题从哪儿来
/ 策划思考的有限性
策划文档本身不可能考虑得那么周全，一是时
间不允许，尤其是进度很急的时候，匆忙之中
必然有所遗漏或者考虑不周的地方；二是策划
自身思维方面的问题，策划认为的不一定就是
对的，因此不能一味地接受策划的设计。这方
面可能新人QA 中枪的稍微多一点。
/ 程序制作的“小偷懒”
这点相信大家也见得不少，比如看到对白比较
短，懒得从文章中复制粘贴，直接手动敲上去，
导致错字连连；再比如在实现策划设计的某功
能时，为了图方便，简化设计流程，功能看上
Understanding the Test Operation 02/03
053
去并无太大差异，但是玩家体验就会打折扣。
正是因为有这些问题存在，就要求我们在测试
的时候对游戏体验有更敏锐的感受。然而在我
的测试工作中，对于用户体验方面的问题产生
了一些疑惑，可能大家也曾经产生过类似的疑
问，那就是做到什么程度？
我们作为测试工程师，第一要务就是要保证产
品的功能符合策划的设定，然而对于用户体
验方面的问题，一方面是我们需要投入多少精
力；另一方面，对于已经发现的用户体验方面
的问题，我们是要全部向策划程序提出，并督
促其修改，还是有所取舍。
为什么会想到这个问题呢，主要是基于以下几
个原因。
/ 开发效率
1. 发现问题需要时间
每个系统或者产品的开发周期是有限的，经常
由于种种原因，留给QA 的测试时间更是有限，
在有限的时间内，既要保证产品的功能性，又
要更大限度地发现用户体验方面的问题，这从
一定角度上来看，无疑是有些对立的。为了更
大限度地保证产品的功能，即使测试完成后可
能也需要探索性地跑一跑，这样留给体验的时
间似乎很少了。也许有人会说，在做功能测试
的同时，也是体验游戏的过程，但是当我们专
心地根据测试用例去跑各个功能测试点的时候，
恐怕很少人有精力可以同时兼顾到这个东西玩
起来怎么样。即便这样，我们也可以无意间发
现零零碎碎的几个看似玩起来不舒服的点。
2. 解决问题需要时间
发现用户体验方面的问题，跟发现Bug 类似，
都需要程序去修复，它甚至比Bug 要更烦琐
一些——需要向策划反馈，等待策划给出优化
调整方案，再由程序进行修改，这无疑在时间
上是有不小消耗的。有时候这也会惹来程序的
反感，“这又不是Bug，不用改啦”，“这
样做没事啦，玩家不会觉得不好的”等等。当
然，等到跟策划达成一致后，他们自然会“乖
乖就范。”
3. 似乎与UE 的工作重复
自公司成立用户体验中心（GUX）以来，我
们有了专业进行用户体验测试工作的部门，现
在很多系统在我们测试结束之后，通常会进行
UE 测试，UE 测试找来特定的玩家对这个系
统进行提前体验，通过玩家的直观感受去发现
游戏中不合理，或者设计不完美的地方。这样
看来，我们像是在UE 测试之前进行了一次过
滤，那我们的工作似乎跟UE 测试之间是不是
有重复？
/ 视野的局限性
针对测试过程本身，我们在发现问题这方面也
存在局限性。
1. 测试的局限性
正如上面所说，我们在测试时，以发现系统功
能性的问题为主要目的，投入到用户感受方面
问题的时间和精力都有限。
2. 测试环境的局限性
我们的测试毕竟是开着一堆权限号寂寞地在内
服匆忙奔走着，这跟我们在外服游走于万千玩
家之中的感受是完全不同的。我们看不到其他
很多人的行为集合，体会不到在特定的环境下
跟特定的玩家互动会有怎样的行为和感受，这
种情况下想要幻想着哪里好哪里不好，似乎有
点天马行空。
3. 个体认知的局限性
每个人存在很大的认知差异性。比如对于同一
件新的锦衣，有人会觉得看上去裙子有点短，
有人觉得这样很正常。那么当我们以自己的角
度发现问题，向策划提出时，很有可能得到相
反的意见。有些问题，无关对错，只是大家见
解不同。
/ 评判标准缺失
我们对一个系统的功能测试得如何，评判标准
有很多：比如发现了多少Bug，再比如放出
后有没有Bug 反馈，等等。但是对于游戏体
验方面的问题，没有一个直观的评判标准，现
在可以想到的就是测试过程中，对策划提出的
神术妙策——质量保障方法和测试案例 理解测试业务
054
意见和建议，对于放出后，体验方面反馈不好
的地方，似乎也找不到源头。
既然QA 在用户体验方面的问题上存在这么多
不可控的地方，那是不是我们就可以轻松放下
专注于功能测试呢？答案当然是NO。（不要
拍砖）尽管有着种种客观因素会导致我们没办
法做到尽善尽美，但是我们需要做，而且有很
多可以做。
3 .2.2　我们可以做哪些
/ 职位使命
这点说起来似乎多余了，我们是QA，是产品
的品质保证者，用户体验作为影响游戏品质的
一个非常重要的点，无疑是我们工作的一个不
可抹杀的点。不管是从责任心来看，还是作为
工作成就感的重要组成部分，发现问题再督促
策划和程序解决问题都是我们的工作要务，这
点是毋庸置疑的。
/ 为UE 测试提供一个更完善的版本
UE 测试是找到真实的玩家进行更真实的体
验，但是通常他们只能在内服形成一个小团队
进行游戏体验测试，可以进行的行为和体验会
受到一些客观因素的限制，比如为了方便这些
玩家体验到每个分支，可能会对某些条件进行
调整，以方便他们达到某些玩法的条件，这样
做会导致某些内容可能无法跟外服完全一样，
因此很难保证所有的问题都完全被发现。比如
2012 年《梦幻西游2》的圣诞节活动，有一
个灭火玩法，每到整点会投放20 团火，每隔
10 分钟未被消灭的火会分裂一次，上限为50
团。灭火的方法就是30 个不同的玩家对这团
火扔道具。UE 测试的时候不可能针对这一个
小玩法就进行半个小时，而且为了方便他们体
会到消灭火这一特殊瞬间，调整了扔道具次数
这个参数，这样他们就无法真实地去看到50
团熊熊烈火遍布城市各个角落的盛况。
在测试中持续关注体验问题，不仅能从更完整
的系统内容中去感受，还能帮助UE 提前发现
和规避一些较为明显的体验问题，为UE 测试
提供一个更为完善的版本，使得他们可以在更
为理想的版本中去提供更深的优化建议。
/ 合理权衡，后期迭代
对于我们发现的问题，都可以拿出来跟策划反
馈，大家可以进行讨论，并根据实际情况设置
这些问题的处理方式。对于比较明显、影响很
大的，自然是非改不可；对于那些比较久远的、
历史原因造成的，改动比较大、改起来比较费
时的，可以先跟策划反馈，择日再提维护优化。
有个旧剧情的优化，主要针对切入战斗的方式
进行了调整，以前只能采取快捷键方式暴力切
入，现在可以点击NPC 弹出对话和选项，避
免了一些误操作。但是测试时发现了一个历史
的问题，有的NPC 身上如果有剧情任务，那
么点击他时只会弹出剧情的对话，而没有正常
的功能对话选项，只有完成这个剧情任务，才
能出现正常的功能对话。自己在其他端口试过
修改前的剧情后发现，老的任务就是这样的。
在跟程序确认，这种情况涉及到的NPC 比较
特殊，改起来比较麻烦，而且风险比较大，
此外存在这种问题的NPC 暂时也无法全部确
定。而本次维护的时间已经确定，如果要改这
里时间明显不够，这个问题对于玩家而言，已
经存在很多年了，不属于急需解决的问题，因
此最终选择让策划日后再优化。
/ 各种建议
除了测试过程中以外，在文档分析的时候，如
果我们可以预先发现问题，那么很多问题就可
以扼制在萌芽阶段了。在这个阶段，我们可以
最大限度地发表我们的见解，提出我们的意见
和建议，甚至提出更好的点子。因为此时程序
还没开工，策划可以对我们的意见进行更全面
的思考，并及时回复，此时应该是提出意见的
最好时机。可惜看着文档去想象终归缺乏真实
感，距离程序的实现也有一定差距，因此终究
会有遗漏。
Understanding the Test Operation 02/03
055
对各个系统的持续建议。我们对于游戏体验中发现的各种问题都可以实时提出自己的建议，每
个月会集体向策划提交一次，并会及时收到策划的答复。这个建议过程是一个细水长流，永不
停息的过程。
/ 多角度交流
针对发现的一些问题，如果对于自己的想法也觉得模棱两可不够自信，可以丢到组内QA 群跟
大家分享一下，群众的智慧是无穷的，多一个人的意见可以开拓自己的想法，明确自己的意见。
/ 深入的游戏体验
相信大家对此体会很深了，之前某位同事在有篇分享中比较深入地讨论了这个话题，简而言之
就是，玩游戏是QA 的工作要务，只有深入体验这块游戏产品的特色，了解玩家的特点和行为
习惯，在测试的时候，才能自然地多从一名普通玩家的角度去思考设计的合理性，那么发现问
题也会变得更加轻松和自然，在与策划pk 的时候，也能更具有说服力。
3 .2.3　结束语
以上是我对于QA 在关于游戏用户体验方面问题的一些疑惑，以及自我解惑的过程。尽管很多
内容只是自己的一种诠释，但是明确了这些之后，我觉得在工作中会更加明确和坚定自己的行为。
因为不管怎样，我们都是在努力将产品做到更好。
测试工作中大家比较习惯的做法是提测之后才正式开始测试工作，而提测节点往往比较靠后，这
个时候才介入测试工作的话对代码提测质量很难把握，对测试花费时间也无法预估，因此QA 及
早介入制作流程显得很有必要。本文介绍了产品“代号M”的做法，QA 通过前置控制手段来保
证提测的代码质量，从而达到减少后期修复问题成本的目的，从目前的实践来看效果显著。
3 .3.1　什么是“过程质量控制”
很多同学可能不知道，之前我们的Title 一直是叫QC 的，后来才升级为QA。这一字之差带来
什么样的差别呢，还是QC 的时候我们强调的是保证我们测试过的产品没有问题，通常在待测产
3.3　“防范于未然”——谈谈过程质量控制
神术妙策——质量保障方法和测试案例 理解测试业务
056
品的制作阶段我们是不会过多介入的，前期一般只会做比较基础的策划文档分析工作。后来升级
为QA 之后我们除了保证后期产品的测试质量之外，同时整个过程也会通过一些控制手段来保证
交付给我们测试的产品质量，从而达到减少后期修复问题成本的目的。控制手段可以是多种多样的，
比如原来的策划文档分析，代码审查机制，基础导表检查，用户体验测试等。如图3-1 是QC 和
QA 的对比示意图。
图3-1　QC 和QA 的差别
图中的过程质量控制就是我们内部对各种控制手段的统一叫法，我们有专门的工作小组每隔半年对
所有小组进行过程质量评估，评估方式是随机抽取各小组内的QA 同学和程序同学进行问卷访谈，问
卷内容都是由工作小组确定下来适用于所有小组的公共考察项。如图3-2 为不同类型考察项截图。
图3-2　过程质量评估考察项举例
从几年来多次打分情况来看，有几个产品的成绩尤为突出，其中产品“代号M”（以下沿用此叫
法）是多次夺冠的明星产品。那么该产品是如何取得如此成绩的呢？有哪些经验可以给大家借鉴
呢？下面我们采访了产品“代号M”的QA，以下根据他们的介绍进行了整理，希望给其他项目
带来一些启发。
3 .3.2　标杆项目“代号M”的经验分享
根据我们多年的经验，总结了以下几点影响玩法制作质量的重要因素：
Understanding the Test Operation 02/03
057
● 各个环节相关人员的拖延；
● 各个环节交付的内容不完善；
● 各种暗改；
● 不断重复踩坑；
● 新人业务不熟悉……
下面就针对以上几点来展开介绍我们对应的控制手段。
/ 拖延
玩法制作包含很多环节，图3-3 是基础流程的介绍图：
图3-3　游戏玩法制作基础流程
在玩法制作开工前，我们会确定好外放时间表，那么其中任何一个环节的拖延就会相应压缩剩余
环节的时间，QA 作为最下游，那么我们绝对是拖延的最终受害者。针对拖延影响特别大的环节
我们进行了相应的“锁定”措施：
1. 策划提交文档时间锁定
以往很多策划都是文档没有出来就先提交制作单，然后文档迟迟没有提交，长期挂单，程序、
QA 要浪费精力去跟进这个文档提交的进度。我们现在是策划只有产出了文档才让其在当周提交
制作单，然后周三前保证文档提交给QA 进行分析，如果延时由QA 主管收集反馈到主策。
2. QA 进行文档分析时间锁定
和文档提交分析一样，QA 回复分析也经常有拖延，导致程序等不到分析结果就偷偷开工，可能
造成实现和最终文档不一致。因此这边也要求QA 周三收到文档后，周五前必须产出分析意见，
QA 主管也会定时确定所有在提文档的分析进度。
3. 周维护表单提交锁定
任何玩法的修改都是要通过周维护版本进行外放，假设周版本需求不能尽早确定，那么肯定会造
成周六、周日加班严重，发布前Patch 也会频繁重打，增加版本外放的风险。我们现在的做法就
是周一的周会确定所有下周二维护时所有的玩法需求，以往通过各策划人工建单的方式改成了主
策统一录入需求进行批量建单，然后周二上午前版本进行锁定，任何人无法在Redmine 平台上
直接创建下周二的周维护表单，如果需要追加需求，必须向主策或PM 申请帮忙改为下周二的版
本号。这样就有效地保证了所有周维护需求有充足的制作时间。
神术妙策——质量保障方法和测试案例 理解测试业务
058
4. Patch 重打锁定
我们是周二进行维护的，之前一直都是周一进
行回归及Patch 发布，经常出现晚上10 点之
后才发布完Patch 的情况，加班情况很严重。
后来就将这个模拟回归时间提前到周五，尽量
保证发布版本周一上班前达到稳定，然后周一
值日生有充足的时间进行每周例行的自动脚本
回归、美术资源提交验证、静态代码检查结果
确认、配置表变更确认等事务。周一需要重打
Patch 那么也必须和主策进行申请。有同学
可能会觉得这样做会压缩版本制作的时间，但
是实际上基于前一个周维护表单提交锁定的设
定，整体的制作时间还是很有保障的，如果实
在无法本周完成的周维护内容也是可以申请推
迟到下周进行外放的。
/ 不完善
1. 策划文档标准制定
之前策划文档提交分析前没有统一的标准，很
多策划都是编辑了玩法主流程后就提交分析，
然后QA 分析期间又在那里补充各种设置，比
如外测时间、全服时间、奖励编号、任务编号
等等，但实际上这些设置同样应该进行分析。
比如外测时间，如果策划定成周末肯定会有问
题，奖励编号等程序写完代码才补充很容易出
现调用时机出错的情况。因此我们后面专门制
定了这些标准并和主策进行了确认，如果达不
到这个标准会向QA 主管反馈打回文档。
2. 测试需求标准制定
除了策划，以前程序也很习惯将局部功能完成后
就提交测试，然后QA 测试过程又在不断地码
剩下的功能，这样带来的后果是QA 测试完的
内容很容易被程序不小心在实现后面的内容时改
掉，diff 情况很不方便查看每次diff 修正了哪些
问题，增大了潜在的风险。因此我们和主程序确
定了提交测试需求的标准，首先必须保证所有功
能完善才提交测试，然后还确定了所有需要说明
的情况，比如测试指令、代码覆盖率、自测情况
说明等，以保证测试顺利，如图3-4 所示。
图3-4　测试需求标准示例
/ 暗改
1. 策划修改数值监控
之前总出现QA 在周维护模拟服上进行回归测
试，然后策划自己跑测发现有些数值不合理想
要进行微调，再然后就直接编辑却又忘了告知
QA 进行相应回归的情况。因此我们在周五模
拟服回归的时候就进行锁表操作，确保版本稳
定后策划的修改我们能够及时进行确认。
2. 程序放出热更新监控
代码外放之后出现紧急问题需要进行热更新
时，程序也经常匆忙改完稍微自测下就直接放
出去，这就导致多次出现引入更严重Bug 的
情况。因此我们加上热更新监控，凡是程序的
热更新操作均会实时提醒所有程序及QA，QA
测试完毕后才进行外放。
/ 重复踩坑
1. 历史Bug 收集归类
对以往的外放Bug 进行归类整理，有两大好
处：一是方便分析确认是否存在框架或规则设
计不当从而进行调整，二是将容易踩坑的耦合
测试点抽取出来补充checklist 防止后面的同
学踩坑。以往Bug 记录都是靠跟进QA 手工
录入Excel，这样很容易漏填。后来我们锁定
了所有Bug 外放的入口：周维护及热更新，
比如周维护进行Bug 修正时，表单一定会有【修
正】关键字，然后QA 平台首先会通知对应
QA 进行Bug 原因录入；同样热更新放出时也
会通知QA 进行Bug 原因录入，然后Bug 管
Understanding the Test Operation 02/03
059
理平台就会自动定时收集以上的数据，再根据
填写的模块进行分类，方便大家查看。
2. 建立Checklist 模版库
“代号M”项目非常成熟，有很多丰富的玩法，
各种玩法规则之间避免不了存在着耦合，如果
只关注自己的玩法很容易踩坑。比如新增了同
袍系统，有个成就叫“人不如故”，条件是连
续和同一个id 结成同袍关系3 次，但是没有考
虑玩家转靓号的情况，同个玩家转了靓号之后
就当作不同玩家了，这明显不合理，后来进行
了修正，兼容转靓号情况。在有了前面完善的
Bug 收集之后，我们就能把类似这种容易耦合
的内容提取出来放到checklist 平台中，测试
的时候大家可以对照checklist 进行最后一遍
确认。
/ 新人易犯错
每年一大波新同学涌入是我们最激动也是最惆
怅的时候，激动的是有人来一起分担各种体力
活了，惆怅的是新同学经验不足更容易犯一些
低级错误，于是我们想到一些调和这个矛盾的
办法，目前看来成效很不错：
1. 测试用例走读
新人同学的游戏经验及测试经验都比较欠缺，
因此测试用例遗漏会比较多。凡是制作类的任
务，新人的测试用例必须进行测试用例走读，
这样方便其他同学一起审核用例的完整性。
2. 新人任务riview
分配给新人的制作任务必须由前辈进行
review，老人会侧重于策划文档分析、主要测
试点跑测、其他测试外事项提醒跟进。
3. 老人开展各种内部沙龙
我们这边QA 的组内培训做的比较好的，因此
出于资源共享考虑，我们QA 举办的沙龙也面
向策划、程序新人开放，新人们可以互相学习
讨论，也为接下来的合作打下良好的基础（见
图3-5）。
图3-5　针对新人举办公共沙龙
3 .3.3　总结
以上通过介绍“代号M”的主要控制手段给大
家展示了QA 如何进行产品质量控制完善的思
路，要保证这些手段的顺利执行离不开以下几
个条件：
（1）QA 首先要保证基础测试工作的质量，才
能争取到过程质量控制主导权。不要出现QA
做出一大堆高大上的工具，外放各种低级Bug
又频出的情况。
（2）项目主要负责人有质量控制意识。过程
质量控制一定会占用策划、程序一些时间来进
行配合执行，只要负责人认可才能有效执行。
（3）QA 要根据自己项目作出适合可行的建
议，让策划、程序能愉快配合执行。
（4）QA 内部需要有给力的技术支持人员进行
工具开发。
QA 成功推动了过程质量控制之后，带来最直
观的效益是提交过来的测试内容有了基础保
障，可以更顺利地开展测试啦！相信大家看
完以上介绍之后对过程质量控制都有一定认
识，到时可以结合自己产品的实际情况多多
发掘需要进行控制的节点，从根本上提高产
品整体质量！