软件测试

软件测试基本概念

软件测试基础

定义
使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定需求或是弄清预期结果与实际结果之间的差别；验证软件是否满足需求；
目的
- 发现缺陷
- 增加信心
- 提供信息
- 预防缺陷
  用最少的人力、物力、财力，找到软件中的问题并修复，从而降低商业风险；
原则
- 应该基于客户需求
- 要尽早进行
- 穷尽测试是不可能的
- 遵循GoodEnough原则/零缺陷和足够好
- 测试缺陷要符合“二八”定理
  一般情况下，软件80%的缺陷会集中在20%的模块中；
- 避免缺陷免疫
  测试用例被反复使用，会导致发现缺陷的能力就会越来越差；
误区
- 软件开发完成后进行软件测试；
- 软件发布后如果发现质量问题，就是软测人员的错；
- 软测要求不高，随便找个人都能做；
- 软测是测试人员的事情，与程序员无关；
- 项目进度吃紧少做测试，时间富裕时多做测试；
- 软测没有前途；

软件测试流程

软件测试基本流程
- 软件需求分析
- 测试计划编写
- 测试用例编写
- 测试执行
- 测试报告
测试准入标准
- 开发编码结束，开发人员已完成单元测试
- 软件需求上功能已经实现
- 测试项目通过基本的冒烟测试，界面功能基本实现
- 被测试项目代码符合软件编码规范且通过评审
- 开发者提交测试申请并提供相应文档
测试准出标准
- 满足客户需求
- 测试用例通过评审并成功
- 覆盖率达到要求
- 发现缺陷都记录到缺陷管理系统中
- 一二级错误修复率100%
- 三四级错误修复率95%
- 遗留问题有解决方案
- 测试项目的功能、性能、安全性达到要求
- 完成总结报告

软件测试的分类

按照阶段分类
- 单元测试
- 冒烟测试
- 集成测试
  - 静态测试
    a. 代码检查
    b. 静态结构分析
  - 动态测试
    a. 主动测试
    b. 被动测试
- 系统测试
- 验收测试
按照测试技术分类
- 黑盒测试
- 白盒测试
- 灰盒测试
按照特性分类
- 性能测试
- 功能测试
按照自动化程度分类
- 手工测试
- 自动化测试
按照测试类型分类
- 界面类测试
- 功能测试
- 性能测试
- 安全性测试
- 文档测试
- 兼容性测试
- 配置测试
其他分类
- α测试
- β测试
- 回归测试
- 随机测试
  代码检查包括桌面检查、代码审查、代码走查

软件质量

质量的定义
ISO8420关于质量的定义：反映实体满足明确或隐含需求的特性总和；
软件质量的定义
反映软件满足明确或隐含需求的特性总和；
基本需求、用户需求、隐式需求
软件测试&&软件质量
软件测试的目的：使用技术手段满足需求；
软件测试的手段：通过找bug验证软件与需求的一致性；
狭义的软件质量：产品无明显缺陷；
软件测试可以验证软件质量；
软件测试只能测试已经完成的内容是否符合需求，只能发现已有的缺陷；
软件质量可以预防没用发现的缺陷；
软件质量和软件测试的管理模式不同：
a. 软件测试的思想：发现问题，解决问题；
b. 软件质量的思想：制定标准，预防问题；

软件质量模型

分类
- 基于经验的模型
  - 层次模型
  - 关系模型
- 基于构建的模型
  通过提供一些方法来构建一个质量模型，包括质量属性之间关系的构建和对质量属性进行分析；
软件质量模型ISO/IEC 9126:1991标准的6大特性
- 功能性
  - 适合性：提供了用户所需要的功能
  - 准确性：提供功能的精确度是否符合目标
  - 互操作性：软件和其他系统进行交互能力
  - 保密安全性：软件保护信息和数据的安全能力（权限和密码）
- 可靠性
  - 成熟性：对内错误的隔离
  - 容错性：对外错误的隔离
  - 易恢复性：失效后，恢复原有功能和性能
- 易用性
  - 易理解性
  - 易学性
  - 易操作性
- 效率
  - 时间特性
  - 资源利用性
- 维护性
  - 易分析性
  - 易改变性
  - 稳定性
  - 易测试性
- 可移植性
  - 适应性
  - 易安装性
  - 共存性
  - 易替换性

软件质量度量

平均失效时间
概念：软件在规定环境下，正常运行到下一次故障的平均时间；
MTTF计算十分困难
- 缺陷和失效不是一一对应
- 数据采集困难
  用于安全性较高的系统；
缺陷密度
(1). 概念：用于测量与软件规模相关的缺陷率；
(2). 缺陷率=缺陷数/一定时间范围内的软件规模；
- 时间范围一般一年为单位；
- 软件规模
  - 代码行
  - 功能点
    (3). 基于代码行的缺陷率一般使用每千行代码的缺陷数（KLOC）来计算缺陷率；
    (4). SSI（i）=SSI（i-1）+CSI（i）-删除的代码-修改的代码；
