51Testing软件测试论坛

标题: 游戏聊天系统测试案例 [打印本页]

作者: jaychousong 时间: 2010-7-26 11:28
标题: 游戏聊天系统测试案例
有没有游戏聊天系统测试的案例，需要注意些什么东西，求各位大大解答！！！

作者: zyl57218655 时间: 2010-7-26 11:36
等待大虾~~~

作者: cncnily 时间: 2010-7-26 11:45
成品的肯定没有，都是内部文件
按照策划案写，加入写测试用例的基本方法就可以了
其实这些都是经验，写多了就好了，谁开始都不会写
http://bbs.51testing.com/thread-276993-1-1.html

[ 本帖最后由 cncnily 于 2010-7-26 11:46 编辑 ]

作者: Aimbot 时间: 2010-7-26 13:30
基于： who已什么样的方式（遍历一下聊天频道）发给who（遍历一下玩家间关系）写一个model-base的功能性测试计划。特别注意下谁不应该收到这样的测试用例，还有就是过一遍敏感字，要和谐么。。。。
然后，服务器端性能测试咯。

作者: Indisorder 时间: 2010-7-26 15:03
嗯，就是测对象(who) 在什么时间(time) 以什么样的方式(how)发送(sepnd)了一个什么样类型(type)的信息(message)，这个信息通过什么样的路径(LAN?WAN?TCP/IP?SMTP?)传送到另一个对象(another who？them?all?)，多久(how long)能收到?收到的信息(message)以什么样的形式显示(what happened when got the message)，收到的信息是否完整(message type,message contents).并且能储存(saved)和存储多久

英语真烦，以后不用英文了，看着就不舒服..

作者: cncnily 时间: 2010-7-26 15:33
这个是聊天系统测试用例？你们这么写吗。。。

作者: Indisorder 时间: 2010-7-26 17:25
思路，英语是用来装13的，哈哈

作者: cncnily 时间: 2010-7-26 17:29
这思路写的。。。人家本来就不会写，你再这么说更没思路了
要循序渐进

作者: maxwell12 时间: 2010-7-26 21:13
不，我觉得他们说的很好。思路超清晰。
可以作为共同的测试用例基础。
然后补充各家的一些区别。
例如防刷屏的那些，同样发言不能重复发送，聊天频道发言间隔。
屏蔽字库大家手头的内容应该是一样的。测一下屏蔽情况。

作者: cncnily 时间: 2010-7-27 09:19
策划案中肯定规定每个频道发言间隔的

作者: Indisorder 时间: 2010-7-27 09:29
if without 策划案...或者策划案根本就没考虑你所考虑的情况的时候
根据自己的经验对相关内容的测试内容的增修删改就很必要了
所以自己心里要有一个测试的大致方向
比如说一个功能模块
测试需要自己做出一个判断
1这个功能模块是一个什么样的功能模块
2这个功能模块由哪些部分组成，每个部分单独实现了什么功能
3这些单独的部分是如何协作，运作时这些部分又是如何互相联系的
4整个功能模块实现功能的力度如何，速度如何？
5有引起它发生异常的因素吗?
6它功能正常的情况下，有外在的破坏因素吗?
照着策划案写我觉得是没问题，可完全照着策划案来写，你的思路就是策划的思路，而不是测试的思路。
不怕没得测，就怕测不完。

作者: cncnily 时间: 2010-7-27 09:36
恩说到这确实哈居然有人说过公司没有策划案
哎以后测试策划可以合并了

作者: Aimbot 时间: 2010-7-27 09:54
给你来个有图

在3年前的一个项目里：我们用了一个玩家关系模型来避免可能的组合爆炸，遍历这个模型后得到了50+组玩家关系，测试用例是2000+。

[attach]63977[/attach]

作者: cncnily 时间: 2010-7-27 10:09
条数很正常只不过这些都是自动跑的还是手动跑的？

作者: Aimbot 时间: 2010-7-27 10:32
废话，当然是手动啦。游戏项目做UI自动化测试不是找死啊。。。。

