详情
本书主要介绍如何将软件测试的专业方法运用到游戏产业中，全面涵盖了游戏测试的基本知识。通过阅读本书，读者将掌握以下知识技能：游戏软件测试的基础理论，游戏测试和测试工程师融入游戏开发流程中的方法，游戏测试中所使用的工具和实用经验，游戏测试工程师这个角色的职责以及决定游戏质量和测试流程的标准。借助真实游戏场景，读者将一步一步地学习测试设计和其他的质量保障手段。
书名：精通游戏测试（第3版）
ISBN：978-7-115-59262-0
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [美] 查尔斯•P.舒尔茨（Charles P. Schultz）
著 [美] 罗伯特•登顿•布赖恩特（Robert Denton Bryant）
译 张立华 高 鹏 高 嵘 陈子昂
责任编辑 李 瑾
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Simplified Chinese language edition copyright ©2022 by Posts & Telecom Press.
All Rights Reserved.
Game Testing: All in One, 3rd Edition, by Charles P. Schultz & Robert Denton Bryant.
ISBN: 978-1-942270-76-8
Copyright © 2017 by Mercury Learning and Information LLC.
本书中文简体版由Mercury Learning and Information公司授权人民邮电出版社有限公司出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。
版权所有，侵权必究。
本书主要介绍如何将软件测试的专业方法运用到游戏产业中，全面涵盖了游戏测试的基本知识。通过阅读本书，读者将掌握以下知识技能：游戏软件测试的基础理论，游戏测试和测试工程师融入游戏开发流程中的方法，游戏测试中所使用的工具和实用经验，游戏测试工程师这个角色的职责以及决定游戏质量和测试流程的标准。借助真实游戏场景，读者将一步一步地学习游戏测试设计和其他的质量保障手段。
本书适合游戏从业者、爱好者及计算机相关专业的师生阅读。
查尔斯•P.舒尔茨（Charles P. Schultz），微软认证教师（Microsoft Certified Educator，MCE），国际软件测试认证委员会美国分会（American Software Testing Qualifications Board，ASTQB）认证工程师，在美国拥有20多项专利。 罗伯特•登顿•布赖恩特（Robert Denton Bryant），美国圣爱德华大学互动游戏研究课程总监。在20多年的职业生涯中，他从一名游戏测试工程师一步步成长为制作出几十部电子游戏的业界高手。他在好莱坞做过营销人员和制片人，也在电子游戏行业做过发行人和开发人员。他是数十款游戏的执行制片人，包括畅销的《世界扑克锦标赛》（World Series of Poker）和《弹珠台名人堂》（Gottlieb Pinball Classics）Console系列，涉及的游戏平台非常广泛，例如CD-ROM、iPad等。他曾是美国和欧洲几所大学的游戏编剧客座讲师，现在在加利福尼亚大学洛杉矶分校和加利福尼亚州伯班克的伍德伯里大学教授编剧课程。他曾获美国南加利福尼亚大学的电影电视制作艺术硕士学位和华盛顿与李大学的新闻学学士学位。
特别感谢希瑟•马克斯韦尔•钱德勒（Heather Maxwell Chandler），是她帮我们联系了出版社，促成了本书新版的问世。
张立华，网名恒温，测试开发专家。目前就职于蚂蚁金服，从事区块链方向测试。毕业于浙江大学计算机科学与技术专业，拥有10年测试经验，是TesterHome社区联合创始人。联系邮箱：lihuazhang@hotmail.com。
高鹏，网名026，测试主管。目前就职于字节跳动，从事教育相关产品的测试工作。他是TesterHome社区的核心骨干，中国移动互联网测试开发技术大会的核心组织者。联系邮箱：gaopeng8100@gmail.com。
高嵘，测试开发负责人，主攻服务端性能测试、游戏协议测试。目前任职于侑虎科技，从事自动化测试、持续集成和持续测试方向的工作。毕业于同济大学计算机系，在游戏行业从业10年。联系邮箱：petitnatuo@gmail.com。
陈子昂，网名陈大猫，工业和信息化部认证高级测试工程师、高级开发工程师和大数据工程师。现任上海莉莉丝游戏测试开发组长，负责工具链和前后端专项自动化开发。联系邮箱：728661182@qq.com。
本书在翻译过程中得到了吴宗非、谢国文、徐士钊等测试行业同人的帮助，他们参与了图书的审核和校对工作，在此一并表示感谢。
冯健，毕业于美国伊利诺伊大学厄巴纳-香槟分校计算机科学与数学专业。他在留美期间曾供职于知名科技企业，目前从事以大数据和预测为主的人工智能相关技术的研究与开发工作，并长期与K-12学校合作，积极推动信息科学的教育工作。联系方式：ericstar303（微信号）。
本书英文版的第1版出版于2005年。在此后的十余年间，电子游戏领域发生了翻天覆地的变化且呈现爆炸式增长。 我们见证了玩家、平台和商业模式的数量的井喷。我们不再从实体零售店购买包装精美的游戏，而是步入了大多数游戏可以被下载到计算机、智能手机和其他终端设备的时代。 资产数十亿美元的全球公司精心制作年度3A史诗级游戏，而独立开发者则发布创意手机小游戏。过去的几年中，数百家公司耗资数十亿美元，试图创造虚拟现实游戏的市场，而《精灵宝可梦Go》（Pokémon Go）在短短一周内证明了增强现实游戏的市场。 从未有过那么多游戏为了吸引更多玩家而竞争，以前的游戏开发团队也从未如此看重游戏的质量和稳定性。现在，对于任何规模的开发团队，学习和遵循游戏测试的流程和规范都变得至关重要，尤其是在这个不断发布补丁、更新包、新功能和扩展包的新时代。现如今，虽然已有这么多游戏，但开发从未停止。所以，游戏测试也从未停止。 软件工程师免不了犯错，游戏设计者会引入缺陷，美术工程师未能闭合三维模型。游戏测试工程师的职责就是在真正的玩家开始玩游戏之前发现游戏中存在的问题，避免玩家陷入沮丧、困惑，保证游戏在销量和口碑上获得成功。在电子游戏开发领域，游戏测试工程师是无名英雄，就像《权力的游戏》（Game of Thrones）中的守夜人一样。 无论你是测试工程师还是测试经理，我们都希望本书所涵盖的内容能帮助你掌握专业技能，使你保持更高的质量警觉性。也许玩家并不知道游戏测试工程师的存在，但是他们一定会受益于你们的努力工作。
本书由异步社区出品，社区（https://www.epubit.com）为您提供相关资源和后续服务。
本书提供如下资源：
● 书中示例所使用的工具及测试表模板和通用流程图等；
● 书中的图片文件；
● 一个FIFA视频。
要获得以上配套资源，请在异步社区本书页面中单击
，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可，如下图所示。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
扫描下方二维码，您将会在异步社区微信服务号中看到本书信息及相关的服务提示。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线投稿（直接访问www.epubit.com/contribute即可）。
如果您是学校、培训机构或企业用户，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社数十年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、人工智能、软件测试、前端、网络技术等。
异步社区
微信服务号
本章主要内容如下。
每个测试工程师和测试团队都需要知道如下两条规则：
● 规则1——不要恐慌；
● 规则2——不要相信任何人。
在游戏测试项目中，恐慌是非常糟糕的事情。恐慌的人并非故意如此，他甚至可能没有意识到自己在恐慌。恐慌是对一系列情况的非理性反应，会导致软件测试工程师对项目造成损坏。如果一个测试工程师对某个不合理的需求反应过激，请提醒他不要恐慌，问问他“第一条规则是什么”。
深海潜水者也会置身于和游戏测试工程师类似的境地：有限的资源（随身携带的装备）、时间限制（空气补给）、需要遵循的规则（上浮和下沉速度）和其他意外（深海不速之客）。根据威廉·摩根（William Morgan）博士的理论，持续的恐慌可能是导致娱乐性潜水事故和死亡的原因之一。恐慌来袭往往是因为受到某些事情的刺激，比如被水草纠缠住了、设备工作不正常或者看见了鲨鱼，从而让没有经验的潜水者感到很危险。但是摩根认为，恐慌不仅无法改善任何事情，还会导致产生不理性和更危险的行为。即使是有着多年经验的潜水者，有时也会无缘无故地感到恐慌。
错误地构建测试版本、漏测一个重要的缺陷或者让开发人员追踪一个不存在的缺陷（本来可以避免），这些都不会给你带来身体上的伤害，但是会让你在其他地方付出代价，比如花费额外的时间和金钱，游戏销量下降、口碑下滑等。
在游戏项目中，一旦出现如下情况，你就会感到恐慌：
● 不熟悉；
● 尚未准备好；
● 承受压力；
● 没休息好；
● 短视。
作为游戏团队的一员，你可能会受命完成一些之前不必做的工作，比如你可能需要运行其他人的测试，或者中途加入一个全然不同的游戏项目，抑或在最后一分钟被告知要接替某人的工作并完成用户演示。遇到这些情况时，你需要依靠已有的经验，坚持基本原则，通过观察其他有相关经验的人的做法，习得新的或者不同的方法。
你甚至可能受命完成一些从未做过的工作，比如实现百分之百的安装自动化，或者编写一个工具来验证游戏中的外语测试。可能从来没有人做过这些工作。不要立刻做承诺，不要节外生枝，也不要逞强。如果你对一个场景很陌生，那么即便根据自己的最佳决断去行事，仍然可能出错。你需要有人来指引你什么时候需要帮助，请保持谦逊，不要总想着自己必须承担一切或者对每个需求都说“好的”。你不必丢弃威信或名誉。找一个能引导你提出一些有效的解决方案的“过来人”，远离显而易见的失败。你甚至可以在互联网上搜索，看看有没有人已经解决了问题，并且愿意分享经验。
注意
第4章展示了如何定义和遵循一系列测试活动，这些活动能为你提供一致的测试工作量和结果，即使在你不熟悉的领域中也同样适用。
你的项目可能会发生许多意想不到的事情，请做好突发意外的准备！在一个游戏的生命周期中，游戏的很多部分需要进行不同的测试。在这些场景背后，许多不同的技术——3D图像、声音、用户界面、多线程和文件系统等一起协同工作。如果你还没有为各种不同的测试任务做好准备，也不具备完成任务所需的技能，就会做得磕磕绊绊。
研究、实践和积累经验是做好充足准备的关键要素。在测试项目的过程中，你应尝试了解更多的游戏代码。和行业保持同步，这样你就知道下一代游戏和技术将会是什么样的，进而成为你负责测试的游戏部分的需求和设计专家，然后熟悉那些你不负责的部分。最意想不到的情况就是你可能调任另一个职位，接替另一个测试工程师，或者承担更多的责任。当这类事情发生时，请做好准备。
注意
第2章为你提供了有关准备成为一名游戏测试工程师的信息，以及你将来可能会遇到的测试环境、项目、角色和工作。
压力来自以下3个方面：
● 进度（完成项目的规定时间）；
● 预算（项目预算）；
● 人力（游戏项目中所分配的人员数量和人员类型）。
在项目中，随时可能发生一种或多种资源缩减的情况，这是无法避免的。通常，这些因素不在测试工程师的控制之下，而是由业务情况或者项目经理决定的。但是无论如何，测试工程师都会受到影响。图1.1显示了项目范围内的资源平衡。
图1.1所示的三角形上的任意一点变动都会挤压项目，造成压力。有时，在游戏项目开始时，某个因素就已经非常小了，或者在项目启动之后的任何时候变小。例如，游戏预算会向另一个游戏倾斜，开发者可能离职去创业，或者公司为了和竞品游戏竞争而急于发布。图1.2显示了预算缩减给项目的进度和人力带来的压力。
图1.1 项目范围内的资源平衡
图1.2 预算缩减带来的压力
另一种造成三角形内部压力的因素是比原计划添加了更多的需求。这个需求可能是内部产生的，例如添加更多的关卡或者角色，或者为了用上最新发布的硬件，把旧的图像引擎替换成新的。为了支持比原计划更多的游戏平台，或者为了跟上最新发布的游戏而添加关卡、角色、在线玩家支持等，测试工程师需要做很多计划外的改变。图1.3描述了在不增加预算和人力的情况下，增加项目需求对预算和人力造成的压力。
图1.3 增加项目需求对预算和人力造成的压力
当项目面临压力时，压力会传递到测试工程师身上。有人会用类似以下的短语来提出要求。
● 我（我们）需要立即……
● 我不在乎。
● 那是过去，这是现在。
● 想办法做出来。
● 实现它。
● 处理它。
● 我们负担不起……
● 没什么大不了的，除非……
你很可能会一次从不同的人那里收集到多个需求，这就需要检查进度、可用的预算和人力，通过减少你通常会做的事情来实现这些需求，从而达成新的三角平衡。请尽可能做最能满足需求的事情。如果使用敏捷开发和测试实践，你就可以在一次次迭代中持续交付工作内容，而不是在一个发布中交付所有功能。
注意
第2章介绍了对测试工程师角色的期待，以及提高游戏质量的方法。
第14章给出了一些高效测试的技巧，当需要执行更多测试时，当需要快速执行、突发执行更多测试时，以及当需要测试更多游戏时，这些技巧会很有用。
连续工作30小时或者一周持续工作100多小时以进行长时间的测试并不是找到缺陷的最好方法，反而有可能引入缺陷！
如果开发工程师也这样，就会让测试工程师忙碌不堪，但是这样对推进游戏发布毫无帮助。测试工程师犯错对项目同样不利。
报告了一个不存在的问题（例如测错了版本、没有正确地进行测试设置或安装等）将导致开发工程师进行不必要的重新评估，从而浪费宝贵的时间。如果你必须在深夜或者周末进行测试工作，那么要在测试前后制订一个清单。如果身边还有其他测试工程师，不妨和他一起互相检查清单。好记性不如烂笔头，记录下测试进行时的相关信息，这样当你记不清的时候，回顾一下笔记就不容易犯错。这有点像制订卫星发射前的测试清单。如果清单里的某一项有问题，那就停止倒计时，回过头来纠正它，并重新测试。等测试结束后，记录下相关的结果和因素。下面是一个样例清单，你可以从这个清单开始，在此基础上扩展，以适应自己的游戏项目。
测试版本正确吗？
测试版本： 。
是否使用了正确的编译版本？
编译版本： 。
是否使用了正确的硬件配置和设置？
描述： 。
是否使用了正确的游戏控制器和设置？
描述： 。
使用了什么安装模式（如果有的话）？
描述： 。
在执行测试前，游戏是否处在正确的初始化状态？
描述： 。
是否按顺序完成了所有步骤？
是否记下了完整的测试和测试结果？
是否记下了你发现的所有问题？
在报告问题时，你是否填了所有必选项？
除了使用常规手段来检查错误，你还要从一开始就寻找策略来避免错误。根据游戏平台和测试环境的不同，采用灵活的测试方法（如探索式测试）可能是一个切实可行的方法，你可以把它作为测试策略中的某些或所有部分的方法。
注意
第15章描述了在项目各个阶段使缺陷暴露的灵活技术手段。
过多关注短期内的事项也是导致恐慌的因素之一。很多游戏项目耗时数月，项目进度是决定今天做什么、怎么做的主要因素。“今天是不是我们最后的测试机会？”对测试工程师来说，这是一个非常好的问题，它提醒我们当前处于哪个阶段。如果回答“否”的话，那么我们将讨论在反复测试的总体策略、测试结果反馈、预算资源等背景下完成现阶段目标的方法。
成功的团队知道如何避免恐慌。处于落后状态时，他们有信心能后来居上，并赢得比赛。因为他们：
（1）熟悉现状；
（2）通过日常训练、比赛录像研究和在比赛中获得的经验准备好了应对方法；
（3）休息充分；
（4）对立刻追上没有压力。
那些有失败记录的团队通常缺失一个或者多个以上因素。
注意
第5章展示了随着项目开发的成熟，该采取哪种类型的测试。这有助于针对特定场景进行适当的测试，并让你知道可以依赖于之后将要进行的其他测试。
表面上看，这是有点怀疑一切的态度。事实上，在项目里引入测试，就意味着有些东西是不能相信的（详细内容见第3章）。游戏项目中测试工程师的存在就是信任问题的结果，例如：
● 发行商不相信游戏会按时发布并具有所承诺的功能，所以他们会根据演示和开发进度来支付报酬，并将其写入合同；
● 媒体和公众不相信游戏会如你许诺的那样好、有趣和令人兴奋，所以他们要求查看屏幕截图和观看试玩演示视频，然后在网上写评论，讨论你的作品；
● 项目经理不相信游戏代码没有缺陷，所以会安排测试，给测试提供资金，并雇用测试人员，包括来自第三方质量保证机构或者团队内部测试部门的测试工程师；
● 发行商不相信开发公司的测试工程师能发现所有缺陷，所以他们可能会雇用自己的测试工程师或者发布一个测试版本供公众试玩并报告他们发现的缺陷。
不要把这当作个人问题，这关系到商业、技术和竞争。投资者投了一大笔钱，势必不想在项目上血本无归。当开发工作开始时，所需的开发技术甚至可能还没有出来，这就给你的团队一个开发史无前例的游戏的机会。通过测试找到游戏缺陷，树立游戏能正常工作的信心。如果发布了有问题的游戏，玩家会抱怨甚至发怒，这会让所有人看到。不要让这种情况在你身上发生。
请评估你的测试计划和测试决策的基础。道听途说、他人的意见和情绪都会使你分神，让你无法专注于你真正应该做的事情。使用测试方法，记录你的工作和结果，这样有助于建立一个客观的游戏测试环境。
评估和分析测试结果（甚至是以前的游戏）将为你提供与游戏相关的优势和劣势的数据。而你最不信任的部分，即劣势部分，在测试、反复测试和分析方面是最需要关注的。图1.4描述了这个关系。
你最信任的那部分，即优势部分，将需要你最少的关注，如图1.5所示。当然，这些部分还是需要时不时地重新测试，来巩固你的信任度。
图1.4 信任度越低，需要做的测试工作越多
图1.5 信任度越高，需要做的测试工作越少
注意
第4章介绍了一些关于评估游戏代码可信性的基本原则。
第7章描述了用平常收集的测试数据来制定评估方法，并介绍如何分析这些评估方法，使其应用到具体的问题领域。
对来自测试团队外部的意见保持警惕。有些人出于善意会提一些走捷径的建议，这样游戏的开发进度可以更快。但是发现不了缺陷并不代表缺陷已被清除，所以不要相信这些人告诉你的话。同时，注意不要越过不信任和有敌意的中间线。整个团队都在努力提供最好的游戏，即使在测试工程师看来不是这样。
要注意这样的陈述：“X发生了，所以Y也会发生/只有Y发生/Y不会发生。”下面是一些例子。
● “只有几行代码发生了变化，所以不需要检查其他地方。”
● “新的音频子系统和旧的工作方式一致，所以你只需要运行旧的测试。”
● “我们为对话框添加了多种语言，所以只需在其中一种语言中检查一部分字符，其余的应该也正确。”
还有如下一些与此大同小异的例子。
● “改动很小，不用担心测试某个功能。”
● “你只要在这里运行1～2个测试，然后告诉我是否正常工作即可。”
● “我们今天就能完成这个，所以……”
小贴士
其他人会建议你应该测试什么和不应该测试什么，如果你做的和这些建议不同，就会发现缺陷的数量非常多。
不要把“不要相信任何人”和“不做任何你被要求做的事情”的态度混为一谈。如果测试主管或者项目经理需要你完成某些功能的测试，请确保自己先尽责完成任务，然后再去关注你不信任的问题。成功者和失败者的不同在于，成功者会说“我已经完成了你的测试任务，并且开始着手锦标赛模式（这里指游戏的另一个功能），在这里发现了一些问题”，而失败者会说“我没时间完成你的测试任务，因为我正在对锦标赛模式进行一些新的测试”。
请检验自己的测试工作，并寻找可以改进的方法，以便对自己寻找缺陷的能力更加自信。永远不要让自信成为自负，更不要盲目相信自己是完美的。请留下一点怀疑自己的空间。对主管、开发人员、其他测试工程师和自己的意见保持开放态度。例如，你正在运行一个测试，不确定使用的是否是正确的版本，就应该去检查一下！有可能你需要重新开始，但是总比报告一个错误的结果，浪费其他人的时间要好。
随着游戏开发的进行，管理层和开发人员希望能对游戏质量满意，从而准备迎接下一个里程碑或者游戏的最终发布。作为一个测试工程师，你不能自鸣得意。请定期激励你的团队，告诉他们“将此版本视为我们发现问题的最后机会”。在是否需要新的测试方面会发生冲突，你会经常听到“重要的问题怎么这么晚才发现”的抱怨。出现这种情况通常有多方面原因，但是和测试是否做得称职无关。以下是你可能会遇到的问题：
● 缺陷是在你发现之前被引入的；
● 早期测试中的缺陷使你无法进入后期缺陷隐藏的游戏部分；
● 随着花费更多的时间测试游戏，你会越来越熟悉缺陷的来源，所以一些难以发现的问题在项目的后期才能发现，这很正常。
不管怎样，即使缺陷从第一个版本开始就存在，那也不是测试工程师故意放在那里的。
注意
第10章和第12章会告诉你凭测试直觉和洞察力测试游戏的方法。
你可以通过一些方法提前了解什么是不可信任的。有时候，只要你提问，开发工程师就会告诉你。
测试工程师：“嗨，比尔，有什么你特别担心的，需要我在测试过程中关注的问题吗？”
比尔：“嗯，我们重新设计了Fuzzy Sword任务的逻辑，我希望你们能关注一下这一块。”你可以通过提到系统的某些部分并观察开发工程师的反应来获得更多的线索。开发工程师转动的眼睛和迟疑的回答会让真相暴露，例如他们有可能怀疑新武器是否会正常工作或者新的多人模式是否像最近一次更改之前那样正常工作。
注意
在第3章中，你会发现为什么测试对游戏的牢靠性如此重要。第3章涵盖了很多导致事情出错的因素，以及作为游戏测试工程师处理这些问题的方法。
如果你一直密切关注这一点，作为一名胸怀远大抱负或者努力工作的游戏测试工程师，你应该会注意到抵抗恐慌的测试方法（不要将这次发布当作最后一次发布）和“不要相信任何人”的方法（把每次发布当作最后一次发布）之间存在明显的矛盾。我们用一种体育运动来类比说明这些概念是如何共存的。
在棒球比赛中，一名击球手不可能在没有一个跑垒手的时候直接得6分。相反，击球手一个接一个上场，一局一局地进行，团队成员根据形势来击球，尽可能打出最高分。击球手和跑垒手保持耐心和善用技巧，严格执行教练的策略，才能获得成功。如果每个击球手都想打出一个本垒打，由于本垒打很难打出，击球手很容易三振出局，而对方投手则精神奕奕地进入下一场。
同时，当每一个成员在击球或者在垒的时候，他都在积极努力地取得最好的结果。击球手需要充分考虑每次投球的类型和位置，正确执行挥杆动作，一旦球被击出，尽可能快地跑垒。他明白这会让团队赶超比分。一分或者打点（打击所得分数，安打、本垒打、牺牲打都可以出打点，打点多少代表对胜利贡献的大小）可能意味着输或赢。
所以作为一名测试工程师，遵从以下的建议，你可以做到两者（这里指的是不要恐慌和不要相信任何人的两条规则）兼备：
● 根据分配给你的职责了解你在团队中的角色；
● 积极准确地执行你的任务；
● 先做最重要的事情；
● 做最有可能发现缺陷的测试；
● 尽可能做理性客观的决定。
注意
第13章描述了如何测试才能让缺陷显现，以便在你的测试中覆盖这些可能性。这也可以帮助你决定哪些测试是很重要的，哪些测试需要频繁运行。
本书的其余章节将指导你在游戏测试中应用这两条规则。不要认为必须把所有事情都结合在一起才能成功。你可能已经是一个非常高效的测试工程师，但你仍可以使用本书中的新见解来改进你的测试技能，并将你从本书第8章～第15章学习到的技术最合理地运用到项目中去。
将这两条规则应用于你在本书中读到的内容。不要过于相信你在本书中读到的内容会对你每一次做的任何事情都起作用。如果你得到的结果完全不合理，请找出原因。尝试使用一些新方法，然后评估效果以决定是继续使用该方法还是改进它，或者是否要尝试其他方法，或者使用最初的方法。但是通过评估之前一定要先尝试。需要提醒的是：在确保合理使用书中的一些技巧之前，不要过于自信。然后你就能够判断这些技巧是否适合你。你会发现这本书里建议的方法很好用。
记住，作为一名游戏测试工程师，每个人都相信你会在游戏发布之前发现问题，所以不要给他们恐慌的理由。
注意
第8章、第9章和第11章会介绍3种重要的游戏测试方法。在开发早期可以使用这些方法来了解游戏软件，并在整个项目中系统地探索游戏的特性和功能。
在本章中，你学习了游戏测试的两条重要规则，了解了它们和本书其余章节的关系。恐慌和信任对成功的游戏测试是不利的。你可以通过记住和应用这两条规则来获得最好的结果。
恐慌会导致如下问题：
● 判断力和决策力下降；
● 不可靠的测试结果；
● 过于强调短期。
恐慌会给项目造成如下损失：
● 不必要的返工；
● 浪费精力；
● 信心和信誉损失。
可通过以下方式避免恐慌：
● 意识到你需要帮助的时候，去寻求帮助；
● 为不可预料的事情做准备；
● 依靠工作流程；
● 充分休息。
不要信任的有：
● 道听途说的事情；
● 某些意见；
● 主观情感。
你可以依赖的有：
● 事实；
● 结果；
● 经验。
测试每个游戏版本，就好像：
● 这不是最后一个版本；
● 这是最后一个版本。
