软件测试技术资料.pdf

软件测试 软件测试技术软件测试技术 2002 年2002 年 3 月 3 月 软件测试 第 i 页 目目 录录 第 1 章 软件测试概述. 3 第 2 章 软件测试的目的. 6 第 3 章 软件测试的组织与管理. 7 3.1 测试的过程及组织 7 3.2 测试方法的应用 8 3.3 测试的人员组织 8 3.4 软件测试文件 9 第 4 章 软件测试的基本方法. 11 4.1 黑盒测试 11 4.2 白盒测试 11 4.3 alac(act-like-a-customer)测试 12 第 5 章 单元测试的基本方法. 13 5.1 单元测试任务 13 5.2 单元测试过程 14 第 6 章 综合测试的基本方法. 15 6.1 自顶向下集成 15 6.2 自底向上集成 16 第 7 章 系统测试的基本方法. 18 7.1 恢复测试 18 7.2 安全测试 18 7.3 强度测试 18 7.4 性能测试 19 第 8 章 确认测试的基本方法. 20 8.1 确认测试标准 20 8.2 配置复审 20 8.3 、测试. 20 第 9 章 排错的基本方法. 21 9.1 排错过程 21 9.2 排错方法 22 第 10 章 软件测试的复杂性与经济性. 23 10.1 系统的目的 23 10.2 潜在的用户数量. 23 10.3 信息的价值 24 10.4 开发机构 24 10.5 测试的时机 24 软件测试 第 ii 页 第 11 章 软件测试的心理学问题. 25 11.1 程序测试的过程具有破坏性. 25 11.2 程序员应避免测试自己的程序. 25 第 12 章 好的测试工程师应具备的素质. 27 第 13 章 面向对象软件的测试. 29 13.1 面向对象测试模型(object- orient test model) 30 13.2 面向对象分析的测试(ooa test) 31 13.3 面向对象设计的测试(ood test) 33 13.4 面向对象编程的测试(oop test). 34 13.5 面向对象的单元测试(oo unit test) 36 13.6 面向对象的集成测试(oo integrate test) 37 13.7 面向对象的系统测试(oo system test). 38 第 14 章 软件测试自动化的一些具体做法. 39 14.1 测试个案（test case ，或称为测试用例）的生成 39 14.2 测试的执行写控制. 39 14.3 测试结果与标准输出的对比. 40 14.4 不吻合的测试结果的分析、分类、记录和通报. 40 14.5 总测试状况的统计，报表的产生. 40 14.6 自动测试与开发中产品每日构建（build）的配合. 41 第 15 章 基于 pb 环境下的软件测试 42 15.1 pb 软件的特点. 42 15.2 测试目标 42 15.3 测试方法 42 15.4 测试过程 43 软件测试 第 3 页 第第1章章 软件测试概述 软件测试概述 信息技术的飞速发展， 使软件产品应用到社会的各个领域， 软件产品的质量自然成为人 们共同关注的焦点。不论软件的生产者还是软件的使用者，均生存在竞争的环境中，软件开 发商为了占有市场， 必须把产品质量作为企业的重要目标之一， 以免在激烈的竞争中被淘汰 出局。用户为了保证自己业务的顺利完成，当然希望选用优质的软件。质量不佳的软件产品 不仅会使开发商的维护费用和用户的使用成本大幅增加， 还可能产生其他的责任风险， 造成 公司信誉下降，继而冲击股票市场。在一些关键应用 (如民航订票系统、银行结算系统、证 券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等) 中使用质量有问题的 软件，还可能造成灾难性的后果。 软件危机曾经是软件界甚至整个计算机界最热门的话题。 为了解决这场危机， 软件从业 人员、 专家和学者做出了大量的努力。 现在人们已经逐步认识到所谓的软件危机实际上仅是 一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失 控。有错是软件的属性，而且是无法改变的，因为软件是由人来完成的，所有由人做的工作 都不会是完美无缺的。 问题在于我们如何去避免错误的产生和消除已经产生的错误， 使程序 中的错误密度达到尽可能低的程度。 给软件带来错误的原因很多，具体地说，主要有如下几点： 1、 交流不够、交流上有误解或者根本不进行交流 在应用应该做什么或不应该做什么的细节(应用的需求)不清晰的情况下进行开发。 2、 软件复杂性 图形用户界面(gui)，客户/服务器结构，分布式应用，数据通信，超大型关系型数 据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代软件开 发经验的人很难理解它。 3、 程序设计错误 象所有的人一样，程序员也会出错。 4、 需求变化 需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能知道但 又不得不那么做。需求变化的后果可能是造成系统的重新设计，设计人员的日程的 重新安排，已经完成的工作可能要重做或者完全抛弃，对其他项目产生影响，硬件 需求可能要因此改变，等等。如果有许多小的改变或者一次大的变化，项目各部分 之间已知或未知的依赖性可能会相互影响而导致更多问题的出现，需求改变带来的 复杂性可能导致错误，还可能影响工程参与者的积极性。 5、 时间压力 软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关 键时刻到来之际，错误也就跟着来了。 6、 自负人更喜欢说: 没问题 这事情很容易 几个小时我就能拿出来 太多不切实际的没问题，结果只能是引入错误。 软件测试 第 4 页 7、 代码文档贫乏 贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。 事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写 得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码 更易于工作的保密(“写得艰难必定读的痛苦”)。 8、 软件开发工具 可视化工具，类库，编译器，脚本工具，等等，它们常常会将自身的错误带到应用 软件中。就象我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只 会使项目变得更复杂。 为了更好地解决这些问题，软件界做出了各种各样的努力。 人们曾经认为更好的程序语言可以使我们摆脱这些困扰，这推动了程序设计语言的发 展，更多的语言开始流行，为了使程序更易于理解开发了结构化程序设计语言，如 pl/1,pascal 等； 为了解决实时多任务需求开发了结构化多任务程序设计语言， 如 modula， ada 等；为了提高重用性开发了面向对象的程序设计语言，如 simlasa 等；为了避免产生不 正确的需求理解，开发形式化描述语言，如 hal/s 等，这使得建立基于自然语言的描述成 为可能，人们以形式化语言来描述需求；为了支持大型数据库应用，开发了可视化工具，如 visual studio、power builder 等。程序语言对提高软件生产效率起到了一定的积极作用，但 它对整个软件质量尤其是可靠性的影响，与其他因素相比作用较小。 可能是因为程序语言基于严格的语法和语义规则， 人们企图用形式化证明方法来证明程 序的正确性。将程序当作数学对象来看待，从数学意义上证明程序是正确的是可能的。数学 家对形式化证明方法最有兴趣，在论文上谈起来非常吸引人，但实际价值却非常有限，因为 形式化证明方法只有在代码写出来之后才能使用， 这显然太迟了， 而且对于大的程序证明起 来非常困难。 受到其他行业项目工程化的启发，软件工程学出现了，软件开发被视为一项 工程，以工程化的方法来进行规划和管理软件的开发。 针对需求不确定的应用， 可以使用渐进和迭代类的开发模型。 还可以采用快速应用程序 开发(rad)和协同应用程序开发（jad）技术，由软件开发者和用户代表共同参与开发软件 规范。rad 和 jad 的基本思路是开发者和用户共同设计系统中的屏幕，开发者迅速地把实 现这些屏幕的最基本功能编写好， 然后把它们交给用户看， 然后用户和开发者回顾这些屏幕 以确认它们达到了用户的要求， 这个周期一直持续到系统的基本部分定义完毕。 一旦设计被 用户接受，开发者将完成完全实现屏幕需要的代码。rad 和传统软件开发项目之间的一个 基本区别是： 应用程序 rad 系统是按阶段发布的。 传统项目一般一次发布， 也叫 “big bang” 。 rad 方法使用高效开发工具，开发者能够非常迅速地设计出系统的基本屏幕，允许用户在 开发周期中很早就能见识到系统将来看起来怎么样， 避免了在传统开发项目中长篇大论并且 枯燥难懂的说明。 ibm 的 dr.harlan mills 提出了净室过程。 净室过程组合了形式化程序验证和统计过程控 制(spc)。在这种方法中，首先用正确性数学证明预防缺陷发生，然后用 mtbf 度量软件质 量。 净室过程是一种相当新的软件开发方法， 它要求软件开发在管理方式和技术方法上作重 大改变，特别是要求 spc 应用到软件的知识，这影响了其被广泛的接受。 硬件成本持续降低，可支持 case 工具运行的新的强大的工作站和网络已经成为软件 工程使用的工作平台，case 工具可完成一些特定的软件开发过程。这些工具提供给软件设 计者以图形方式描述软件设计的能力，这样就易于维护、易于交叉检查、易于理解。许多人 （尤其是 case 工具供货商）相信 case 工具扮演了解决软件危机和拯救软件工业的角色， 但事实上我们看到的情形却是许多公司花了大量的金钱买回的 case 工具但很少使用，原 因在于这些工具执行的过程与机构的软件设计过程不相适用。 软件测试 第 5 页 在可以借助许多新的技术和工具进行软件开发的今天， 软件开发过程的成熟性问题开始 引起人们的重视。 这种产品一致性问题的主要症结在于管理， 因此人们将目标转向了管理的 改善，一些以改进软件开发过程为目标的活动已经展示出积极的结果。 以下是一些比较典型的文本。 sei sw- cmm iso spice(software process improvement and capability determination) bootstrap iso- 9000- 3 tickit trillium 事实上，对于软件来讲，还没有象银弹那样的东西。不论采用什么技术和什么方法，软 件中仍然会有错。 采用新的语言、 先进的开发方式、 完善的开发过程， 可以减少错误的引入， 但是不可能完全杜绝软件中的错误， 这些引入的错误需要测试来找出， 软件中的错误密度也 需要测试来进行估计。 测试是所有工程学科的基本组成单元，是软件开发的重要部分。自 有程序设计的那天起测试就一直伴随着。统计表明，在典型的软件开发项目中，软件测试工 作量往往占软件开发总工作量的 40以上。而在软件开发的总成本中，用在测试上的开销 要占 30到 50。如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成本比例 也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许 多测试工作。 因此， 测试对于软件生产来说是必需的， 问题是我们应该思考 “采用什么方法、 如何安排测试?” 软件测试 第 6 页 第第2章章 软件测试的目的 软件测试的目的 软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误， 那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。 如果测试目的是 为了给最终用户提供具有一定可信度的质量评价， 那么测试就应该直接针对在实际应用中会 经常用到的商业假设。 不同的机构会有不同的测试目的； 相同的机构也可能有不同测试目的， 可能是测试不同 区域或是对同一区域的不同层次的测试。 在谈到软件测试时，许多人都引用 grenford j. myers 在the art of software testing 一书中的观点： 1、 软件测试是为了发现错误而执行程序的过程； 2、 测试是为了证明程序有错，而不是证明程序无错误。 3、 一个好的测试用例是在于它能发现至今未发现的错误； 4、 一个成功的测试是发现了至今未发现的错误的测试。 这种观点可以提醒人们测试要以查找错误为中心， 而不是为了演示软件的正确功能。 但 是仅凭字面意思理解这一观点可能会产生误导， 认为发现错误是软件测试的唯一目， 查找不 出错误的测试就是没有价值的，事实并非如此。 首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征， 可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮 助我们设计出有针对性地检测方法，改善测试的有效性。 其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详 细而严谨的可靠性增长模型可以证明这一点。 例如 bev littlewood 发现一个经过测试而正常 运行了 n 小时的系统有继续正常运行 n 小时的概率。 软件测试 第 7 页 第第3章章 软件测试的组织与管理 软件测试的组织与管理 作为软件开发的重要环节， 软件测试越来越受到人们的重视。 随着软件开发规模的增大、 复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。然而，为了尽可 能多地找出程序中的错误， 生产出高质量的软件产品， 加强对测试工作的组织和管理就显得 尤为重要。 从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试 的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果 设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是 相当昂贵的。 因此， 较理想的做法应该是对软件的开发过程， 按软件工程各阶段形成的结果， 分别进行严格的审查。软件的生命周期可用图 1 的流程表示。 为了确保软件的质量， 对图 1 的过程应进行严格的管理。 虽然测试是在实现且经验证后 进行的，实际上，测试的准备工作在分析和设计阶段就开始了。 3.1 测试的过程及组织测试的过程及组织 当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设 计熟悉的设计人员编写测试大纲， 明确测试的内容和测试通过的准则， 设计完整合理的测试 用例，以便系统实现后进行全面测试。 在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一 般可按下列方式组织： 1、 首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书 及在设计过程中形成的测试大纲、 测试内容及测试的通过准则， 全面熟悉系统， 编写测试计划，设计测试用例，作好测试前的准备工作。 2、 为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、 集成测试和验收测试。 3、 代码会审： 代码会审是由一组人通过阅读、 讨论和争议对程序进行静态分析的过程。 会审 小组由组长，23 名程序设计和测试人员及程序员组成。会审小组在充分阅 读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审 会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的 关键所在。 实践表明， 程序员在讲解过程中能发现许多自己原来没有发现的错 误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修 改方法的讨论， 可能发现与之有牵连的甚至能涉及到模块的功说明、 模块间接 口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善 了软件的质量。 4、 单元测试： 单元测试集中在检查软件设计的最小单位模块上， 通过测试发现实现该模块 的实际功能与定义该模块的功能说明不符合的情况， 以及编码的错误。 由于模 块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序， 清楚地了解该模块的 i/o 条件和模块的逻辑结构，采用结构测试（白盒法）的 软件测试 第 8 页 用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对 任何合理和不合理的输入都能鉴别和响应。 高可靠性的模块是组成可靠系统的 坚实基础。 5、 集成测试： 集成测试是将模块按照设计要求组装起来同时进行测试， 主要目标是发现与接 口有关的问题。 如数据穿过接口时可能丢失； 一个模块与另一个模块可能有由 于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能； 个别看起来是可以接受的误差可能积累到不能接受的程度； 全程数据结构可能 有错误等。 6、 验收测试： 验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。 经集成测 试后， 已经按照设计把所有的模块组装成一个完整的软件系统， 接口错误也已 经基本排除了， 接着就应该进一步验证软件的有效性， 这就是验收测试的任务， 即软件的功能和性能如同用户所合理期待的那样。 经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经 验收后，将软件提交用户。 3.2 测试方法的应用测试方法的应用 集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括?/p 1、 用边值分析法和（或）等价分类法提出基本的测试用例； 2、 用猜测法补充新的测试用例； 3、 如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再 按以上（1）、（2）两步进行。 单元测试的设计策略稍有不同。 因为在为模块设计程序用例时， 可以直接参考模块的源 程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种： a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发 现用黑盒法产生的测试用例未能满足所需的覆盖标准， 就用白盒法增补新的测试用例来满足 它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条 件组合覆盖或路径覆盖标准。 b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒 法进行补充。 3.3 测试的人员组织测试的人员组织 为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分 析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进 行软件测试。基于此，测试人员的组织也应是分阶段的。 软件测试 第 9 页 3.3.1 软件的设计和实现都是基于需求分析规格说明进行的。 需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的 质量，应对其进行严格的审查。审查小组由下列人员组成： 组长：1 人 成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户 3.3.2 设计评审： 软件设计是将软件需求转换成软件表示的过程。 主要描绘出系统结构、 详细的处理过程 和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同 时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成： 组长：1 人 成员：包括系统分析员、软件设计人员、测试负责人员各一人。 3.3.3 程序的测试： 软件测试。 是整个软件开发过程中交付用户使用前的最后阶段， 是软件质量保证的关键。 软件测试在软件生存周期中横跨两个阶段： 通常在编写出每一个模块之后， 就对它进行必要 的测试（称为单元测试）。编码与单元测试属于软件生存周期中的同一阶段。该阶段的测试 工作， 由编程组内部人员进行交叉测试 （避免编程人员测试自己的程序） 。 这一阶段结束后， 进入软件生存周期的测试阶段， 对软件系统进行各种综合测试。 测试工作由专门的测试组完 成，测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的 分析、设计和编程经验的专业人员组成，人数根据具体情况可多可少，一般 35 人为宜。 3.4 软件测试文件软件测试文件 软件测试文件描述要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过 程， 同时也是设计软件开发其它一些阶段的工作， 对于保证软件的质量和它的运行有着重要 意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。测试文件的编写是测 试工作规范化的一个组成部分。 测试文件不只在测试阶段才考虑， 它在软件开发的需求分析阶段就开始着手， 因为测试 文件与用户有着密切的关系。 在设计阶段的一些设计方案也应在测试文件中得到反映， 以利 于设计的检验。 测试文件对于测试阶段工作的指导与评价作用更是非常明显的。 需要特别指 出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须 用到测试文件。 3.4.1 测试文件的类型 根据测试文件所起的作用不同， 通常把测试文件分成两类， 即测试计划和测试分析报告。 测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。 由于要测试的内容可能涉及到软件的需求和软件的设计， 因此必须及早开始测试计划的编写 工作。不应在着手测试时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开 始，到软件设计阶段结束时完成。测试报告用来对测试结果的分析说明，经过测试后，证实 了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件 软件测试 第 10 页 质量的评价，又是决定该软件能否交付用户使用的依据。由于要反映测试工作的情况，自然 要在测试阶段内编写。 3.4.2 测试文件的使用 测试文件的重要性表现在以下几个方面： 1、 验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这 些测试条件对弄清用户需求的意图是十分有益的， 2、 检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明 测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如 何。如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解 决。 3、 明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。 了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上 的准备。 4、 生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例 是作好测试工作的关键。在测试文件编制过程中，按规定的要求精心设计测试 用例有重要的意义。 5、 评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结 果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提 出评价意见。 6、 再测试：测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再 测试时，是非常有用的。 7、 决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效 性，甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。 3.4.3 测试文件的编制 在软件的需求分析阶段， 就开始测试文件的编制工作， 各种测试文件的编写应按一 定的格式进行。 软件测试 第 11 页 第第4章章 软件测试的基本方法 软件测试的基本方法 软件测试的方法和技术是多种多样的。 对于软件测试技术，可以从不同的角度加以分类： 从是否需要执行被测软件的角度，可分为静态测试和动态测试。 从测试是否针对系统的内部结构和具体实现算法的角度来看， 可分为白盒测试和黑盒测 试； 4.1 黑盒测试黑盒测试 黑盒测试也称功能测试或数据驱动测试， 它是在已知产品所应具有的功能， 通过测 试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完 全不考虑程序内部结构和内部特性的情况下， 测试者在程序接口进行测试， 它只检查程序功 能是否按照需求规格说明书的规定正常使用， 程序是否能适当地接收输入数锯而产生正确的 输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划 分、边值分析、因果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序 外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输 入测试， 只有把所有可能的输入都作为测试情况使用， 才能以这种方法查出程序中所有的错 误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法 但是可能的输入进行测试。 4.2 白盒测试白盒测试 白盒测试也称结构测试或逻辑驱动测试， 它是知道产品内部工作过程， 可通过测试来检 测产品内部动作是否按照规格说明书的规定正常进行， 按照程序内部的结构测试程序， 检验 程序中的每条通路是否都有能按预定要求正确工作， 而不顾它的功能， 白盒测试的主要方法 有逻辑驱动、基路测试等，主要用于软件验证。 “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举 路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手， 得出测试数据。 贯穿程序的独立路径数是天文数字。 但即使每条路径都测试了仍然可能有错 误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第 二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了 一些与数据相关的错误。 软件测试 第 12 页 4.3 alac(act- like- a- customer)测试测试 alac 测试是一种基于客户使用产品的知识开发出来的测试方法。 alac 测试是基于复 杂的软件产品有许多错误的原则。 最大的受益者是用户， 缺陷查找和改正将针对哪些客户最 容易遇到的错误。 软件测试 第 13 页 第第5章章 单元测试的基本方法 单元测试的基本方法 单元测试的对象是软件设计的最小单位模块。 单元测试的依据是详细设描述， 单元 测试应对模块内所有重要的控制路径设计测试用例， 以便发现模块内部的错误。 单元测试多 采用白盒测试技术，系统内多个模块可以并行地进行测试。 5.1 单元测试任务单元测试任务 单元测试任务包括： 1 模块接口测试； 2 模块局部数据结构测试； 3 模块边界条件测试； 4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。 模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测 试才有意义。测试接口正确与否应该考虑下列因素： 1 输入的实际参数与形式参数的个数是否相同； 2 输入的实际参数与形式参数的属性是否匹配； 3 输入的实际参数与形式参数的量纲是否一致； 4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同； 5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配； 6 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致； 7 调用预定义函数时所用参数的个数、属性和次序是否正确； 8 是否存在与当前入口点无关的参数引用； 9 是否修改了只读型参数； 10 对全程变量的定义各模块是否一致； 11 是否把某些约束作为参数传递。 如果模块内包括外部输入输出，还应该考虑下列因素： 1 文件属性是否正确； 2 open/close 语句是否正确； 3 格式说明与输入输出语句是否匹配； 4 缓冲区大小与记录长度是否匹配； 5 文件使用前是否已经打开； 6 是否处理了文件尾； 7 是否处理了输入/输出错误； 8 输出信息中是否有文字性错误； 检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。 局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误： 1 不合适或不相容的类型说明； 2 变量无初值； 3 变量初始化或省缺值有错； 4 不正确的变量名（拼错或不正确地截断）； 5 出现上溢、下溢和地址异常。 除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如 fortran 的公用区）对模块的影响。 软件测试 第 14 页 在模块中应对每一条独立执行路径进行测试， 单元测试的基本任务是保证模块中每条语 句至少执行一次。 此时设计测试用例是为了发现因错误计算、 不正确的比较和不适当的控制 流造成的错误。 此时基本路径测试和循环测试是最常用且最有效的测试技术。 计算中常见的 错误包括： 1 误解或用错了算符优先级； 2 混合类型运算； 3 变量初值错； 4 精度不够； 5 表达式符号错。 比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 1 不同数据类型的对象之间进行比较； 2 错误地使用逻辑运算符或优先级； 3 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等； 4 比较运算或变量出错； 5 循环终止条件或不可能出现； 6 迭代发散时不能退出； 7 错误地修改了循环变量。 一个好的设计应能预见各种出错条件， 并预设各种出错处理通路， 出错处理通路同样需 要认真测试，测试应着重检查下列问题： 1 输出的出错信息难以理解； 2 记录的错误与实际遇到的错误不相符； 3 在程序自定义的出错处理段运行之前，系统已介入； 4 异常处理不当； 5 错误陈述中未能提供足够的定位出错信息。 边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界 上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错 误。 5.2 单元测试过程单元测试过程 一般认为单元测试应紧接在编码之后， 当源程序编制完成并通过复审和编译检查， 便可 开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大 发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。 应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了 一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数 据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入- 退出”消息。 驱动模块和桩模块是测试使用的软件， 而不是软件产品的组成部分， 但它需要一定的开 发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和 桩模块不能完成某些模块的测试任务， 这些模块的单元测试只能采用下面讨论的综合测试方 法。 提高模块的内聚度可简化单元测试， 如果每个模块只能完成一个， 所需测试用例数目将 显著减少，模块中的错误也更容易发现。 软件测试 第 15 页 第第6章章 综合测试的基本方法 综合测试的基本方法 时常有这样的情况发生， 每个模块都能单独工作， 但这些模块集成在一起之后却不能正 常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢 失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误 差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系 统测试技术， 按设计要求把通过单元测试的各个模块组装在一起之后， 进行综合测试以便发 现与接口有关的各种错误。 某设计人员习惯于把所有模块按设计要求一次全部组装起来， 然后进行整体测试， 这称 为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定 位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难 断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围 一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量 式集成方法。 6.1 自顶向下集成自顶向下集成 自顶向下集成是构造程序结构的一种增量式方式， 它从主控模块开始， 按照软件的控制 层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先 是把主控制路径上的模块集成在一起， 至于选择哪一条路径作为主控制路径， 这多少带有随 意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块 m1， m2，m5 和 m8 集成在一起，再将 m6 集成起来，然后考虑中间和右边的路径。广度优先策 略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把 m2、m3 和 m4 与主控模块集成在一起，再将 m5 和 m6 和其他模块集资集成起来。 自顶向下综合测试的具体步骤为： 1 以主控模块作为测试驱动模块， 把对主控模块进行单元测试时引入的所有桩模块用实 际模块替代； 2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块； 3 每集成一个模块立即测试一遍； 4 只有每组测试完成后，才着手替换下一个桩模块； 5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。 软件测试 第 16 页 从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已 部分完成的结构，若采用深度优先策略，下一步将用模块 m7 替换桩模块 s7，当然 m7 本 身可能又带有桩模块，随后将被对应的实际模块一一替代。 自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验， 因此较早地 发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重 要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是 把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模 块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定 位和纠正， 并且失去了在组装模块时进行一些特定测试的可能性； 第二种方法无疑要大大增 加开销；第三种方法比较切实可行，下面专门讨论。 6.2 自底向上集成自底向上集成 自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到 较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。 自底向上综合测试的步骤分为： 1 把低层模块组织成实现某个子功能的模块群（cluster）; 2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出； 3 对每个模块群进行测试； 4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块 群。 从第一步开始循环执行上述各步骤，直至整个程序构造完毕。 下图说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动 模块进行测试。因模块群 1、模块群 2 中的模块均隶属于模块 ma，因此在驱动模块 d1、d2 去掉后，模块群 1 与模块群 2 直接与 ma 接口，这时可对 mad3 被去掉后，m3 与模块群 3 直接接口，可对 mb 进行集成测试，最后 ma、mb 和 mc 全部集成在一起进行测试。 软件测试 第 17 页 自底向上集成方法不用桩模块， 测试用例的设计亦相对简单， 但缺点是程序最后一个模 块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系 统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为 有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。 此外， 在综合测试中尤其要注意关键模块， 所谓关键模块一般都具有下述一或多个特征： 对应几条需求；具有高层控制功能；复杂、易出错；有特殊的性能要求。关键模块 应尽早测试，并反复进行回归测试。 软件测试 第 18 页 第第7章章 系统测试的基本方法 系统测试的基本方法 计算机软件是基于计算机系统的一个重要组成部分， 软件开发完毕后应与系统中其它成 分集成在一起， 此时需要进行一系列系统集成和确认测试。 对这些测试的详细讨论已超出软 件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应 完成下列工作： （1） 为测试软件系统的输入信息设计出错处理通路； （2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系 统测试提供经验和帮助； （3） 参与系统测试的规划和设计，保证软件测试的合理性。 系统测试应该由若干个不同测试组成， 目的是充分运行系统， 验证系统各部件是否都能 政党工作并完成所赋予的任务。下面简单讨论几类系统测试。 7.1 恢复测试恢复测试 恢复测试主要检查系统的容错能力。 当系统出错时， 能否在指定时间间隔内修正错误并 重新启动系统。 恢复测试首先要采用各种办法强迫系统失败， 然后验证系统是否能尽快恢复。 对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数 据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需 估测平均修复时间，确定其是否在可接受的范围内。 7.2 安全测试安全测试 安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者， 采用各种办法试图突破防线。例如，想方设法截取或破译口令；专门定做软件破坏系统 的保护机制； 故意导致系统失败， 企图趁恢复之机非法进入； 试图通过浏览非保密数据， 推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系 统安全设计的准则是， 使非法侵入的代价超过被保护信息的价值。 此时非法侵入者已无利可 图。 7.3 强度测试强度测试 强度测试检查程序对异常情况的抵抗能力。 强度测试总是迫使系统在异常的资源配置下 运行。例如，当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例； 定量地增长数据输入率，检查输入子功能的反映能力；运行需要最大存储空间（或其他 资源）的测试用例；运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等 等。 软件测试 第 19 页 7.4 性能测试性能测试 对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求， 虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环 境中才能全面、 可靠地测试运行性能系统性能测试是为了完成这一任务。 性能测试有时与强 度测试相结合，经常需要其他软硬件的配套支持。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步确认 测试即可开始。 确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。 软件测试 第 20 页 第第8章章 确认测试的基本方法 确认测试的基本方法 8.1 确认测试标准确认测试标准 实现软件确认要通过一系列墨盒测试。 确认测试同样需要制订测试计划和过程， 测试计 划应规定测试的种类和测试进度， 测试过程则定义一些特殊的测试用例， 旨在说明软件与需 求是否一致。 无是计划还是过程， 都应该着重考虑软件是否满足合同规定的所有功能和性能， 文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和 可维护性等）是否令用户满意。 确认测试的结果有两种可能， 一种是功能和性能指标满足软件需求说明的要求， 用户可 以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才 发现严重错误和偏差一般很难在预定的工期内改正， 因此必须与用户协商， 寻求一个妥善解 决问题的方法。 8.2 配置复审配置复审 确认测试的另一个重要环节是配置复审。 复审的目的在于保证软件配置齐全、 分类有序， 并且包括软件维护所必须的细节。 8.3 、测试、测试 事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误 的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解， 等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收 测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至 数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用 户验收，此时多采用称为、测试的过程，以期发现那些似乎只有最终用户才能发现的问 题。 测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品 （称为版 本）进行测试，试图发现错误并修正。测试的关键在于尽可能逼真地模拟实际运行环境和 用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过测试调整的软 件产品称为版本。 紧随其后的测试是指软件开发公司组织各方面的典型用户在日常工作 中实际使用版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对版 本进行改错和完善。 软件测试 第 21 页 第第9章章 排错的基本方法 排错的基本方法 排错（即调试）与成功的测试形影相随。测试成功的标志是发现了错误。根据错误迹象 确定错误的原因和准确位置，并加以改正的主要依靠排错技术。 9.1 排错过程排错过程 如下图所示，排错过程开始于一个测试用例的执行，若测试结果与期望结果有出入，即 出现了错误征兆，排错过程首先要找出错误原因，然后对错误进行修正。因此排错过程有两 种可能，一是找到了错误原因并纠正了错误，另一种可能是错误原因不明，排错人员只得做 某种推测，然后再设计测试用例证实这种推测，若一次推测失败，再做第二次推测，直到发 现并纠正了错误。 排错是一个相当艰苦的过程， 究其原因除了开发人员心理方面的障碍外， 还因为隐藏在 程序中的错误具有下列特殊的性质： 1、 错误的外部征兆远离引起错误的内部原因， 对于高度耦合的程序结构此类现象 更为严重； 2、 纠正一个错误造成了另一错误现象（暂时）的消失； 3、 某些错误征兆只是假象； 4、 因操作人员一时疏忽造成的某些错误征兆不易追踪； 5、 错误是由于风时而不是程序引起的； 6、 输入条件难以精确地再构造（例如，某些实时应用的输入次序不确定）； 7、 错误征兆时有时无，此现象对嵌入式系统尤其普遍； 8、 错误是由于把任务分布在若干台不同处理机上运行而造成的。 软件测试 第 22 页 在软件排错过程中，可能遇到大大小小、形形色色的问题，随着问题的增多，排错人员 的压力也随之增大，过分地紧张致使开发人员在排除一个问题的同时又引入更多的新问题。 尽管排错不是一门好学的技术（有时人们更愿意称之为艺术），但还是有若干行之有效 的方法和策略，下面介绍几种排错方法。 9.2 排错方法排错方法 无论采用哪种排错方法，目标只有一个，即发现并排除引起错误的原因，这要求排错人 员能把直观想象与系统评估很好的结合起来。 常用的排错策略分为三类： 1、原始类（brute force） 原始类排错方法是最常用也是最低效的方法， 只有在万般无奈的情况下才使用它， 主 要思想是“通过计算机找错”。例如输出存储器、寄存器的内容，在程序安排若干输 出语句等，凭借大量的现场信息，从中找到出错的线索，虽然最终也能成功，但难免 要耗费大量的时间和精力。 2、回溯类（backtracking） 回溯法能成功地用于程序的排错。 方法是从出现错误征兆处开始， 人工地沿控制流程 往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加， 以致人工进行完全回溯到望而不可及 3、排除类（cause eliminations） 排除法基于归纳和演绎原理，采用“分治”的概念，首先惧与错误出