软件质量保证基本知识加复习建议_西安交通大学软件质量保证

本文内容整理自西安交通大学软件学院杜小智老师的mooc附件ppt

mooc链接：软件质量保证_中国大学MOOC(慕课)

写在前面

本文是我在复习软件质量保证课程时整理的复习资料，内容不是很全，只涉及到了Mooc的前两章内容，考试内容我也不太记得了，需要特别强调的是他考到了实验！！！就是让做的那个JUnit5的实验，考的也比较简单，我们只考到了让编写对于一个东西的测试代码，如果实验自己写的完成这个也不是很困难，然后再就是给了一个网易邮箱的注册界面，让等价类分析，然后还有路径测试，和边界值测试，其实上课虽然讲了10种，但是应该就只考了这三种，可以看看mooc的视频或者ppt，我也整理出来了，如果需要的话可以看这（里面整理到的题目都必须要搞懂，不然考试就备受折磨）。选择和简答也中规中矩，但我记不得有啥，不过不是很难，应该有RUP？或许吧，反正应该就是mooc前两章的东西，如果不会的话编起来也挺容易的（我自己觉得是这样的）

一、软件质量保证基础知识

Six software engineering practices

• 开发迭代
• 管理需求
• 使用组件架构
• 模型可视化(UML)
• 持续验证质量
• 管理变更

相关术语

错误

• 人们在开发软件过程中发生的过错(mistake) ;
  • 客户可能未完全描述清楚他的意图;
  • 分析人员未完全理解客户的需求、编写出不完善的需求文档;
  • 设计人员未完全弄清楚需求文档描述的问题; .
  • 实现人员受限于自身能力及工作状态编写出不完善的程序;
• 软件错误是一种人为的过程， 对于软件本身来讲是一种外部行为。

缺陷

• 错误在程序中的表现;
• 存在于软件(文档、数据及程序)之中的那些不希望或不可接受的偏差;
• 当缺陷被激活时，会发生软件故障;
• 缺陷是造成软件故障甚至失效的内在原因;
• 常用Bug指代缺陷。

故障

• 软件运行过程中出现的不希望/不可接受的内部状态; .
• 软件丧失了在规定的限度内执行所需功能的能力;
• 故障是动态的，可能会导致失效;
• 故障是软件缺陷的内在表现。

失效

• 软件运行时产生的不希望/不可接受的外部行为结果;
• 系统行为对用户预期的偏离;
• 失效是软件缺陷的外在表现，只有运行中的软件才可能发生失效
• 失效可能会带来事故

总结

软件缺陷产生的原因

软件缺陷的类型

• 软件未实现需求规格说明书要求的功能;
• 软件出现了需求规格说明书指明不应该出现的错误;
• 软件实现了需求规格说明书中未提到的功能;
• 软件未实现需求规格说明书虽未明确提及但应该实现的功能; .
• 软件难以理解、不易使用、运行缓慢等，即:用户体验不佳。

软件缺陷产生的原因

需求规格说明书的问题

导致软件缺陷最大的原因是产品需求规格说明说明书

团队协作问题

• 不同阶段的团队成员相互理解不一致;
• 相互职责划分不够清晰，存在扯皮推诿情况;
• 沟通不够充分，对接口的理解不一致,造成单元无法集成;
• 公司或团队文化，对软件质量不够重视;
• 团队成员技术水平有限。

未考虑复杂的应用场景

• 未考虑大量用户同时使用软件系统的情况;
• 未考虑海量数据使用场合;
• 对于边界条件缺乏考虑;
• 只考虑正常情况，对于异常情况未充分考虑;
• 对于一些实时性系统，未进行整体考虑和精心设计，未注意时间同步要求;
• 只考虑系统自身，未考虑系统与第三方软件及硬件之间的依赖关系。

技术方面问题

• 开发人员的技术具有局限性;
• 新技术不成熟或对新技术不够熟练，使得软件存在缺陷;
• 用户的要求在现有技术水平下不可能实现;
• 软件逻辑过于复杂，在问题分解时划分的不够合理。

总结

• 引起软件故障的原因涉及:人员、技术、管理及成本等多方面;
• 缺陷的存在是软件不能按期完成或失败的重要原因。

软件缺陷分类

按开发阶段分类

按严重程度分类

