51Testing软件测试论坛

标题: 【讨论下吧】情况很糟我很淡定，工作未满三年者慎入 [打印本页]

作者: Indisorder 时间: 2010-12-14 17:59
标题: 【讨论下吧】情况很糟我很淡定，工作未满三年者慎入
本帖最后由 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
本帖最后由 homedw 于 2010-12-14 20:07 编辑

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

作者: Indisorder 时间: 2010-12-14 20:21

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

哈哈恩呢。

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

作者: Indisorder 时间: 2010-12-15 09:18
先改简单-重要的
再改简单-不重要的
然后集中火力消灭掉复杂-重要的
留下复杂-不重要的大家一起讨论到底改不改

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

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

作者: 云层 时间: 2010-12-16 11:53
写的很好

作者: 操操 时间: 2010-12-16 11:54
我很佩服你

作者: snowjian 时间: 2010-12-16 12:29
测试范围还有设计级别的：界面设计不合理，测试体验不好。某个任务流程设计不合理，某个功能设计有缺陷等等。

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

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

作者: shajqiu 时间: 2010-12-17 10:55
测试范围有多少, 测试报告就有多少份.

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

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

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

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

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

作者: shajqiu 时间: 2010-12-17 11:24
好吧我是回帖终结者~~

作者: henry425 时间: 2010-12-17 14:58
受教了~~~~有些事，有些想法，有些概念，在路上，走着走着就偏了~

作者: 寂寞情流感 时间: 2010-12-20 10:30

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

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

作者: 寂寞情流感 时间: 2010-12-20 10:34
况且UI的风格色调怎么说也是一个主观的问题，这个你说不好看，他说这样挺好。。。这个问题没有标准，所以优先级肯定比不过CRASH

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

作者: Indisorder 时间: 2010-12-20 12:28

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

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

作者: Indisorder 时间: 2010-12-20 12:30

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

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

作者: Indisorder 时间: 2010-12-20 12:36
最近听到业界大批裁员的信息，貌似与我无关。。。
每年的这时候都会因为项目失败才开始洗牌，那群只会用EXCEL排序的HR们又蛋疼了哈哈。

作者: maxwell12 时间: 2010-12-20 13:08
前几年大冒进
现在到了洗牌的时候了

作者: Indisorder 时间: 2010-12-20 13:11
恩。。看来当时选择小成本小制作非主流是正确的。哈哈

作者: homedw 时间: 2010-12-20 13:36
我们公司还行,我也很稳定...每天都可以有时间自学.就是急需找个能用于工作当中的技术学学. 现在学per很少用的到.这只能算个储备吧.领导一天也不管我,有活的时候好好做就对咯.相对新人轻松一些.但是压力也大啊...

另: 我觉得测试员真应该多看点用户体验的东西(经验老道也就不需要看咯),界面设计啥的,反正有的功能用起不爽,或者你自己认为还有更好的解决方法, 提一个[建议]bug也不为过,爱修补修,反正老子尽力了.可能别人(一般是开发)看着你这种行为会很蛋疼.其实这是对自己项目充满"爱" 的表现啊!我就提过类似的建议,修鸟!哇哈哈

作者: maxwell12 时间: 2010-12-20 13:45
建议学习游戏制作过程.不知道怎么做的,怎么测?

作者: 韦冬梅 时间: 2010-12-20 15:27
有没有做能源管理测试的童靴？做测试几年了，没有长进，现在跳槽到能源管理做测试，希望能跟大家交流下。

作者: Indisorder 时间: 2010-12-20 18:19
恩，现在我就被提取出去做些边角功能的策划设计，他妹子的，不得清闲。
唯一指望这个项目赶紧结束好好补下脚本和数据库相关的东西。

作者: homedw 时间: 2010-12-21 09:38
你都成多面手咯....LOL 羡慕哟...我还在学习脚本...数据库只会查询而已....

作者: maxwell12 时间: 2010-12-21 11:31
数据库查询学的好,测试中也能帮上忙

作者: 星空物语 时间: 2010-12-21 20:36
回复 21# Indisorder

我是亲身经历了，走-光了，测试员就我一个了……
不过你为什么说HR要蛋疼呢？

作者: 星空物语 时间: 2010-12-21 20:38

我就提过类似的建议,修鸟!哇哈哈
homedw 发表于 2010-12-20 13:36

我提的不知道修多少了- -
第一年也和你一样挺兴奋，往后就蛋定多了

作者: Indisorder 时间: 2010-12-22 09:15

回复 Indisorder

我是亲身经历了，走-光了，测试员就我一个了……
不过你为什么说HR要蛋疼呢？
星空物语发表于 2010-12-21 20:36

HR一般都是把简历做成表格然后根据学历什么的排序。。。非常之脑残。。。

作者: searing 时间: 2010-12-22 16:53
我认为测试的出路，根本的出路在于自身的修养和技术水平上。
因为测试的理想状态肯定是将游戏所有不合理和不正确的地方找出，而不正确很容易界定，而不合理就要一个人的知识面和技术水平了，而且表达能力和说服能力也很重要，就像当年希特勒能将那么多德国人陷入狂热一样，很多人以为单纯的希特勒是邪恶的，但是我们更进一步的了解后才明白，希特勒是一位博览群书、才华横溢的人。同样的，如果测试想让自己的工作更顺利也必须提高自己的学识和技术水平。
同样也出现了问题，如果用相同的学识和技术是不是当初自己选择了策划或者程序要比现在强好多？起码工资肯定强。其实很多测试到后来都是这么想的。
但是我没有这么想，因为我才是真正的兴趣使然，而且我们的目标应该更高远，而不是更低。
这里我也要奉劝那些想通过测试赚钱的人了，如果你只想赚钱，那么请尽早收手吧，不然你会后悔的。

