软件工程讲义-07.ppt

软件工程第七章 软件测试 7.1 测试的目的和原则 7.2 测试方法与测试用例设计 7.3 软件测试的策略 7.4 软件测试的种类 7.5 程序的静态测试 7.6 程序调试 7.1 软件测试的目的和原则 鉴于以上观点，IEEE在其软件工程术语标准中给软件测试下的定义是“用人工或自动的手段来执行和评价系统或系统部件的过程，以检验它是否满足规定的需求，或识别期望的结果和实际的结果之间有无差别”。 在以上两个目的中，通常测试专家更侧重后一个。他们普遍将软件测试视为“根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去执行检查并发现软件错误的过程 ”。 Myers软件测试目的 Myers在其名著“The Art of Software Test”中强调： 测试是程序的执行过程，目的在于发现错误； 一个好的测试用例在于能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 换言之，测试的目的是 想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。 测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。 实施测试收集到的测试结果数据为可靠性分析提供了依据。 测试不能表明软件中不存在错误，它只能说明软件中存在错误。 7.1.2 软件测试的原则 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 程序员应避免检查自己的程序。 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。 所有的测试都应当追溯到用户要求，导致程序不能满足用户要求的错误是严重错误。 充分注意测试中的群集现象。经验表明，测试发现错误的80%很可能出自20%的模块，换句话说，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 严格执行测试计划，排除测试的随意性。 应当对每一个测试结果做全面检查。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 7.1.3 软件测试的对象 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。 测试的两个方面： 缺陷测试 V V（验证和确认） 验证(Verification)，检查软件生存期各个阶段过程活动的结果是否满足规格说明的描述，证实各阶段和阶段之间的逻辑协调性、完备性和正确性。 确认(Validation)，是比验证更广泛的过程活动。目的是想证实在一个给定的外部环境中软件的逻辑正确性，即是否满足用户的要求。 Boehm给出两者的区分： 验证：我们是否在正确地建造一个产品 确认：我们是否在建成一个正确的产品 在整个生存周期中各个阶段都必须应用V V技术。两个主要目标是： 发现系统中的缺陷； 判断在给定的操作环境下系统是否可用； V V技术分为两种： 软件检查：对系统的各种表示进行静态分析，以发现问题。这些检查可以借助工具进行文档和代码分析。 软件测试：通过执行测试数据观察系统的操作特征（行为）是否符合要求。 软件配置：软件需求规格说明、软件设计规格说明、源代码等； 测试配置：测试计划、测试用例、测试程序等； 测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。 测试结果分析：比较实测结果与预期结果，评价错误是否发生。 排错（调试）：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。 修正后的文档再测试：直到通过测试为止。 通过收集和分析测试结果数据，对软件建立可靠性模型 利用可靠性分析，评价软件质量。 如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。 7.1.5 测试与软件开发各阶段的关系 软件开发过程是一个自顶向下，逐步细化的过程 软件计划阶段定义软件范围（作用域） 软件需求分析阶段建立软件信息域、功能和性能需求、约束等 软件设计阶段建立软件体系结构、用户接口、数据结构和细部设计 程序编码阶段把设计用某种程序设计语言转换成程序代码 测试过程是依相反顺序安排的自底向上，逐步集成的过程。 7.1.6 软件测试计划 软件测试计划是制定测试过程的标准，而不是描述具体的测试内容。 测试计划给所有相关人员一个总的系统测试的概貌，安排测试人员参加到测试中来。 测试计划结构: 测试计划不是一个不变的文档。 7.2 测试方法与测试用例设计 黑盒测试 等价类划分 边界值分析 错误推测法 因果图 功能图 接口测试 白盒测试