软件质量保证与测试 第2讲 软件测试的基本概念和方法

Presentation on theme: "软件质量保证与测试 第2讲 软件测试的基本概念和方法"— Presentation transcript:

1 软件质量保证与测试 第2讲 软件测试的基本概念和方法
软件质量保证与测试 第2讲 软件测试的基本概念和方法

2 软件测试的基本概念和方法 1 软件质量就是客户的满意度 2 软件缺陷(Bug)是什么 3 软件测试的基本方法 4 软件测试的分类和阶段
5 软件测试的工作范畴

3 软件质量的内涵 软件质量是客户满意度的体现 客户 + 质 + 量?

4 质量 (Quality) 质量是系统、部件或过程满足 明确需求 客户或用户需要或期望的程度不同 软件质量：软件产品具有满足
质量是系统、部件或过程满足　 明确需求 客户或用户需要或期望的程度不同 IEEE <<Standard Glossary of Software Engineering Terminology>> 软件质量：软件产品具有满足 规定的或隐含要求能力要求有 关的特征与特征总和(ISO 8492)　 软件质量：软件产品满足 使用要求的程度

5 软件质量范围- 3A Accountability (可说明性) – 用户可以基于产品或服务的描述和定义进行使用. (例如: 市场需求说明书, 功能设计说明书.) Availability (有效性) – 产品或服务对于99.999% 客户总是有效的 (例如: 性能测试和恢复测试) Accessibility (易用性) – 对于用户, 产品或服务非常容易使用并且一定是非常有用的功能 . (例如: 确认测试和用户可用性测试)

6 高质量的软件 “客户”广义定义 : 内在的定义 : 下一个环节/工序的接收者，更广的服务的对象，周围有任何联系或影响的团队、人。
应该是相对的无产品缺陷(Bug Free)或只有极少量的缺陷, 它能够准时递交给用户并且所用的费用都是在预算内的并且满足客户需求，是可维护的。但是, 有关质量的好坏最终评价依赖于用户的反馈。 “客户”广义定义 : 内在的定义 : 下一个环节/工序的接收者，更广的服务的对象，周围有任何联系或影响的团队、人。 软件的设计者，程序的检测者，项目管理者，品质管理人员 … - 广泛的定义 : 最终用户，客户管理，

7 软件质量不同的视点 先验论观点：质量是产品一种可以认识但不可定义的性质 制造者的观点：质量是产品性能和规格要求的符合度
用户观点：质量是产品满足使用目的之程度; 制造者的观点：质量是产品性能和规格要求的符合度 产品观点：质量是联结产品固有性能的纽带; 基于价值观点：质量依赖于顾客愿意付给产品报酬的数量

8 高质量软件标准体系 产品质量 过程质量: 在商业过程中有关的质量内容:
是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量. 质量模型: McCall 模型, Boehm 模型, ISO 9126 模型 过程质量: 软件能力成熟度模型 CMM ( Capability Maturity Model). 国际标准过程模型 ISO 9000 软件过程改进和能力决断 SPICE ( Software Process Improvement and Capability dEtermination) 在商业过程中有关的质量内容: 培训、成品制作、宣传、发布日起、客户、风险、成本、业务等

9 产品质量的标准 - 功能性 Functionality - 可用性 Usability (简单安装; 轻松使用; 友好界面)
- 可靠性 Reliability (用户使用的根本) - 性能 Performance - 容量 Capacity - 可测量性 Scalability - 可维护性 Service manageability - 兼容性 Compatibility - 可扩展性 Extensibility

10 软件质量特征 ( ISO9126) 功能：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
可靠：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。 易用：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。 效率：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。 可维护：与进行指定的修改所需的努力有关的一组属性。 可移植：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。

11 Boehm软件质量模型 正确性 可靠性 效率 完整性 可用性 可维护性 可测试性 灵活性 可移植性 重复性 互用性 阐述性 连贯性 容错性
执行效率/储存效率 存取控制/存取检查 可训练 沟通良好 简单性 易操作的 工具 自我操作性 扩展性 一般性 模块性 软件系统独立性 机器独立性 通讯公开性 可操作性 阐述性 互用性 数据公开性

12 McCall模型 可移植性 可靠性 效率 可测试性 可维护性 易更改 易用性 总体 效用 易懂性 人体工程学 设备独立性 模块独立性 精确性
总体 效用 易用性 可维护性 可测试性 人体工程学 可移植性 易懂性 精确性 完整性 完全性 可说明性 设备功效 易操作性 沟通良好 自我操作性 架构性 简明性 模块独立性 连续性

13 软件过程质量 软件能力成熟度模型 CMM ( Capability Maturity Model). 国际标准过程模型 ISO 9000
软件过程改进和能力决断 SPICE ( Software Process Improvement and Capability dEtermination)

14 质量保证的策略 主要分三个阶段： 以检测为重：产品制成之后进行检测，只能判断产品质量，不能提高产品质量。
以过程管理为重：把质量的保证工作重点放在过程管理上，对制造过程 中的每一道工序都要进行质量控制。 以新产品开发为重：在新产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患。

15 全面质量管理 (TQM) TQM = Total Quality Management 全面质量管理
全员参与质量管理 全过程质量管理。 TQM的4个关键要素: 关注客户 过程改进 质量的人性化因素 度量(即模型的测量和分析)

16 质量管理发展五个阶段 1900 1920 1931 1960 2000 手工操作者 专职检验员 过程统计技术 全面质量管理 以顾客为中心 阶
时间 2000

17 任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求
2.2 软件缺陷(Bug)是什么 Any problem/disfigurement/limitation in product design & development Feature or function can’t work Unreasonable design Partly realization in function Data error Run error Limitation in features Difference between actual results and expected results Unfriendly UI, Low performance Others 任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求 什么是 Bug?

