软件测试技术

当前位置:首页 > 软件测试技术

《游戏测试精通》 第八章

第八章 测试过程

程序员不会对自己的游戏进行测试。他们没时间,即使有时间也最好让别人来测试。但电子游戏时代刚开始的时候,开发游戏的程序员通常也是游戏的艺术家、设计师和测试员。即使是很小的游戏——只有一封电子邮件那么大——程序员的大多数时间仍然是花费在设计和编程上,花在测试上的时间很少。例如,开发Astrosmash游戏的程序员由于假设没有玩家能得分达到一千万点,结果他没有编写处理得分溢出情形的代码。当他浏览自C设计的代码时——基于他自己的假设——游戏似乎运行良好。这个游戏有趣一一其图形 激动人心(就当时而言),在Intellivision平台上,这个游戏变成了畅销游戏之一。


游戏发布后才几周,一些顾客就开始打电话抱怨。当他们得分超过999999点时,得分显示的是负数、字母和非数字的符号。这之后,此类的游戏缺陷被描述成忽略了“用户的无限得分潜能”。这个问题因下面的事实而恶化,那就是,Intellivision 控制台有一个特征,允许玩家以慢动作玩游戏,因而更易于积累到高分数。程序员约翰索尔(该游.戏的作者)得到了深刻的教训:用户总会让你吃惊。


8.1 “黑盒”测试


几乎所有的游戏测试都是黑盒测试,即在应用程序的外部进行测试。黑盒测试是指.测试员在不清楚源代码以及没有源代码的情况下进行的测试。游戏测试员通常不会通过阅读游戏代码来发现缺陷。而是像普通玩家一样通过玩游戏(操纵输入设备上的按钮)来努力发现缺陷。对于测试游戏最为复杂的网络或是最为简单的视频显示模块,黑盒测试是最经济的方式。


图8-1 所示的是一些你能提供给电子游戏的不同的输入和你能得到的输出。最基本的输入是以按键和光标移动的形式表示的位置数据和控制数据。这些可以用一系列的输入设备:操纵杆、键盘、鼠标和诸如跳舞毯、专用钓鱼游戏控制器、沙球控制器和鼓形


控制器等之类的专用设备实现。音频输入可以通过耳机中的或附在游戏控制器上的麦克风实现。视频输入可以通过USB接口的摄像机实现。来自于其他用户的输入可以通过第二个控制器、本地网络或因特网实现。最后,诸如保存的游戏和选项设置之类的储存数据能够输入存储卡或硬盘保存而后输出。


image.png


当游戏接受这些类型的输入时,它会以有趣的方式做出反应,并且产生诸如视频、音频、震动(通过强反馈设备)和储存在存储卡或硬盘上的数据之类的输出。


然而,一个电子游戏的输入路径不是单向的。它是一个反馈环,从而实现玩家和游戏的不断地互动。若玩家得不到游戏的正确响应,他们会停止游戏。他们会根据自己在.游戏中的看到的、听到的和体验到的经历来不断改变和调整自己的输入。反过来,游戏也根据用户输入的内容而做出相应的调整。图8-2显示了这一反馈环。


image.png


如果游戏结果对玩家来说是完全可以预见的,那么游戏就没任何乐趣可言了。但反过来,如果玩家接收的反馈任何时候都是完全随机的,那么游戏也会变得毫无意义。因此,游戏的反馈应该具有一定的随机性、不可预见性,但又不能过度。正是反馈环的不可预见性使得游戏有趣。因为设计的游戏本来就是让玩家惊讶的,而玩家又总能做出使程序员惊讶的事,所以黑匣子测试使得测试员可以像玩家那样思考和行动。


8.2  ”白盒”测试


与黑盒测试相反,白盒测试让测试员直接对终端用户无法触及的源代码进行检查。一个白盒测试员通常要阅读一部分游戏代码和预测代码中的响应行为,并测试代码是否能涵盖所有的输入,这是一个使人望而生畏的挑战。只使用白盒方法来测试游戏是相当困难的,因为要解释玩家反馈环的复杂性几乎是不可能的。然而,这些情况也体现出白盒测试比黑盒测试更实际和更必要的一面。


白盒测试包括:


游戏开发者在提交与游戏的其他部分整合的新代码时执行的测试。


●测试代码模块将成为可跨游戏或平台重复使用的库的一部分。

●测试对游戏引擎或游戏中间件来说至关重要的代码方法或功能。

●测试有可能被第三方开发商或修改者扩充和修改的代码模块

●测试用来支持诸如图形卡或音频处理器之类的最新硬件的特定功能的低级例程。


运行白盒测试时,可以让特定的模块以不同的路径运行以确保每条路径都行得通。测试时的输入可以参照代码定义的数据类型和取值。通过检查模块的返回值、全局变量的改变和模块中局部变量的处理情况,可以检查测试的结果。下面演示一个白盒测试,请看游戏《重返德军总部:深入敌后》(Castle Wolfenstein: Enemy Teritr)中的一个例程:


const char *TeamName (int team) {
if (team==TEAM_ AXIS)
return "RED";
else if (team==TEAM ALLIES)
return " BLUE" ;
else if (team==TEAM_ SPECTATOR) 
return "SPECTATOR" ;
return "FREE" ;
}


这个模块需要进行四个白盒测试来测试模块中每一行代码的行为。第一个测试用参数TEAM AXIS来调用TeamName功能,然后检查“RED”字符串是否被返回了。第二次测试,传递TEAM_ ALLIES 值并检查“BLUE”字符串是否被返回。第三次测试,传递TEAM_ SPECTATOR并检查返回的是否是“SPECTATOR"字符串。最后,传递其他诸如TEAM_ NONE之类的值,然后检查是否返回“FREE”字符串。这些测试不但把每一行代码至少执行了一次,而且测试了每一个if陈述的“true” 和“false”分支的行为。


这个小练习显示了白盒测试方法和黑盒测试方法间的关键差异:


●在一个游戏中,黑盒测试应该测试所有的不同输入,例如不同的菜单和按键。白盒测试要求测试代码执行的不同路径。

●通过观察代码,白盒测试将测试所有能传递或被测试模块处理的可能值。黑盒测试的产品需求和特性描述中则不会提供这样的信息。

●为了产生可重复的结果,黑盒测试依赖对游戏及其操作环境的一致性配置。白盒测试只依赖被试的模块界面,以及对流、文件系统或全局变量进行处理时用到的外部文件。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~