详情
本书第一部分首先介绍软件功能测试中的两大关键理念：数据驱动测试和关键字测试；第二部分围绕这两大理念全面介绍了经典测试工具UFT11.5（QTP的最新版本）的功能和使用方法，并结合实践讲解具体的使用方法及实现数据驱动测试和关键字测试的方法；第三部分，在UFT的基础上引入几个高阶工具，讲解安全测评中的Fuzzing测试。
博为峰旗下
软件测试网作品系列
Practices in Advanced Automated Functional Software Testing
51Testing软件测试网 组编
北京
编委
王威（具有多年软件开发经验和软件测试工作经验，对产品测试的方法和管理流程有深刻的认识，51Testing软件测试培训高级讲师）
王琰（具有丰富的通信终端产品的测试以及管理工作经验，51Testing 软件测试培训高级讲师）
朴春龙（Mercury认证CPC，自动化测试专家，51Testing软件测试培训高级讲师）
邓强（具有丰富的软件系统测试工作经验，对功能性测试、自动化测试、性能测试及测试框架均有深入的研究，51Testing软件测试培训高级讲师）
周峰（信息产业部认证系统分析员，51Testing软件测试培训高级讲师）
周春江（具有多年通信协议和通信终端设备的测试工作经验，51Testing软件测试培训高级讲师）
商莉（多年从事软件开发、软件测试及质量保证方面的管理工作，51Testing 软件测试培训高级讲师）
宋光照（具有深厚的开源软件测试实践经验，擅长嵌入式测试，51Testing软件测试培训高级讲师）
刘德宝（具有多年软件测试及培训经验，参与门户网站、移动BOSS等多个大型软件测试项目，在自动化测试技术方面具有丰富的项目经验，51Testing软件测试培训高级讲师）
编辑部成员
张晓晓 严代丽
我是一名在软件研发与测试产业中工作超过15年的从业者，在一个偶然的机会中从软件研发领域转入软件测评领域，并承担起了软件测试领域的教学和研究工作，常常感叹人生不是能计划出细节的，生活充满了迷一样的色彩与神奇。但这样的感悟似乎用在软件测试产业中也是很恰当的，软件测试产业也拥有着同样的迷一样的色彩！
软件测试产业的诞生时间就是个迷，目前没有人能说清楚软件测试产业具体是在哪一天诞生的。总的说来软件测试产业是一个既古老又年轻的行业，说它古老，是说它跟软件研发产业一起诞生，20世纪50年代就有了；但是又可以说它无比年轻，直到20世纪80年代末软件工程学科确立（软件研发才正式有了生命周期模型与阶段），软件测试才作为一个软件工程过程有了独立的价值与内涵，成为了一个独立领域。随后软件研发产业得到了快速发展，日益成为国民经济中不可或缺的要素，软件测试也日益发展成一个独立的产业，到今天已经逐渐发展成为了几乎与软件研发并驾齐驱的一个产业领域了，没有人怀疑缺乏了测试环节的软件研发是残缺品，风险多多。所以，软测产业的诞生与发展到底只有一二十年的历史，还是覆盖了整个软件产业发展的历史，这是个说不清楚的迷。
软件测试的迷样色彩远不止诞生历史这样一点，软件测试是一个同时被尊重和贬低的领域，充满了矛盾。从软件测试领域的重要性来说，但凡是个严肃意义上的软件产业从业者，大家对软件测试的重要意义是百分百地认可和尊重的，说到软件测试的时候不乏溢美之词；但是任何一个严肃意义上的软件从业者也不能否定目前软件测试领域的基本态势是做不了软件研发的人员做软件测试，这个产业的实践实际上是在贬低软件测试的重要性。这个矛盾以及为什么形成了这样一个矛盾局面，不是三言两语可以说清楚的，软测产业的混沌与迷在我进入软件测试领域的这些年也还没有看到明显的改变迹象。
再谈一谈软件测试的实践。近些年来软件测试领域涌现了大量的技术和工具，从测试核心支撑技术到辅助监控分析技术，不可谓不全面，软件测试的实践已经变得简单轻松起来，但是同时我们也发现，软件测试在最基本的测试实践上也还存在不少问题，比如在功能自动化测试领域——这个在软件测试产业里公认的最成熟的领域——依然还存在重大问题，有很多软件全部或部分的功能测试无法进行自动化测试，进而造成了测试必须后退到手工的完全原始的模式进行（这也是我编写本书的原由）。软件测试产业的技术进步与待解决的问题总是同样多，这样的一个局面，迷惑了软件产业的多数从业者，大家时而对软件测试充满了信心，觉得软件测试可以解决很多问题；时而对软件测试充满了困惑，觉得为什么在如此基础的问题上，软件测试都还如此不成熟而不为所用。软件测试产业在核心的实践环节上也具有着迷一样的色彩。
作为一名资深的软件研发人员和一个软件测试从业人员，我对以上几点迷局的看法是这样的：第一，还没有消除人为认知上的一些对软件测试产业相对肤浅的歧视，这主要来源于对软件测试中简单的手工测试的印象；第二，软件测试技术的发展还没有成熟完备到可以解决由软件研发所产生的全部问题，很不幸的是可能软件测试从根本上就有些问题不能突破，毕竟软件测试是逆向过程，逆向过程一般不能还原到正向的全部过程。
在这段文字中我使用了“迷局”这样的字眼，倾向似乎悲观，但我确实不是一个悲观主义者，我认为软件测试产业确实存在着这样的迷局或者说矛盾局面，作为从业者我们否定和美化这样的局面是没有意义的，只有通过从业人员不断地发挥专业精神获得行业和产业的认可与尊敬，这些迷局才能真正清澈起来，这是我们软件测试领域的进步动力也是我们大家作为软件测试从业者义不容辞的责任！
周焕来
近些年来软件测试领域涌现了大量的技术和工具，从测试核心支撑技术到辅助监控分析技术，这使软件测试的实践已经变得简单轻松起来，但是，我们也发现，软件测试在最基本的测试实践上也还存在不少问题，比如在功能自动化测试领域——这个在软件测试产业里公认的最成熟的领域——依然还存在重大问题，有很多软件全部或部分的功能测试无法进行自动化测试，进而造成了测试必须后退到手工的、完全原始的模式进行（这也是我编写本书的初衷）。软件测试产业的技术进步与待解决的问题总是同样多，这样的一个局面，迷惑了软件产业的多数从业者，大家时而对软件测试充满了信心，觉得软件测试可以解决很多问题；时而对软件测试充满了困惑，觉得为什么在如此基础的问题上，软件测试都还如此不成熟而不为所用。
目前，同类书籍主要围绕QTP的使用展开，本书主要围绕QTP脚本开发展开，不局限在 QTP 工具本身。本书用到了 HP QTP 工具的最新版本 UFT 11.5 的资料，另外，立足于完整的功能测试，引入了Peach等非常见功能测试工具资料，建立了一套完整的、跨平台的功能测评体系。
本书的主要内容为：首先介绍软件功能测试中的两大关键理念：数据驱动测试和关键字测试；然后围绕这两大理念全面介绍了经典测试工具UFT11.5（QTP的最新版本）的功能和使用方法，并结合实践讲解具体的使用方法及实现数据驱动测试和关键字测试的方法；最后，在UFT的基础上引入几个高阶工具，并讲解了安全测试中的Fuzzing测试，并引入到功能自动化测试领域，补充常用功能测试工具在非界面测试和非Windows平台测试方面的不足。
本书适合软件测试从业者以及大专院校相关专业的师生使用，也可以作为相关培训学校的教材。
编辑联系邮箱：zhangtao@ptpress.com.cn。
面向 GUI图形用户界面的功能测试是功能测试的基础问题，也是功能测试的核心问题，HP UFT 11.5 为测试人员提供了丰富的从基础到高阶的测试选择。
第 4 章 Unified Functional Testing 介绍
第 5 章 GUI 的自动化测试方法
第 6 章 数据驱动测试
第 7 章 关键字驱动测试
数据驱动的测试方法要解决的核心问题是把数据从测试脚本中分离出来，从而实现测试脚本的参数化。
自动化测试对录制和编辑好的测试步骤进行回放，这种是线性的自动化测试方式，其缺点是明显的，就是其测试覆盖面比较低。测试回放的只是录制时做出的界面操作，以及输入的测试数据，或者是脚本编辑时指定的界面操作和测试数据。
如何让测试脚本执行时，不仅仅局限于测试录制或编辑时的测试数据呢？数据驱动的测试方式是解决这个问题的最佳方案。数据驱动测试把测试脚本中的测试数据提取出来，存储到外部文件或数据库中，在测试过程中，从文件动态读入测试数据。
注意
如果希望测试的覆盖面更广，或者让测试脚本能适应不同的变化情况，则需要进行测试脚本的参数化，采用数据驱动的测试脚本开发方式。
通常，数据驱动测试按以下步骤进行。
（1）参数化测试步骤的数据，绑定到数据表格中的某个字段。
（2）编辑数据表格，在表格中编辑多行测试数据（取决于测试用例以及测试覆盖率的需要）。
（3）设置迭代次数，选择数据行，运行测试脚本每次迭代从中选择一行数据。
提供了一些功能特性，让这些步骤的实现过程得以简化。例如，使用“数据”视图来编辑和存储参数，如图6-1所示。
另外，还提供“Data Driver 向导”，用于协助测试员快速查找和定位需要进行参数化的对象，并使用向导进行一步一步的参数化过程。
在UFT中可以通过把测试脚本中固定的值替换成参数的方式来扩展测试脚本，这个过程也叫参数化测试，能有效地提高测试的灵活性。
可以通过参数化的方式，从外部数据源或数据产生器读取测试数据，从而扩大测试的覆盖面，提高测试的灵活性。
在 UFT 中，可以使用多种方式来对测试脚本进行参数化，数据表参数化（Data Table Parameters）是其中一种重要的方式，还有环境变量参数化（Environment Variable Parameters）、随机数参数化（Random Number Parameters）等。
下面以自带的“Flight”程序为例，介绍如何对测试脚本进行参数化。假设在名为“航班预订”的订票界面中，输入航班信息后，插入订票记录，然后希望重新打开该记录，检查航班信息中的终点的设置是否正确，录制的测试脚本如图6-2所示。
提示
对于这样一个测试脚本，仅能检查特定的航班订票记录的正确性，如果希望测试脚本对多个航班订票记录的正确性都能检查，则需要进行必要的参数化。
首先，把测试步骤中的输入数据进行参数化，例如航班日期、航班始点和终点等信息。下面，以“输入终点”的测试步骤的参数化过程为例，介绍如何在关键字视图中对测试脚本进行参数化。
（1）选择“终点：”所在的测试步骤行，单击“值”列所在的单元格，如图6-3所示。
（2）单击单元格旁边的“<#>”按钮，或按快捷键“Ctrl+F11”，则出现如图6-4 所示的界面。
提示
在这个界面中，选择“参数”，在旁边的下拉框中选择“Data Table”，在“名称”中输入参数名，也可接受默认名，在“数据表中的位置”中可以选择“全局表”，也可以选择“当前操作表（本地）（U）”，它们的区别是参数存储的位置不同。
（3）单击“确定”按钮，在关键字视图中可看到，“值”值已经被参数化，替换成了如图6-5所示。
（4）这时，选择菜单“视图→数据”，则可看到如图6-6所示的界面。
可看到，在“p_Item”列中有一个默认数据“Frankfurt”，这是参数化之前录制的脚本中的常量，可以在“p_Item”列中继续添加更多的测试数据。
提示
可以双击修改“p_Item”列名，让其可读性更强，例如，改成“FlyTo”。
（5）把其他几个数据也参数化，如图6-7所示。
运行时，就会从如图6-8 所示的数据表格中提取数据来对测试过程中的各项输入进行参数化。
对于选择航班这个测试步骤的参数化来说会有所不同，因为航班会跟随所选择的起点和终点而变化，因此，需要做特殊的处理。如下列代码所示。
先通过访问 Get ItemsCount 属性，获取航班列表的行数，然后使用 RandomNumber随机选取其中一项。最后再通过 Select 方法选择航班。参数化后的测试步骤如图6-9所示。
提示
使用随机数也是测试脚本参数化的一种重要方法，在测试代码中，可用RandomNumber来实现，在关键字视图编辑的界面如图6-10所示，其效果与在脚本中直接编辑是一样的。
测试脚本的最后一个测试步骤是检查订票记录中的航班终点是否正确，同样需要进行适当的参数化，具体方法如下。
（1）单击检查点所在测试步骤的“值”列中的单元格，如图6-11所示。
（2）单击旁边的按钮，则出现如图6-12所示的界面。
（3）在“配置值”中选择“参数”后，可单击“确定”按钮接收默认的设置，也可单击旁边的编辑按钮，在如图6-13所示的界面中，进行参数化的详细设置。
在“参数”中，选择“Data Table”；可在“名称”修改参数名，或接受默认的命名，产生如图6-14所示的数据列，也可以选择“FlyTo”，因为检查点所指的航班终点得到的预期值应该与测试步骤中选择航班终点时的输入数据一致，否则认为错误。
把测试步骤和检查点的参数化工作都完成后，可得到如图6-15所示的测试步骤。
运行这个测试脚本之前，还要做一些必要的设置，选择菜单“文件→设置”，出现如图6-16所示的测试设置界面，切换到“运行”页，在“数据表迭代”中，可设置数据表格的迭代方式。
运行，得到测试结果。
对于重复使用的测试用例，可以转换成公共用例，适当参数化后，可被其他测试用例调用。可以把Action的输入适当参数化，转换成可重用的测试步骤。
对“Flight”程序中的登录模块的测试步骤是在执行其他测试步骤之前都要经过的测试步骤，因此，有“潜力”成为一个可重用的Action。对于如图6-17所示的测试步骤，可以进一步参数化后，成为可重用的测试步骤，被其他Action调用。
选择“Action1”所在的行，然后单击鼠标右键，在弹出的菜单中选择菜单“操作属性”，则出现如图6-18所示的界面。
在“名称”中输入新的Action名称，例如“登录_Action”，在“描述”中输入对Action的描述信息，如图6-19所示。
注意
把“可重用操作（R）”勾选上，表示该Action为可重用的测试步骤，是可被其他Action调用的测试步骤。
切换到“参数”页，如图6-20所示。单击“+”按钮，添加调用Action需要输入的参数名和类型。
提示
在这里，“登录_Action”需要两个参数，其中“AgentName”表示代理机构登录名，“密码”表示登录密码。
添加完参数后，回到关键字视图，选择“输入代理机构名”所在的测试步骤，单击“值”列的单元格旁边的“<#>”按钮，出现如图6-21所示的界面。
在“参数（P）”中，选择“测试/操作参数”，然后，选择刚才编辑好的参数“AgentName”，单击“确定”按钮。重复这个步骤，为“输入登录密码”的测试步骤设置参数，得到如图6-22所示的测试步骤。
完成登录_Action 的参数化后，就可以在其他 Action 中调用这个 Action，方法是在Action的测试步骤中，选择菜单“插入→对现有操作的调用”插入现有的Action，如图6-23所示。
在这个界面的“从测试：”中选择“<当前测试>”，在“Action”中选择“Login_Action”，单击“确定”按钮后，即可插入对“登录_Action”测试步骤的引用，如图6-24所示。
选中“登录_Action”所在的行，单击鼠标右键，在弹出的菜单中选择菜单“操作属性”，出现如图6-25所示的界面。
在“参数值”页中，为每一个参数设置输入的参数值，也可以单击“值”列旁边的“<#>”按钮，为输入绑定到 Data Table 中的数据。单击“确定”后，可在专家视图看到如图6-26所示的测试代码。
该测试代码使用了RunAction方法来调用“Login_Action”，输入的第一个参数值和第二个参数值都为“MERCURY”。测试脚本的运行结果如图6-27 所示，可看到“Login_Action”被成功地调用，测试结果中也列出了调用“Login_Action”所输入的参数值。
除了前面所讲的几种参数化测试的方式外，还可以使用环境变量来进行测试的参数化。下面介绍如何使用环境变量来参数化测试步骤。
在使用环境变量之前，需要定义好环境变量，具体方法如下。
（1）选择菜单“文件→设置”，出现如图6-28所示的界面。
（2）在这个界面中，切换到“环境”页，在“变量类型”中选择“用户定义”，然后，单击旁边的“+”按钮，在如图6-29所示的界面中，定义环境变量名和输入的值。
（3）重复这个步骤，定义“密码”的环境变量，得到如图6-30所示的结果。
定义好环境变量并设置好其值之后，就可以在测试步骤中使用该环境变量。方法如下：
（1）在关键字视图中，定位到测试步骤的“值”列，如图6-31所示。
（2）单击旁边的“<#>”按钮，出现如图6-32所示的界面。
提示
在界面中，选择“参数（P）”，并在下拉框中选择“Environment”，在“名称（N）”中选择“AgentName”，在“值（V）”中输入对应的值。
（3）重复这个步骤，设置“输入登录密码”的测试步骤所对应的环境变量，如图6-33所示。
设置完后，可得到如图6-34所示的测试步骤。
这样，在运行测试脚本时，就会读取测试步骤所绑定的环境变量值，来执行相应的数据输入动作。
选择菜单“文件→设置”，在如图所示的界面中，单击“导出（X）”按钮，可把当前定义的环境变量导出到XML文件中，如图6-35所示。
导出后的XML文件如图6-36所示。可看到，<Variable>和</Variable>之间是一个个定义好的环境变量，包括变量名和变量值。
对于导出的XML文件，可以再次导入，如图6-37所示。
也可以在测试脚本中编写代码来加载，例如，下面的脚本在执行界面的测试步骤之前，先加载D:\\C3\ParameterizingTest3\Env目录中的某个环境变量文件。
Systemutil.Run "C:\Program Files\HP\Unified FunctionalTesting\samples\flight\app\flight4a.exe" ' 启动flight程序"
Dialog（"登录"）.WinEdit（"代理名称:"）.Set Environment（"AgentName"）@@hightlight id_;_3475436_;_script infofile_;_ZIP::ssf1.xml_;_
Dialog（"登录"）.WinEdit（"密码:"）.Type Environment（"密码"）@@ hightlight id_;_3868630_;_script infofile_;_ZIP::ssf2.xml_;_
Dialog（"登录"）.WinButton（"确定"）.Click
为了简化测试脚本参数化的过程，还提供了名为“Data Driver”的功能，可自动检测脚本中可能需要进行参数化的变量。
“数据驱动”可以帮助测试人员快速找到需要参数化的测试对象、检查点的数据。例如，对于如图6-38所示的录制脚本，选择菜单“工具→数据驱动”，出现如图6-39所示的界面。
在这个界面中，列出了测试步骤中所有可能需要进行参数化的变量。
单击“参数化”按钮，出现如图6-40所示的数据驱动向导。
单击“下一步”按钮，则出现如图6-41所示的界面。
在这个界面中的左边窗口，定位到测试步骤所操作的界面控件，在右边显示参数化的名称和数据，单击“编辑”按钮，可在如图6-42所示的界面中进一步设置参数。
单击“确定”按钮，回到向导界面，单击“下一步”按钮，则出现如图6-43所示的界面，表明测试步骤的参数设置完成。其他测试步骤也可按类似的方式一步步地完成参数化。
执行数据驱测试前要先定义测试所需的数据源，数据驱动测试的数据源除了UFT自带的DataTable之外，可以是文本文件、Excel文件、数据库表格等。本小节主要列举了以文本文件或者以Excel文件为代表的文件数据源的数据驱动测试实例。
在本实例中以 UFT 自带订票系统为例讲解如何使用文本文件存储数据源实现数据驱动测试。
首先，录制订票系统的业务流程，如图6-44所示：
其次，用记事本编辑一个文本文件作为测试的数据源，在文本文件中的每一行测试数据包括了订票系统中预订航班的时间、航班预订的起点、航班预订的终点及航班表名称，它们代表了调用订票系统做的一个测试动作。这四个输入数据采用分号将其分隔开，把文件保存为DataCase.txt文件存放于C盘中，格式如下：
然后，在录制好的UFT脚本中编辑脚本实现文本文件作为数据源的数据驱动测试。修改后的UFT脚本如下：
在该脚本中，先创建FileSystemObject对象，该对象是Windows文件系统对象，它可以将一系列操作文件和文件夹的动作通过调用对象本身的属性直接实现。在本实例中采用的是OpenTextFile函数对文件进行读、写或追加。再采用SystemUtil对象的Run方法打开UFT中的订票系统，在循环中访问数据文件，每次读入一行数据直到最后一行，每一行采用 Split函数按分号“；”切割取到每个变量对应的数据，在本实例订票系统的脚本中预订航班的时间数据、航班起点、航班终点、名称分别就可以用 DataStr（0）、DataStr（1）、DataStr（2）、DataStr（3）替换。
编辑完脚本后，运行 UFT 就可以实现外部数据源的数据驱动测试，由于在DataCase.txt文件中包括了3行数据，则订票系统一共要运行3次。运行结果如图6-45、图6-46和图6-47所示。
最后，查看运行结果，如图6-48所示。
用 Excel 组织测试数据是采用外部数据源进行数据驱动测试中很常见的一种方法。采用文本文件作为数据源的一个不足点就是用户需要自己定义数据之间的分隔符，并且在读入数据时用Split函数来进行分割。然而采用Excel文件作为数据源则可以避免这个不足，因为 Excel 本身就是用于数据表格存储的，每一个数据采用一个单元格存储。在本实例中仍然以UFT自带订票系统为例讲解如何使用Excel文件存储数据源实现数据驱动测试。在本实例中，业务流程与文本文件作为外部数据源的数据驱动测试一样，因此它的脚本如图6-44所示。
然后设计数据源，在 Excel 表格中每一行测试数据包括了订票系统中预订航班的时间（Data_of_Flight）、航班预订的起点（Fly_From）、航班预订的终点（Fly_To）及名称（Custom_Name），执行表格中的一行就代表订票系统的一个测试动作。将 Excel 中数据3行数据以名为DataCase1.xls保存于C盘中，Excel中数据格式如图6-49所示。
其次，在录制好的UFT脚本中再次编辑脚本实现Excel文件作为数据源的数据驱动测试。修改后的UFT脚本如图6-50所示。
在该实例脚本中利用了 Excel 的 COM 接口进行编程，首先在脚本中创建了Excel.Application 对象。Application 对象是 Excel 对象模型中最高层级的对象，代表Excel 应用程序自身，它包括工作簿、工作表、单元格集合及它们包含的数据。利用Workbooks 对象的 Open 方法打开工作簿的文件名，通过设置对应的工作表以后就可以通过 Worksheet.Cells 属性找到工作表中的对象变量。那么，订票系统中测试的对象预订航班的时间（Data_of_Flight）、航班预订的起点（Fly_From）、航班预订的终点（Fly_To）及名称（Custom_Name）分别用 sheet.Cells（rowcout，1）、sheet.Cells（rowcout，2）、sheet.Cells（rowcout，3）、sheet.Cells（rowcout，4）替换，rowcout代表了 Excel的行数。最后，循环访问数据文件，每次读入一行数据直到运行到 Excel表中的末尾。
编辑完脚本后，运行 UFT 实现 Excel 文件外部数据源的数据驱动测试，由于在DataCase1.xml文件中包括了3行数据，则订票系统一共要运行3次。运行结果如图6-51、图6-52和图6-53所示。
最后，查看运行结果，如图6-54所示。
图书在版编目（CIP）数据
软件功能测试自动化实战教程/周焕来，贾海涛编著；51Testing软件测试网组编.--北京：人民邮电出版社，2015.3
ISBN 978-7-115-38471-3
Ⅰ.①软… Ⅱ.①周…②贾…③5… Ⅲ.①软件—测试—自动化—教材 Ⅳ.①TP311.5
中国版本图书馆CIP数据核字（2015）第023956号
内容提要
软件功能测试既是基础的软件测试领域，也是一个没有完全解决问题的领域，若要便捷有效地进行自动化功能测试是一件不简单的事情，为了帮助读者较好地进行自动化功能测试，特意撰写本书，本书的主要内容为：第一部分理念篇，主要包括软件测试概论、软件自动化测试、数据驱动测试技术、数据驱动测试技术的特点、数据驱动的自动化测试框架、数据驱动测试中的参数化技术、数据驱动测试的应用、关键字测试技术、关键字驱动测试特点、关键字驱动的自动化测试系统实现等；第二部分GUI测试篇，包括Unified Functional Testing 介绍、分析应用程序、调试和分析测试、使用GUI测试、编写自动化测试脚本、GUI的自动化测试方法、在关键字视图中添加测试信息的输出、编辑测试脚本、运行和调试测试脚本、利用活动屏幕来编辑测试脚本、关键字驱动测试方法、关键字驱动测试步骤；第三部分API与服务测试篇，包括API/接口测试、UFT 中的API测试、API测试通用流程、Web Service测试；第四部分非主流测试工具篇，主要有Linux系统交互应用功能测试框架工具Expect、网络协议自动化测试工具Sulley、创建FTP协议描述框架、无界面应用功能自动化测试工具Peach等技术。
本书适合软件测试从业者、新入职人员，以及大专院校相关专业的师生用书和培训学校的教材。
◆组编 51Testing软件测试网
编著 周焕来 贾海涛
责任编辑 张涛
责任印制 张佳莹 焦志炜
◆人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
三河市潮河印业有限公司印刷
◆开本：800×1000 1/16
印张：16.25
字数：293千字 2015年3月第1版
印数：1-3000册 2015年3月河北第1次印刷
定价：45.00元
读者服务热线：(010)81055410 印装质量热线：(010)81055316
反盗版热线：(010)81055315
