自动化测试在功能测试中的应用
刘柏青
QQ：253458
msn：lbq1972@21cn.com
1 综述
1.1 什么是自动化测试
自动化测试是指能自动输入测试数据，自动检查被测对象的响应的测试
1.2 自动化测试的优缺点
优点：
测试效率高
测试过程可完全重现
缺点：
前期耗用的工作量较大
对测试人员的技术水平要求较高
需要对测试脚本（程序）进行维护
1.3 自动化测试的适用范围
存在大量重复性的手工测试的项目
测试时间比较长的项目
1.4 自动化测试的对测试人员的要求
有编程能力，至少会使用一种高级语言（C/C++、java、VB、Pascal）
有一定系统设计的能力
1.5 自动化测试过程
制定测试方案
编写、修改、维护测试脚本
测试实施
2 测试过程详述
2.1 设计方案
2.1.1 选定工具
winrunner：类C语言，编程能力强，浏览器、ActiveX控件的支持不如QTP。需要对界面的每类控件都录制一下，确认测试工具的确能操作该控件。
QuickTest Professional（QTP）：类VB语言，编程能力较弱，浏览器、ActiveX控件的支持强。需要对界面的每类控件都录制一下，确认测试工具的确能操作该控件。
自己编写的程序
2.1.2 确定测试环境
数据库环境
磁盘文件环境
测试脚本开始运行时的界面环境（通常为登录成功后的界面）
测试脚本结束运行时的界面环境
2.1.3 用例设计
确定功能点
确定测试数据
2.2 编写、修改、维护测试脚本
2.2.1 考虑脚本的架构
做到用例与用例的无关性，即每个用例都能单独运行，一用例不以另一用例的运行为前提
要便于挑选若干用例来运行
要便于大量用例的管理
当界面发生变化时，脚本的修改量要尽可能容易
winrunner举例：
举例1：每个用例对应一个子脚本，一个主控脚本控制调用各子脚本
举例2：每个用例对应excel表格的一条记录，主控脚本从表格中读取用例信息后运行
2.2.2 编写测试环境初始化的脚本
数据库环境初始化
磁盘文件环境初始化
界面环境初始化
2.2.3 生成界面描述文件（winrunner、QTP）
对界面的每个控件都录制一下，让测试工具生成界面描述文件
对录制出来的界面描述进行整理，提高可读性
2.2.4 编码与调试
脚本能完全自动运行，不因遇到错误而中止
注意脚本与被测软件的同步问题，避免因不同步而导致脚本中止或报错
各用例对测试结果的判断和输出不能造成脚本的中止
各用例结束时的界面环境必须能通过初始化脚本回到初始的界面环境
不建议使用检查点来判断测试结果
2.2.5 维护
根据界面的变化而改动
根据操作步骤的变化而改动
根据用例的变化而改动
2.3 测试实施
2.3.1 搭环境
2.3.2 运行测试脚本
2.3.3 记录bug
3 性能测试的误区
自动化测试一定能提高测试效率，缩短测试时间
自动化测试一定能降低测试成本
自动化测试令测试工作变得简单易行，谁都可以来做
做自动化测试，会录制脚本就够了
4 常见问题
我们的项目时间紧，怎么样做自动化测试？
自动化测试何时开始介入？
测试工具无法识别第三方控件时怎么办？
业务逻辑比较复杂，从而导致测试脚本比较复杂，怎么办？
刘柏青
QQ：253458
msn：lbq1972@21cn.com
1 综述
1.1 什么是自动化测试
自动化测试是指能自动输入测试数据，自动检查被测对象的响应的测试
1.2 自动化测试的优缺点
优点：
测试效率高
测试过程可完全重现
缺点：
前期耗用的工作量较大
对测试人员的技术水平要求较高
需要对测试脚本（程序）进行维护
1.3 自动化测试的适用范围
存在大量重复性的手工测试的项目
测试时间比较长的项目
1.4 自动化测试的对测试人员的要求
有编程能力，至少会使用一种高级语言（C/C++、java、VB、Pascal）
有一定系统设计的能力
1.5 自动化测试过程
制定测试方案
编写、修改、维护测试脚本
测试实施
2 测试过程详述
2.1 设计方案
2.1.1 选定工具
winrunner：类C语言，编程能力强，浏览器、ActiveX控件的支持不如QTP。需要对界面的每类控件都录制一下，确认测试工具的确能操作该控件。
QuickTest Professional（QTP）：类VB语言，编程能力较弱，浏览器、ActiveX控件的支持强。需要对界面的每类控件都录制一下，确认测试工具的确能操作该控件。
自己编写的程序
2.1.2 确定测试环境
数据库环境
磁盘文件环境
测试脚本开始运行时的界面环境（通常为登录成功后的界面）
测试脚本结束运行时的界面环境
2.1.3 用例设计
确定功能点
确定测试数据
2.2 编写、修改、维护测试脚本
2.2.1 考虑脚本的架构
做到用例与用例的无关性，即每个用例都能单独运行，一用例不以另一用例的运行为前提
要便于挑选若干用例来运行
要便于大量用例的管理
当界面发生变化时，脚本的修改量要尽可能容易
winrunner举例：
举例1：每个用例对应一个子脚本，一个主控脚本控制调用各子脚本
举例2：每个用例对应excel表格的一条记录，主控脚本从表格中读取用例信息后运行
2.2.2 编写测试环境初始化的脚本
数据库环境初始化
磁盘文件环境初始化
界面环境初始化
2.2.3 生成界面描述文件（winrunner、QTP）
对界面的每个控件都录制一下，让测试工具生成界面描述文件
对录制出来的界面描述进行整理，提高可读性
2.2.4 编码与调试
脚本能完全自动运行，不因遇到错误而中止
注意脚本与被测软件的同步问题，避免因不同步而导致脚本中止或报错
各用例对测试结果的判断和输出不能造成脚本的中止
各用例结束时的界面环境必须能通过初始化脚本回到初始的界面环境
不建议使用检查点来判断测试结果
2.2.5 维护
根据界面的变化而改动
根据操作步骤的变化而改动
根据用例的变化而改动
2.3 测试实施
2.3.1 搭环境
2.3.2 运行测试脚本
2.3.3 记录bug
3 性能测试的误区
自动化测试一定能提高测试效率，缩短测试时间
自动化测试一定能降低测试成本
自动化测试令测试工作变得简单易行，谁都可以来做
做自动化测试，会录制脚本就够了
4 常见问题
我们的项目时间紧，怎么样做自动化测试？
自动化测试何时开始介入？
测试工具无法识别第三方控件时怎么办？
业务逻辑比较复杂，从而导致测试脚本比较复杂，怎么办？
