当前位置:
文档之家› 917575-计算机软件技术基础-第11章 软件测试、维护与质量保证2015
917575-计算机软件技术基础-第11章 软件测试、维护与质量保证2015
返回
13
• 11.2 软 件 维 护
• 软件维护是使软件处于良好运作状态的活动。它本是 项目(或产品)交付后的被动活动,一般由以下几种情 况引发:改正软件中存在的一些错误(正确性维护); 支持软硬件因升级而需要的适配性维护;使用软件一 段时间后用户提出新的要求,则要做改进性维护(业 务过程模型改动了);发现了病毒或外购部件隐藏缺 陷则做预防性维护。总之,维护要对原有软件做变更、 修改设计、重写代码、重新测试、建立新的文档版本, 是比较费钱费事而软件商又必须做的事情。对于初学 者来说,知道有这项活动就可以了。
第11章 软件测试维护与质量保证
返回
1
11.1 软 件 测 试
11.1.1 测试技术
试用例设计是测试的中心问题。测试用例设计与采用的 测试技术和实施技术的侧重点有关。
黑箱测试
每个程序或模块都是按规格说明设计编码的。按规格说 明指明的输入和预期的功能、性能进行测试。如果只看 输入和程序运行结果,不管程序内部执行过程,这种测 试称为黑箱测试。如果怎么测怎么对,那么黑箱测试就 完成了。程序的使用性能是测试的主要目标。一般说的 程序测试即指黑箱测试。
• 基于程序本身性质 前面的五种技术可以应用在所 有类型的软件中。然而,对于某些类型的应用,还 要针对它们本身的特点和特殊要求来产生测试。这 样的测试有面向对象的测试、基于构件的测试、基 于Web的测试、GUI测试、并发程序的测试、协议 一致性测试、分布式系统测试、实时系统测试、科 学软件测试等。
返回
返回
6
• 11.1.2 集成测试策略
集成测试最终是将本项目所有模块总成交出完整的程序 产品。一般说来,单元测试错误是相对好找的,集成 测试问题较多,且运行一次时间也长,所以测试策略 很重要。
由底向上集成
最底层的模块叫原子模块,如图11.28中的A、B、C、 D、E。它们首先测试,显然只需在Q、Y、R、S处设 驱动模块QD、YD、RD、SD,不需桩模块。测完之 后,驱动模块上升,在X、Z处设XD、ZD,QD、RD、 SD处换回Q、R、S再测。最后由P驱动整个程序。
返回
20
软件质量保证
SQA计划在项目计划期间制定。在成立项目组时, 同时成立SQA小组。其内容是:
• 规定要做的评估
• 规定要做的评审和审计
• 指明项目要用到的标准
• 定出错误报告、追踪的规程
• 规定SQA小组要做的文档
• 向项目小组提供哪些反馈(即报告的内容)
•参与项目的软件过程描述的开发
•评审软件工程活动,验证是否和定义的软件过程 相似
• 基于测试者的直觉和经验 测试的产生依赖于测试者的技能、直 觉和他对类似程序的经验。这在那些不能为形式化的技术所 “捕捉”的测试中尤为有用,但在不同的测试中有效程度可能 变化很大。采用这种技术时,根据测试者的经验和直觉,可以 使用黑箱、白箱或混合测试。
• 基于规格 采用这种技术是在只需按软件规格测试时,因此使用 黑箱测试。
返回
17
11.3.1 软件质量与度量
软件质量需求有两个方面: ⑴ 显式的。要与软件和应用程序显式陈述的规范 说明中的功能、性能强相符,符合开发标准和准 则、指南。所谓“强相符”是指功能不多也不少。 出现了规范说明以外的多余功能并不是一件好事, 当有未预料到的使用情况发生,它也许就是错误 根源。
返回
•这种自底向上集成是一种增量方法。完全不增量也可以,即每 个模块都先做单元测试,中间模块一头设驱动,一头设桩,分 别完成后,最后一次总集成,叫大爆炸(big bang)式集成。这 样运行次数最少,但总集成时复杂性陡增。只在每个单元测试 运行时间都较长的情况下采用。
返回
8
自顶向下集成
自顶向下集成法与自底向上集成法相反,一开始抓住 总控模块(主程序),处处设桩(凡有调用子模块处), 测完一块向下走一块,因而必然是增量式。增量时 根据被测软件特点,可采用深度优先(depth-first), 测完一块进入下一层直到最底层,然后再测其他未 测模块,依然是测完一层进入下一层。按图11.28 的程序结构,其测试次序是:
图 由底向上测试
这种策略的优点是总是测试“真实”模块,易于设计较 充分的用例。其缺点是不到最后总没有一个“完整” 的概念,属于全局性的用例难于设计周全。
返回
7
•为了弥补这种缺陷,由底向上不完全从最底层的模块开始,而 是分出簇(cluster)或叫构件(build)。簇是相关的一组模块,如 图11.28中的Q-A-B、Y-C、R-D、S-E设驱动模块XD、ZD测试 左右三簇,Y-C簇直接由P驱动。分簇使驱动模块减少,测试运 行次数也可相对减少,但过大的簇使测试复杂性增加。
5
桩和驱动模块
模块不是孤立的,因此在孤立测试一个模块时要设计驱 动模块(driver)和桩(stub)模块才能测试。驱动模块 是一个简单的调用程序,但应便于各测试用例的输入, 抄录被测模块用到的全局数据,并给出显眼的输出。 被测模块运行中如调用其他模块,被调用的子模块设 计为桩模块。桩模块尽量不干扰被测模块,例如子模 块的功能是矩阵转置,桩中按用例放一转置后的矩阵, 一调入就返回,不要做冗长的计算而影响被测主题, 有时甚至是一空模块,只设信号值,表示已经调用过 了。复杂的计算尽量查表、插值。模块测试环境的示 意图如图 。
返回
16
开发软件必须和它的规范(模块的、子系统的、 项目的)相符,证实相符的手段是测试和验证。 如果两人做同一题目都通过测试,
A做的成品测了1天,B的测了3天(包括改错), B 的 可 测 试 性 差 。 A 的 代 码 800 行 , B 的 代 码 2 000行,运行效率A优于B。A用了两个月后老 出错,B一直正常,B的可靠性优于A……可见 质量因素是相当复杂的,要认真分析。以什么 指 标 度 量 (Metrics) , 有 了 指 标 如 何 量 度 (Measurement)是技术性很强的工作。
返回
3
按实施测试侧重
测试技术的分类方法可以有很多种。前面介绍的黑箱和白箱是按照 经典的分类方法——“忽略或知道实现细节”——对测试技术的 分类。通常在实施测试时,不同的情况下有不同的侧重点,根 据这点有另一种常用的分类方法。这种分类方法也称为“基于 测试如何产生”。它的各种测试技术也采用黑箱和白箱技术。 根据它可将测试技术分为以下几类:
严格说来,传统基于模块的单元测试只相当于面向对象方法体的 测试,而面向对象的方法体一般很简单,一两句、十来句完成 单一小功能,一个类有多个
返回
12
11.1.4测试文档
在软件分析和设计时就要准备写出测试计划,到设计完 成后及时写出测试规格说明
11.1.5面向对象软件测试
1面向对象测试的特点 (1)测试重点转移 (2)按模型设计测试用例 (3)充分利用测试工具 2面向对象测试种类和样式 九种类别的测试覆盖了面向对象测试的所用方法
返回
11
• 面向对象软件测试
和传统软件一样,面向对象软件测试的目的也是要以可承受的开 销找出尽可能方法,接口测试胜于方法体。一个功能单元往往 是多个类的小簇。小簇按样式组织。单元测试一般是白箱的。 多的瑕疵。但是,面向对象软件本身特有的性质决定了测试技 术和策略有了较大的改变。
面向对象测试的特点
•测试重点转移
返回
22
1风险管理 11.4软件项目管理
(1)风险因素:产品大小,业务相关,客户相关,
技术相关,开发环境,组织大小和人员经验,重用 件相关,过程相关
P-X-Q-A-B-Y-C-Z-R-D-S-E
返回
9
回归测试
增量测试中常常因增加了模块改变了配置,原先测试 过并改正了的程序又出现问题。回归测试 (regression testing)是将测试过的用例的子集重 新执行,以确保新的变更不会产生不希望的边界效 应。回归测试主要的工作是收集有代表性的用例子 集 , 可 以 人 工 整 理 , 也 可 用 找 回 归 (capture playback) 工 具 辅 助 完 成 。 整 理 出 的 回 归 测 试 集 (suite)包含这些内容:程序的每种功能的典型样板 用例(为以后测试用);对每种更改特别敏感的用例; 已改好的软件构件的用例(以便其他项目用此构件时 直接用以测试)。。
18
软件质量与度量
⑵隐式的。满足本企业(单位)所有的期望,例如 某项功能和性能超出本项目规范说明定义的需求, 以占领市场。返回19来自11.3.2 软件质量保证
软件质量保证(SQA)是一种管理活动,由两类不同 的任务组成。一类是软件工程师负责质量方面的 技术工作:运用技术方法做出量度(如功能点、代 码行);进行正式技术评审(FTR);实施测试计划。 另一类任务由SQA小组(由项目经理、开发人员、 客户、销售人员组成)制定并实施SQA计划;做出 记录;分析;报告。
返回
4
• 基于代码 这种技术依据程序的控制流或数据流, 要求测试覆盖所有的控制流或数据流路径。因此, 它使用白箱技术。
• 基于故障 采用这种技术时,测试的目的在于展现 出可能的或预先定义好的故障。它可以使用黑箱、 白箱或混合测试。
• 基于使用 为了保证测试的可靠性,测试环境应尽 可能地和实际操作软件的环境一致。
白箱测试也叫路径测试。所有的语句必须执行一次以 上,这是最起码的要求。彻底些,每条路径都要走 到,因为if E then A 当E为‘假’时它沿空路径走 出程序,走不出就是错。所有路径都走一遍还不能 保证彻底。因为每个判断的子条件也可能从未用过。 只有每个判断的子判断为‘真’为‘假’都走一遍 才相对彻底。
返回
14
维护模型
制定维护计划必先有维护模型。有两类维护模型:
• 日常维护
也叫快速修理(quick-fix)。对于属于这类的正确 性维护和简单的适配性维护,直接从修改代码 入手。然后修改设计、分析、测试文档。计划、 人员组织、成本、验收相对简单。这也是所谓 的小修小改。