首先需要着重指出的一点是，本文所针对的仅是当前最流行的战争策略类Webgame，对于其它类型Webgame并不适用。

　　事实上，在当前的Webgame市场上所充斥的这些战争策略游戏的高度同质化，已经使得我们在很大程度上对于Webgame品质的好坏丧失了判断力。究竟一款Webgame设计成什么样子才能够成功，这个问题是行业内没有任何一个人可以回答的了的。在当前以运营和宣传能力作为评判一款Webgame成败的标准是一种很可行和可信的方法，但是对于Webgame的设计者和开发者（尤其是策划），这样的现状却是致命的。究竟我们如何去设计一款Webgame，应当遵循什么样的设计原则？在找到这个问题的答案前，我们的游戏设计者被迫处在一个迷茫期中。事实上，本文无意于去找到这一设计原则，仅仅是尝试在开发过程中寻求一些减少和避免设计失误的方法。

　　数值设计被认为是战争策略类Webgame设计中最难的一环，其原因就在于我们对于数值设计的评价标准知之甚少。从表面上看，Webgame的数值设计是存在有很大的随意性的，尤其是作为Webgame核心的各项时间和资源增长速度的设计，由于它们对于各个玩家来讲是公平的，而且相互之间往往很难看出直接的数值关联，因此很多对此并不精通的游戏策划在设计它们时往往过分随意。而隐藏在这种随意背后的，往往就是灾难性的游戏进程。无论是资源生产速度和资源消耗速度的不匹配，游戏战略进程和玩家部队生产速度的不匹配，主城和分城建设因不同资源和科技起点造成的数值漏洞，都属于容易带给玩家很严重的游戏体验挫折，但并不容易在设计阶段快速发现的问题。因此的，在战争策略类Webgame的设计开发过程中，我们需要引入设计测试的方法。

　　传统的软件测试和游戏测试更加偏重的都是程序漏洞（一般称为Bug）而不是设计漏洞。究其原因，很重要的一点就是测试的测试文档（或称测试用例）是基于既有的设计文档的，测试的评判标准是实现的程序（游戏）是否符合既有的需求文档。但是在这一过程中，设计的错误往往被忽略。大量的设计漏洞由于测试不充分而没有在游戏开发测试阶段被发现，而是被保留到了正式的外部测试阶段。尤其是一些后期的数值型漏洞，往往是在游戏开始公测甚至于正式运营后才暴露出来的。由于游戏数值的普遍关联性，以及玩家角色积累的连续性，在这一阶段暴露出的设计漏洞能否被弥补，弥补需要多少时间都成为了未知数。因此的，在游戏开发过程中，我们需要针对设计漏洞的测试流程和测试方法。

　　事实上，在游戏行业的开发过程中，针对单一玩法，单一流程的设计测试（或者叫内容测试）是存在的，而且也可以说是比较到位的，但是，战争策略类 Webgame的特殊性就在于它的设计漏洞往往出现在多个系统，多个玩法，多个流程共同作用的一个混合的玩家游戏过程中，而不是存在于某一个个体中，这样的，传统的基于模块的测试方法在应对战争策略类Webgame时往往是很不充分的。那么，Webgame测试中还需要什么样的测试方法呢？很简单的，就是测试者（事实上，这个测试者的角色建议以游戏策划而不是专门的游戏测试人员担任）以不同的游戏阵营和游戏角色加入游戏，整体体验游戏进程，并且记录各种体验性数据（一般为混合性数据，即不存在于游戏数值策划文档内的数据，例如玩家主城升级到X级所需的整体时间，玩家从进入游戏到开出第一座分城所需要的时间等）。

　　我们来看一个近期比较火热的战争策略类Webgame：《热血三国》中所出现的两个最为严重的，也是游戏设计者在近期更新中着重解决的两个设计漏洞：

　　1.游戏中后期很容易出现资源堆积现象（尤其是石头和铁），继而频繁的发生“人祸”。一个玩家因故两天不上游戏就可能导致接近致命的非PVP损失。

　　2.玩家频繁刷十级NPC城快速提升声望。

　　我们会注意到，以上的设计漏洞恰恰反映了两种最常见的容易在设计开发测试流程中被忽略的漏洞：一是多个混合系统长时间作用所发生的混合效应（漏洞一反映了资源生产，资源储存，资源消耗和人祸系统四个系统共同作用过程中的配合问题）；二是单一系统的效果没有直观反应出其漏洞（十级NPC城的掠夺收益是在游戏策划的规划之内的，但他并没有清晰的意识到这一规划到底会导致什么样的整体结果）。而对于绝大部分在游戏中进行到这一阶段的玩家而言，这些漏洞都是显而易见的。同样的，我们可以意识到，如果我们有这样一个基于玩家整体游戏过程的测试的话，那么很多问题是可以在游戏面世之前被发现和解决的。