每个公司都有考评：季度的，年度的，项目的，个人能力的。每个主管都会想尽办法的去不断完善自己的考评天平，让它公平、公正、全面、却又不失针对性。最常见的做法，主管先定制一个通用模板，然后收集手下每个人的自定目标，双方详谈后定制出一份针对个人的考评方案。至于个人技能水平的考评，那就五花八门了。最常见的就是罗列出本行业在当前公司所需的所有技能，分类、细化、给出评判标准。但是考评时，我想基本上不会有公司会组织大家来考一次试，由此来决定个人技能的等级。一般都是从个人的平时工作内容，完成情况来做个大致估计。

说到这，我的本意不是要讨论如何去考评，而是针对考评本身这个事情，有点想法。个人技能的考评结束了，费时费力的做了这么多，除了给提升某人的职级，薪水涨了，我们到底还有多少地方会用到这个考评的结果？大多数主管在分配任务的时候，不否认的会有技能储备的考量，但是有多少主管在分配任务时会拿出每个人的技能考评结果，针对每个人（注意：是每个人）的弱项去有计划的安排工作？我想很多主管都是凭主观感觉，凭自己对手下人的了解去分配任务的吧，或者对于几个

---

 

3.       练习

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

在开始讲解之前，首先我假定你已经掌握了如何录制、回放VU脚本，如何在录制过程中插入Timer，以及如何用TestManager创建脚本套件。同时我也假定你已经阅读了本文的第2章，因此我会省去有关用户延迟时间方面的内容。下面的练习只需用1个用户，某些情况下只需2个用户就可以进行测试了。因此别对

 

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

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

压力测试专家可能会辩论说测试脚本开发这种层次的详述仅仅是一项额外的工作，并不会增加项目的价值。如果我们的目标是进行压力测试的话，我会认同这种说法。在本系列的第一章中，压力测试定义为“在不包括用户延迟的高用户负载下，各种脚本的组合测试，但对确定用户体验并不合适”。回顾第一章，本系列专注于外部用户的性能体验与客户满意度之间的联系。作为负载测试的一部分，确定用户

 

第一章 介绍

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

1.       简介

有多少次因为网页速度太慢，你被迫终止了该任务并选择了其它站点？大约有46％的消费者会因为站点过于技术化或者性能问题而选择