Transcript 自动化测试体系 - 51Testing软件测试网

自动化测试
1
测试现状及问题
•测试筹备
•测试实施
•系统内部测试
现象：接口测试，测试
数据种类繁多，具有大
量的测试案例
问题：关注关键数据，
执行少量的、关键的测试案例，
测试不足
现象：大量集成测试案
例，代码、界面不稳定，
版本更新极为频繁
问题：测试人员少，无法承受重复
的繁重工作量，执行少量的、
关键的测试案例，测试不足
•系统连接测试(LT)
•系统集成测试(SIT)
•用户接受测试(UAT)
•测试审核
问题：测试人员少，无法承受重复
现象：大量业务测试案
的繁重工作量，执行少量的、
例，代码、界面不稳定，
关键的测试案例，测试不足
版本更新比较频繁
•运营维护测试
现象：版本定期发布，
大量回归测试案例，代
码、界面稳定
问题：大量回归测试案例，无
足够手工回归测试人员，测试不足
2
解决思路初探
自动化测试的标准应用
测试阶段的
功能测试
– 背景：在高覆盖率要求的前提下，每个功能的测试案例量很大，并且由于
测试阶段中不断的代码修改、集成，重复测试的次数很多
– 应用：自动化功能测试，包括接口功能测试、界面安全性测试、业务功能
测试，提高测试的覆盖率，降低测试的工作强度
– 限制：由于测试阶段中的代码和界面的频繁变更，自动化的覆盖率应以少
量覆盖、关键覆盖为原则
测试阶段的
业务流测试
– 背景：在集成测试和用户接受测试阶段中，业务流程的测试是主要工作内
容。但是，每个业务流程由于操作步骤多，导致执行时间长，重复的执行
增加了测试的工作量和加重了工作负担
– 应用：自动化业务流测试，提高测试的覆盖率，降低工作强度
– 限制：同样由于测试阶段中的代码和界面的频繁变更，自动化的覆盖率应
以少量覆盖、关键覆盖为原则
运营维护阶段
的回归测试
– 背景：在运营维护阶段，每次新版本发布前，应进行充分的回归测试，确
保部分代码的变更不会影响大部分未变更的代码正确性。但是，通常情况
下，这个阶段中不会固定拥有大量的测试人员来实施手工回归测试工作
– 应用：自动化功能测试，自动化业务流测试
– 限制：独立的测试环境引起资源争用或者巨大投入，在资源受限的情况下，
应以最小化占用资源的方式进行
自动化测试的实际应用
•测试筹备
•测试实施
•系统内部测试
•系统连接测试(LT)
•系统集成测试(SIT)
•用户接受测试(UAT)
•测试审核
自动化接口功能测试：
测试数据自动生成，依据报文规范自动生成测
试脚本，自动执行接口功能测试，提高接口测试的
覆盖率，促进开发质量
核心业务集自动化测试：
少量自动化测试工程师，自动化少量核心业务，
版本更新时快速执行，保障核心模块的质量，提高
测试效率
核心业务集自动化测试：
少量自动化测试工程师，自动化少量核心业务，
版本更新时快速执行，保障核心模块的质量，提高
测试效率
•运营维护测试
自动化功能测试、自动化业务流测试：
自动化测试小组，计算可行自动化率，建设自
动化回归测试技术平台，长期运行自动化测试，保
障系统运行质量
3
实施难度与风险
标准实施角色
测试管理
自动化测试管理
测试管理
机构
–
–
–
–
–
–
–
手工测试的传承
业务测试
机构
– 提供业务测试需求
– 提供业务测试案例，包括操作步骤、业务数据和验证方法
自动化测试实施
自动化测试
机构
–
–
–
–
自动化测试支持
测试环境
– 自动化测试环境的基础设施支持
自动化测试支持
项目组
– 自动化测试环境的应用环境支持
– 自动化测试组件开发的技术支持
建设自动化测试体系
规划自动化测试技术平台
根据软件项目测试需要确定项目级自动化测试策略
自动化测试工作的计划、组织和协调
自动化测试环境的计划、组织和协调
自动化测试缺陷与手工测试缺陷的关联管理
自动化测试结果的分析、评估与审定
设计、实现自动化测试技术平台
自动化测试可行性分析；确定自动化率目标和自动化测试需求
设计、实现可执行的自动化测试业务测试过程和组件
设计、实现自动化执行机制；执行自动化测试
实施难度
自动化测试设计
1
业务测试
– 当前业务测试规范度尚未完善
– 业务测试案例尚未达到符合标准的程度
– 为自动化测试编制符合要求的测试案例带来较大的工作量
自动化测试
–
–
–
–
自动化测试角色不了解信息应用系统的业务
若无详细的测试需求，无法快速分析、确定自动化测试需求
若无详细的测试案例，无法快速设计自动化测试案例
学习业务的工作量较大
测试环境
项目组
– 自动化测试的组件开发需要项目组提供软件界面处理逻辑的详细
文档，或者由项目组的开发人员提供技术支持，导致工作量较大
实施难度
自动化测试实现
2
自动化测试
业务测试
测试环境
项目组
– 自动化测试的脚本开发与应用软件的界面、代码变更息息相关
– 自动化测试的脚本量越大，维护工作量就越大
– 若实施准备不足或风险预估不完整，甚至导致实现失败
实施难度
自动化测试执行
3
自动化测试
– 自动化测试可能遇到多项目并行的情况
– 给自动化测试的管理带来较大的难度要求
业务测试
测试环境
项目组
– 自动化测试在运营维护期的执行过程中需要对测试环境独占
– 若测试环境资源有限，会造成无测试环境资源或者测试环境资源
严重争用的情况
降低业务测试不规范带来的各种工作量
自动化测试
手工测试
工
作
重
点
=
提
高
测
试
需
求
和
测
试
案
例
的
规
范
度
手工测试规范度不足
改进
最低标准
测试需求
测试案例
发展
手工测试规范度满足
最高标准
测试需求
测试案例
工
作
问题：
重
1）不足以设计自动化测试
点
=
解决：
自
1）依据最低标准，基本设计
2）向业务测试角色学习、补充 动
化
3）提高业务认识，补充设计
测
试
设
积累
提高
计
、
实
现
依据最高标准，直接设计 与
执
行
自动化测试技术平台
自动化测试技术平台
测试管理
测试执行
• 项目管理子系统
• 测试执行组织调度子系统
• 用户管理子系统
• 测试运行计划设计子系统
• 测试需求管理子系统
• 测试执行子系统
• 业务组件管理子系统
• 测试执行监控子系统
• 业务测试过程管理子系统
• BC、BP开发子系统
• 测试数据管理子系统
测试分析
• 测试分析子系统
自动化测试技术平台的建设目标
平台目标
1
3
设计工作可视化操作
测试数据集中管理
测试执行自动控制
2
测试结果综合分析
自动化测试
技术平台
4
问题解决
多项目并行
1
自动化测试技术平台
《
自
动
化
测
试
管
理
办
法
》
《
自
动
化
测
试
管
理
规
程
》
项目管理子系统
《
自
动
化
测
试
规
范
》
测自项
试动目
工化
作
测自项
试动目
工化
作
用户管理子系统
测自项
试动目
工化
作
测自项
试动目
工化
作
内容大纲
一、
技术发展趋势
二、
ROI分析
三、
流程、案例示例
四、
组织管理
五、
自动化测试体系
六、
应用系统架构
七、
集成架构
一、 技术发展趋势－1
没有测试
手工测试
•
•
•
•
•
时间紧
可靠性低
人力缺乏
无法保证一致性
无法重复
自动测试
快速
可重复
高覆盖率
高可靠性
重用性强
1、 将乏味且人工容易出错的工作进行自动化，实现功能的回归测试，在应用程序
修改之后，运行自动化测试脚本，快速完成回归测试
2、将重复的测试工作自动化完成，为其他方法的测试赢得更多时间；
3、降低测试成本，提高测试复用度和测试效率，占用少量的业务测试人力资源
一、 技术发展趋势－2
录制回放
脚本技术
数据驱动
关键字驱动
业务驱动
可维护性
低
中
中
中
高
可靠性
低
高
高
高
高
效率
低
中
中
中
高
可复用性
低
中
中
高
高
健壮性
低
高
高
高
高
可移植性
低
低
中
中
中
易用性
高
低
中
中
高
内容大纲
一、
技术发展趋势
二、
ROI分析
三、
流程、案例示例
四、
组织管理
五、
自动化测试体系
六、
应用系统架构
七、
集成架构
测试自动化基本实践方法
Procedure for
X Risk
过程
根据特定测试风险等级来选择合适的测试
过程.
方法
通过以测试过程的最优组合和资源、进度、风险的
约束来多次运行自动化测试次数，来达到最小化工
作量的目标
High
复杂度
Medium
复杂度
Low
复杂度
High Risk
Medium Risk
Low Risk
基于风险和复杂度评估达到测试目标的最佳性价比
自动化测试工作任务的优先级
优先级策略

