wr 在游戏测试中遇到的问题

jolley

因为初次使用WR，一些问题可能比较弱质，但是希望能够得到回答，我仿照了游戏的测试流程做了从游戏登陆界面到游戏主截面的代码，但是在进入游戏主界面以后，我就傻呆了，因为我要取得某个NPC的属性信息以及玩家的属性信息，比如，在一个与NPC答题的系统里面，就有答题的次数，经验奖励和物品奖励，以及答题允许时间（一天能答多少道题），答题正误提示信息反馈等等，这些个人感觉WR好象都做不了？ 请高手指点一下，之前我的想法是将NPC当作一个bitmap来处理，因为在一个游戏窗口里面WR的GUI MAP editor非常stupid,都识别不出来贴上去的按钮什么的，要把他弄成virtual object 才可以。所以想到了用bitmap,但是显然用bitmap是不行的，我在想有没有什么办法做到这个呢？请大家帮我想想办法。先谢谢拉。

i297269775

都是牛人啊
学习啦

jolley

1、我们在自动化的时候一定要记得我们是为了测试而自动化，不要到最后变成了为了自动化而自动化；

davy, 当然我们引入自动化测试到游戏中是为了尽可能减少那些simple/repeated的工作,不能将自动化测试当作一个教条,而忽视它真正的目的.我之前的那个想法,是希望能够尽可能将游戏测试最大程度地自动化,方便进行各项测试,而不仅仅局限于GUI方面的,而在接口方面,甚至命令行方面都能够进行测试,有专门的测试接口,并且测试接口是和编制程序同步的,但是是独立的,逻辑是一致的,这样就有测试客户端的想法,这个是基于一些外文资料得出的,因为他们在一个游戏里面已经这样做到了id software的 The Sims Online(TSO model).

2、为什么在自动化测试中强调的是用脚本而不是用编程语言，就是因为脚本的开发成本低，追求的是快速开发，低投入高产出，而你现在要用脚本来写全套的游戏逻辑，那么使用脚本是不合适的，我写的测试脚本大体有三个数量级的，几行十几行的，二三百行的，五百至一千行的，但是基本不会有超过千行的测试脚本，如果超过，也会拆成几个独立的小脚本；你可以评估一下你的代码规模，而且不要忘记维护的成本；

谢谢提醒.现在想来这个级别应该与程序部编制的程序处于相同数量级别,这的确要引入模块化的思想去组织代码规模,对功能要进行足够地细化,之前的想法是测试客户端逻辑与真正客户端逻辑一致,而用脚本来驱动.相当于是这样的结构:测试客户端(NULL Client) = TSL脚本(非界面显示部分) + 客户端逻辑, 真正客户端 = 显示部分 + 客户端逻辑.并且以为这样可以节省客户端逻辑这部分的东西,但是实际上却不是的.

3、按照你的设想做的话，在项目/产品完成之前你成功的机率有多大，项目/产品是否能够承担的起如果你失败而造成的测试延误损失？

现在只有我前面提到的id software的The Sims Online游戏里面用到这种模型.并且极大地提高了自动化测试在该游戏测试的占用率.
本意是想将回归测试自动化,但是后来发现,可以更加好地进行测试,就从TSO中引入了测试客户端,这样可以从根本上改变目前手工测试的测试环境,提高测试效率,现在测试组的人手不够,只是我一个人去尝试做.主流测试还是用那种所见即所得的手工测试,现在游戏产品已经发布,这些想法和做法要在下款游戏中才能做得到.

[ 本帖最后由 jolley 于 2008-2-16 18:22 编辑 ]

mythxhg

............

脚本是不会考虑玩家感受的,一把刀,你可以用它来救人也可以用它来杀人,同样的所谓外挂目的是为了升级,但它的技术也可以帮助你验证你想要的东西,脱机外挂实际就可以做数据包校验,披上LR之类多并发的外衣就可以做性能测试,非脱机外挂可以直接模拟玩家的操作,要做功能点校验又有何不可?
至于你说的可玩性,一些模糊概念的东西是不可能转化为机器语言的,计算机只能识别明确的是与不是,难道你奢望你的脚本能判断这好不好玩,够不够好玩?.

davy_chen

楼上说的在技术层面没有问题，但是也有偏离测试的嫌疑，尤其是脱机外挂，已经基本不会考虑玩家感受了，玩家做外挂是为了升级，测试人员做自动脚本，是为了验证。

mythxhg

其实按键精灵可以帮到你,不过想完成比较精确的回放是有点难度的,按键提供了很多有用的函数,一些颜色识别,位图识别等等都是针对游戏来设计的,这也是为什么很多游戏的外挂都用他来制作.

按键的外挂跟WR等自动化测试工具一样的原理,都是通过界面作为入口.
现在的脱机外挂实际上是跟LR的回放一个原理,对游戏的数据包收发作为入口.

