第一章 软件测试标准及模型
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
展现层 业务服务逻辑层
基于服务的 Supertester自动化 测试工具
数据层
基于SQL的数据库 自动化测试工具
数据层:通过运行SQL脚本直接验证SQL语句 的功能和性能,并可进行模拟并发运行SQL 测试脚本,验证SQL执行效率和数据库性能, 为基础的数据库编程优化提供支持
改善5:灰度发布
Techexcel
RUP测试过程
RUP测试过程
敏捷测试
自动和手 动
面向业务 功能测试 探索性测试 α、 β、 λ测试 用户验收测试 性能和压力测试 安全性测试 非功能性测试 面向技术
手动
支 持 团 队
用户故事测试
单元测试 组件测试
评 价 产 品
自动
工具
传统测试与敏捷测试
敏捷方法体系:XP
沟通 简单 反馈 勇气 尊重
保密性 完整性
抗抵赖性 可追踪性 真实性
模块性 共存性
互操作性
可重用性
可分析性 可更改性 可测试性
适应性 可安装性 可替换性
CMMI与TMMI
CMMI与TMMI
目录 1:质量标准
2:测试模型
瀑布式开发与V模型
Rup测试过程
敏捷测试模型 测试驱动开发
3:提升软件的工程能力
软件工程与测试模型
、需求分析、软件设计、程序
编写、软件测试、运行维护。 规定活动自上而下、相互衔接 的固定次序,逐级下落。
V模型
V模型是最广为人知的测试模型 由Paul Rook在20世纪80年
代后期提出的,旨在改进软件开
发的效率和效果。 从左到右,描述了基本的开发过 程和测试行为。 非常明确地标明了测试过程中存 在的不同级别,描述了这些测试 阶段和开发过程期间各阶段的对 应关系
传统软件项目面临的挑战:新需求/运维
紧急的需求
变化的文档
没时间测试 质量要求高
……
传统软件工程面临的挑战
我们的困惑与期望? 无法实现高质量交付 无法实现快速交付
传统软件工程面临的挑战:部分实践的改善
开发人员
波次 协同 开发
自动
1.9days 0.2days
测试人员
2.3days
环境配置& 应用配置
版本控制
环境配置& 应用配置
开发人员 查看代码度量数据 和测试失败原因
编译 提交测试 组装打包 代码分析
测试人员 自服务部署
测试环境
UAT环境/回归环境 配置环境 部署二进制包 冒烟测试 性能测试环境 配置环境 部署二进制包 冒烟测试 运行容量测试 生产环境 配置环境 部署二进制包 冒烟测试
测试驱动开发
Personal Software Process的Development
Analysis
Design
Code
Build
Test
Test-Driven Design and Development
Analysis
Design
Code Unit Test
Code
Build
Run Test
不同的开发模式适配不同的测试模型和测试过程。
开 发 流 产品平台 水 技术平台 线
规划
需求
设计
实现
测试
部署
测试 需求
测试设计
测 试 测试执行 执 行
瀑布模型
瀑布模型的核心思想是按工序 将问题化简,将功能的实现与 设计分开,采用结构化的分析 与设计方法将逻辑实现与物理 实现分开。 软件生命周期划分为制定计划
统一工作区
产品测试
1
统一受控区
产品发布
产品开发
统一 开发环境
产品测试
产品发布
2 3
3
2 3 制4 品 仓3 库4
统一 测试环境 省份1 测试环境
省份1 准生产环境
省份1 受控区
省份2 受控区
省份2 测试环境
省份2准生 产环境
5
省份1 发布区 省份2 发布区
5
省份1 生产环境 省份2 生产环境
5
5
工程项目版本发布策略
D省
C省
下发 差异 下发 分析 下发
C省上线
波次在项目中的实施
B省
B省上线
A省 产品线
需求 基线 需求 分析 统一 设计 统一 发布
每波次开发
需求 基线
波次 N+1
改善2:版本管理
代码入库受控 主干发布 本地验证与主干验证 紧急需求/紧急bug分支发布
环境与版本的对应
产品开发
目录 1:质量标准
2:测试模型
瀑布式开发与V模型
Rup测试过程
敏捷测试模型 测试驱动开发
3:提升软件的工程能力
传统软件项目面临的挑战:全局视角
迫于压力被打回,所有人 unhappy 甚至多次评审, 结果仍是四不像
外部压力:市场;竞 争对手;高层领导
PMM
Plan
1个月 2个月
评审点
很好地处理测试与开发的交接过程 (交接的过程是一个时间段,而不 是一个点) 左边描述的是针对单独程序片段所 进行的相互分离的编码和测试,此 后将进行频繁的交接,通过集成最 终合成为可执行的程序,然后再对 这些可执行程序进行测试。 己通过集成测试的成品可以进行封 装并提交给用户,也可以作为更大 规模和范围内集成的一部分。多根 并行的曲线表示变更可以在各个部 分发生。 X模型还定位了探索性测试,这是 不进行事先计划的特殊类型的测试 ,给有经验的测试人员在测试计划 之外发现更多的软件缺陷。
自动
0.4days
自动化 回归测试
自动
0.2days
自动化 发布上线
模块集成 接口联调
波次
困惑和期望
发布到 制品仓库
功能开发或 缺陷修复
Total:7.2days
自动 构建与测试
快速交付? 高质量交付?
制品仓库 测试环境
执行 业务测试
开发环境/CI服务器
回归环境
生产环境
与场景2比较:从编码开始到交付11.2天/模块,平均故障下降32%;
W模型
测试伴随整个软件开发周期,而 且测试的对象不仅仅是程序,需 求、设计等同样要测试,测试与 开发是同步进行的。 W模型有利于尽早地全面的发现 问题。 测试和开发活动也保持着一种线 性的前后关系,上一阶段完全结 束,才可正式开始下一个阶段工 作。这样就无法很好的支持迭代 开发。
X模型
测试过程转型与优化
强化自动化测试
系统应用
系统层次结构 展现层 基于界面操作自动 化测试工具
三个层次的自动化测试
界面层:实现界面操作过程,业务受理过程 的正确性验证。 逻辑层:对服务进行单个项或服务流程测试, 这类测试避免了界面限制的局限性,能够充 分验证业务服务以及服务流程的正确性。并 且由于服务具有结构化的特点,易于实现测 试的自动化,同步支持基于服务的性能测试。
RQ
Design
1个月 2个月+
评审点
DE
Code
成品来自百度文库
TE
每个版本进行回归测试,TE压 力大
…
3个月开发需求……
高Cost1
全部设计图
高Cost2 高Cost3
传统软件项目面临的挑战:开发测试阶段
问题1:测试是唯一质量控制环节,后置/被动。测试时间总是被压缩 问题2:测试、联调与发布的时间消耗过长,交付周期漫长
开发人员
5.1days
功能开发或 缺陷修复
0.3days
(新需求) 申请发布
发布人员
0.4days
编译构建到 测试环境
测试人员
5.2days
执行 业务测试
发布人员
0.4days
执行 发布上线
4.2days
模块集成 接口联调
(项目) 一次性发布
开发环境 编译环境/测试环境 生产环境
问题3:开发与设计脱节,经常推倒重来 问题4:小的集成bug影响全局
华为
站立会议,现场客户
代码共享
测试先行 Test Frist Design (TDD)
编码标准
结队编程
验收测试 •功能性 •非功能性
Pair Programming Refactoring 简单设计
Simple design
开发
重构
持续集成CI
40H
Planning Game
小步快跑 保持随时随地都有一个可用的软件 Small Rlease
改善1:协同的波次开发
传 所有功能开发完毕 漫长的BUG修复 统 方 总集成 式
波 功能增长 主干 ( 少 ) 次 Bug修复 方 潜在集成 潜在集成 式 …
BUG修复
波次在新需求/版本升级中的实施
总集成
E省
下发 差异 分析 协同 计划 产品A部分 需求1 产品B部分 A省上线 时间 统一交付 差异 分析 增量 设计 下发 下一波次 开发
集成测试
基 线 部 署
验证测试
新需求/维护测试
功能/发 布环境:
Bug修复:实时 发布 波次新增功能: 集中波次前发布
模拟测试和并运行 期间为一天发布两 次
割接前封版后及割接当 运维阶段为每周固 天,执行紧急发布过程, 定时间发布 增加技术总负责人与项 目、用户审核
……
第一波集成 第二波集成 工单补录 并运行 封版 割接
软件测试标准及模型
刘振田 2014-05 cowardliu@126.com
测试模型——总体框架
Bvt测试 冒烟测试
测试模型——工具集成框架(自动化)
自动化测试工具Qtp/Selenium
生产心跳测试
目录 1:质量标准
2:测试模型
瀑布式开发与V模型
Rup测试过程
敏捷测试模型 测试驱动开发
开发环境
配置环境 部署二进制包 冒烟测试 自动验证测试
运维 执行一键式部署
报告 二进制包 元数据
报告 二进制包 元数据
二进制包
报告 元数据
制品仓库
持续集成与持续交付
单元测试
静态检查
代码覆盖率
持续集成与持续交付
交付制品统一管理 发布部署过程IT流程支撑
1
制品仓库 发布 申请
状态 跟踪
3
2
改善4:测试过程转型与自动化测试
3:提升软件的工程能力
ISO/IEC 9126-1-2001
外部和内部质量
功能性
可靠性
易用性
效率
维护性
可移植性
适合性 准确性 互操作性 保密安全性 功能性的 依从性
成熟性 容错性 易恢复性
易理解性 易学性 易操作性 吸引性
时间特性 资源利用性
易分析性 易改变性 稳定性 易测试性
适应性 易安装性 共存性 易替换性 可移植性 的依从性
联调 /UAT环 境: 性能/培训 环境:
基线部署
根据测试轮 次和版本进 行集中部署
模拟测试和 并运行期间 为一天发布 两次
上线后联调 环境废弃使 用
基线部署
根据性能测 试轮次集中 发布
改善3:持续集成与持续交付
持续集成与持续交付
5套环境建设与管理
源代码
代码、半成品、成品在环境之间平滑生成与管理
可靠性的 依从性
易用性的 依从性
效率 依从性
维护性的 依从性
ISO/IEC 25010-2011
外部和内部质量
功能适用性
可靠性
性能效率
操控性
安全性
兼容性
维护性
可移植性
易判有用 成熟性 完整性 适合性 正确性 可用性 容错性 易恢复性 时间行为 资源利用 容量 易学习 易操作 用户错误保护 诱人用户界面 易掌握