加入我们，或者，欢迎回来。
您需要 登录 才可以下载或查看，没有帐号？注册会员
x
本帖最后由 琪露诺 于 2012-8-8 08:32 编辑
游戏的自动化测试设想和浅析 （感谢走路君、Udars君、orzfly君） （因为数学基础不够，所以可能写得比较粗略，抱歉啦……咱真的没表达能力什么的= =）
一 写在前面 我们都知道，程序设计中有一个“自动化测试”的概念。简单点说，就是这样一个情景：程序员下班时，打开自动化测试程序，配置好参数后回家去了，第二天他回到单位，看到一组组测试数据已经摆在了眼前。这些数据是由自动化测试程序对指定的程序进行测试所生成的结果。大数据量的测试再也不需要程序员一条一条输入、不断监视程序运行的状态了，这些都可以由自动化的程序包办。同时，大量数据的测试像是“地毯式搜索”一样，减少了测试漏洞的出现。 而设计游戏的我们，不禁也会想到：游戏也是需要大量测试工作的，这么好的技术，可以用在游戏上吗？ 我觉得游戏也可以有自动化测试的系统，并且它可以节省大量的人力物力。自动化测试不需要像人类测试一样经历游戏的流程、受到60FPS的限制，只需要在计算机内部进行数据的处理和运算，就可以得出大量的测试结果。随着游戏制作领域的技术发展，游戏的自动化测试门槛一定会越来越低，利用自动化测试技术辅助游戏的测试，简化游戏的设计工作，甚至成为游戏测试的一大部分，将成为未来游戏制作领域中的一大趋势。 游戏自动化测试的领域，主要在于数值系统的测试（如果用一个AVG做自动化测试，或者测试RPG游戏中的对话部分，加起来一共才有多少工作需要做呢？）。含有RPG、SLG、RTS等等元素的游戏中，有大量数据需要进行测试，有大量平衡需要调整。防止数据类型在特定情况下出现明显的偏差，并且在保证数据位于合理范围的基础下模拟玩家的心理，得出游戏对于玩家的难度曲线等参数。在计算机的强大运算能力之下，上面的任务可以很轻松地完成。 需要声明的是自动化测试目前来看不可能代替传统的人工测试。游戏过程涉及很多心理因素，玩家对游戏的反应也会根据玩家的不同有所不同，此外目前计算机也无法完全模拟人类玩家的思考方式和行为。所以自动化测试是有局限性的。 很多人所疑虑的问题是，自动化测试会不会带来巨大的成本呢？我觉得目前可能是，但是不久的将来这些成本都会大幅度降低。在后面会有更加具体的论述。
二 从魔塔开始，走出自动化测试第一步 几年前有一个小游戏风靡全国各大小游戏网站，那就是魔塔。魔塔的战斗方式是相当简化的，然而这种战斗元素和它的精神却广泛运用在很多RPG、SLG等类型的游戏中。角色和敌人分别站在一边，双方轮流攻击对方，一次攻击的伤害值就是简单的攻击力减去防御力。这可以说是最简单的一个数值模型了。 已知角色的攻击力是aa，防御力是ad，敌人生命是eh，攻击力是ea，防御力是ed，因为之前战斗的顺序和每一回合的伤害都已经固定了，所以角色和某一个敌人战斗的伤害是固定的。可以通过下面的公式计算。 damage= [eh / (aa - ed)] * (ea - ad) （方括号是取整。方括号里刚好整除的时候取整结果需要加一。） 稍微解释一下，它的意思也就是在角色击败敌人的过程中敌人的攻击对角色造成了多少伤害。虽然貌似这句话没什么用但是理解后面的一些内容可能会容易些吧。 有了上面的内容，首先来看防止数据偏差过大的问题。 在固定数值的游戏中，如果能力继承的流程特别长，前面的小小偏差到了后面可能会放大为巨大的优势积累。解决这个问题的方法可能会在于整体能力设计的几何级数增长，或者极度精密的测试。有了自动化测试的技术，这方面的担忧可以减少一些。 魔塔那样的游戏，除了敌人，地图上还有增益物品这一大类的道具。为了简化模型，暂时先不考虑“钥匙”和“门”的元素，也忽略一些角色靠近后主动伤害角色一次的怪物。增益道具，可以分为“生命增加”和“攻防增加”两个类别。稍微考虑一下就能发现，生命增加的道具只要在角色生命足够的基础上，早获得和晚获得对过关最终状态的影响是一样的，而攻防增加越早，获得的好处就越大（攻击的增加有一个临界点问题，在计算公式中取整处已经体现出来了）。因为假设游戏中存在按比例消减生命，所以生命增加的道具获取方式以“刚好够用”为好。 所以，如果要让AI去玩魔塔这类游戏，每一步搜索会是这样一个过程： 我的周围有哪些事件可以到达？ 我周围的事件中，有攻防增益的物品吗？如果有就获得它。 我可以和周围哪些怪物战斗？ 和哪些怪物战斗我的生命还不够，需要获得旁边的生命增加道具？ 对于整个游戏，这会是一个搜索，因为地图上有大量事件，所以运算速度是几何级数的。 刚才所描述的模型，简单到把一切能去掉的都已经去掉，或许运算量还能承受。但是只要加上一点其他东西，比如角色的技能，或者是能破坏一堵墙的道具，运算量立马上去好几个数量级，枚举的方式是达不到目的了。
三 往哪个方向构建AI？ 所以说，更高级的AI在自动化测试中也是需要的了。但是自动化测试AI有与游戏中AI不同的地方。在下面我们将会遇到这两者明显的不同。 人类玩这个游戏的时候，经常会注意到地图上的宝石，并且考虑战胜多少怪物才能得到某一个宝石。我们可以以攻防增益道具（沿用魔塔的说法，下面称为“宝石”）为中心，把地图的数据转存为“每一个宝石或者每一堆宝石由多少怪物来看守”，衡量怎么样的拿宝石的顺序能把伤害降低到最少。 如果这是一款对战的游戏，而需要制作的是一个对战AI，自然需要用到很多模糊算法等高级的算法，以在短时间内判断出大量宝石的比较优的获取顺序。但是我们面前的是一个测试AI，它可以一整天一整天地来算某道特定的谜题。所以，果断进行遍历吧。只要数据量能接受，测试AI可以最大程度地使用准确度高的遍历方法。 同样，如果这AI代表的是玩家角色的一位同伴，这位同伴需要辅助玩家完成任务。那么同伴的动作需要很谨慎，很多奇葩的动作就都不能去做了，需要提前剪掉这些分支。然而测试AI所做的就是需要深入人类所没有顾及到的各个角落，把最极端的数据挖出来。 所以，一有条件，就尽管地用遍历吧。 在遍历之后，也可以增加一些随机数值的测试（尤其是没有经过遍历的方面）。遍历和随机的差别比较像严格设计测试用例的测试和探险测试的差别，结合起来使用应该既能提升效率又能获得不错的效果。 上面说的只是处理数据偏差部分的内容。而模拟玩家部分应该考虑哪些内容呢？如果游戏中有一个商店，可以用战斗获得的金钱换取能力，可能有的玩家会全部投入到增加攻击上，有的玩家会增加到防御，有的玩家因为玩得不好导致缺乏生命，所以会在商店中买一些生命来维持游戏周转，也有玩家会经过计算来判断攻击还是防御会更划算。假如购买n次，每次可以购买攻击防御生命三种选一，那么一共有3^n种选择，显然不能接受。所以需要用一系列参量来表示玩家的购买情况，每一组参量表示一组玩家在游戏过程中的购买情况，遍历这些参量就能得到所有较为可能的购买情况。比如设置一个“攻击性”参数，参数越高购买攻击的次数就越多；设置“稳重”参数，参数高代表在攻击足够的情况下尽量增加防御。除此之外还有很多设置参数的方式。这只是简单的一个例子，更好地模拟玩家，并且输出玩家的“感受”，在下面的章节中会比较详细地介绍。
四 RPG战斗内的数据估算 写了上面那些内容，可能很多人会产生这样的错觉：自动化测试就是让AI把游戏玩几遍。那么，拿来一个比较传统的RPG，地图的遇敌是随机的，角色每一次行动可以在一长串的技能列表中选择，每一次技能的伤害也是有上下浮动的。在这么多随机的影响下，究竟让AI玩多少次才能得出具有统计意义的数据？而整个游戏流程那么长，数据量之大是否可以承受？ 其实不必这样做。要对一款游戏进行测试，首先可以把它分成阶段或者部分，对每一个部分进行相对独立的测试。如果是传统的RPG或者类似的模式，可以把Boss作为节点，让角色具有一定的等级和装备，使用一些简单的AI配合适量枚举，得出角色和Boss战斗的情况，判断角色和Boss战斗有多少难度，存不存在碾压或者根本过不去。然而角色的等级如何确定呢？ 在游戏设计的时候，设计人员应该会给Boss一个估计性的等级设定，也就是某个等级水平的玩家。所以测试的时候可以先用这个预期的等级测试一下。接着就需要估计玩家到达Boss处的实际等级大概是多少了。如果是随机遇敌，可以采用一些近似的公式： 经验 = Σ（遇敌地图行走的格数/遇敌步数*平均一次战斗获得的经验） 或者其他更准确一些的公式。其他方式的遇敌也可以建立一些模型，因为这些模型是需要大量重复使用的。再根据经验来推断玩家的等级。计算出的经验也不是精确值，所以可以以上限、下限和中间取的几个值分别计算等级，再去和Boss战斗。而和Boss战斗的过程中，除了直接模拟的方式，也可以用期望值计算等方式计算战斗的情况（注意当出现10%造成巨大伤害一类的技能时候，期望值计算需要慎用了）。除了经验之外，金钱、道具也是需要考虑到的。可以用AI对金钱、道具进行一个粗测，防止Boss战时玩家握有过量的道具导致游戏失衡。 相对于Boss的测试，节点之间的测试会方便一些，粗测主要的目的在于防止中途的杂兵对玩家造成太大的阻碍，并且消除一些RP影响太大的因素。
五 涉及操作的测试和难度估算 涉及操作的游戏虽然也可以用AI模拟测试，但不一定所有场合都要把游戏流程模拟一遍。“在角色击败敌人的过程中敌人的攻击对角色造成了多少伤害”，如果是一对一的决斗，这句话几乎是哪里都适用的，包括涉及动作。比如一个ARPG的Boss战，Boss有A、B两个形态，A形态有a、b两种技能，B形态有c、d、e三种技能，那么总的伤害就是这五种技能对角色造成的总的伤害了，而每一种技能造成的伤害由三部分因素影响：技能本身的威力大小、技能击中角色的可能性、这个Boss使出技能的次数。 技能本身的威力大小由技能本身属性和角色的属性决定，偏差一般不会太大。技能击中角色的可能性涉及到技能的范围、玩家的操作水平和习惯。Boss使出技能的次数涉及到Boss存活的时间，进而转化为玩家和Boss双方能力对比和玩家操作水平两部分。 ( Boss生命 / 玩家攻击Boss一次的平均伤害 ) * 玩家攻击Boss一次的平均时间 = 总时间 玩家受到的伤害 = Σ(总时间 / Boss某个攻击的频率) * Boss某个攻击的伤害 * Boss某个攻击的命中率 上面两条简单的式子或许可以做一点参考。命中率等等的参数可以由玩家水平和玩家习惯确定。但是上面的公式仅限于流程比较长、数据趋于统计的情况。然而这虽然可以用在一些游戏元素中，大多数ARPG的情况还是不符合这些标准。很多时候，和敌人战斗时敌人的攻击很强力，需要靠玩家的操作一次次躲开，并且找机会攻击敌人。所以，对某一个环节的特意分析也会经常用到。 比如敌人使用一个往角色现在方向直线飞过去的火球。如果玩家一时没注意或者被其他现象干扰，可能会原地不动或者沿着火球的方向移动，最后被火球命中。水平很高的玩家可能会微移，让火球从旁边擦过去；水平低一些的玩家可能会走很长的路避开火球。后面两种情况虽然都躲开了这一次攻击，但是对后续的行为有一些影响。在分析和计算技能伤害范围的过程中，可以以这样的方式来考虑。 在角色面对一堆敌人的情况下，很多时候可以把敌人整体处理，看成一个单位以后进行伤害等参数的估计。如果局面过于复杂，或许建立模型的成本已经高于让AI去玩几遍，所以这个时候使用适度的枚举或者随机测试吧，会方便不少。
六 简单讨论塔防等即时战略元素的测试 较为复杂的对战型即时战略游戏，因为作者的水平有限，所以暂时不予讨论了，可能可以分解为多种要素后再分析，然后进行测试（对于此处，Udars君说可以在设计敌人AI的时候顺便把测试AI制作了，因为两者的相似点还是很多的）。这里讨论一种比较简单的即时战略样式：塔防。 “战略”要求游戏具有相当好的平衡性。然而很多的自制塔防游戏经常会出现这样的问题：作者对塔防地图有着明确的导向和想法，希望玩家能够通过塔的种类、位置上的配合达到比较好的效果。然而玩家却一律采用最低级的塔布满了整个地图，很“傻瓜”地一直撑到最后一波。虽然可能在期望值计算中各种攻击性塔的价值比较类似，或者因为塔各有属性所以不方便在公式中计算，但是可能有一种塔因为攻击频率特别高，或者性价比特别高，导致破坏了整个游戏的平衡，以数据上的优势掩盖了特性。 因为这样的排布方法有明确的逻辑，所以很方便设计出类似的AI，尝试各种类似的情况，并且可以设置一些“debuff塔和性价比高的塔配合”等等，以查看是否出现了太多意料之外的情况。 “即时”又涉及到了操作的层面。塔防是以策略为主的，操作所占的比重会比较低，但是在有一些作品中，因为建造、升级和拆除塔需要比较多的时间，及时操作也成为了游戏的一大要求。除了简单地以APM作为参数，进行模拟和推算以外，还可以设置一些其他的参数来影响操作速度曲线，比如APM长期维持在较高水平后会跌落等等。
七 自动化测试划算吗？ 从目前测试行业的情况来看，程序的自动化测试应用得十分有限，很大程度上规模较大的公司才有条件采用程序自动化测试的技术。而游戏自动化测试的门槛更高，它需要AI编写人员、数据分析人员等的参与，需要针对特定游戏或者一类游戏的测试平台。但是，不久的将来，游戏自动化测试的成本会迅速降低。 首先，标准化是现在大多数行业的趋势，而目前游戏设计和测试行业很多地方都依赖于工作人员的经验和主观判断。随着游戏规模的不断增大，设计和测试的工作量也会迅速增加，这个时候需要强有力的一大工具来减少工作人员的重复任务，达到减少人力成本的目的。 但是，自动化测试所需要的人员不也有额外的支出成本？我觉得这笔成本在未来将会越来越低。目前AI的开发已经有很多方便的工具，而且AI的理论也在不断发展。“所见即所得”式的AI开发可能也即将降临。再加上测试需要的AI难度会低于游戏中的队友AI等智能，所以以后的AI编写人员只需要学习基础的知识就能写出理想的测试用AI。 目前已经有一些游戏公司采用自动化的方式辅助游戏的设计和测试了。有游戏公司使用自动化技术对随机生成的地图进行分析，供制作人员参考。据说三国杀在设计新人物的时候采用计算机模拟的方式让它和没有技能的人物战斗足够多局，从这些牌局中获得大量可以参考的数据。
八 总结 游戏的自动化测试，目的在于减少测试人员和设计人员的重复工作，提升游戏开发速度和质量，适应大数据量、大规模游戏的开发。 游戏自动化测试除了模拟游戏进程，还可以采用等效估计的方式。游戏自动化测试所需要的AI可以在智能上弱一些，不足的地方以枚举来弥补，并且结合随机数据的测试。 目前游戏自动化测试门槛相当高，但是它会成为未来的发展方向。
| 
写轮眼
发表于 2012-8-8 08:31:02
收藏
分享
提升卡
沉默号角
喧嚣号角
变色卡
升龙剑
发表于 2012-8-8 10:05:50
楼主
