51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3403|回复: 12
打印 上一主题 下一主题

游戏测试写用例有用么?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-11-23 15:10:24 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
我从事游戏测试一年多了,接触了两个项目,之前的那个项目由于不断变更需求和开发周期缩短,导致测试时间也很紧,所以一直都没写过用例。
这次接触了新的项目,按道理应该写用例了,不过写了两天后,我突然觉得没什么必要!因为游戏相关的功能太多了。其中的逻辑关联也很复杂。
要写完所有的,着实要花上一些时间。而后还要不断对用例做维护。我开始怀疑为用例花这么多时间值得么?还请有经验的人指点一下。

[ 本帖最后由 yiyistar2001 于 2009-11-23 15:12 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-11-23 15:17:05 | 只看该作者
当然有用啦,游戏也是软件的一种吗?测试也是离不开这个基本的测试方式方法的。还是有必要去写的。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-11-23 16:59:32 | 只看该作者
只写主要的逻辑,其他的例如大量的资源检查如果你觉得太费时间的话,可以采用随机抽样方式检查。
我以前也很困惑这点,因为要写的实在太多,时间上不允许;但不写用例又怕测漏,只写重要的主干逻辑。如果可能,可以调看一些功能实现的代码、脚本,进行类白盒的方式检查,先看程序逻辑有没有问题,如果没问题,就看相应的资源配置文件。采用抽查的方式,确实有些功能,如大量的物品,如果每个都看的话,确实很费时间的。如果某一个物品出了问题,就检查相应的配置表。
但一些重要功能(逻辑性非常强的)要写用例,恼人的地方就是用例的维护,游戏功能不断的增加,每增加一个功能你就要修改一次用例,但最后你发现修改用例的时间远远占用了你测试的时间,如果真这样的话,就直接给开发人员和策划人员沟通,邮件确认或者通过其他办法。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2009-11-24 10:08:24 | 只看该作者

只写主要的逻辑

感谢楼上,对我有了一些启发。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-11-24 12:13:04 | 只看该作者
我都想写测试用例,但是公司qc部很不正规,几乎都不写。而且我写过一两份,虽然感觉有点用,但是浪费时间很多,其他人根本不会看,我也不会看第二遍。发觉至少在公司写用例没啥用处,经常反思用例是否有用(回归和交叉测试肯定有用)、效率是否高……最惨的是主管定下了用例模板,要我们按照它写,还与我觉得有用的写法很不同,郁闷死了。所以偶也一直不写用例了,最多自己画画流程图,在笔记本写写草稿,只要自己看得明白……
   还有哪位兄台说说用例的用处?

[ 本帖最后由 lukacrusade 于 2009-11-24 12:19 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2009-11-24 14:04:58 | 只看该作者
用例用例,不是给写的人用的,是给用的人用的。

有点绕,其实很简单的道理,做一件事有明确的目标,才能评估做这件事的值与不值。
用例的价值:
1、交流以及覆盖率提升。
前提:用例需要被认真评审
目的:通过多个相关人员的集体头脑风暴,补充所未预见到的测试点或学习别人的测试逻辑。
当然写用例的时候也能巩固自己的测试逻辑;
项目测试备份的重要组件。
价值:对个人提升有较大推动

2、降低项目风险系数
前提:公司需要正确评估测试成本
目的:量化测试质量的一种方式,同时可以降低人员变动的风险
价值:仅对项目质量有帮助

3、设计与执行分离
前提:设计用例与执行用例的人不同,一般针对大型项目或多地域性项目
目的:由少量高级而有经验的测试人员设计测试用例,大量初级的测试人员执行用例,优化测试团队的人员配置。
价值:更细化了职位分工,减低测试成本,提升测试质量。目前不少大型公司都在采用这样的方式进行测试管理。

PS:针对中小型公司,不进行项目测试备份,没有严格的测试评审,还是赞成lukacrusade的意见,“自己画画流程图,在笔记本写写草稿”,将更多的时间放到其他应该学习的地方才是硬道理。(流程、工具、编码、业务,测试学无止尽的必杀技。)
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2009-11-24 21:18:12 | 只看该作者
顶jackc!

做时间允许的情况下,尽量写测试用例
如果时间不够的情况下可以通过化一些流程图,一些组合图。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2009-11-24 22:46:01 | 只看该作者
同意jackc的说法。
补充一点,写测试用例的同时也在对游戏逻辑、功能进行进一步的熟悉,我们首先拿到的是需求,因为执行策划编写能力的参差不齐,导致的功能需求可读性差异也很大。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
 楼主| 发表于 2009-11-25 10:03:47 | 只看该作者
lukacrusade,如果你有好的用例编写方法,不妨先写出来,然后给你的主管看。我想既然是好的东西,他没有理由不接受!

takiro说的“执行策划编写能力的参差不齐”,这个我深有体会。如果文档编写有序,语言表达清楚的话,我想即使不编写用例,执行的时候也是很容易的,不过这样的策划团队很难存在。这才导致我们要编写用例来理清思路。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2009-11-27 11:18:49 | 只看该作者
写测试用例和编程序写注释一样
这活不是你一个人干,方便别人使用。
即使是你一个人干,不都写下来,万一你忘了点什么功能覆盖率就差了一部分。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2009-12-1 11:19:34 | 只看该作者
楼主只适合玩儿游戏,不适合做测试。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2009-12-22 11:38:33 | 只看该作者

回复 6# 的帖子

讲的太好了
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2010-1-26 17:19:26 | 只看该作者
我也在纠结要不要写用例~~~看了6楼的解释。受益匪浅
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-12 20:50 , Processed in 0.071735 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表