论常用的性能需求获取方法

下面就跟大家一起讨论几种常用的获取性能需求的方法。

1.依据用户明确要求

依据用户明确给出的测试相关数据和指标是分析系统性能需求最直接、最简便的方法。对于前面提到的专业型客户，如银行、军事、医疗、政府机关等以及国外客户大多都会给出较明确的性能需求（响应时间、并发量、服务器资源指标等），作为开发方，只需进行整理后参照明确指标进行测试即可。

2.依据用户提供的已有数据整理分析得出

所谓客户提供的已有数据指客户业务交易的纸质数据、客户旧版本系统中的历史数据（服务器日志、数据库记录等）。例如，一个未曾使用过电子系统的保险公司，获取需求时可以通过汇总已有投保纸质单据进行分析，得出各地域及每年某个时间段的投保、理赔数量、主要投保及理赔的险种业务等来进行性能测试。若该公司已有旧版本的电子投保系统，则旧版本的运行系统中存在了大量有价值的数据。比如：Web服务器（IIS、Apache或Jboss等）的日志中记录了系统访问情况以及出错信息等，我们可依据日志信息分析客户的业务量，以及每年、每月、每周、每天的峰值业务量等（通过服务器日志获取性能需求的方法参见1.6.3节）。此时，以充分的真实业务数据做参考得出的性能需求显得更加真实有效。

3.依据同行业中类似项目或类似行业中的数据

该方法包含了两种情况，一种为“依据同行业种类似项目的数据”，另一种为“依据类似行业中的数据”。这两种情况所表达的含义是一致的：当自己没有某些资源时，要学会借助外界力量帮助自己实现性能目标的获取。比如，有读者可能会这样问：需求中没有说明性能需求，只说要做一个网站的性能测试。此时，如何开展性能测试呢？回答是：先分析用户群特征，然后参考其他同行企业的公布出来的数据进行测试。

下面，给出几个依据同行业中类似项目的数据或类似行业中的数据得出性能需求的几个实例。

例1-1. 在某企业网站的成功解决方案中介绍该方案的优势为：“实现了7*24稳定运行要求，系统可承载3000用户同时访问，1秒快速响应您的请求等”，其中的数据可作为性能需要的参考。

例1-2. 有一些网站首页本身就提供了点击量、文章浏览量等统计信息，尽管在许多时候，不能完全照搬这些数据，但这些信息仍然具有很强的参考价值。

例1-3. 在开发一个保险类软件时，除了可从客户发布的一些成功解决方案中获取数据，还能主动去索取一些数据，比如，可以咨询某保险公司：“我想购买贵公司的保险，但首先要了解一下投保情况和理赔的数据或比例等，好让自己更确信公司的诚信……”。不过，这种方式不被推荐，因为对方的回答很可能存在水分以提高业务量。

例1-4. 可以借助一般的B/S架构的项目性能目标来套，比如：2/5/10原则，即2秒的响应是愉快的，5秒是可接受的，10秒是最大可忍受的。

4.80/20原则分析计算得出

在性能测试需求获取中，经典的80/20原则可理解为：每个工作日中80％的业务在20％的时间内完成；80%的功能只会有20%的用户访问，或者说80%的用户只使用20%的功能。

例1-5. 每年业务量集中在8个月内，每个月有20个工作日，每个工作日为8小时工作制。根据80/20原则，可得出，每天80%的业务在1.6小时（8小时*20%）内完成。去年，全年处理业务约100万笔，其中15%的业务处理中每笔业务需对应用服务器提交7次请求；70%的业务处理中每笔业务需对应用服务器提交5次请求；其余15％的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量的2倍进行。请根据上述数据进行测试强度的估算。

v每年总的请求数：

(100万笔*15%*7次/笔+100*70%*5/笔+100*15%*3/笔)*2倍=1000万次/年。

v每天请求数：

。

v每秒请求数：

(62500次/天*80%)/(8小时*20%*3600秒/小时) = 8.68次/秒（约为9次/秒）。

可见，服务器处理能力应达9次/秒。

5.任务分布图

若利用上面的某种方法获取到了客户业务相关的某些数据，则可借助任务分布图作进一步分析。任务分布图能够直观地展现客户业务在24小时内的交易情况，能协助读者整理出交易频繁的业务种类及相应的时间段。如：表中是某在线购物网站的任务分布图，从中可见：12:00-14:00及20:00-22:00点之间的交易混合程度较高，“查询”任务的并发用户在14:00达到最大。任务分布图也支持对全年或某个月的任务分布情况作统计分析，在此不再赘述。

某在线购物网站的任务分布图