第一次给大家分享书，我其实是一个不太爱看书的人，这本书我刚开始看的时候，就有一种内心被读懂的感觉，有工作经验的小伙伴，看了肯定会有和我一样的感觉。这本书我没法去形容，只能说我看到的太晚了，看了下出版时间2007年，真的太强了，如果我刚入行就看了的话，应该会少走很多弯路。
下面贴上书的正文，让大家感受下这本书的魅力。
※
※
※
第1章
游戏测试的两条原则
每当我开始指导一个新的测试团队或一名新的测试员，我都会给他们两条原则：
原则1：不要恐慌
原则2：不要相信任何人
1.1 不要恐慌
恐慌对一个游戏项目来说十分不利。恐慌的人往往并不想恐慌，但他也许无意识地就会产生恐慌。这是人应对一系列复杂情景时做出的非理性反应，但这会使测试员做出对项目不利的事情。一般情况下，当我意识到测试员对某一复杂的要求做出不恰当的反应时，我通常会问他“原则1是什么？”从而间接地提醒他不要恐慌。
虽然测试人员无法避免有时会对错误的构造进行测试、无法发现重要的缺陷，或将错误的游戏缺陷报告给开发者，并且已经为此而身心疲惫。但比起要付出额外的时间代价、花费额外的金钱、销售受到损失，以及名声收到损害来，这些是值得的。
通常当你处于以下处境时，恐慌就会发生，
l 不熟悉
l 未准备好
l 处于压力之下
l 不安
l 只能看到短期目标
1.1.1 不熟悉
作为游戏团队的一员，你可能被要求做某些你以前从未做过的事情。比如，有可能你要测试一个别人也在测试的项目，或被安排到一个不同的游戏项目中，或在最后时刻被告知替别人去为客户做演示。在这些处境中，根据你所掌握的知识，坚持一定的基本原则，然后通过观察别人如何做事来不断地学习新的、不同的做事方法就可以了。
有时，你甚至会被要求完成你以前从未做过的事情，；例如做一个100%的自动安装测试，或者在游戏中编写一个工具软件来验证外文文本。由于之前也许没有这样的先例，所以不要立马做出承诺，也不要拼凑员工，更不要努力去做英雄。如果你对某一处境不熟悉，要依据你的最佳判断来行事，即使这仍可能错。这就要求你有一个好的“雷达”来为你寻求足够的帮助，同时你也要表现出谦卑的一面，这样你不会使得任何事情都得你自己来承担或由你来定夺，你也不会失去任何威信或权力。你要做的就是顺其自然地引导你的下属，让他们找到有效的解决办法。尽量远离那些明知会失败的做法。你可以上网搜索去看看是否有人有相同的经历以及他们是如何解决的。
1.1.2未准备好
任何人都不希望许多意料之外的事情出现在自己的项目中。但测试人员必须考虑这些不可预料的事！在游戏的生命周期中，游戏的许多部分需要在不同的点得到测试。在幕后，许多不同的技术在运作—如三维图形、音频、用户界面、多线程和文件系统等。如果你没准备好去完成一系列的测试任务，不具备成功地完成这些任务的技能，你就只会犯错而不可能成功。
学习、实践和经验是必备的要素。在项目完成期间，应尽量去弄懂更多的游戏代码。并跟上产业的发展，这样你也能知道下一代游戏和技术会是怎么样。你可以努力成为游戏中你负责测试的部分的需求分析和设计方面的专家，并同时熟悉游戏中的其他部分。这样，当你可能需要适应不同的职位，或暂时代替另一个测试员，或承担更多的责任时，你就游刃有余了。
1.1.3 处在压力下
压力来自三个方面：
l 进度表（完成项目的时间）
l 预算（花在项目上的金钱）
l 职员数（分配来设计游戏项目的人数和人员类别）
项目在执行中，很有可能出现一个或多个资源的紧缩情形。作为测试员，这些要素不会处于你的控制之下。通常它们由商业情况或项目经理决定。不管事哪种情况，你都会受到一定程度的影响。图1-1所示的是项目范围内资源处于平衡时的情形。
移动三角中任一点都会使项目不稳定，导致压力。有时，一个游戏项目开始时这些要素中的一个会欠缺，或项目开始之后某一时刻它们可能变少。例如，经费可能转移到另一游戏项目，开发者可能离开而开一家自己的公司，或者时间表要求你赶在一家竞争对手的游戏软件发布之前发布你的游戏。图1-2表明预算减少会对游戏项目的时间进度和职员数产生压力。
从这个三角看，另一种产生压力的原因是比原来的计划的需求要多。这个需求可能是内部造成的，例如增加了更多的游戏关卡或人物，或废弃旧的图形引擎，换个新的图形引擎，以体现某一新公布的硬件特性。另外也有一些其他没有列入计划的变化，比如为了使游戏比原计划能支持更多的游戏平台在游戏管卡、人物、支持的在线玩家人数等方面跟上新发布的游戏潮流。图1-3展示了项目内容增加时对没有增加的预算和职员数所造成的压力。
只要这个项目中存在压力，它就能通过人与人之间的交流体现出来。比如，需要你做什么时，他会使用如下词组：
l “我/我们立即需要…….”
l “我不管……”
l “此一时，彼一时”
l “想想具体怎么做吧”
l “请着手实现它”
l “尽快处理它”
l “我们负担不起……”
l “别的都不重要，但……”
有时，你可能一次要处理多个任务，并且由不同的人指派。此时应检查项目的时间表、预算和职员人数。可以通过降低你通常的标准来满足这些要求，以便于能适应新形成的三角形。最大程度地做最能影响满足需求的事情。然后，再留意那些要赶上进度的事情。
1.1.4 不安
对于长时间的测试，高强度地连续工作30个小时或一周工作100个小时以上，不是找到游戏缺陷的最佳方法。但是，这却是导致缺陷产生的好方法！因为当开发者这样通宵达旦地工作时，测试员也必须和他们一样，但这并不会对游戏的发布产生什么帮助。这跟测试员犯错一样，对项目而言是非常不好的。
若测试员报告了并不存在的问题（例如，由测试错误的构造，没有安装或安装不规范等导致）会给开发者带来麻烦，浪费他们的宝贵时间，如果你必须得在深夜或工作时间很长的一周之后再做测试，请在测试前和测试后列一个清单。要是还有别的测试员在场，可以让他们帮助检查你的材料，以后在他们进行测试时，你也可以反过来帮他们检查。通过一边工作一边记下测试信息，即使以后因怕疲惫而记忆模糊，你也不会犯错。这类似于发射太空飞船前列的清单，一旦出错，就停止倒计时。退回去改正错误—就像测试说明中所说的一样，做完测试后，记录相关的结果和事实。下一页有一个清单示例，你可以依照它列一个自己的清单来适应你自己的游戏项目。
除了通过实践来检查错误之外，还应该寻找能够在第一时间就阻止错误发生的途径。借助你的游戏平台和测试环境，要实现不间断地重复工作，自动化也许是个可行的选择。甚至当你在家休息时，自动化的任务也能运行。
1.1.5 只能看到短期目标
恐慌症包括更多地关注短期目标。许多游戏项目要花费数月的时间，因此这是一个成为决定你今天要干什么和怎么干的因素。为了使测试员恢复其正常的思考，我常问的一个问题就是“这是我们测试这个游戏的最后机会吗？”如果答案是“不”，然后我们就根据重复测试、从测试结果得到反馈和资源预算等制定的整体策略讨论如何才能接近当前的目标。
一个成功的体育运动团队知道怎样避免恐慌。当他们落后时，他们有信心能从落后的状态扳回比分并赢得比赛，因为他们熟悉情况、了解处理这类事情的方法、镇定，且不使自己感到压力。而有失败记录的团队通常缺乏一个或多个这类要素。
1.2 不要相信任何人（这一句真的是测试至理名言）