- 代码行：基于指令语句，包括可执行代码和数据定义；注释
- SSI：整个软件产品的代码行；
  - CSI：新版本增加和修改代码对应的代码行；
    (5). 总缺陷数/KSSI：评价整个产品的代码质量；
    实际应用缺陷数/KSSI：评价应用领域内的缺陷率；
    版本的缺陷数/KCSI：评价当前版本的开发质量；
    版本的应用缺陷数/KCSI：评价针对用户发现的缺陷的开发质量；
    (6). 缺陷率=缺陷数/代码行；
    缺陷数=缺陷率*代码行；
    目标：更少的缺陷数；
    (7)基于代码行的缺陷率：
  - 从技术角度估算软件规模
  - 局限性
    (8). 基于功能点的缺陷率从功能的角度很亮软件规模，软件开发的目标是满足客户需求，而向用户提供一定的功能；
  - 功能：执行一定任务的可执行语句的集合；
  - 平均每个功能点的缺陷数越低，软件质量越好；
  - 局限性

用户满意度度量

用户问题
(1). PUM(用户-月问题数)；
- PUM = 一段时间内用户报告的问题总数/用户数；
  - 用户报告的问题：真正的缺陷+影响用户使用的非缺陷问题；
  - 用户数=授权数*月份；
- 减少分子
  - 改进开发过程，降低产品缺陷；
  - 改善产品易用性、文档编写、用户教育、售后支持来降低非面向缺陷的问题；
- 增大分母
  - 增大产品销售量；
用户满意度

过程中质量度量

常见的过程中度量方法
- 机器测试阶段的缺陷密度；
  机器测试阶段的缺陷率通常与软件产品在使用中的缺陷率成正比；缺陷率越低，过程质量越高；
- 机器测试阶段的缺陷到达模式
  一段时间内，缺陷率随时间变化的趋势；
  常见的度量：
  (1). 用时间间隔测量的缺陷到达模式
  (2). 有效缺陷的到达模式
  (3). 缺陷随时间累积的模式
- 基于阶段的缺陷移除模式
  反映整个开发过程中的全面缺陷移除能力；
- 缺陷移除效率
  用于衡量测试是否充分，包括整体的缺陷移除效率和阶段移除效率；
  (1). 阶段缺陷移除效率=本阶段发现的属于本阶段功能的缺陷总数/产品中潜在的本阶段缺陷总数；
  (2). 产品中潜在的本阶段缺陷总数=本阶段已发现缺陷数+以后发现的缺陷数；
  (3). 整体缺陷移除效率≈发布前发现的缺陷数/缺陷总数；

产品维护中质量度量

常见的维护中度量方法
- 机器修复积压和积压管理指标
  (1). 修复积压
  缺陷到达率；
  用户报告问题的修复率；
  (2). 积压管理指标(BMI) $BMI=\frac{当月已解决的问题数}{当月报告的问题数}*100%$ ${\color{Red} BMI>100}$ ，表明积压减少，软件产品可控并趋于稳定；
  $BMI\le 100$ ，表明积压增加，软件产品不稳定；
- 修复响应时间和修复响应
  (1). 修复响应时间
  所有问题从发现到解决问题的平均时间；
  修复响应时间越短，用户满意度越高；
  (2). 修复响应主要考虑用户的期望
  协商同意的修复时间；
  完成对用户承诺的能力；
- 拖欠修复百分比 $拖欠修复百分比=\frac{修复时间超时的问题数}{一段时间内修复的问题总数}*100%$ 针对相同严重等级的问题进行统计；
  该指标主要反映完成对用户承诺的能力；
- 修复质量
  (1). 有缺陷的修复百分比=所有修复中有缺陷的修复数/一定时间间隔内修复的缺陷总数
  (2). 有缺陷修复的潜伏时间=有缺陷的修复发现的时刻-缺陷修复完成的时刻；

软件质量度量工具

检查表
收集资料，规范过程
帕累托图
二八定理：寻找少数的关键因素
直方图
观察数据分布，判断软件的总体质量分布情况
散点图
表示模块之间关系，预测缺陷级别
游程图
观察一段时间内参数（模块）的性能
控制图
判断软件开发过程是否可控
因果图
整理和分析质量问题与其影响因素之间的关系

软件缺陷

软件缺陷产生的原因

软件评审

软件评审分类

技术评审
对产品以及各阶段输出内容进行技术性评估，重点在技术实现上面；
文档评审
对软件过程中所存在的各类文档格式及内容等进行评审；
包含：软件需求规格说明书、功能设计规格说明书、测试计划、测试用例；
管理评审
流程评审

软件审查方法

评审方法：临时评审、轮查、走查、互为复审、审查；

需求评审标准

正确性
完备性
易理解性
一致性
可行性
易修改性

软件评审方法

如何进行需求评审：

分层评审法：先整体后细节
分类评审法：从业务需求、功能需求、非功能需求、用户操作性需求评审；
分阶段评审方法：需求形成过程中，最好采用分阶段评审方法进行多次评审；

设计审查

概述
(1). 体系结构设计
(2). 详细设计
软件设计评审标准
(1). 质量属性
- 可维护性
- 可移植性
- 可测试性
- 健壮性
界面设计的评审
- 易懂性、易用性
- 一致性和规范性
- 美观与协调性
- 遵守惯例和通用法则
系统部署的评审
- 着重是否服从和遵守部署设计的技术规范
- 逻辑设计的审查
- 物理设计的审查
- 可用性设计的审查
- 可伸缩型设计的验证
- 安全性设计的验证