【讨论下吧】情况很糟我很淡定，工作未满三年者慎入

Indisorder · 发表于 2010-12-14 17:59:42

本帖最后由 Indisorder 于 2010-12-14 18:17 编辑

下午和一个认识的朋友聊天说测试工作的时候拌了几句嘴，说的都很激动哈哈。
主要我说了句：“正义可以压倒邪恶，但是问题是他们可以界定什么是正义什么是邪恶”。
我试图描述测试在整个游戏团队所处的角色。
朋友说我总是自以为是。但是我觉得我这句话没什么错的地方
===============性价比================================
早几年的时候我确实觉得测试可以发现BUG然后提交修改和验证通过，
但是现在慢慢发现在游戏中，越来越多的不确定因素让人很难选择是否将其定义为BUG。
从最初的可玩性探索到功能的逻辑性再到性能的稳定性，
越来越多的妥协——也许这不是妥协，而是让步。
想起之前有在帖子里说过：我的技术不是懂什么什么语言会写什么什么脚本，而是能让程序和策划很开心的去修改掉他们的BUG。
做的时间越长越觉得，作为测试员，要学会适可而止。不是所有的BUG都会被修改的。
又得拿BLZ说事儿：从9C到W1更新了多少次了？谁有认真看过更新程序完成后的那些更新内容的？
今年五月左右的时候跟坛子里的喜姐交流时候她有句话我很赞成。
无论是用例，BUG单还是测试报告，都要注重一个“性价比”。
我相信这也是坛子里的老鸟们普遍认同的东西。
在写用例的时候可以用一条用例检查出好几个BUG，这叫性价比高；
BUG单很明确程序或者策划能够迅速的重现或者直接被提供了可能存在的问题原因得以快速修改，这叫性价比高；
测试报告可以告诉大家我们当前进行的工作进度和当前没有解决的问题，团队管理层可以迅速的做出相应的反应来安排和协调人手，这叫性价比高；
我觉得作为合格的测试是对整个团队的开发进度是要有推动作用而不是阻碍作用的。即使是一个BUG也是有它的性价比。

