第
This presentation is the property of its rightful owner.
Sponsored Links
1 / 117

第 8 部分 自动化测试技术及工具 PowerPoint PPT Presentation


  • 125 Views
  • Uploaded on
  • Presentation posted in: General

第 8 部分 自动化测试技术及工具. 袁玉宇 [email protected] [email protected] 本部分课程目标. 测试与自动化测试 自动化测试技术 自动化测试工具. 自动化. 自动化是对策略、经验、工具及工件的使用,它减少了对手工或人的干预或非技能方面的介入,及重复或冗长工作需要。. 测试自动化. 自动化测试直接依赖于整个软件流程的可自动化成熟度。 包括:测试流程、持续编译、持续集成、测试系统发布、测试执行、测试管理、缺陷测试跟踪等多个方面的自动化实现和整合。. 测试和自动化的区别. 自动化测试的误区.

Download Presentation

第 8 部分 自动化测试技术及工具

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


8

第8部分 自动化测试技术及工具

袁玉宇

[email protected]

[email protected]


8

本部分课程目标

  • 测试与自动化测试

  • 自动化测试技术

  • 自动化测试工具


8

自动化

自动化是对策略、经验、工具及工件的使用,它减少了对手工或人的干预或非技能方面的介入,及重复或冗长工作需要。


8

测试自动化

  • 自动化测试直接依赖于整个软件流程的可自动化成熟度。

  • 包括:测试流程、持续编译、持续集成、测试系统发布、测试执行、测试管理、缺陷测试跟踪等多个方面的自动化实现和整合。


8

测试和自动化的区别


8

自动化测试的误区

  • 期望自动化测试能够完全取代手动测试

  • 期望自动化测试发现大量的新缺陷

  • 期望自动化测试能够智能的完成绝大多数工作

  • 期望自动化测试是一劳永逸的


8

自动化测试的目的

  • 缩短测试周期,加快测试进度,从而加快产品发布进度

  • 实现更大规模、更大频率的测试

  • 减少手工测试的人力资源投入,降低测试成本

  • 提高测试覆盖率

  • 保证回归测试的可控性和一致性


8

自动化测试的目的

  • 提高测试用例执行的可靠性

  • 在不降低质量的情况下由低技能的人员完成

  • 定义清晰的测试过程,降低和避免测试人员的个体对整体测试的影响

  • 提高测试人员的工作效率,并使更高技能的人员有时间和资源,对产品进入更深层次的测试。

  • 辅助测试人员完成手工无法完成的测试工作。


8

测试用例的质量指标

  • 检测软件缺陷的有效性

  • 测试用例的可仿效性

  • 测试用例执行、分析和调试的经济性

  • 测试用例的可修改行


Keviat

Keviat图


8

适合做自动化测试情况

  • 产品型项目

  • 大型增量式开发、持续集成项目

  • 能够自动编译、自动发布的系统

  • 需要多次重复机械性动作的测试


8

适合做自动化测试情况

  • 简单而烦琐的基于命令行交互方式的测试

  • 完成一些手工难以完成的测试目标

  • 涉及大量第三方软件或设备的测试


8

不适合做自动化测试情况

  • 按需定制型项目(通常为一次性的短期项目)

  • 项目周期很短的项目

  • 业务规则复杂的项目


8

不适合做自动化测试情况

  • 依赖于人类的习惯、感官或智力的测试内容

  • 不需要频繁测试的软件

  • 软件不稳定


8

自动化测试面临的问题

  • 目标因素

  • 时间因素

  • 资源因素

  • 需求因素

  • 技术因素


8

自动化测试过程管理

  • 测试管理自动化

  • 测试执行及报告自动化

  • 缺陷跟踪自动化


8

被测软件产品

  • 提供API的软件

  • 基于命令行的接口

  • 基于GUI

  • 基于终端接口


8

自动化测试的最佳实践

  • 自动化测试的代码效率不是越高越好

  • 自动化测试的执行过程和记录应便于分析

  • 自动化测试的设计和脚本可读性越好越好


8

自动化测试的最佳实践

  • 自动化测试的脚本可维护性是重中之重

  • 完整性是自动化测试成功的前提

  • 自动化测试脚本之间是松耦合或彼此独立的


