3.       练习

为了证明以上提到3种方法的简单和有效，下面以www.wmata.com站点（华盛顿市区交通运输的权威站点）为例，来创建用户使用模式的模型。选择这个网站的原因是它具备示例论证所需的各种条件属性，同时你不需要购买或注册任何东西，我也不需要考虑版权问题等。当然，如果你是为网站的所有者测试的话，就不会有这个问题了。你也可以在你喜欢的、含有弹出窗口的静态站点上验证这些方法。

在开始讲解之前，首先我假定你已经掌握了如何录制、回放VU脚本，如何在录制过程中插入Timer，以及如何用TestManager创建脚本套件。同时我也假定你已经阅读了本文的第2章，因此我会省去有关用户延迟时间方面的内容。下面的练习只需用1个用户，某些情况下只需2个用户就可以进行测试了。因此别对www.wmata.com网站施加大用户量的测试，否则你会被认为是恶意攻击并承担刑事责任，有言在先，我是不会承担任何责任的。

假设通过直觉我们确定用户使用模式如图7所示。

图7 WMATA网站上的用户路径

3.1.      全路径脚本方法练习

使用全路径脚本方法来模拟用户路径，我们需要如图8的两个脚本。

图8 代表WMATA用户路径的全路径脚本

我们将通过点击适当的链接，添加注释、Timer、延迟等来录制这两个浏览路径，与第2章介绍的方法一样。

对于上面两个路径中的Plan a Trip路径的脚本录制，我们的旅途将从Vienna地铁站到Smithsonian地铁站，中间经过多个著名的博物馆。请按下面的步骤：

• l        从主页开始录制
• l        点击屏幕右侧的Riding Metro部分的系统地图链接
• l        在橙色线路中点击最左边的车站，Vienna车站
• l        点击右边的Riding Metro中的Stations下拉框
• l  点击Smithsonian车站
• l     停止录制

对于View General Information脚本，按以下步骤录制：

• l        从主页开始录制
• l        点击屏幕右方的About Metro
• l        点击Metro Police链接
• l        点击右边的Metro B2B中的Solicitation/awards
• l        停止录制

现在我们可以在TestManager创建测试套件来执行这个场景了。点击Suites > New Suite > Blank Performance Testing Suite来创建测试套件，接着通过User Groups > Insert > User Group创建2个用户组，分别设置60％和40％的用户比例，在用户组的右键菜单中通过Insert > Test Script插入相应的脚本。如图9所示。

图9 用于执行WMATA全路径脚本的测试套件

是不是很简单呢？好，我们继续吧。

3.2.      路径片段方法练习

在这个练习里，我们将录制3个分割脚本，如图10所示。

图10 代表WMATA用户路径的分割脚本

这种方法也非常的简单。我们在一个Record Session中录制Home Seg和Plan a Trip Seg脚本，在另外的Record Session中录制View General Info Seg脚本，然后再插入和上一个练习一样的注释、Timer、延迟等。

首先录制打开主页的操作，通过选择Robot工具菜单Record > Split Script，或者浮动工具栏上的Insert Toolbar > Split Script按钮来分割脚本，并保存为Home Seg。接下来继续录制下一段脚本，步骤如下：

• l        点击System map
• l        点击Vienna Stop
• l        点击Stations
• l        点击Smithsonian Stop
• l        停止录制，保存为Plan a Trip Seg

View General Info Seg脚本可以有不同的录制方式：Network或API（这方面的讨论超出了本文的讨论范围，如果有需要的话可以查看其帮助手册）。在API的录制方式中，开始录制打开主页然后再分割脚本并随便保存成某个名字，因为我们并不需要这个脚本。接下来的录制：

• l        点击About Metro
• l        点击Metro police链接
• l        点击Solicitations/awards
• l        停止录制并保存为View General Info Seg

如果是以Network方式录制的话，我们可以在脚本录制之前先访问主页，在开始真正的操作之前才激活录制功能，然后再用和上面一样的步骤进行录制，这样就不必录制一些无用的脚本了。

接着用前面介绍的方法创建一个执行脚本的测试套件，如图11所示。我们还可以先把脚本加到scenario中，再把scenario加到用户组中（图5就是这种方式的，可以参考）。但其实这两种方式都是一样的。

图11用于执行WMATA分割脚本的测试套件

3.3.      灵活脚本方法练习

如果你已经在做这个练习，或曾经访问这个网站的话，你可能会发现在WMATA网站的Plan a Trip path的最后一页上，有一个关于地铁站之间行程价格和时间的链接。出于好奇心你可能点击来看看。我们把这个可选的路径加到Plan a Trip的脚本中，并假设其中50％的用户会关心行程的价格和时间的问题，如图12所示。

图12 添加了可选路径的WMATA用户路径

出于练习方面的考虑，我们重点关注Plan a Trip部分的模拟。我们先录制一个包含了Fares and Times部分的脚本。这里使用的是全路径脚本方式，虽然也可以用脚本片段方式。

第一部分的脚本，可以用和前面一样的步骤。录制打开主页（www.wmata.com），点击System map，点击Vienna stop，点击Stations，在下拉框中选择Smithsonian stop。接下来录制另一段脚本。点击Fares & travel times between stations链接（这里会弹出一个新的浏览窗口，这也就是使用灵活脚本方法的最佳方式），在下拉列表中选择Vienna，点击Get Fare Data点击，看完结果之后再点击关闭按钮，最后停止录制。

