|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 >
|
|
考试要求：掌握
相关知识点：90个
|
|
|
|
|
负载压力测试需求分析既需要借助于相关的理论知识，又要依靠测试工程师在相关领域的经验积累，下面分别介绍一些理论知识及经验方法。
|
|
|
|
|
|
测试需求是应用需求的衍生，而且测试用例也必须覆盖所有的测试需求，否则，这个测试过程就是不完整的。主要有以下的几个关键点：
|
|
|
|
. 测试的对象是什么，例如“被测系统中有负载压力需求的功能点包括哪些”；“测试中需要模拟哪些部门用户产生的负载压力”等问题。
|
|
|
|
. 系统配置如何，例如“预计有多少用户并发访问”；“用户客户端的配置如何”；“使用什么样的数据库”；“服务器怎样和客户端通信”；“网络设备的吞吐能力如何，每个环节承受多少并发用户”等问题。
|
|
|
|
. 应用系统的使用模式是什么，例如“使用在什么时间达到高峰期”；“用户使用该系统是采用B/S运行模式吗”等问题。
|
|
|
|
我们来针对用户提出的问题，做一个简单的需求回答，如下表所示。
|
|
|
|
|
|
|
|
|
|
下面我们介绍80～20原理测试强度估算及UCML压力需求分析。
|
|
|
|
|
|
80～20原理：每个工作日中80%的业务在20%的时间内完成。例如，每年业务量集中在8个月，每个月20个工作日，每个工作日8小时即每天80%的业务在1.6小时完成。
|
|
|
|
举一个例子来看80～20原理如何应用与测试需求分析。
|
|
|
|
去年全年处理业务约100万笔，其中，15%的业务处理中，每笔业务需对应用服务器提交7次请求；70%的业务处理中，每笔业务需对应用服务器提交5次请求；其余15%的业务处理中，每笔业务需对应用服务器提交3次请求。根据以往的统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。
|
|
|
|
|
|
每年总的请求数为：（100×15%×7+100×70%×5+100×15%×3）×2=1000万次/年；
|
|
|
|
每天请求数为：1000/160=6.25万次/天；
|
|
|
|
每秒请求数为：（62500×80%）/（8×20%×3600）=8.68次/秒；
|
|
|
|
|
|
UCML（User Community Modeling Language）压力需求分析
|
|
|
|
UCML?是一个符号集合，这些符号可以创建虚拟系统用法模型，以及描述相关参数。当把它应用到负载压力性能测试时，这些符号可用于表示工作量分配、操作流程、重点工作表、矩阵和马尔可夫链等。负载压力性能测试工程师在决定测试中用到什么活动，以及它们发生的频率时，经常用到这些参量。UCML输出的结论图表可有效地应用于文档，甚至是测试计划、测试设计等，还可作为讨论和数据整理的依据。系统分析人员和用户还可以用它们回顾和验证工作流程和工作量的需求。
|
|
|
|
UCML?给支持负载压力性能测试的复杂数学模型创建一个直观的可视化模型，对于数学模型来说，UCMLT?不是代替品，而是一种补充。现在至少可以证明这一可视化技术对测试人员、应用用户、开发者、经理和商家来说都是相当直观的。根据我们的经验，它使类似于“此activity通用吗”、“为什么activityB必须以activityD作为先决条件，这是不正确的”，甚至“如何再次阅读重点工作表”这样的重要问题得到了更直观的表现。
|
|
|
|
没有专门对应于UCMLT?的画图工具，除了用SmartDraw画UCMLT?模型时，还可以应用PowerPoint、Microsoft Visio等软件来画，而且我们可以为Microsoft Visio和SmartDraw创建符号库。
|
|
|
|
UCMLT?不是一种工业标准，现在还不能证明是适用于任何类似IEEE的工业标准或规范。用户可以应用其中的全部或部分符号，或者按照需要来修改或改进它们。下面我们来看看UCML?的符号。
|
|
|
|
|
|
基本符号可以表示系统应用。在许多情况下，一个用法路径可以看作是一个应用会话。事实上，用法路径是UCML?的基础，因为项目组的所有成员早已理解了系统应用。
|
|
|
|
|
|
数量环是用来回答“多少”、“多大频率”问题的。圆圈里显示的是一个数或者百分比。例如，在模拟精确量的时候用数，不管人数的具体多少；在模拟整个用户群中的一部分时，用百分比表示。如下图所示为数量环。
|
|
|
|
|
|
|
|
|
|
描述线是水平的实线，表示activity和用户类型。每个描述线都标注了一个或多个描述内容，来显示用户类型、activity或运行路径。附在描述语句后面的圆括号里的内容是所有同类用户的百分比，或者是在一定时间段内运行这一activity、执行这条路径的用户百分比。在一定情况下，用数量环来描述特定用户类型、activity、数量和频率更直观。通常，当有多项标注的activity出现或者同一条线上出现相同的数量或频率时，使用数量环，当数量或频率附属于一个特定activity时，使用圆括号。
|
|
|
|
|
|
用户类型描述线在模型的最左边，表示将要进入已创建的应用中的用户类型，例如：基本用户、超级用户、管理员。与用户类型相关的百分比显示了所有用这种类型表示的系统中的用户比例。如下图所示为用户类型描述。
|
|
|
|
|
|
|
|
|
|
activity类型描述线表示系统的不同类型用户的activity和运行路径。线的上面列出了已完成的用户activity，或运行路径所查看的界面。由建模人员决定应该将特定activity的每个步骤列出还是简单地给activity命名。记录的关键是每个水平线表示毫无转折的到达该activity的直线路径。这条线可以分出支路也可以合并，表示通过该系统对行动路线的选择。选择特定运行路径的用户的百分比显示在路径始端的数量环里。在模型中任何一个指定点，所有运行路径的用户之和都是100%，与访问站点的人数相同。如下图所示为activity类型描述线。
|
|
|
|
|
|
|
|
|
|
垂直的虚线表示模型中的同步节点。如果同步节点已命名，就将它的名字写在线的上方。同步节点用于描述合并。有两种可以用同步节点符号表示的合并，即时间上的合并和运行点的合并。如下图所示为同步点。
|
|
|
|
|
|
|
|
时间上的合并意味着在进程开始之前，先到达同步节点的建模用户必须等待所有其他建模用户都到达此节点。在建立信息系统时，这是非常有帮助的。
|
|
|
|
运行点上的合并意味着，所有建模用户都运行通过了应用中的同一位置，但不一定在同一时间。网站的注册界面就是一个常见的例子。在这个例子中，所有用户在被允许访问其他界面之前，必须在同一网页上填写各自的资格鉴定。在开发脚本时鉴别这些运行同步节点是很有帮助的，因为它们可以为脚本、草稿、功能、程序等充当普通的开始/关闭点。
|
|
|
|
我们发现，在名称后用圆括号插入同步节点类型的注释很有帮助，例如：“同步点1（time）”。
|
|
|
|
|
|
系统运行时，常常要求用户进行一些不会改变其全部行为的选择或输入数据。模型中，用位于运行路径下方的一个虚线框来表示这些选项。如下图所示。
|
|
|
|
|
|
|
|
选择框需要标注一个词或断语，来描述那些随着用户的改变而变化的选择和数据。特定数据将会记录在模型内的电子数据表中。
|
|
|
|
|
|
模型中，条件是用户根据结果来改变其运行路径的节点。下面的例子里，假设用户要购买一本书。如果用户查询后，发现它有库存，用户就按照“Yes”路径购买此书。但是，如果此书无库存，用户就按照“No”路径取消此过程。如下图所示为条件。
|
|
|
|
|
|
|
|
|
|
在运行路径上，虚线的半圆弧表示循环，半圆弧所环绕的活动将重复执行。需要反复的次数或需要重复此行为的用户百分数（不是模型表示的所有用户），标注在数量环里。如下图所示。
|
|
|
|
|
|
|
|
|
|
除了运行路径中断的节点以外，构筑用户的跳出是非常重要的。指向数量环的下划线表示路径在具体某点处，将要跳出系统的用户百分比。记住，所有进入系统的用户都应显示退出。跳出系统的类型应记录在标签上，例如“Log Out”（如果用户基于首选方式退出系统）或“Abandon”（如果用户没有基于首选方式退出系统）。如下图所示为跳出路径单方式。
|
|
|
|
|
|
|
|
下面的例子显示了从运行路径跳出的多种方式。其中，50%的用户放弃了系统，40%的用户正在退出系统，因此他们是以首选方式跳出系统的（另外的10%从另一个运行路径跳出，没有给出表示）。如下图所示为跳出路径多种方式。
|
|
|
|
|
|
|
|
|
|
大多数应用是不局限于直线路径的。开始执行同一activity的一组用户，可能只是为了以后分支到不同的运行路径中。如果我们把activity线想象成汽车运行的马路，那么分支就表示由司机进行方向选择的十字路口。下面的例子显示了一个分支，可以在这个分支上选择两条路径中的一条离开主页。分支上用户百分数的和必须等于引起分支的界面上的用户百分比。这个例子里，主页有100%的用户，而分支上的百分比之和也是100%。如下图所示为分支一。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
带有分支的运行路径常遇到将不同分支合并到一起的情况。仍以交通类推，这就相当于来自不同道路的汽车行驶到同一条马路。下面的例子显示了两个不同路径合并到Update Billing Information这一activity。同理，合并前的用户的总百分比必须等于合并后的总用户百分比。如下图所示为分支合并。
|
|
|
|
|
|
|
|
另外一个常应用的合并是为了显示不同类型的用户在同一点进入了软件，如下图所示。这里，每个不同类型的用户用不同的颜色表示。这样做是为了在以后的模型中，使对应于特定用户组的行为能够通过颜色区分。每个用户类型后面都用圆括号标注了它的缩写，这些缩写在以后的模型中也可以应用。这对那种必须由黑白表示的模型特别有利。
|
|
|
|
|
|
|
|
我们可以将符号组合为User Community模型。
|
|
|
|
基本符号的组合使UCML?语言更加强大。通过组合符号，可以在一个能形成整个Community的虚拟模型的系统中，表示所有可能的用户运行路径。再以交通类比，将模型中的线想象成马路、每个建模用户想象成在这些路上行驶的汽车。把两条或更多条线相遇的点看作十字路口，将同步点看作是交通信号，将跳出看作是驶出轨道。数量环显示出马路的运行载重，因此创建了一个用户如何穿过软件的“地图”。
|
|
|
|
举个例子，我们将为在线书店建立一个UCML?图表。假设这是一个新的应用，所以我们没有可以分析利用的现存数据。经过一系列的采访，我们收集了下面的信息。它们是关于用户进入网站的activity和他们预期的相关量。
|
|
|
|
. 四种用户类型：新用户（20%），会员（70%），管理员（4%），商家（6%）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. 新用户可以开设账户（开设账户后就变成了会员）。
|
|
|
|
. 会员可以选择以下activity：进入系统、升级账户、项目结算、检查结算状态。
|
|
|
|
. 管理员和商家必须从主页进入系统，再从管理员界面开始。
|
|
|
|
. 管理员可以选择以下activity：添加新书、检查结算状态、升级结算状态、取消命令。
|
|
|
|
. 商家可执行以下报告：库存、上周销售额、上月销售额。
|
|
|
|
|
|
|
|
|
|
很明显，如上图所示包含了访问总结中所未提到的信息，这些信息是为最初草案而估计的。仔细观察还会发现，不是所有来自于访问总结的信息都囊括进来了。现在图标可以反馈到被采访者处了，以便他们确认或改正运行路径和用户量、添加或删除activity。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. 系统日常业务主要有哪些操作，高峰期主要有哪些操作。
|
|
|
|
|
|
|
|
选择重点交易的指标为高吞吐量、高数据库I/O、高商业风险。举例如下表所示，“登录”、“生成订单”以及“发货”为负载压力测试重点。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
如下表所示为任务频率表，负载压力测试需要模拟不同用户角色压力。
|
|
|
|
|
|
|