8

自动化测试的脚本技术

  • 线性脚本

  • 结构化脚本

  • 共享脚本

  • 数据驱动脚本

  • 关键字驱动脚本


8

线性脚本

  • 线性脚本是录制手工执行的测试事例得到的脚本。

  • 如果用户只使用线性脚本技术,即录制每个测试事例的全部内容,则每个测试事例可以通过脚本完整地被回放。

  • 几乎任何重复的操作都可以使用线性脚本技术自动化。


8

线性脚本的优点

  • 简单,只需坐在计算机前录制手工任务。

  • 可以快速开始自动化。

  • 对实际执行操作可以审计跟踪。

  • 用户不必是编程人员(如果不修改)


8

线性脚本的缺点

  • 无共享或重用脚本。

  • 容易受软件变化的影响。

  • 修改代价大。

  • 如果回放脚本时发生了录制脚本时没有发生的事情,引起整个测试失败。


8

结构化脚本

  • 结构化脚本类似于结构化程序设计,结构化脚本中含有控制脚本执行的指令。

  • 控制脚本执行的指令:顺序,选择和叠代。


8

结构化脚本例子

Part of the Scribble test script

SelectOption ’ File/Close’

Focuso On’ Close’

LeftMouseClick’Yes’

FocusOn’Save As’

Type countries2

LeftMouseClick’Save’

If Message=‘Replace existing file?’

LeftMouseClick’yes’

End if

FocusOn ‘ Scribble’

SelectOption’File/Exti’


8

结构化脚本的优缺点

  • 健壮性好,对一些容易导致测试失败的特殊情况进行处理。

  • 可以执行许多其他类似的功能,如重复的指令可以使用循环结构。

  • 可以作为模块被其他脚本调用。

  • 脚本变得更加复杂,而且测试数据仍然’捆绑’在脚本中。


8

共享脚本

  • 脚本可以被多个测试事例使用。这意味着脚本语言允许一个脚本被另一个脚本调用,而这多少已成为所有测试执行自动化工具的标准。

  • 这种技术思路是产生一个执行某种任务的脚本,而不同的测试要重复这个任务,当要执行这个任务时只需要在每个测试事例的适当地方调用这个脚本。


8

共享脚本例子

ScribbleOpen(FILENAME)

LeftMouseClick’Scribble’

FocusOn’Scribble’

SelectOption’File/Open’

FocusOn’Open’

Type’countries’

LeftMouseClick’Open’


8

共享脚本例子

ScribbleSaveAs(FILENAME)

FocusOn’Scribble’

SelectOption’File/Close’

FocusOn’Close’

LeftMouseClick’Yes’

FocusOn’Save As’

Type FILENAME

LeftMouseClick’Save’

FocusOn’Scribble’

SelectOption’File/Exit’


8

共享脚本例子

Call ScribbleOpen(‘countries’)

FocusOn’Scribble’

SelectOption’List/Add Item’

FocusOn’Add Item’

Type’France’

LeftMouseClick’OK’

FocusOn’Scribble ’

SelectOption’List/Add Item’

FocusOn’Add Item’

Type’Germany’

LeftMouseClick’OK’

FocusOn’Scribble’

Call ScribbleSaveAS(‘TEST2’)


8

共享脚本的优点

  • 以较少的开销实现类似的测试。

  • 维护开销低于线性脚本。

  • 删除明显的重复。

  • 可以在共享脚本中增加更智能的功能。


8

共享脚本的缺点

  • 需要跟踪更多的脚本,文档、名字、以及存储,很难找到适当的脚本。

  • 对于每个测试仍需要一个特定的测试脚本。因此维护成本比较高。

  • 共享脚本通常是针对被测软件的某个部分。


8

数据驱动脚本

  • 数据驱动脚本技术将测试输入存储在独立的数据文件中,而不是存储在脚本中。脚本中存放控制信息(如菜单导航)。执行测试时,从文件中而不是直接从脚本中读取测试输入。这种方法的最大好处是同一个脚本可以运行不同的测试。


8

数据驱动脚本例子

