|
本帖最后由 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:至少,我很邪恶。 |
|