典型的软件缺陷

输入、输出缺陷

数据缺陷

计算缺陷

逻辑缺陷

缺口缺陷

软件质量

质量定义

质量不等于需求规格说明书

不同人对于质量的关注点不同

质量维度

质量维度：FURPS

• 功能测试：Function test
• 易用性测试：Usability test
• 可靠性测试：Reliability test
• 性能测试：Performance test
• 可支持性测试：Supportability test

功能测试

易用性测试

可靠性测试

性能测试

可支持性测试

质量的维度

Qos/非功能性需求

软件质量定义

• GB/T12504-90：软件蚕品种能满足给定需求的各种特性的综合。这些特性称为质量特性，包括：功能性、可靠性、易用性、可维护性、可移植性、经济性等
• ANSI/IEEE 729标准：软件产品中能慢组规定的和隐含的与需求有关的全部特征和特性

软件质量模型

软件质量模型

• McCall质量模型
• ISO/IEC 9126质量模型
• Boechm质量模型
• ISO 9000:2000质量标准
• Perry模型

McCall质量模型

产品操作质量因子

产品修复和产品转变质量因子

质量标准

总结

ISO 9126质量模型

质量特性与子特性

两种模型异同

相同

不同

总结

没有一种标注的质量模型可以应用于各类软件项目

软件质量保证

软件质量保证的定义

软件质量保证（Software Quality Assurance，SQA），是确保软件产品自诞生起到消亡止的全生命周期的质量活动，即确定、达到和维护需要的软件质量高而进行的所有有计划的系统性管理活动。

目标

• 保证软件开发及其维护符合功能与技术需求;
• 保证软件开发及其维护符合管理需求;
• 为实现前两个目标，组织一些活动来改进软件开发效率和维护效率。

软件质量保证活动

• 项目前质量活动
• 软件生命周期中的质量活动
• 基础设施方面
• 管理方面的质量活动
• 软件质量标准
• SQA自身的考虑

项目前质量活动

• 合同评审活动
  • 确保用户需求清晰、确保项目规划和资源需求估计合理、对参与项目的专业员工的能力进行评审、评估客户能否正常履行合同、并对开发风险进行评估。
• 制定开发计划
  • 开发进度及人员安排进行规划,明确所需要的硬件资源、开发工具、过程管理方式，确定与合作伙伴的分工与协作。
• 制定质量计划
  • 明确质量目标、并将质量目标分解为多个可量化的子目标，明确每个阶段开始和结束的质量标准，给出较为详细的评审、测试、验证及确认活动的安排。

软件生命周期中的质量活动

基础设施方面

管理方面的质量活动

软件质量标准

SQA自身的考虑

SQA与软件测试的对比

• 软件质量保证（SQA）
  • 面向过程
  • 注重减少开发过程中的错误做法
  • 过程：怎样做事情
• 软件测试
  • 面向产品
  • 注重发现产品中的缺陷
  • 产品：过程的最终结果
• 交汇点
  • SQA一般通过努力改进过程来改进产品

软件测试定义与目标

软件测试

• 保证和提高软件质量的手段
• 更关注软件产品
• 重点在于发现软件产品中的缺陷

软件测试定义

• 狭义定义：
  • 为了发现错误而执行程序的过程
• 广义定义：
  • 在软件开发过程中的所有评审、确认、检验等活动

定义说明

• 由特定测试团队执行的一个正式过程
• 按照预先计划的测试过程来执行计划的测试用例
• 软件行为是可以预测的且稳定的
• 软件测试不等于软件使用

软件测试目标

• 直接目标
  • 发现尽可能多的缺陷
  • 评估软件质量
  • 在规定的时间和预算内，执行测试工作
• 简介目标
  • 编制软件错误记录，用于错误预防

讨论

是否可以通过测试发现所有缺陷？

• 比如穷举行测试，一般而言是不行的，采用穷举行测试不显示也不可能
• 即使可以穷举所有路径，程序可能依然存在错误
  • 路径测试并不能保证程序满足系统功能需求
  • 程序可能遗漏了某些路径
  • 路径测试难以返现数据敏感的错误

目标：以有限的输入，返现尽可能多的bug

软件测试模型

软件测试模型

• V模型
• W模型
• X模型
• H模型

V模型

