举例一： 如面购买宝箱的例子，针对于需求，仅是对于给出的数据进行了测试，但是在实际情况中，实际要求中需要注意的点。根据平时测试，出现过问题的地方，所以又应该考虑到以下的测试点：
a.尝试购买-1个宝箱
b.尝试购买0个宝箱
c.多次购买小于5个宝箱
d.多次购买5个宝箱
e.购买宝箱后重启客户端/服务器
f........
举例二：对于游戏中，需要做屏蔽词功能，需要考虑到以下玩家会进行操作的功能点进行测试（多多自走棋为例），我们需要考虑到所有可能出现玩家输入信息的地方，根据对平时对项目的熟悉以及自己的经验，想到一些可能会出现问题的地方：
a.创建账号（玩家填写角色名称）
b.聊天功能(世界聊天、好友私聊、队伍聊天、发送邀约信息、制图工坊、房间队伍聊天、局内战斗聊天、局内私聊、局内观众、局内裁判、观战发送聊天信息)
c.个人信息（玩家修改昵称）
d.自建房间（玩家创建/修改房间昵称）
4. 场景法百度百科对场景法的解释是：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。 在一个游戏功能中，将大功能拆分为一个个小功能，而这些小功能就可以视为一个个小场景，这些小场景的集合就成了这个完整的功能模块。
举例，比如多多自走棋的通行证每周挑战功能：
根据这个界面，我们可以分为以下几个部分：
a.每日奖励
b.经验等级
c.具体任务信息
d.购买等级
e.奖励展示
f.视频播放
g.帮助按钮
h.购买等级
以上这些小功能以玩家可能会涉及到的操作为出发点，我们可以理解为一个个小场景，将他们组合起来就构成了这个完整的功能，这些小功能构成了整个每周挑战这个功能。以上的这些小功能应该更多以玩家的角度进行考虑。
5. 因果图法和判定表等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系、相互组合等。考虑输入条件之间的相互组合，可能会产生一 些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多，因此需要考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图。
下面先了解一下因果图得一些规则，下面以图的形式详细说明6种因果逻辑。
c表示原因，e表示结果：
a.恒等：如果原因为真，那么结果必定为真。
b.非：只有原因为假，结果才为真。
c.与：只有2个原因都为真，那么结果为真。
d.或：2个原因中有一个为真时，结果就为真。
e.与非：先与后非。
f.或非：先或后非。