第十三章 程序与过程.docx
《第十三章 程序与过程.docx》由会员分享，可在线阅读，更多相关《第十三章 程序与过程.docx（24页珍藏版）》请在冰豆网上搜索。
第十三章程序与过程
第十三章 程序与［过程］
＊程序
＊［过程］
＊原始码控制与程式码回顾
＊资讯传递的重要性
＊主动与反应的资讯
在这个章节中，我们将会讨论运用软体工厂的概念之后，若想要在成本效率上有良好的成绩，必须进行的程序与实行事项。
不过，这些程序与实行事项并非受限于软体工厂的范畴，它们可以在所有非琐碎的研发中占有优势。
大部份在研发中的软体（尤其是游戏软体）在研发方式上面并没有真的程序化，一般的游戏企划在成长时，只是从［稍有系统］到［很有组织］而已。
这个章节中提及从管理观点来看研发过程，而管理的部份则是藉由状况报告以进行控制。
满足管理部门的兴趣，是程序与实践的主要理由。
管理者想要取得精确的资讯以及状况的报告，然后以这些资讯来判断未来的行动国，不用打扰研发方面的工作。
同样的，研发者不想让管理者不分青红皂白的介入，并在一连串没有重点、浪费时间的问题下，打断了研发的过程。
这些程序与实践将会包括互动的介面与区域，让资讯可以在随时不断更新的方式之下传送，并定义出控制流程，用来引导研发的方向。
这个［过程］并不见得象您想象的那么糟糕，它大部份都是与常识有关的。
不过，最好的［常识］，就是把它写下来让每一个人都很清楚这边所指的［常识］究竟是什么。
如果每一个人对常识的概念都不同时，它就会碎裂成不同的看法。
这些过程的执行是否要延伸，端看企划的需求而定。
一个很重要的企划，就需要用严格的方式来进行：
而较不重要的，可以用比较轻松的方式来看待。
程序
在这个章节中讨论的程序类别，都是减少劳力浪费的基本控制与方法，并在低品质的成果污染整企划之前，将不良的部份拔除。
下列的程序列表，是在企划的进行时程中，维持精确企划资讯以及控制的建议事项。
每一个程序都在后面的章节中进一步的说明。
＊设计回顾
＊文件回顾
＊技术回顾
＊程式码回顾
＊单元测试
＊整合测试
＊系统测试
＊设定测试
＊后退测试
整体来说，［回顾］行为在找寻与侦测上面，要比单纯的测试来得好；先决条件是把回顾力量集中在找出问题，而不是修正问题。
另一个附加的好处，在于回顾也倾向于找出不同类型的错误。
回顾
回顾的格式大体是相同的，只不过回顾的东西不一样。
二种类型的回顾有［正式］与［非正式］。
要进行哪一种类型的回顾，端看工作的本质来决定。
这个工作与内容有密切的关系，而且正式与非正式的比率，也是由情况来决定（这一切通常是由企划管理者在分派工作时决定的，但是个体的贡献也有可能影响这个决定）。
不管怎么说，企划管理者知道工作究竟有多复杂，所以他（或她）应该可以说明哪些东西需要回顾一下比较好，重点是没有什么工作可以不经过查核的手续。
回顾通常是在一个企划受到时间压力时，第一件半途而废的事情；这通常是一件大错误。
省下这一点时间，通常会造成长期有痛苦。
只是把没经过查验的工作插入企划中，然后发现没有倒塌就认为一切OK，算不上什么好事。
这种［方式］并没有在企划时程表中，指出会出现的任何难题，更没有告诉您这些工作是怎么完成的。
回顾可以让您在早期的阶段中，拔除任何明显的错误――在他们进入企划之前――而且对于预防低于标准以及虚有其表的工作而言，这是最好的方式。
在一个不进行回顾过程的企划中，低水准的工作会变得难以侦测并存在很长的时间。
这种类型的问题会等到很久之后才显现出来，通常是在某些人修护或是更新受影响的地区时才会发现。
在这个时候，又有谁知道这个毒害扩散的范围？
后期的工作可能是以这个反复无常的原始工作为基础，导致邪恶长存。
回顾还有其他的好处：
它可以让所有的员工共享并散布相关的知识。
由于这个工作会在一个小组中进行讨论与回顾，这些知识会传播到所有人之间，大量的降低了风险。
非正式的回顾
非正式回顾很简单，完全没有真实的纸上作业，也没有复杂而耗费时间的会议。
一个非正式的回顾包括了把数个小组成员集合在您的萤幕旁边，然后与他们讨论您的工作，如果能进行一段排演会更好。
这些回顾可以用数个不同的方式来完成。
举例来说，在一个非正式的程式码或是设计的回顾中，您可以选择几种不同的方式，象是简单的排演与视察，虽然这些作法一样可以在正式的回顾中运用。
排演是由这个工作的作者来指挥，主要的作用在于可以用很简单而且容易了解的方式进行回顾工作。
排演的优点在于快速而简单，而且它可以忽略掉工作中的科技品质。
这并不是一个真正的评估，比较象是一个评议请求（requestforcomments,RFC）。
这也是一个分享技术与经验的好机会。
如果一个回顾原有更好的点子以及更佳的工作实施方法，也可以在这边传达给作者。
这种交谈也是很正当的；有时候回顾员工会学到一些新的技巧。
讯息的传递协助了分散大量知识到所有的人身上，所以会降低小组对单一人物的依赖。
在理论上，每一个员工都应该努力淡化本身的地位，没有一个人是绝对重要的。
很明显的，以这种方式来工作，管理阶段不应该在任何人身上加诸压力与紧张；要让一个人做出更多的事，就在他身上加诸更大的压力，这种观念是错误的。
要让人们全力表现出他们的能耐，他们必须尽可能的放轻松并有安全感，而且还要了解他们在做的事情，需要在期限之前完成的重要性。
这已经造成足够的压力，而不用靠着管理阶层来做额外调整。
不过，排演并不一定都是乐观的，因为在一个回顾过程中，大多是以最没效率的方式来进行。
在统计学上来看，排演的有效程度有很大的变动，能打到的错误比率可能在30%到70%之间。
其中的一位回顾员通常是您的技术管理者，而他（或她）可以让您的工作有保证。
在这方面完成之后，只要有任何主题（或是问题）在讨论并解决之后，就可以插入企划的主要贮藏室之中。
这边很重要的一件事是，技术主管不应该在这边以管理的权威施压，否则在作者觉得有必要让他的作品发扬光大、证明他自己的同时，会让结果变成其他的东西。
这件事并没有发展到这个程度的必要，它的目的只是讨论工作并侦查出任何明显的错误。
从另一方面来看，视察几乎是排演的相反。
这并不是与作者谈论并一路看完工作内容，而是要技术管理人员拿着韁绳并看着排演进行。
这边需要以全新眼光来看工作内容，可能有助于发现作者遗漏掉的问题，这是因为作者［太熟悉］作品所导致的。
不过，缺点就是这一类的视察要花漫长的时间来进行，不过至少它有很大的机会找出错误。
如果在回顾的过程中，有人找到了问题并靠着一些动作或是变更修正，那工作内容就需要原来的回顾员再回顾一次，包括那个第一次提出要求修正事项的人员。
这个随后而来的回顾是否正式，必须靠着它的本质来决定。
庞大的变更需要正式的回顾，但是较小的调整以及改善只要非正式的回顾就行了。
至于变更控制，它本身就是一个庞大的主题，将在第14章中讨论。
非正式回顾的危险在于它们有可能变得太不正式。
所以，在一次回顾中经常指派出负责人员，是一个较好的方式。
这个非正式回顾也是正式回顾的一部份。
一个没有效率的非正式回顾可能比完全不回顾还糟糕，它会逐步把错误的安全感小组之中，导致最后出现大麻烦。
正式回顾
通常在一次回顾中会包括四到五个人。
这一个回顾小组的人员，是从合适的群组领导者中遴选出来，而且先前的负责人员也应该包括在内。
只要有任何没效率的东西，就会让所有东西都没效率。
作者的责任就是确保所有的回顾员都充份了解他们要看的东西，才能展开这场回顾；这可能包括影印好的工作内容，并回答任何回顾员在进行之前的所有问题。
回顾员的责任就是确保他们十分熟悉要回顾的东西。
回顾会议真正的目标并不在这个成品上面，这会花掉太多的时间。
回顾会议的目标是让回顾员在会议之前，详加讨论要回顾的内容。
所以，在会议之前回顾员应该完成一份回顾表，列出他们想要在这个会议中提出的重点。
视回顾的规模大小，他们应该要花一到二小时的时间，看完相关的资料。
一个简单的回顾将在第15章中提出，其中包括的RTF（RichTextFormat）文件已经附在本书的光碟片上面。
基本上，回顾表是用来提醒回顾员，让他们不致于忘掉任何要观察的东西。
结论将写在列表中，并以不同程度的严厉眼光来看待，象A是最严重的错误，而E是最小的问题（当然了，您也可以选择适合您自己的分级方案，但这种方式最为常见，而且最容易了解。
这简直象是回到学校一样！
）
工作的内容应该以数个标准来回顾，其中的［符合需求］是最重要的一点。
这才是我们应该要求的东西。
能够与企划和公司标准相符也是十分重要的，但是功能很明显是第一优先事项。
在会议中，回顾表上的每一个要点都要提出来讨论。
这个会议将从负责人员的展示开始进行，这一场展示将会概略性的说明工作内容，并开始讨论其中包涵的东西。
很多人遗漏的一点是，在一个回顾中的批评并不是针对任何人，或是对完成工作的员工进行人身攻击。
回顾的目标是取得第二种意见，把工作中出现的问题拔除。
让一群人专注于一个想法，可能会更容易找出问题所在。
这个回顾应该集中力量于找出问题；这个会议并不是用来讨论解决方案的。
这样做只会让所有人分神，目前并没有必要把所有的问题都解决掉。
回顾会议的真正本质，事实上就是钜细靡遗的找寻错误。
它只是在一场独立的回顾会议中，利用讨论来进行资讯分享的时刻。
在回顾的过程中，其中有90%的错误是在会议之前找到的。
一旦在回顾表上面的所有重点都讨论完之后，他们就可以进入［行动状态］。
基本上，这些要点不是被接受，要不然就是遭到拒绝。
如果它们被接受了，那么作者就必须进行校正的工作，来满足提出这些要求的人。
如果有超过一位回顾员提出相同的缺点，只有其中一个会取得问题的［所有权］。
他们考虑到的所有重点都必须合并成一个电子回顾表，将与工作一块储存起来，以待日后查验。
如果这些变更会显著的影响功能（例如它牵涉到其他的区域），那就有必要召开一个变更控制的会议，讨论任何逆向效果中的控制与限制。
视需要变更内容的本质，可能必须进行另一次正式的回顾。
在这种情况下，应该运用同一组回顾人员。
如果所需要的变更级小，那一场非正式回顾就应该足够了。
作者需要让每一位回顾员在他们指出的要点上签名。
一旦这一步完成之后，工作就可以插入企划的主体中。
这一切听起来象是一场冗长的过程，而且――说实话好了――的确如此。
不过，我已经发现只要能预防次水准的工作进入企划，那就可以大幅节省您花在回顾上的时间。
我也发现了一点，如果有人知道他的工作会被人拿来回顾，他们在工作时就会更加小心并注意各个细节，而且对他们所做出来的东西更为自豪。
这可以增加注意力，对士气有正面的好处。
人们知道他的工作在检查之后即将纳入企划，所以企划代表了更高的标准（而且风险也会大大的下降）。
在这些理由下，回顾大约可以增加20%的生产力。
绝对不要低估提升员工士气对输出结果的正面效果。
由于游戏研发的本质，执行回顾的工作会受到一般性的抵抗。
要压制这种抵抗的最有效方式，就是收集回顾中找到的错误，然后算出找到每个问题的平均时间。
把这个统计数字，与研发后期修正这些错误所要花费的时间（与金钱）相比较，就没有人说得过您了。
一般测试
如同我看过的很多企划都没有回顾系统一样，我从来没有看过一个没有测试系统的企划。
我看过很没有测试效率的企划，而且这些通常很容易发现。
当游戏推出后处处都是臭虫时，它通常有一到二个理由：
这个测试就是够不上水准；或是研发小组的时间用光光，发行公司已经受够了，所以一定要把它丢上市面，不管里面有多少臭虫。
在这边，我们先来考虑第一种剧本：
次水准的测试。
测试是找寻错误的过程，您在程式码中预期可以找到多少错误？
就算是陪审团也无法得到一个正确的数字，但是在业界中粗估的平均数字，是每一千行的程式码，会出现15到50个错误。
在游戏产业方面我会稍微高估一点，虽然这方面可能会视游戏是小型或是中型企划，而有所不同。
测试是在找寻研发任何阶段中，可能发生的数种错误：
但是，一般来说，测试可以侦测出来的错误，只限于原型与程式设计的阶段中。
请牢记这一点，只要一个错误没有被抓出来，时间越久要修正它的费用就越高。
如果在设计阶段出现一个错误，在实施到一半时才要修正它很显然要比在设计阶段中，把它抓掉更费时费钱。
事实上，这是实施这个过程的主要理由。
它可以让您试图去［相位牵制］；不是，这不是与［星舰迷航记］有关的东西（虽然它应该也是）；这边的相位牵制，表示您要在创造的阶段去侦测并修正其中的错误。
一个标准的统计指出，在创造时发生的错误如果没有抓出来，事后的修正要花费将近200倍的时间。
很明显的，侦测并修正错误的动作越早做越好。
同时，也要记住测试本身并无法影响软体的品质。
尝试藉由测试来加强软体的品质是没有用的；它的作用只不过是品质的指标。
它后面必须附带着决定性的方式，才能加强品质；让这些额外的效果反应在下一个测试过程中。
在这部份提及的测试，指的是针对程式码；所以下列的章节中，指的就是程式码的测试。
非正式的测试
［非正式的测试］与［非正式回顾］指的并非同一件事。
这边并没有必要把一群人聚集在萤光幕前面，因为非正式测试只是任何研发者，在进行程式码模组研发时做的测试。
每一个研发者在撰写一个程式时，都会周期性的将程式码编辑并进行测试（至少我希望如此！
）这是一个很好的出发点，但是这并不足以预防爬进程式中的臭虫――尤其是在模组整合的阶段。
大部份我看过的游戏研发企划中，只有运用到这种类型的测试，再来就是让一个有活力的人进行游戏测试，一直延续到企划结束为止。
这通常只能勉强合格。
为了加强非正式的测试，有为数不少的自动错误侦测应用程式（象是NumegaBoundschecker）以及程式设计的技巧，可以用来找出明显的错误。
它真的有用，但是如果能再加上一些基本的测试程序，这个风险可以明显的降低。
虽然是否要进行正式测试，必须看工作的本质来决定，所有在这边讨论的测试阶段，都应该以一种或是其他的形态来实施。
正式测试
正式测试十分类似非正式测试，只不过它们比较具有结构性。
一个特殊模组所提供的测试描述，将用来对这个模组的所有功能与特色，进行耗损性测试。
这段描述通常是由该模组研发人员中的软体规划师所撰写。
测试描述是以一种特别的方式来撰写的（一个简单的测试描述将在第15章介绍，而且以RTF格式的文件放在本书的光碟中）。
这个测试应该是设计用来执行这个模组中的每一条程式路径。
因为要完成这个工作并不是简单的事，所以测试描述本身也是回顾的重点之一。
三种主要的测试可以用这种方式完成：
正向、负向与特别。
正向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。
一个正向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上看到正确的三角形。
负向的测试是在检查预期的行为，所以这些测试是写来让模组产生预期结果的。
一个正向测试的例子，是对一个专门用来画三角形的模组传递一连串的方位，并预期在画面上看到正确的三角形。
负向测试则是查看没有预期到的行为，而且这些测试是针对产生例外而且还能控制的错误状况。
一个负向测试的例子是对一个专门用来画三角形的模组传递三个相同的数值，或是排成一线的三个点。
这时应该可以测试临界的状况，在您送出三个很大的数值（正值或是负值）时会出现什么情况？
那一串很小的数值呢？
或是送三个零进去？
在规划测试时，试着考虑各种不同的输入值丢入系统，不管是有效或是无效的数值。
这些物件将以各种可能压迫系统；把您找到的任何东西统统丢进去。
您可能发现并非所有东西都会出错，但是您可以除掉其中最麻烦的问题。
特别测试是乱数的效果。
测试者要玩弄模组，并查看他（或她）是否得到预期的结果。
这些测试只是把一些测试者想要的东西丢入模组，举例来说，他可能把一组乱数产生的点丢入绘制三角形的模组中，并查看输出的三角形是否正确。
很多组织只会使用这三种模组的其中之一，但是要进行真正有效的测试，这三种方式都该使用。
如果一个测试模组已经写好，可以把这三种测试隔离测验，那就应该让测试者可以任选进行的测试项目。
当您在执行一个测试描述时，结果应该以电子档的方式记录下来。
这些测试应该以文字说明，让结果可以表达出［真］或［假］的回应。
在一些例子中，需要进一步的描述才能得到正确的结果（尤其是在测试失败时）。
如果一项测试失败，那么就要进行下一步的行动。
一项测试的失败理由不外乎二项：
问题在于程式码，或是在于测试。
这二者所采取的行动都是一样的，测试者站起来回报问题，并展开修正问题的工作。
单元测试
单位测试是研发者进行的第一波测试行动，而且它是一种开箱测试，表示测试者完全了解要测试对象的从里到外。
从统计学中显示，在平均的情况下，单元测试可以在程式模组中，找到将近一半的错误。
单元测试通常是以严格的方式来进行，它会设计一个简单的程式，该模组中的每一种功能动作。
这可能简单而且没有互动性，或是它会更为先进并容许设定输入的参数。
单元测试的用途如字面所示：
它是在隔离的状况下测试。
这可以预防其他方面的互动，象是容易出错的模组。
这就是为何要限制测试环境的原因，而且也是为何这个限制的测试环境要越简单越好。
有好几次我在测试结果中找到错误，最后发现它居然是源自于我所使用的资料！
如果您在程式码中找一个虚幻的问题，最后发现是您输入的测试资料出错一定会让人心灰意冷（我试着将它看为提升经验的练习，我真的这样做了，但是我不会建议把这种过程，做为判断您神智清楚的举动）。
单元测试可以在数个不同的层级中施行。
如果我们拿C++做为例子，那单元测试可以在模组的层级或是物件层级中进行。
对那些不熟悉物件导向科技（您之前看的是什么？
）的人而言，一个物件是一个逻辑性的资料与程式码封包，可以用来处理资料。
这个程式可以分为许多方法，类似于程序化程式设计的功能。
物件等级的测试是一个黑箱测试，而方法层级测试是一个开箱测试。
当然了，测试无法保证模组中不会有任何错误。
一个测试只能证明模组中有错误，但这就是要牢牢记住的重要规则。
如果一项测试显示出模组中没有错误，那比较可能的情况，是这个测试本身不适用。
或许它没有包括了足够的状况，也可能测试本身有问题。
要让研发者的想法倾向完成的东西非测试不可，实在有困难。
一个成功的测试可以找出破碎的程式；您所认识的人，又有几个人愿意主动把自己的程式打破？
事实上，这是一个别有含意的问题，而答案应该是所有人。
如果不是的话，那这些研发者还不够彻底。
不幸的是，我注意到一些研发者在写好程式之后马上宣布他写完了。
他们似乎很厌恶在自己的程式码中找出错误，就象这个举动会指出他们的弱点一样。
这一点在游戏产业中特别盛行，让软体之狼四处横行。
在某些公司中，指出任何迹象的弱点，象是取得把东西撕碎的特权一样，只留下您被四分五裂的尸体，被兀鹰吃得一干二净。
每个人都会犯错，这是很自然的事，但是它代表的不只是一个错误：
您是要在自己的程式码中找寻并修正一个错误（承认您自己的失败），还是要拒绝接受您会犯错的事实，甚至不想全面检查？
研发者应该主动查看并打破自己的程式码。
他们需要进行测试，假定程式码是一个有臭虫的謎题；事实上，他们应该真的想要找出错误。
用这个角度来看吧：
您宁愿让谁找出您程式中的错误？
您，还是其他人？
如果您先假定不会找到任何问题，那就有可能找不到任何问题。
这并不是因为真的没有错误；这是因为研发者不愿意仔细而且努力，去注意该注意的地方。
整合测试
整合测试是研发者会进行的下一阶段测试，虽然它也可以由其他的组合来执行。
如果由一个测试小组的成员来做这件事，那这就是一个黑箱测试；如果是由研发者来进行测试，就是一个开箱测试（在进行整合测试时如果能由研发者与小组中测试者同时进行更好。
不过，整合测试是介于单元测试与系统测试的中途站，所以这并不是一个严格的规则）。
整合测试是测试新的程式模组，与现有程式基础是否能够整合的测试动作。
它会造成组译上的问题吗？
名称领域是否出现碰撞？
它真的有作用吗？
这个程工测试――在必要性上面――并不需要单元测试那么详细，因为在这个测试中，要看的就是模组在程式环境下的运作情况。
您几乎可以把它形容为模组的［实战演练］。
整合测试的焦点在于解决一个新模组整合进来的技术问题。
在理论上，模组本身应该在单元测试之后已经没有错误。
在整合之中，一些在单元测试中没看到的问题，通常会以十分明显的方式出现。
这些可能会让人倍感挫折并很难查出来，提供您一个正确的动机，在这个阶段之前把所有的问题尽可能摘掉，而且您绝对不会把这些问题留到系统测试的阶段。
如果您觉得在整合阶段进行错误诊断十分困难，那您应该试试到系统测试中找出一些小小的臭虫再来说这句话！
这个测试应该与单元测试差不多，应该写好一个描述，来执行每一条程式路径。
在整合测试中的一个严格的规则是，一次只能整合一个模组。
这是一个简单而明显的规则：
如果您把二个以上未经测试的模组同时整合进来，在找出问题的来源时，其困难程度将会以指数曲线上升。
它们可以到处都是错误，或者它们可能在相互作用之后，以未预期的方式来运作。
不管是哪一种，都是您绝对不想踏入的领域。
好消息是，利用物件导向结构的系统整合，并不会比早期的古老日子中，采用程序化的程式设计难到什么地方去。
物件导向技术可以让所有的东西都简单点。
游戏研发在采用这些技术上已经慢了一步，主要是因为物件导向应用程式被认为是慢火炖煮的软体，而且在编辑时大家都认为产生出来的程式码很没效率。
这些在早期的恶劣日子中或许没错，但是因于现在这个时代已经可以与作业系统合作；如果一直抱着把系统每一分效率都逼出来的想法，会越来越困难。
除此之外，靠着物件导向API（象是DirectX）扮演将游戏与基础硬体加以隔离的角色，运用程式语言让研发更为容易，是比较合理的作法。
一旦整合测试完毕，这个模组就可以签名了，它已经是基础程式的一部分了。
系统测试
系统测试是一种至少要每天做一次的事；如果这不可行的放在，最少也要每星期进行一次。
如果比这个频率更长，系统测试就会失去它的效用。
程式码在每星期的变动量实在不小，如果要修复破损的程式码，却有其他的程式已经改变或是其他程式码以它为基础时，就是一件大工程了。
系统测试的频率指的就是这种事情，在某些状况下，并不是所有系统都可以进行测试。
这通常只有在最大的企划中才有执行的需要，而且大部份的游戏应该可以每日进行系统的测试工作。
为了方便起见，这个软体需要每天都处于可以扩建的状况。
事实上，这是最主要的需求，不论系统测试是不是每天都要进行。
这个软体应该在可以扩建的状态下，并不是指它要发挥所有功能；子系统可能还没写好，在这种情况下应该把它关掉。
在这边指的［关掉］应该是由界面所定义的，但是目前还没有这个功能，所以它必须转换成［关掉功能］并输出一个除错的讯息，或是出现一个预期的错误，视这个界面的重要性而定。
这个结构已经大部份都完成全面定义，让研发者可以轻易的取用。
扩建刚开始时，会由测试小组来一个烟雾测试，看看它是不是够稳定。
这边的烟雾测试是从电子工程方式中引用而来的，用来测试刚建好的装备，看看它是不是会运作：
他们把开关打开，如果它开始冒烟，就表示没有用。
如果没有通过烟雾测试，这个成果就会被退回。
研发者在修整这个扩建的东西时，具有最高的优先权。
这个东西损毁的时间越久，表示测试小组浪费的时间越多。
这并不是一个好状况。
一旦这个成果开始运作，它就可以在资源控制系统中贴上一个标签。
所有好的资源控制软体，都可以让您什对内容做一次［快照］，就算它有更新的档案在后期加入也能重新创造。
每天制作一个快照是十分重要的，因为它可以确保测试小组在这个成果上面再多花一天的时间。
为这部份安排一个合理的每日行动系统，可以保证所有研发者在下午三点都签好名字。
完成的程式码与模组就可以从资源控制系统进行查验，然后进行全面的系统建造工作。
同一个下午就可以进行烟雾测试，而且系统测试也可以在接下来的几天由测试者施行。
扩建一个游戏的时间要受到限制，才能让系统测试者有时间进行所有的测试。
系统测试应该在二种层级中运作。
第一个层级是执行测试描述，来检查是不是所有完成的功能都如同宣传般运作（这是系统测试中，有效的正向与反向测试）。
这些测试的描述写法，很象是按照软体结构撰写的：
在这个层级的测试中，主要在于结构设计的错误，而不是低级程式码的错误。
当然了，有些在整合测试中没出现的问题会在这个地方冒
升级会员 