023信息系统综合测试与管理

信息系统综合测试与管理

测试基础

软件测试模型

测试模型，是测试和测试对象的基本特征、基本关系的抽象

V模型

20世界80年代后期，Paul Rook提出，是软件开发瀑布模型的变种，反映测试活动与分析和设计的关系

V模型价值在于，明确地标明测试过程中存在不同级别，并清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XEOJd5r8-1612749715716)(D:\考试\高级项目管理\zk整理\pic\14.bmp)]

优点：

• 将复杂的测试工作按阶段划分为各小阶段来实现
• 从多角度测试系统找出更多的缺陷

缺点：

• 软件测试容易误导为软件开发的最后一个阶段
• 需求、设计阶段产生的问题不能很早发现
• 质量控制和测试效率无高效发挥

W模型

W模型由Evolutif公司提出，增加软件各开发阶段中同步进行的验证和确认测试活动

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Eoi4tMfI-1612749715720)(D:\考试\高级项目管理\zk整理\pic\15.bmp)]

优点：

• 测试和开发同步进行，有利尽早发现问题
• 增加非程序角度测试系统的思想
• 测试准备及设计工作提前，提高测试质量及效率

缺点：

• 把软件开发视为需求、设计、编码等一系列串行活动
• 开发和测试保持一种线性的前后关系
• 无法支持迭代、自发性以及变更调整

H模型

将测试活动完全独立出来，形成一个完全独立的流程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hrZMkv7h-1612749715721)(D:\考试\高级项目管理\zk整理\pic\16.bmp)]

优点：

• 独立流程，利用研究更深的测试技术
• 测试技术重复利用
• 高效调整测试人员
• 缺陷修复时不受项目组内部人员限制

缺点：

• 独立的测试组对系统认识不够深入
• 影响测试质量及测试效率

X模型

X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合成为可执行的程序

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BKgiBfBd-1612749715723)(D:\考试\高级项目管理\zk整理\pic\17.bmp)]

优点：

• 强调单元测试及集成测试的重要性
• 引入探索性测试使测试模型与现实更接近
• 缺陷修复时不受项目组内部人员限制

缺点：

• 只强调测试过程中的部分内容
• 没有对需求测试、验收测试等内容进行说明

前置测试模型

Robin F.Goldsmith等人提出，将测试和开发紧密结合

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wEf5O2f0-1612749715725)(D:\考试\高级项目管理\zk整理\pic\18.bmp)]

软件测试类型

按照开发阶段划分

• 单元测试
  • 单元功能
  • 单元接口
  • 单元局部数据结构
  • 单元中重要的执行路径
  • 单元各类错误处理路径
  • 单元边界条件
• 集成测试
  • 模块间接口
  • 模块间数据传递
  • 全局数据结构
• 系统测试
  • 用户角度功能性验证
  • 非功能性验证
• 验收测试
  • 整个系统测试与评审
  • 根据验收通过准则分析测试结果
  • 决定是否接收系统及测试评价

按照测试实施组织划分

• 开发方测试
• 用户测试
• 第三方测试

按照测试技术划分

• 黑盒测试
• 白盒测试
• 灰盒测试

按照测试执行方式划分

• 静态测试
• 动态测试

按照测试对象类型划分

• 功能测试
• 界面测试
• 流程测试
• 接口测试
• 安装测试
• 文档测试
• 源代码测试
• 数据库测试
• 网络测试
• 性能测试
  • 负载测试
  • 压力测试
  • 稳定性测试

按照质量属性划分

• 容错性测试
• 兼容性测试
• 安全性测试
• 可靠性测试
• 可用性测试
• 维护性测试
• 可移植性测试
• 易用性测试

按照测试地域划分

• 本地化测试
• 国际化测试

软件测试技术

黑盒测试法

• 通过测试
• 失败测试

优点：

• 简单
• 与实现无关
• 用户角度
• 基于文档
• 自动化测试方便

