设计上要求务必达到：
1低耦合，高内聚
这个能简化我们实现测试的过程，又能让我们更准确的定位问题和回归问题。具体原因这里就不说了，可以去看看软件设计和测试的一些资料。
2.游戏运行要高透明，游戏运行的对象是可以给定条件获得，并且运行条件是可编辑的。
这个问题不能太深入，太深入可能公司就要找我麻烦了哈，大家原谅一下。这样设计的目的就是为了，我们可以定制我们的测试过程和预期结果。
3.通信是是可以设置和编辑的。
其实client与server的交互的本质是通过发送数据包来实现的。我们游戏人员通常说的协议其实是制的一个一个的数据结构，而不是tcp/ip之类的协议。实现这个的目的是我们在部署大量client与server交互的时候不需要运行我们的client，只需要一个发包client就可以了，而不需要弄上几千几万个物理client。
4.所有的接口在发布版本是关闭的。
这个是鉴于某公司之前出现了一次严重事故而增加的，之前某公司由于发布失误，导致外网玩家可以直接编辑游戏运行的一些数据，这个做起来也非常简单，在server上加一个宏就可以实现：ifdef _Debug define Test endif 就可以了。在编译发布版本的时候，就不会暴露这些高危数据出来，当然方式有很多，根据自己情况定是最好的。
接着,主要说一下哪些可以用来做自动化测试。
前面我大概说了一下游戏自动化测试的一些现状需求，这一篇主要谈谈游戏里面哪些可以做，哪些好做，哪些难做，哪些没必要做以及一些原因。欢迎拍砖哈，希望大家也谈谈你们的做法和优点。
我们在做游戏自动化测试之前，我们先假设我们的架构已经设计的足够好，允许我们能够通过我们的测试工具，获取游戏的运行状态并且修改游戏的状态。原本打算写到五就差不多了，后来应一些朋友的要求，我会大概说说游戏架构没有考虑到自动化测试的时候，自动化测试可以做的一些事情。
据我了解的情况，目前国内所有的网络游戏都是采用面向对象的方法设计和实现的，如果有不是的，我没接触过，也不知道用什么办法去做，所以再一次假设，我们的游戏都是使用的面向对象的方法设计和实现的，请记住，这里我再三提到对象这个概念。后面讲的一些东西将会围绕这个概念展开。
还是先说一下哪些东西不建议采用自动化测试吧：
1.表现类，以主观感受为主为测试目的测试对象。
大家都知道，计算机最喜欢做的是逻辑性计算，而不是人性计算。之所以不做，原因就是这类测试几乎无法定义预期结果，所以更不要谈测试结果了，如果没有测试结果，那么计算机做了什么呢?这种问题主要集中在client上，比如画面，音效，操作性，当然还有设计的游戏平衡性等等。这里标准其实就是：当人无法用逻辑语言表达出预期结果的东西，不要试图自动化。
文章来源于领测软件测试网 https://www.ltesting.net/
