性能测试用户模型

　　概述

　　在性能测试过程中，很重要的一个部分就是评估待测系统在一定压力下的性能表现。比如系统上线后，真实的性能到底如何?两年后系统的使用用户增加后，性能又如何?这些都是性能测试中，项目相关人最关心的问题。

　　所谓的性能表现，说的更直观一些，其实就是用户体验。用户不会在乎系统的处理能力是多少、吞吐量是多少，他们能够感受到的只是系统能否处理他们的请求、处理的速度有多快。

　　这里提到的一个关键词是“一定压力”，这个压力指的是系统在预期的线上场景中所承受的压力。只有准确的定义和模拟预期的压力，才有可能获取到实际场景中真实有价值的用户感受，而不是那些只存在理论意义的数据指标。

　　压力是由用户产生的，那么如何准确的定义和模拟用户的行为，也就成了问题的关键。

　　以往的性能测试中，用户的具体行为是由性能测试人员敲定的。性能测试以外的人员，大概只能了解性能测试会模拟多少个用户，针对哪些模块或者功能做测试，更进一步的还会明确虚拟用户的工作量和所需的时间。这些内容一般也就是性能测试方案中所描述的测试场景。

　　但这些信息仍然无法准确的对压力进行描述。比如同是100个虚拟用户，每个人需要在1小时内完成一定量的工作，如果这些用户在时间分布上是一个接一个的使用系统，那么对服务器来说，可能就和单个用户没有区别。再比如同是100个用户在线，每个人间隔30秒操作一次和间隔60秒操作一次，压力可能就会相差一倍。而这些直接影响到测试结果和有效性的细节，测试执行人以外的人员一般无法了解，有时恐怕性能测试人员自己都不明确，完全靠制作脚本过程中发挥，导致测试过程比较随意，测试结果的有效性也大打折扣。

　　有可能对测试结果产生影响的因素主要包括：活跃用户数量、用户活跃时间、用户操作频率(思考时间)、用户操作路径、系统访问量随时间分布、各页面访问量(工作量)分布等等。对这些因素考虑的越准确，测试的结果才会越有效。

　　本文正是试图对上述内容进行标准化的描述，制定一种规范的分析方法。通过此方法，让测试人员更准确的设计测试场景，让其他人员有机会了解到具体的测试过程，并且能对其进行监督和检查。最终达到“不同测试人员应该测出相同的测试结果”这一目的，也就是获得准确有效的性能测试结果。

　　本方法无法取代数据分析，而是应该作为其的一个应用，可以直观有效的对用户行为以及系统的压力做出描述，测试人员、开发人员、管理者和业务人员等所有项目相关人都会从其中受益。

　　术语定义

　　虚拟用户(Vuser)

　　性能测试中模拟的用户，用户的行为由测试脚本定义。

　　在线用户(或活跃用户)

　　一个时间段内，与服务器保持交互的用户，也称为活跃用户。需与论坛或者QQ上常见的“在线人数”定义区分，该类系统的在线用户不一定是活跃用户，在线只是一种状态。但在业务类系统中，一般只考虑活跃用户，可认为与在线用户通用。

　　相对并发用户

　　类似活跃用户，表示单位时间段内与服务器保持交互的用户，这些用户在理论上有同一时刻(即绝对并发)进行操作的可能(对这种可能性的度量称为并发度)。相对并发的说法主要是为了区分绝对并发，尽量避免使用“并发”这个容易引起歧义的术语。

　　绝对并发用户

　　同一时间点(严格的说是足够短的时间段内)与服务器进行交互的用户，一般通过测试工具提供的并发控制(如LR的集合点)实现。

　　并发度

　　在一个时间点上，可能与服务端进行交互的用户的数量，它表达的是“绝对并发”的一种可能性。

　　思考时间

　　用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的。

　　活跃时间

　　用户与服务器进行交互的持续时间。

　　基础数据

　　此分析方法依赖于以下基础数据，基础数据的详尽程度将直接决定此模型的有效性和准确性：

　　1、系统的访问量随时间分布关系。可以直观的观察到使用压力是如何分布在一天(一段时间)之间的，通过此数据来构建性能测试场景。

　　用户的活跃时间(与系统进行交互的时间)。用户的活跃时间是进行系统并发度估算的基础。比如已知系统的使用压力集中在4个小时内(平均分布)，此期间访问量为100，用户的平均活跃时间是30分钟，那么并发度估算为100/(4h/30min)≈12.5。

原文转自：http://www.uml.org.cn/Test/201306041.asp