游戏测试写用例有用么？
我从事游戏测试一年多了，接触了两个项目，之前的那个项目由于不断变更需求和开发周期缩短，导致测试时间也很紧，所以一直都没写过用例。这次接触了新的项目，按道理应该写用例了，不过写了两天后，我突然觉得没什么必要！因为游戏相关的功能太多了。其中的逻辑关联也很复杂。
要写完所有的，着实要花上一些时间。而后还要不断对用例做维护。我开始怀疑为用例花这么多时间值得么？还请有经验的人指点一下。
[ 本帖最后由 yiyistar2001 于 2009-11-23 15:12 编辑 ] 当然有用啦，游戏也是软件的一种吗？测试也是离不开这个基本的测试方式方法的。还是有必要去写的。 只写主要的逻辑,其他的例如大量的资源检查如果你觉得太费时间的话,可以采用随机抽样方式检查。
我以前也很困惑这点,因为要写的实在太多,时间上不允许;但不写用例又怕测漏,只写重要的主干逻辑。如果可能,可以调看一些功能实现的代码、脚本,进行类白盒的方式检查,先看程序逻辑有没有问题,如果没问题,就看相应的资源配置文件。采用抽查的方式,确实有些功能,如大量的物品,如果每个都看的话,确实很费时间的。如果某一个物品出了问题,就检查相应的配置表。
但一些重要功能(逻辑性非常强的)要写用例,恼人的地方就是用例的维护,游戏功能不断的增加,每增加一个功能你就要修改一次用例,但最后你发现修改用例的时间远远占用了你测试的时间,如果真这样的话,就直接给开发人员和策划人员沟通,邮件确认或者通过其他办法。
只写主要的逻辑
感谢楼上，对我有了一些启发。 我都想写测试用例，但是公司qc部很不正规，几乎都不写。而且我写过一两份，虽然感觉有点用，但是浪费时间很多，其他人根本不会看，我也不会看第二遍。发觉至少在公司写用例没啥用处，经常反思用例是否有用（回归和交叉测试肯定有用）、效率是否高……最惨的是主管定下了用例模板，要我们按照它写，还与我觉得有用的写法很不同，郁闷死了。所以偶也一直不写用例了，最多自己画画流程图，在笔记本写写草稿，只要自己看得明白……还有哪位兄台说说用例的用处？
[ 本帖最后由 lukacrusade 于 2009-11-24 12:19 编辑 ] 用例用例，不是给写的人用的，是给用的人用的。:)
有点绕，其实很简单的道理，做一件事有明确的目标，才能评估做这件事的值与不值。
用例的价值：
1、交流以及覆盖率提升。
前提：用例需要被认真评审
目的：通过多个相关人员的集体头脑风暴，补充所未预见到的测试点或学习别人的测试逻辑。
当然写用例的时候也能巩固自己的测试逻辑；
项目测试备份的重要组件。
价值：对个人提升有较大推动
2、降低项目风险系数
前提：公司需要正确评估测试成本
目的：量化测试质量的一种方式，同时可以降低人员变动的风险
价值：仅对项目质量有帮助
3、设计与执行分离
前提：设计用例与执行用例的人不同，一般针对大型项目或多地域性项目
目的：由少量高级而有经验的测试人员设计测试用例，大量初级的测试人员执行用例，优化测试团队的人员配置。
价值：更细化了职位分工，减低测试成本，提升测试质量。目前不少大型公司都在采用这样的方式进行测试管理。
PS：针对中小型公司，不进行项目测试备份，没有严格的测试评审，还是赞成lukacrusade的意见，“自己画画流程图，在笔记本写写草稿”，将更多的时间放到其他应该学习的地方才是硬道理。（流程、工具、编码、业务，测试学无止尽的必杀技。） 顶jackc！
做时间允许的情况下，尽量写测试用例
如果时间不够的情况下可以通过化一些流程图，一些组合图。 同意jackc的说法。
补充一点，写测试用例的同时也在对游戏逻辑、功能进行进一步的熟悉，我们首先拿到的是需求，因为执行策划编写能力的参差不齐，导致的功能需求可读性差异也很大。 lukacrusade,如果你有好的用例编写方法，不妨先写出来，然后给你的主管看。我想既然是好的东西，他没有理由不接受！
takiro说的“执行策划编写能力的参差不齐”，这个我深有体会。如果文档编写有序，语言表达清楚的话，我想即使不编写用例，执行的时候也是很容易的，不过这样的策划团队很难存在。这才导致我们要编写用例来理清思路。 写测试用例和编程序写注释一样
这活不是你一个人干，方便别人使用。
即使是你一个人干，不都写下来，万一你忘了点什么功能覆盖率就差了一部分。 楼主只适合玩儿游戏，不适合做测试。
回复 6# 的帖子
讲的太好了 我也在纠结要不要写用例~~~看了6楼的解释。受益匪浅
页:
[1]
