前段时间写过一篇博文,关于用例设计的,近有个朋友问游戏中玩家与Npc交易的用例怎么写,拖了好久了,有空赶紧写下来呵呵。
  很久没玩游戏了也没接触过游戏测试,只能单独从设计用例的角度来思考,目的只是通过这次实例来分享下我个人设计用例的思路,希望对大家有所帮助,因此,实例比较简单并没有深入去挖掘,只是介绍的一种方法。
  题目:编写玩家与Npc交易的测试用例
  在初拿到这个题目时,会不会和茫然,觉得无从下手,那我们第一个应该想到的不是怎么去测,而是如何理清自己的思路,这里我介绍一种方法,被很多人忽视掉的方法。图表辅助设计。
  首先我们确定,在玩家与Npc交易的过程中的一个流程是什么样的,那么我们不如来画个图,帮助我们理清思路。

  根据这幅图,我们能够确定一条基础流,选择商品—选择数量—确定交易—交易成功
  自然有了基础流还有备选流(这个用例设计方法名:场景分析法)
  备选流1:选择商品—选择数量—商品不足—选择数量—确定交易
  备选流2:选择商品—选择数量—空间不足—选择商品......
  备选流3:选择商品—选择数量—确定交易—余额不足—选择商品......
  到这里为止,你有4条测试用例了,而在整个操作中商品的数量是需要你进行输入的,你不妨将输入进行分类,运用等价类划分和边界值,假设你得到的结果是可输入以下内容:
  a、整数   b、小数    c、特殊符号   d、非数字符号
  这种情况,你可以试试将等价类和场景结合使用,执行场景用例时,按照等价类划分的内容来进行输入,原本用例条数为4*4=16条,结合一下,依然还是4条。
  另外,仔细将整个过程中的功能点罗列出来,诸如,加减数量,选择商品,取消选择,确认,取消,关闭,商品总价计算,金钱扣除,将这些功能点,与你的场景进行结合使用,原本几十条的用例,进行组合排序后,会极大的缩水。
  顺便也提一下,如果你了解因果图决策表或者正交,那你还可以在排序中加入这些方法的设计思想,后达到尽可能少的用例覆盖尽可能多的面积,后在在分析时也能很直观的知道哪些功能点覆盖了,哪些功能点遗漏了。
  对于图表辅助设计用例,可以尝试运用UML,其实UML图很多对于我们设计用例都有用处,只是现在用的人极少而已,测试员在设计用例时,第一件要做的事是保持自己的思维清晰,(当然这里说的是常规的测试,诸如free test,以及敏捷测试对用例要求不高的可以忽视。)思维清晰大的来说包括2类,1类是流程清晰,除了业务流程,还有操作流程,可以理解为时序,另1类这是功能点分布,要清楚的知道包括哪些功能点,这些功能点的功能实现等,好是将其进行罗列,这类文档也许不会和缺陷报告等测试文档进行归档,但却能极好的帮助我们设计测试用例。