性能测试用户模型(3)

　　会员

　　解释：100个会员，有一半是进行买书流程的，还有一半是进入账号进行信息维护和查看订单状态。

　　管理员

　　解释：管理员操作都需要从登录管理页面开始，操作最多的是查看订单状态(50%)，其中有一半的订单需要修改，增加书目和取消订单都占25%。

　　供应商

　　解释：供应商也需要从管理员页面登录。供应商用户只能进行查看报表操作，可以选择多种不同类型的报表进行统计，平均每个用户需要查看3种报表。

　　确定了各个用户角色的模型后，再根据各用户所占的比例，合并成整体用户群的使用模型。

　　解释：从整体考虑，新用户占 20%，会员70%，管理员4%，供应商6%。不同类型的用户通过不同颜色来标识，所有的用户都需要从主页开始访问系统。此模型反应了系统的整体使用情况，也即测试场景需要模拟的压力。而测试场景中具体要执行的测试脚本，则主要根据各类型用户各自的用户模型来开发。

　　在绘制出模型图后仍然需要不断的同技术人员、业务人员沟通讨论，找出模型中不合理或者遗漏之处，并逐步完善，直到共同确认。甚至是测试结束后，也需要根据系统实际运行环境来不断调整，为后续的测试提供更准确的模型。

　　但只依靠模型图仍然不能有效的对压力进行描述，可以发现前文提到的种种基础数据信息目前还未得到使用，如用户操作的间隔时间、页面上需要输入的数据等等。没有模型，这些数据是缺少实用意义的;没有数据，模型图也无法得到应用。

　　基础数据分析

　　以下图表均取自互联网，本文是在“已经获取所需数据”的前提下，讲解性能测试的一些设计思路。至于如何才能取得这些数据，将在后续的文章中说明。

　　系统访问量分布

　　由系统的日访问量分布图，可知系统的访问压力集中在哪个时间段内。系统的压力是在一天中平均分布的，还是集中在某几个更小的时间段内。根据此信息，我们对测试场景的时间进行设计，如从分布图中明显看出每天的大部分访问量集中在9：00～11：00和14：00～16：00两个时段，那么就可以设计2小时内完成一半访问量的测试场景。

　　用户的平均活跃时间

　　用户活跃时间，是指用户一次使用系统的时长，可用来指导测试脚本的设计，即每个虚拟用户脚本应该在多长时间内执行完。

　　由系统访问量分布和用户活跃时间两个数据，可以对系统使用的并发度进行估算。比如已知系统在2个小时内有200访问量，且分布接近于平均，用户的平均活跃时间为30分钟，那么此时间段的并发度应为：200*30/120=50。这里并发度50传递的信息是，在一个用户活跃周期内，总共会有50个用户与服务端进行交互(即相对并发)。也就是说任意时间点，最大的绝对并发可能性是50，当然实际可能远低于此，可以根据业务特点再乘以相应比例进行估算。

　　在性能测试时，可以依据此数据设计系统高峰期压力的测试场景。比如我们已知，系统压力最大时，单位时间段内活跃用户有100人(并发度100)，那么这种压力场景，就可以以用户平均活跃时间为测试时间段，启动100个虚拟用户并在该时间段内完成各自的工作量。

　　页面停留时间

　　即请求之间的间隔(思考)时间，如在编辑页面上停留多久才会点提交按钮。如果无此数据，性能测试脚本只有运行时长是有数据(活跃时间)支撑的，脚本中的各请求之间的思考时间，只能通过常规判断和猜测，由性能测试人员自己掌控。收集到此数据后，性能测试脚本会更加符合真实用户的操作习惯，更加接近真实用户。

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