写完一后就被人严重的bs了一下，说我界面不友好.....我只好说，这就是我的风格!嘿嘿，对于这个界面确实因为能力有限，编辑起来特别麻烦，所以在我没有找到好方法前，我决定不改这个风格了!
这一篇，我主要说说游戏自动化测试对游戏架构的需求：
首先，如果在一款成熟运营的游戏中，试图让测试自动化起来，几乎是不大现实的。原因不外有二：
1.我要想在游戏世界里刷出一个怪或要取得一个player的信息，如果我们的开发人员没有暴露接口出来，请问，我们该怎么办?
2.我们要做一个自动化体系，是我们自己再去开发一个新的系统呢?还是用原来的系统?如果开发一个新系统，那么我可以告诉你，国内几乎没有那个项目老大允许你这么做，运营期的游戏，最重要是一个持续稳定，如果你插入你的开发量进去，我可以明确的告诉你，你会完全打乱你老大的计划。那好，那我们在原来的系统上改吧?对这一点，我相信有经验的同学都知道，去改别人的代码的效率远远低于自己开发的效率(如果是小改动，可能是达不到自动化的效果的)。
这2个原因是阻碍游戏自动化的主要因素，当然还有其他因素，比如对项目组对测试认识方面等等的问题，这些我不在这里讨论，这里只说说技术上的需求。
这一篇，我将会从游戏架构设计上大概谈谈，游戏自动化对架构的需求，下一篇会说说，成熟运营的游戏自动化可以做些什么。软件测试
在项目风格基本确定后，就是程序架构的设计了，如果在这个时候不考虑到测试的一些需求的话，那后期做起来就会很难。
一般来说，游戏设计分3大块：1.数据库设计。2游戏逻辑server。3 游戏的逻辑client。这里的server是广义的server，不同公司的设计是不一样的，不细分。游戏client就是指平时我们运行的，可以实际“玩”的游戏，运行在我们玩家的pc机上的可执行程序。
对于我们测试来说，其实可以把数据库独立出来，数据库和游戏的交互无非就是存取修改操作。在不考虑的性能情况下，自动化测试可以不考虑数据库，当然对于数据安全性等的操作其实属于策略问题。
其实我们实际做的自动化测试主要是游戏server的实际运行和与client的交互。这里再强调一下，自动化的本质是为了提高测试效率，所以我们只让计算机做他适合做的事情，而不是把所有的测试都交给计算机，那可能就本末倒置了，反而是为了自动化而自动化，没意义。
设计上要求务必达到：
1低耦合，高内聚
这个能简化我们实现测试的过程，又能让我们更准确的定位问题和回归问题。具体原因这里就不说了，可以去看看软件设计和测试的一些资料。
2.游戏运行要高透明，游戏运行的对象是可以给定条件获得，并且运行条件是可编辑的。
这个问题不能太深入，太深入可能公司就要找我麻烦了哈，大家原谅一下。这样设计的目的就是为了，我们可以定制我们的测试过程和预期结果。
3.通信是是可以设置和编辑的。
其实client与server的交互的本质是通过发送数据包来实现的。我们游戏人员通常说的协议其实是制的一个一个的数据结构，而不是tcp/ip之类的协议。实现这个的目的是我们在部署大量client与server交互的时候不需要运行我们的client，只需要一个发包client就可以了，而不需要弄上几千几万个物理client。
4.所有的接口在发布版本是关闭的。
这个是鉴于某公司之前出现了一次严重事故而增加的，之前某公司由于发布失误，导致外网玩家可以直接编辑游戏运行的一些数据，这个做起来也非常简单，在server上加一个宏就可以实现：ifdef _Debug define Test endif 就可以了。在编译发布版本的时候，就不会暴露这些高危数据出来，当然方式有很多，根据自己情况定是最好的。
今天主要就这么多内容了哈，不能太深入，深入会涉及到公司的一些机密，但是思想还是可以分享的。
文章来源于领测软件测试网 https://www.ltesting.net/