用第二章介绍的方法调整延迟时间后，把这段新录制的代码插入到前面的脚本中，形成一个满足新流程的脚本。代码3展示了部分的脚本。

列表3：添加了查看费用信息的部分脚本

如同前面在线书店的例子一样，这种方法通过变量的随机值来控制脚本的执行路径。

给高级用户：灵活脚本方法看起来非常简单，但需要注意的是，if语句中浏览的是独立浏览器窗口的会好一些。这种脚本方法可以用在任何可选的导航路径，但前提是开始点和结束点在同一地方，对于个别的sockets（set Server_connection和http_disconnect命令）来说需要手工维护。这个详细讨论起来就太多了，根据我个人的经验，如果没有非常必要的情况的话，另外录制一个脚本来覆盖那部分的用户模型会没那么痛苦。

4.       小结

本文介绍了3种模拟个别用户行为模式的方法，以及如何在Rational TestManager中使用。你可以使用全脚本路径方法、脚本片段方法和灵活脚本方法中的一种或者组合来有效地模拟任何的个别用户行为模式。本系列的下一篇文章将详细介绍如何使用TestManager创建测试套件来准确模拟全部的用户群，而不仅是个别用户。

5.       参考

“Website Stress-Testing” by Serdar Yegulalp (ExtremeTech Web site)

6.       附录（单词）

distinction：区别, 差别
simplistic：过分单纯化的
make sense：有意义
access to：有权使用
alternative：可供选择的办法
universally：普遍地,全体地,到处
inherent：固有的, 内在的, 与生俱来的
drawback：缺点, 障碍
redundant：多余的,冗余的
yield：出产, 生长, 生产
eliminate：排除, 消除
surefire：准不会有错的, 一定能达到目的的
Survey：调查,测量
in concert with：和...相呼应［合作］
leave out：省去,不考虑
out of curiosity：出于好奇心
original version：原著

 
第三章 模拟个别的用户模式

Web应用特色是做同样的事情可以有多种的操作路径，同样的有多种浏览方式可以到达相同的地方。对用户来说这是一件好事情，但对于测试者来说，这将使测试变得更加复杂，我们不仅需要知道用户在做什么，还要知道他们是如何做的。本文将论述如何使用Rational TestStudio来设计和脚本化测试套件（suite），解决用户可能选择不同浏览路径的问题，使得测试结果能更准确地代表用户的感受。

压力测试专家可能会辩论说测试脚本开发这种层次的详述仅仅是一项额外的工作，并不会增加项目的价值。如果我们的目标是进行压力测试的话，我会认同这种说法。在本系列的第一章中，压力测试定义为“在不包括用户延迟的高用户负载下，各种脚本的组合测试，但对确定用户体验并不合适”。回顾第一章，本系列专注于外部用户的性能体验与客户满意度之间的联系。作为负载测试的一部分，确定用户体验的关键是模拟个别用户的行为模式，而压力测试并不需要关注这些。（请阅读《网站压力测试》（Website Stress-Testing），该书对两者的区别做了明确的说明）。下文将论述如何将这些个别用户模式应用到用户组（群）中。

本系列的第二章论述了如何模拟个别用户延迟，类似的，本文将同样的基于在Noblestar多年的测试经验并以TestStudio进行示范。本文适用于TestStudio所有等级的用户，但更适用于中高级用户。我建议你将本文提到的观点应用到一个你清楚其用户负载、用户模式和用户体验度量的网站上进行有效性验证，将用户体验结果与实际结果进行比较。

1.       确定用户模式

为了准确地收集到用户体验度量，你必须在适当的时间，将适当的压力应用到系统适当的部分上。这听起来好像很复杂，但实际并非如此。你可以从确定个别的用户模式开始。我会介绍一些不同的方法，并以在线书店为例说明如何确定用户模式。

假设你是书店的经营者，希望从性能视角来了解用户在网站上购书的情况。首先需要回答一个问题：有一个回头客（return user）登录网站后想买一个最新的畅销书New York Times，他需要通过哪些页面来完成？我们可以得到如图1的购书路线图（如何生成这个图将在下文详细论述）。

 图1 购买小说的主要路线图

上图的例子中，所有用户从首页开始，通过三种方式其中的一种来进行：

• l         搜索书名或作者
• l         到小说分类中慢慢查找
• l         直接在畅销书闪烁的链接中找到它

每种路径的用户比例上图已经标示出来了，所有用户都买了书。这是一个非常简单的例子，但这些概念可以很容易地应用到复杂的情况。注意，上图每条路径确定了一种活动，但并未包括活动的具体步骤或访问的页面。

上图的实现方法对你的测试目的来说也许已经足够准确，但也许不够。方法如下：在为此模型选择了购书网站作为例子后，我认为最通常的用户活动就是买书了。接着访问这个网站，找出买书的所有可能的路径，以一个网站用户或测试者的身份，通过自己的经验和直觉，评估自己访问每条路径的可能性。最后完成了上面的图形。

运用你的直觉和最佳猜测的方法，有两方面的好处：（1）在用科学的方法识别用户模式之前，已经对网站有了一个直观的感受；（2）以此来验证用更科学的方法获得的用户模式，也很有意义。由于我无法获取到更科学的信息（例如日志文件，流量监控软件，系统设计文档，系统管理权限等等），所以我只能到此为止，但你可以做得更好。