Control script: ScribbleControl

OpenFile’ScribbleData’

For each record in ScribbleData

Read INPUTFILE

Read NAME1

Read NAME2

Read OUTPUTFILE


8

数据驱动脚本例子

Call ScribbleOpen(INPUTFILE)

FocusOn’Scribble’

SelectOption’List/Add Item’

FocusOn’Add Item’

Type NAME1

LeftMouseClick’OK’

FocusOn’Scribble ’

SelectOption’List/Add Item’

FocusOn’Add Item’

Type NAME2

LeftMouseClick’OK’

FocusOn’Scribble’

Call ScribbleSaveAS(OUTPUTFILE)

EndFor


8

数据驱动脚本例子

Data file: ScribbleData

Countries, Sweden, USA, test1

Countries, France, Germany, test2

Countries, Austria, Italy, test3

Countries, Spain, Finland, test4


8

数据驱动脚本优点

  • 可以很快增加类似的测试。

  • 测试者增加新测试不必具有工具脚本语言的技术或编程知识。

  • 对第二个测试及后续测试无额外的脚本维护开销。


8

数据驱动脚本缺点

  • 初始建立的开销较大;

  • 需要专业编程支持;

  • 必须易于管理。


8

关键字驱动脚本

  • 就是较复杂的数据驱动技术的逻辑扩展。

  • 分为三层结构:一是控制脚本;二关键字动作描述;三是数据或测试用例。


8

自动化技术

  • 模拟/虚拟技术

  • 对象管理技术

  • 脚本技术

  • 比较技术


8

自动化技术

  • 执行技术

  • 录制、回放技术

  • 同步技术

  • 健壮性技术


8

软件开发生命周期测试工具


8

如何评价和选择自动化测试工具

  • 是否支持脚本化语言

  • 是否支持函数的可重用

  • 是否支持外部函数库

  • 是否具有对象映射/抽象层


8

如何评价和选择自动化测试工具

  • 是否支持分布式测试执行

  • 是否支持数据驱动测试

  • 是否具有强大的错误处理机制


8

测试活动


8

测试用例例子


8

适合自动化的活动


8

非侵入式和侵入式

  • 非侵入式工具是仅用于监视和检查软件而不对其进行修改。

  • 侵入式工具是通过某种方式修改程序代码或者操纵操作环境。

    测试通常设法使用侵入性尽量小的工具以减少测试结果的可能性。


8

查看器和监视器

任何能够洞察系统,看到一般用户看不到的数据的工具都可以归于查看或监视测试工具。

如:代码范围分析器

代码调试器

通信分析器


8

驱动程序

驱动程序是用于控制和操作测试软件的工具。驱动程序最简单的例子是批文件,即顺序执行的程序或命令的简单清单。


8

施压和增负工具

  • 施压和增负工具向测试软件增加压力和负荷。这些工具可以分别设置内存量、磁盘空间、文件数量,以及运行该机器上软件的其他可用资源。

  • 施压和增负工具的相似之处是它们为软件创造难以实现的条件。


8

分析工具

大多数软件测试员利用以下常用工具简化日常工作:

  • 字处理软件

  • 电子表格软件

  • 数据库软件

  • 文件比较软件

  • 抓屏和比较软件

  • 调试器

  • 秒表


8

宏录制和回放

宏录制和回放:是一种驱动程序工具。是通过录制第一次执行测试案例时的键盘和鼠标操作,然后在需要重新执行时回放。

宏设置的项目:

名称、重复次数、触发条件、捕捉对象、回放速度、回放位置。


8

可编程的宏

  • 可编程的宏:通过编写回放系统遵守的简单指令来实现测试,可以实现等待特定条件成立才继续执行。但只可以直接执行命令行——只能循环和重复,不可以使用常规的变量和决策语句。


8

完全可编程的自动测试工具

  • 完全可编程的自动测试工具:具有成熟编程语言的能力,加上驱动测试软件的宏命令,以及进行验证的能力。


Mercury interactive corporation

Mercury Interactive Corporation

  • WinRunner

  • LoadRunner

  • TestDirector


Winrunner