• 单元测试与详细设计对应;
  • 主要针对程序源码进行测试;
  • 通常发生在项目的早期，在每个最小可测单元完成之后，立即进行测试工作;
  • 通常由开发人员执行单元测试，以保证自己编写的程序不包含明显的缺陷;
  • 也可以由测试人员进行单元测试来检验该程序单元是否满足了预期要求。
• 集成测试对应于概要设计
  • 涉及多个单元综合在一起进行测试
  • 单元之间数据传递是否正确
  • 单元之间的接口是否一致
• 系统测试对应于需求分析;
  • 将所有程序单元综合在一起;
  • 并同计算机硬件、输入输出接口设备、第三方系统、数据以及人等一起进行测试;
  • 涉及功能性、非功能性方面。
• 验收测试由用户主导
  • 目的是为了检验软件开发团队所交付的软件是否满足其最终需求;
  • 采用真实的业务数据;
  • 不仅关注功能是否实现，还关注程序的非功能性要求;
  • 可能会请一-些专家及组织中相关人员来使用软件，或者请第三方测试机构来检验软件。

缺点

• 将测试活动作为编码之后的一个环节，理论上还是一个瀑布模型，只是将测试活动进行了细化;
• 通过测试发现的缺陷，修复成本往往很高。

W模型

• 基于尽早地和不断地进行测试的原则;
• 验证(Verification)
  • 是指开发人员是否在正确地做事情，强调过程的正确性,不仅检验当前阶段是否正确，还检验当前阶段是否与上一个阶段相一致;
• 确认(Validation)
  • 是指开发人员是否在做正确的事情,强调结果的正确性,不仅检验当前阶段是否正确，还检验当前阶段的工作是否与用户的需求相一致。
• 优点
  • 强调测试应伴随整个软件开发周期;
  • 测试的对象也不仅仅是程序，还包括需求、设计及相关文档。
• 缺点
  • 仍然将开发活动分解为需求分析、设计、编码等串行活动; .
  • 测试和开发之间也是一种线性的先后关系;
  • 不支持迭代式开发。

软件测试分类

6个维度分类

• 按阶段分类
• 按是否运行软件分类
• 按设计方法分类
• 按测试执行者分类
• 按需求分类
• 按测试对象分类

按单元分类

• 单元测试(Unit testing) 针对的是一-个小的程序单元，用于检验该单元是否满足预定功能;
• **集成测试(Integration testing) **是将多个被测后的程序单元综合在一起进行的一种测试活动，其目标主要是发现与接口有关的问题;
• **系统测试(System testing) **是将所有程序单元综合在一-起， 并同计算机硬件、输入输出接口设备、第三方系统以及人等一起进行测试;
• **验收测试(Acceptance testing) **是由用户主导的测试，目的是为了检验软件开发团队所交付的软件是否满足其最终需求。

按是否运行软件分类

• **静态测试(Static testing)是指不需要执行被测软件而进行的测试活动。
  • 桌面检查、代码走查、同行评审、静态分析等;
  • 往往能发现大量错误(浅显)
• **动态测试(Dynamic testing) **是指实际执行软件的测试活动，在测试过程中，将预先设计好的测试用例或临时设计的测试用例输入给被测软件，然后判断程序的输出是否符合预期，往往能够发现些深层次错误。

按设计方法分类

• 黑盒测试(Black box testing)、行为测试、功能性测试或基于需求的测试。
  • 只关心软件的输入和输出、不关心软件采用哪种编程语言实现;
  • 设计依据是软件需求规格说明书。
• 白盒测试(White box testing)、玻璃盒测试(Glass box testing)、透明盒测试或结构性测试(Structural testing)。
  • 基于程序源码的测试。
• 灰盒测试(Gray box testing)
  • 介于白盒测试与黑盒测试之间，是二者相结合的方法。

按测试执行者分类

• 人工测试(Manual testing) 也称为手工测试，是指测试工作由人来逐个完成。测试人员通过手工方式给被测软件输入-个测试用例，等被测软件执行完成以后，手工记录该测试用例是否通过。
• 自动化测试(Automatic testing) 是由计算机自动完成的测试，在测试过程中，不需要或很少需要人工干预。录制/回放、脚本技术、数据驱动、关键字驱动和业务驱动等;
• 人工测试与自动化测试相结合。

