本期我们有幸邀到了剑3的李清来继续谈剑3的测试开发。
测试：幕后的一根支柱
测试在游戏开发甚至在整个软件开发行业当中，似乎是处于一种很不显眼的位置，比如：
“这个游戏真好玩，里面的设定太有趣了。”（夸策划的）
“这个游戏里的人物好漂亮啊。”（夸美术的）
“这个游戏速度真快，在我的破机器上都能跑。”（夸程序员的）
但很少听说夸测试的话。而且如果出了问题，似乎也是策划、美术和程序挨骂，不大会把测试单独抓出来批斗。比如：
“什么弱智任务啊～”（策划的错）
“画面真烂！”（美术的错）
“垃圾客户端，天天崩。”（程序员的错）
对于外界来说，测试好像是透明的，似乎不存在。而测试所做的工作也不是用户能直接能展示给用户能看到的。但从游戏开发的整个过程来看，测试又是很重要的，因为测试关注的是产品的质量。产品在投入市场之前，必须先过测试这道关。就好像汽车一样，我想没人想要买一辆刚拼装起来没有经过任何检测的车。
所以我说，测试是游戏开发幕后的一根支柱。
测试的两条腿：功能测试与测试开发
那么如何测试游戏呢？直接进入游戏去，使用每一个功能，看是不是符合设计是个好办法，而且是个很重要的办法。这种测试我们称作功能测试。从理论上来说，功能测试可以发现所有的问题：产品就摆在那里，只要彻底地使用产品，不管多么隐蔽的问题，都可以找到。但实际上，这是行不通的。
首先，游戏中有海量的数据，不可能单纯靠人来验证。比如游戏中各种道具的购买价格不应该是负数，如果要用人眼来检查一遍，费时费力不说，还很容易看花眼，导致漏掉问题。
其次，功能测试很难覆盖到一些测试环境。比如网络游戏中大量玩家同时登录，服务器是不是能够正常处理？如果要靠真实的玩家来同时登录的话，成本太高了，而且还不一定能实现出来。
所以，单纯的功能测试走起来会很辛苦，还需要另一条腿：测试开发。
测试开发的职能：
一、代码审查
程序员编写出代码，经过编译，成为可以在机器上执行的程序。代码之于可执行程序，就相当于零配件和汽车的关系。对于汽车来说，只检查整车而不检查零配件是不可思议的。所以程序员写出的代码也要经过检查。这部分工作就落在测试开发的身上了。
检查代码有很多办法，其中之一就是代码审查，简言之，就是不运行源代码，只是检查代码本身。这里主要是检查源代码的格式是不是符合规范，有没有低级错误，异常情况是不是做了处理，程序流程有没有问题等等。
之所以要做这件事，是因为这个方法实施起来比较简单，而且直接深入到源代码内部，可以尽早发现一些问题。而这时发现的问题，是最容易修改的，也就是说，为bug付出的代价最小。另外，还可以让测试开发熟悉源代码，为进一步的测试打好基础。
二、编写测试代码
代码审查也不是万能的，有很大的局限。比如代码审查的效率还是比较低。最重要的一点，代码审查阶段，代码是没有运行起来的。那么代码的实际运行情况是不是和预想的相符就不好说了。所以测试开发还要想办法让代码运行起来，看一段代码的实际运行表现是不是正确的。这时就要编写测试代码了。
比如针对一个函数，测试开发要检查这个函数是不是能够完成该做的工作，对于不同的参数组合是不是能够正确处理，是不是做了不该做的事情（多干活也是不对的）等等。为了能够彻底检查这个函数的功能，测试开发就要编写一系列专门针对测试这个函数的代码，故意制造各种各样的环境让这个函数运行，然后分析函数的运行结果。这样经过一系列测试代码的检验，我们对这个函数就会有信心。
再比如，我们想要测试大量客户端同时链接服务器的情况。实际找很多玩家来要花费很多功夫，效率及其低下。而如果等到对外测试，刚开始开放服务器时，又太晚了，而且还不是随时碰到这种情况。这时测试开发就派上用场了。可以写一段程序，专门模拟大量并发的情况，虽然忽略了很多因素，但从中还是可以分析出来一些瓶颈所在。
编写测试代码还有个好处，就是可以经常运行测试。程序员每天都在修改代码，如果可以很快运行测试的话，就可以提早发现问题。功能测试就不太容易做到这一点。因为有时开发提交的代码可能在界面上还不能表现出来，而且即时有表现，功能测试也会要安排测试计划，可能不能够即时测试到修改过的部分。
三、编写测试工具
比如前面提到的检查道具出售价格，靠肉眼费时费力又不可靠，成本也高。其实像这种大量重复性的劳动完全可以交给机器去做，让测试开发写个工具，再多的道具价格也能很快检查完，而且不容易出问题。
再比如我们希望一些重复性的工作能够每天定时运行，可Windows的计划程序局限性比较大，比方说有很多台机器的话，给每台机器上都布置相同的任务就很麻烦，而且也不容易知道当前各个机器上正在运行哪些任务。所以我们就写了一个管理任务的工具，只通过一台机器，就可以给其它机器上布置任务，而且可以随时观察每个任务的执行情况。
结语
∩能保证剑网3的稳定。