WinRunner

  • 是一种企业级的用于检验应用程序是否如期运行的功能性测试工具。

  • 通过自动捕获、检测和重复用户交互的操作。

  • 它会自动操作应用程序,在它的意外功能为测试排除干扰,包括消息和警报。


Loadrunner

LoadRunner

  • 是一种预测系统行为和性能的负载工具。

  • LoadRunner是一种较高规模适应性的,自动负载测试工具,它能预测系统行为,优化性能。

  • LoadRunner强调的是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的确认和查找问题。


Testdirector

TestDirector

  • TestDirector是业界第一个基于Web的测试管理系统,它可以在您公司组织内进行全球范围内测试的协调。

  • 通过在一个整体的应用系统中提供并且集成了测试需求管理,测试计划,测试日程控制以及测试执行和错误跟踪等功能,TestDirector极大地加速测试过程。


8

测试管理包括如下四个阶段


Specify requirements

需求定义(Specify Requirements)


8

定义测试范围

  • 测试组收集所有可以利用的文档信息,开始测试处理过程,例如收集市场和商务需求文档、系统需求说明书和设计文档等。

  • 使用这些文档对应用程序的测试方面作一个全面彻底的了解,并以此为基础来确定你的测试范围、测试目的、目标和策略。


8

定义测试范围

  • 应用程序的主要目的是什么?

  • 应用程序有哪些主要特点?

  • 哪些功能在这个产品中是相对重要的?

  • 在应用程序中,哪些功能是危急的或高风险的?

  • 你的测试优先级是什么?

  • 你的客户或最终用户是否同意你的测试优先级?

  • 你总的质量目标是什么?


8

定义测试范围

  • 举个例子,假设一个航班预定软件,它可以实现管理航班调动、旅客登记和机票销售。

  • 可能会定义主要的测试需求为:登陆操作、数据库操作、传真发送操作、安全性能力检查、图形和报表操作、UI检查操作和帮助。


8

创建测试需求大纲


8

定义需求


8

分析需求定义

  • QA管理人员复查这些需求,并确定测试范围被更早的定义。他们还应该将需求的状态改为“Reviewed”,假如这个需求被评审通过的话。


8

需求模块 一览


8

从需求产生测试

  • 在需求树中,右键点击一个需求,并选择Generate Test。编制测试用例对话框将被打开。

  • 对于Subject框,从测试计划树中选择一个主题或输入一个新的主题名。

  • 在Test Name框中,为新测试输入一个名字。默认情况下,TestDirector将使用需求名称作为测试名。


8

从需求产生测试


8

从需求产生测试

  • 假如你不希望TestDirector去创建测试步骤,取消Create Design Steps复选框的选择。假如此选项是被选中的,TestDirector将为每个子需求添加一个步骤到测试。

  • 选中Add Test to Test Set复选框,去要求TestDirector在测试实验室模块中增加测试到测试集。在Test Set列表中,选择一个测试集或输入一个新的测试集名称。

  • 点击OK。


Planning tests

测试计划(Planning Tests)


8

定义测试策略

你应当怎样测试你的应用程序?

  • 你将使用哪些测试技术?

  • 你将怎样处理缺陷?

    你需要什么资源?

  • 为了测试,你需要什么资源?

  • 各个任务什么时候被完成?


8

定义测试主题

  • 根据应该程序功能的等级关系,将应该程序功能分解为各个主题,并建造相应的表现应用程序功能的测试计划树。

  • 测试计划树是你的测试计划的一种图形的表现。它是根据主题组织的测试分级表,而每一个主题所包含的,就是为了实现质量要求而需要进行的测试。


8

设计测试

  • 为测试计划树上的每一个主题设计测试。确定每个测试主题应该创建哪些种类的测试。

  • 然后在每个测试计划树的分支上创建并设计它们。


8

创建需求覆盖

  • 将测试计划树上的每一个测试连接到需求树上的一个或多个需求。通过为需求定义测试覆盖,你可以对你测试计划中的测试和它原始的测试需求之间进行追踪。


8