Automation ROI Matrix
测试范围

# of Test Cycles for
Beginning of Return on
Automation
由风险驱动测试
( 例如：高风险的项先被测试)

复杂度
Hig
h
自动化的优先顺序:

对于能尽快（最少运行次数）
达到投资回报平衡点

高风险的测试案例优先

低复杂度的测试案例优先
Risk
Low
1
4
3
5
6
8
High
5.0
5.9
Medium
6.6
7.3
8.1
7.3
8.1
#
2
7
5.5
9
- Priority # / Order
Low

Medi
um
5.0
Assuming test cases for all risks and
complexities are in-scope for each test
cycle.
自动化测试目标
初级阶段目标

只适用于功能测试阶段，因为
一般会：

给定预算，进度，资源

给定平均或期望的测试运行次
数

根据业务流程的不同（复杂度
和风险）最大化自动化率（只
能达到有限值）
高级阶段目标

可以适用于回归测试：

自动化率可以逐步提高
增加自动化测试的次数
减少测试运行时的缺陷
通过灵活的合理的自动化测试目标最大化时间和资源的
利用率和价值
二、 ROI分析－1
Automation ROI Matrix
# of Test Cycles for Beginning of Return on
Automation
复杂度
High
Medium
Low
5.9
5.5
Risk
High
5.0
1
Medium
6.6
4
7.3
5
Low
5.0
#

