| 编辑推荐: |
本文来自于csdn，性能测试需求从哪里来？怎么判断出用户提出的性能测试需求是否过于理想化
？文章做出了详细说明。
|
|
1 前言
一些性能测试人员常犯的错误就是，测试一开始就直接就对系统加压，不弄清楚性能测试的目的，其实性能测试和其他类型的测试一样，都需要先进行测试需求的分析，做相应的测试设计工作，否则测试工作无的放矢。那么性能测试需求从哪里来？怎么判断出用户提出的性能测试需求是否过于理想化
？
答案和也和其他类型测试一样，性能测试需求需要从需求文档、各种招标文档中来，从和项目组人员、客户交流的信息中获取和分析。对于无法和用户直接沟通的测试人员来说，建议先从需求、招标等文档中获得一些明确的信息点（包括用户情况和系统运行环境情况、各个系统的运行场景），通过一些明确的信息点来挖出一些隐含的性能测试需求；挖掘的角度可以按照性能测试侧重的角度去分析，如：系统的用户访问量、系统的处理能力（响应时间）、系统的数据量、网络要求等方面。
下面以某个数据中心项目为例，进行说明，恳请网友同仁们多评论多给意见。
1.1 项目背景
在“数字国土”和“金土工程”的推动下，经过多年努力，A市各级国土资源管理部门建立了大量的国土资源应用系统，数量已达13个之多，这些系统的应用范围几乎覆盖了国土管理的所有业务领域。同时积累了大量的国土资源数据，包括基础地理、不同年代的遥感影像和土地利用现状、土地利用规划、建设项目用地审批、矿业权审批、不同年代的土地调查成果、土地登记数据（含地籍测量）、基准地价、土地市场动态监测、土地市场交易等数据成果。
虽然A市国土资源局在基础数据库和电子政务系统建设方面发展迅速、成绩斐然，信息化工作已经成为促进国土资源管理职能转变、机制创新和管理创新的源泉和动力。然而，由于在信息化的开始阶段，总体建设思路不明确，导致在具体建设项目过程中必然统筹不到位，各应用系统职责边界不清，系统集成整合度不高，数据资源隶属于某个系统，无法方便地被其他系统使用，每建设一个系统，就形成“信息孤岛”一座。这严重制约了数据资源的共享和应用，造成大量基础信息资源的闲置和浪费，使信息化工作在国土资源管理和促进科学发展机制中的作用大打折扣。如果不消除“信息孤岛”，不仅在今后的信息共享所付出的代价将呈级数上涨，还将严重影响全局信息化建设的持续健康发展。
本期项目目标和建设任务有：
1、实现A市国土资源系统信息资源科学分类与组织，制定一个适用可行的、融多个数据库为一体的数据组织规范，建立A市国土资源科学数据整体模型。
2、完成A市国土资源标准主体数据库设计和初始建库，实现国土资源业务系统成果数据融合和信息共享，实现国土系统科学数据资源集中存储。
3、完成A市国土资源标准主体数据库维护平台的开发，实现多源、异构数据（包括GIS）统一管理和集中展示，并能够为各业务应用系统和社会公众提供完善的信息服务。
4、完成主体数据库应用服务的开发，在主体数据库的基础上，建立一些应用服务，提供给用户做二次开发。
5，在主体数据库应用服务的基础上，开发二个主题应用，来验证服务正确性、稳定性、可扩展性。
1.2 系统介绍
根据上一节的项目任务，本期需要建设的系统有：
1、 数据采集系统 ，该系统从已经建成的13个系统中抽取数据、转换和装载到标准主体数据库中，该系统为C/S架构，在整个项目体系中，充当数据入口的作用。
2、 标准主体数据库维护平台，对主体数据库的初始建库、元数据定义、日常的维护工作。包括创建数据集合、表定义等，该系统为B/S架构，提供给系统管理员使用。
3、 GIS数据管理系统：对标准主体数据库中的GIS数据的进行更新、查询、制图输出等，该系统为C/S架构。
4、 标准主体数据库应用服务系统：在主体数据库的基础上，提供一个数据共享和应用的服务层，这些服务层，为客户方提供二次开发的目的，同时系统一些常用的业务查询、报表统计分析功能，如土地利用报表的输出。
5、 基于二个业务的主题应用（即土地市场监测和分析和违法地块快速核查），这二个应用的主要为了验证标准主体数据库应用系统的正确性和可扩展性，保证用户在标准主体数据库应用系统上二次开发的系统是稳定、可靠的。
2 获取原始信息
2.1 获取文档的信息
从需求文档中了解到，对A市国土资源局数据中心的性能要求如下：
具备对TB级海量数据的综合管理和安全保障能力；
主体数据库的数据装载速度必须远大于新数据的产生速度，不允许出现主体数据库数据更新不及时的现象发生；
数据库应支持应用系统或者成果数据的同步或异步更新；
在支持用户并发业务数据的综合查询时间<1s；
报表展现时间<5s；数据分析时间<5s；空间数据表现时间<5s；
支持至少50个用户并发访问数据库；
统计分析和图表结果累计时间小于10秒。
从需求文档描述和项目背景信息中等相关文档可以明确：
各个系统的结构比较复杂，需要13个系统进行接口；
数据中心的数据是实时更新的，要求标准主体数据库的数据装载数据必须大于数据的产生速度；
所有的系统以一个中心数据库展开（本项目中称标准主体数据库）。
用户对报表的展现、分析、空间数据的表现最关心，要求时间在5秒之内；因为这些功能是体现数据中心、数据共享价值的功能；
用户要求并发人数在50人以上；
未明确信息：
系统并发用户数50是否合理？
用户最关心的功能；
系统的运行的环境情况（软硬件）
数据中心的数据是实时更新的，要求标准主体数据库的数据装载数据必须大于数据的产生速度；这是一个要求，但是具体数据才生的速度和更新的速度是怎么样的？
2.2 系统运行环境
系统软硬件情况
答：系统软件情况，可以从用户软件的采购清单中获得。
系统的硬件情况，一般从技术方案、网络方案中获得。
本次获得结果：
网络带宽：电子政务专网100M到桌面；网络拓扑结构：有内外分离器，中间有防火墙隔离。
数据库服务器：操作系统采用windows 2003 ；数据库为oracle 10g 10.2.0.3以上；空间数据引擎：Arcgis
sde 9.3 ；硬件： Intel（R） xeon(R) CPU E7450 24核 32位机器
，物理内存16GB；采用磁盘阵列方式存储，可用磁盘空间2TB；
Web服务器：IIS 6.0 ；Webgis平台：arcgis server 9.3；硬件： Intel（R）
xeon(R) CPU E7450 24核 32位机器 ，物理内存16GB；采用磁盘阵列方式存储，可用磁盘空间2TB；
客户端桌面：内存1GB以上；
2.3 系统业务量
从和项目组交流的过程中，发现A市国土局的“建设用地审批”业务和“城镇地籍管理”业务量最大，在08-2009年的建设用地审批业务中，建设用地审批业务量有1000件。每件业务数据大概有2KB，空间数据量大概有5MB。
城镇地籍中土地登记信息，从2004年到2009年12月6号共发生了39万8000余次业务，但是早期发生的业务较少，到了2007年到2009年，随着房地产市场的火爆，系统发生的业务越来越多，每天业务量峰值最高达到512件（2009年11月16日）。
抽取最近2009年11月份2周土地登记交易量数据：
其他的业务日交易量比较少，如土地利用现状调查、土地利用规划等相关业务的数据量少，基本按照年度进行更新。
2.4 系统使用情况
标准主体维护平台：给信息中心系统管理人员用，通过录入标准主体数据库元数据，来完成数据的建库、数据错误维护工作，争取不用arccatalog
和oracle工具。系统结构为B/S结构；
2个主体应用：给2个业务科室人员用；
标准主体应用服务：给所有业务处室人员用，系统同时提供一个二次开发框架，由信息中心人员做二次开发。
数据采集系统：给信息中心管理人员用；
2.5 用户关心功能
局领导：最关心每年收取的“土地出让金”，土地出让的面积；数据从土地市场数据库中获取；
业务处室人员：常用的查询、分析、统计功能，如：土地利用报表统计、；
信息中心管理人员：数据采集系统的更新功能能够及时、正确的更新到标准主体中心库中。
3 分析性能需求
分析角度：
1、按照成熟的性能测试策略，从前端、服务端、网络几个层次来分析。（为以后的测试指标做基础）前端：并发用户数、服务端：系统处理能力和硬件选型等
；网络端：网络流量和带宽；
2、从软件结构做分析，找出可能瓶颈。
3，系统将来是否能够满足性能压力 ？
3.1.1 系统整体架构分析
下面是整体的架构图：
从软件部署图上面可以看出：
统一身份验证服务的压力较大，并发登录的压力在这个上面，需要考虑。
空间数据引擎控制着多个系统空间数据的读取，压力比较大。
BS部分的压力可以一共分到5层上面（我们可以逐层来分析）（客户端、web服务器、arcgis server、arcsde
、oracle）
ETL数据采集系统是整个数据中心的入口，数据更新效率对发挥数据中心的效果影响深远。
因为13个系统是不间断运行的，数据要求实时更新，所以本系统要求7×24小时运行，测试时需要增加疲劳强度的测试。
3.1.2 软件系统耗时功能分析
标准主体数据库维护平台：元数据树的浏览，因为需要从多个表中构建多一个元数据，A市的数据量很大，所以应该重点测试；数据库结构的创建，需要在数据库中创建实例和结构，所以耗用时间长，需要测试。
空间数据库管理系统：数据入库、制图、缓冲分析；
标准主体应用服务系统：长年度的报表统计、大范围的数据浏览；
统一身份验证服务；
3.1.3 用户访问量
目的：知道最大的并发用户数
用户数：通过调查了解，和本项目相关的业务处室一共有、土地规划处 、耕地保护处 、土地利用处 、地籍处
、矿产资源处 、地质环境处 、执法监察处共7个处室，以每个处室5-6人计算，合计为42人次。加上信息中心各科室（档案科、综合科、数据科、信息科）20人
合计约62人。其中执法监察系统需要到分局运行，共7个分局，每个分局约3人次使用该系统，执法检查系统需要支持7×3+6=27人次的最大并发。
到目前为止，如果不在标准主题数据库上面增加别的应用的话，则整个标准主题数据库需要支持62+21=83最大并发数。
3.1.4 系统业务量和系统处理能力
目的：知道业务量，可以分析出系统处理能力，每分钟、每小时，要查询、交易的业务个数。
根据业务量，来分析出系统处理的能力。本项目中一共包括多个系统，每个系统都需要进行处理能力分析，这里我们以“数据采集系统”中的“建设用地审批”和“城镇地籍数据”2种数据的更新要求为例，来确认系统的处理能力（即达到“主体数据库的数据装载速度必须远大于新数据的产生速度，不允许出现主体数据库数据更新不及时的现象发生”的要求）。
在第2部分“获取原始信息/系统业务量”中，我们了解到，在用的13个系统中，土地登记系统和建设用地审批系统的业务量最大（每年达到1000个），土地登记日登记业务峰值达到2000个。
建设用地业务数据更新时间要求：
业务量较大的情况：每年1000个项目，那么每天需要办理的建设用地审批项目有：1000 /（11×22）=4.1个项目
（扣除节假日）约=5个项目。
根据80-20原则和高峰工作原则，假如每天工作时间在8×0.2=1.6小时内完成，那么也就是系统最差情况1.6小时之内必须完成5个项目的数据更新。也就是19.2分钟必须完成建设用地的数据更新才能保证前面的需求：“主体数据库的数据装载速度必须远大于新数据的产生速度，不允许出现主体数据库数据更新不及时的现象发生”。
按照固定资产投资比例，假如每年以20%的速度增长，2009年每天需要完成6个项目的更新，也就是16分钟必须完成一个建设用地项目的数据更新（一个业务的数据量约为2KB，5MB的空间数据）。
城镇地籍数据更新时间要求：
峰值每天最高能达到近600件，每天以8小时计算, 根据80-20原则和高峰工作原则，假如每天工作时间在8×0.2=1.6小时内完成，那么系统在最坏情况下，需要在1.6小时之内完成600个业务数据的更新。那么需要在每分钟完成6.25个业务的数据更新。每个业务约为1KB的数量，则每分钟需要完成6.25KB的数据更新。
基础地理数据：根据数据量的大小来计算出每小时、每分钟的交换数据量等等性能测试需求。
3.1.5 系统存储能力和数据量分析
截止到2008年，A市国土各种数据情况约200GB（这个是初略数据，从现场数据人员获得），假如以每年30%的速度递增，则以后
数据中心至少支撑如上数据量的运行。按照每年保留2个数据备份，系统存储要求至少有，压缩比率为20%，则总体的存储能力如下表。
3.1.6 网络流量
根据每个业务办理需要的数据量，假如一个业务办理需要20KB的数据，那么并发20个业务是，需要400KB的数据。说明带宽在1M左右就可以满足要求。
办理一个业务网络带宽简单算法：数据包的单位大小（跟操作系统有关）*(发送包个数+接受包个数)
目前用户方为专网100MB到桌面，带宽这块可以不考虑。
4 得出性能测试需求
在基于2008年的数据量的情况，可以将用户最初的初略需求完善成如下更加明确的要求：
当前至少满足：总数据量在200GB，总存储能力在520GB下面，网络带宽在100M的情况下：
n 主体数据库的数据装载速度必须远大于新数据的产生速度，不允许出现主体数据库数据更新不及时的现象发生；目前至少保证每19分钟完成一个建设用地的更新（数据量为2k+5MB）。每分钟必须满足7个（6.25进1）(数据量为1KB)个土地登记数据的更新。
n 在支持用户并发业务数据的综合查询时间<1s；
n 标准主体应用的报表展现时间<5s； 标准主体数据分析和GIS的数据分析数据分析时间<5s；空间数据浏览和定位空间数据表现时间<5s；
这些是领导关心的功能，需要重点满足。
n 标准主体应用服务的统计分析和图表结果累计时间小于10秒，如空间数据管理系统的制图功能、二次土地调查的报表输出。
n 系统最大的用户数要满足62+21=83人次对标准主体数据库的访问。
n 执法检查系统中能满足并发27人的访问；
n 要求满足83人次统一身份验证功能；标准主体数据库oracle能满足并发83人的访问；
n 系统需要满足7×24小时的不间断运行，运行一段时间后，整体执行效率不衰减。
如果用户2009年以后需要在标准主体数据库上面进行扩展、开发一些新的应用，那性能需求还需要进一步进行分析，性能要求将更加高。 |
