软件工程-08.ppt

第八章 软件测试工程 软件工程课件 第八章 软件测试工程 8.1 软件测试的任务 8.2 软件错误 8.3 人工测试 8.4 在软件开发生存周期中的测试活动 8.5 面向对象的测试 8.6 单元测试 8.7 集成测试 8.8 系统测试 8.9 程序调试 澳大利亚昆士兰州的银行系统，由于系统从2009年12月31日直接跳到了2016年1月1日，导致大量用户的信用卡提前失效。同时，各种定期交易也 陷入瘫痪，银行系统不得不紧急启用手工审核流程来处理巨潮般的交易流水。紧接着，德国银行协会（BdB）发表警告，说该协会下发行的高达3000万张银行 卡由于“千年虫延期十年发作的原因”而可能有部分功能无法使用。 中国也遭遇了类似的问题，但问题目前看来集中于出租车行业。据悉，安徽芜湖、新疆乌鲁木齐、湖北随州、辽宁沈阳和锦州等地的几万辆出租车的计价器忽然 在2010年1月1日出现了价格归零的故障。 8.1 软件测试的任务 基于不同的立场，有两种完全不同的测试目的。 从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。 从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求。 而Glenford J. Myers则认为应该首先认定软件是有错误的，然后用测试去发现尽可能多的错误。他于1979年提出了对软件测试的定义：“测试是为发现错误而执行的一个程序或者系统的过程。” Myers还给出了与测试相关的三个重要观点： 测试是为了证明程序有错，而不是证明程序无错误； 一个好的测试用例是在于它能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试； 鉴于以上观点，IEEE在其软件工程术语标准中给软件测试下的定义是“用人工或自动的手段来执行和评价系统或系统部件的过程，以检验它是否满足规定的需求，或识别期望的结果和实际的结果之间有无差别”。 测试的目的是 想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。 测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。 实施测试收集到的测试结果数据为可靠性分析提供了依据。 测试不能表明软件中不存在错误，它只能说明软件中存在错误。 软件测试的原则 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 测试用例应由测试输入数据、执行条件和对应的预期输出结果组成。 程序员应避免检查自己的程序。 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。 所有的测试都应当追溯到用户要求，导致程序不能满足用户要求的错误是严重错误。 测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 严格执行测试计划，排除测试的随意性。 应当对每一个测试结果做全面检查。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 软件测试的对象 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。 测试的两个方面： 缺陷测试 V V（验证和确认） 验证(Verification)，检查软件生存期各个阶段过程活动的结果是否满足规格说明的描述，证实各阶段和阶段之间的逻辑协调性、完备性和正确性。 确认(Validation)，是比验证更广泛的过程活动。目的是想证实在一个给定的外部环境中软件的逻辑正确性，即是否满足用户的要求。 Boehm给出两者的区分： 验证：我们是否在正确地建造一个产品 确认：我们是否在建成一个正确的产品 在整个生存周期中各个阶段都必须应用V V技术。两个主要目标是： 发现系统中的缺陷； 判断在给定的操作环境下系统是否可用； V V技术分为两种： 软件检查：对系统的各种表示进行静态分析，以发现问题。这些检查可以借助工具进行文档和代码分析。 软件测试：通过执行测试数据观察系统的操作特征（行为）是否符合要求。 静态和动态的 VV 测试信息流 测试的生存周期模型 软件测试生存周期模型的V模型 V图 软件测试计划 软件测试计划是制定测试过程的标准，而不是描述具体的测试内容 测试计划给所有相关人员一个总的系统测试的概貌，安排测试人员参加到测试中来。 测试计划结构: 8.2 软件错误 从不同的角度有不同的分类。同一个错误可能有多个征兆，因而它可以被归入不同的类。下面从不同角度对错误分类。 按错误的性质和范围分类 (1) 功能错误 规格说明错误：规格说明未反映用户需求，不完全，有二义性或自身矛盾。 功能错误：程序实现的功能与规格说明及用户