按需求分类

• 功能性测试(Functional testing) 主要基于软件需求规格说明书进行测试，验证软件是否实现了所期望的每个功能，也包括检验软件是否存在多余功能或遗漏了某些功能。
• 非功能性测试(Non-functional testing) 是指出功能性测试之外的其它系统级别的测试。
  • 性能测试、安全性测试、可靠性测试、易用性测试、兼容性测试、压力测试、文档测试、用户界面测试…

按测试对象分类

• 桌面程序测试是经典的软件测试，在互联网出现之前，软件测试多数属于桌面程序测试。它针对的是运行于计算机上的本地化程序。
• 嵌入式系统测试不仅关注其功能是否满足需求，更加关注其性能、可靠性等方面的需求Web程序的测试不仅局限于功能方面的测试,还需要考虑性能测试、界面测试、安全性测试及兼容性测试。
• Web程序的测试不仅局限于功能方面的测试，还需要考虑性能测试、UI测试、安全性测试及兼容性测试。
• 移动APP测试包括功能性测试、兼容性测试、隐私测试等。

软件测试原则

10个原则

测试思想与测试用例

测试思想

概念

• 测试思想（Test idea）是辨别某个测试可能有用的简要说明
• 测试思想与测试用例不同，它是测试用例的思想来源

来源

案例

某程序接受范围为[10,100]的整型输入,有哪些输入值的思考

测试用例

组成

• 输入：前提（在测试用例执行之前已经出在的环境）、由某种测试方法所表示的实际输入
• 预期输出：后果和实际输出

测试活动

典型测试用例信息

二、软件测试流程

RUP测试流程

RUP（Rational Unified Process）

软件过程

• 软件工程过程提供规范但灵活的方法来指派软件项目团队中每个成员的任务和职责
• 目标是在规定的时间和预算内，保证软件产品的质量满足用户的需求
• 过程定义了为达到某个目标，谁(who) 应该做什么(what)、在什么时候(when) 做、如何(how) 做

软件工程生命周期

RUP基本术语

RUP软件侧测试角色

• 测试经理(Test Manager)
  • 对整个测试工作负责
  • 明确测试任务与目标
  • 制定测试计划
  • 安排测试人员
  • 协调资源
• 测试分析师(Test Analyst)
  • 分析被测软件的特征
  • 细化测试目标
  • 构思测试思想
  • 设计测试用例
  • 准备测试数据
  • 分析测试结果
  • 编写软件缺陷报告
• 测试设计师(Test Designer)
  • 测试开发工程师、测试架构师、测试自动化专家
  • 定义测试方法
  • 确定测试环境和配置
  • 开发自动化测试工具
  • 提供测试指导手册
  • 本质上是开发人员
• 测试员(Tester)
  • 执行测试用例
  • 记录测试结果
  • 测试_工作的执行者，可以利用测试设计师提供的自动化测试工具执行测试工作
  • 对自动化测试能否成功起到很重要作用
  • 可能会编写测试脚本

RUP测试流程

定义评估任务

主要任务

定义评估任务（Define Evaluation Mission）的目标：确定测试工作的重点

常见目标

目标变化

• 测试团队可能会同时有多个目标;
• 测试团队的工作目标也会随着软件生命周期而发生变化;
• 每次迭代的目标明确非常关键，并基于目标来进一步制定计划

指定测试计划

• 考虑被测软件的特征、测试团队的人员组成、测试周期、测试目标等因素;
• 明确规定测试工作的范围、方法、资源和进度
• 明确每个任务的责任人，评估可能存在的风险。
• 指定工作范围不完全等同于开发工作范围
  • 测试考虑更多
  • 每次迭代的测试目标不同

测试方法

• 测试方法（Test Approach）有时也称为测试策略（Test Strategy）
• 确定将要具体使用的测试技术，从而完成预期测试使命
• 一个好的测试方法通常包括五个方面
  • 多样性
  • 以风险为中心
  • 与产品相关
  • 实际可行
  • 可防御

多样化

• 不应只采用一-种测试技术，而是同时采用多种技术;
• 每一种测试技术都有优缺点，只适合发现某类问题，而对于其它类型的缺陷则无法发现;
• 同时综合应用多种测试技术，有助于增加发现软件缺陷的概率。