所以为一个游戏编写测试脚本实际上就是一个外挂制作的过程.多学点相关知识吧,以界面作为入口的外挂还是相对简单的.

davy_chen

看了你的想法，给我的感觉是，不是不能实现，但是投入过大，这样相当于你又自己重建了一个游戏，这里有几点：
1、我们在自动化的时候一定要记得我们是为了测试而自动化，不要到最后变成了为了自动化而自动化；
2、为什么在自动化测试中强调的是用脚本而不是用编程语言，就是因为脚本的开发成本低，追求的是快速开发，低投入高产出，而你现在要用脚本来写全套的游戏逻辑，那么使用脚本是不合适的，我写的测试脚本大体有三个数量级的，几行十几行的，二三百行的，五百至一千行的，但是基本不会有超过千行的测试脚本，如果超过，也会拆成几个独立的小脚本；你可以评估一下你的代码规模，而且不要忘记维护的成本；
3、按照你的设想做的话，在项目/产品完成之前你成功的机率有多大，项目/产品是否能够承担的起如果你失败而造成的测试延误损失？

jolley

davy你好，之前我的想法是在怪物掉落以后，会在游戏界面上出现一个掉落物品的位图，然后通过检查游戏界面的变化来达到统计掉率的目的，因为游戏里面的掉落物品必须是先掉在地上才能拣到的，通过累加某个特定的位图信息来获得特定物品的数量，但是后来才发现这种做法是在可以获取单个位图信息的基础上才是可行的，不然这种做法是有问题的。除了位图检测来确定对象之外，目前还没有一些好的方法。：（
不过一个总的想法是将这些游戏里面的元素都弄成GUI 对象，比如将NPC弄成一个按钮，将对话框弄成一个菜单，等等，因为现在的测试工具很多都是GUI测试的，并且一下子要求开发人员做测试接口，也不现实，不过想弄个测试客户端，主要是用脚本来驱动，来完成与客户端进行交互，这个客户端类似于真正的客户端，但是不同的是，这个客户端有真正客户端的全部逻辑（不包含显示部分），但是是没有界面的。
谢谢指教! davy.

davy_chen

如果你能够通过游戏系统得到位图信息（例如象游戏外挂一样过滤包），这样做是可以的，但是如果你完全是通过外部程序/脚本来扫描屏幕得到相关信息（如我上面的例子），那么你的想法就会有很大麻烦。因为你可能要处理以下一些情况：
1、掉落物品可能是动画显示，经常使用闪光或缩放来表示，所以不便于静态比对；
2、掉落的物品可能随位于玩家的相对位置，改变显示形态，玩家离掉落物品远，物品显示较小，例物品近，则显示比较大，而且随着方位可能会因为角度变化而发生显示变化；
3、掉落物品被遮挡，掉落的物品可能会被地图中的一些物品遮挡，例如植物，地形，建筑物，或各玩家，而且一次打怪可能会掉落多件物品，物品之间也会出现层叠现象。
所以，你理论上想的是可以的，但是要实际运行还是很困难的，我上面的例子你可以看到，我检测的内容很少，通常不会以某个图片做判断，而只用一两个点做校验。

jolley

谢谢拉，davy,你真牛，呵呵。让我豁然开朗了许多，不过为了确定我明白了你的意思。
我在想一个怪物掉落物品的问题，希望你再来指点一下：
通过位图来检测，如果刷怪的时候，怪物死亡以后，就会掉一个物品，这样的话，就在游戏界面上面增加了一个位图的信息，检测到这个位图以后，就累加，在一个时期内，如果消失了，那么就说被玩家拾取到了，当然在地图刷新时间到来之前（网游中地图上的物品会隔一段时间就会清除掉的）。并且设置一个变量来寄存这个数据，这样的话，就来设置怪物掉落物品的数量。
这种做法对吗？

davy_chen

第三条补充说明：
这里的意思就是一种状态可能有多种表现，不管用哪种表现识别，只要能够与其他状态区别开就可以使用。例如
1、纸牌游戏中，如果我想让脚本按照游满足戏规则自动出牌，但是说大点这就要人工智能了，怎么办，很多纸牌游戏中，如果出牌符合规则时，选中要出的牌会自动变颜色等，那么我们只要让脚本选牌后检查一下颜色就可以知道当前状态是满足出牌规则的状态，还是不满足的状态；
2、网游中玩家一般总是在屏幕的中央显示，只有当玩家走到地图边缘的时候才可能会偏离中间点，我们让脚本怎么知道他到了地图边缘，经常发现网游会附带一个小地图，绿点表示玩家，那么平时绿点都会在小地图的中央，即固定位置，所以我们只要让脚本检测该坐标点是否为绿色，就知道我们的玩家是否走到了地图的边缘。（我们为什么要用小地图识别，因为在游戏界面中玩家的移动是动画的，很难捕捉状态，所以用相对稳定，较容易获取的状态去识别。）