作者: Indisorder 时间: 2010-7-27 10:36

原帖由 cncnily 于 2010-7-27 09:36 发表
恩说到这确实哈居然有人说过公司没有策划案
哎以后测试策划可以合并了

版主是上人，大公司大场面大制作...哈哈
不过现在确实有很多策划是从测试转过去的

作者: Indisorder 时间: 2010-7-27 10:43
那个关系模型表很牛掰，要是真是全手工完成的就更牛掰了，但是主要还是那个关系模型表牛掰。
我接触的项目，没有做到那么全，也就仅仅依靠行为交涉表和错误猜测，案例大致也在1000条以上。
要达到自动化来做UI方面的确实不太现实，所以也是比较头疼的事情。所以才把重点放在主要功能实现上。
而且像聊天这样的功能，在内网环境下测试出来的结果和在外网以及加压情况下完全不同....曾经杯具过一次，深有体会....牵扯到玩家交互的东西.....切记要加压....

作者: cncnily 时间: 2010-7-27 10:52
测来测去还是要黑盒哎
这工作量加了几次班啊呵呵

作者: Indisorder 时间: 2010-7-27 11:02
没加过班。。。有偷懒的办法。。。既然是玩家交互使用的东西。。。。
丢给玩家自己去研究好了。。。。只要在大方向上把控以下不让BUG淹没开发就是了

这个说的玩家自己去研究。。说的是降低该聊天系统的测试优先级，在确保不泄密的前提下
玩家参与到项目的测试来。。这个资源嘛。。400到500真人同时在线我还是有那么些资源的。。。

作者: Aimbot 时间: 2010-7-27 11:33
请注意我的后半句话：游戏项目做UI自动化测试不是找死啊。。。。
普通一个3A级游戏项目，UI从设计到实现被全部删光推倒重来个3，4次很正常。一个UI程序员每天身上背个7，8百个bug才叫UI程序员。

开发个UI自动化测试工具需要的资源也许不会太多，但是维护这个工具绝对是噩梦。这种ROI超低的买卖是打死也不能干的。。。

作者: cncnily 时间: 2010-7-27 11:38
我们UI测试一般在后期中间他们爱怎么删怎么删爱怎么改怎么改最终商业版的时候才审核

作者: Indisorder 时间: 2010-7-27 13:40
确实要等到最终商业版才最终审核，不同的游戏（不同的投资理念）决定不同的测试策略。

作者: Aimbot 时间: 2010-7-27 22:28
楼上2个不专业了吧。先丫测design啊，会点脚本语言的话直接给丫prototype出来啊。菜单是能进行代码级测试的最简单一层了，就不能趁这个反正怎么搞都无所谓的阶段研究研究？就当练练逻辑性也好啊。

作者: cncnily 时间: 2010-7-28 09:24
以目前行业发展状况和技术水平来讲我确实不专业也不知道专业的标准是什么如果LS高手知道的话那我要请教咯。
不过我只知道只要保证产品质量就OK 当然要看可以保证产品质量在什么水平。
我想我们初衷都是一样的吧。

作者: 数电线杆子 时间: 2010-11-17 17:27
聊天系统测试，也还是得看策划需求才能分析测试点的，不同的游戏聊天系统差别还是很大的，用什么语言开发的，聊天服务器相关的，聊天系统也分很多的，世界聊天，国家聊天，联盟联天，场景聊天，组队聊天，等等，不同的游戏有不同的需求，才能分析不同的测试点，稳定性和确定聊天系统压力测试方案。如：有些游戏世界聊天是收费或扣道具的，有些游戏世界聊天是要达到多少等级后才能使用的，有些游戏为了防止刷屏有聊天间隔时间限制等等。。。。

作者: jiazurongyu 时间: 2011-5-18 17:31
聊天功能还是系统，完整的话还要验证信息量对服务器的压力。
比如聊天长度 50字节，发51个显示50个。还是输出超过50就无法输入，用边界吧
49位置用中文汉字去冲

作者: michealv 时间: 2011-5-24 16:30
这个矩阵很大啊……

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