任务
【任务描述】：性能测试需求分析是整个性能测试工作开展的基础，其质量直接影响性能测试结果，那如何对系统进行分析建模，并将其转化为可衡量的性能指标呢？
【任务目标】：熟悉性能测试的种类和常用的性能测试评价指标，掌握性能测试需求分析方法。
【任务储备】：
1、性能测试常用指标
（1）响应时间(Response Time)
响应时间(Response Time)指用户发出请求到请求响应所需要的时间。对用户来说，当用户单击一个按钮，发出一条指令或在系统页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象；对系统来说，响应时间的整个过程分三个部分: 呈现时间、数据传输时间和系统处理时间，呈现时间指浏览器对接收到数据的一个处理展示的过程，不同电脑硬件、不同浏览器可能有不一样的呈现时间。
（2）并发用户数
并发用户数指的是在同一时段与服务器进行了交互的在线用户数量，这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是“挂”在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。并发用户数量越大，对系统的性能影响越大，并发用户数量较大可能会导致系统响应变慢、系统不稳定等。软件系统在设计时必须要考虑并发访问的情况，测试人员在进行性能测试时也必须进行并发访问的测试。
（1）TPS
TPS(Transaction Per Second)，每秒事务数指系统每秒钟能够处理的事务和交易的数量，它是衡量系统性能的一个重要指标。事务是指用户某一步或者几步操作的集合，操作集合通常有一个完整的意义。如用户对某系统的一次登录，用户在购物网站是哪个对商品的一次确认支付过程。
（2）点击率
点击率是每秒钟用户向Web服务器提交的HTTP请求数。这个指标是Web应用特有的一个指标: Web应用是“请求－响应”模式，用户发出一次申请，服务器就要处理一次，所以点击是Web应用能够处理的交易的最小单位。如果把每次点击定义为一个事务，点击率和TPS就是一个概念。因此，点击率越大，对服务器的压力也越大。
（3）吞吐量
吞吐量是单位时间内系统处理用户的请求数量，它衡量的是软件系统服务器的处理能力。从业务角度看，吞吐量可以用请求数/秒、页数/秒、人数/天、处理事务数/小时等单位来衡量。从网络角度看，吞吐量可以用字节/秒来衡量。
（4）资源利用率
资源利用率是服务器或操作系统性能的一些数据指标，如服务器的CPU利用率、磁盘利用率等。通常需要关注的服务器资源有：
² CPU使用率：指用户进程与系统进程消耗的CPU百分比，长时间消耗的情况下一般可接受不超过85%。
² 内存利用率：内存利用率=（1-空闲内存/总内存大小）×100%，，一般可接受不超过85%。
² 磁盘I/O：一般使用%Disk Time（磁盘用于读写操作所占操作所占用的时间百分比）度量磁盘读写性能。
² 网络带宽：一般使用Bytes Total/sec度量，表示发送和接收字节的速率，可以判断连接速度是否有瓶颈。
2、性能测试方法
（1）负载测试
负载测试方法是指在被测系统上不断地增加压力，直到性能指标（如响应时间）超过预定指标或某种资源使用（如CPU使用率）已经达到饱和状态。负载测试方法可以找到系统的处理极限，为系统调优提供数据。
（2）压力测试
压力测试方法是测试系统在一定饱和状态下（如CPU使用率等）系统能够处理的会话能力，以及系统是否会出现错误。
（3）可靠性测试
可靠性测试方法通过给系统加载一定业务压力的情况下（如CPU利用率为80%），使系统持续运行一段时间，测试系统在这种条件下能否稳定运行。
（4）并发测试
并发测试方法通过模拟用户的并发访问，测试多个用户并发访问同一个应用、同一个模块或者同一个数据记录时是否存在是否存在死锁或者其他性能问题。
（5）验收性能测试
验收性能测试方法通过模拟生产运行的业务和使用场景组合，测试系统的性能是否满足生产性能要求。
3、性能测试需求分析
性能测试需求分析作为性能测试过程的初始阶段，是整个性能测试工作顺利开展的基础。需求分析可以从一下几个方面进行：
（1）系统信息调研
系统信息调研指对被测试系统进行分析，需要对其有全面的了解和认识，这是做好性能测试的前提，具体需要调研的信息如下图所示。
（2）业务信息调研
业务信息调研指对被测试的业务进行分析，通过对业务的分析和了解，方便后续进行性能测试场景的确定以及性能测试指标的确定，具体需要调研的信息如下图所示。
（3）确定性能测试点
在性能测试需求分析过程中，可以从一下几个方面分析确定被测系统的性能测试点：
² 关键业务。确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点，例如转账、扣款等接口。如果项目（或功能点）不属于关键业务（或关键业务点），则可考虑后续方面。
² 日请求量。确定被测项目各功能点的日请求量（可以统计不同时间粒度下的请求量，如小时、日、周、月），如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要进行性能测试，而且是关键业务点，可以被确定为性能点。
² 逻辑复杂度。判定被测项目各功能点的逻辑复杂度，如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要进行性能测试，原因是在分布式方式的调用中，当某一个环节响应较慢，就会影响到其他环节，造成雪崩效应。
² 运营推广活动。根据运营的推广计划来判定待测系统未来的压力，未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用，例如，运营计划做活动，要求系统每天能支撑多少PV、多少UV，或者一个季度后，需要能支撑多大的访问量等。当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要进行性能测试。
（4）确定性能指标和测试方法
性能需求分析一个很重要的目标就是需要确定使用的测试方法和性能评价指标。性能指标有很多，可以根据具体项目选取和设定，而具体的指标值则需要根据业务特点进行设定。
【任务实施】
企业网站内容管理系统分为管理后台和网站两部分，后台管理支持以下几种业务操作：登录、修改个人信息、栏目属性管理（增删改查）、栏目管理（增删改查）、文章属性管理（增删改查）、文章管理（增删改查）、静态化、批处理、生成报表、系统备份，网站有以下栏目：首页、公司产品、新闻动态、关于我们，经过调研和分析，某集团公司企业网站内容管理系统用户的每天使用习惯如下所示：
Ø 1：00~3：00，批处理数为20，生成报表数为30，系统备份次数为11；
Ø 3：00~5：00，批处理数为25，生成报表数为60，系统备份次数为8；
Ø 5：00~7：00，批处理数为15，系统备份次数为12；
Ø 8：30~9：00，有100个用户进行登录，80用户进行文章新增或者修改，15个用户进行属性新增或者修改，10个用户进行静态化，1000个用户访问了网站首页，500个用户访问新闻动态，200个用户访问了公司产品；
Ø 9：00~12：00，有30个用户进行登录，30用户进行文章新增或者修改，5个用户进行静态化，3000个用户访问了网站首页，1000个用户访问了公司产品，300个用户访问了关于我们；
Ø 12:00~14：00，有500个用户访问了网站首页，200个用户访问了公司产品，50个用户访问了关于我们；
Ø 14：00~16：00，有50个用户进行登录，40用户进行文章新增或者修改，2个用户进行修改个人信息，3个用户进行静态化，300个用户访问了网站首页，100个用户访问了公司产品；
Ø 16：00~18：00，有30个用户进行登录，20用户进行文章新增或者修改，2个用户进行属性新增或者修改，1个用户进行静态化，100个用户访问了网站首页，20个用户访问了公司产品；
Ø 18：00~20：00，有10个用户进行登录，10用户进行文章新增或者修改，1000个用户访问了网站首页，300个用户访问了公司产品；
Ø 20：00~22：00，有50个用户访问了网站首页，10个用户访问了关于我们；
Ø 22：00~24：00，有生成报表数40张。
请根据OA系统的用户使用习惯，分析确定性能测试指标和测试方法。
1、画出OA系统的任务分布图 ，具体如下图所示。
2、确定关键任务及性能指标。根据任务分布图和业务复杂度可以确定登录、文章新增或者修改、网站首页3个模块为关键业务，用户集中在8：30~9：00这个时间段内使用，且登录、文章新增或者修改这2个模块业务成功率必须为100%，按照常识：CPU的使用率不超过75%、内存使用率不超过70%、2/5/10s的响应时间标准在（在2 s之内给客户响应被用户认为是“非常有吸引力的”，在5 s之内响应客户被认为是“比较不错的”，而10 s是客户能接受的响应的上限），可以初步确定某公司企业网站内容管理系统的性能指标如下表所示（具体指标值需要和业务及开发确认）。
3、确定测试方法和设计测试场景
根据系统调研情况和初步确定的性能指标，可以设计某公司企业网站内容管理系统的测试场景，具体如下表所示。
性能测试企业案例：