设计测试步骤

  • 在测试计划树中对具体的测试进行设计。创建测试步骤,描述所要执行的操作、检查点和预期的结果。定义完测试步骤后,紧接着就应该决定,该测试是准备手动测试还是自动测试。

  • 对于手动测试,应该按你定义好的步骤,在应该程序中执行它,并记录相应的结果。


8

自动测试

  • 自动化测试允许在无人值守的情况下,高速地执行测试。它也使测试能够重复的执行和使用。

  • 在设计完测试步骤后,你能够决定哪些测试应该进行自动化。影响测试自动化的因素包括:执行的频率、数据输入量、执行时间的长度和复杂度。


8

分析测试计划

  • 复查你的测试计划去确定怎样它才能满足在测试过程开始阶段定义的测试目标。然后通过产生TestDirector报告和图表对你的测试计划进行分析。

  • 建议贯穿整个测试过程来分析你的测试计划,从而更好地保证测试过程的成功。复查测试计划,并确定是否满足测试目标,并相应地对测试计划作出调整。


8

测试计划模块一览


Running tests

测试执行(Running Tests)


8

创建测试集

  • 通过创建测试集和为每个测试集选择测试来开始整个测试实验室工作流。一个测试集是在TestDirector工程数据库中,设计以达到明确的测试目标的一组测试。


8

制定测试运行安排

  • TestDirector能够让你对测试集中的测试执行进行控制。你能够设置条件,并安排执行测试的日期和时间。你也可以设置执行测试的顺序。


8

运行手动测试

  • 一旦你已经定义了测试集,你就可以开始执行这些测试了。当你手动运行一个测试时,你需按照测试计划树中定义的测试步骤来一步一步执行。每个步骤是通过还是失败,决定于应该程序的实际结果是否与期望的输入相匹配。


8

运行自动测试

  • 一旦你定义了测试集,你就可以开始执行这些测试。你可以选择所有的测试或指定部分测试到一个测试集中。你的选择中,可以包含自动测试和手动测试。

  • 当你运行一个自动测试时,TestDirector会自动打开所选定的测试工具,运行这个测试,并向TestDirector中输出测试结果。当你运行一个手动测试时,会发送一封E-mail到指定的测试人员,并要求他(她)执行这个手动测试。


8

分析测试结果

  • 在测试运行后,你应当分析测试的结果。你的目的是识别失败的步骤,并确定应用程序中的缺陷是否被侦测,或者你的测试的预期结果是否需要去更新。你可以通过查看运行的数据和


8

执行测试模块一览


Tracking defects

缺陷跟踪(Tracking Defects)


Adding defects

Adding Defects

  • 当你在测试中找到一个应用软件的错误, 你向td项目发送一个错误报告.项目存储这个错误信息在一个错误数据库以便可以让任何有权限的人查看这些错误


Reviewing new defects

Reviewing New Defects

  • 回复所有在工程中的错误哪个是被确定的. 这个任务一般是通过质量保证员或者项目经理完成. 修改一个新的错误为Open,指派这个错误到一个项目开发小组,你能找到相同的错误,如果重复出现,改变错误身份为Closed 或者Rejected, 或者从项目中删除他们


Repairing open defects

Repairing Open Defects

  • 确定这个是Open defects。 需要判定这个错误的原因,修改或者重建程序,这个人物由开发人员完成,当错误被修改将身份改为Fixed。


Testing a new application build

Testing a New Application Build

  • 在新建的软件下运行测试,如果一个错误没有重现,将这个错误的身份改为Closed。如果这个错误再次出现,将身份改为Reopen,并且返回到上一页and return to the, RepairingOpen Defects这个任务一般安排质量保证员或项目经理完成


Analyzing defect data

Analyzing Defect Data

  • 查看有多少错误被修改的报告, 哪些还是open。你的工作,你能保存这些数据来帮助错误追踪过程,并且当用到时转载他们

  • 报告和图表能帮助你分析错误修复过程,并且查看错误存在于项目的时间. 这些帮助你决定什么时候这个软件能够发表


The defects module at a glance

The Defects Module at a Glance


Working with project database