=============有点乱，调整下=======================
也有国外游戏测试圈子的朋友，我记得询问其这类问题的时候，
他直接来了个 not ur game,just play and report..
老外都很达观的，项目不是我负责的，我只是玩它，看看哪儿有问题报告上去。
找到的问题都很主观，一千个观众有一千个哈姆雷特，何况游戏会有上万上十万的在线玩家？
因为你游戏玩儿的多，见的多，跟过的项目组多，技术全面，长的好看，个子高，什么什么的,所以它就是BUG了？有理由么？能重现么？重现的几率是多少？模拟过BUG爆发后的后果么？不带这样玩儿的吧?这不是制定什么规范什么验收标准就能解决的事情了。团队里有人比测试更清楚这些BUG，只是人家有别的事情忙分工不同所以安排测试来专门检查这些东西的。所有的规范和标准应当从客户处来，没有客户？——不至于吧，研发公司的客户不就是运营公司么？运营公司总有能力去做市场调研的吧。靠着自己写的不知道从哪儿改过来的优先级和严重程度定义标准就开始去定义BUG然后丢过去告诉团队的其他成员：看，BUG，改吧。不带这样玩儿的吧？有的公司用测试员每月发现的BUG量来界定员工工资，测试和程序关系恶化的后果多了去了，最后影响项目进度谁也逮不着好。
==============情况很糟我很淡定======================
上面说的很乱，现在冷静下来了，总结下自己的看法，希望是和大家交流，不是我写了一大堆然后后面跟上几条“受教了”“不错”，如果觉得我哪儿不对，请例举和说明原因。我相信我说的这些不一定是对的，但是我个人认为它是有用的。
1，测试的范围
-界面级别的：所有玩家只要不瞎就能看到的内容，如果有BUG，哪怕是一个字写错了，必须改。
-功能级别的：所有玩家只要不是植物人能用到的功能，主要功能实现无错误，流程判断逻辑正确。
-功能交互级别的：别再纠结正交表什么什么的，玩家使用时连带功能关系不超过N层的（N根据功能复杂程度自行定义），必须改。
-功能拓展级别的：所有的应用接口使用边界值填入表现正常，异常数据输入会报错或不会引起功能失败。
-性能要求相关的：这个有服务器配置文档，自己去找程序要。
-安全级别的：这块儿我不熟我没去过运营公司。知道的朋友可以补充下
-兼容性要求相关的：别TM用win95了，别TM的用IE6以下了，知道最近附近电脑城硬件装机和软件安装配置么？知道网吧配置么？知道最近淘汰了那一批硬件么？知道操作系统又出了什么新补丁了么？IE和FIREFOX还有流行用的这些浏览器都现在什么版本常用的哪些？实在不行游戏著作权文档里面有最低配置和推荐配置呢，搞清楚这些你就知道兼容性测试怎么做了
2，用例
不管是黑盒还是白盒，不管是手工还是自动化。
高效设计测试用例，高效执行测试用例。
这个东西水很深大家继续讨论。
3，测试的要求
-所有的用例都必须经过测试内部自评以及策划，程序评审；
-所有的BUG提交时务必能够重现，重点考虑是否是由自己机器配置或者其他因素引起。如果不能重现则要详细描述情况发生时的基本情况。另如果有截图，录像等方式更好。
-所有的测试报告提交准时并且要求条理清楚，少出现什么“大概”“也许”“应该”的词语，格式依次为：
1概述（测试小结）：在XX时间对XX模块采用XX测试方法进行了XXX测试，目的是为了检测XXX在XXX阶段的游戏中是否存在XXX问题。
2测试结果：测试后发现存在如下问题(根据修改难度和影响大小）按照顺序以表格的形式列举。内容包括BUG简述，重现方式，BUG影响和修改优先级（根据修改难度和影响大小以及项目实现进度来界定吧，把别人给你的从网上DOWN下来的破标准丢一边去）
3其他存在的问题：这块随便提建议，写清楚问题现状，有可能产生的问题预估和问题的影响。但是最好写清楚是“建议”。是否采纳不是你说了算。没错是测试驱动开发，没说测试领导开发。
禁止出现的内容：
1，对已定制的项目进度，里程碑的改动。
2，对已实现功能的策划案的改动。
3，对所有你发现但是没有被修改的BUG的腹诽。我相信如果可以你完全可以在BUG的状态上加上“暂不处理”或者“下个版本实现”的字样以便程序员和策划来商讨。
4。少TM来一堆执行了多少多少条用例，发现BUG多少个，要么干脆不写，要么直接写上对功能以及流程图的覆盖率。

灵活点好不好？有空问问看报告的人喜欢什么字体，多大字号也是应该的。

===========================================================
游戏研发，不是我们测试一个部门的事情。
我仍然相信“正义可以压倒邪恶，但是他们可以界定什么是正义什么是邪恶”。

——PS：至少，我很邪恶。

homedw · 发表于 2010-12-14 20:06:50

本帖最后由 homedw 于 2010-12-14 20:07 编辑

bug按照严重级，重现概率，优先级来确定撒。这样就很好咯撒。
话说开发严重优先级和运营不一样。运营可能会把一些bug弄得很高级别。关乎玩家体验的那更是第一位咯。我是发现咯。。能TM坚持3年的都是半神。是吧，你看你25,6了，压力来了吧，想提高收入？游戏测试您就别想咯。

Indisorder · 发表于 2010-12-14 20:21:13

bug按照严重级，重现概率，优先级来确定撒。这样就很好咯撒。
话说开发严重优先级和运营不一样。运营可能 ...
homedw 发表于 2010-12-14 20:06

哈哈恩呢。

星空物语 · 发表于 2010-12-14 22:54:36

呵呵，我现在就是BUG先报MANTIS上再说，严重的、优先级高的就再RTX一下相关程序策划美术，再后面改不改就不是我的事了，有句话么：报不报是你的问题，改不改是他们的问题
回2楼，据说测试主管薪水还不错

Indisorder · 发表于 2010-12-15 09:18:00

先改简单-重要的
再改简单-不重要的
然后集中火力消灭掉复杂-重要的
留下复杂-不重要的大家一起讨论到底改不改

ft1986926 · 发表于 2010-12-16 10:47:27

回复 5# Indisorder
有点不同意见，或者说是疑问
如果是最后消灭复杂-重要的，在消灭的过程中很可能再产生简单-重要，简单-不重要的缺陷，如果是在项目的后期，这样风险很大

寂寞情流感 · 发表于 2010-12-16 11:28:35

严重的问题，能解决的还是尽快解决，如果只放一边，不进行深入分析，程序不会知道是否有那个能力去解决（我们项目中也会遇到程序无法处理的问题，最后只能把那一块CUT掉，不过我们是console game），首要解决的是会导致某个模块无法测试的，然后是会影响测试效率的，比如频繁的CRASH，剩下的就根据MILESTONE的定义，哪些是需要优先解决的。

云层 · 发表于 2010-12-16 11:53:17

写的很好

操操 · 发表于 2010-12-16 11:54:34

我很佩服你

snowjian · 发表于 2010-12-16 12:29:13

测试范围还有设计级别的：界面设计不合理，测试体验不好。某个任务流程设计不合理，某个功能设计有缺陷等等。

summy911 · 发表于 2010-12-16 15:34:40

对于测试报告提交这块，楼主说的很正确，借鉴，有时候开发和运营针对的问题真是不一样；
开发的人会认为概率性的死机等问题排在首位去解决，可站在用户的角度会认为首先映入眼帘的是界面以及使用的人性化，交互是否合理等等，有时候还真的很难界定呢？

maxwell12 · 发表于 2010-12-17 10:19:04

研发测试的工作和运营测试的工作有交集,但着重点确实不同.而且本来就是不同的软件测试阶段.
小乱写的东西,我很同意.游戏业测试工作的现状,不敢说了解,怎么也在行里做了这些年,眼见的东西还是不少.
同意的是小乱上半部的意见,下半部的不用我来发表同意与否,本来就是很好的经验之谈,理应如此.
小乱用邪恶治邪恶只是手段.
前几年网游行业大炼钢铁,仿佛战国时代.现在结果已现.人间正道是沧桑.

shajqiu · 发表于 2010-12-17 10:55:39

测试范围有多少, 测试报告就有多少份.

测试主管来安排工作流程和出报告时间, 负责每一块测试的测试员都应该给出就自己这一块的报告.
报告送出给测试主管, 当然也可以抄送给游戏制作人.
报告的内容我觉得可以是已测试用例为主的概括. 以及详细的执行用例的情况.

通常在周末左右的时间,测试主管把各个领域的测试报告汇总出一份总报告.
报告内容已各个测试范围的统计为主,依照各个领域的测试用例来算出当前版本完成进度.
详细的通过数字来告知游戏制作人当前的版本情况以及这周测试情况.

然后通过各个测试范围的TOP3-5
根据自己经验判断给出这份总报告的 TOP10-15

至于上面喜欢什么字体, 字体大小, 报告风格,报告排版....完全不鸟, 他们是看报告而不是看女人.
排版颜色风格公司有标准就用之即可,无标准那么你就自己创造吧..

写报告,发报告, 判断BUG的严重性,测试用例,孰知项目进度以及下个节点需要达到的要求.....
这些应该是每一个普通测试员应该具备的基本素质吧....?

shajqiu · 发表于 2010-12-17 11:24:17

好吧我是回帖终结者~~

henry425 · 发表于 2010-12-17 14:58:05

受教了~~~~有些事，有些想法，有些概念，在路上，走着走着就偏了~

寂寞情流感 · 发表于 2010-12-20 10:30:38

对于测试报告提交这块，楼主说的很正确，借鉴，有时候开发和运营针对的问题真是不一样；
开发的人会认为概 ...
summy911 发表于 2010-12-16 15:34

死机>UI，就算做为玩家，有比打BOSS打一半死机，上线发现BOSS给人抢了，还掉了极品（传奇类），ROLL团G团，等你上来，东西已经分给别人了，（WOW FB类）还恼火的事吗。

寂寞情流感 · 发表于 2010-12-20 10:34:36

况且UI的风格色调怎么说也是一个主观的问题，这个你说不好看，他说这样挺好。。。这个问题没有标准，所以优先级肯定比不过CRASH

maxwell12 · 发表于 2010-12-20 10:45:44

崩溃的问题有很多种.确实存在某些客户端崩溃的处理等级低的情况.
当然,如果是打BOSS崩溃这种复现几率极大的,处理等级是最高级.
用了一个极端个案,勿怪

Indisorder · 发表于 2010-12-20 12:28:16

况且UI的风格色调怎么说也是一个主观的问题，这个你说不好看，他说这样挺好。。。这个问题没有标准，所以优 ...
寂寞情流感发表于 2010-12-20 10:34

明天就要做验收宣讲了，你突然发现两个可以同时打开功能界面的风格色调不一致
优先级提高到最高。。。

Indisorder · 发表于 2010-12-20 12:30:13

崩溃的问题有很多种.确实存在某些客户端崩溃的处理等级低的情况.
当然,如果是打BOSS崩溃这种复现几率极大的 ...
maxwell12 发表于 2010-12-20 10:45

我也来个极端个案：
客服报告说：玩家XXX报告打BOSS崩溃
测试：硬件环境，软件环境
客服：他说他用的win95
测试：NMB...

		自动登录	找回密码
密码			(注-册)加入51Testing

【讨论下吧】情况很糟我很淡定，工作未满三年者慎入

相关帖子

站长推荐 /1