jolley

还有谁能帮上忙的？

jolley

原帖由 davy_chen 于 2008-1-23 10:23 发表
1、游戏的自动化测试我认为是自动化测试中最难的一块了，所以不成功也算很正常；
2、如果想可靠，高效的进行你所描述的自动化测试，最好能够与开发合作，例如开放后门，或者通过某种途径告知你游戏当前状态，这样你 ...

1 严重统一你的说法，自动化测试本来在软件行业来说就是比较难的话题，而在游戏这个比较特殊的行业来说，更加是这样的了。一般的网络游戏都是C/S模式的，涉及到客户端和服务器端的交互之类的。
2 当然如果要做的话，就要获得开发人员的支持了，因为现在的测试是分成三类的，GUI测试，接口测试，命令行测试，目前普遍的自动化测试工具是针对GUI测试的，因为GUI测试是捕获GUI信息而进行自动化的，不够详细和全面，甚至比较比较片面。而后两种测试相比较而言是理想的做法，但是却要求开发人员比较好的支持。除非建立一整套的流程说服开发人员这些做法的必要性，否则很难说，他们会采用你的想法。
3 对第三条不甚了解，望多多指点，在游戏里面，获取NPC的对象属性是很难的，即便是NPC的id.所得到的只是一个bitmap信息，对于一个bitmap信息来说，有什么用呢？显然不是我想要的。
4 这个当然，具体问题具体分析，尽量在目标明确和针对性很强的情况下做这些自动化测试。谢谢提醒。

jolley

原帖由 lantianwei 于 2008-1-23 09:59 发表

1.我不是非常清楚你说的NPC是什么东西
2.根据你的描述,应该是对被测程序识别的效果不是很好,建议不要用WR做自动化,如果真想做,估计会有困难,但如果你技术扎实的应该也可以做点出来

1 是这样的，NPC的全称是non-player-character,是非玩家角色，在游戏里面，举个例子，我们可以向NPC买卖东西，以及跟NPC战斗，和跟NPC对话，等等这些交互操作都是在玩家和NPC之间进行的。
2 我所用WR感觉对游戏里面的NPC识别效果是不怎么好的，无法获取NPC的标识信息，我以前试过用virtual object wizard,来将他做个object,但是还是获取不了NPC的标识信息，做成bitmap的话，更加不用说落，根本就偏离了我的需求，我所关心的是游戏中的回归测试，个人觉得WR做回归测试比较擅长，所以就采用了WR，如故是性能测试的话，当然我会选择LR落，呵呵，另外我是做了一年技术开发转到测试的，所以基本的技术还是有保障的。另外还有一点值得说明的是：不用WR做回归自动化测试，那么用什么呢？

davy_chen

1、游戏的自动化测试我认为是自动化测试中最难的一块了，所以不成功也算很正常；
2、如果想可靠，高效的进行你所描述的自动化测试，最好能够与开发合作，例如开放后门，或者通过某种途径告知你游戏当前状态，这样你就可以避免从界面中直接捕获这些信息了。这种方法应该是最优的，但是需要你能够说服你们的开发人员支持你；
3、对于某状态不易识别时，可以考虑从相关状态入手，找最容易得到的信息辅助识别，如果我们知道游戏规律（不仅是规则）时，可以自己模拟游戏的发展演化，这点在棋类游戏中尤其明显。
4、见山开路，遇水搭桥，遇到什么具体问题就针对性的具体解决，在游戏自动化测试中不要追求统一的实现方法。

lantianwei

原帖由 jolley 于 2008-1-23 09:45 发表
哪位高手帮帮忙呀。我还是不明白怎么获取游戏中玩家和NPC的变量标识呀？玩家或者NPC在一个窗口里面相当于什么呀？怎么样把给取出来NPC和玩家的属性出来，现在游戏中很多标识都记在NPC和玩家身上，如果不获得这些信息 ...

1.我不是非常清楚你说的NPC是什么东西
2.根据你的描述,应该是对被测程序识别的效果不是很好,建议不要用WR做自动化,如果真想做,估计会有困难,但如果你技术扎实的应该也可以做点出来

jolley

哪位高手帮帮忙呀。我还是不明白怎么获取游戏中玩家和NPC的变量标识呀？玩家或者NPC在一个窗口里面相当于什么呀？怎么样把给取出来NPC和玩家的属性出来，现在游戏中很多标识都记在NPC和玩家身上，如果不获得这些信息的话，那么做一个简单的答题系统测试是怎么去实现自动化的呢？很迷惑。请大家慷慨相助。：）