1、回归测试现状和存在的问题

回归测试的目的： 确认软件经过一些小的变更或修改后是否仍满足所有的需求

回归测试是重复测试，要求使用相同的方法，使用相同的测试用例和数据，在相同的环境下进行测试

典型手工回归测试流程

现状和存在的问题]

2、建设自动回归测试系统

自动化哪些过程？

自动回归测试流程

自动回归测试带来的变化

自动回归测试的投入产出比分析

3、自动回归测试系统技术实现

1）实现方法

自动回归测试工作原理

自动回归测试系统功能结构

自动回归测试框架技术结构

测试用例设计

§ 最小分支原则

§ 封装、复用

§ 参数化

§ 动态加载

脚本生成器

§ 与测试用例设计的关系

§ 公用函数库

§ 对字符界面和 GUI 的支持

§ 配置管理

业务流管理器

§ 推拽测试用例，支持条件分支

§ 测试用例间的数据传递

§ 业务流管理：增、删、改、插入

§ 支持对同一个测试用例的多次引用和配置

数据管理器

§ 选择业务流、测试用例

§ 显示测试用例参数列表

§ 方便地修改参数值

测试调度器

§ 预约（定时）执行

§ 选择需要执行的业务流

§ 执行测试

§ 出错处理

自动回归测试框架的作用

§ 降低管理难度，使用一个管理界面，隐藏管理细节

§ 测试设计和测试实现分离

§ 支持手工测试和自动测试

§ 分离技术性测试人员和非技术性测试人员的工作

§ 集成数据驱动、关键字驱动和功能分解测试的最好特征

§ 具备自动脚本生成功能

自动回归测试框架的技术特点

§ 基于自动测试工具的测试框架，具有测试计划驱动技术的所有优点

§ 充分利用测试工具的功能，与测试管理集成

§ 基于业务流的测试，数据也是基于业务流配置的

§ 应用与自动测试框架分开

§ 可支持技术性测试人员和非技术性测试人员使用

§ 脚本与数据分开

§ 自动测试开发与运行环境分开

§ 有专门的数据管理模块，数据维护简便

§ 自动生成代码，基本不需要编码，效率极高

§ 使用数据库，不需要手工管理大量文件

§ 采用基于组件的技术，提供预制组件

§ 支持业务功能脚本和录制脚本

4、自动回归测试系统的实施方法

自动测试失败的原因

§ 为了快速建立自动测试系统，忽略了维护工作量，致使维护工作量过大，不可接受

§ 购买工具前几乎不存在测试过程

§ 无经验的或临时的测试小组

§ 设计不固定

§ 使用了错误的工具

§ 过分关注自动化技术，忽略了测试目标

§ 低估了自动测试的成本，资源不足

如何才能实施成功？

实施策略

§ 分步实施，降低风险

§ 明确的人员分工，确保具有相应技能

- 项目经理

- 测试人员 VS 开发人员

- 自动测试工程师

- 业务人员

§ 完善的文档

- 自动测试体系

- 完整的项目管理文档

- 完整的工程文档

§ 选用合适的工具，自动测试框架不影响测试工作的进行

§ 关注测试目的，而不是自动化技术

实施方法的优点

§ 从系统工程、过程改进的角度看自动回归测试的实施，方法、工具、技术和人员并重

§ 尽可能并行，节省时间

- 框架与应用分开

- 框架与脚本开发分开

- 框架与用例设计分开

§ 采用分步走的方法，降低风险

§ 可提高可维护性，降低维护工作量

总结

解决方案的特点（一）

§ 先进性

- 从系统工程、过程改进的角度看自动回归测试的实施，方法、工具、技术和人员并重

- 采用测试计划驱动技术和组件技术实现，是国际最先进的自动回归测试技术

- 业务驱动，基于业务流的测试

- 所有自动测试相关内容存储在统一的中央数据库中，便于重用

- 能支持自动化测试和手工测试

§ 可维护性 - 测试用例维护工作量不变

- 脚本和数据分开，降低维护难度和工作量

- 可自动生成脚本，降低脚本维护工作量

- 有专门的数据管理模块，简化数据维护工作

- 使用数据库，无需手工维护大量配置文件，并使之保持一致

§ 可复用性

- 自动回归测试方法论（相关规程、模板、指南、样例）的复用

- 项目实施经验和数据的复用

- 自动回归测试框架的复用

- 组件的复用

- 业务流和测试用例的重复使用

- 原有脚本仍可使用

§ 自动化

- 应用与自动测试框架分离，可并行

- 使用预制组件可加快自动测试的进程

- 脚本可自动生成

- 自动测试开发环境与运行环境分离可实现无人值守的自动测试

- 测试用例和配置数据修改后可动态加载

- 单个客户端上同时进行多个测试