如果你正在进行一个真实的测试，那么可以用以下的任一种方法来测定用户模式：

• l        如果测试的是一个已发布的网站，那么可以通过流量监控软件（如WebTrends、LiveStats）的统计信息来测定实际的数据和分布情况。这些软件在正确配置之后，能够以易于理解的图表方式告诉你每种用户活动的比例和行为路径。如果没有流量监控软件的话，也可以通过日志文件中的页面点击信息来测定用户活动分布。第四章将会对此进行更详细的论述。
• l        如果有网站技术规格说明书的话，它会告诉你用户最可能进行哪些活动，以及用户期望在哪些导航路径的指引下进行操作。有时功能测试脚本或测试用例也有助于用户活动和路径的确定。这些资料不会直接告诉你实际上用户是如何浏览网站的，但你能够间接地知道系统是如何与用户进行交互的。
• l       如果测试的网站是新开发的从来没有发布过，那么你可以尝试着从相似网站的管理员处收集到用户使用模式的信息。当然，这类网站通常最有可能的就是你们的竞争对手，因此它们的管理员可能并不会那么合作。
• l        如果以上三种方法都行不通的话，你可以进行简单的内部实验，通过员工、客户、朋友或家庭成员的帮助来测定不同用户是如何浏览网站的。如我在第二章提到的，对于从没有发布过的网站来说，我发现这是一种非常高效的数据收集方法，同时也是验证使用其它方法收集到的数据的一种有效途径。

2.       用TestStudio模拟用户模式

Rational TestStudio提供了很多种创建和模拟虚拟测试用户的方法，但就是因为有太多的方法，有时也会变得难以选择。下文将以在线书店为例，描述并论证三种用户模式的模拟方法，这同时也是个人觉得最简单和最通用的方法：

• l        全路径脚本方法：为每条浏览路径录制单独的脚本，并在测试套件（suite）中分配适当的用户比例。
• l        路径片段方法：为图形中的每一段线录制单独的脚本，并在测试套件中正确的组织起来。
• l        灵活的脚本方法：在录制的脚本中创建灵活的脚本，处理大部分浏览路径中的少数例外。

每个方法都可以与其它方法结合起来使用，模拟更复杂的用户模式。每种方法都有其固有的优点和缺点，下文将会提到。

2.1.      全路径脚本方法

三种方法中全路径脚本方法最容易描述和执行。这种方法为每个可能的浏览路径录制单独的端到端脚本，然后创建测试套件以适当的分布组织执行这些脚本。图2展示了购买小说的脚本中所包括的三种可能的路径。

图2 全路径脚本方法的购书路径

录制3个这样的脚本是相当简单的事情。请注意，图中主页访问和购书活动在所有的脚本中都是重复的，这会在其它方法的论述中再次提到。图3展示了脚本在TestManager测试套件中的用户比例情况。

图3 全路径脚本执行方法的测试套件

这是模拟简单用户模式的一个好方法，只需少量的脚本就能覆盖所有可能的用户路径。而且，也不需要手工修改任何脚本来模拟用户模式。由于每种用户都直接匹配一个脚本，当测试有安全的会话ID或cookie的站点时比较容易处理安全问题，也许这就是这种方法最大的优势。（我会在后续的文章中论述关于安全会话的处理）

但另一方面，这种方法也有较大的缺陷。首先，脚本中重复的功能意味着更多的开销，会降低当前测试环境下的虚拟测试用户数。如果你的测试实验室和我一样的话，你需要为这些消耗巨大的测试保留所有的资源，而你当然不希望硬件设备成为瓶颈而使得性能测试结果变得很糟糕。就个人而言，在大多数情况下我会尽量使每个套件的测试脚本数量少于12个。在不影响性能测试结果的情况下，你的主站点和代理站点的硬件越好，测试套件中就能容纳更多的脚本。

其次，还有关于动态数据方面的缺点。脚本中的冗余部分有时会包含一些每个虚拟用户都不同的数据（例如登录信息），可能会用到数据池。这会导致每个脚本都有独立或非常相似的数据池，以及用于控制这些数据逻辑的共享变量或持久变量。如果管理不当的话，这些将产生大量的开销。通常，尽可能地消除持久变量，并减少数据池的数量和大小，只产生必要的数据，是一个不错的做法。

最后，如果脚本中主页或者购书部分发生了变化，所有脚本都需要修改。如果变动较大的话，3个脚本都需要重新录制。对于已经稳定的已发布应用来说，这可能不会有这个问题，但如果测试的系统还在开发当中，那要好好考虑一下了。

2.2.      路径片段方法

路径片段方法也是一种相当简单的方法。这种方法为每段路径录制一个独立的脚本（也称分割脚本），如图4所示。这些脚本按适当的顺序和分布组成可被执行的测试套件。

图4 路径片段方法的购书路径

如你所见，和全路径方法相比，这种方法多了两个脚本，但脚本中没有了重复的活动。图5展示了TestManager中代表我们的书店浏览模型的一种测试套件组织方法。

图5 路径片段方法的测试套件

