模板
教程
环境
性能
功能
管理
基于用户体验的软件性能测试：第三章 模拟个别的用户模式
压力测试专家可能会辩论说测试脚本开发这种层次的详述仅仅是一项额外的工作，并不会增加项目的价值。如果我们的目标是进行压力测试的话，我会认同这种说法。在本系列的第一章中，压力测试定义为“在不包括用户延迟的高用户负载下，各种脚本的组合测试，但对确定用户体验并不合适”。回顾第一章，本系列专注于外部用户的性能体验与客户满意度之间的联系。作为负载测试的一部分，确定用户体验的关键是模拟个别用户的行为模式，而压力测试并不需要关注这些。（请阅读《网站压力测试》（Website Stress-Testing），该书对两者的区别做了明确的说明）。下文将论述如何将这些个别用户模式应用到用户组（群）中。
本系列的第二章论述了如何模拟个别用户延迟，类似的，本文将同样的基于在Noblestar多年的测试经验并以TestStudio进行示范。本文适用于TestStudio所有等级的用户，但更适用于中高级用户。我建议你将本文提到的观点应用到一个你清楚其用户负载、用户模式和用户体验度量的网站上进行有效性验证，将用户体验结果与实际结果进行比较。
1.确定用户模式为了准确地收集到用户体验度量，你必须在适当的时间，将适当的压力应用到系统适当的部分上。这听起来好像很复杂，但实际并非如此。你可以从确定个别的用户模式开始。我会介绍一些不同的方法，并以在线书店为例说明如何确定用户模式。
假设你是书店的经营者，希望从性能视角来了解用户在网站上购书的情况。首先需要回答一个问题：有一个回头客（return user）登录网站后想买一个最新的畅销书New York Times，他需要通过哪些页面来完成？我们可以得到如图1的购书路线图（如何生成这个图将在下文详细论述）。
图1 购买小说的主要路线图上图的例子中，所有用户从首页开始，通过三种方式其中的一种来进行：
搜索书名或作者 到小说分类中慢慢查找 直接在畅销书闪烁的链接中找到它每种路径的用户比例上图已经标示出来了，所有用户都买了书。这是一个非常简单的例子，但这些概念可以很容易地应用到复杂的情况。注意，上图每条路径确定了一种活动，但并未包括活动的具体步骤或访问的页面。
上图的实现方法对你的测试目的来说也许已经足够准确，但也许不够。方法如下：在为此模型选择了购书网站作为例子后，我认为最通常的用户活动就是买书了。接着访问这个网站，找出买书的所有可能的路径，以一个网站用户或测试者的身份，通过自己的经验和直觉，评估自己访问每条路径的可能性。最后完成了上面的图形。
运用你的直觉和最佳猜测的方法，有两方面的好处：（1）在用科学的方法识别用户模式之前，已经对网站有了一个直观的感受；（2）以此来验证用更科学的方法获得的用户模式，也很有意义。由于我无法获取到更科学的信息（例如日志文件，流量监控软件，系统设计文档，系统管理权限等等），所以我只能到此为止，但你可以做得更好。
如果你正在进行一个真实的测试，那么可以用以下的任一种方法来测定用户模式：
如果测试的是一个已发布的网站，那么可以通过流量监控软件（如WebTrends、LiveStats）的统计信息来测定实际的数据和分布情况。这些软件在正确配置之后，能够以易于理解的图表方式告诉你每种用户活动的比例和行为路径。如果没有流量监控软件的话，也可以通过日志文件中的页面点击信息来测定用户活动分布。第四章将会对此进行更详细的论述。 如果有网站技术规格说明书的话，它会告诉你用户最可能进行哪些活动，以及用户期望在哪些导航路径的指引下进行操作。有时功能测试脚本或测试用例也有助于用户活动和路径的确定。这些资料不会直接告诉你实际上用户是如何浏览网站的，但你能够间接地知道系统是如何与用户进行交互的。 如果测试的网站是新开发的从来没有发布过，那么你可以尝试着从相似网站的管理员处收集到用户使用模式的信息。当然，这类网站通常最有可能的就是你们的竞争对手，因此它们的管理员可能并不会那么合作。 如果以上三种方法都行不通的话，你可以进行简单的内部实验，通过员工、客户、朋友或家庭成员的帮助来测定不同用户是如何浏览网站的。如我在第二章提到的，对于从没有发布过的网站来说，我发现这是一种非常高效的数据收集方法，同时也是验证使用其它方法收集到的数据的一种有效途径。