8.1
6
7.3
2
3
8
8.1
7
9
- Priority # / Order
Assuming test cases for all risks and
complexities are in-scope for each test
cycle.
二、 ROI分析－2
自动化测试固定成
本的例子：
自动化测试可变成
本的例子：
手工测试共
同要素的例子：
 硬件
 应用软件的许可证
 应用软件的技术支持
 自动化测试环境的设
计和搭建
 自动化测试环境的维
护
 脚本开发工具软件
 脚本开发工具的许可
证
 测试工具的培训
 测试工具的引入和启
动
 自动化测试用例的设
计
 自动化测试用力的实
现
 自动化测试的维护
 自动化测试用例的执
行
 自动化测试结果的分
析
 缺陷的报告
 测试结果的报告
 测试执行数据的保存
 自动执行的测试





被测软件分析
测试规划
基础测试设计
缺陷报告
测试结果报告
内容大纲
一、
技术发展趋势
二、
ROI分析
三、
流程、案例示例
四、
组织管理
五、
自动化测试体系
六、
应用系统架构
七、
集成架构
三、 流程、案例示例－1
三、 流程、案例示例－2
手工测试流程
测试经理
业务测试人员
软件工程师
自动化测试工程师
环境支持
测试分析
报告
测试计划
测试方案
交易分支
案例设计
业务测试
案例设计
测试场景
设计
手工
执行
测试执行
分析
修复
缺陷
交易分支
模板
交易分支案例
自动化构建
业务流案例
自动化构建
测试执行
场景构建
被测系统
环境构建
自动化
执行
测试环境
管理
测试执行
分析
三、 流程、案例示例－3
交易分支
• 交易分支案例：
– 给交易分支增加一组数据，成为交易分支案例——为具体
的测试案例所使用
• 交易分支的视图：
– 交易分支输入文档（设计）
– 交易分支脚本（自动化测试）
• 交易分支对应：
– 交易
– 交易的执行分支覆盖
三、 流程、案例示例－6
业务测试案例
• 业务测试案例
– 具有输入、输出参数
– 每个步骤都由交易分支案例组成，可以进行数据传
递，如：传递帐号。
– 每个交易分支案例，都具有执行中使用的柜员信息
– 具有校验功能
– 由业务案例设计人员设计
内容大纲
一、
技术发展趋势
二、
ROI分析
三、
流程、案例示例
四、
组织管理
五、
自动化测试体系
六、
应用系统架构
七、
集成架构
四、 组织管理－1
测试管理机构
其它机构
机构领导
开发管理部门
环境实施管理部门
自动化测试项目管理组
其它岗位
其它岗位
业务测试专家
自动化测试管理岗
自动化测试实施组
测试经理
被测系统项目经理
>
自动化测试分析师
自动化测试工程师
>
被测系统开发工程师
被测系统测试工程师
设备和基础设施组
四、 组织管理－2
自动化测试绩效考核体系
测试管理机构
机构领导
其它岗位
其它岗位
确定自动化测试
发展战略
业务专家
确定达到战略所需
要的目标、任务
组织管理层次绩
效考核规程
自动化测试管理岗
测试管理机构
自动化测试项目管理组
业务专家
自动化测试管理岗
测试经理
该层次
KPI
被测系统项目经理
+
日常管理目标、
任务
项目管理目标、
任务
项目(群)管理层
次绩效考核规程
项目实施目标、
任务
项目实施层次绩
效考核规程
自动化测试项目管理组
自动化测试实施组
测试经理
自动化测试分析师
自动化测试工程师
被测系统项目经理
被测系统开发工程师
被测系统测试工程师
设备和基础设施组
自动化测试实施组
该层次
KPI
+
内容大纲
一、
技术发展趋势
二、
ROI分析
三、
流程、案例示例
四、
组织管理
五、
自动化测试体系
六、
应用系统架构
七、
集成架构
五、 自动化测试体系－1
测试组织
测试管理目标
测试管理体系
1
(与自动化测试相关的
部分)
组织过程资产
项目级自动化测试实施
流程
2
自动化测试要求
手工测试需求
被测系统
项目过程资产
需求
测试结果
自动化测试结果
项目级整体测试管理流
程
（与自动化测试相关部
分）
3
工作产品
度量需要
配置状态报告
审计报告
评审报告
度量分析报告
支持过程
4
（评审流程，配置管
理、变更管理、需求管
理等，需定义接口）
五、 自动化测试体系－2
测试管理体系
1
(与自动化测试相关的部分)
项目级自动化测试实施流程
2
项目级整体测试管理流程
3
(与自动化测试相关的部分)
1.1自动化测试管理办法
1.2自动化测试组织
3.1自动化测试需求管理
1.3自动化测试环境（组织级环境规划）
2.1自动化测试小组组建
1.4自动化测试资源（工具、人员）
2.2自动化测试工作策略确定
1.5自动化测试度量
2.3自动化测试需求分析
1.6自动化测试的项目的选取
2.4自动化测试计划确定
3.4(自动化）测试环境（项目级环境
应用）
2.5自动测试过程设计
3.5自动化测试资源使用
2.6自动测试业务组件设计
3.6自动化测试度量
4.1评审
2.7自动化测试实现
3.7自动化测试监控
4.2配置管理
2.8自动化测试运行
3.8自动化测试验收
4.3变更管理
2.9自动化测试分析
3.9自动化测试项目管理
支持过程
4
4.4需求管理
3.2自动化测试案例管理
3.3自动化测试缺陷管理
内容大纲
一、
技术发展趋势
二、
ROI分析
三、
流程、案例示例
四、
组织管理
五、
自动化测试体系
六、
应用系统架构
七、
集成架构
六、 应用系统架构
1.1测试项目管理子系统
1.7测试数据管理子系统
1.2用户管理子系统
1、业务组件、业
务测试过程
管理平台
1.6 BC、BP开发子系统
1.3测试需求管理子系统
1.5业务测试过程管理子系统
2.1测试执行组织调度子系统
1.4业务组件管理子系统
2、自动化测试执行平台
2.2测试运行计划设计子系统
2.4测试执行监控子系统
3、测试分析平台
2.3测试执行子系统
内容大纲
一、
技术发展趋势
二、
ROI分析
三、
流程、案例示例
四、
组织管理
五、
自动化测试体系
六、
应用系统架构
七、
集成架构
七、 集成架构
测试执行 测试管理
新门户
测试分析 测试开发
门户集成
工作流 对系统中的业务流程进行集成
管理 和管理，实现更复杂的功能。
流程集成
应用系 与系统进行连接，调用其的功
统连接 能。
应用集成
测试设计 测试实现 测试执行 测试分析
新功能
消息中 在不同的系统之间传递消息和
间件 数据。
数据集成
SQL SVR
ORACLE
翻译和 对传递的消息和数据进行翻
转换 译、格式转换、格式化等。
新数据库
为什么自动化测试“看上去很美”
呢？
大量测试
数据如何
维护？
大量脚本
如何维护？
变更
如何初始
化测试环
境？
自动化测试
C
R
运
行
测试执行管理工具
测试执行工具
业务流程设计
初始化运行环
境
营业自动化测试
用例向导
执行引擎
帐务自动化测试
用例设计
结果分析
计费自动化测试
用例参数管理
用例数据管理
基础测试管理平台
测试数据库
测试案例库
系统内部关系
测
试
需
求
阶
段
走需求变更管理流
程的需求
不走需求变更管理
流程的需求
同步测试需求
创建测试需求
平台后台服务器
Telelogic接口
细化测试需求
在基础案例库中查
找是否存在案例
基础案例库
Y
测
试
设
计
阶
段
导入测试案例
是否存在？
前台自动
N
案例向导
案例类型？
后台自动
自动测试数据管理器
手工
修改测试案例
设计前台自动类
测试案例
设计手工类
测试案例
测试案例同步
关联测试需求
ATS案例设计
设计后台自动类
测试案例
平台后台服务器
Telelogic接口
系统内部关系
设计测试流程
手工
测
试
构
建
阶
段
案例类型？
后台自动
前台自
动
替换参数变量
配置测试数据
ATS运行配置
测试数据分类、
格式转换
自动测试数据管理器
业务流数据配置器
用户资料打包、
格式转换
预期结果分类、
格式转换
测
试
执
行
阶
段
测
试
分
析
阶
段
选择测试集
测试执行准备
测试数据上传
执行测试集
ATS执行引擎
获取实际结果
格式化实际结果
比对
比对结果入库
ATS管理分析
平台后台服务器
案例状态同步
测试报告
Telelogic接口
基础案例库维护
其
它
基础案例入库
基础案例库维护
基础案例库
平台后台服务器
Telelogic接口