这种方法只需更少的脚本，对于简单的用户模式来说相当不错。虽然多了两个脚本，但不会比全路径脚本方法需要更多的开销。在本在线书店的例子中，将产生五个实际的脚本，但每个都比全路径脚本方法产生更少的开销，所以总的开销其实差不多。这种方法真正的优点是通过没有冗余的脚本，消除多脚本访问同一个数据池，以及多个类似或同样的数据池的可能性。

这种方法同时也降低了当被测应用发生局部改变时重新录制脚本的可能性。对于采用迭代式开发和测试的应用来说，这将是一个巨大的好处。

这种方法有两个缺点：（1）可能需要用到共享变量，（2）如果脚本或场景运行不正常，调试会变得复杂，并导致共享变量的使用。如果场景的正确运行需要在两个脚本之间传递信息，则只能用共享变量来传递信息。这个复杂的主题会在以后的文章中提到。如果你将录制的分割脚本在场景中组合起来，但与录制时的顺序不同的话，脚本可能会运行不起来。在脚本录制前谁也不知道分割后的脚本是否能运行起来。如果不能正确回放，那通常是没有通过共享变量来传递信息的问题。

2.3.      灵活的脚本方法

灵活的脚本方法能让你模拟在主要的浏览路径中的少量例外路径。例如，在我们的在线书店中，每条路径上的顾客可能都会打开其它信息窗口，也并不是所有的顾客最终都会买书。

图6 包含了少数例外的购书浏览路径

图中的虚线表示了一些偏离主浏览路径的活动。在Name Search路径中有10％的用户会看帮助，在Select Best Seller路径中有25％的用户会阅读读者评论，在Fiction Books路径中有5％的用户会参与调查活动。而且，所有用户中的25％并没有买书就离开了。

在这种方法中，测试套件模型可以保留但必须重新考虑脚本。幸运的是，通过有计划地处理这些可选的偏离活动的脚本，避免了在测试套件中增加任何的全路径脚本、分割脚本、用户组等。我们只需简单地在分割的脚本中增加一些代码就能处理这些偏离。这些处理需要最基本的C编程经验，但我会和你一起做下去，这样的话即使你没有编程经验也能通过简单的复制、粘贴完成这些代码。

让我们来看看如何修改Name Search这段代码，以满足客户在搜索之前先看帮助这样的场景。列表1显示了满足场景的部分代码。

列表1 查看帮助信息的Name Search脚本

那么我们如何模拟查看帮助的10％用户呢？这个简单，我们在每次脚本被调用时生成一个1～10之间的随机数字，当数字为1时将进行查看帮助的操作，否则跳过这一步。请看列表2。

列表2 模拟10％的用户查看帮助信息的脚本

其它3个可选路径也能够用类似的方法实现。

灵活的脚本方法对于处理这种不需要完成整个脚本，起始点和结束点相同的活动非常有用。这种方法的另一个很好的例子如用户的注册过程，对于初次使用的用户需要进行账号注册才能登录系统，但是，并非所有的用户都需要，因此，这也是脚本中需要考虑的。

比其它两种脚本方法来说，这种脚本方式实现起来更快并且所需的开销更少，同时冗余的代码也更少。把这种方法和其它的两种合起来一起使用，将能模拟几乎所有的用户模式。

这种方式的缺点在运行时就会显露出来。在录制过程中，有些socket可能会在if语句外面打开并在if语句里面引用，回放时如果if语句里面的脚本不执行的话会导致脚本执行失败。还有其它一些类似的问题。如果遇到这样的问题，你可以进行脚本调试，但这里我不会详细讨论。一般而言，弹出式的独立浏览窗口上的活动不会出现这种问题。

2.4.      选择哪种方法

在大多数情况中，选择使用哪种方法来模拟用户使用模式只是一个个人偏好问题。上面已经提到，每种方法都有其优缺点，你只能根据具体的情况选择最佳的那种。在测试复杂的站点时，我通常会将3种脚本方法组合起来使用。

下面有一些选择方法供参考：

当站点满足以下情况时使用全路径脚本方法：

• l        只有少量的浏览路径冗余
• l        浏览路径中只有少量的datapool冗余
• l        使用安全的session
• l        通过URL的参数传递数据

当站点满足以下情况时使用路径片段方法：

• l        有很大的浏览路径冗余
• l        浏览路径中有大量的datapool冗余
• l        有限的安全性
• l        没有通过URL的参数传递数据

当站点满足以下情况时使用灵活脚本方法：

• l       存在起止都在同一页面的可选浏览路径
• l        存在弹出窗口的链接

为了证明这些概念的简单和有效，我建议大家跟着下面的练习一起做，前提是大家已经知道如何录制和回放VU脚本，以及如何在录制过程中插入timer。

4.1.      确定用户延迟和分布情况的练习

选择一个完全静态的网站，因为每次都变化的网站只会妨碍学习过程。接着确定一个导航的路径，比如在onblestat.com网站的首页上，点击About Us，然后点击Essentials，最后点击Heritage。首先在记事本上记下你认为每个页面可能的用户分布和延迟时间，然后找一些同事根据纸上的指示进行操作，并记录下他们在这些页面的停留时间。看看实际的时间与分布是否接近于记事本上的记录。

4.2.      在VuC的练习中模拟用户延迟和分布情况

