游戏测试用例设计实例

发表于:2011-10-25 11:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Mr.曾    来源:51Testing软件测试博客

  前段时间写过一篇博文,关于用例设计的,最近有个朋友问游戏中玩家与Npc交易的用例怎么写,拖了好久了,今天有空赶紧写下来呵呵。

  很久没玩游戏了也没接触过游戏测试,只能单独从设计用例的角度来思考,目的只是通过这次实例来分享下我个人设计用例的思路,希望对大家有所帮助,因此,实例比较简单并没有深入去挖掘,只是介绍的一种方法。

  题目:编写玩家与Npc交易的测试用例

  在最初拿到这个题目时,会不会和茫然,觉得无从下手,那我们第一个应该想到的不是怎么去测,而是如何理清自己的思路,这里我介绍一种方法,被很多人忽视掉的方法。图表辅助设计。

  首先我们确定,在玩家与Npc交易的过程中的一个流程是什么样的,那么我们不如来画个图,帮助我们理清思路。

  根据这幅图,我们能够确定一条基础流,选择商品—选择数量—确定交易—交易成功

  自然有了基础流就还有备选流(这个用例设计方法名:场景分析法)

  备选流1:选择商品—选择数量—商品不足—选择数量—确定交易

  备选流2:选择商品—选择数量—空间不足—选择商品......

  备选流3:选择商品—选择数量—确定交易—余额不足—选择商品......

  到这里为止,你有4条测试用例了,而在整个操作中商品的数量是需要你进行输入的,你不妨将输入进行分类,运用等价类划分和边界值,假设你得到的结果是可输入以下内容:

  a、整数   b、小数    c、特殊符号   d、非数字符号

  这种情况,你可以试试将等价类和场景结合使用,执行场景用例时,按照等价类划分的内容来进行输入,原本用例条数为4*4=16条,结合一下,依然还是4条。

  另外,仔细将整个过程中的功能点罗列出来,诸如,加减数量,选择商品,取消选择,确认,取消,关闭,商品总价计算,金钱扣除,将这些功能点,与你的场景进行结合使用,原本几十条的用例,进行组合排序后,会极大的缩水。

  顺便也提一下,如果你了解因果图决策表或者正交,那你还可以在排序中加入这些方法的设计思想,最后达到尽可能少的用例覆盖尽可能多的面积,最后在在分析时也能很直观的知道哪些功能点覆盖了,哪些功能点遗漏了。

  对于图表辅助设计用例,可以尝试运用UML,其实UML图很多对于我们设计用例都有用处,只是现在用的人极少而已,测试员在设计用例时,第一件要做的事就是保持自己的思维清晰,(当然这里说的是常规的测试,诸如free test,以及敏捷测试对用例要求不高的可以忽视。)思维清晰大的来说包括2类,1类是流程清晰,除了业务流程,还有操作流程,可以理解为时序,另1类这是功能点分布,要清楚的知道包括哪些功能点,这些功能点的功能实现等,最好是将其进行罗列,这类文档也许不会和缺陷报告等测试文档进行归档,但却能极好的帮助我们设计测试用例。

版权声明:本文出自 Mr.曾 的51Testing软件测试博客:http://www.51testing.com/?434556

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • onlyxuxu
    2011-10-26 11:07:39

    我觉得可以分类为业务逻辑上的用例和基本输入情况的用例显得更为清晰,业务逻辑上的用例也就是你分析的那四条流,基本输入情况的用例也就是你分析的4中种输入情况

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号