近几周一直在某SLG项目内负责功能模块测试与周边工具推进的工作，渐渐感悟到了些用例设计与业务代码的联系。
游戏的业务逻辑是比一般应用复杂的。而且对于自己项目这种强玩法的游戏而言，甚至还会出现以下的现象——QA驱动策划，策划驱动开发。
策划案能够大概阐述游戏的界面、逻辑与数值，但是如果有复杂的特例，还需要QA在实际测试中去挖掘。游戏测试用例的设计过程，不仅可以看成是策划案的延伸，而且也可以看作是一份业务代码的参考文档。如果了解游戏服务端与客户端机制，跟进过代码的话，甚至可以根据它们设计一些极端的用例。
好比说，某一个建筑，占地是5x5，但是它横跨国界，一部分在A国，一部分在B国。那么这个建筑，是属于A国，还是B国呢？
如果你是开发的话，会考虑一个简单的设计：这一个建筑中心点在哪里，就属于哪个国家。
解决所属国家很简单，但是业务是多变的，策划的大脑是被二柱子捅得很深的。如果游戏机制允许玩家占领了该建筑，并利用这个建筑的地块做一些操作，那么根据中心点判断所属国家的逻辑，并足以满足业务，还需要加上地块的判定。
因此测试点就来了：
- 建筑在国界，中心点在A国 ——> 显示所属A国
- 建筑在国界，所属A国，但也拥有B国的地 ——> 能利用B国地块，做xxx操作
至于真实能不能用B国的地块做xxx操作，这就需要与策划沟通了。但重要的是，这一类地方，往往是容易出现缺陷的地方。
又比如说，你本来有一个5x5的建筑，但是等你换了阵营之后，建筑缩水成3x3的了，但“进入”建筑后的游戏功能基本没有变化。这个时候，不仅需要回归建筑相关功能，而且也需要关注建筑体积变化带来的影响。比如说，我为这个建筑添加了一个标记，那么点击原来5x5的范围，是不是还能激活这个标记？
如果没有配表支持的话，可能在开发过程中，原先就会写死建筑的大小。这样，点击3x3外围的空地，就有可能激活标记，导致bug。
总之，QA是最了解产品（游戏）的人。设计测试用例的时候，也要想到如果是自己写这个业务逻辑，会怎样设计代码，这样反推过来，就形成了一种代码排查方案。作为QA，你永远不知道研发会在什么样的地方犯错，但是常code review，养成跟进代码并思考的习惯，就能够对游戏代码设计增加一份了解，从而更容易发现游戏设计中不容易被人注意，却又容易引发缺陷的细节。