游戏测试用例设计实例

　　前段时间写过一篇博文，关于用例设计的，最近有个朋友问游戏中玩家与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