第七章 软件测试自动化 《软件测试技术》 电子教案

1、第七章第七章 软件测试自动化软件测试自动化 本章要点本章要点 1.自动化测试应考虑的各种因素； 2. 自动化测试和手工测试中涉及的问题以及二者的优缺点； 3.应用自动化测试工具的目的； 4.自动化测试工具的分类和选择方法； 5.自动化测试过程实例及自动化测试经验。 本章目标本章目标 1. 1.了解自动化测试应考虑的各种因素以及如何衡量自动化测试成本。 2. 2.掌握自动化测试和手工测试的优缺点，知道如何正确选择两种软件测试策略。 3. 3.了解测试工具的分类、使用目的及其选择，了解几种常用的测试工具。 4. 4.了解自动化测试的过程。 进行自动化测试的适当时机进行自动化测试的适当时机 并非一律

2、用自动化测试就好，要考虑经济性、并非一律用自动化测试就好，要考虑经济性、有效性，适当的进行自动化测试。有效性，适当的进行自动化测试。概述概述 当对产品的一些特征来设计一系列测试时，对当对产品的一些特征来设计一系列测试时，对每一个测试都需要决定是否对其进行自动化测试。每一个测试都需要决定是否对其进行自动化测试。 如何做出一个合理的决定，假设如下：如何做出一个合理的决定，假设如下： 1 1拥有稳定的自动化测试技术支持。拥有稳定的自动化测试技术支持。 2两种极端的可能性：一种就是无需人工干预的完全自动化测试，另一种就是只运行一次就废弃的人工测试。 3自动化测试和手工测试都可行（但事实并非如此）。 4

3、测试是通过外部接口来完成的（黑盒测试）。 5不要求必须进行自动化测试。 6测试已经设计好之后，再决定是否进行自动化测试。 7有一定的时间用于完成测试，并且在这段时间里完全有可能把测试做好。 在决定是否要进行自动化测试之前，通常需要考虑如下几个主要问题： 1同手工测试相比，只运行一次的自动化测试要多付出多少代价？ 2自动化测试的生命周期是有限的。那么，这类测试是否迟早要终止？什么事件将会导致测试中止？3在整个生命周期内，这次测试能捕获到新bug的可能性会有多大？这些难以预计的收益能够使自动化测试的成本得到补偿吗？自动化测试的成本自动化测试的成本 创建一次自动化的测试所花费的时间要比一次手工测试所

4、花费的时间多得多。测试成本因产品的架构以及自动化测试的方式不同而异。介绍如下几种(费用由高至低)： 通过图形用户界面来测试产品； 使用GUI捕捉/回放工具来跟踪测试与产品之间的交互，同时建立脚本； 测试的是一个编译器； 测试成本还要考虑测试时间、Bug的多少等问题。自动化测试的生命周期自动化测试的生命周期 测试的生命周期如下图测试的生命周期如下图7-17-1所示：所示： 创建测试测试运行测试中止运行测试代码改变运行测试代码改变运行测试代码改变 在决定是否进行自动化测试之前，必须首先估计一下，产品的代码变动在什么范围内，测试仍能存活。如果要求代码不能有太多变动，要做的测试最好是非常善于捕获bug

5、的测试；而且要求估计生命周期。 介于需要被测试的代码和测试之间的代码称作中介代码（intervening code）。 一、中介代码的变动对测试周期的影响 中介代码是使测试中止的一个主要原因。 例如，用户界面以前要求输入 号码，现在变为提供一个可视的 键盘，使用鼠标点击数字来模拟使用真实的 。虽然通过两种界面向被测试的代码传递的都是相同的数据，但是因为没有了提供输入 号码的地方，自动化测试可能就会中止。 为了使测试免受中介代码变化的影响，应该从以下几个方面考虑： 1、评估一下中介代码的改变会不会影响测试。如果绝不会影响到测试，使用自动测试就能节省大量的时间。 2、如果中介代码的变化会影响到测试

6、，就必须考虑一下使用测试库函数能够使测试不受影响的可能性会有多大。 3、假如没有测试函数库如果是在捕捉/回放的模式下使用GUI测试自动化工具不要指望测试会不受影响。 二、被测试代码的改变对测试周期的影响二、被测试代码的改变对测试周期的影响 需要判断一下被测试的代码的稳定性。 首先，需要重点考虑代码的行为。 其次，考虑功能的增加会不会影响测试。 自动化测试的价值自动化测试的价值 进行自动化测试要解决的问题就是：自动化测试的价值必须要超过所有因此而放弃的手工测试的价值。 考虑问题如下： 1.测试代码的结构要清晰。 2.测试通常是用来测试功能代码。支撑代码对于测试者来说通常是不可见的。 3.但功能代

7、码的改变通常会改变代码的行为。因此，极有可能会使测试中止，而不是报告bug。 4.测试的价值主要在于支撑代码改变以后仍能捕获bug的能力。 5.如果我们一点也不了解支撑代码，无法知道测试是否能捕获bug?如何估计测试是否有助于我们捕获bug? 6.可以认为与被测试的代码进行交互的其他代码大多数是支撑代码，支撑代码的变化也会产生自动测试所能捕获的bug。注意：高价值的测试不可能是特征驱动测试而是任务驱动测试。 一、分析被测试代码的结构。 例子：被测试的是一段处理从银行账户里提款的代码。 （例子详见教材） 把被测试的代码分成两部分： 功能代码（feature code），它直接实现被测试代码所完成

8、的功能。测试会专门对其进行调用。功能代码（support code）可以完成用户所进行的操作（通过使用用户界面的关联代码）。 支撑代码(support code)，它起到支持功能代码 （support code）的作用。测试代码会对其进行调用，但并没有针对这些代码的特殊测试。 图7-2 功能代码和支撑代码示意图 在这里，支撑代码位于水平线以下。功能代码位于水平线以上，共有五种不同的功能，我们只针对其中的两个功能进行测试。 二、被测试代码的变化所带来的影响。 主要考虑这样一些问题： 1就给定的结构而言，代码的变化将会产生什么样的影响？ 2什么样的变化具有测试价值？ 假设一些功能代码发生了变化，如

9、图7-3中灰色图形所示： 这种变化极有可能会导致调用功能代码的测试中止。因此，如果希望使用自动化测试的方法在发生变化的功能代码（feature code）中找到bug，就必须终止原有测试。如果测试的成本很高，这样做是很不经济的。 为了使原有的测试行为仍然能够保留，通常采用的做法是更改支撑代码（support code）以便能够支持其他功能代码的变动。请看图7-4：图7-3图7-4 三、支撑代码的变化对测试的影响 主要从以下两方面来考虑这个问题： 代码的变化有多少？这些变化会引入多少bug?例子例子 假设我正在测试一个产品，测试已经完成一半。假设我正在测试一个产品，测试已经完成一半。产品已经实现

10、了主要的功能，但是还需要增加一产品已经实现了主要的功能，但是还需要增加一些辅助功能。现在我要对这些主要的功能进行测些辅助功能。现在我要对这些主要的功能进行测试。试。 测试过程中，在同如下人员进行交流的过程中测试过程中，在同如下人员进行交流的过程中提出的问题如下：提出的问题如下： 程序员程序员：这些辅助的功能是否有可能需要改变产品的支撑代码？程序员有可能精心设计了支撑代码，并且考虑坚持使用可视化的用户界面来完善各种功能。如果是这样的话，那么自动化测试的价值就不大。 但是因为要急于完成测试，程序员也可能知道程序的支撑代码的结构不会一成不变的。由于大部分工作将会重复进行，所以可能会特别需要进行自动化

11、测试。或者程序员也不知道支撑代码是否要改变。 项目经理项目经理：在新版本中，新增的功能是一个十分重要的部分吗？如果是这样的话，由于市场竞争激烈，图形用户界面有可能改变吗？以前，用户界面改动有多大？ 为什么会希望今后的改动越少越好？这些变化是为了增加功能，还是用来代替现有的功能？我们需要切实的估计一下变动的可能性，因为任何变化都可能会提高自动化测试的成本，缩短测试的生命周期。 了解并熟悉测试工具的人员了解并熟悉测试工具的人员：如何应对产品的变化？什么样的变化会使测试中止？对于新增加功能的测试，遇到这些情况的几率会有多大？ 一次自动化测试所花费的成本相当于几次手工测试，并且要特别重视测试价值的大小

12、和生命周期的长短，这样做可能不对。但这都是为了避免犯下灾难性的错误，如果自动化测试的成本很高而生命周期很短，我们最好使用手工测试。 但是这并不意味着不能使用自动化测试，而是要判断与衡量。 在测试中，要不断跟踪bug报告并加以修改，保留所有和测试相关的文档。从这些资料当中，我们常常能够发现更为重要的信息。如： 什么样的因素与产生的bug无关？ 哪里存在bug？ 代码行为的稳定性如何？ 经过一段时间，要进行自动化测试还是手工测试的想法就会逐渐成熟，可能会形成一个更大的测试套。另外一些需要考虑的问题另外一些需要考虑的问题 1.手工测试有时候会发现一些自动化测试所不能发现的问题。 2.尽管人善于发现问

13、题，但很容易疲劳。并且不能对结果做出精确的分析。 3.由于我们不能保证每次手工输入的数据完全相同。因此，重复的手工测试多少会有些不同，那么就有可能捕获支撑代码中的bug。 4.要求对配置测试进行更多的自动化测试。 5.如果在进行第一次测试的时候就捕获了bug。表明这部分程序代码将来有可能发生变化，要进行更多的自动化测试 。 6.如果自动化测试的技术支持足够强大，开发人员很容易就能做回归测试，自动化测试也需要比手工测试快得多，但是并不是所有的公司都具有这样的自动化测试技术支持水平。 7.使用手工测试的时候捕获了bug, 但又不能再现bug时会使人很沮丧。 8.程序更改之后，测试人员应该对其进行检

14、查。 9.因为进行自动化测试的创建要花费一些时间，因此把第一个bug提交给程序员所花费的时间要比手工测试花费的时间长。 10.把测试设计的有利于进行自动化测试，但不善于捕获bug。 11.如果产品的行为改变了，自动化测试就有可能会报告一些不真实的bug。 12.如果自动化测试创建的十分好，能够有序的运行，并且可以改变测试运行的顺序。 13.我们可以在产品需要测试之前先设计测试。 14.也许自动化测试的价值直到下一个新版本发布之后才能体现出来。 自自动动化化测试测试和手工和手工测试测试比比较较 自动化测试并不能完全取代手工测试，二者各有优缺点。 自自动动化化测试与测试与手工手工测试测试的比的比较

15、较 表7-1显示了手工测试与自动化测试的比较结果。这个测试案例中包括1750个测试用例和700多个错误。测试步骤手工测试自动化测试通过使用工具改善测试的百分比测试计划的开发3240-25%测试用例的开发26211755%测试执行4662395%测试结果分析1175850%错误状态/更正检测1172380%产生报告961683%时间总和109027775%表7-1 自动化测试和手工测试比较短测试周期中手工测试面临的挑战短测试周期中手工测试面临的挑战 迭代式的开发过程已逐渐取代传统的瀑布式开发，成为了目前最流行的软件开发过程。在迭代开发中强调在较短的时间间隔中产生多个可执行、可测试的软件版本，这就

16、意味着测试人员也必须为每次迭代产生的软件系统进行测试。 随着软件开发过程的进展，测试工作越来越繁重，如果使用手工测试的方法，将很难保证测试工作的进度和质量。 手工手工测试测试的的问题问题 手工测试的方法是根本不可能符合软件快速开发的要求的。大公司用自动化测试因为它适合自动化测试的特点和有较高的投资回报率。 1、针对产品型项目的测试 2、针对增量式开发、持续集成项目的测试 3、针对能够自动编译、自动发布的系统的测试 4、回归测试 5、需要多次重复、机械性动作的测试 6、需要频繁运行的测试 7、将烦琐的任务转化为自动化测试 自动化测试的问题自动化测试的问题 自动化测试并不能完全取代手工测试。例如：

17、自动化测试并不能完全取代手工测试。例如：在下面几种情况下就不适合使用自动化测试。在下面几种情况下就不适合使用自动化测试。 定制型项目（一次性的） 项目周期很短的项目 涉及业务规则复杂的对象 关于美观、声音、易用性的测试 很少运行的测试，如：一个月只运行一次的测试。 测试的软件不稳定 涉及物理交互的测试 自动化测试的优点自动化测试的优点 1、对程序的新版本运行己有的测试，即回归测试。2、可以运行更多更频繁的测试。 3、可以进行一些手工测试难以完成或不可能完成的测试。 4、充分地利用资源。 5、测试具有一致性和可重复性。 6、测试具有复用性。 7、缩短软件发布的时间。8、增强软件的可靠性。自动化测

18、试的缺点自动化测试的缺点 1、自动化测试不能取代手工测试， 测试主要还是要靠人工的。 2、新缺陷越多，自动化测试失败的几率就越大。 3、工具本身不具有想象力 4、技术问题、组织问题、脚本维护 5、测试工具与其他软件的互操作性 自动化测试工具的选择和使用自动化测试工具的选择和使用 7.3.1 7.3.1 应用自动化测试工具的目的应用自动化测试工具的目的 一般而言，在测试过程中应用自动化测试工具主要为了以下几个目的： 1、 提高测试质量； 2、 减少测试过程中重复的手工劳动，提高测试效率； 3、 实现测试自动化，充分利用测试资源。 自动化测试工具的概要介绍自动化测试工具的概要介绍 根据软件生命周期

19、中的定义，可以把自动化测试工具分为白盒测试工具、黑盒测试工具和测试管理工具三大类。这些工具和软件开发过程中相关活动的关系如图7-6所示：编码以及单元测试白盒测试工具测试管理工具黑盒测试工具需求分析框架设计详细设计集成测试系统测试验收测试图7-6 测试工具与开发过程关系图 一、白盒测试工具 白盒测试工具一般是针对代码进行测试的工具，测试中发现的缺陷可以定位到代码级，根据测试原理的不同，又可以分为静态测试工具和动态测试工具。 1、 静态测试工具 所谓静态测试就是不运行测试而直接对代码进行分析的测试。 静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件。 2、

20、 动态测试工具 动态测试主要采用“插桩”的方式，即向代码生 成的可执行文件中插入一些监测代码，运行框架程序，统计程序运行时的数据，可以针对所有类的成员函数进行测试，也可以只针对类的公共接口函数进行测试。 （1）商业性的白盒测试工具，比较有代表性的如：compuware公司的Numega系列工具和ParaSoft的JavaSolution以及C/C+ Solution系列。 （2）非商业性的白盒测试工具，主要以Xunit系列为代表的测试框架工具。 二、黑盒测试工具 黑盒测试工具包括功能测试工具和性能测试工具。 黑盒测试工具的代表有Rational公司的TeamTest、Robot，Compuwa

21、re公司的QACenter，另外，专用于性能测试的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。三、测试管理工具 测试管理工具用于对测试进行管理。一般而言，测试管理工具主要对软件缺陷、测试计划、测试用例、测试实施进行管理。 *缺陷跟踪工具是管理工具使用最多的*。 测试管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord等软件。 如何选择缺陷跟踪工具？方法如下：1.使用word、excel等类型的平面文档；2.自行设计开发一套管理软件；3.购买商业性的软件； 4.下载一套适合自己的开源

22、软件，自行配置和维护。 四、 其他自动化测试工具 还有一些专用的自动化测试工具:针对数据库测试的TestBytes，对应用性能进行优化的EcoScope等工具。自动化测试工具的选择自动化测试工具的选择 在考虑选用工具的时候，建议从以下几个方面来权衡和选择： 1、 功能 *除了基本的功能之外，以下的功能需求也可以作为选择自动化测试工具的参考： 1) 报表功能； 2) 自动化测试工具的集成能力； 3) 操作系统和开发工具的兼容性； 2、价格 3、对自动化测试工具进行评估。主要从以下几点来考虑： 在使用了多种工具后对今后要采用的工具进行期盼。 自动化测试工具的实际性能是否和自动化测试工具文档中声明的

23、一致。 3总结试用自动化测试工具的结果，得出评估报告。 4、引入自动化测试工具的目的是使测试自动化 自动化测试工具在测试过程中的应用自动化测试工具在测试过程中的应用 很多引入测试软件的公司并没有能够让测试软件发挥应有的作用，其原因主要有三个方面： 1 1、没有考虑公司的实际情况，盲目引入自动化测、没有考虑公司的实际情况，盲目引入自动化测试工具试工具 2 2、没有形成一个良好的使用自动化测试工具的环、没有形成一个良好的使用自动化测试工具的环境境 3 3、没有进行有效的自动化测试工具的培训、没有进行有效的自动化测试工具的培训性能测试实例性能测试实例 本节列举了一个使用LoadRunner进行的性能

24、测试实例。 7.4.1 LoadRunner 7.4.1 LoadRunner 简介简介 LoadRunner 是一种预测系统行为和性能的负载测试工具。通过模拟成千上万名用户和实施实时性能监测来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。其主要功能如下：1、轻松创建虚拟用户 2、创建真实的负载 3、定位性能问题 4、分析结果精确定位问题所在 案例分析案例分析 该案例仍然是针对电厂两票管理系统的性能测试，电厂工作人员可以使用该管理系统开出工作票和操作票。假设开设100个账号和密码可供

25、100个工作人员同时开出工作票或操作票。要求，每台机器只能由一个用户使用，每个用户只能使用各自不同的账号登录该管理系统，开票结束后，要求把工作票或操作票内容存档，若在规定的时间内没有存档，则系统强制存档。 但是，一般测试部门不可能有100台机器同时进行测试的。所以，使用模拟IP地址，修改脚本来协助测试。但是，为了保证测试结果，建议使用所有可用的机器进行复测，因为有时候测试工具是不可以完全信赖的。 现场测试环境：现场测试环境： 硬件：100台PC机，一个Web服务器 操作系统：Windows 2000 Server 测试工具：Loadrunner 8.0 浏览器：和IE6.0 测试人员：质控小组

26、4人，执行现场测试 项目小组22人，提供现场环境 技术小组各1人，提供技术支持 测试要求：测试要求： 100个用户拥有独立IP地址，不同的用户及密码登录，开票操作完成后各自同时把工作票或操作票内容存档。测试内容：测试内容： 100个用户以不同的用户名和密码登录该管理系统。开票完成后，把工作票或操作票内容存档。测试系统是否能正常开票以及正确存档。 测试方案测试方案： 1、 完全50台实际的PC机进行现场测试。 （1） 准备工作，并做计划。第一轮测试执行三遍，设定50个用户开出的工作票或操作票内容同时提交，第一遍全部使用，第二遍25台使用，25台使用，第三遍全部使用 （1） 准备工作，并做计划。第

27、一轮测试执行三遍，设定50个用户开出的工作票或操作票内容同时提交，第一遍全部使用，第二遍25台使用，25台使用，第三遍全部使用IE6.0（2） At 9：00 ，50个用户同时登录系统（3） At 9：05 ，50个用户同时提交（4） 分别记录第一轮测试（三遍）的结果（5） 第二轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，全部使用IE5.0（6） At 9：15 ，50个用户同时登录系统（7） At 9：20 ，30个用户同时提交（8） At 9：25 ，剩余20个用户同时提交（9） 记录第二轮测试结果（10） 第三轮测试准备工作，设定30个用

28、户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，全部使用 （11） At 9：15 ，50个用户同时登录系统 （12） At 9：20 ，30个用户同时提交 （13） At 9：25 ，剩余20个用户同时提交 （14） 记录第三轮测试结果 （15） 第四轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户使用，延时提交用户使用IE6.0 （16） At 9：15 ，50个用户同时登录系统 （17） At 9：20 ，30个用户同时提交 （18） At 9：25 ，剩余20个用户同时提交 （19） 记录第四轮测试结果 （20

29、） 第五轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户使用，延时提交用户使用IE5.0 （21） At 9：15 ，50个用户同时登录系统 （22） At 9：20 ，30个用户同时提交 （23） At 9：25 ，剩余20个用户同时提交 （24） 记录第五轮测试结果 （25） 第六轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户其中20个使用，10个使用，延时提交用户使用IE5.0 （26） At 9：15 ，50个用户同时登录系统 （27） At 9：20 ，30个用户同时

30、提交 （28） At 9：25 ，剩余20个用户同时提交 （29） 记录第六轮测试结果 （30） 第七轮测试准备工作，设定25个用户开出的工作票或操作票内容同时提交，另外25个用户分两次分别延时5、15分钟提交 （31） At 9：35 ，50个用户同时登录系统 （32） At 9：40 ，25个用户同时提交 （33） At 9：45 ，剩余的其中15个用户同时提交 （34） At 9：55 ，其他10个用户同时提交 （35） 记录第七轮测试结果，参见第二轮测试第六轮测试过程分别对和的情况进行测试 （36） 第八轮测试准备工作，设定其中25个用户开出的工作票或操作票内容不提交，由系统强行提交

31、（37） At 10：10 ，50个用户同时登录系统 （38） At 10：15 ，25个用户同时提交 （39） 其余用户的内容由系统强行提交 （40） 记录第八轮测试结果，参见第二轮测试第六轮测试过程分别对和的情况进行测试 （41） 第九轮测试准备工作，设定其中25个用户开出的工作票或操作票内容同时提交，15个用户延时5分钟提交，其余用户由系统强行提交 （42） At 10：25 ，50个用户同时登录系统 （43） At 10：30 ，25个用户同时提交 （44） At 10：35 ，剩余的其中15个用户同时提交 （45） 剩余10个用户系统强制提交 （46） 记录第九轮测试结果，参见第二轮

32、测试第六轮测试过程分别对和的情况进行测试 2、模拟50个用户进行测试。其中，18台是PC机，另外32台机器的IP地址是Loadrunner模拟出来的。 （1） 在18台实际的PC机中抽取其中一台虚拟32个IP地址，包括自身的IP地址，这台机器上共33个IP地址，这33个IP地址只能全部使用或者全部使用IE6.0 （2） 其余17台实际的PC机分别由17个人操作，另外一台机器由一位质控小组人员操作 （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 3、模拟50个用户进行测试。其中，10台是PC机，另外40台机器的IP地址是用Loadrunner模拟出来的。

33、（1） 在10台实际的PC机中抽取其中一台虚拟40个IP地址，包括自身的IP地址，该机器上共41个IP地址，这41个IP地址只能全部使用或者全部使用IE6.0 （2） 其余9台实际的PC机分别由9个人操作，另外一台机器由一位质控小组人员操作 （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 4、模拟75个用户进行测试。其中，35台是PC机，另外40台机器的IP地址是用Loadrunner模拟出来的。 （1） 在35台实际的PC机中抽取其中三台分别虚拟13、13、14个IP地址，这40个IP地址只能全部使用或者全部使用IE6.0 （2） 其余32台实际的PC

34、机分别由32个人操作，另外三台机器由两位质控小组人员操作 （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 5、模拟100台用户进行测试。其中，40台是PC机，另外60台机器的IP地址是用分别用四台实际的PC机模拟出来的。记录测试结果。 （1） 在40台实际的PC机中抽取其中四台分别虚拟15个IP地址，这64个IP地址只能全部使用或者全部使用IE6.0 （2） 其余36台实际的PC机分别由36个人操作，另外四台机器由四位质控小组人员操作 （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 6、 对5中所述情况重复测试两次。 7、 为了保证结果的正确性，完全100台实际的PC机进行现场测试。过程参见1测试过程：测试过程： 1、 一台PC机上创建15个虚拟的IP地址。首先，启动IP Wizard，如下：开始程序LoadrunnerToolsIP Wizard点击“Add”，添加你计划虚拟的IP地址。但是注意不能添加已经被占用的IP地址。 2、 启动Virtual User Generator，