在这个网站的不同测试时间，我用尽了4个方法来确定用户延迟和分布情况。在所有的案例中，根据正态分布曲线获得不同的时间值。出于对于这个例子的考虑，我们假设并非总是如此，这样你才能看到如何使用内置的C函数和我之前介绍的新的normdist函数来产生时间延迟。

我重申一点，这个例子中的延迟和分布并不能很好地代表实际网站交互。我会在这篇文章地讨论中创建练习来论证所有的主题。

首先基于一个静态网站录制一个简单的VU脚本（我用noblestat.com来录制）。录制时用timer将每个页面包括起来。（你也可以用timer block，但录制出来的原始脚本有点差别，我会在第5章详细介绍timer block）。录制3个页面，Home Page、Page1、Page2。

录制完成之后用1个虚拟用户回放一下，确保没有修改之前的脚本回放成功。然后再用Robot打开脚本并找到第一个stop_time命令。这部分的脚本如下：

这部分代码停止了计时器对加载主页的时间统计，并开始了对加载Page1的计时器统计，再等待了差不多12秒后才开始对Page1的下载。实际上，你并不想将12秒的延迟时间也算在计时器里面的，还有并不希望12秒是静态值，而是一个6秒到18秒延迟范围的正态分布。你可以通过删除或注释掉start_time命令后的set Think_avg这一行，同时在stop_time和start_time命令之间加入delay(uniform(6000,18000))来实现。这段代码显示如下：

现在这段代码将统计主页和Page1的真正加载时间，等到用户阅读完主页之后才访问Page1页面，并且等待时间是一个6到18秒正态分布下的随机时间。

找到Page1的stop_time命令，原始代码如下：

和上面一样，这段脚本停止了Page1的计时器，开始了Page2的计时器，并延迟了8.5秒左右的时间。这里，你希望把8秒的静态延迟改为最小值6秒、最大值14秒、标准差2秒的正态分布延迟。如果你没有计算延迟范围标准差的方法，那么将最大延迟时间减去最小延迟时间再乘以25％是一个比较精确的、可以接受的方式。

将normdist函数拷贝到脚本中#include命令的下面，代码如下：

然后删除或注释掉start_time命令下面的set Think_avg这一行，并在stop_time和start_time命令之间添加delay(normdist(6000,14000,2000))。这段代码如下：

再次强调，没有normdist函数的话脚本执行将会出错。现在这段代码也能正确的统计Page1、Page2的加载时间了，并且在用户阅读Page1之时有一个随机的正态分布时间。如果你愿意的话，可以检查一下全部修改后的脚本。

5.       高级用户：双峰正态分布

为了应用这种分布，你应该有Rational TestStudio的性能测试经验以及C语言的基本了解。我测试过的很多网站就有些这样的页面，它们的用户访问呈双峰正态分布。想象一个有很多文字的页面，首次访问时用户可能会详细地阅读这些文字，下一次你就会直接的跳过这个页面到下一个页面了。这种页面的用户延迟时间如图8所示。

图8 文字性网页所展现的双峰正态分布

在这个例子中，假设60％的用户花了8秒的时间浏览了这个页面并寻找下一个链接，而其它40％的用户花了45秒的时间详细的阅读了整个页面。你会发现这是两个有着不同的最小值、最大值、标准差的正态分布。在脚本中模拟这种分布的方法生成一个0到10的随机数，并创建一个控制逻辑，当随机数字落在1～6之间时实现左边的延迟，在7～10时实现右边的延迟。

这段代码执行1000次后将呈现图9的数据情况。

图9 我们的脚本生成的双峰正态分布

如你所见，使用同样的方法，利用这段代码就可以轻松的改变分布类型和数值，以及控制每个峰值中不同的用户比例。把这些原理放在一起形成各种不同的组合，就有可能模拟几乎所有用户的延迟分布，并达到相当级别的精确度。举例来说，还可以再添加一个10秒到2分钟的均匀分布来模拟其它15％的用户，而这种可能性是无止境的。

6.       小结

这篇文章给你带来的关键点很简单：模拟的用户越精确，性能测试结果的可信度就越高。精确用户模拟的第一步就是模拟用户延迟。本文讨论了如何确定用户延迟时间，以及如何使用Rational TestStudio把它应用到你的虚拟用户脚本中。接下来的2篇文章将论述如何确定和模拟个别用户网站使用模式，以及如何将这些合并到单个用户组模型中。

7.       附录（单词）

It goes without saying：不言而喻，不用说
make educated guesses：做出有根据的推测
in-house experiments：内部实验
in case：万一
realistic：逼真的
significantly：意味深长地，值得注目地
bell curve：贝尔曲线
negative exponential：负指数
skew：歪斜的
programmatic：有纲领性的，计划性的
in-depth discussion：深入讨论
represent：代表，表示
parenthesis/parentheses：圆括号
jot down：草草记下，摘要记载下来,
co-worker：合作者，同事
come up with：提出，拿出
built-in：内置的，内置
reiterate：重申，重做
bracket：括在一起，括弧，支架
proportion：比例，均衡，面积，部分

网站的访问者们以不同的速度进行思考、阅读和打字，作为测试过程的一部分，你的责任是解决如何模拟并脚本化这些不同的速度。这些在Rational TestStudio中有许多方法可以实现，你将在《User Experience, Not Metrics》系列的第二章中学习到其中的一些。本系列文章的关注点是将客户满意度和外部用户的性能体验关联起来，这已经在本文的第一章解释过。本文及后续文章将提供必要理论，包括关于如何根据测试目的模拟实际用户，并根据多年的性能测试经验以录制或修改脚本作为例子来论证这些原理。