缺点：

• 覆盖率低
• 自动化复用性低

主要方法：

• 测试区域确定法
  • 等价类划分
  • 边界值分析法
• 组合覆盖法
  • 全组合覆盖法
  • 成对组合覆盖法
  • 正交实验设计法
  • 数据覆盖法
• 逻辑推断法
  • 因果图法
  • 判定表法
  • 大纲法
• 业务路径覆盖法
  • 场景分析
  • 功能图
• 黑盒测试方法综述
  • 首先进行等价类划分
  • 必须使用边界值分析方法
  • 可以用错误推测法追加测试用例
  • 检查逻辑覆盖程度
  • 有输入条件组合，可以选用因果图和判定表
  • 参数配置类，要用正交试验法
  • 业务清晰，可以场景法

白盒测试法

概念

白盒测试允许测试人员利用程序内部逻辑结构及有关信息，设计或选用测试用例，对程序所有逻辑路径进行测试

白盒测试遵循原则

• 保证一个模块所有独立路径至少被测试一次
• 所有逻辑值均需测试真和假两张情况
• 检查程序的内部数据结构，保证结构有效性
• 在上下边界及可操作范围内运行所有循环

白盒测试方法

• 静态白盒测试
  • 代码检查法
  • 静态结构分析法
  • 静态质量度量法
• 动态白盒测试
  • 覆盖测试
  • 控制结构测试
• 其他白盒测试方法
  • 程序插桩
  • 程序变异测试

信息系统测试管理

测试管理概述

测试管理是为了实现测试工作预期目标，以测试人员为中心，对测试生命周期及其所涉及的相应资源进行有效的计划、组织、领导和控制的协调活动

测试管理的主要因素包括

• 测试策略的制定
• 测试项目进度跟进
• 项目风险的评估
• 测试文档的评审
• 测试内部、外部的协调沟通
• 测试人员的培养

测试管理内容

• 测试目标明确
• 测试团队搭建和测试人员管理
• 测试实施过程监控
• 测试风险的评估和风险的应对策略
• 测试外部的沟通协调
• 测试资产、产品的统一管理
• 测试规范的制定
• 测试绩效考核的制定与考评

测试监控管理

测试监控内容

• 测试用例执行的进度
• 缺陷的存活时间
• 缺陷的趋势分析
• 缺陷分布密度
• 缺陷修改质量

配置管理

• 选取合适的配置管理工具
• 整理配置项，明确管理流程
• 整体配置管理
• 增加发布前验收测试环节
• 采用并行开发方式
• 明确角色与职责

测试风险管理

风险主要有以下方面

• 需求风险
• 测试用例风险
• 缺陷风险
• 代码质量风险
• 测试环境风险
• 测试技术风险
• 回归测试风险
• 协调沟通风险
• 其他不可预计风险

测试人员绩效考核

• 工作内容考核
  • 参与软件开发过程的工作内容考核
  • 参与测试文档的准备工作
  • 执行测试的工作
  • 测试结果缺陷残留
  • 测试人员的沟通能力考核
• 工作效率与工作质量考核
  • 测试设计中工作效率相关指标
    • 文档产出率
    • 用例产出率
  • 测试设计中工作质量相关指标
    • 需求覆盖率
    • 文档质量
    • 文档有效率
    • 用例有效率
    • 评审问题数
  • 测试执行中工作效率相关指标
    • 执行效率
    • 进度偏离度
    • 缺陷发现率
  • 测试执行中工作质量相关指标
    • 缺陷数
    • 有效缺陷数/率
    • 严重缺陷率
    • 模块缺陷率
    • 遗漏缺陷率
    • Bug发现时间点，Bug曲线的收敛性
    • 缺陷定位和可读性
• 对自动化测试人员效率的度量
• 对测试项目负责人效率的度量
• 测试管理的度量
  • 计划质量
  • 成本质量
• 考核注意事项