人月神话-12

是程序编制时间的一半。这个步骤的“重大罪过”是在没有把程序划分成测试段，并对执行终止位置进行计划的前提下，粗暴地按下“开始（START）”。内存转储。本机调试非常有效。在两小时的交互过程中可能会发现一打问题，但是计算机的资源非常匮乏，成本很高。想象一下计算机时间的浪费，那实在是一件可怕的事情。- 80 ------------------------ Page 93-----------------------因此，当使用在线高速打印机时，测试技术发生了变化。某人持续地运行程序，直到某个检测失败，这时所有的内存都被转储。接着，他将开始艰苦的桌面工作，考虑每个内存位置的内容。桌面工作的时间和本机调试并没有太大的不同，但它的方式比以前更为含混，并且发生在测试执行之后。特定用户调试用的时间更长，因为测试依赖于批处理的周期。总之，整个过程的设计是为了减少计算机的使用时间，从而尽可能满足更多的用户。快照。采用内存转储技术的机器往往配有2000～4000个字（word双字节），或者8K～16K 字节的内存。但是，随着内存的规模不断增长，对整个内存都进行转储变得不大可能。因此，人们开发了有选择的转储、选择性跟踪和将快照插入程序的技术。OS/360 TESTRAN允许将快照插入程序，无需重新汇编和编译，它是快照技术方向的终极产品。5 6交互式调试。1959年，Codd 和他的同事 以及Strachey 都发表了关于协助分时调试工作的论文，提出了一种兼有本机调试方式实时性和批处理调试高效使用率的方法。计算机将多个程序载入到内存中准备运行，被调试的程序和一个只能由程序控制的终端相关联，由监督调度程序控制调试过程。当终端前的编程人员停止程序，检查进展情况或者进行修改时，监督程序可以运行其他程序，从而保证了机器的使用率。Codd 的多道程序系统已经开发出来，但是它的重点是通过有效地利用输入/输出来提高吞吐量，并没有实现交互式的调试。Strachy 的想法不断得到改进，终于在1963 年由MIT的Corbato 和他的同事在7090 的实验性系统上实现7。这个开发结果导致了MULTICS、TSS和现在其他分时系统的出现。在最初使用的本机调试方法和现在的交互式调试方法之间，用户可以感觉到的主要差异是工具性软件、调度监控程序和其它相关语言解释编译器的出现。而现在，已经可以用高级语言来编程和调试，高效的编辑工具使修改和快照更为容易。交互式调试拥有和本机调试一样的操作实时性，但前者并没有象后者要求的那样，在调试过程中要预先进行计划。在某种程度上，像本机调试那样的预先计划显得并不是很必要，因为在调试人员停顿和思考时，计算机的时间并没有被浪费。不过，Gold 实验得到一个有趣的结果，这个结果显示在每次调试会话中，第一次交互取得的工作进展是后续交互的三倍8。这强烈地暗示着，由于缺乏对调试会话的计划，我们没有发掘交互式调试的潜力，原有本机调试技术中那段高效率的时间消失了。- 81 ------------------------ Page 94-----------------------我发现对良好终端系统的正确使用，往往要求每两小时的终端会话对应于两小时的桌面工作。一半时间用于上次会话的清理工作：更新调试日志，把更新后的程序列表加入到项目文件夹中，研究和解释调试中出现的奇怪现象。剩余一半时间用于准备：为下一次操作设计详细的测试，进行计划的变更和改进。如果没有这样的计划，则很难保持两个小时的高生产率；而没有事后的清理工作，则很难保证后续终端会话的系统化和持续推进。9测试用例。关于实际调试过程和测试用例的设计，Grunberger 提出了特别好的对策 ，10，11在其他的文章中，也有较为简便的方法 。系统集成调试软件系统开发过程中出乎意料的困难部分是系统集成测试。前面我已经讨论了一些困难产生和困难不确定的原因。其中需要再次确认的两件事是：系统调试花费的时间会比预料的更长，需要一种完备系统化和可计划的方法来降低它的困难程度。下面来看看这样的方法12所包括的内容 。使用经过调试的构件单元。尽管并不是普遍的实际情况——不过通常的看法是——系统集成调试要求在每个部分都能正常运行之后开始。实际工作中，存在着与上面看法不同的两种情况。一种是“合在一起尝试”的方法，这种方法似乎是基于这样的观点：除了构件单元上的bug之外，还存在系统bug （如接口），越早将各个部分合拢，系统bug 出现得越早。另一种观念则没有这么复杂：使用系统的各个部分进行相互测试，避免了大量测试辅助平台的搭建工作。这两种情况显然都是合理的，但经验显示它们并不完全正确——使用完好的、经过调试的构件，能比搭建测试平台和进行全面的构件单元测试节省更多的时间。更微妙的一种方法是“文档化的bug”。它申明构件单元所有的缺陷已经被发现，还没有被修复，但已经做好了系统调试的准备。在系统测试期间，依照该理论，测试人员知道这些缺陷造成的后果，从而可以忽略它们，将注意力集中在新出现的问题上。但是所有这些良好的愿望只是试图为结果的偏离寻找一些合理理由。实际上，调试人员并不了解bug 引起的所有后果；不过，如果系统比较简单，系统测试倒不会太困难。另外，对文档记录bug 的修复工作本身会注入未知的问题，接下来的系统测试会令人困惑。- 82 ------------------------ Page 95-----------------------搭建充分的测试平台。这里所说的辅助测试平台，指的是供调试使用的所有程序和数据，它们不会整合到最终产品中。测试平台可能会有相当于测试对象一半的代码量，但这是合乎情理的。一种测试辅助的形式是伪构件（dummy component），它仅仅由接口和可能的伪数据或者一些小的测试用例组成。例如，系统包含某种排序程序，但该程序还未完成，这时其他部分的测试可以通过伪构件来实现，该构件读入输入数据，对数据格式进行校验，输出格式良好、但没有实际意义的有序数据以供使用。另一种形式是微缩文件（miniature file）。很常见的一类bug来自对磁带和磁盘文件格式的错误理解。所以，创建一个仅包含典型记录，但涵盖全部描述的小型文件是非常值得的。微缩文件的特例是伪文件（dummy file），实际上并不常见。不过OS/360 任务控制语言提供了这种功能，对于构件单元调试非常有用。还有一种方式是辅助程序 （auxiliary program）。用来测试数据发生器、特殊的打印13输出、交叉引用表分析等，这些都是需要另外开发的专用辅助工具的例子 。控制变更。对测试期间进行严密控制是硬件调试中一项令人印象深刻的技术，它同样适用于软件系统。首先，必须有人负责。他必须控制和负责各个构件单元的变更或者版本之间的替换。接着，就像前面所讨论的，必须存在系统的受控拷贝：一个是供构件单元测试使用的最终锁定版本；一个是测试版本的拷贝，用来进行缺陷的修复；以及一个安全版本，其他人员可以在该拷贝上工作，进行各自的程序开发工作，例如修复和扩展自己的模块和子系统等。在System/360 工程模型中，在一大堆常规的黄颜色电线中，常常可以不经意地看到紫色的电线束。在发现bug 以后，我们会做两件事情：设计快速修复电路，并安装到系统，从而不会妨碍测试的继续进行。这些更改过的接线使用紫色电线，看上去就像伸着一个受了伤的大拇指。我们需要把更改记录到日志中，同时，还要准备一份正式的变更文档，并启动设计自动化流程。最后，在电路图或者黄色线路中会实现该设计的调整——更新相应的电路图和接线表，以及开发一个新的电路板。现在，物理模型和电路图重新吻合了，紫色的线束也就不再需要了。- 83 ------------------------ Page 96-----------------------软件开发也需要用到“紫色线束”的手法。对于最后成为产品的程序代码，它更迫切地需要进行严密控制和深层次的关注。上述技巧的关键因素是对变更和差异的记载，即在一个日志中记录所有的变更，而在源代码中显著标记快速补丁和正式修改之间的区别，正式修改是完备并经过测试的，而且需要文档化。一次添加一个构件。这样做的好处同样是显而易见的，但是乐观主义和惰性常常诱使我们破坏这个规则。因为离散构件的添加需要调试伪程序和其他测试平台，有很多工作要做。毕竟，可能我们不需要这些额外工作？可能不会出现什么bug？不！拒绝诱惑！这正是系统测试所关注的方面。我们必须假设系统中存在着许多错误，并需要计划一个有序的过程把它们找出来。注意必须拥有完整的测试用例，在添加了新构件之后，用它们来测试子系统。因为那些原来可以在子系统上成功运行的用例，必须在现有系统上重新运行，对系统进行回归测试。阶段 （量子）化、定期变更。随着项目的推进，系统构件的开发者会不时出现在我们面前，带着他们工作的最新版本——更快、更卓越、更完整，或者公认bug 更少的版本。将使用中的构件替换成新版本，仍然需要进行和构件添加一样的系统化测试流程。这个时候通常已经具备了更完整有效的测试用例，因此测试时间往往会减少很多。项目中，其他开发团队会使用经过测试的最新集成系统，作为调试自己程序的平台。测试平台的修改，会阻碍他们的工作。当然，这是必须的。但是，变更必须被阶段化，并且定期发布。这样，每个用户拥有稳定的生产周期，其中穿插着测试平台的改变。这种方法比持续波动所造成的混乱无序要好一些。14Lehman和Belady 出示了证据，阶段（量子）要么很大，间隔很宽；要么小而频繁 。根据他们的模型，小而频繁的阶段很容易变得不稳定，我的经验也同样证实了这一点——因此我决不会在实践中冒险采用后一种策略。量子（阶段）化变更方法非常优美地容纳了紫色线束技术：直到下一次系统构件的定期发布之前，都一直使用快速补丁；而在当前的发布中，把已经通过测试并进行了文档化的修补措施整合到系统平台。- 84 ------------------------ Page 97-----------------------祸起萧墙（Hatching a Catastrophe）带来坏消息的人不受欢迎。- 索福克里斯项目是怎样延迟了整整一年的时间？…一次一天。None love the bearer of bad news.- SOPHOCLESHow does a project get to be a year late? ... One day at a time.当人们听到某个项目的进度发生了灾难性偏离时，可能会认为项目一定是遭受了一系列重大灾难。然而，通常灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。同样，项目进度经常以一种难以察觉，但是残酷无情的方式慢慢落后。实际上，重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。昨天，某个关键人员生病了，无法召开某个会议。今天，由于雷击打坏了公司的供电变压器，所有机器无法启动。明天，因为工厂磁盘供货延迟了一周，磁盘例程的测试无法进行。下雪、应急任务、私人问题、同顾客的紧急会议、管理人员检查——这个列表可以不断地延长。每件事都只会将某项活动延迟半天或者一天，但是整个进度开始落后了，尽管每次只有一点点。里程碑还是沉重的负担？如何根据一个严格的进度表来控制项目？第一个步骤是制订进度表。进度表上的每一件事，被称为“里程碑”，它们都有一个日期。选择日期是一个估计技术上的问题，在前面已经讨论过，它在很大程度上依赖以往的经验。里程碑的选择只有一个原则，那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。以下是一些反面的例子，例如编码，在代码编写时间达到一半的时候就- 85 ------------------------ Page 98-----------------------已经“90％完成”了；调试在大多时候都是“99％完成”的；“计划完毕”是任何人只要愿1意，就可以声明的事件 。然而，具体的里程碑是百分之百的事件。“结构师和实现人员签字认可的规格说明”，“100%源代码编制完成，纸带打孔完成并输入到磁盘库”，“测试通过了所有的测试用例”。这些切实的里程碑澄清了那些划分得比较模糊的阶段——计划、编码、调试。里程碑有明显边界和没有歧义，比它容易被老板核实更为重要。如果里程碑定义得非常明确，以致于无法自欺欺人时，很少有人会就里程碑的进展弄虚作假。但是如果里程碑很模糊，老板就常常会得到一份与实际情况不符的报告。毕竟，没有人愿意承受坏消息。这种做法只是为了起到缓和的作用，并没有任何蓄意的欺骗。对于大型开发项目中的估计行为，政府的承包商做了两项有趣的研究。研究结果显示：1. 如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着开始时间的临近，无论最后情况会变得如何的糟糕，它都不会有太大的变化。2. 活动期间，对时间长短的过高估计，会随着活动的进行持续下降。3. 过低估计在活动中不会有太大的变化，一直到计划的结束日期之前大约三周左右。好的里程碑对团队来说实际上是一项服务，可以用来向项目经理提出合理要求的一项服务，而不确切的里程碑是难以处理的负担。当里程碑没有正确反映损失的时间，并对人们形成误导，以致事态无法挽回的时候，它会彻底碾碎小组的士气。慢性进度偏离同样也是士气杀手。“其他的部分反正会落后”进度落后了一天，那又怎么样呢？谁会关心一天的滞后？我们可以跟上进度。何况，和我们有关的其他部分已经落后了。棒球队队长知道，进取这种心理素质，是很多优秀队员和团队不可缺少的。它表现为“要求跑得更快”，“要求移动得更加迅速”，“更加努力尝试”。对软件开发队伍，进取同样是非常必要的。进取提供了缓冲和储备，使开发队伍能够处理常规的异常事件，可以预计和防止小的灾祸。而对任务进行计算和对工作量进行度量，会对进取超前会造成一些消极的影- 86 ------------------------ Page 99-----------------------响——这时，人们往往会比较乐观地放缓工作节奏。就这一点来说，它们是令人扫兴的事情。不过，如同我们看到的，必须关心每一天的滞后，它们是大灾祸的基本组成元素。并不是每一天的滞后都等于灾难。尽管会如上文所述，事先估计会给工作进度的超前带来影响，但对活动的一些计算和考虑还是必要的。那么，如何判断哪些偏离是关键的呢？只有采用PERT 或者关键路径技术才能判断。它显示谁需要什么样的东西，谁位于关键路径上，他的工作滞后会影响最终的完成日期。另外，它还指出一个任务在成为关键路径时，可以落后的时间。严格地说，PERT 技术是关键路径计划的细化，如果使用PERT 图，它需要对每个事件估计三次，每次对应于满足估计日期的不同可能性。我觉得不值得为这样的精化产生额外的工作量，但为了方便，我把任何关键路径法都称为PERT 图。PERT 的准备工作是PERT 图使用中最有价值的部分。它包括整个网状结构的展开、任务之间依赖关系的识别、各个任务链的估计。这些都要求在项目早期进行非常专业的计划。第一份PERT 图总是很恐怖的，不过人们总是不断地进行努力，运用才智制订下一份PERT 图。随着项目的推进，PERT 图为前面那个泄气的借口，“其他的部分反正会落后”，提供了答案。它展示某人为了使自己的工作远离关键路径，需要超前多少，也建议了补偿其他部分失去的时间的方法。地毯的下面当一线经理发现自己的队伍出现了计划偏离时，他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。团队可以弥补进度偏差，他可以想出应对方法或者重新安排进度以解决问题，为什么要去麻烦老板呢？从这个角度来看，好像还不错。解决这类问题的确是一线经理的职责。老板已经有很多需要处理的真正的烦心事了，他不想被更多的问题打搅。因此，所有的污垢都被隐藏在地毯之下。但是每个老板都需要两种信息：需要采取行动的计划方面的问题，用来进行分析的状态数据3。出于这个目的，他需要了解所有开发队伍的情况，但得到状态的真相是很困难的。一线经理的利益和老板的利益是内在冲突的。一线经理担心如果汇报了问题，老板会采取行动,这些行动会取代经理的作用，降低自己的威信，搞乱了其他计划。所以，只要项