一些业内的专家称用户延迟的变化和实际测试结果并不相关，当用户众多时即使每个用户活动之间有20秒的延迟也会得到相同的结果。我会争辩说，如果是多年前单服务器架构、静态HTML脚本的情况下我可能会同意，但对于当今多层次、多功能的网站来说这是不可能的了。《科学的网站负载测试》（The Science of Web-site Load Testing）的作者Alberto Savoia对为什么20秒的理论并非事实进行了相当详细解释并提供了真实世界的实例和数学证明。

本文对各级别的TestStudio用户均有帮助，但对中高级用户尤佳。这里我介绍了脚本化不同的数学分布的方法，但你必须自己决定哪种才能最精确地匹配特定的场景。统计学的精确度在最终用户群的模拟上，对于每个网站来说是重要而独特的。

1.       确定用户延迟

用户登录，浏览主页，填写表格等需要多长时间？通过几种方法并结合网站上的用户活动能够大概获取用户延迟时间。最好的方法当然是使用生产现场上收集到的真实数据，但这几乎是不可能的，因为测试通常发生在网站发布投入使用之前。正因为如此，有时需要根据网站的行为做出有根据的推测。最能接受的四种方法如下：

• l       当测试的网站已经投入生产时，你可以从每个页面的日志文件中知道浏览（或打字）的时间，并从中提取出平均差和标准差，并确定实际值和分布状态。有了这个信息，每个页面的用户延迟时间就可轻易确定。你的生产现场也可能拥有能直接提供这类信息的网站流量监测软件，例如WebTrends或LiveStat等。
• l       在日志文件或时间、资源记录缺乏的情况下无法进行详细的日志分析时，你可以利用一些（调查）公司已经收集到的度量和统计数字。这些统计数据来自于用户或站点的客观抽样，提供了平均页面浏览时间和用户会话持续时间。尽管这些数字不是来源于你的特定站点，但是作为近似值来说已经很不错了。图1是来自NetRatings的一个样本数据。
   

 图1 NetRatings提供的样本数据

• 如你所见，这是非常高层次的信息，对模拟实际用户或许有用，也或许没用。图中最有用的信息是“观看页面的持续时间”（Duration of a Page Viewed），报告了用户观看所有类型网页的平均时间。其余的统计信息由浏览网站的庞大的用户群组合统一汇总而成。
• l       假如你没有日志文件，或者认为来自其它公司的度量指标不具备代表性的话，你可以通过员工、客户、朋友或家庭成员们运用简单的内部实验来进行，例如，新用户和老用户的页面观看时间是不同的。这种方法也被认为是“剪贴板和秒表法”。对于还没有投入运行的网站，或者通过其它方法收集到的数据进行验证，我觉得这是一种非常有效的数据收集方法。
• l        最后的手段是通过你的直觉或猜测来评估这些延迟的范围。对于逼真的负载测试来说，即使是这种最后的方法也要比忽略用户延迟的变化好得多。每个用户在每个页面消耗同样时间，这样的负载测试虽然简单，但不逼真，并且会产生令人误解的结果。  

2.       了解延迟的范围和分布情况

现在你已经知道了用户在页面上所花的时间及其范围，但还没有最终完成对用户延迟的模拟。你必须使用户的延迟时间多样化，否则服务器将会呈现如图2的负载情况。

 图2 条纹式的响应图

在上面的响应图中，每个红点都代表一个用户活动（在这里是页面请求），水平轴是时间，以秒为单位, 从测试开始时计算，垂直轴列出了每个虚拟用户。这个响应图是一个典型的“条纹式”（Striping）请求，这必须在负载测试中尽量避免的。上图是一个压力测试的好例子，但非负载测试。如果你拿一个尺子垂直地放在图上并从左到右缓慢移动，在垂直方向上，你会看到这些代表了用户活动的红点几乎是在同一线上，这也表示了服务器在同一时间接受到的用户请求。这是对实际用户群的非常差的刻划。现在看看图3。

 图3 非条纹式的响应图

如果你同样地用尺子来量一量，你会发现这次红点分布得更加均匀一些。虽然还不完善，但明显地更加贴近实际用户的情况。这两个测试运行唯一的区别是后者有了一定的随机延迟，而不是绝对的延迟。

在对上面的两个例子进行有计划地调整之前，有3点信息是必须知道的。在第一个例子中，我只是使用了脚本录制时的平均延迟时间。第二个中，我加入了最小和最大的延迟值以及分布。有很多这种分布的数学模型，我将重点介绍最常用的两个：均匀分布（uniform distributions）和正态分布（normal distributions），为了完整起见同样介绍了负指数分布。这个分布并不经常用到但也不是没用，高级程序员可以将这种分布和其它数学函数结合起来进行某些用户模式的模拟。

介于最小值和最大值之间的平均分布是最容易模拟的。这种分布模型只是简单的从上下边界中选择随机的数字并构成均匀分布，这意味着生成的数据并不会只在数据范围的中间或两边。图4显示了1000个0到25之间的平均分布情况。

图4 最大和最小值之间的均匀分布

