全国中小企业股份转让系统有限责任公司交易支付平台第三方验收测试外协合作项目建议书v0.9

全国中小企业股份转让系统有限责任公司交易支付平台第三方验收测试外协合作项目建议书投标文件（正本）东软集团股份有限公司东软集团股份有限公司2014年1月14日目录目录第一部分商务部分91报价函92法定代表人授权委托书103谈判分项报价114技术规格偏离表125商务条款偏离表136投标人资格审查文件1461谈判人基本信息表1462投标人财务状况表1563投标人无违约情况证明2364投标人无违法情况声明2465投标人纳税情况证明2566企业法人营业职照2767组织机构代码证2868ISO90012008质量管理体系2969ISO270012005信息安全管理体系31610CMMI认证33611东软IT系统第三方测试服务项目技术实力346111金融行业主要测试项目案例346112测试人员在项目中的分布情况357保密承诺函388知识产权和使用权承诺书399项目组配备人员情况表4010拟投入本项目的主要人员简历表4111投标人已完成的与招标内容相同或相似项目一览表50第二部分技术部分551总述5511背景5512建设目标5513建设内容5514指导方法56141东软BENCHMARKING方法学56142东软性能工程服务方法学582第三方交易平台功能测试方案6721功能测试范围6722功能测试内容67221功能测试背景67222功能测试需求67223功能测试目标67224系统框架结构68225项目时间要求6823功能测试过程6924测试交付计划6925功能测试模块规划70251交易系统模块70252行情系统模块70253交易监察系统模块71254数据处理功能模块713统一性能测试平台建设方案7231性能测试范围7232性能测试规范7233性能测试内容75331性能测试需求分析75332性能测试脚本开发79333性能测试数据模型建立82334性能测试场景建立83335系统资源监控规范及性能指标建立8834性能基线的建立与维护9435性能测试沟通机制9736性能测试实施过程10037性能测试报告的生成1054模拟工具实现方案10841模拟撮合工具108411管理配置108412自动撮合成交109413手工撮合成交109414快速成交109415生成清算文件11042模拟行情工具110421行情模拟110422模拟假设111423历史行情自动回放111424行情配置11143非功能实现111431界面风格实现111432灵活性和扩展性1125测试结果展现方案11251测试用例管理11252测试场景11253测试结果11354测试结果分析11355系统管理1146组织结构、人员和角色11561项目组织结构11562角色和职责1177项目管理12071项目风险12072变更管理12173测试版本管理12174项目跟踪12175沟通管理12276文档管理1238项目计划和工作量估算1249交付成果物12610东软性能测试服务介绍127101我们的优势127102专业服务分类128103性能案例的运作130104项目的交付13211东软测试体系介绍133111东软测试体系133112专业化的测试团队137113多样化的测试工具138114全面化的测试服务14112东软测试能力介绍146121人力资源能力1461211人力资源储备1461212职位级别规划1471213金融行业线测试资源152122标准化测试过程1521221测试准备1531222测试计划1531223测试设计1541224测试执行1541225分析总结1551226测试监控156123测试过程管理1561231测试项目管理1561232测试需求管理1581233测试质量管理1591234测试风险管理1611235测试设计管理1631236测试评审管理1641237测试分析管理1651238配置管理166124测试技术1681241测试类型1681242测试方法1691243测试内容1711244度量分析17613测试中心规划服务介绍177131服务内容1771311阶段实施1781312组织职能划分1791313测试体系基础架构1801314测试工具181132用户体验测试服务1821321基本概念介绍1831322投入和回报1831323评估侧重方向1831324测试的方法和过程18414东软介绍186141东软集团介绍1861411业务架构1871412核心竞争力1891413质量管理优势1901414公司创造力1901415行业服务1911416遍布全国的销售和服务网络1921417东软创造的“第一”1921418国际合作1931419主要客户及成功案例1941413金融测试领域案例列表1961414证券业典型案例19715售后服务199151服务内容199152服务方式199153培训计划2001531软件实施培训2001532维护期培训20016部分典型案例介绍200161上海证券交易所第三方UAT测试201162广东发展银行测试服务合作203163外汇交易中心第三方功能测试204164上海浦东发银银行性能测试206165中国工商银行研发资源采购208附件1信息安全保密协议211附件2信息安全保密协议基本条款217附件3典型案例合同复印件221附件4企业简介242附件5企业组织架构245第一部分商务部分1报价函致全国中小企业股份转让系统有限责任公司根据贵方交易支持平台第三方验收测试项目，我方针对该项目的报价为壹佰玖拾贰万壹仟壹佰肆拾肆圆元人民币。并正式授权的下述签字人顾程颖，客户经理代表谈判人东软集团股份有限公司，提交谈判文件要求的全套响应文件，包括1、报价函、商务部分及技术部分响应文件；2、其他资料。并承诺响应文件中的全部内容真实有效。据此函，签字人兹宣布同意如下1、我方已详细审核并确认全部谈判文件，包括修改文件（如有时）及有关附件。2、一旦我方成交，我方将组建项目组，保证按合同协议书中规定的周期2014年7月18日内完成工作并提供相应的服务。3、我方同意所提交的响应文件在谈判文件的响应须知中规定的谈判有效期内有效，在此期间内如果成交，我方将受此约束。4、除非另外达成协议并生效，你方的成交通知书和本响应文件将成为约束双方的合同文件的组成部分。5、其他补充说明（补充说明事项）与本谈判有关的一切正式往来通讯请寄地址北京市海淀区东北旺西路8号软件园6号楼东软大厦邮编100193电话01056517788传真01082826292谈判人东软集团股份有限公司谈判人代表代表人盖章、签字日期2014年1月14日2法定代表人授权委托书3技术规格偏离表项目名称全国中小企业股份转让系统第三方交易平台验收测试序号货物/服务名称采购规格响应规格偏离说明注谈判人应特别针对谈判文件中的技术条款进行逐一应答，谈判人应对所投产品技术指标有详细的描述。谈判人名称（盖章）东软集团股份有限公司谈判人授权代表签字日期2014年1月14日4商务条款偏离表项目名称_全国中小企业股份转让系统第三方交易平台验收测试_序号谈判文件条款号谈判文件的商务条款响应文件的商务条款说明谈判人名称（盖章）东软集团股份有限公司谈判人授权代表签字日期2014年1月14日5投标人资格审查文件51谈判人基本信息表单位名称东软集团股份有限公司成立日期1991年06月17日经营地址沈阳市浑南新区新秀街2号单位性质股份有限公司注册资金壹拾贰亿贰仟柒佰伍拾玖万肆仟贰佰肆拾伍人民币电话传真法定代表人刘积仁电话总经理王勇峰电话上级单位名称资质等级计算机信息系统集成特一级资质信用等级国家AAA级信用企业经营范围附营业执照复印件（请见商务部分本章节66）高级职称中级职称初级职称单位员工概况合计人181人1135人3365人企业简介请见附件3单位组织构架请见附件4下属单位情况52投标人财务状况表2012年财务审计报告53投标人无违约情况证明证明我东软集团股份有限公司无违约历史，特此声明。东软集团股份有限公司54投标人无违法情况声明证明我东软集团股份有限公司无违法记录，特此声明。东软集团股份有限公司55投标人纳税情况证明56企业法人营业职照57组织机构代码证58ISO90012008质量管理体系59ISO270012005信息安全管理体系510CMMI认证511东软IT系统第三方测试服务项目技术实力5111金融行业主要测试项目案例行业分类客户项目广东发展银行网银相关系统（测试项目）、后台流程再造（测试项目）、储畜合并（测试项目）、重空（测试项目）、电子商业汇票系统（测试项目）、一户通（测试项目），银行核心项目、数据交换平台、ODS数据仓库、性能测试项目等中国工商银行外部研发资源采购项目中间业务管理平台项目、柜面终端项目、网上银行、开放式基金财务估值系统AS、中国工商银行国际化网站项目、中国工商银行人力资源系统项目、中国工商银行个人网上银行项目、中国工商银行科技管理系统、中国工商银行新终端系统改造、主机核心系统、帐务系统等上海浦东发展银行资产托管系统性能测试方案（测试项目）、电子商务交易资金托管系统测试（测试项目）银行兴业银行兴业银行托管业务系统改造测试（测试项目）、信用卡核心系统（开发、测试）、互动短信项目（开发、测试）、邮件管理项目（开发、测试）、呼叫中心项目（开发、测试）、市场营销项目（开发、测试）、客服管理系统项目（开发、测试）、电子化文档管理项目（开发、测试）、信息共享系统项目（开发、测试）、信用卡综合业务平台项目（开发、测试）、信审项目（开发、测试）、卡交易监控项目（开发、测试）、账单管理（开发、测试）、催收项目（开发、测试）、报表分析系统（开发、测试）、数据仓库决策分析系统（开发、测试）交通银行交通银行自动化测试服务项目上海证券交易所上海证券交易所第三代监察系统UAT测试（测试项目）、上海证券交易所LEVER2后台数据生成系统（开发、测试）、上海证券交易所创新试验平台（开发、测试）上海期货交易所上海期货交易所电子出入金系统（开发、测试）、上海期货交易所电子仓单项目（开发、测试）大连商品交易所大连商品交易所仓单电子化项目（开发、测试）、大连商品交易所银行出入金项目（开发、测试）证券、期货、外汇中国外汇交易中心新一代本币交易系统第三方测试项目（测试项目）、COMSTAR增值服务系统（测试项目）、外汇交易中心外币项目管理和质量管理（管理类）、外汇交易中心风险控制一期二期（开发、测试）、外汇交易中心本币项目管理和质量管理（管理类）、外汇交易中心数据发布系统客户端（开发、测试）太平洋保险寿险网站（测试）、产险网站（测试）、电话车险营销（开发、测试）平安保险保险资产管理监管信息系统项目二期（测试）、PICCLIFE项目（测试）天平保险天平车险承保系统（测试项目）、天平车险理赔系统（测试项目）人保财险第三代核心系统（开发、测试）、新一代定报价系统（开发、测试）、财务系统（开发、测试）、法律系统（开发、测试）、数据治理（开发、测试）等保险人保寿险核心系统（测试项目）、设备管理系统（开发、测试）、核心系统运维、电子商务运维、规则引擎项目（UAT测试）、国华人寿保险国华人寿保险测试人员外包项目（测试项目）5112测试人员在项目中的分布情况序号客户名称项目名称测试人员数量所在地1上海证券交易所集成测试5上海2外汇交易中心测试服务外包31上海3期货交易中心测试服务外包23上海4太平洋保险测试服务外包40上海5天平保险测试项目5上海6国华保险测试人员外包项目3上海7大众保险测试人员外包项目1上海8建信人寿测试人员外包项目1上海9兴业银行ICFP性能测试4上海10兴业银行定向租用8上海11兴业银行托管项目3上海12交通银行核心系统测试18上海13工商银行测试人员外包项目18上海14浦发银行托管项目2上海15东方航空测试人员外包项目2上海16丰田金融核心业务系统性能测试项目4北京17工商银行北研服务外包项目15北京18工商银行数据中心测试项目22北京19民生银行核心业务系统测试项目30北京20人保财险第三代核心测试17北京21人保寿险核心业务系统测试项目12北京22外汇管理局贸易外汇管理项目15北京23保监会保监会监测管理项目3北京24银行协会宏观经济监测项目3北京25广发银行广发银行核心系统；开发平台；信用卡核心系统项目测试131广州26中国工商银行新终端改造；网上银行；新一代个人贷款等项目15广州27中国工商银行新终端改造；网上银行；新一代个人贷款等项目6珠海28广东农村信用社农信银改造、电票、卡积分管理系统等项目21广州6保密承诺函保密承诺函致全国中小企业股份转让系统有限责任公司我司承诺严格遵守全国中小企业股份转让系统有限责任公司的各种保密制度，同意签署保密协议，见本投标文件附件1、附件2。投标人全称东软集团股份有限公司日期2014年1月14日7知识产权和使用权承诺书致全国中小企业股份转让系统有限责任公司_若成交，我公司承诺1、本项目中所使用的软件和技术不涉及任何知识产权和使用权纠纷。2、采购人拥有本项目开发软件的全部知识产权。未经采购人同意，我方不得以任何方式向第三方披露、转让和许可有关的技术成果、计算机软件、技术资料和文件。除本研发工作需要之外，未得到采购人的书面许可，我方不得以任何方式利用上述技术成果、计算机软件、技术资料和文件。如我司或我司人员违反本承诺，我司完全愿意承担由此而产生的一切后果与法律责任。特此承诺。谈判人名称（加盖公章）东软集团股份有限公司法定代表人或其授权代理人（签字）日期2014年1月14日8项目组配备人员情况表姓名性别年龄参加工作时间在本项目中任职顾程颖女322006年客户经理王羿女292006年项目经理刘思成男352008年业务咨询顾问王超男322008年质量经理黄正环男322004年测试架构师宋成可男302007年测试设计师王熠女262011年测试工程师安密女242011年测试工程师邱敏女272011年测试工程师魏星女252011年测试工程师商务谈判人名称（加盖公章）东软集团股份有限公司法定代表人或其授权代理人（签字）日期2014年1月14日9拟投入本项目的主要人员简历表姓名顾程颖性别女出生日期1982年10月31日毕业院校及专业黑龙江大学计算机科学与技术学历及学位学士毕业时间2006年7月1日从事本专业时间8年为谈判人服务时间8年职称高级项目经理拟在本项目中担任职务客户经理资格证书主要经历时间参加过的类似项目名称及规模该项目中任职2006年至今姓名王羿性别女出生日期1984年8月22日毕业院校及专业华北电力大学电气工程及其自动化学历及学位学士毕业时间2006年7月10日从事本专业时间8年为谈判人服务时间5年职称资深测试拟在本项目中项目经理设计师担任职务资格证书N/A主要经历时间参加过的类似项目名称及规模该项目中任职2006年至今公司外部网站企业工作流平台MOSS平台开发（四方集团协作门户系统）NOKIATCFW测试OVIJSCP21B检查系统日处理成交笔数10000万笔的定值下,连续运行72小时并且继续申报,撮合，转让，竞价，详情单查询等业务动作是否可用及稳定C检查系统的业务数据、申报笔数8000万笔并发与成交笔数8000万笔并发的负载下,连续运行72小时过程中,所有业务动作是否可用及稳定。因此,性能测试需求必须要包含有多少用户WHO在什么时间WHEN或者持续多久WHEN进行了什么业务WHAT,最终需要关注怎样的指标HOW。除此以外,需要根据项目性质和性能测试的目标来获得性能测试需求的来源WHERE,归纳为4W1H。3313获取性能测试需求的方法性能测试需求是应用需求的衍生,既需要借助于相关的理论知识,又要依靠测试工程师在相关领域的经验积累,根据前面4W1H的性能测试需求的要求,即对性能测试需求进行整理,确定恰当的并发用户数、在适当的时间进行典型的业务活动时,关注的性能指标有怎样的结果,东软根据多年性能测试实践经验,总结获取性能测试需求的方法如下。1性能需求信息来源A开发过程相关文档。这是性能测试需求的主要来源,项目开发计划书、需求规格说明书、设计说明书、测试计划等文档都可能涉及性能测试的要求,通过收集这些资料,可以找到初步的性能需求。相关的项目干系人有客户代表、项目经理、需求分析员、系统架构设计师、产品经理等。B相似项目性能需求。公司的其他产品或项目会累积出一些数据,如技术论坛一小时最多能发1000新帖博客平均每天新增800篇,以这些数据为确认新项目测试需求的基础。C业界公认标准。如响应时间,根据服务器的不同和项目的具体情况可能有两类标准A类标准4秒以内,用户可以接受49秒,30用户离开810秒,60用户离开超过10秒,90用户离开B类标准（在用户有心理预期系统响应不够及时的情况下）8秒,用户可接受16秒,50用户离开32秒,90用户离开D用户使用模型。性能测试要通过一系列场景的执行来完成,分析用户的使用模型是获取性能测试需求的有效手段,即定义系统的典型使用方式,考虑哪些用户使用系统的哪些典型业务,在什么时间段和用户数量的估计值,因此需要和最终的用户有很好的沟通,最好能够实地考察用户的应用情况。如某OA系统的每天早上800会有200个用户在10分钟内登录系统每天使用的高峰是在9001100和下午的14001600等。28020原则估算测试强度8020原理每个工作日中80的业务在20的时间内完成。举例如下每年业务量集中在8个月,每个月20个工作日,每个工作日8小时即每天80的业务在16小时完成。去年全年处理业务约100万笔,其中15的业务处理中每笔业务需对应用服务器提交7次请求其中70的业务处理中每笔业务需对应用服务器提交5次请求其余15的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果,每年的业务增量为15,考虑到今后3年业务发展的需要,测试需按现有业务量的两倍进行。每年总的请求数为100X15X7100X70X5100X15X3X21000万次/年每天请求数为1000/20X8625万次/天每秒请求数为62500X80/8X20X3600868次/秒即服务器处理请求的能力应达到9次/秒。3服务器访问日志一般的服务器有两部分日志一是运行中的日志,它主要记录运行的一些信息,尤其是一些异常错误日志信息二是访问日志信息,它记录访问的时间、IP、访问的资料等相关信息。为了获取系统性能测试的需求,可以分析的访问日志以了解系统更多真实负载和主要的业务场景。下面介绍一下利用TOMCAT产生的访问日志数据所做的有效分析。有了这些数据,可以根据时间段做以下的分析处理独立IP数统计访问请求数统计访问资料文件数统计访问流量统计访问处理响应时间统计统计所有404错误页面统计所有500错误的页面统计访问最频繁页面统计访问处理时间最久页面统计并发访问频率最高的页面应用项目的性能测试成功的关键不在于性能测试工具,而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法,性能测试实践经验,才能保证一个应用性能测试的成功。332性能测试脚本开发通过测试需求调研后，对需要做性能测试的典型交易将要进行脚本开发。以行情发布时间为例以集中交易平台系统为例，典型交易为普通转让做市转让竞价转让申报检查申报处理成交摄合成交处理成交回报处理数据维护交易数据查询证券类别查询股票信息查询摄合模式查询回转交易查询异常警报用户登陆用户权限管理日初/日终数据处理实时行情数据管理特殊参数查询与管理交易限制管理日志管理经过前期POC的验证，项目实施时可以采用了LOADRUNNERJAVA和LOADRUNNERSOCKET录制两种方式开发相关的压力测试脚本，两种测试脚本的优缺点与适用范围如下。录制方式脚本可读性开发支持需求对测试人员要求做检查点适用JAVAAPI好强高易复杂业务SOCKET录制差弱低难简单业务对于FIX下单等交易，由于其采用金融领域专有的FIX协议，采用了QUICKFIXJ等相关开发包来完成的FIX下单业务脚本的开发。对于不易使用脚本模拟的业务可使用客户提供的柜台配置工具进行。开始参数化文件逐条获得测试参数和预期结果利用参数形成测试请求发送请求获得服务返回信息测试结果文件结束应用服务器比较返回信息与参数化文件中的预期结果已到达参数化文件结束是否为了保证脚本具体良好的可维护性和可重用性，东软对长期使用的测试脚本采用框架开发，通过使用脚本框架，测试人员只需要在电子表格中填写好测试数据和预期结果并提交给测试工具，测试工具会按计划自动从表格中读取测试用例来执行并记录测试结果，测试执行完毕后自动生成测试对比和统计报告。采用这种方式后可以极大地提高了测试执行效率。把测试人员从繁重无聊的测试执行和整理工作中解脱出来，使测试人员更专注于测试用例的设计和统计分析。同时避免了人工核对数据的不可靠性，从而实现了对每日构建后的系统版本进行快速的回归测试，保证了测试中发现缺陷的及时提交，也加快了系统重构的效率，有效地增强了测试成果的交付能力和质量。333性能测试数据模型建立需求描述针对目前项目交易系统性能需求，制定出符合当前性能测试要求的数据模型建立规范，并主要包括如下内容数据模型分析过程及方法数据模型的类别包括单交易数据模型混合交易数据模型并发场景数据模型稳定性测试场景数据模型数据模型与交易模型、交易场景的组织关系数据模型范围主要有交易系统挂牌公司协议转让普通股票数据模型挂牌公司做市普通股票转让数据模型证券信息行情发布数据模型协议转让行情发布数据模型做事转让行情发布数据模型两网及退市公司股票行情发布数据模型证券交易系统数据模型期货交易系统数据模型业务处理数据模型业务数据日初，日终处理数据模型资产管理系统数据模型系统整理容量数据模型建立数据模型，需要建立基础数据模型和测试数据模型。基础数据模型就是为场景中的数据做评估，产生一个所需要准备的数据的期待值，从而，从数据后台，准备出相应的测试数据记录。做为场景的预备数据测试数据模型是根据场景用运行的脚本，由测试分析师通过编写程序或手工生成的具体的测试数据集合。是有目的性的针对脚本中具体需要什么类型的数据而产生的数据模型。从用户关注系统的业务增长有力要求，可以按客户要求建立容量指标额增长模型，主要是数据量上的要求。334性能测试场景建立东软性能顾问将根据业务负载分析，使用压力工具来模拟未来应用系统的负载模型，从而评估系统所能提供的服务质量是否满足投产的性能需求，同时通过响应时间、资源消耗以及第三方产品的性能来诊断和定位现场IT系统的瓶颈所在，最大化降低客户的运行风险，最大化保护客户的IT投资。针对目前本项目各交易系统的实际运行情况及未来业务发展的需要，制定出符合当前性能测试要求的性能测试场景，主要包括如下内容1性能测试场景的分类标准基准测试场景单交易容量测试场景混合交易容量测试场景并发场景测试场景稳定性测试场景正常交易日交易场景特殊日交易场景高峰交易场景2性能测试场景的组成要素交易数据运行时设置交易配比数据量等3场景来源交易日的日均交易量历史峰值交易日的交易量特殊日的交易量不同交易渠道发起的交易量一般交易日的交易配比历史峰值交易日的交易配比特殊日的交易配比不同交易渠道发起的交易配比4性能场景的加减压策略5数据模型范围主要有交易系统挂牌公司协议转让普通股票测试场景挂牌公司做市普通股票转让测试场景证券信息行情发布测试场景协议转让行情发布测试场景做事转让行情发布测试场景两网及退市公司股票行情发布测试场景证券交易系统测试场景期货交易系统测试场景业务处理测试场景业务数据日初，日终处理测试场景资产管理系统测试场景6委托类场景模型交易报送用户容量测试场景成交回报用户容量测试场景交易并发测试场景交易报送数据容量测试场景成交回报数据容量测试场景交易混合并发测试场景7查询类场景模型客户实时转让交易查询场景客户证券资料查询场景做市商资料查询场景客户资金查询场景客户基本资料查询场景8）交易系统交易系统典型交易做市转让用户容量测试场景客户登陆并发测试场景竞价转让用户容量测试场景账户查询并发场景券商容量测试场景交易并发测试场景日处理成交容量测试场景日处理申报容量测试场景3341TPS场景设计对于金融交易类系统的性能测试场景，在设计上通常采用如下公式TPSVU/PACING它是性能测试方法中最核心的部分，通过该公式，可以较精确的测试出系统的TPS。目标TPS根据需求得到，设置一个PACING就知道需要测试多少VU。减少PACING和增加VU都可以增加目标TPS。分析本项目中系统的性能测试需求，应重点关注的是高峰时段交易量，即高峰TPS，TPS的值一定要满足需求，TPS如果不达标则需要进行优化。对于平均响应时间和交易成功率，仅作参考，在一个可接受的范围内即可。最大并发用户数在测试时不一定要测试到那么多，例如的200并发，在实际测试当中如果在测试到100并发时，TPS就可以满足要求了，那么就认为测试通过，再继续测试200、300等并发只是考察系统可以处理的最大TPS。性能需求是所有测试工作的基础，一定要严格定义严格评审，尽量符合实际业务情况，这样后续的测试结果才有参考价值。实测TPS如果远高于目标TPS，交易指标可能定义的过低，性能问题可能没有暴露。实测TPS如果远低于目标TPS，交易指标可能定义的过高，将会花费大量时间成本用于性能优化，项目周期延长。3342并发用户数估算为了进行容量规划和进行性能方面的管理，正式发布产品之前往往有必要估算系统能够承受的最大并发用户数。因为系统资源的使用直接与并发用户数挂钩。就拿WEB应用来说，内存的使用，CPU的利用率，服务器的进程/线程数，数据库连接数和网络带宽占用率都是关于并发用户数的增函数。尽管知道并发用户数的重要性，大多数情况下用户还是经常通过第六感或者是大胆臆测去估计这个数值，十分缺乏理性。本次介绍一种简单的方法来得出这个并发用户数的估计值通过某些其他的参数，这个值将会更加易于估算并且更加合理。在T时间段里，系统的平均并发用户数为如果LOGINSESSION的总数是N，平均SESSION时长为L,则平均并发用户数为例如一个170000名员工的薪酬系统，预计系统上线只有50的员工定期使用系统其中百分70会在每个月的最后一周使用系统一次，参与了用户接受度测试的员工平均使用系统的时间为5分钟，求某个月的最后一周的并发用户数（限定关注的时间为每一天的工作时间）N1700000507/5（一周工作5天）11900L5分钟T8小时480分钟CNL/T119005/480124所以，每月最后一周使用系统的并发用户数为124如果令并发用户数为X,那么就意味着满足标准正态分布均值为0且方差为1通过查表可以得到这就表示并小用户数小于C3的概率是9987,这个概率对于绝大多数用途都足够大，所C以估算高峰高发用户数为C3,即C沿用以前的例子，补充条件如下假设80的员工进入这个薪酬系统的时间是上午930到1230以及下午230到430这5个小时，尽管一天工作时间是8小时。并且，在这5小时之间登录数保持稳定。则N17000005（07/5）08（一周工作5天）9520L5分钟T5小时300分钟CNL/T95205/300159高峰并发用户数C3CC196利用上述公式可以通过系统的登录用户数来计算某段关注时间的平均并发用户数，另外给出了一些估算这些参数的建议。在登录用户数符合泊松分布的假设下，大致推断了高峰并发用户数的上限。在实际业务数据不完整的情况下，前面的分析为提供了一个分析和解决问题的方向。更准确的预估并发用户数还是需要对用户使用习惯的了解，或是从系统日志中采集。335系统资源监控规范及性能指标建立为了更迅速、有效的向客户提供评估、分析、诊断和解决性能问题的专业服务，针对不同客户和项目的需求，东软设计了一系列的解决方案、方法、策略、工具集和顾问人员来供客户选择。针对目前本项目性能需求，制定出符合当前性能测试要求的系统资源监控规范，将分别建立各系统的差异性监控方法。具体监控指标项可按项目实际业务需求进行裁剪或增补。3351监控方法本项目中所使用的所有工具将给出相关的监控实施手册，包括WINDOWS、LINUX、ORACLE、SQLSERVER等操作系统、中间件的监控规则，如SITESCOPE监控实施手册、IBMNMON监控实施手册、AWR监控实施手册、LR监控插件开发手册等，完成知识传承及转移。3352监控策略本项目使用LOADRUNNER监控业务的性能结果并使作相关专业工具监控服务器的性能指标情况。使用LOADRUNNER监控服务器的性能情况变化趋势，直到场景执行完毕，判断场景所包含的业务功能是否存在性能缺陷。3353监控指标性能指标是指评价软件和解决方案性能质量的尺度及依据。在该性能测试平台项目中我们主要关心以下几种度量指标，其中包括响应时间RESPONSETIME、系统吞吐量THROUGHPUT、系统资源利用率UTILIZATION，并发用户数CONCURRENTUSERS、HTTP事物处理数/秒和会话/秒HTTPTRANSACTIONSPERSECONDANDSESSIONPERSECOND、网络流量统计NETWORKSTATISTICS,资源请求队列长度、标准偏差等。1、响应时间响应时间也称为用户等待时间，从用户观点来看，它是从一个请求的发出到客户端收到服务器的响应所经历的延迟，通常以时间单位来衡量，如秒或毫秒。一般而言，等待时间与尚未利用的系统容量成反比。它随着低程度用户负载的增加而缓慢增加，但一旦系统的某个或几个资源已经耗尽，等待时间就会快速的增加（即性能拐点）。下图表明了响应时间与用户负载量之间的典型特征关系。2、吞吐量（点击率）吞吐量是指在某个特定的时间单位内系统所处理的用户请求数目。常用的单位是请求数/秒或页面数/秒。3、资源利用率资源利用率是指系统不同资源的使用程度，比如服务器的CPU，内存，网络带宽等等。它常用资源利用百分比来衡量，如下图所示，利用率通常与用户负载成正比，但是当达到一定数量时，随着用户量持续增长，利用率将保持一个恒定的值，这里已经达到资源的最大可用度。当某项资源在系统运行的某段时间内90，则说明该资源已经成为系统的瓶颈。提升这种资源的容量可以增加系统的吞吐量并缩短响应时间。4、并发用户数并发用户数是指系统在运行期间内同时访问的用户数。并发用户数增加，系统资源利用率也将增加。5、每秒请求数和会话数每秒请求数指每秒钟客户端向WEB站点发送的GET或POST请求数量。每秒会话数是与性能紧密相关的，它是每秒中到达并访问网站的用户数目。6、标准偏差标准偏差体现了系统的稳定性程度。偏差越大，表明系统越不稳定，这样的后果就是部分用户可以感受良好的性能，而另一部分用户却要等待很长时间。本项目将使用LOADRUNNER等工具监控服务器的性能情况，为发现性能缺陷提供准确的参考数据。根据前期POC经验下面列出常用的一些参考指标。对于不同的交易系统其监控方法、监控策略、监控指标也有不同。类别指标名称描述每秒交易数TPS每秒成功处理完成的交易数量系统表现交易响应时间客户端发送请求,服务器返回最后或者第一个字节的时间交易成功率指定时间内成功完成的事务数量网络吞吐量每秒系统流入流出的字节数PROCESSORTIMEPROCESSOR_TOTAL总的CPU占用率SYSTEMPROCESSORQUEUELENGTH处理队列中的线程数USERTIMEPROCESSOR_TOTAL用户进程的CPU占用率PROCESSPRIVATEBYTES进程独占的内存字节PROCESSWORKINGSET进程使用的内存页DISKTIMEPHYSICALDISK_TOTAL指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比AVGDISKQUEUELENGTH读取和写入请求的平均数AVAILIABLEMBYTESMEMORY可用物理内存数PAGEREADS/SEC每秒发出的物理数据库页读取数NETWORK网络流量WINDOWSCONTEXTSWITCHES/SECSYSTEM每秒线程切换次数CPUUTILIZATION（SYSTEMUSER）CPU占用率操作系统用户进程REDHATLINUXAVERAGELOADCPU处理等待线程数类别指标名称描述PAGINGRATE内存页交换率DISKBUSY磁盘处占用率CONTEXTSWITCHESRATE线程切换率NETWORK网络流量MEMORYFREE内存占用高速缓存区命中率高速缓存区命中率库快存命中率库快存命中率共享区库缓存区命中率共享区库缓存区命中率SGA中字典缓冲区的命中率SGA中字典缓冲区的命中率回滚段的争用回滚段的争用SGA中重做日志缓存区的命中率SGA中重做日志缓存区的命中率监控内存和硬盘的排序比率监控内存和硬盘的排序比率ORACLE当前打开游标总数当前打开游标总数PAGESPLITS/SEC每秒钟分页次数FULLSCAN/SEC每秒发生的全表扫描次数BATCHREQUESTS/SEC每秒钟批次请求数量SQLCOMPILATIONS/SEC每秒编译SQL语句数量USERCONNECTIONS当前用户连接数NUMBEROFDEADLOCKS/SEC每秒死锁数量AVERAGEWAITTIMEMS平均锁等待时间SQLSERVERTOTALSERVERMEMORY（KB）SQLSERVER使用的全部物理内存0053610216266061509780605430237660665616407661931290480931718人员_人员查询绩效管理_制定绩效计划人员导出人员人员_人员入司自助_查看工资条登录HR登录绩效管理_绩效审核组织_展现制定聘任活动页面加班审批绩效管理绩效评估人员_人员花名册360度_评估人提交评估结果薪资_薪资查询登录_员工自助登录问卷_用户提交员工调查答卷0481216平均响应时间（秒）90响应时间（秒）业务混合场景响应时间0999045100026843942649970421020999040709986843099976476843人员_人员查询绩效管理_制定绩效计划人员导出人员人员_人员入司自助_查看工资条登录HR登录绩效管理_绩效审核组织_展现制定聘任活动页面加班审批绩效管理绩效评估人员_人员花名册360度_评估人提交评估结果薪资_薪资查询登录_员工自助登录问卷_用户提交员工调查答卷0TPS业务混合场景TPS3354监控工具本项目对系统性能监控将主要采用四种方式使用HPSITESOPEFORLR100工具部署单独的性能监控服务。收集各服务器的硬件资源利用情况（包括CPU、内存、磁盘、网络等）以及SQLSERVER和ORACLE数据库的相关性能指标。使用IBMNMON工具收集LINUX服务器的硬件资源利情况（包括CPU、内存、磁盘、网络等）。使用LOADRUNNER自定义脚本监控特殊关注的ORACLE指标。使用ORACLEAWR监控ORACLE的性能表现。34性能基线的建立与维护针对不同交易系统建立性能测试档案，根据历次测试结果分析性能变化趋势，在性能基线的建立与维护中主要有以下内容根据不同系统建立性能测试档案性能基线统计指标性能基线记录规范1002003003503503803804005001002003004005000100200300400500600102030系统总体交易处理能力业务压力（笔/秒）实际处理（笔/秒）20406080100152025303530323334100200300400500020406080100120102030服务器CPU消耗业务压力（笔/秒）CPU占用率（）500550600650700550560570580590450460470480490100200300400500400450500550600650700750102030服务器内存消耗业务压力（笔/秒）内存占用（M）3503805005000100200300400500600102030系统总体交易处理能力业务压力（笔/秒）实际处理（笔/秒）602533300010203040506070102030服务器CPU消耗业务压力（笔/秒）CPU占用率（）600570470300400450500550600650102030服务器内存消耗业务压力（笔/秒）内存占用（M）在进行多轮多版本软件测试中，将针对性能测试硬件环境、应用软件版本，中间件及数据库等配置进行基线管理。确立软件的相关关注点的可接受性能基线并建立软件性能演化步进模型，对软件的性能特征进行分析与预测。35性能测试沟通机制东软经过多年实施第三方测试的经验，现在已经形成了一套稳定、高效的沟通方法、规范和流程。建设方开发厂商第三方测试测试需求测试业务模型第三方测试用例测试总结与分析厂商测试案例评价测试日报、周报、月报通报开发风险与进度提出业务需求待测系统厂商测试案例测试缺陷测试案例整改意见缺陷跟踪情况在客户的质量保证工作思路中，东软第三方测试作已作为重要一环，主要进行系统的上线前测试执行、缺陷跟踪、厂商用测试方案审核以及测试分析等工作。测试过程和开发过程都贯穿软件过程的整个生命周期，它们是相辅相成、相互依赖的。在每个项目开发周期的软件测试服务过程中，需要进行若干轮的迭代测试，测试过程可由多个迭代计划、应对变更及复审迭代组成，第三方测试团队采取增量测试的方法与开发厂商团队进行交互。RELEASE14RELEASE13RELEASE12REL11产品26周开发活动发布增量的产品生产高质量的产品测试团队（第三方测试公司）启动项目产品前景项目目标、约束条件粗粒度需求大致估算迭代发布计划项目状态26周服务活动发布增量的平台服务报告开发团队（应用开发厂商）开发团队（应用开发厂商）允许发布可交付的产品中间产品（工件）允许发布可交付的产品用户需求细化的需求、变更的需求、设计方案客户服务等平台、软件复用过程改进、监理、测试每个项目的开发过程包括两个团队，即第三方测试团队和软件开发团队。这两个团队相对独立。测试团队负责发布增量的测试用例和测试报告，以及确认是否能够发布可交付的产品；软件开发团队负责发布增量的产品。第三方测试团队不仅要完成了新增需求中要求的测试，而且还要从系统功能、安全性等角度出发，向建设方及开发厂商提出了相关建议。对测试发现的系统缺陷，东软第三方测试团队建立了完善的缺陷管控流程。具体包括“缺陷提交缺陷确认缺陷修复缺陷回归缺陷关闭上线后运行质量跟踪”等各个环节。通过日报、周报的形式及时将测试情况、缺陷跟踪情况及时通报给联通局方，以便局方随时掌握重点项目进展情况。每周通过周例会，通报周测试情况，对针对重点项目进行测试情况分析，为一期项目测试工作提供数据、材料依据。除此之外，东软第三方测试团队可以从测试用例设计整体思路、测试用例有效性、覆盖面、复用性和可维护性等方面出发，着重对重点项目的厂商测试用例和方案进行评审。通过专业的用例评审，帮助系统在上线前验收测试中最大程度的发现系统中的缺陷。36性能测试实施过程根据企业的实际情况，性能测试应该分为开发与用户现场两个阶段来进行。严格地讲，性能测试应该按照测试环境的软、硬件配置高低分为两个阶段。只是由于开发阶段的软、硬件配置相对较低，而用户现场的投产环境软、硬件配置较高，因此才把性能测试分为开发与用户现场两个阶段。对于拥有先进实验设备甚至实验室的公司，完全可以在开发阶段完成全部的性能测试工作，如果用户现场仍要进行性能测试，则只是相对简单的验收测试。开发阶段的性能测试实施开发阶段的性能测试主要指软件试运行前的性能测试。这一阶段的性能测试是一个反复迭代的过程。这一阶段的性能测试较多关注于软件功能而引起的缺陷。因此主要进行用户并发性能测试，即核心模块并发用户测试与组合模块并发用户测试。此外，可能还会进行一些预期性能指标的性能测试。通过开发阶段的性能测试可以发现一些核心算法问题，最大限度地排除由软件本身引起的问题。对于系统类软件或特殊应用系统的性能测试，解决其性能问题可能很耗时，所以应该较早地组织硬件资源进行各类性能测试，例如疲劳强度与大数据量测试、服务器性能测试等。用户现场性能测试的实施用户现场的性能测试有验收测试的“味道”，是开发阶段性能测试工作的延续。这一阶段的性能重点是关注性能测试的整体表现。可以看出，用户现场的性能测试主要是为了验收与调优。因此对于系统软件和特殊应用系统，性能测试应该尽可能全方位覆盖。而对于一般应用系统，由于风险较低，所以测试范围可以适当缩小以节省成本。用户现场的性能测试主要基于投产环境，测试对象多是即将准备投产的系统，甚至可能是已经投产的系统。投产环境的硬件资源配置通常较高，各类性能测试基本都可以开展。对于系统软件和特殊领域的应用系统，这一阶段的性能测试主要包含预期指标性能测试、并发用户性能测试、各类服务器性能测试、疲劳强度与大数据量性能测试等内容，基本覆盖了“全面性能测试模型”的各个方面。与开发阶段的性能测试相比，本阶段执行的性能测试用例数量可能会少一些，但是测试用例覆盖的范围与开发阶段的性能测试基本一致。一般应用系统在用户现场的性能测试通常包含预期指标性能测试与用户并发性能测试，可能也会对服务器进行一定的测试，不过内容通常比较简单。一般应用系统发生性能问题的风险通常不会太高，因此只要通过验收测试即可。东软的性能顾问能够通过科学先进的方法加上有效的工具模拟出客户未来的负载模型来测试和优化应用系统性能。一个典型的案例要经过计划、执行、分析、和收尾四个阶段。3611计划阶段计划阶段主要是分析客户应用系统的组成、结构、应用特点以及和业务相关的流程操作。针对具体的客户性能需求和应用性能特点，选择测试策略、测试方法和测试点，同时编制测试计划、准备环境、准备用例等相关内容。在计划阶段主要包括两部分工作内容，1评估被测系统系统的性能测试一般是软件系统已经开发或是部署完成之后的测试，要求测试对象至少具有一定的稳定性，在功能上基本满足了需求，对一个很不稳定或是半成品的软件系统进行测试没有太大的意义。然后通过对被测系统进行功能和业务分析，确定系统的架构类型、关键业务与非关键业务的性能特点和分类、客户的性能需求、用户的行为模式、以及风险评估等。通过对被测系统的评估，可以测试人员充分的了解项目、系统的背景和性能需求，为正确的选择测试方法和测试策略打下基础。通过对系统的业务模式和用户行为的分析，可以选择合适的工具和方法来定义真实有效的性能测试场景，通过风险评估还可以有效的控制整个项目的有效性和正确性，最小化整个项目的风险。2组建测试团队通过前期对系统的评估，建立一定可以进行性能测试的团队。根据项目的大致情况，确定人员需要的技能，从而从组织中挑选合格的人员组成测试组。3用户活动剖析与业务建模用户活动剖析与业务建模活动用来寻找用户的关键性能关注点。用户对系统性能的关注往往集中在少数几个业务活动上，在确定性能目标之前，需要先把用户的这些关注点找出来，从而确定最贴近用户要求的性能目标；用户活动剖析的方法大体上分为两种系统日志分析和用户调查分析；系统日志分析是指通过应用系统的日志了解用户的活动，分析出用户最关注、最常用的业务功能，以及达到业务功能的操作路径；用户调查分析是在不具备系统日志分析条件（例如，该系统尚未交付用户运行实际的业务）时采用的一种