Working with Project Database

  • 当你创建一个TestDirector工程后,你需要存储和管理TestDirector自身产生和连接的数据库。每一个工程都支持通过数据库来存储工程信息。

  • TestDirector是一个知识库,它存储着需求、测试、测试集、测试个案(Test Run)、工程文档和定制信息。为了应用程序测试工程能够正常工作,TestDirector需要持续不断地访问这些数据。


8

可使用数据库应用软件

  • Microsoft Access

  • Sybase

  • Microsoft SQL

  • Oracle


Testdirector1

TestDirector包含模块


Testdirector2

TestDirector显示数据

  • 需求树(Requirements Tree)

  • 测试计划树(Test Plan Tree)

  • 测试网格(Test Grid)

  • 设计步骤网格(Design Steps Grid)


Testdirector3

TestDirector显示数据

  • 测试集树(Test Sets Tree)

  • 执行网格(Execution Grid)

  • 缺陷网格(Defects Grid)


8

连接需求到一个测试

  • 在测试计划期间,当你在测试计划树上选择一个测试时,TestDirector会在需求覆盖标签页中显示这个测试的需求覆盖。覆盖网格中列出了所选择测试所覆盖的需求。你可以在这个覆盖网格中添加或删除需求。


8

添加需求覆盖

  • 从需求树上选择需求,添加需求覆盖到一个测试。

  • 在测试计划树上选择一个测试。

  • 点击Reqs Coverage标签页。

  • 点击Select Requirements按钮去在右边显示需求树。


8

添加需求覆盖

  • 在需求树中搜索特定的需求:在Find输入框中输入所要搜索的需求的名称(或部分名称),并点击Find按钮。假如搜索成功,TestDirector会在树中高亮显示此需求。

  • 在树中刷新一个需求:选择需求,并点击Refresh Selected按钮。若想刷新树中所有的需求,右键点击此需求树,并选择Refresh > Refresh All。

  • 选择一个需求或需求主题去添加覆盖。


8

添加需求覆盖

  • 假如你想覆盖能够包括所选需求的子需求,选中Include Child Requirements Into Test Coverage复选框。

  • 点击Add to Coverage按钮,需求被添加到覆盖网格中。

  • 提示:你可以通过在拖动需求树中的需求或需求主题到覆盖网格中,来定义需求覆盖。

  • 点击Close按钮去隐藏需求树。


8

连接测试到需求

  • 在测试计划模块,你可以通过选择需求连接到一个测试来创建需求覆盖。也可以在需求模块,通过选择测试连接到一个需求来创建测试覆盖。一个测试能够覆盖一个或多个需求,一个需求也可以覆盖一个或多个测试。


8

关于构建测试

  • 在测试计划模块通过定义测试步骤来构建测试:详细地、一步一步地指示关于怎样去执行一个测试。一个步骤包括应该程序准备执行的动作、输入和期望的输出。一个步骤也能够包括参数。在添加测试到测试计划树之后,你应为每一个测试定义步骤并定义基本的测试信息。


8

创建测试步骤

  • 在测试计划树上选择一个测试,并点击Design Steps标签页。

  • 点击New Step按钮或右键点击设计步骤标签页并选择New Step。设计步骤编辑器被打开。


8

创建测试步骤

  • 为测试步骤输入Description和Expected Result。键入数据为任何用户自定义的字段。

  • 点击New Step按钮,来增加另外的步骤。紧接着的序列号显示在Step Name框中。

  • 选择Close按钮来关闭设计步骤编辑器,并添加这些测试步骤。


8

自动化测试队伍


8

测试执行:分析结果

  • 测试环境导致失败

  • 应用程序改变导致假失败

  • 测试错误导致假失败

  • 重复失败

  • 测试缺陷导致假失败

  • 错误遗漏导致假失败


8

使用测试工具和自动化的问题

  • 软件变更

  • 人眼和直觉是不可替代的

  • 验证难以实现

  • 容易过分依赖自动化

  • 编写宏、开发工具和编制猴子都属于开发工作。

  • 某些工具是侵入性的,可能导致测试的软件不正常失败。


8

小结

  • 清楚何时使用工具和使用哪一种工具是软件测试员的重要技巧。

  • 创建、使用测试工具和测试自动化是有意义的工作。


  • Login