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 紧急的、必要的

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号