以风险为中心

与产品相关

实际可行

可防御

测试与评估

测试与评估的目标

• 工作重心：如何达到所需的测试深度和广度
• 测试执行工作并对测试结果进行分析
• 设计测试分析师和测试员

需要解决的问题

• 如何进行测试工作
• 如何评估测试结果
• 如何编写缺陷报告

测试技术

测试技术

测试技术的维度

缺陷报告

• 缺陷报告体现了测试员的能力
• 一个优秀的测试员，不一定是发现缺陷数量最多的那个人，而是使缺陷被修复数量最多的那个人。

拒绝修复缺陷的原因

如何让程序员接受缺陷

编写缺陷报告原则

• 清晰
• 简单

缺陷报告

缺陷报告示例

跟随测试

• 当发生失效时，要进行跟随测试: .
  • 分析失效产生的条件
  • 发现失效发生的规律
  • 分析边界条件
  • 分析不可复现的缺陷

为什么要跟随测试

例子

不懂缺陷，临界条件，失效

跟随测试定义

• 跟随测试是一种探索性测试
• 有助于帮助开发人员理解缺陷并加快缺陷的修复
• 在开始看到失效后继续进行测试，以期望发现缺陷的所有影响

跟随测试技术

• 改变测试行为
• 改变选项和配置
• 改变运行环境
• 改变测试数据

改变测试行为

改变选项和配置

改变运行环境

• 软件环境
  • 操作系统、数据库、浏览器
• 硬件环境
  • 处理器类型、内存大小、网络带宽
• 在测试过程中，应该同时在两台配置完全不同的计算机上执行测试工作，从而检查缺陷是否和运行环境有密切关系

改变测试数据

• 测试数据的变化也会给程序带来较大的影响
  • 小文件->大文件
  • 小的并发量->大的并发量
• 在实际测试工作中，要认真设计测试数据，从而更有效地发现程序中存在的缺陷

完成验收任务

主要任务

• 涉及两类角色:测试经理和测试分析师
• 主要任务:撰写测试总结报告
• 不断反馈测试I作的进展情况
  • 目前已进行了多少测试工作?
  • 还有多少测试工作需要完成?
• 这两个问题是复杂的多维度问题，不能简单回复

测试工作进展

测试总结报告

• 风险和职责
• 测试情况汇报
• 缺陷度量
• 延期或不修复bug的确认

风险和职责

测试情况汇报

缺陷度量

• 自开始到现在项目出现的Bug情况以及修复情况用图的方式展示
• 直观明了地了解项目的质量状态
• 在项目的后期，如果Bug修复率低于Bug发现率，项目规划存在风险

理想Bug曲线

实际的Bug曲线

延期或不修复Bug的确认

验证测试方法

• 目的：确定测试方法是否可行

• 工作重点

  • 较早地验证测试方法是否可行
  • 建立支撑架构
  • 获得需要的可测试性
  • 了解每种测试技术的优缺点和适用情况

• 可测试性（Testability）

  • 可见性（Visibility）
    • 测试人员能够看到和理解软件正在做什么
  • 可控性（Control）
    • 测试人员能够强迫某些事情发生

• 改进软件的可测试性

  • 增加软件的可见性

    • 软件使用标准的UI控件
    • 对于每 个类型的错误，设定唯一的错误消息， 增加关于程序内部的可能错误的消息
    • 充分利用日志系统

  • 采用基于组件的架构

    • 通过API来进行自动化测试
    • 暴露接口规范，提供除U接口之外的更多API

  • 使用一些设备和工具.

    • 内存查看器、仿真器

确认构建稳定性

• 冒烟测试、构建回归测试、构建验证测试
• 目的：确认构建足够稳定从而值得测试
• 工作重点:
  • 评估构建的稳定性
  • 评估构建的可测试性
  • 确认这个版本的开发工作符合预期
  • 决定是否值得测试这个构建
  • 如果新的构建被拒绝，继续测试当前版本的软件

为什么构建稳定性重要

确认构建稳定性

改进测试资产

• 目的：维护和改进测试资产，增加复用性
• 工作重点：
  • 构建测试套
  • 为测试套编制测试脚本
  • 去除过时的测试资产或投资收益比不高的资产
  • 维护测试环境配置