面向对象软件开发教程9.doc

311 面向对象测试 任何值得构建的东西都应当测试。包括模型、文档和源代码在内，你构建了很多种制品。 第9章面向对象测试你将从本章学到什么？l 如何消除围绕着面向对象测试的误解l 全生命周期面向对象测试（FLOOT）方法学l 用于测试需求、分析和设计模型的技术l 用于测试代码的技术l 用于测试准备部署的系统的技术l 用户可以用来验证系统的技术l 如何写测试用例、装备和配套设施l 如何记录缺陷为什么需要阅读本章？仅仅开发出软件还很不够，我们要开发能够工作的软件。由于软件变得更为复杂要使用对象技术来处理这种复杂性，那将变得更难测试。在软件的整个生命周期内可以应用很多种测试技术，本章将讨论这些技术。软件工程的基础之一是要尽可能地进行测试。要在开发早期找到并修正缺陷有两个理由：大多数错误都在项目周期的早期犯下，修正缺陷的成本将会随着发现它们的时间呈指数增长。大部分缺陷在生命周期早期就已经进入软件产品之中。第一，技术人员擅于完成编码和设计这样的技术任务，那也就是他们为什么是技术人员的原因所在。很不幸，技术人员往往并不擅长非技术工作，例如需求收集和进行分析，这也许是他们之所以是技术人员的另一个原因。激励我们尽早测试的第二个原因是修正缺陷的成本将会随着发现的早晚而变化（越晚的话成本就会越大）。这是软件开发的本质所决定的，所有工作都将以前面的工作为基础。例如，建模基于需求定义阶段的信息收集；编程基于开发模型；测试基于源代码。如果某项需求被误解，那么所有基于这项需求的建模决策都将不合法，所有基于那项模型的代码都将变得可疑，之后进行的测试也就会查出应用程序出错。如果最终错误是在开发周期末期或在应用程序发布时检测到，那时维护起来很可能会费用昂贵。另一方面，如果错误在生命周期早期检测出来，修正它们就会需要较少的费用，因为我们只需要更新少量的文档。定 义缺陷（defect）：任何降低系统完全而有效地满足用户需求功能的东西。也称做臭虫（bug）、错误（fault）或特性（feature）。9.1 消除对面向对象测试的误解开发人员对于面向对象的测试存在几个常见的误解。部分原因是由于在面向对象发展的早期缺乏对OO测试的研究，人们更注重于概念、建模与程序实践。IT业界有一种趋势，喜欢把注意力集中在前端开发以及建模和编程上，而不会把注意力放在不太有“吸引力”的主题上，比如测试就是这种不太具有吸引力的主题。我想如果指出这些误解，这样我们就能准确地理解面向对象测试了。提示：你可以测试的不只是代码 从本章你将会了解到，可以测试所有可交付的制品，而不仅仅是源代码。至少要评审模型和文档，这样的话你可以在深入源代码之前就能找到并修正缺陷。9.1.1 误解1：有了对象就可以少做点儿测试软件越复杂，需要投入测试的工作量就越大。这是开发人员持有的最为危险的误解，造成这个误解的原因是没有完全理解继承。初次接触OO的开发人员常常会假定某个类已经被测试过，他们可以从这个类继承创建子类，而不需要完全测试新类。这个假设是错误的。当一个类从其他类中继承时，它增加了新的行为，在这些行为当中一部分是全新的，一部分是对已有行为的扩展。子类会实现新的、并且常常是比其父类更加复杂的业务规则。这些业务规则可能会扩展或与已有类的规则相冲突。结果是，除了与新行为相关的测试用例之外，还需要在新的子类上面适当地重新运行最初为父类开发的测试用例，以确保它仍能工作。重新运行测试以确保已有功能仍能工作，这被称做回归测试，重新把父类测试在子类上运行称做继承回归测试。换句话说，我们需要做更多的测试工作，而不是相反。当停下来思考时，你会发现这确实是有意义的。首先选择OO的一个理由就是，你想要开发比遵循结构化/过程方法开发的应用程序更为复杂的程序。这样，对于更为复杂的应用程序就需要做更多的测试，难道这会没有意义吗？定 义回归测试（regression testing）：验证已有软件在变动后仍能工作。继承回归测试（inheritance regression testing）：在给定子类上直接或非直接运行父类测试用例的行为。9.1.2 误解2：结构化测试技术是充分的测试方法需要变更以反映新的开发方法。好的一方面是这个误解其实部分是正确的。坏的一方面是这个误解仅有部分是正确的。在本章中你会看到，许多代码测试技术，如边界值测试，对于测试OO代码来说仍是可用的，许多通用系统和用户测试技术对于软件整体的集成测试也是可用的。但是，从本章还会看到好几项传统的测试技术，例如覆盖测试等，它们在OO世界中将不再像以前那么重要。多态、对象改变类型的功能，否定了覆盖测试，因为代码今天可能对于某个对象来说是正确的，但明天在这个对象改变类型后可能会失效。结构化测试技术没有考虑这种情况，对象封装了数据和行为开发标准发生了改变。测试标准也要发生变动，这难道没有意义吗？9.1.3 误解3：测试用户界面是充分的软件远不止是用户界面。因为工具供应商常常关注于开发测试应用程序用户界面的工具，他们会花费相对较少的努力在其他测试项目上，测试经验不足的开发者很容易会假定仅测试用户界面就足够了。是的，用户界面是很重要，但对于应用程序来说，除了屏幕显示和报表之外还有很多其他因素。必须要测试应用程序的所有方面，包括用户界面上的可见单元与隐藏单元。9.2 全生命周期面向对象测试全生命周期面向对象测试（FLOOT）方法学是测试技术的集合，用以验证和检验面向对象软件。FLOOT生命周期在图9-1中描述，指出在软件开发所有方面提供的不同技术。在本节当中会提供每种FLOOT技术的简介。如果需要了解更详细的内容，请参阅Building Object Applications That Work（Ambler，1998a）一书的第12章。定 义覆盖测试（coverage testing）：确保所有代码行都至少用过一次的行为。集成测试（integration testing）：确保几部分软件可以在一起工作的行为。用户界面测试（user interface testing）：用户界面测试用以确保它遵守被广泛接受的UI标准并能满足它所定义的需求。经常指的是图形用户界面（GUI）测试。9.2.1 回归测试用户期待系统以前版本中的所有功能仍然会在新的版本中存在并得到改进。回归测试是确保应用程序变化后不会反过来影响已有的功能行为。如果对程序做过很小的修改，不加测试就把程序投入生产，那样你只会看到它的失败，因为小的改动可能会影响到你已完全忽略的另一部分程序。回归测试可以用来避免所有类似的问题。当应用程序开始实际测试时，回归测试是应该考虑的第一件事。如果把轿车开进车库，安装一套新的立体声系统，此后你却发现只有新的立体声可以工作，而前大灯却不能工作，你该会多么生气呀！当然了。你想一想，如果因为新增的电子邮件系统造成发布的应用程序不能让用户发传真给其他人，用户会有多么气愤？他们当然会非常气愤了。图9-1 全生命周期面向对象测试（FLOOT）方法学的技术设计中的改动会造成旧的测试过程发生变化。应该怎样做回归测试呢？最快的方法是在应用程序新版本上运行所有以前的测试用例。尽管这听起来是个好主意，但实际上它并不实用。第一，可能已经修改了部分甚至全部应用程序设计。这意味着需要修改一些以前的测试用例。第二，如果改动真正影响了系统的一个组件，那么只须运行影响那个组件的测试用例。尽管这种方法会存在风险（因为你的改动可能比预期更大），但它将有助于减少回归测试的时间和成本。增量开发大大增加了回归测试的重要性。认识到增量开发使回归测试变得关键，这很重要（记住，从局部来看OO开发是增量的）。不管何时发布一个应用程序，我们都需要确保它以前的功能正常，采用增量方法时，就要经常发布应用程序，这意味着回归测试变得越来越重要了。提示：要花时间做测试 测试常常被看成整个构建过程中支持程序开发的一种应付行为。很明显，许多开发人员感到交付一堆不能正常工作的功能（他们没有测试过）比交付功能较少但肯定能够工作的功能要来得更重要。相反，他们应该花时间确保其应用程序能够正常工作，或减少他们交付的功能以在同样的时间内产生高质量的工作。按时交付产品，但产品不能工作，这是没有意义的。9.2.2 质量保证质量保证（QA）是评审和审核项目可交付品的行为，以及验证它们是否符合标准、准则以及内部过程的一系列活动。基本上来说质量保证回答了下面的问题：“你在构建正确的东西吗？”和“你在用正确的方式构建它吗？”质量保证对于整个项目的成功来说很关键，它应该是所有项目阶段的完整组成部分。在开发过程的各个层面，都要检查自己的工作以确保其质量。质量是从旁观者的角度进行评价。质量保证当中的一个关键概念是，软件质量通常是从旁观者的角度来指出其在许多方面的表现，包括：l 它满足用户的需求了吗？l 它按时完成了吗？l 它符合预算吗？l 它遵守标准了吗？l 它易于使用吗？l 它是不是没有缺陷呢？l 它容易维护和改进吗？l 把它集成到当前的技术环境中容易吗？定 义质量保证（quality assurance）：验证正确的事情以正确的方式构建。9.2.3 测试需求模型、分析模型和设计模型从前面了解到，许多缺陷是在生命周期早期引入的，其中许多常常是在需求和分析活动中引入的。还有，越早检测到错误，修正成本就会越少。因此，这就迫使你尽可能地测试需求、分析和设计制品。幸运的是，存在一系列的技术可用以完成这些事情。如图9-1所示，这些技术是用况情景测试、原型走查、需求评审、模型评审、模型走查以及用户界面测试。这些测试一般与需求、分析和设计平行进行，以期尽可能早地检验工作。提示：质量是每个人的任务 技术检查后寻找质量仅是解决办法的一部分，绝对不会是全部。质量是专业开发人员的一种生活方式，他们努力在第一次就交付高质量的产品，并期望每次都如此。按照这种方式工作的开发人员都会把注意力放在客户身上，客户将在下游使用开发人员在开发过程中创建的制品。最好的程序员积极寻找新的、更好的解决问题的方法，不断努力改进工作的质量。质量是每个人的任务，而不仅仅是质保部门的任务。9.2.3.1 用况情景测试用况情景测试有助于验证用户需求。用况情景测试（Ambler，1998b）在第4章中已详细讲过，指的是用户积极参与以确保用户需求准确的测试过程。基本思想是一组主题信息专家（SMEs），并辅以协调员，走查一组定义过的用况，以验证CRC模型和分析层的类模型，准确地反映用况所定义的需求。定 义模型评审（model review）：审查分析和/或设计模型的技术评审。模型走查（model walkthrough）：不太正式的一种模型评审。对等评审（peer review）：由一小组有着待检查产品专业知识的人来审查项目交付品或部分交付品的一种技术评审。原型走查（prototype walkthrough）：用户使用原型走查一组用况的过程，就像存在真正系统一样。主要目标是测试原型设计是否达到他们的要求。需求评审（requirement review）：需求模型在其中被审查的一种技术评审。技术评审（technical review）：一种测试技术，其中一项或多项开发制品被一组对等的人严格检查。评审一般集中于准确程度、质量、可用性以及完整性。不那么正式的评审经常指的是走查或对等评审。用况情景测试（use case scenario testing）：一种测试技术，其中一人或多人通过演练用况情景的逻辑来验证领域模型（一般是CRC模型）。9.2.3.2 原型走查原型走查能很快地验证原型是否达到了用户的要求。原型走查（Ambler，1998b）在第4章已详细讨论过，指的是用户走查一系列用况的测试过程，目的是检验用户原型是否达到了他们的要求。基本思想就是用户假定原型就是真正的系统，并试着用它解决由情景描述的真实的业务问题。当然了，他们需要使用想像力填充应用程序缺少的功能（例如从永久存储读写对象），但在大部分情况下这会是相当简单的过程。定 义主题信息专家（subject matter expert，SME）：通过个人知识或研究所得，负责提供问题和/或技术领域相关信息的人。用户接受测试（user-acceptance testing，UAT）：一种测试技术，用户通过使用软件来检验应用程序是否达到他们的要求。用户在计算机旁坐下，开始走查用况。你的工作是坐在那里，看着他们，看看系统是不是很难使用或遗漏了某些功能。在许多情况下，原型走查很像9.2.6.2节中讲述的用户接受测试。惟一不同之处在于用的是原型而不是真正的系统。9.2.3.3 用户需求评审用户接受评审确保你准确地理解了需求。用户需求评审是一项测试技术，在这个过程中由一组用户和/或公认的专家评审需求制品。需求模型包括用况模型、业务规则定义、约束定义和非功能需求，需求模型应该预先分发给评审的参与者，以便他们能预先通查。要经常组织会议，每个人都要在会上描述他们在需求模型里发现的问题和潜在的缺陷。用户需求评审的目的在于确保需求能够准确地反映用户团体的优先权，并确保模型在软件开发过程中易于理解。9.2.3.4 模型评审和走查模型评审在修正缺陷带来的成本较低时就较早地揭示了开发过程中的缺陷。模型评审也称做模型走查或模型对等评审，它是一种测试技术，在这个过程中为建模付出的努力要被一组同等水平的人来严格评审。基本思想是一组合乎要求的人，包括技术人员和SME，聚在一个房间里面，评估目前开发的所有或部分应用程序模型。评估的目的是要确定模型不仅完成了用户团体的要求，而且质量也达到要求，易于开发、维护和改进。当模型评审正确完成后，你会得到很好的收益，因为它们常常可以在项目早期就确定缺陷，减少了修正缺陷带来的成本。实际上，据Grady（1992）报告说，在所有设计错误中，5075可以通过技术评审发现。提示：成功的测试可以发现错误所在 测试的主要目标是找到应用程序中的问题，这样就可以修改它们。如果测试没有发现任何问题，那么很可能你要改进你的测试工作量。9.2.3.5 用户界面测试应用程序的用户界面（UI）是与用户直接交互的部分：屏幕显示、报表、文档和软件支持必需品。用户界面测试验证UI是否遵循了机构内部挑选的公认标准，是否完成了它所定义的需求。用户界面测试常常指的是图形用户界面测试。当用户界面限制在一套预定义的用户界面事件上时，如键盘输入，用户界面测试可以与检验应用程序“是否完成了正确的事情”一样简单，在考虑可用性问题时，例如工程师检验软件是不是接近直觉易于使用，用户界面测试也会变得很复杂。9.2.4 测试源代码面向对象编程语言的语言结构注定了需要新的测试技术。面向对象源代码由几项内容组成，包括方法（操作）、类和继承关系。你需要反映支持这些新结构的测试技术；换句话说，需要反映面向对象最为本质的测试技术。在本节中，我概述了几种不同的传统代码测试技术，像黑盒测试和覆盖测试；还介绍了面向对象测试技术，像类测试和继承回归测试等。甚至在最简单的面向对象程序之中，你也会发现自己会用到其中大部分测试技术。在编码的同时完成测试。代码测试技术一般在编写源码时才用。极限编程（也称做XP）的驱动原则之一是要先写出测试代码（Beck，2000）。基本思想是，通过在写操作本身之前写出给定操作的测试代码，以迫使你考虑那项操作应该做什么，怎样做，进而改进代码质量。它可以确保你使用测试代码来验证自己的工作，使得运行它就可以立即知道代码是否是按照应有的方式工作。定 义人性因素工程师（human-factors engineer，HFE）：从事应用程序用户界面分析、设计和/或用户工作环境的专家。用户界面（user interface，UI）：软件的用户界面是与用户直接交互的部分，包括屏幕显示、报表、文档以及软件支持（通过电话、电子邮件等）。用户界面事件（user interface event）：常常是由用户启动的一个事件，例如键盘输入、鼠标动作或由麦克风捕捉的语音输入，这些事件能引起应用程序的动作。黑盒测试（black-box testing）：确保给定输入A，被测试的组件/系统将会给你预期结果B的行为。边界值测试（boundary-value testing）：确保代码正确处理偶然和极端情况的行为。类测试（class testing）：确保类和它的实例（对象）按照定义执行的行为。类集成测试（class-integration testing）：确保组成应用程序的类和它们的实例按照定义执行的行为。代码检查（code inspection）：一种技术检查形式，其中被检查的交付品是源代码。覆盖测试（coverage testing）：确保所有代码行都至少用过一次的行为。方法测试（method testing）：确保方法（也称为操作或成员函数）按照定义执行的行为。路径测试（path testing）：确保代码中所有逻辑路径都至少走过一次的行为。它是覆盖测试的超集。单元测试（unit testing）：测试系统所有的小组件以确保它们都能工作的行为。白盒测试（white-box testing）：确保特定代码行可以按照定义工作的行为。也称做明盒测试（clear-box testing）。9.2.4.1 黑盒测试黑盒测试是在不了解软件如何实现的情况下执行的。黑盒测试，也称做接口测试（interface testing），是在不了解内部工作流程的情况下仅基于方法、类或应用程序的期望功能创建测试用例的一项技术。定义黑盒测试的一种方法是，给定输入A，应该能够得到期望的结果B。黑盒测试的目标是确保系统能够完成它们应该完成的事情，而不是确保它们是怎样完成的。例如，字处理器的黑盒测试可能会验证它能从硬盘中读取文件，然后按照最初的方式将文件写回。它是黑盒测试，因为你可以不需要了解字处理器怎样读写文件就能够运行它。创建黑盒测试常常由应用程序的用户需求驱动（用户需求一般由用况归档）。这里的基本思想是，看着用户需求并问自己，需要做些什么工作才能弄明白用户需求是否满足。黑盒测试的优点是它们可以验证应用程序完成了它所定义的用户需求。不幸的是，黑盒测试并没有显示出额外的、经常是技术类型的、用户没有定义的功能也可以工作。处理这种情况，就需要创建白/明盒测试用例。提示：让其他人测试你的工作 尽可能做出最好的工作是每个人的职责。同时，你也要认识到，因为许多人都确信自己的工作是正确的，他们经常会犯下其他人才能看出来的错误。最好的方法是开发人员先测试自己的工作，找出主要的缺陷，然后让专业测试工程师接管测试工作，这样就能增加发现错误的机会。9.2.4.2 边界值测试边界值测试验证软件是否能处理异常或极端情况。边界值测试基于这种认识，即需要测试代码以确保它可以处理异常和极端的情况。例如，从银行账户提取资金的边界值测试可能会包括像提取0.00美元、0.01美元和-0.01美元，一大笔资金、一大笔负额资金，等等这样的测试用例。而且，如果自动取款机每天有取款500美元的限制的话，你也要创建验证单笔交易能够提出500美元，而不是500.01美元的测试，对一系列交易增加相同的量，运行相同的测试。基本思想是把业务规则或常识定义的限制找出来，创建测试用例，测试这些值周围的属性值。边界值测试的主要优点是它能确认程序代码是否可以处理异常或极端情况。边界值测试的一个重大的缺限是，开发人员很容易让自己相信他们仅需要完成边界值测试就可以了。毕竟，它只会发现异常错误，不是吗？事实上是你要把常见的和异常的错误都找出来。9.2.4.3 类测试类测试既是单元测试又是集成测试。类测试既是单元测试又是传统的集成测试。说它是单元测试，因为要把类和它的实例作为单元隔离测试；但它又是集成测试，因为需要验证类的方法和属性是否可以配合工作。在类测试的过程中需要做出的一个假设是，系统中所有的类都能工作。尽管听起来这是个很不合理的假设，但它基本上是可以把类测试和类集成测试分离开来的。类测试的主要目标是分离地测试类，如果没有假定其他任何东西都是可以工作的话，这件事将会很难进行下去。9.2.4.4 类集成测试类集成测试可以验证类是否可以顺利地一起工作。类集成测试，也被称做组件测试（component testing），它解决系统中的类或系统中的组件是否能一起有效工作的问题。类，或更准确地说是类的实例，可以一起工作的惟一一种方式是互相发送消息。这样，在这些对象发送消息之前，它们之间必然存在某种关系，这意味着类间联系可以用来驱动集成测试用例的开发。换句话说，策略应该是看着类图中出现的关联、聚合以及继承关系，明确表达出类集成测试用例。提示：新的开发范型隐含着新的测试范型 面向对象开发与结构化/过程化开发有着很大的不同。过去你用于测试结构化程序的许多技术都不再适用，或者需要重新编制才能满足面向对象开发的新需求。9.2.4.5 代码检查代码检查验证是否已经正确地构建了代码，并帮助培训开发人员在编码过程早期检测出潜在的问题。代码检查，也称做代码评审（code review），它经常会暴露出普通测试技术测不出的一些问题尤其是，拙劣的编码实践将会使应用程序难以扩展和维护。代码检查检验是否正确地构建了代码，并检验构建的代码是否易于理解、维护和改善。代码检查是一种训练开发人员软件工程技术的有效手段，因为检查会暴露出需要改善的地方。所以说，代码检查是尽可能地在编码过程早期就检测并修改问题的一种有效方法。写出一千行代码，检查它，修改它，然后前进；写出十万行代码，然后找出除了对编写代码的人以外对任何人来说都莫名其妙的代码，相比之下前者要好得多。代码检查应该关注以下质量问题：l 代码能满足设计吗？l 类、方法和属性的命名规范。l 代码文档标准和规范，比如 把方法的作用归档了吗？ 把传入的参数归档了吗？ 把方法返回值归档了吗？ 把一段代码完成的内容和为什么完成这些内容归档了吗？l 编写较小的方法，该方法仅完成一项功能，并且可以成功地完成该项功能。l 如何简化代码。9.2.4.6 覆盖和路径测试覆盖测试确保所有的代码行都被测试；路径测试确保所有的逻辑路径都被测试。覆盖测试是一种技术，使用这种技术可以设计出测试所有代码路径的一系列测试用例。在许多情况下，覆盖测试仅是一系列白盒测试用例，这些用例一起检查应用程序中每行代码至少一次。路径测试是覆盖测试的子集，不仅确保所有的代码行都测试过，而且所有的逻辑路径也都被测试过。当方法有一套以上的case语句或嵌套IF语句时，两种测试方法就会不同：用覆盖测试确定测试用例的数目。也可以使用路径测试在case语句及嵌套IF语句之间计算路径最大数目，你会把这个数与逻辑路径数相乘。覆盖测试最主要的优点在于它有助于确保应用程序中所有代码都被测试过，但它不能确保所有代码的组合被测试过。另一方面，路径测试确实也测试了代码组合，但它需要更多的努力来明确表达并运行测试用例。在许多情况下，由于任务的种类是指数级变化的，路径测试是不太实际的。提示：在做出重要测试之前执行代码检查 我的经验是代码检查应该放在测试之前来完成，因为一旦代码被测试验证后，开发人员很少会主动检查他们的代码。他们的观点是，既然代码已经可以工作了，为什么还要重新审视它们呢？这意味着应该首先检查代码，按检查意见行动，然后测试它。提示：按制品风险进行测试 McGregor（1997）指出风险越大，就越需要评审和测试。换句话说，可能会投入巨大精力测试空中交通管制系统，但“Hello World”程序则不需要花费同样多的精力。9.2.4.7 继承回归测试毫无疑问，面向对象代码测试中最重要的一部分应该是继承回归测试，也就是为待测试类的所有父类运行类和方法的测试用例。继承回归测试背后的动机很简单：希望新的子类不会带来错误的想法是非常天真的。新的方法增加进来，已有的方法常被子类重新定义，这些方法经常会访问并改变父类定义的属性值。很可能，子类会以父类中没有指定的方式，或者至少是没有预料到的方式改变属性值。我个人喜欢在新的子类上运行旧的测试用例，以验证所有代码仍能工作。9.2.4.8 方法测试方法测试是确保方法（在C+和Java中也称做操作或成员函数）能够按照预先定义的方式执行。在结构化世界中，与方法测试最为接近的是函数和过程的单元测试。尽管一些人争辩说类测试真的是单元测试的面向对象版本，但从我的经验看：为特定方法创建的测试用例经常被证明是很有效的，不应该忽略，因此我们需要方法测试。在方法测试的过程中要解决下面这些问题：l 确保访问器方法能够工作。l 确保每个方法返回合适的值，包括错误消息和异常。l 传入每个方法的参数都要进行基本检查。l 确保每个方法都按文档叙述的方式执行。定 义访问器（accessor）：用以修改或检索单个属性值的操作。也被称做getter和setter操作。9.2.4.9 白/明盒测试白盒测试基于对代码的认识来进行设计。白盒测试，也称做明盒测试（clear-box testing）或详细代码测试（detailed-code testing），它基于这样的概念应用程序代码可以驱动测试用例的开发。基本方法是，看着代码，然后创建检查它的测试用例。使用白盒测试，就能够看到应用程序的内部工作机制，有了这种认识，就可以创建能够运行特定代码段的测试用例。例如，假定你可以访问从字处理器中读入文件的源代码。当阅读代码时，你看到有一条IF语句确定读入的文件是字处理文件还是简单的文本文件，然后使用合适的方法将文件读入。这表明至少要在这段代码上执行三次测试：一次读入字处理文件，一次读入文本文件，再一次读入既非字处理文件又非文本文件的文件。通过阅读代码，就能够确定出执行代码不同逻辑路径的新的测试用例。白盒测试主要的优点是它能创建执行特定代码行的测试，这些代码行有可能黑盒测试中没有测试过。不幸的是，它不能确定所有的用户需求是否都已经得到满足，因为它仅能测试你写出的特定代码。9.2.5 整体测试系统系统测试由开发人员执行，验证应用程序是否已准备好做用户测试。系统测试是一个测试过程，这个过程的目标是确保全部系统都能根据需求按照定义工作。系统测试一般趋向于在开发周期末期进行，它使你在程序交付给用户测试（9.2.6节）之前可以修改已知问题。系统测试由下面几种技术组成：l 功能测试。l 安装测试。l 操作测试。l 强度测试。l 支持测试。9.2.5.1 功能测试开发人员执行功能测试以验证他们的应用程序是否准备好用户接受测试。功能测试是一种系统测试技术，使用这项技术开发人员可以验证应用程序是否达到了用户预定义的要求。它的方法是，开发人员（一般是测试工程师）使用系统展示的主要功能，确保他们的应用程序已经准备好执行用户接受测试（UAT）了。当用户自己确信系统达到了他们的要求时，就要进行用户测试。许多情况下，功能测试和用户接受测试惟一的区别是谁做了这件事：是测试者还是用户。我们常使用用况（在第4章里详细讲述过）开发功能测试用例，因为它们描述了用户如何使用应用程序的确切行为。你会发现应用程序设计中的变化迫使你二次访问用况，验证它们仍是适用的，其实这些问题应该在构建过程中确定下来和修改。定 义功能测试（function testing）：一项测试技术，使用这项技术开发人员可以确认他们的应用程序是否满足了分析中确定下来的用户需求的要求。安装测试（installation testing）：确保应用程序可以成功安装的行为。操作测试（operations testing）：确保支持/操作应用程序的操作人员需求得以满足的行为。强度测试（stress testing）：确保系统在大量交易、大量用户等情况下可以按预期执行的行为。支持测试（support testing）：确保支持人员需求得以满足的行为。系统测试（system testing）：一项测试过程，在这个过程中可以找到并修改应用程序中的任何已知问题，以便为用户测试做好准备。9.2.5.2 安装测试应用程序的安装工具/过程是全部应用程序包的一部分，因此它们必须测试。安装测试是一种系统测试，其中焦点是应用程序被成功安装。应该考虑下面几个重要的问题：l 能成功地把应用程序安装到以前从未安装过的环境中吗？l 能成功地把应用程序安装到已有或存有以前版本的环境中吗？l 配置信息定义正确吗？l 考虑到以前的配置信息了吗？l 在线文档安装正确吗？l 安装这个程序会影响其他应用程序吗？l 对这个应用程序来说，是否有充足的计算机资源？安装功能检测到资源的情况并能适当地做出反应吗？定 义测试用例（test case）：对软件项目必须支持的情形的描述，包括配置、一系列活动以及预期结果。用况（use case）：一系列活动，提供给参与者可测量的值。9.2.5.3 操作和支持测试操作和支持测试有助于确保系统一旦部署就能连续运转。操作测试的目标是验证操作人员的需求是否满足，确保应用程序一旦正确安装后操作人员就能够成功地运行。除了目标对象是支持人员外，支持测试与操作测试描述相似的问题。Tourniaire和Farrell（1997）建议，除了操作机构的要求之外，支持机构的需求也应该在应用程序投入运转之前进行测试。9.2.5.4 强度测试强度测试的目标是确定应用程序不能正常工作时的负载/容量水平。强度测试是确保应用程序在大量用户、大量交易（测试大量交易也称做容量测试）、大量数据传输、大量打印报表下也能工作的过程。目标是当系统不再运转时找到系统的强度点，这样就能获得对在异常和/或高强度情形下系统如何执行的认识。9.2.6 用户测试系统测试后是用户测试，它是由用户团体成员执行的测试过程组成。用户测试的目标是让用户验证应用程序能否满足他们的要求。用户测试由下面的技术组成：l Alpha测试。l Beta测试。l Pilot测试。l 用户接受测试（UAT）。定 义容量测试（volume testing）：强度测试的子集，特别用于处理在给定时间段里应用程序可以处理多少交易或数据库访问。9.2.6.1 Alpha测试、Beta测试和Pilot测试用户与你相比，他们能设计出更多更好的测试脚本。测试的一个主要问题在于你仅能测试你所了解的问题。除非天天做用户的工作，否则你永远不会知道问题域的需求。这意味着你将永远不能定义出与用户一样多的真实测试脚本；这样，让用户来给你测试就很有意义了。两种常见的方法是Alpha测试和Beta测试（Alpha/Beta测试指的是内部用户使用程序的Pilot测试，也称飞行测试）。Alpha测试是给一小批用户分发还未到黄金阶段的软件，让他们使用，反馈他们遇到的问题。尽管这类软件一般都会错误，不能完全满足用户的要求，但这会使用户在等待正式发布软件之前就弄清楚你在做什么。除了Alpha测试（Beta测试接在Alpha测试之后）阶段软件修正了更多错误之外，Beta测试基本上是相同的过程，软件被分发给更大的一批用户。Alpha测试和Beta测试的主要目标是测验运行产品，然后在发布程序之前修改发现的所有错误。定 义Alpha测试（alpha testing）：一个测试阶段，软件产品预发布版本，在正式发布软件前分发给需要使用产品的用户，这些产品经常会有错误。反过来，这些用户愿意把他们发现的错误报告给软件开发人员。Alpha测试后一般跟着Beta测试。Beta测试（beta testing）：除了软件产品应该会有更少的错误之外，其余都与Alpha测试相同。软件开发公司为了确保尽可能地满足更多的客户需求就使用这种方法。Pilot测试（pilot testing）：与Beta测试等价的一种测试过程，机构用它来测试他们为自己内部使用所开发的程序。用户测试（user testing）：用户团体而不是开发人员来执行测试的过程。用户测试技术包括用户接受测试、Alpha测试、Beta测试和Pilot测试。9.2.6.2 用户接受测试用户是确定应用程序是否真正达到他们要求的惟一人选。在系统测试成功验证后，用户必须执行用户接受测试，在这个过程中他们要确定应用程序是否真正能满足他们的要求。这意味着需要让用户使用你的软件。真正知道需求的正是你自己，你知道与用户接受测试相关的人应是系统实际用户，不是用户经理，也不是用户工作部门的副主席，是实际用户每天使用程序进行工作。尽管可能需要给他们一些培训，让他们获得必需的测试技能，真正的用户是有资格进行用户接受测试的人。如果你对应用程序进行了详细的功能测试，那么用户接受测试的过程顶多会花几天时间。9.3 从测试用例到缺陷根据测试目标定义、运行一系列测试。测试的基本目的是验证测试目标的正确性。要进行测试，需要根据提出的目标定义、运行一系列测试。测试用例是对执行的单个测试的定义。要归档测试用例，需要在运行测试把待测项目调整到已知状态之前描述它的目的、要执行的配置工作、实际测试的步骤和测试预期的结果。测试脚本是测试的实际步骤，有时是要遵守的书面步骤或源代码。在测试目标上运行测试脚本。测试套件是一系列测试脚本，测试装备是测试套件的部分代码。在测试目标上运行测试套件，产生的测试结果指明测试过程的实际结果。如果实际测试结果与由部分测试用例归档的预期测试结果不同，那么就确定出测试目标中存在一个潜在的缺陷。提示：一次测试顶一千条意见 你可以说自己的应用程序可以工作，但直到有了测试结果我才会相信你。定 义缺陷（defect）：任何降低系统完全而有效地满足用户需求功能的东西。也称做臭虫（bug）、错误（fault）或特性（feature）。测试用例（test case）：单个测试的定义。测试装备（test harness）：聚合测试脚本的测试套件中的部分代码。测试脚本（test script）：运行测试用例的执行步骤。测试脚本使用从代码测试到功能测试的书面步骤等不同的技术实现。测试套件（test suite）：一系列测试脚本。测试目标（test target）：待测试的一个项目，例如模型、文档或部分软件。发现一个缺陷时要记录其详细信息，以帮助你日后修改。找到缺陷还不够，你必须记清楚已发现了它。由于下面的几个理由，收集这种信息显得很重要。第一，它能提供准确的描述，这样缺陷就可以被修改过来。第二，它提供分析并改进工作实践的度量。这个数据应该首先用来避免缺陷，或至少用来在开发过程中马上找到缺陷以减少修正成本。Humphrey（1997）建议记录下面这些与缺陷相关的信息：l 缺陷的描述。l 发现缺陷的日期。l 发现缺陷的人的姓名。l 缺陷类型（用户界面错误、应用程序崩溃等等）。l 缺陷发现的阶段。l 缺陷引入的阶