正态分布，也称为贝尔曲线，更难以模拟但也更加准确。这种分布模型随机地选择数字，并通过对中心值或平均值的选择频率进行相应的加权。图5展示了在0到25之间产生的1000个数字的正态分布情况（平均值为12.5，标准差为3.2）。在没有可用的实际数据的情况下，正态分布一般都被认为是最准确的数学模型。

图5 理想的正态分布

负指数模型的分布情况如图6所示，这种模型延迟时间的频率明显地向末端歪斜。我觉得这种分布很少有用，但出于完整性考虑这里还是包括进来了。图6显示了在0到25之间产生1000个数字的负指数分布情况。

图6 负指数分布

3.       在TestStudio中生成时间延迟

使用Rational TestStudio的VuC语言，有很多方法可以生成时间延迟。对于如何使用Think_avg及相关的命令和参数来实现，Rational的文档和培训资料已经做了详细的说明，这里不做深入讨论，只做简要介绍。这个方法只有在Think_avg命令不在计时器（Timer）里面或附近时才有效。我发现Think_avg命令更容易代表客户端的处理过程，但对用户模型来说并不合适。关于计时器和客户端处理时间模型将在后续的文章中详细讨论。

当脚本中的用户延迟不包含在计数器中的时候使用delay命令。下面是使用delay命令创建静态值以及均匀、负指数、正态分布以实现用户延迟的讨论。

如果已经明确某些活动消耗了所有用户8秒的操作时间（很少，但有可能），可用以下命令：

括号中的数值是静态延迟值，以毫秒为单位。此命令的语法是delay(value);，静态延迟一般只用在精确模型中。

如果确定用户在网站上执行活动的时间在6到12秒之间，那么均匀分布能准确地代表实际用户。命令如下：

在这个例子中，6000是最小值而12000是最大值，以毫秒为单位。此命令的语法是delay(uniform(min_value, max_value))。

如果确定用户在网站上活动的时间在9到15秒之间，但大部分用户接近9秒而不是15秒，同时没有用户少于9秒，这时使用负指数分布将最准确。典型的例子比方是只有当9秒的短片播放完后，下一步的按钮才会显示。命令如下：

在这个例子中，9000是最小值而15000是最大值，以毫秒为单位。此命令的语法是delay(negexp(min_value, max_value))。

在VuC函数中并没有创建正态分布的延迟命令。为此，我们用下列的函数以及delay命令的组合构成了正态分布。注意，normdist函数在每个脚本中必须直接放在#include命令下面。

将这个函数以0毫秒为最小值，25000毫秒为最大值，3200毫秒为标准差，执行1000次产生的正态分布如图7所示。需要注意的是，这里使用了与理想正态曲线相同的参数，只是把单位由秒替换成毫秒。大家可以看到，这个曲线图与图5的理想正态分布几乎是一样的。

图7 用normdist函数生成的正态分布

delay函数在正态分布中使用频率最高。可用以下命令来模拟一个10秒到35秒之间，标准差为3.2秒，呈正态分布的用户延迟（对于上面的例子而言，只是将时间右移了10秒）：

这里10000是最小值而25000是最大值，3200是标准差，均以毫秒为单位。此命令的语法为：delay(normdist(min_value, max_value, std_deviation))。记住，如果脚本里面没有normdist函数的代码将会报错。

第一章 介绍

随着越来越多的人依托互联网从事日常业务操作，应用程序的性能在成功的电子商务解决方案中变得至关重要。为了确保成功，很多公司开发了工具和方法来测试和调整应用程序的性能。但这些工具和方法基本上都是关注在系统度量上的优化，而非用户体验。《User Experience, Not Metrics》系列文章将对如何确定真正的用户体验，以及使用Rational Suite TestStudio测试工具，以一套行之有效的方法对应用程序性能调优的相关方面进行讨论，侧重于最终用户的性能体验上。在本简介中，旨在对整个系列文章中的相关概念和术语进行介绍。

1.       简介

有多少次因为网页速度太慢，你被迫终止了该任务并选择了其它站点？大约有46％的消费者会因为站点过于技术化或者性能问题而选择了离开。换言之，如果你的站点速度太慢客户就会离去，这是所有的互联网用户都熟知的道理。这时你的第一想法不是“哎呀，不知道站点的吞吐量怎样”，而是“简直太慢了!我可没有时间在这里等，到别处去吧”。现在想想，人们离开你的站点是否因为性能问题？

基于此，用户不会在乎你的吞吐量、带宽或每秒点击率等指标，他们只要一个良好的用户体验。市场上有大量的书讨论了如何设计良好的性能，还有更多的书把重点放在如何使得站点更加直观、生动、令人愉悦和易于操作上。关于速度的好处也讨论过，但如何真正预知并调优系统来提高用户体验呢？那就是直接的用户体验测试了。有两种方法做到这一点。可以把站点直接投入到能够进行数据采集和系统调优的生产环境中，并祈祷你的站点不会太慢或崩溃。另一种明智的选择是模拟真实的多用户活动，进行重复的测试和调优，最后再投入到生产环境中。这听起来是一个简单的选择，但如何准确地模拟真实的多用户活动呢？这就是本文尝试着去解答的问题。

2.       术语和概念

理解以下的术语和概念对于理解后续的文章非常重要。

