【导读】软件开发由于是人为的设计和开发过程，发乍缺陷很难避免，传统软件工程做法足通过软件测试，控制软件存在的缺陷。在本文中我们讨论通过实施有效的评审和检查以及软件测试活动，控制软件交付后，存在较少缺陷。1 引言　　每个产品都会有缺陷，在软件开发过程中应争取尽早发现缺陷，开发的时候提高软件质量要远比开发完成 后再进行测试更为有效。一般对软件开发主要控制缺陷手段是进行测试和检查，在一定程度上可以确保不让不 合格产品交付到用户手里，然而能够保证最初制造的产品就是一个合格产品吗能将质量测试融入产品中去 吗实现起来比较困难，而且只能在开发的结束才能进行测试。其实这不仅是改进软件流程所独有的现象，也 是目前软件开发共同面临的问题。要想得到高质量软件， 重要的是将质量设计到软件中。这比如何设置质量保证 部门、向谁报告、独立测试、需要进行什么样的评审等事情重要得多。要想在软件开发的每个阶段都注重质量需要有一个流程进行管理，大多数软件流程改进模型(像CMM和ISO9000)都认为有效和正确的流程必然会导致生产出高质量软件。我们有理由相信有效的流程肯定能制作出一开始就能正常工作的高质量软件。下面先介绍缺陷管理的基本原理，然后讨论软件在产品开发周期中的验证和确认，特别是所采用的评审、检查和测试技术。2 缺陷管理　　软件中一般会有问题和缺陷，其实这都是一些由开发人员造成的软件错误，这些缺陷实际上在开发过程从 提出要求到进行维护的任一阶段都可能造成。假如适当条件永远不发生而没有触发执行有问题代码的话，缺陷 就将隐藏下去，否则它们会暴露出来而造成失效。失效的严重程度不尽相同，最坏情况下失效可使系统崩溃或 者系统功能不正常，而轻微时失效仅仅使用户感到不方便或不满意而已(如响应时间太慢或者接口使用困难等)。　　当然还是应该尽量避免缺陷，关于缺陷管理有两个指导性原则。首先，在最初阶段就要避免造成缺陷，可 以通过在产品开发周期每个步骤都使用正确技术做到这一点。第二个原则就是在流程中尽可能早地检测出缺陷，一旦检测到就要从源头处把它消除掉。这就是说如果缺陷是在低层设计中造成的，就应在此时把它消 除，最好在编码开始前。　　时间拖得越久，消除和修复缺陷的费用就越高。研究指出，缺陷在产品开发周期晚期发现其消除的费用将 会急剧上升。为避免缺陷，需要针对软件开发每一阶段的特殊技术进行培训。　　通过评审检查的验证和确认活动，是缺陷形成后尽早检测出来并从源头处把它消灭掉，这样做不仅去除缺 陷的费用更少，而且使我们相信质量已被制造在产品中，而不是直到装运前才将高质量产品筛选出来。通过评审就是在每一阶段对软件进行评估，以保证它符合前一阶 段所提出的要求，同时，通过在开发工作完成时对软件及其技术指标规范进行测试，以保证软件符合总体要求。3 评审和检查　　有人说技术工作需要进行评审就如同铅笔需要橡皮擦一样，因为人总是要犯错误的。在开发过程的各个阶段进行评审，如果软件开发时没有定出精确要求，则根本不可能通过评审或其它方法验证设计是否准确，因为此时设计不是根据要求做出而是孤立的，任何对缺陷的判定最终都是个人观点。因此评审和检查首先假设软件开发过程已有严格的要求。评审每个开发阶段的中间产品有两个基本作用。首先，我们能在早期检查出缺陷并在修改费用较低时将其消除掉；其次，这一点可能更重要，我们能够在公司内部改变流程，在软件开发最初阶段就提出大量的严格要求。如果管理层在评审上投机取巧，则到时候可以清楚地看到没有好的要求(或者好的设计)评审就不会带来什么价值。　　评审可作为质量过滤的一种形式用于软件开发各阶段，其目的是尽早发现错误以使产品更加完善。评审 结果是：指出产品中需要改进之处；确认好的部分，使产品在编码方式、文件样式、设计方法等方面更加一致，以便技术工作能更好地进行管理；改进软件开发过程。　　进行评审，确保四方面的特性。完整性，下一阶段 产品与其前期设计的产品是完备的整体，没有待定项、 遗漏功能。一致性，符合产品的要求。可行性，产品能 完成。易测性，产品做指定测试的能力，该测试必须是 具体的、明确的和可以量化的。　　评审会议的组织，人员应限于3～7人，会议中，明确分工，经过培训。为使会议有效，事前做准备，时间一般不超过两个小时；评审的是产品而不是它的设计者，要客观地讨论产品而不涉及与之相关的人要限制争论和辩解。搞清问题所在但不要试图去解决任何事情会议的焦点 是发现而不是解决，正式评审中小组的目的不是进行共同设计。会议应沿着发现问题的思路进行，指定记录员。　　评审检查是很经济的，通过检查能在修复费用相对较低的早期阶段发现缺陷。此外当要求作必要的修改 时，对多层次设计文件、产品代码及产品文件进行改动会出现脉动效应，而检查能防止这类效应，评审的另一 个关键是它设计为检测缺陷而不是检测失效。最后，因 为每一个中间产品必须要能追溯至前一级中间产品，所以评审必然会改善整个流程，而要求的准备和设计工作都做得很差的小组几乎就拿不出合适的东西进行评审。4 软件测试　　虽然正式评审和检查占用了我们大量的精力，测试 仍然是缺陷控制和检查中很有用且很重要的一个部分。 测试时我们在受控状态下运行软件以检测缺陷，如同我们在提要求、设计和编码等各阶段进行评审和检查一样，我们在软件制作的任何适当的地方进行测试。下面将简单介绍单元测试、集成测试，系统测试和回归测试。　　4．1单元测试　　单元测试的任务是在一个受控环境中执行—个特定模块。它—般包括某种形式的构架，通常为短线程和驱动器。 —般用来验证模块的功能属性，但也可以测试其它项目，如性能、可用性等等，可使用“黑盒”或“白盒”方法进行。　　4．2集成测试　　当各模块已经过单独的单元测试后，我们就将它们组合到一起，看与其它模块集成在一起时的整体功能。模块可按多种途径集成，包括从上向下和从下向上。实际上任何方法都可以使用，只要测试人员能了解特定模块组合所 表示的行为，组合从最前面两个模块开始，到加入最后一个 模块结束，形成一个完整的系统。理想状况下，集成测试应 每加入一个模块进行一次。集成测试—般也看作验证的一 种形式，因为组合模块的行为是一个功能规范的产品。4．3系统测试　　系统测试是指对整个系统或产品进行测试，看它是否符合总体系统要求。系统测试人员相当于用户代言 人，因为测试指导文件应该或者是用户提出的需求，或者是直接基于这一要求的技术规范。系统测试能发现 任何质量问题，包括功能、性能、可靠性和可用性，还有特定项目的其他方面要求。　　4．4回归测试　　回归测试就是漏洞修复完成后再对软件进行测试， 以确保软件没有产生“回归”或因修复而变得更糟，这 种测试一般要重新运行最初发现问题的原始测试程序。　　测试是一个专业，要用专门的一套技术来进行关键的工作。好的测试是从一开始就参加软件开发，可为产品开 发阶段带来一种质量的观念。尽量使产品暴露出问题才是公司和用户的最大利益所在,应当注意的是测试的技能 与开发并不相同。常常和测试联系在一起的用户和开发 人员，但用这两类人作测试都存在一些问题。开发人员的工作是构建，他制造产品；而测试人员的任务则是找出缺 陷，每个工作都要求特定的个陛，在两者之间随意变动不是小事。更重要的是，让开发人员去测试自已的代码，当处理代码的薄弱部位时，会不自觉地退缩，不是很好地了解问题而是绕开软件中有问题的部分，他们没有足够的勇气对自己动手术。由用户来进行测试，虽然在可用性方面能提供大量反馈。用户在测试时通常重复，不够系统，另外缺乏想象力。对新软件缺乏信心，速度也比较慢。5 结束语　　许多公司对独立测试或功能验证相当满意。但这 些公司的测试一般是在流程结束时才会进行，以确定产 品达到必要的质量水平。本文重点是评审和检查，尽管这两种技术提供了一个更可靠的机制，可以随着开发阶段的进行将质量制造在产品中，但它们在软件公司中使用得并不普遍。用很少人对产品进行直观检查在很多 方面会相当费力，但其潜在的好处是巨大的。每个产品 都有缺陷，这是无法改变的，但产品中的缺陷迟早都是 会发现的。最坏的情况是在应用现场发现，最好则是尽 可能早地在软件开发过程中发现缺陷。一个很充分的 理由就是应该制造缺陷更少的产品，并且这些剩下的缺 陷其严重程度应能被用户所接受。