18 问题出在哪里？ 项目没有被很好地理解；计划不周，最终导致进度拖延。 没有充分的文档资料。 人与人的交流比写程序困难得多。
软件可靠性缺少度量的标准，质量无法保证。 软件难以维护、不易升级。

19 解决问题的想法 Better management 管理 Different team organizations 组织
Better languages & tools 语言和工具 Uniform coding conventions 编程惯例 必须意识到：“软件” ≠ 编程，它有自己的生命周期 (life cycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。

20 软件测试 实践证明：对软件进行充分的测试 才能够有效的保证软件质量 对软件产品进行充分测试，找出其中的缺陷(Bug),并进行修复(Fix)。

21 缺陷 - Bug 缺点（defect） 偏差 （variance） 谬误（fault） 失败 （failure）
问题（problem） 矛盾（inconsistency） 错误（error ） 毛病 （incident ） 异常（anomy）

22 软件缺陷 IEEE (1983) 729 软件缺陷一个标准的定义： 软件缺陷的主要类型/现象：
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷的主要类型/现象： 功能、特性没有实现或部分实现 设计不合理，存在缺陷 实际结果和预期结果不一致 运行出错，包括运行中断、系统崩溃、界面混乱 数据结果不正确、精度不够 用户不能接受的其他问题，如存取时间过长、界面不美观

23 软件缺陷的产生 技术问题 算法错误，语法错误，计算和精度问题，接口参数传递不匹配 团队工作 误解、沟通不充分 软件本身
文档错误、用户使用场合(user scenario)， 时间上不协调、或不一致性所带来的问题 系统的自我恢复或数据的异地备份、灾难性恢复等问题

24 软件缺陷构成

25 软件缺陷在不同阶段的分布 在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。
规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现，而不能在需求分析一个阶段发现

26 缺陷成本

27 软件测试是质量控制的重要手段，保证客户拿到或用户使用高质量的软件产品
2.3软件测试的基本方法 根据G.J. Myers观点--软件测试的目: 软件测试是为了发现错误而执行程序的过程 一个好的测试能够在第一时间发现程序中存在的错误 一个好的测试是发现了至今尚未发现的错误的测试。 软件测试是质量控制的重要手段，保证客户拿到或用户使用高质量的软件产品

28 软件测试误区 误区一：如果发布出去的软件有质量问题，都是软件测试人员的错 误区二：软件测试技术要求不高，至少比编程容易多了
误区三：有时间就多测试一些，来不及就少测试一些 误区四：软件测试是测试人员的事，与开发人员无关 误区五：根据软件开发瀑布模型，软件测试是开发后期的一个阶段

29 软件测试的原则 所有测试的标准都是建立在用户需求之上。
软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合。

30 软件测试的原则 （2） 第三方进行测试会更客观，更有效。 软件测试计划是做好软件测试工作的前提。
测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）

31 软件测试的原则 （3） 应当把“尽早和不断地测试”作为测试人员的座右铭
回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见 测试应从“小规模”开始，逐步转向“大规模”。 不可将测试用例置之度外，排除随意性。 必须彻底检查每一个测试结果。 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系 对测试错误结果一定要有一个确认的过程。

32 测试方法 黑盒子和白盒子 静态的和动态的 文档、代码审查 数据输入边界条件法 等价划分、数据流程图 状态变换图 逻辑路径法

33 黑盒子和白盒子 结构测试 逻辑驱动测试 客户需求 事件驱动 输入 输出 功能测试 数据驱动测试

34 静态的和动态的 主持人 作者 记录员 列席人员 内审员 技术专业人员 用户代表 不正式 正式 互审 走读 审查会议 运行程序

35 自动测试和手工测试 手工模拟用户操作

36 验证和确认（V & V） Verification：Are we building the product right？
是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性 Validation： Are we building the right product? 是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求

37 2.4 软件测试的分类和阶段 开发生命周期 测试生命周期 ... 维护 需求定义 应用定义 应用开发 修订 建立 执行. 执行 测试计划
缺陷跟踪 测试开发 测试设计 评估

38 软件测试分类 测试阶段或层次 目标/特性 方法 单元测试 系统测试 验收测试 性能测试 强壮性测试 功能测试 白盒测试 黑盒测试 适用性测试
可靠性测试 集成测试 安全性测试

39 软件测试阶段 阶 段 输 入 输 出 需求分析 需求定义, 市场分析文档, 相关技术文档 市场需求分析会议记要 , 功能设计, 技术设计
输 入 输 出 需求分析 需求定义, 市场分析文档, 相关技术文档 市场需求分析会议记要 , 功能设计, 技术设计 设计审查 市场需求文档, 技术设计文档 测试计划, 测试用例 功能验证 代码完成文件包,功能详细设计说明书 最终技术文档 完整测试用例,完备的测试计划, 缺陷报告, 功能验证测试报告 系统测试 代码修改后的文件包 完整测试用例,完备的测试计划 缺陷报告 缺陷状态报告 项目阶段报告 确认测试 代码冻结文件包 确认测试用例 缺陷报告审查 版本审查 版本发布 代码发布文件包 测试计划检查清单 当前版本已知问题的清单 版本发布报告 MRD: Market Requirement Document Fns: Functional Specification

40 测试阶段（SDLC)

41 单元测试 单元测试的对象是程序系统中的最小单元---模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块 单元测试一般由编程人员和测试人员共同完成

42 集成测试 集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题 两种集成方式：一次性集成方式和增殖式集成方式。

43 功能测试 功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用

44 系统测试 系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等

45 验收测试 &安装测试 验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样
安装测试是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试

46 2.5 软件测试的工作范畴

47 Q & A