性能测试（Performance Testing）：通过运行实际所期望的用户模式，确定和消除应用程序或系统的瓶颈的过程。见图1。

工作量分布（Workload Distribution）：系统中一组用户功能操作的一种体现，有时被理解为用户群模式。以一个零售站点的一天中使用情况为例，大部分的用户在购物，还有的在搜索特定的商品，有的在结账并最终离开站点，同时可能也有管理员在更新商品价格。负载分布是基于一段时间内用户执行特定功能的比例。在以上的例子中其负载分布可能是：购物－83％，商品搜索－5％，结账－10％，后台管理－2％。

从用户体验的角度来看，性能目标（Performance Goals）可以表示为执行预定数量的并发用户时所允许的最大响应时间。

响应时间（Response Time）是从最终用户的角度来衡量的。例如，从用户点击登录按钮到下一页面完全加载的时间。

会话持续时间（Session Duration）是单个用户在一次站点访问过程中的所有持续时间总量，会话持续时间因用户类型而异。

并发用户数（The number of Concurrent Users）是特定时间点上实际访问站点或活跃会话的总用户数。

每小时的使用总量（Total Hourly Usage）是一小时内访问站点的期望用户数，通过将会话持续时间乘以并发用户数计算得到。

基线（Baselines）在此理解为用于时间比较起点的单用户、单脚本的测试。

用户延迟（User Delay）是插入脚本的一段等待时间，以便当脚本回放时和实际用户有相同的步调。

在本系列文章中可能用到一些不同的人有不同理解的术语。这些术语说明如下。

负载测试（Load Test）是一种包括等待时间，准确模拟目标用户群操作的多用户测试。负载测试可用于执行不同的用户负载以获取诸如站点所能支持的最大用户数的信息，（并以次判断）是否能够满足预期的性能目标。

压力测试（Stress Test）是由多个脚本组成的在高用户负载下，不包括等待时间的一种测试。这类测试对于评估系统在一定负载下的稳定性和功能性比较有用，但不适合于测定用户体验。

基准（Benchmarks），收集有关系统硬件、支撑软件的度量指标。例如，可以通过基准测试访问一个大图片来测定Web服务器的吞吐量和每秒点击率。

3.       系列文章概览

本系列每月将会有一篇新文章发布。所有文章将包括所介绍的实际应用的方法和技术的讨论、现实中的例子和（或）代码样本，以及“Now you try it”的练习。每篇文章都会被分成初级、中级还是专家级，这些等级通常指的是技术实现讨论所需代码的复杂性。每篇文章中提到的概念将适用于所有专业知识水平。下面简要描述一下前12篇文章。

3.1.      模拟真实用户（Modeling Real Users）

确定真正用户体验的关键之一是有效的模拟实际的用户和用户群。本系列的前3篇文章将讨论如何从应用程序的角度出发，使用Rational Test Studio来准确模拟单个用户或整个用户群。相关主题包括：

Part 2: Modeling Individual User Delays

Part 3: Modeling Individual User Patterns

Part 4: Modeling Groups of Users

3.2.      （捕获）有意义的时间

在模拟实际用户之后，从这些用户的角度获取系统（应用）的响应时间变得相当迫切。只是简单的捕获这些时间是不够的。除非能够解释这些时间的模式，否则这些时间是没有意义的。接下来的3篇文章讨论了如何使用Rational Test Studio来捕获和解释真正的时间体验。相关主题包括：

Part 5: What should I time and where do I put my timers?

Part 6: What is an outlier and how do I account for one?

Part 7: Consolidating and interpreting Times

3.3.      向干系人汇报（Reports to Stakeholders）

我不得不承认干系人和决策者需要测试报告，我们不能只是简单地告诉他们测试结果是“行”或者“不行”。我们需要采集大量的数据并形成简明、有意义的报告。这部分的文章将讨论哪些测试类型将给干系人和决策者带来更多的价值，以及如何使用Rational Test Manager来收集数据和生成各种摘要信息。相关主题包括：

Part 8: What Tests add value to stakeholders?

Part 9: Summarizing across multiple tests with accuracy

Part 10: Creating a Degradation Curve

3.4.      高级主题

本系列的最后主题将围绕一些曾经给作者带来困扰的高级问题展开讨论。这些文章采用案例研究的形式。每个案例研究概括了客户问题的特殊需求、作者的形成解决方案的思维过程、可能的解决方案的要点，以及详细描述了挑选办法。相关主题包括：

Part 11: Handling Secure Session ID’s

Part 12: Conditional user path navigation (intelligent surfing)

Part 13: Working with Unrecognized Protocols

4.       小结

本系列文章是鲜明的：相对于当今的计量习惯，用户视点是一种更加可靠的网站性能衡量的方式。这一系列的文章旨在教导读者如何使用Rational Test Studio来模拟多用户的活动，以及一个经过验证的优化最终用户性能体验的方法。本文将分享一些关于如何有效运用方法学，以及利用Rational测试工具等有用的信息，甚至是一些有用的贴士（Tips）来规避曾经令专家们也感到为难的问题。希望大家喜欢并保持关注。

5.       附录（单词）

User experience 用户体验

Application’s perspective 应用程序的角度

Fraction of an hour：以小时为单位的分数形式

Stakeholders 干系人

Concise and meaningful report 简明、有意义的报告

imperative 紧急的、必要的