很久没敲键盘写些东西了,对于我这个"整理控"来说一直遵循着"好记性不如烂笔头"(咋这么不押韵呢?)的原则,工作中整理的感悟汇成笔记垒起来已有我大腿高了.当然你可以质疑我悲催的身高.
废话少说,这次配文主要是回馈一些朋友所言,看到用MindManager画的图希望有一些解释文字能够阅读起来更清晰明了.其实MM的一些便签和附注都对各引线已做过一些解释.可下载这个工具打开看原mmap格式的文稿看下.
--------------------------
初涉游戏行业的QA人员应具备什么技能?
传统意义的概念,很多人将QA即质量保证工作当作一份简单的测试来看,更简之而言便是无止境的玩游戏而已.不可否认的是,测试是QA的核心所在,他是整个质保工作的砥柱支撑.我们要将这份工作做好变需要掌握一定的测试技术.当然高强度的"玩"游戏也是其中手段之一.正因为如此,很多刚毕业的学生将踏入游戏圈的第一份工作选择了游戏测试.然而他们心中却向往着游戏策划这个很崇高的职业.这也是我面试很多没有工作经验或较少工作经验应聘者所想的.作为他们的面试官,我是很理解他们的心情.我见过很多一直在这份行业走下去并做的很不错的职业工程师,也有部分最后走上管理层,当然相当一部分也选择了转行,无论哪条路,我们都应该有一份沉着的积淀,没有踏实的跳板,哪个岗位都是岌岌可危.
我们要将游戏测试做到得心应手,并有足够手段查找出程序设计漏洞以至于对整个版本质量可控.不可少的就要思考"测试"是否有方法和思路可循呢?
具体的层次关系参见MM图吧.这里抽取几个点说明一下.
游戏测试思路
功能导向.就游戏中"背包"而言.我们可以假想游戏的世界和现实世界在某种程度是近似的.游戏内的背包可以想象成我们日常生活的口袋一样.我们要检测背包是否达到期望功能,简单而言也就是想知道"我们的口袋是否能装的了东西,并且在我想取出的时候可以随时取出,不会丢失.".为了这个功能.我们就可以粗浅的画一些思维图.以功能为基点发散导向.如:
1 我们能装什么物品呢?---这条路走向不同物品的兼容,数量等.
2 我身上能有最多能有几个口袋?几种口袋呢?---考虑背包栏的分类,扩容道具功能等.
3 我的口袋安全吗?是否能跟随我翻山越岭持之以恒呢?---考虑不同场景下,不同时间段(上下线,服务器维护前后)物品的存留
.......这里不做详解了.
其他的如流程导向,即区别在于更多以操作为指引,如"好友"系统,这个系统的问题一般暴漏在客户端做各种操作所引发,其功能其实很简单也就是添加成功可交互即可.所以选择这种思路比较适合.人人交互,这里的人人是一个概念,主要关注点是复杂交互类的模块,如"组队""副本"系统.可以考虑A和B,C...等多种单位之间独自行为,整体行为等对组队功能的影响,所以这个是较其他比较复杂的.(一定要衍生到一个独立A的概念,即独立游戏场景行为至单PC帐号角色行为)
其他的一些测试思路这里不多讲了,毕竟这是个尴尬的话题.早初寻一本游戏测试的书籍着实不容易,即便现在有了基本也是概念居多,应用于实际效率不尽人意.曾阅过一本外文相关书籍,奈何英文水平有限,打着有道硬是在本上记录完全,最终取之可用之处十之有三罢,加之几年的工作心得而总结出一些.所以实际中的应用体会才是基础.故希望大伙能自己总结.
游戏测试用例
用例的编写是每个测试人员必备的基本功.所以实际当中我见过的用例模板也是五花八门各有千秋.其中最主要的矛盾集中在两种方式上.1 以独立模块为索引 2 以操作流程为索引.其各种利弊在MM图上标明,不多言.其实我认为测试用例设计的初衷是为了帮助查找更广更深入的问题.一味的追求格式的统一有方便部门整体工作的优势,但强调过头即也不值当.只要我们遵循几点:1 实操人员看的懂,看的省事.提出补充可方便更新且不打乱主题结构. 2 编写人员要互相更换不同类型模块,并互相审核. 3 格式应根据测试模块可作细微调整. 4 有独立突出地方存放特殊用例即只有在具体测试过程中才能发现和能发现价值bug的用例. 5 用例的从诞生到最后确认过程,应跟随项目的变化,策划案的变化,周遭其他因素的变化而变化,从理念上排除尽早确定已做好测试准备的想法.实际情况中,用例和策划案确定一样,是相对而非绝对.所以至少应经过5轮真正意义上的修改包括审核.
游戏白盒测试
相关游戏的白盒测试.最多体现在项目研发初期游戏架构和逻辑模块开发阶段.对于此类测试工作没必要退避三舍,不必有非有程序能力才可做的想法.当然在实操过程中积极的学习是很关键的,这个比在大学里学到的更实用和快速.一些白盒测试工具我认为实际应用价值不是很大.所以从架构而言我们可以关注游戏各组件的协同工作关系,从中查找瓶颈,如修改数据库数据,单独加压崩溃聊天服务器而查看区域服务器情况,断开通信服务器查看协议包的处理情况等等.从逻辑模块初期测试而言,我们可以在非完整客户端的环境下改变模块某些变量参数来校验功能模块的整体功能,同时考虑各接口应用,调用的关系.避免模块最终的互相功能影响.
我们掌握了基本游戏测试技能后,我们何去何从?
1 职业经理人
2 职业工程师
这只是个方向.是否能做好,取决于你的业务面是否宽广,所以无论你已经是部门主管,经理,总监或是资深测试工程师.发挥部门价值才能突显自我价值是不变的道理.而通俗的多做事是最好的办法.有几个业务是可以考虑的.
游戏评测
这也是一个比较悲催的职业,当然是就国内而言.我们现在的游戏对bug都可笑之放过何况可玩性.毕竟这是个策划一家独大的时代.对于就"反策划"而产生的工作实际当中难免是道理站得住脚,实操无人支持的尴尬境地.想要改变这个现状只能是上面的那个经理总监或资深工程师以利弊关系和专业的报告和BOSS交涉.仁者见仁吧,这里说明评测的几个基点.
1 将结论前置,开头突出关键点
2 观点鲜明,数据论证,切忌个人观点描述冗余
3 考虑整体,好的独立设计未必适合
4 考虑游戏生存的大环境
5 分析现象发生原因.切忌一味描述现象
6 明确自身定位,切忌使用高端玩家身份
7 切忌将个人习惯引导评测思路
8 避免以点盖面,细小问题单一处理,不影响整体评价.并保持真实,认真对待
9 “二八定律”利用20%时间发现问题,80时间引用数据论证和解决方案提供
10 要提出分期处理建议.以实际进度落实不同解决方式.
还要注意的就是针对的部门和人群.对策划,运营,市场,玩家,BOSS有具体的报告关键点.把握好这些才能输出一份合理专业的报告,并将转为实操.
其他测试
除了游戏测试意外.公司必然有其他业务,如工具,平台开发等等.既然是QA部门,就应该经质量意识贯穿整个公司行为中,所以只要用到的东西都必须经过QA之手,此也对QA的专业多面性提出的要求.
QA在公司其他职能?
记得一点,你该做什么事情不要老倚仗别人告诉你.将部门放在公司发展的高度想问题.就会发现你可以在产出部门设立各种标准,可以给人事考核部门提供相应考核的数据等等.只要你做这个行业,就应该不断问自己,如果你是BOSS,你如何让公司快速高效有价值的发展,哪些是你能以部门之力能做到的?
---------------------
一篇不成熟的文章,一点不成熟的见解!
欢迎批评更正.
韩振华_120204
Download:
快盘:http://www.kuaipan.cn/index.php?ac=file&oid=23429351542358582
快传:http://kuai.xunlei.com/d/XNNFJMWWTOGR
--------------------
新浪博客(原文地址):http://blog.sina.com.cn/s/blog_4920b0bd0100yldz.html
新浪微博:http://weibo.com/hanzhenhuahzh
腾讯博客:http://t.qq.com/hanzhenhuahzh
欢迎交流!
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |