软件质量保证与测试课内实验指导书白盒测试黑盒测试

软件质量保证与测试课内实验指导书
第一章白盒测试
1.1白盒测试背景知识
结构性测试是知道产品内部工作过程，检测产品内部动作是否按照规格说明书的规定正常进行。

结构性测试允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

1.1.2 逻辑覆盖
结构性测试力求提高测试覆盖率。

逻辑覆盖是一系列测试过程的总称，它是在使用白盒测试法时，选用测试用例执行程序逻辑路径的方法。

逻辑覆盖按覆盖程度由低到高大致分为以下几类：
①.语句覆盖：设计若干测试用例，使程序中每一可执行语句至少执行一次；
②.判断覆盖：设计用例，使程序中的每个逻辑判断的取真取假分支至少经历一次；
③.条件覆盖：设计用例，使判断中的每个条件的可能取值至少满足一次；
④.判断/条件覆盖：设计用例，使得判断中的每个条件的所有可能结果至少出现一次，
而且判断本身所有可能结果也至少出现一次；
⑤.条件组合覆盖：设计用例，使得每个判断表达式中条件的各种可能组合都至少出现
一次；显然，满足⑤的测试用例也一定是满足②、③、④的测试用例。

⑥.路径覆盖。

设计足够的测试用例，使程序的每条可能路径都至少执行一次。

如果把路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据用例。

1.1.2 基本路径测试
如果把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就成为基本路径测试。

它是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。

设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。

①程序的控制流图
控制流图是描述程序控制流的一种图示方法。

符号○称为控制流图的一个结点，一组顺序处理框可以映射为一个单一的结点。

控制流图中的箭头称为边，它表示了控制流的方向，在选择或多分支结构中分支的汇聚处，即使没有执行语句也应该有一个汇聚结点。

边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

②计算程序环路复杂性
进行程序的基本路径测试时，程序的环路复杂性给出了程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。

所谓独立路径，是指包括一组以前没有处理的语句或条件的一条路径。

只要设计出的测试用例能够确保这些基本路径的执行，就可以使得程序中的每个可执行语句至少执行一次，每个条件的取真分支和取假分支也能得到测试。

基本路径集不是唯一的，对于给定的控制流图，可以得到不同的基本路径集。

通常环路复杂性可用以下三种方法求得。

*将环路复杂性定义为控制流图中的区域数。

*设E 为控制流图的边数，N 为图的结点数，则定义环路复杂性为V(G)＝E－N＋2。

*若设P 为控制流图中的简单判定结点数，则有V(G)＝P＋1。

③导出测试用例
利用逻辑覆盖方法生成测试用例，确保基本路径集中每条路径的执行
1.2 测试题目
1.2.1 三角形问题
1.2.1.1 三角形问题的描述
三角新问题接受三个整数a,b和c 作为输入，用作三角形的边。

程序的输入是由这三条边确定的三角形类型：等边三角形、等腰三角形、不等边三角形或非三角形。

1.2.1.2 三角形问题描述的细化
三角形问题接受三个整数a,b和c作为输入，用作三角形的边。

整数a,b,c必须满足以下条件：
✓c1. 1≤a≤200
✓c2. 1≤b≤200
✓c3. 1≤c≤200
✓c4.a<b+c
✓c5.b<a+c
✓c6. c<a+b
程序的输出是有着三条边确定的三角形类型：
等边三角形、等腰三角形、不等边三角形或非三角形。

如果输入值没有满足这些条件中的任何一个，则程序会通过输出消息来进行通知。

如果a,b 和c 的取值满足c1,c2和c3，则给出以下四种相互排斥输出中的一个：
如果三条边相等，则程序的输出是等边三角形；
如果恰好有两条边相等，则程序的输出是等腰三角形；
如果没有两条边想相等，则程序输出的是不等边三角形。

如果c4,c5和c6中有一个条件不满足，则程序输出的是非三角形。

1.2.1.3主要代码
见附件中Project
1.2.1.4要求
1.根据以上的C++代码画出该程序的流程图；
2.根据流程图，用白盒测试的用例设计方法设计测试用例实现：语句覆盖、判定覆盖、
条件覆盖、条件判定覆盖以及条件组合覆盖；
3.根据代码画出程序的流图，根据流图计算图的复杂度，计算出基本路径的条数，并给
出基本路径；
4.根据基本路径覆盖法设计测试用例，覆盖3中得到的基本路径；
1.2.2 NextDate问题
1.2.2.1 NextDate问题的描述
NextDate是一个有三个变量(月份、日期和年)的函数。

函数返回输入日期后面的那个日期。

变量月份、日期和年都具有整型值，则满足一下条件：
✓c1. 1月份12
✓c2. 1日期31
✓c3. 1812年2012
可以使规格说明更具体，包括对日期、月份和年的无效输入值的响应定义。

还可以对无效逻辑组合定义
1.2.2.2 NextDate问题的主要代码
见附件中的project
1.2.2.3 要求
1.根据以上的C++代码画出该程序的流程图；
2.根据流程图，用白盒测试的用例设计方法设计测试用例实现：语句覆盖、判定覆盖、条
件覆盖、条件判定覆盖以及条件组合覆盖；
3.根据代码画出程序的流图，根据流图计算图的复杂度，计算出基本路径的条数，并给出
基本路径；
4.根据基本路径覆盖法设计测试用例，覆盖3中得到的基本路径；
第二章黑盒测试
2.1 黑盒测试的背景知识
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。

在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

2.1.1 等价类划分法
等价类划分的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。

每一类的代表性数据在测试中的作用等价于这一类中的其他值。

该方法是一种重要的，常用的黑盒测试用例设计方法。

2.1.1.1划分等价类
划分等价类：等价类是指某个输入域的子集合。

在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果。

等价类划分可有两种不同的情况：有效等价类和无效等价类。

有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：与有效等价类的定义恰巧相反。

设计测试用例时，要同时考虑这两种等价类.因为，软件不仅要能接收合理的数据，也要能经受意外的考验。

这样的测试才能确保软件具有更高的可靠性。

2.1.1.2 划分等价类准则
划分等价类的方法：下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两
个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一
个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的
情况下，可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）
和若干个无效等价类（从不同角度违反规则）.
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等
价类进一步的划分为更小的等价类.
2.1.1.3设计测试用例的步骤
在确立了等价类后，可建立等价类表，列出所有划分出的等价类：
输入条件划分有效等价类与无效等价类。

然后从划分出的等价类中按以下三个原则设计测试用例：
①为每一个等价类规定一个唯一的编号；
②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一
步。

直到所有的有效等价类都被覆盖为止；
③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，
直到所有的无效等价类都被覆盖为止。

2.1.2 边界值分析法
边界值分析是通过选择等价类边界的测试用例。

边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。

它是对等价类划分方法的补充。

2.1.2.1边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.
使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据.
2.1.2.2基于边界值分析方法选择测试用例的原则：
①.如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个
范围边界的值作为测试输入数据；
②.如果输入条件规定了值的个数，则用最大个数,最小个数，比最小个数少一，比最大个数
多一的数作为测试数据；
③.根据规格说明的每个输出条件，使用前面的原则①；
④.根据规格说明的每个输出条件，应用前面的原则②；
⑤.如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和
最后一个元素作为测试用例；
⑥.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为
测试用例；
⑦.分析规格说明，找出其它可能的边界条件。

2.1.2.3 边界值分析中的两种假设
边界值分析中基于两种假设：
1.根据缺陷的数量边界值分析分为两类：单缺陷假设和多缺陷假设；
2.根据健壮性的考虑边界值分析分为两类：非健壮性分析和健壮性分析。

2.2 测试题目
2.2.1 三角形问题
问题的描述如上一章中1.2.1节的描述
2.2.2 NextDate问题
问题的描述如上一章中1.2.2节的描述
黑盒测试要求
1.根据题目中给出的三角形问题和NextDate问题的需求说明书，按照等价类划分法，设
计测试用例，覆盖所有的等价类；
2.根据题目中给出的三角形问题和NextDate问题的需求说明书，按照边界值分析法，设
计测试用例，进行功能性测试。

边界值分析法需要包含：单缺陷假设非健壮性假设；多
缺陷假设非健壮性假设；单缺陷假设假装性假设；最坏情况测试。

第三章自动测试工具——Nunit的使用
NUnit是一个单元测试框架，专门针对于.NET来写的。

其实在前面有JUnit(Java)，CPPUnit(C++)，他们都是xUnit的一员。

最初，它是从JUnit而来。

现在的版本是2.5.2。

接下来我所用的都是基于这个版本。

NUnit最初是由James W. Newkirk，Alexei A. Vorontsov 和Philip A. Craig，后来开发团队逐渐庞大起来。

在开发过程中，Kent Beck 和ErichGamma2位牛人也提供了许多帮助。

看来对于NUnit还真是下了一番力气了
NUnit是xUnit家族种的第4个主打产品，完全由C#语言来编写，并且编写时充分利用了许多。

NET的特性，比如反射，客户属性等等。

最重要的一点是它适合于所有.NET语言。

3.1 NUnit介绍
图3.1 NUnit运行效果
从中我们可以非常容易发现,右边是个状态条,图1是红色的,图2是绿色的.为什么会这样呢?因为如果所有测试案例运行成功,就为绿色,反之如果有一个不成功,则为红色,但也有黄色的.左面的工作域内则是我们写的每一个单元测试.
通过上面的图片,我想你对NUnit有个总的了解了.
接下来还是分为2个部分,一是NUnit的布局,另外一部分就是它的核心概念.
首先熟悉一下NUnit GUI的布局.
让我们更进一步看一下测试运行器窗口的布局。

在右边面板的中间，可以看到测试进度条。

进度条的颜色反映了测试执行的状态：
∙绿色描述目前所执行的测试都通过
∙黄色意味某些测试忽略，但是这里没有失败
∙红色表示有失败
底部的状态条表示下面的状态：
∙状态.说明了现在运行测试的状态。

当所有测试完成时，状态变为Completed.运行测试中，状态是Running: <test-name> (<test-name>是正在运行的测试名称)。

∙Test Cases说明加载的程序集中测试案例的总个数。

这也是测试树里叶子节点的个数。

∙Tests Run 已经完成的测试个数。

∙Failures 到目前为止，所有测试中失败的个数.
∙Time 显示运行测试时间（以秒计）
File主菜单有以下内容：
∙New Project允许你创建一个新工程。

工程是一个测试程序集的集合。

这种机制让你组织多个测试程序集，并把他们作为一个组对待。

∙Open 加载一个新的测试程序集，或一个以前保存的NUnit工程文件。

∙Close关闭现在加载的测试程序集或现在加载的NUnit工程。

∙Save 保存现在的Nunit工程到一个文件。

如果正工作单个程序集，本菜单项允许你创建一个新的NUnit工程，并把它保存在文件里。

∙Save As允许你将现有NUnit工程作为一个文件保存。

∙Reload 强制重载现有测试程序集或NUnit工程。

NUnit-Gui自动监测现加载的测试程序集的变化。

当程序集变化时，测试运行器重新加载测试程序集。

（当测试正运行时，现在加载的测试程序集不会重新加载。

在测试运行之间测试程序集仅可以重新加载。

一个忠告：如果测试程序集依赖另外一个程序集，测试运行器不会观察任何依赖的程序集。

对测试运行器来说，强制一个重载使全部依赖的程序集变化可见。

∙Recent Files 说明5个最近在NUnit中加载的测试程序集或NUnit工程（这个列表在Windows注册表，由每个用户维护，因此如果你共享你的PC，你仅看到你的测试）。

最近程序集的数量可以使用Options菜单项修改，可以访问Tool主菜单。

∙Exit退出
∙View菜单有以下内容：
∙Expand一层层扩展现在树中所选节点
∙Collapse 折叠现在树中选择的节点
∙Expand All递归扩展树中所选节点后的所有节点
∙Collapse All递归折叠树中所选节点后的所有节点
∙Expand Fixtures扩展树中所有代表测试fixture的节点
∙Collapse Fixtures折叠树中所有代表测试fixture的节点
∙Properties显示树中现所选节点的属性
Tools 菜单由这些项:
∙Save Results as XML作为一XML文件保存运行测试的结果
∙Options让你定制NUnit的行为
现在看看右边，你已经熟悉Run按钮和进度条。

这里还有一个紧跟Run按钮的Stop按钮：点击这个按钮会终止执行正运行的测试。

进度条下面是一个文本窗口，在它上方，由以下4个标签：
∙Errors and Failures 窗口显示失败的测试。

在我们的例子里，这个窗口是空。

∙Tests Not Run 窗口显示没有得到执行的测试。

∙Console.Error 窗口显示运行测试产生的错误消息。

这些此消息是应用程序代码使用Console.Error输出流可以输出的。

∙Console.Out 窗口显示运行测试打印到Console.Error输出流的文本消息。

3.2 一些常见属性
接下来,我将讲述这个框架如何使用.同时也涉及到一些非常重要的概念，我想其客户属性是非常重要的。

在NUnit里，有以下几种属性：
∙Test Fixture
∙Test
下面对每种属性一一讲解。

TestFixtureAttribute
本属性标记一个类包含测试，当然setup和teardown方法可有可无。

(关于setup 和teardown 方法在后面介绍) 做为一个测试的类,这个类还有一些限制：
∙必须是Public，否则NUnit看不到它的存在。

∙它必须有一个缺省的构造函数，否则是NUnit不会构造它。

∙构造函数应该没有任何副作用，因为NUnit在运行时经常会构造这个类多次，如果要是构造函数要什么副作用的话，那不是乱了。

TestAttribute
Test属性用来标记一个类（已经标记为TestFixture）的某个方法是可以测试的。

为了和先前的版本向后兼容，头4个字符（“test”）忽略大小写。

（参看/test.html）
这个测试方法可以定义为：
从上面可以看出，这个方法没有任何参数，其实测试方法必须没有参数。

如果我们定义方法不对的话，这个方法不会出现在测试方法列表中。

也就是说在NUnit的界面左边的工作域内，看不到这个方法。

还有一点就是这个方法不返回任何参数，并且必须为Public。

例如：
一般来说，有了上面两个属性，你可以做基本的事情了。

再对如何进行比较做一个描述。

在NUnit中，用Assert（断言）进行比较，Assert是一个类，它包括以下方法：AreEqual，AreSame，Equals，Fail，Ignore，IsFalse，IsNotNull，具体请参看NUnit的文档。

3.3 在.NET环境下应用NUnit
3.3.1 为测试代码创建一个Visual Studio工程
在Microsoft Visual Studio .NET中，让我们开始创建一个新的工程。

选择Visual C#工程作为工程类型，Class Library作为模板。

将工程命名为NUnitQuickStart.图4-1是一个描述本步骤的Visual Studio .NET。

3.3.2 增加一个NUnit 框架引用
在Microsoft Visual Studio .NET里创建这个例子时，你需要增加一个NUnit.framework.dll引用，如下：
在Solution Explorer右击引用，然后选择增加引用
NUnit.framework组件，在Add Reference对话框中按Select和OK按钮。

3.3.3 为工程增加一个类
3.3.4 建立你的Visual Studio 工程，使用NUnit-Gui测试
从程序->NUnit2.2打开NUnit-gui,加载本本工程编译的程序集.
为了在Visual Studio .NET中自动运行NUnit-Gui，你需要建立NUnit-Gui作为你的启动程序：
在Solution Explorer里右击你的NunitQuickStart工程。

在弹出菜单中选择属性。

在显示的对话框的左面，点击Configuration Properties夹
选择出现在Configuration Properties夹下的Debugging。

在属性框右边的Start Action部分，选择下拉框的Program作为Debug Mode值。

按Apply按钮
设置NUnit-gui.exe 作为Start Application。

，你既可以键入nunit-gui.exe的全路径，也可
使用浏览按钮来指向它。

下图中描述了如何将NUnit-Gui 作为工程的测试运行器
3.3.5编译运行测试.
现在编译solution。

成功编译后，开始应用程序。

NUnit-Gui测试运行器出现。

当你第一次开始NUnit-Gui，它打开时没有测试加载。

从File菜单选择Oprn，浏览NUnitQuickStart.dll 的路径。

当你加载了测试的程序集，测试运行器为加载的程序集的测试产生一个可见的表现。

在例子中，测试程序集仅有一个测试，测试程序集的结构如下图所示：
按Run按钮。

树的节点变为绿色，而且测试运行器窗口上的进度条变绿，绿色代表成功通过。

3.4 其它一些核心概念
上面的例子介绍了基本的NUnit特性和功能。

TestFixture，Test，和Assert是3个最基本的特征，我们可以用这些特性进行程序员测试了。

但是有的时候，你觉得这3个远远不够，比如有的时候打开一个数据库连接多次，有没有只让它打开一次的方法呢?如果我想把测试分类，应该怎样实现呢?如果我想忽略某些测试，又应该如何去完成呢?不用担心，NUnit已经有这样的功能了。

3.4.1 SetUp/TearDown 属性
在早期给的test fixture定义里，test fixture的测试是一组常规运行时资源.在测试完成之后，或是在测试执行种，或是释放或清除之前,这些常规运行时资源在一确定的方式上可能需要获取和初始化。

NUnit使用2个额外的属性：SetUp和TearDown,就支持这种常规的初始化/清除.上面的例子来描述这个功能。

现在增加乘法：
我们仔细一看，有重复的代码，如何去除重复的代码呢？我们可以提取这些代码到一个独立的方法，然后标志这个方法为SetUp属性。

