第八章 软件测试自动化课件.pptx

第八章 软件测试自动化第1页/共100页测试面临的问题测试用例会越来越多，工作量越来越大，而且许多测试用例会被不断地重复执行。如果由手工来完成，不仅占用很多人力资源，而且工作重复单调，会影响测试人员的积极性，降低测试工作人员的热情 怎么办？测试自动化第2页/共100页目录 8.1 自动化测试的作用与优势 8.2 自动化测试的原理 8.3 自动化工具的分类与选择 8.4 自动化测试的引入第3页/共100页8.1自动化测试的作用与优势什么是自动化测试？自动化测试（自动化测试（automated testautomated test）是相对手工测试）是相对手工测试（manual testmanual test）而存在的一个概念，由手工逐个）而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的地运行测试用例的操作过程被测试工具自动执行的过程所代替。过程所代替。第4页/共100页自动化测试的作用手工测试的不足： 手工测试执行时间长，测试效率低。 由于手工测试的工作量很大，在测试人员不足或测试周期很短的情况下，难以达到测试的充分性要求。第5页/共100页 当修改了软件之后，经常难以及时完成有效的回归测试。同时，回归测试是典型的重复性测试工作，会使测试人员感到单调枯燥。 当测试过程包含大量测试用例和测试数据时，测试执行和管理的细节会很繁琐，容易出错。第6页/共100页 难以便捷和全面地对测试进程及其结果进行统计分析并生成规范性的测试报告。 性能测试时无法模拟大规模软件系统负载。 难以完成系统可靠性测试，无法模拟验证系统连续运行几个月甚至几年后是否仍然能够稳定运行。第7页/共100页手工测试p 发现缺陷率高发现缺陷率高p 容易实施容易实施 p 创造性、创造性、灵活性灵活性p 覆盖率量化困难覆盖率量化困难p 重复测试效率低重复测试效率低p 不一致性、可靠性低不一致性、可靠性低p 依赖人力资源依赖人力资源 高效率（速度）高效率（速度） 高复用性高复用性 覆盖率容易度量覆盖率容易度量 准确、准确、可靠可靠 不知疲劳不知疲劳 激励团队士气激励团队士气 机械、难以发现缺陷机械、难以发现缺陷 一次性投入大一次性投入大自动测试手工测试 vs.自动测试第8页/共100页两者相互补充p在系统功能逻辑测试、验收测试、适用性测试、涉及交互性测试时，多采用手工测试方法；p单元测试、集成测试、系统负载或性能、可靠性测试等比较适合采用自动测试；p对那种不稳定、开发周期短或一次性的软件等不适合自动测试；p工具本身缺乏想象力和创造性，自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷；第9页/共100页测试工具对软件测试的影响 测试工具的广泛使用大大提高了软件测试的自动化程度。通过测试工具可以模拟手工测试的步骤，控制被测软件的运行，自动完成测试用例执行结果的判断，实现半自动或全自动的测试过程。第10页/共100页 需要注意的是，自动化测试不可能完全替代手工测试，很多的测试过程还必须依靠手工测试完成。自动化测试和手工测试在实际工作中应当取长补短、综合使用。此外，自动化测试并不只是单纯使用测试工具，还包括应用自动化测试的思想和方法，建立适应自动化测试的策略与工作流程。第11页/共100页8.1.2 自动化测试的优势 自动化的性能自动化的性能测试测试 性能测试需要模拟大量的负载，最常见的是模拟成百上千的并发用户来测试系统的性能瓶颈、验证各种性能指标，离开测试工具是根本无法完成的。因此，类似性能测试这种需要模拟大量用户和并发任务的测试活动非常适合采用自动化测试。第12页/共100页 自动化的回归测试自动化的回归测试 回归测试是重复已执行过的测试，避免修改程序对原有正常功能产生影响。回归测试用例是已经完全设计好的，即使有些改动一般也不会太多，而且测试的预期结果也是完全可以确定的。第13页/共100页回归测试中自动化与手工测试工作量对比第14页/共100页图8-1 回归测试中自动化与手工测试工作量对比自动化与手工测试工作量对比： 自动化测试在初次测试时因为要开发自动化测试用例，工作量会大于手工测试。但是随着回归测试的增多，初期产生的工作量被均摊，总工作量明显小于手工测试，并且回归测试的次数越多效果越明显。第15页/共100页自动化测试的其他一些优势 可以规范整个测试流程，方便地进行软件缺陷跟踪和管理。 测试的全面性明显优于手工测试。 能更好地保证程序代码、测试用例和相关文档记录的版本一致性。第16页/共100页 提高功能测试基本操作和数据验证的质量和效率。 便于捕捉偶然发生的软件缺陷。 能更好地利用人力资源。将繁琐、单调和重复的工作交由自动化测试来做。第17页/共100页8.2 自动化测试的原理8.2.1 测试用例的录制与回放 很多软件或专门的软件工具都提供了录制特定软件操作的功能，最常见的是Microsoft Word中的宏。 图8-2 Microsoft Word中录制宏的窗口第18页/共100页适合录制为宏的任务： 对于Word中需要反复执行的某些任务，可以将其录制为宏，通过运行录制后的宏来自动执行该任务。 例如，插入具有指定尺寸、边框、行数和列数的表格，或者是将手工去除空格、文字查找与替换、格式修改等个性化排版操作录制为一个宏，方便之后进行一次性操作。第19页/共100页 例子：在Word中插入一个22的表格、选择表格样式、在每个表格中输入一个数据”录制为宏，其脚本代码如下所示。第20页/共100页Sub 宏1()注释ActiveDocument.Tables.Add Range:=Selection.Range, NumRows:=2, NumColumns:= _ 2, DefaultTableBehavior:=wdWord9TableBehavior, AutoFitBehavior:= _ wdAutoFitFixed With Selection.Tables(1) If .Style 网格型 Then .Style = 网格型 End If .ApplyStyleHeadingRows = True .ApplyStyleLastRow = False .ApplyStyleFirstColumn = True .ApplyStyleLastColumn = False .ApplyStyleRowBands = True .ApplyStyleColumnBands = False 从上面Word宏的例子可知，通过工具可以将软件操作和数据输入录制为相应的脚本因此可以通过，运行脚本重复之前的所有操作。第21页/共100页End With Selection.Tables(1).Style = 浅色底纹 - 强调文字颜色 5 Selection.TypeText Text:=数据1 Selection.MoveRight Unit:=wdCell Selection.TypeText Text:=数据2 Selection.MoveRight Unit:=wdCell Selection.TypeText Text:=数据3 Selection.MoveRight Unit:=wdCell Selection.TypeText Text:=数据4End Sub开源测试工具Katalon Recorder 安装过程安装过程 在“ ”注册用户后下载自己需要的版本，也可以在谷歌应用商店或者通过火狐浏览器插件下载和安装Katalon IDE。安装完成后，在火狐浏览器的右上角出现Katalon Recorder的快捷图标。第22页/共100页图8-3 Katalon Recorder IDE的界面第23页/共100页使用Katalon Recorder IDE录制一个简单的自动化测试脚本。 新建一个测试用例“Test Case Demo”，然后单击“Record”按钮开始录制。 在Firefox浏览器中输入网址“”，在打开的页面中选择出现的文字“XXXX年XX月XX日 星期X ”，单击鼠标右键后从弹出的菜单中选“Katalon Recorder”“verifyText”这样就增加了一个验证点。第24页/共100页 采用相同的方法，图8-4为测试运行结果。第25页/共100页 测试脚本由一个“open”和两个“verifyText”命令组成。 如图8-4所示。第一个验证点通过，相应的命令变为绿色；第二个验证点失败，命令窗口中的命令文字变为红色，测试日志窗口中也以红色文字提示“error did not match”。 结论：第二个验证点的秒时间数字在不断变化，与最初记录的预期结果不同，因此验证失败，由此也说明测试工具可以自动发现非常微小的结果偏差。第26页/共100页 可以将测试用例导出为各种常用语言的脚本。单击“Export”按钮，在下拉框中选择希望的脚本语言即可。这样就节省了测试人员编写复杂测试脚本的工作量，只需要在录制好的脚本基础上进行修改即可。如图8-5测试脚本的输出。第27页/共100页图8-5 测试脚本的输出第28页/共100页 总结 自动化测试的一般过程是首先启动被测软件和相应的测试工具，通过测试工具录制软件操作过程并且插入验证点，对录制好的脚本进行必要的调试，然后保存脚本作为测试用例。执行测试时，调用自动化测试脚本，通过脚本操纵被测软件执行，验证测试结果，根据测试工具的执行日志生成软件缺陷报告。第29页/共100页8.2.2 代码分析静态分析工具FindBugs 静态分析工具FindBugs可以检查和分析Java代码类或者Jar文件，在不实际运行程序的情况对Java源程序进行静态测试。将程序代码与定义的代码规则或缺陷模式进行对比可以发现很多种软件缺陷。第30页/共100页FindBugs常用的规则主要可以分为以下几类。 Correctness（正确性）。代码可能在某些方面不正确。 Bad practice（不良实践）。源程序明确违反规定的编码规范。 Performance（性能）。可能导致软件性能不佳的代码。第31页/共100页 Multithreaded correctness（多线程的正确性）。多线程编程时可能导致错误的代码。 Dodgy（不可靠）。具有潜在危险的代码。 通过上述规则，FindBugs能够帮助开发人员发现源程序中存在的代码缺陷或隐患，并且提供了修改意见供开发人员参考，大大提高了Code Review的效率与质量。第32页/共100页 图8-6 Eclipse中FindBugs的规则配置页面第33页/共100页对象识别 功能测试工具需要和用户界面打交道，就需要能操作、控制用户界面上各种对象，所以大部分功能测试工具是基于GUI对象识别技术来实现自动化测试的。对象的识别，就是获得这个对象的类别、名称、属性的值。第34页/共100页1、类、对象、属性和方法 打开网页http:/后可以看到如图8-7所示的页面部分，图中包含以下一些典型的GUI对象。第35页/共100页对于图8-7所示对象的解释 链接SIGN-ON、REGISTER、SUPPORT和CONTACT是LINK类的对象，对象SIGN-ON具有诸如“href”和“text”这样的属性，通过这些属性用户可以进入特定的网页。第36页/共100页 “User Name”和“Password”是WebEdit编辑框类的对象。对象“User Name”具有诸如“name”和“max-length”这样的属性，通过这些属性可以在给定Web页面中唯一识别该对象。对象“User Name”具有一个方法（method）集合，通过方法实现在编辑框中输入文本。 基本上，你所看到的应用程序的所有GUI元素都是特定类的对象。 第37页/共100页 UFT有如下一些默认的“add-ins”，可以增加更多的扩展“add-ins”以支持不同类型的应用程序。支持的应用程序包括: ActiveX Mobile UI Automation Visual Basic Web第38页/共100页图8-8 UFT中的对象识别对话框第39页/共100页 UFT中的软件单元“Object Spy”能够具体识别一个特定对象的属性、属性的值和方法。 图8-9是例子中“SIGN-ON”对象的属性和操作，这里的操作（Operations）也就是对象的方法（Methods）。第40页/共100页图8-9 通过Object Spy识别对象属性与方法第41页/共100页2、对象库 对象库在对象识别和功能测试中的作用图8-10 测试设计与执行流程中的对象库第42页/共100页“测试设计”和“测试执行”两个阶段 上述两种测试阶段对象的含义如下。 运行时对象（Run-time Objects）是被测软件的实际对象，在执行测试时与测试对象的属性进行对比匹配。 测试对象（Test Objects）存储在对象库中，包含一系列的对象属性。UFT通过学习GUI对象的属性以及属性值来产生测试对象。第43页/共100页对象库的测试原理 运行脚本时，UFT会根据对象库中测试对象的特征属性描述来查找运行时对象，然后对比对象属性。如果一致，进行后续操作；如果不一致，则提示对象无法识别。第44页/共100页图8-11 UFT中对象库的管理界面第45页/共100页3、UFT对象识别的完整过程（1 1）描述属性（描述属性（Description Properties） 在第一个阶段，UFT组合使用强制（Mandatory）属性和辅助（Assistive）属性完成对象识别，上述两种属性的组合被称为已学习描述（Learned Description），有时也称为描述属性（Description Properties）或测试对象描述（Test Object Description）。第46页/共100页图8-12 UFT对象识别过程第47页/共100页（2）可视关系标识符（Visual Relation Identifiers，VRI） 在这一阶段，UFT利用可视关系标识符VRI完成对象识别，VRI定义了对象与其邻居对象的相对位置。VRI是UFT中新增的对象识别机制。第48页/共100页如图8-13（a）所示，一个Web页面上有两个“Submit”按钮，因为不管以后这些按钮出现在网页的什么位置，“OK”按钮总是会出现在第一个“Submit”按钮的左边。所以，即使在以后的测试过程中，这些按钮在网页中的位置相反（如图8-13（b）所示），UFT仍然能够识别出第一个“Submit”按钮。第49页/共100页图8-13 基于可视关系标识符的对象识别（3）智能识别（Smart Identification） 在这一阶段，UFT组合使用一个测试对象类的基本属性（Base Filter Properties）和一些可选属性（Optional Filter Properties）来完成对象识别。 UFT利用基本属性产生候选匹配对象的列表，然后通过逐项对比可选属性，缩小候选匹配对象的范围，直到识别出唯一的对象。第50页/共100页图8-14 智能识别中基本属性和可选属性的配置智能识别的配置第51页/共100页（4）顺序标识符（Ordinal Identifier） 顺序标识符是用来标识一个对象相对于其它对象的顺序的数字值。当UFT发现有多个对象具有相同的属性值而无法对它们进行唯一识别时，可以通过顺序标识符将它们区别开来。第52页/共100页三种类型的顺序标识符 Index 。识别对象时，UFT 可以将值分配给测试对象的Index 属性以唯一地标识对象。 Location 。识别对象时，UFT 可以将值分配给测试对象的Location 属性以唯一地标识对象。 CreationTime。仅适用于Browser对象。识别浏览器对象时，UFT将值分配给CreationTime标识属性。第53页/共100页8.2.4 自动化测试框架1、自动化测试框架的基本含义 框架提供了软件系统整体或部分的可重用设计，是可以被开发者直接使用和扩展定制的应用骨架。软件重用从模块和对象重用发展到构件和框架重用，重用粒度不断增大。 自动化测试框架是一种特殊类型的框架。第54页/共100页 从广义上来讲： 自动化测试框架，是一组自动化测试的规范和测试脚本的基础代码，以及测试思想、方法和惯例的集合。 从狭义上来讲： 自动化测试框架是由一个或多个自动化测试基础模块、自动化测试管理模块、自动化测试统计模块等组成的工具集合。第55页/共100页一个典型的自动化测试框架图8-15 自动化测试框架的基本模块包括测试用例管理模块、自动化执行控制器、报表生成模块和测试日志模块第56页/共100页各模块的功能 测试用例管理模块包括用例的添加、修改、删除等基本功能，也包括用例编写模式、测试数据管理、可复用的测试用例库管理等功能。 自动运行控制器主要负责以什么方式执行用例。第57页/共100页 报表生成模块主要负责用例执行以后生成报表，报表一般为HTML格式。 日志模块主要用来记录用例的执行情况，以便于高效地追踪用例执行情况和分析用例失败信息。第58页/共100页2、自动化测试脚本类型（1）线性脚本 线性脚本是由测试工具录制并记录软件操作过程和输入数据所形成的脚本，通过回放来重复人工操作的过程，一般用于简单测试或者作为基本脚本供修改后进一步使用。第59页/共100页用于测试计算器的加法功能线性脚本示例第60页/共100页（2）结构化脚本 结构化脚本类似于结构化程序，具有顺序、分支、循环等逻辑结构。 结构化脚本能够体现模块化与库函数的思想。模块化后的脚本可以支持分层的脚本结构，实现脚本之间的相互调用。可以被多个测试用例使用的脚本有时也被称为共享脚本。第61页/共100页通过UFT检查Mercury Tours站点（http:/www.newtours. ）中是否存在User Name编辑框第62页/共100页（3）数据驱动脚本 数据驱动脚本将测试数据和具体测试执行过程进行分离，将测试输入数据存储在独立的数据文件或数据库中。 简单来说就是执行相同的测试步骤，使用不同的测试数据。第63页/共100页例如，测试软件登录功能时的数据驱动脚本如下第64页/共100页（4）关键字驱动脚本 关键字驱动脚本用一系列关键字指定要执行的测试任务。关键字对应封装的业务逻辑，各种基本操作由关键字代表的函数完成。第65页/共100页图8-16是一个通过Katalon Recorder生成的关键字驱动脚本，用于测试Mercury Tours站点的登录功能。第66页/共100页3、自动化测试框架类型 测试脚本模块化框架 测试库架构框架 数据驱动测试框架 关键字驱动或表驱动测试框架 混合测试自动化框架第67页/共100页（1）测试脚本模块化框架（The Test Script Modularity Framework） 测试脚本模块化框架的特点是将被测程序分解为多个逻辑模块，对每个模块都创建一个小而独立的测试脚本，测试脚本中包含了各功能点的控件识别和业务逻辑操作。第68页/共100页（2）测试库架构框架（The Test Library Architecture Framework） 这种框架与脚本模块化框架类似，同样能够产生高度模块化的测试用例。不同的是，被测程序被分解为过程和函数，而不是测试脚本。所有测试用例中的常用功能可以作为函数被存储在一个公共测试库中（例如SQABasic Libraries、APIs、DLLs等）。第69页/共100页（3）数据驱动测试框架（The Data-Driven Testing Framework） 当使用不同的输入数据集多次测试相同功能时，不应当以硬编码的形式在测试脚本中大量嵌入这些测试数据，而是应当将其保存在XML文件、CSV文件、数据库等外部数据源中。测试执行时，通过脚本代码将测试数据载入到脚本变量中。第70页/共100页（4）关键字驱动或表驱动测试框架（The Keyword-Driven or Table-Driven Testing Framework） 关键字驱动测试框架源于数据驱动测试框架。在数据驱动测试框架中，数据文件中只包含测试数据；而在关键字驱动框架中，数据文件中存储的是关键字和测试数据。第71页/共100页（5）混合测试自动化框架（Hybrid Test Automation Framework） 自动化测试框架的主要目的是将不同层次的对象和逻辑进行抽象、分离与封装，以便于把程序变更所引起的测试用例修改和维护工作量减少到最小。因此，实际工作中一般用到的自动化测试框架是一个混合框架。第72页/共100页图8-17 混合测试自动化框架第73页/共100页8.3 测试工具的分类与选择8.3.1 软件测试工具分类1、商业测试工具 专业开发软件测试工具的公司有很多，其中以MI（Mercury Interactive）、IBM Rational和Micro Focus最为著名。第74页/共100页（1）MI的主要测试工具 MI开发的测试工具最著名的是LoadRunner、UFTQTPWinRunner和Quality Center Test Director。LoadRunner是测试人员都熟知的性能测试工具，能够满足企业级应用，实现对C/S和B/S结构软件系统的性能测试。第75页/共100页UFTQTPWinRunner三者都是MI开发的功能测试工具。Quality Center Test Director是MI开发的测试管理工具。Test Director（简称TD）是一个基于Web的测试管理系统能够完成需求管理、测试计划管理、测试用例管理和缺陷跟踪管理。第76页/共100页（2）IBM Rational的主要测试工具IBM Rational公司的产品涵盖了需求管理、软件建模、配置管理等全方位的软件工程CASE（Computer Assisted Software Engineering）工具，其产品的一个典型优势是几乎所有的工具都支持跨平台安装。第77页/共100页IBM Rational主要有以下一些测试工具。功能测试工具可分为手动测试工具Rational Manual Tester和自动测试工具Rational Functional Tester、Rational Robot。性能能测试工具包括Rational Performance Tester和Rational Robot。Rational Robot包括了功能测试和性能测试。第78页/共100页白盒测试工具包括Rational PurifyPlus和Rational Test RealTime。测试管理工具包括Rational TestManager和Rational ClearQuest。第79页/共100页（3）Micro Focus的主要测试工具 英国Micro Focus公司的测试工具很多源自于著名的Compuware公司和Segue公司。 Compuware公司黑盒测试工具集QACenter里包括功能功能测试工具QARun、性能测试工具QALoad和测试管理工具QADirector。第80页/共100页 Segue公司是一个专业开发测试工具的厂商，其产品SilkTest、SilkPerformer完全可以和Mercury QTP、Loadrunner媲美。第81页/共100页表8-1 主要的商业测试工具第82页/共100页功能测试性能测试白盒测试测试管理HP MercuryUFTQTPUFTQTPLoadRunnerLoadRunner Test Director,Quality CenterQuality CenterIBM RationalRational Manual Tester, Rational Functional Tester, Rational RobotRational Performance Tester, Rational RobotRational PurifyPlus/PureCoverage, Rational Test RealTimeRational TestManager, Rational ClearQuestMicro Focus(Compuware,Segue)QARun, Micro Focus TestPartner, Micro Focus SilkTestQALoad, Micro Focus SilkPerformerBoundsCheckerTrueCoverageDevPartnerQADirector, TrackRecordTelelogic LogiscopeLogiscope ParasoftWebKing C+Test, JTest,.TEST, SOA Test Programming Research QAC/ C+/J RadviewWebFTWebLoad TestView ManagerMicrosoft ACT(Application Center Test)IntelliTest2、开源测试工具 白盒测试工具 功能测试工具 性能测试工具 测试管理工具第83页/共100页（1）白盒测试工具针对不同的程序语言有着不同的白盒测试工具，一般有以下几种测试工具。 例如JUnit（Java）、CppUnit（C+）、DotUnit（.Net）、HtmlUnit（HTML）、JsUnit（JavaScript）、PHPUnit（PHP）、PerlUnit（Pear）等。第84页/共100页（2）功能测试工具 AutoIT用于测试基于Windows GUI操作的软件。 Ruby+Watir组合是近年非常流行的全免费自动化测试框架可以实现对Web应用程序的自动化测试 。 Selenium支持Ruby、Java、Perl、Python等脚本语言，目前在国内外日益流行。第85页/共100页（3）性能测试工具 JMeter最初只是测试Web应用，目前已经能够支持HTTP/HTTPS、SOAP、JDBC、LDAP、JMS等。 TestMaker可以和Seleinium、SoapUI集成，TestMarker只是更好地调度、监控和管理测试的过程，监控系统的性能指标，获得测试结果。第86页/共100页 ApacheBench能同时模拟多个并发请求，专门用于Web服务器的基准测试。 Grinder基于HTTP的测试可以由浏览器来记录整个测试过程。 Siege是一个压力测试和评测工具，用于Web开发。第87页/共100页（4）测试管理工具测试管理工具开发难度较小，因此开源免费的产品很多，下面是一些常见工具。 Bugzilla可与CVS进行无缝集成，当前最成熟。 Mantis是一款Web缺陷管理工具，国内使用较多。 BugFree是一款轻量级的Web缺陷管理工具。 TestLink可对测试需求、计划、用例、执行、缺陷报告等进行完整管理。第88页/共100页8.3.2 当前最好的自动化测试工具2017-2018世界质量报告中给出了世界排名前10的自动化测试工具。其中既包含了免费工具也包含了商业工具。（1）Selenium（开源）（2）Katalon Studio（免费）（3）UFT（商业）（4）Watir（开源）（5）IBM Rational Functional Tester（商业）第89页/共100页（6）TestComplete（商业）（7）TestPlant eggPlant（商业）（8）Tricentis Tosca（商业）（9）Ranorex（商业）（10）Robot Framework（开源）第90页/共100页8.3.3 如何选择软件测试工具选择软件测试工具应该注意的一些因素（1）根据具体测试需求比较工具的功能、价格和服务。（2）考虑引入测试工具的连续性和一致性。（3）分析测试工具对各种操作系统平台的兼容性。（4）评估测试工具与其它相关软件产品的集成能力。（5）考察测试工具是否有强大的报表统计功能。第91页/共100页 8.4 自动化测试的引入8.4.1 引入过程中存在的问题（1）盲目迷信自动化测试 虽然自动化测试能够带来非常明显的收益，但是也具有一定的局限性。（2）片面追求全面的自动化测试 测试的全面自动化意味着所有可以自动完成的测试任务都通过测试工具或程序来自动执行。然而，全面的测试自动化目前还仅仅是一个理想目标。第92页/共100页（3）盲目引入测试工具 软件企业各有其特点，测试工具自身的特点和适用性也各不相同。因此，必须在综合考量与评估之后才能合理选择测试工具。（4）忽视测试脚本的质量问题 测试工具主要通过测试脚本完成自动化测试，测试脚本本身就是程序，因此需要首先保证测试脚本本身的质量。第93页/共100页（5）缺乏专业的测试人员 专业的测试工具和软硬件测试环境配置固然是成功完成自动化测试的必要条件，但是掌握良好测试技术、具有丰富测试经验的测试人员才是决定性因素。（6）没有考虑自动化测试的开发和维护成本 自动化测试在提高测试效率的同时也会造成测试开发和维护成本的提高。第94页/共100页8.4.2 自动化测试的引入风险分析（1）成本风险 自动化测试的成本包括测试人员、测试工具、硬件设备以及测试准备、开发、执行和维护的费用等。（2）切入点的风险 自动化测试的引入应当由简到难、由点到面，需要根据软件企业自身产品的特点找准实施自动化测试的切入点。第95页/共100页（3）切入方式的风险 在引入自动化测试时不能贪多求全，需要综合应用自动化测试与手工测试，对自动化测试在整个测试活动中的比例进行合理规划。（4）时间风险 测试项目需要预留较为宽松的测试时间以应对首次实施自动化测试所带来的冲击。需要合理估计实施自动化测试所需要的时间，避免仓促实施影响测试效果。第96页/共100页（5）开发和测试流程以及设计变更的风险 在实施自动化测试后，测试团队甚至整个开发组织为了适应测试工具的应用，原有开发和测试工作流程或多或少的会发生改变，测试用例设计方法乃至软件设计也会有相应的变化。因此，需要分析流程和设计变更的程度，尽可能克服变更中可能存在的困难。第97页/共100页3）适合引入自动化测试的软件项目当一个软件项目具有以下特征时，比较适合引入自动化测试。（1）程序已经基本稳定，不再会发生频繁的变动（2）用户界面稳定（3）项目的进度压力不大第98页/共100页（4）测试脚本的可重用性比较高（5）回归测试的频率高、数量多（6）软件产品有较高的性能要求（7）组合遍历型的测试第99页/共100页（8）持续集成测试（9）测试流程和测试用例设计规范（10）资源充足第100页/共100页