作者: searing 时间: 2010-12-22 16:54
我认为测试的出路，根本的出路在于自身的修养和技术水平上。
因为测试的理想状态肯定是将游戏所有不合理和不正确的地方找出，而不正确很容易界定，而不合理就要一个人的知识面和技术水平了，而且表达能力和说服能力也很重要，就像当年希特勒能将那么多德国人陷入狂热一样，很多人以为单纯的希特勒是邪恶的，但是我们更进一步的了解后才明白，希特勒是一位博览群书、才华横溢的人。同样的，如果测试想让自己的工作更顺利也必须提高自己的学识和技术水平。
同样也出现了问题，如果用相同的学识和技术是不是当初自己选择了策划或者程序要比现在强好多？起码工资肯定强。其实很多测试到后来都是这么想的。
但是我没有这么想，因为我才是真正的兴趣使然，而且我们的目标应该更高远，而不是更低。
这里我也要奉劝那些想通过测试赚钱的人了，如果你只想赚钱，那么请尽早收手吧，不然你会后悔的。

作者: searing 时间: 2010-12-22 16:56
额，是不是我浏览器出问题了？有版主没？把上边的删了。。

作者: Indisorder 时间: 2010-12-22 17:33
赚钱不好么，呵呵，同意你的观点，头像也不错，就是截的不全，加勒比海盗我还是看了的。

作者: 星空物语 时间: 2010-12-22 23:02

HR一般都是把简历做成表格然后根据学历什么的排序。。。非常之脑残。。。
Indisorder 发表于 2010-12-22 09:15

我们是末位淘了好多人，然后前景不妙自己走了一些人，跟HR毫无关系

作者: homedw 时间: 2010-12-22 23:33
楼上是哪里的游戏公司哦。。还有末位淘汰。。看新闻9游裁员很多人哇？神兵玄奇。。。我最喜欢的港式漫画。结果进去玩到30级我就不玩咯。。。觉得没啥意思还黑累，结果最后看说注册人数150万，后来演化成在线只有数千人。。。。简直就是个悲剧啊！

作者: Indisorder 时间: 2010-12-23 11:02
星空我没说淘汰，我说的是招聘的时候

作者: hacker14 时间: 2011-2-17 11:17
真难，对于高性价比的测试用例，我就是设计不出来。

该如何是好呢

作者: lanfeng 时间: 2011-2-21 20:19

我也来个极端个案：
客服报告说：玩家XXX报告打BOSS崩溃
测试：硬件环境，软件环境
客服：他说他用的w ...
Indisorder 发表于 2010-12-20 12:30

有的测试还会说：“SB，他怎么不用win32”

作者: jiazurongyu 时间: 2011-5-12 12:49
哎..测试要在开始就规避一些问题,使以后工作更加好做

作者: jiazurongyu 时间: 2011-5-12 12:50
客服报告说：玩家XXX报告打BOSS崩溃
测试：硬件环境，软件环境
客服：他说他用的win95
测试：NMB...

首先这个是客服的问题吧,这类bug都不应该报上来.win95如何支持现在游戏的

作者: jiazurongyu 时间: 2011-5-12 12:51
缺陷管理中,当前项目的关键点可以把bug级别略+1级
非关键点，按项目紧急度略减
但不包含 A类bug，B类也要有适当办法，如加保护等

作者: jiazurongyu 时间: 2011-5-12 12:52
测试的技术不是懂什么什么语言会写什么什么脚本，而是能让程序和策划很开心的去修改掉他们的BUG。
这句话并不可取，个人见解

作者: wytanmark09 时间: 2011-6-8 12:15
回复 45# jiazurongyu
能进游戏不能打BOSS玩家纠结啊直接改成95不支持么..

作者: coollee 时间: 2012-1-16 18:40
第一：界定一个BUG主要取决于开发文档描述&操作习惯，用户体验感，常理等。但只要开发文档描述的详尽，那么确定这是不是一个BUG就会很容易。
第二：职业操守。作为一名测试特别是游戏测试，测试的出发点，立场，测试的职业操守是不能丢的，凡事有原则和底线，违背其一自己都过去，要是两天统统违背那么也就不配做一名测试。
第三：莫要忽略沟通技巧，（描述问题的能力；协调解决问题的能力）
第四：领导的能力，有些问题下面的人很难解决，那么就要清楚各自的领导，说明问题再行解决。
第五：流程的建立：每个公司都有各自的项目流程，但建立的流程是否完善，时候有人遵守，不遵守之后是否有相应的惩罚制度，也是相当的中。
第六：自身能力素质的提高：你要是个高手不管白盒黑盒你总能发现别人发现不了的问题，发现的问题你总是能找到重新规律，就是有理有据。那我相信没有哪个白痴能否掉这个问题。

测试不好做，但要记住，产品的质量是任何产品的根本，开发要是NB那就用不到测试了，所有根本还是自身的问题。正视你自己，正视的你的工作。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)