自动化讲解-PPT精选文档
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
自动化测试
1
测试现状及问题
•测试筹备 •测试实施 •系统内部测试 •系统连接测试(LT) •系统集成测试(SIT) •用户接受测试(UAT) •测试审核
现象：大量集成测试案 例，代码、界面不稳定， 版本更新极为频繁 问题：测试人员少，无法承受重复 的繁重工作量，执行少量的、 关键的测试案例，测试不足 现象：接口测试，测试 数据种类繁多，具有大 量的测试案例 问题：关注关键数据， 执行少量的、关键的测试案例， 测试不足
手工测试规范度不足
最低标准 测试需求 测试案例
改进
发展
手工测试规范度满足
最高标准 测试需求 测试案例
自动化测试技术平台
自动化测试技术平台
测试管理
• 项目管理子系统 • 用户管理子系统 • 测试需求管理子系统 • 业务组件管理子系统 • 业务测试过程管理子系统
测试执行
• 测试执行组织调度子系统 • 测试运行计划设计子系统 • 测试执行子系统 • 测试执行监控子系统
自动化测试的实际应用
•测试筹备 •测试实施 •系统内部测试 •系统连接测试(LT) •系统集成测试(SIT) •用户接受测试(UAT) •测试审核 •运营维护测试
自动化接口功能测试： 测试数据自动生成，依据报文规范自动生成测 试脚本，自动执行接口功能测试，提高接口测试的 覆盖率，促进开发质量 核心业务集自动化测试： 少量自动化测试工程师，自动化少量核心业务， 版本更新时快速执行，保障核心模块的质量，提高 测试效率 核心业务集自动化测试： 少量自动化测试工程师，自动化少量核心业务， 版本更新时快速执行，保障核心模块的质量，提高 测试效率
测试阶段的 功能测试
– 背景：在高覆盖率要求的前提下，每个功能的测试案例量很大，并且由于 测试阶段中不断的代码修改、集成，重复测试的次数很多 – 应用：自动化功能测试，包括接口功能测试、界面安全性测试、业务功能 测试，提高测试的覆盖率，降低测试的工作强度 – 限制：由于测试阶段中的代码和界面的频繁变更，自动化的覆盖率应以少 量覆盖、关键覆盖为原则
运营维护阶段 的回归测试
– 背景：在运营维护阶段，每次新版本发布前，应进行充分的回归测试，确 保部分代码的变更不会影响大部分未变更的代码正确性。但是，通常情况 下，这个阶段中不会固定拥有大量的测试人员来实施手工回归测试工作 – 应用：自动化功能测试，自动化业务流测试 – 限制：独立的测试环境引起资源争用或者巨大投入，在资源受限的情况下， 应以最小化占用资源的方式进行
测试分析
• 测试分析子系统
自动化功能测试、自动化业务流测试： 自动化测试小组，计算可行自动化率，建设自 动化回归测试技术平台，长期运行自动化测试，保 障系统运行质量
3
实施难度与风险 标准实施角色
– – – – – – – 建设自动化测试体系 规划自动化测试技术平台 根据软件项目测试需要确定项目级自动化测试策略 自动化测试工作的计划、组织和协调 自动化测试环境的计划、组织和协调 自动化测试缺陷与手工测试缺陷的关联管理 自动化测试结果的分析、评估与审定
自动化测试实施
自动化测试 机构
自动化测试支持
测试环境
– 自动化测试环境的基础设施支持 – 自动化测试环境的应用环境支持 – 自动化测试组件开发的技术支持
自动化测试支持
项目组
实施难度
1
自动化测试设计
业务测试
Fra Baidu bibliotek
– 当前业务测试规范度尚未完善 – 业务测试案例尚未达到符合标准的程度 – 为自动化测试编制符合要求的测试案例带来较大的工作量 – – – – 自动化测试角色不了解信息应用系统的业务 若无详细的测试需求，无法快速分析、确定自动化测试需求 若无详细的测试案例，无法快速设计自动化测试案例 学习业务的工作量较大
业务测试
测试环境
项目组
实施难度
3
自动化测试执行
自动化测试
– 自动化测试可能遇到多项目并行的情况 – 给自动化测试的管理带来较大的难度要求
业务测试
测试环境
– 自动化测试在运营维护期的执行过程中需要对测试环境独占 – 若测试环境资源有限，会造成无测试环境资源或者测试环境资源 严重争用的情况
项目组
降低业务测试不规范带来的各种工作量
测试管理 自动化测试管理
测试管理 机构
手工测试的传承
业务测试 机构
– 提供业务测试需求 – 提供业务测试案例，包括操作步骤、业务数据和验证方法 – – – – 设计、实现自动化测试技术平台 自动化测试可行性分析；确定自动化率目标和自动化测试需求 设计、实现可执行的自动化测试业务测试过程和组件 设计、实现自动化执行机制；执行自动化测试
手工测试
工 作 重 点 = 提 高 测 试 需 求 和 测 试 案 例 的 规 范 度
自动化测试
工 作 问题： 重 1）不足以设计自动化测试 点 = 解决： 自 1）依据最低标准，基本设计 2）向业务测试角色学习、补充 动 化 3）提高业务认识，补充设计 测 试 设 积累 提高 计 、 实 现 依据最高标准，直接设计 与 执 行
问题：测试人员少，无法承受重复 现象：大量业务测试案 的繁重工作量，执行少量的、 例，代码、界面不稳定， 关键的测试案例，测试不足 版本更新比较频繁
•运营维护测试
现象：版本定期发布， 大量回归测试案例，代 码、界面稳定 问题：大量回归测试案例，无 足够手工回归测试人员，测试不足
2
解决思路初探 自动化测试的标准应用
自动化测试
测试环境
项目组
– 自动化测试的组件开发需要项目组提供软件界面处理逻辑的详细 文档，或者由项目组的开发人员提供技术支持，导致工作量较大
实施难度
2
自动化测试实现
自动化测试
– 自动化测试的脚本开发与应用软件的界面、代码变更息息相关 – 自动化测试的脚本量越大，维护工作量就越大 – 若实施准备不足或风险预估不完整，甚至导致实现失败
测试阶段的 业务流测试
– 背景：在集成测试和用户接受测试阶段中，业务流程的测试是主要工作内 容。但是，每个业务流程由于操作步骤多，导致执行时间长，重复的执行 增加了测试的工作量和加重了工作负担 – 应用：自动化业务流测试，提高测试的覆盖率，降低工作强度 – 限制：同样由于测试阶段中的代码和界面的频繁变更，自动化的覆盖率应 以少量覆盖、关键覆盖为原则
1
测试现状及问题
•测试筹备 •测试实施 •系统内部测试 •系统连接测试(LT) •系统集成测试(SIT) •用户接受测试(UAT) •测试审核
现象：大量集成测试案 例，代码、界面不稳定， 版本更新极为频繁 问题：测试人员少，无法承受重复 的繁重工作量，执行少量的、 关键的测试案例，测试不足 现象：接口测试，测试 数据种类繁多，具有大 量的测试案例 问题：关注关键数据， 执行少量的、关键的测试案例， 测试不足
手工测试规范度不足
最低标准 测试需求 测试案例
改进
发展
手工测试规范度满足
最高标准 测试需求 测试案例
自动化测试技术平台
自动化测试技术平台
测试管理
• 项目管理子系统 • 用户管理子系统 • 测试需求管理子系统 • 业务组件管理子系统 • 业务测试过程管理子系统
测试执行
• 测试执行组织调度子系统 • 测试运行计划设计子系统 • 测试执行子系统 • 测试执行监控子系统
自动化测试的实际应用
•测试筹备 •测试实施 •系统内部测试 •系统连接测试(LT) •系统集成测试(SIT) •用户接受测试(UAT) •测试审核 •运营维护测试
自动化接口功能测试： 测试数据自动生成，依据报文规范自动生成测 试脚本，自动执行接口功能测试，提高接口测试的 覆盖率，促进开发质量 核心业务集自动化测试： 少量自动化测试工程师，自动化少量核心业务， 版本更新时快速执行，保障核心模块的质量，提高 测试效率 核心业务集自动化测试： 少量自动化测试工程师，自动化少量核心业务， 版本更新时快速执行，保障核心模块的质量，提高 测试效率
测试阶段的 功能测试
– 背景：在高覆盖率要求的前提下，每个功能的测试案例量很大，并且由于 测试阶段中不断的代码修改、集成，重复测试的次数很多 – 应用：自动化功能测试，包括接口功能测试、界面安全性测试、业务功能 测试，提高测试的覆盖率，降低测试的工作强度 – 限制：由于测试阶段中的代码和界面的频繁变更，自动化的覆盖率应以少 量覆盖、关键覆盖为原则
运营维护阶段 的回归测试
– 背景：在运营维护阶段，每次新版本发布前，应进行充分的回归测试，确 保部分代码的变更不会影响大部分未变更的代码正确性。但是，通常情况 下，这个阶段中不会固定拥有大量的测试人员来实施手工回归测试工作 – 应用：自动化功能测试，自动化业务流测试 – 限制：独立的测试环境引起资源争用或者巨大投入，在资源受限的情况下， 应以最小化占用资源的方式进行
测试分析
• 测试分析子系统
自动化功能测试、自动化业务流测试： 自动化测试小组，计算可行自动化率，建设自 动化回归测试技术平台，长期运行自动化测试，保 障系统运行质量
3
实施难度与风险 标准实施角色
– – – – – – – 建设自动化测试体系 规划自动化测试技术平台 根据软件项目测试需要确定项目级自动化测试策略 自动化测试工作的计划、组织和协调 自动化测试环境的计划、组织和协调 自动化测试缺陷与手工测试缺陷的关联管理 自动化测试结果的分析、评估与审定
自动化测试实施
自动化测试 机构
自动化测试支持
测试环境
– 自动化测试环境的基础设施支持 – 自动化测试环境的应用环境支持 – 自动化测试组件开发的技术支持
自动化测试支持
项目组
实施难度
1
自动化测试设计
业务测试
Fra Baidu bibliotek
– 当前业务测试规范度尚未完善 – 业务测试案例尚未达到符合标准的程度 – 为自动化测试编制符合要求的测试案例带来较大的工作量 – – – – 自动化测试角色不了解信息应用系统的业务 若无详细的测试需求，无法快速分析、确定自动化测试需求 若无详细的测试案例，无法快速设计自动化测试案例 学习业务的工作量较大
业务测试
测试环境
项目组
实施难度
3
自动化测试执行
自动化测试
– 自动化测试可能遇到多项目并行的情况 – 给自动化测试的管理带来较大的难度要求
业务测试
测试环境
– 自动化测试在运营维护期的执行过程中需要对测试环境独占 – 若测试环境资源有限，会造成无测试环境资源或者测试环境资源 严重争用的情况
项目组
降低业务测试不规范带来的各种工作量
测试管理 自动化测试管理
测试管理 机构
手工测试的传承
业务测试 机构
– 提供业务测试需求 – 提供业务测试案例，包括操作步骤、业务数据和验证方法 – – – – 设计、实现自动化测试技术平台 自动化测试可行性分析；确定自动化率目标和自动化测试需求 设计、实现可执行的自动化测试业务测试过程和组件 设计、实现自动化执行机制；执行自动化测试
手工测试
工 作 重 点 = 提 高 测 试 需 求 和 测 试 案 例 的 规 范 度
自动化测试
工 作 问题： 重 1）不足以设计自动化测试 点 = 解决： 自 1）依据最低标准，基本设计 2）向业务测试角色学习、补充 动 化 3）提高业务认识，补充设计 测 试 设 积累 提高 计 、 实 现 依据最高标准，直接设计 与 执 行
问题：测试人员少，无法承受重复 现象：大量业务测试案 的繁重工作量，执行少量的、 例，代码、界面不稳定， 关键的测试案例，测试不足 版本更新比较频繁
•运营维护测试
现象：版本定期发布， 大量回归测试案例，代 码、界面稳定 问题：大量回归测试案例，无 足够手工回归测试人员，测试不足
2
解决思路初探 自动化测试的标准应用
自动化测试
测试环境
项目组
– 自动化测试的组件开发需要项目组提供软件界面处理逻辑的详细 文档，或者由项目组的开发人员提供技术支持，导致工作量较大
实施难度
2
自动化测试实现
自动化测试
– 自动化测试的脚本开发与应用软件的界面、代码变更息息相关 – 自动化测试的脚本量越大，维护工作量就越大 – 若实施准备不足或风险预估不完整，甚至导致实现失败
测试阶段的 业务流测试
– 背景：在集成测试和用户接受测试阶段中，业务流程的测试是主要工作内 容。但是，每个业务流程由于操作步骤多，导致执行时间长，重复的执行 增加了测试的工作量和加重了工作负担 – 应用：自动化业务流测试，提高测试的覆盖率，降低工作强度 – 限制：同样由于测试阶段中的代码和界面的频繁变更，自动化的覆盖率应 以少量覆盖、关键覆盖为原则