这样2个测试方法可以共享对操作数的初始化了，这里是改动后的代码：
这样NUnit将在执行每个测试前执行标记SetUp属性的方法.在本例中就是执行InitializeOperands()方法.记住，这里这个方法必须为public，不然就会有以下错误：Invalid Setup or TearDown method signature
3.4.2 ExpectedException
这里是一个验证这个假设的测试。

有的时候,我们知道某些操作会有异常出现，例如，在实例中增加除法，某个操作被0除，抛出的异常和.NET文档描述的一样。

参看以下源代码：
除了[Test]属性之外，DivideByZero方法有另外一个客户属性：ExpectedException。

在这个属性里，你可以在执行过程中捕获你期望的异常类型，例如：在本例就是
DivideByZeroException。

如果这个方法在没有抛出期望异常的情况下完成了，这个测试失败。

使用这个属性帮助我们写程序员测试验证边界条件(Boundary Conditions)。

3.4.3Ignore属性
由于种种原因，有一些测试我们不想运行。

当然,这些原因可能包括你认为这个测试还没有完成，这个测试正在重构之中，这个测试的需求不是太明确。

但你有不想破坏测试，不然进度条可是红色的哟。

怎么办？使用Ignore属性。

你可以保持测试，但又不运行它们。

让我们标记MultiplyTwoNumbers测试方法为Ignore属性：
运行测试,现在产生了下面的输出：
Ignore属性可以附加到一个独立的测试方法,也可以附加到整个测试类(TestFixture).如果Ignore属性附加到TestFixture,所有在fixture的测试都被忽略.
3.4.4 TestFixtureSetUp/TestFixtureTearDown
有时，一组测试需要的资源太昂贵。

例如，数据库连接可能是一个关键资源，在一个
test fixture的每个测试中，打开/关闭数据库连接可能非常慢。

这就是我在开始提到的问题。

如何解决？NUnit有一对类似于前面讨论的SetUp/TearDown的属性：TestFixtureSetUp/TestFixtureTearDown。

正如他们名字表明的一样，这些属性用来标记为整个test fixture初始化/释放资源方法一次的方法。

例如，如果你想为所有test fixture的测试共享相同的数据库连接对象，我们可以写一个打开数据库连接的方法，标记为TestFixtureSetUp属性，编写另外一个关闭数据库连接的方法，标记为TestFixtureTearDown属性。

这里是描述这个的例子。

第四章WinRunner的使用
凡问到Mercury公司的测试工具，每个人都会说Winrunner记录的是前台界面的操作过程，是功能测试工具，；Loadrunner记录了后台程序的交互信息，是性能测试工具。

似乎在每位测试人员的心中，Winrunner和Loadrunner已经被很明确地界定开来，前者只能做功能测试，而后者只能进行性能测试。

但是出乎大家的意料，Winrunner也能进行性能测试，只不过这不是一种常规的测试方法，不为广大测试人员使用。

但是不被广泛使用并不是代表不行，前一阶段，我就在某系统上使用Winrunner进行了一次性能测试，证实了该测试方法的可行性。

下面我将介绍使用Winrunner进行性能测试的工作原理，详细介绍使用Winrunner进行性能测试的测试方法，以及点明该方法优势和弊端。

有兴趣的测试爱好者，可以仔细阅读，尝试使用Winrunner进行性能测试。

4.1 使用Winrunner进行性能测试的原理
性能测试的初衷就是模拟大量的用户对应用系统同时进行操作，查看大量访问的情况下，应用程序的运行情况和系统的承载情况。

Winruner是功能测试工具，它主要的功能是记录用户的界面操作。

如果使用Winrunner 进行性能测试，模拟大量的客户前台界面操作的情况（Loadrunner只是记录后台程序的交互情况），那不是真正达到了性能测试的目的了么。

我们知道Winrunner是没有办法模拟大量用户的，但是Loadrunner的Controller可以。

所以我们就会很自然地想到使用Loadrunner调用Winrunner，并发大量的用户，完成性能测试工作。

在使用Winrunner进行压力测试时，我们要选用一台主控机和一台压力生成器，让主控机通过远程桌面方式访问压力生成器。

由于GUI脚本是界面操作，所以一个界面只能运行一个 GUI脚本，但是通过远程桌面方式访问主机，我们可以使一台机器展现出两个界面，而且这两个界面互不干扰，各自操作的。

所以我们建议使用远程桌面的方式控制压力生成器。

如果压力生成器可以同时打开2个远程桌面界面，那么我们就可以运行2个虚拟用户，如果可以打开3个，那么我们就可以运行3个虚拟用户，以此类推。