|
|
文/张敬峰
满眼bug难，一把辛酸泪。都云测试苦，谁解其中味？
当大家都在对一款S级产品侃侃而谈时，当大家激动着欢呼月流水破亿时，当大家赞美游戏的设计多么牛x时，一群测试工程师还在默默的测试着即将上线的功能。在缤纷闪耀的舞台上很难看到他们的面孔，在寂静的深夜却总是留下他们疲倦的背影。
记得笔者曾经跟心存困惑的测试兄弟们说过，在成功的产品面前，有些人是台前英雄，有些人是幕后英雄，而我们测试人员则是幕后的幕后英雄。各种辛酸，如鱼饮水，冷暖自知。
一款产品的研发与运营的成功，有很多因素促成，比如设计层面的、IP层面的、运营层面的等等，然而容易被大家忽视的也时常被大家忽视的一个层面则是来自于产品质量。毫无疑问的是，质量关乎产品的生死成败。
那么在一款S级产品成功研发与运营的背后，为了在紧迫的节奏下保障产品质量，测试人员又面临着怎样的挑战与困境呢？笔者结合实际S级项目经验，就以下几个层面跟各位同仁一起谈一谈在研发与运营过程中测试人员面临的各种挑战和困境。
挑战一
版本管理
“这个bug怎么没测出来啊？”
“啊，这个怎么上线了，我x，怎么不经过测试就直接把代码提到线上了？”
这样的对话，是不是大家都经历过呢？有时候面对一个bug或严重事故时，开发人员会感到很委屈，没人告诉我不能提交啊？或者已经被混乱的分支搞得头昏眼花，一不留神就提上去了。测试人员也感到很委屈，根本不知道代码已经提到线上了，而这个功能还没测试或没测试完毕。
虽然大家都感到很委屈，但是事故已经发生了，怎么办？
项目上线运营之后，可能同时存在N个开发分支，混乱的提交代码导致的bug可能会成为导致线上事故的主要因素。而出了问题首要被问责的往往是测试人员，面对这个困局，只能严格做好代码分支管理和提交规范，以及最后的提交内容检查。从逻辑上来讲，既然我们不应该相信开发人员写的代码，那么我们也没理由相信他们的提交操作。
为此我们尝试在某些项目做了一个excel格式的检查列表，如下图：
证据确凿，签字画押，办法是土了一些，貌似还挺管用～
挑战二
Bug与事故管理
由于我们每个个体都存在着认知局限性，所以对同一件事物，有的人看到的是一个点，有的人看到的是一条线，有的人看到的是一张平面，有的人却看到了三维立体图形。这个理论对于bug与事故也是成立的，我们提出的一条条bug并非是冰冷的无生命的存在，如果大家用心挖掘的话，这些bug数据能为我们提供非常多的理论和决策支持。
很多人认为Bug提出了并被修复了就行了，为什么还要花精力去对这些数据进行数据挖掘呢？有那时间也许我能多发现几个bug了。如果大家还是这样的思维，那么可能你还停留在体力劳动层面，还没有把测试工作上升到脑力劳动层面。这样做的根本原因是为了解决下面的2个问题：
1.我们总是习惯在同一个地方犯错，不断的踩同样的坑
2.精细化的项目管理需要真实数据支撑
举2个小例子，来说明下bug和事故挖掘能为我们提供哪些数据支持。
例子一：bug数据有利于我们统计出游戏中哪个模块容易出现问题，见下图
例子二：bug数据有利于我们统计出开发人员的技术稳定性，见下图
可提取的数据非常多，这里就不一一列举，这些数据可以应用到项目下一阶段的版本中，为我们测试工作提供参考，或者为其它项目提供一些数据参考。
挑战三
人员数量与管理的困境
笔者曾经在不同的场合多次被问过，一个手游项目中配备多少个测试人员比较合适？其实这个问题没有标准答案的，跟每个项目的做事风格，游戏的类型，团队的协同效率等都有关系，很难说出一个完美的答案。
不过根据笔者经历过的多个项目经验而言，每2个开发人员配备1个测试人员是相对合理的。在2:1的配比下，开发和测试能够很好的协同工作，发挥出的效率相对较高，当然这个不是绝对的，比例稍微差异也不大影响，但是如果差别较大，无论是多配还是少配置，都会一定程度影响整个项目的工作效率。
另一个经常被问到的问题是，项目现在很挣钱，但是还是偶尔会出现一些线上事故，我们能不能多加几个测试来降低事故率？相信这个状况不仅仅是测试的同仁遇到过，可能项目里各个职能团队都会遇到过这个问题。一个项目就像一头饕餮巨兽，总是想法设法的吞噬可争取到的尽可能多的资源，尤其是在挣钱的阶段，这本身并没有问题，问题是人多了，真的能解决问题么？
对于这个问题，笔者觉得每个团队的负责人都需要深刻的思考一下。有没有可能加人会导致反作用？人多了，问题没解决，反而线上出现更多的事故。笔者认为是否应该加人应该考虑两方面因素：导致线上出事故的本质和测试组长的管理能力。
如果线上事故不是因为人少测不过来导致的，而是其他一些因素比如项目流程导致的，那么我们随便加人可能导致更加严重的后果，因为尝试解决问题的方向错了。
如果确实因为测试人员过少导致线上事故频发，我们优先考虑的问题可能并不是增加人手，而是目前的这个测试组长是否有能力带领更大的团队。古人云：一将无能，累死三军。如果组长能力够的话，果断加人就能让问题立竿见影，如果组长能力不够，可能首先要做的是寻觅一个能力更高的组长。
挑战四
测试覆盖度的挑战
在上面挑战一中我们谈到的胡乱提交代码导致的线上事故，这种我们可以看作是与测试关联不大的外部因素，这里我们继续谈谈可能导致线上事故的内因，那就是测试不充分，出现盲点。
每当发布版本时，我们是不是都怀着忐忑的心情？我们很难预料这个版本是不是还有未发现的bug，曾经有些时刻，当鼠标点下去的那一刹那，我的心是颤抖的。为了让自己对版本更有信心，更心安理得一些，我和我的同事们在某些测试关键节点做了一些改良，总结了一下，大概有下面几个方面：
1.尽早的开始测试。甚至不必等一个功能完全开发完毕，只要某些部分是大概完整的，我们就可以开始测了，这样能尽早的暴露出缺陷和漏洞，为后续的工作争取更多的时间。
2.可选项：交叉测试。交叉测试其实是老生常谈了，大家都知道交叉测试能避免很多测试的盲点。但在一个手游项目，尤其是快速迭代的项目，功能从开发到上线可能只有一两天时间，如果固守交叉测试的思维，时间根本不允许。所以交叉测试变成了一个可选项，版本紧迫时就果断放弃，时间充裕时则一定进行。
3.bug和事故分享。每周定期进行本周bug和事故会议，花一点时间，让大家了解到工作中存在的不足，吸取以往的经验并给大家一个警醒作用。
4.必选项：版本上线前作checklist检查。迫于版本迭代速度，很多功能可能连完整跑一遍测试用例都变的不太可能，而游戏各个功能之间藕合度又比较高，很难预料一个功能的修改是不是会导致别的功能出bug。面对这种两难的境况，我们怎么办才能保证测试覆盖度？通过实际验证，版本上线前集中精力做全功能的checklist不失为一个恰当的选择。通过checklist我们几乎可以覆盖到游戏的所有功能，虽然精细度不够，但可以就每个功能的核心点都做一遍检查，在保证版本进度的基础上确保核心点不出问题。既然不能大而全，我们就小而精。
额外说一点亡羊补牢的题外话，版本发布后，并非万事大吉，还需要我们继续观察一段时间，及时了解玩家反馈。如果发现问题，尽量第一时间解决。
挑战五
与策划程序不得不说的故事
策划、程序员与测试在传说中是基情四射的小伙伴，如同铁三角般在一起快乐的生活，然而残忍的现实总是让他们之间充满争吵，纷纷扰扰，剪不断，理还乱。说好的策马奔腾共享人世繁华呢？一声长叹，其实我只想静静。
很多时候剑拔弩张并不是要分出个胜负，而是找个机会宣泄下长久积压的压力，读书人的事，辩论一下能叫吵架么？
其实大家真正关心的核心只有一个，那就是时间。测试抱怨程序代码写的慢，留给测试的时间太少。程序员抱怨策划的需求总是变来变去，立字据都没用。策划则委屈的说你们懂个x，我能不变么，我又不是神，况且boss一个眼神已经把我秒了。。。
于是这个抱怨怪圈一直在时空中旋转着，直到某个英雄驾着七彩祥云降落凡间。他带给我们一件管理利器：进度管理。良好的进度管理能很大程度上帮助我们控制住项目研发这匹脱缰野马，让各个环节的时间安排更加科学合理，减少各个环节的抱怨。
那么我们实际是怎么做的呢？有鉴于google sheet被墙，我们只能用相对低端一些的excel+svn来解决决这个问题。当然可能还存在其它好用的工具，我们并没有花太多精力在工具本身上，因其非关键因素，关键的是整个项目要有进度管理的思维并认同这种思维。无图无真相，小伙伴们请看下图（项目实际进度管理表，虽非假语村言，真名还是隐去，请小伙伴们见谅）：
自从进度管理做好后，策划、程序员与测试又可以一起快乐的玩耍了～
挑战六
资源利用与协调
对于一名测试工程师，发现缺陷，保证负责的工作不出问题，在笔者看来也仅仅能够打60分，勉勉强强及格。要想获得优秀并非易事，意味着我们要付出很多额外的时间和精力去做好各种衔接工作。这样的事情比较多而杂，比如帮客服同事确认用户的反馈，与平台部门的人合作接入sdk，每天核对项目进度，配合运营同事验证活动，为其它部门提供一些测试数据等等。
为了把这些看似额外的工作做好，单靠我们自身的力量显然是不够的，要善于利用和协调资源，借外力为己用。为了做好资源协调与利用，我们大概可以从3个方向进行：
1.工具方向：如何在杂乱的事情中理出头绪并避免遗忘？一些在线云笔记，貌似是不错的选择，做完划勾，简单轻松。为了避免广告的嫌疑，这里就不直接提供名字了。还有其他的为了方便工作的工具也可以多网上搜索一些，工欲善其事，必先利其器。
2.思路方向：在工作中，可能我们无法搞定所有的事情，我们要学会借力，任何领导和协作部门都可以看作是可利用的资源。要学会向他们争取支持，拓展可使用资源的来源，从而完成一些不可能的任务。
3.态度方向：保持微笑着与其他部门协调合作。无论事情能不能搞定，保持一个良好的态度，总会有更多的机会，也能为以后的合作打下良好的基础，毕竟不是一锤子买卖。
挑战七
责任与担当
测试在整个项目中起着一个承上启下的作用，上衔研发环节，下接运营环节。做好了锦上添花，做不好怨声载道。
测试也是项目事故的首要被问责人，除了勇敢的承担之外，更重要的是要总结分析每一次事故，沉淀经验教训，争取下一次不再犯同样的错误。如果不做总结反思，还不如不承担。如果一个人连承担责任的勇气都没有的话，那么也意味着这个人丧失了继续前进的机会。我是测试，我为测试代言，我们都有一颗勇敢的心。
测试要简单可以做的很简单，点点游戏就可以了。要做的复杂也可很复杂，可以帮程序员做单元测试，可以做服务端压力测试，可以做客户端性能测试，可以做sdk测试等等。就看我们能够承担多大的责任，能够挑战怎样的困境，能否超越昨天的自我。
面对无尽的黑夜，回首昨日的荣耀，我们将继续奋力前行，毕竟，我们的征途是星辰大海！
作者简介
张敬峰，计算机专业科班出身，但代码能力是个战5渣。早年是光荣的钢铁工人，后来抱着对游戏的无限热爱，投身游戏圈，入坑较深。长期在项目一线做测试和测试管理工作，参与过《刀剑英雄》、《大决战》、《亚特兰蒂斯之龙》、手游版《英雄无敌》等众多项目的质量保证过程。
via：游戏葡萄
声明：游资网登载此文出于传递信息之目的，绝不意味着游资网赞同其观点或证实其描述。
|
|
发表于 2015-12-2 16:29:37
