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