性能稳定性测试方案模版

1、深圳市巨鼎医疗设备有限公司病历本项目性能稳定性测试方案文档编号：受控状态：编制：审核：批准：发布2015-xx-xx发布2015-xx-xx实施深圳巨鼎医疗设备有限公司CLEA?XX性能稳定性测试方案文件编号版本AO页码2/20修订记录日期修订版本描述作者XX性能稳定性测试方案文件编号版本A0页码3/20目录1. 概述51.1. 目的51.2. 历史背景52. 测试范围52.1. 性能指标测试52.2. 稳定性测试53. 测试环境63.1. 网络拓扑63.2. 软硬件配置64. 测试方案64.1. 测试对象分析64.1.1. APP终端74.1.2. APP后台84.1.3. 前置机-云端10

2、4.1.4. 前置机-医院端114.1.5. 全流程114.2. 指标选择（xiangyong提供）134.2.1. 吞吐量134.2.2. 操作相应时间144.2.3. 操作成功率144.2.4. 并发测试154.2.5. 资源使用指标154.3. 数据与脚本准备164.4. 资源监控184.5. 稳定性方案184.5.1. 稳定性业务模型（xiangyong提供数据模型）184.5.2. 稳定性测试周期185. 测试方法18XX性能稳定性测试方案文件编号版本AO页码4/205.1. 吞吐量185.2. 操作相应时间185.3. 操作成功率185.4. 并发测试185.5. 资源使用指标18

3、5.6. 稳定性测试方法196. 测试实施安排196.1. 人力资源196.2. 计划安排197. 输出物207.1. 测试记录207.2. 缺陷&报告20关键词：摘要：缩略语清单XX性能稳定性测试方案文件编号版本A0页码5/201. 概述1.1. 目的通过病历本系统的性能稳定性测试实施，在测试范围内可以达到如下目的：> 了解病历本系统在各种业务场景下的性能表现；> 了解病历本系统的稳定性；> 通过各种业务场景的测试实施，为系统调优提供数据参考；> 通过性能测试发现系统瓶颈，并进行优化；> 预估本系统可以支撑的业务容量；> 为部门是否切平台提供数据依

4、据。1.2. 历史背景描述产品历史版本继承关系，以及之前比较容易出现的性能稳定性问题和现象或，者外面已经使用了此产品的客户反馈较多的性能稳定性问题有哪些等等。不涉及2. 测试范围2.1. 性能指标测试本次性能测试需要测试的性能指标包括：1、吞吐量方面：APP后台每秒能够处理的业务的数量（详见4.2.1）；2、APP前台各操作响应时间，操作类功能要求在3秒以内：3、操作成功率99.99%：（采用LoadRunner工具重复业务10000次）4、并发测试：对APP后台的并发测试，对云端的并发测试；5、资源使用指标：APP后台、前置机服务器CPU（80%）、内存占用率（80%）、数据库资源占用、内存

5、泄露、句柄泄露等；2.2. 稳定性测试范围：1、对APP后台稳定性测试，2、对前置机的稳定性测试；监控内容：1、服务器各进程的CPU、内存、句柄、网络、磁盘10柯血XX性能稳定性测试方案文件编号版本A0页码6/203. 测试环境3.1. 网络拓扑附口灿嬰昔拾俏息科机房即胡户枷料用白方案-；#4ijt«Hf.團立网11|和宜乩即药熬n印科方茶_；腿川成St老"火用庄-服务.-.I“i:饰曲L定內冋J广3.2. 软硬件配置软件环境软件名称版本备注全院系统V2.2?前置机V1.1?病历本V1.1？硬件配置硬件名称数量规格备注云服务器1病历本后台+云端虚拟机1全院服务器1+前置机2

6、虚拟机1全院服务器2+前置机2虚拟机1病历本后台+云端工具工具名称工具版本备注进程监控工具Windows自带的perform系统资源监控工具Windows自带的performLoadRunner&14. 测试方案4.1. 测试对象分析CLEA?柯丽inXX性能稳定性测试方案文件编号版本AO页码7/20依伴系统也架世隐信思科上I?:-:.-grr歸-iii.氐嗟不a&Rii申希丹旦EizEn*州户羁M耐MlgSlIWS玄軍丁网迟貳UKIHil=»J!b|i43»Hl+l.'*皴拥屮心irniJBftneuiiriri#n1>翹也中Iw.k总祠!t

7、uba«j?I任対苍*iflEn-.flftin丹机-臣隘峑4时比4£叩务!flfrpJFi'tiSI爭£TIS)3'iHTll-flEU»WindiTi：J|I用)54肯戛KF肓河阖1叫榔口也时ZlTBQ皤屯H.1eI17|1:出師：和入1.1出*阳ft烧鬥理丽厲7北±削圏Jt叱1可加广虫时JW务i；MR卷It罔慕込卜起ZIT111切屮户H?(HHFJBS9CI殖黑冋4播11nranKF曲SrvIrHfi口)4.1.1. APP终端一、作用：1、向后台发送HTTP请求；2、解析后台返回的数据，UI显示；3、指标和响应时间二、性

8、能测试点：1、对于单个终端，无需测试并发，在后台有压力运行时，使用手机终端测试单个操作的响应（这里计时怎么记录？）；2、建议将APP界面主要功能全部测试一遍，给出体验性能评估（3秒）；备注：基于后台已经存在数据情况下，不考虑数据从全院到病历本后台的时间CLEA?XX性能稳定性测试方案文件编号版本AO页码8/205"|，J口工橫块正辛启漁FF<13<53>3S注册登陆r-i干亦.-?：1.Jt-<208.i.：.as(S：3S用戶叠陆畑>K3t.'i；.L=-fl?f-A-.'-<205(-6i;l>M5第二万昼時<13厂

9、-l'i!1''-：;-d.s<3S>SS®iu*A<13<33>33asW：-S1=:3'as<5S>33妄取片5例£馬例未出as<2S>2S義取储侧已出谓整到需働祥情齐面时间as：3S瓷看<!£；阕;*-1-.1右上伟病例.>?：mes<ES；3S匸"比n<13<3S>3S淖加芋友d.s<3S>3S極找牙主営息姓宕cs；：富借改寺左伯息-至系as：-3£f：-!：as<53>35昼改芾岌伯勲-手机

10、寻缶<3S；阕F:"ds>3S瓷行杀左诒例列喪eg.'兀?：r，、.tr.中匸-i1：日<33旳r-=:'.itd.s：3S>SS極初吓人営息莊码as富降改冲认伯更-手机号asCSS：-3Si11：<2QS：=s用>MS"卩P：；l；F缶<3Si.f舒r>-：*：»as(S：3S许孟-下找设BEeg畑>K34"*1'as0>334.1.2. APP后台一、作用1、接收前台HTTP请求；2、按业务逻辑处理请求，还回数据给APP前台；以最复杂的订阅流程为例，下面是业务处理逻辑

11、图柯丽UIXX性能稳定性测试方案文件编号版本A0页码9/20二、性能测试点：1、HTTP请求压力，这里重点测试后台处理前台大量请求时的性能，对前台发送的不同请求分别进行压力测试：包括各种查询、新增、修改请求等，并发模拟100以上请求，通过API接口测试得出后台性能，涉及内容如下；APP终端操作验证点注册/登陆用户注册不开展性能，功能测试测试获取验证码的时间用户登陆1、并发多少人同时登陆退出登陆不涉及第二方登陆不开展性能，功能测试测试获取验证码的时间获取病例获取病例（订阅）1、并发多用户订阅2、手机端测试多久可以收到订阅成功的消息添加就诊卡1、并发测试修改就诊卡不涉及删除就诊卡不涉及家庭病例査看

12、病例列表1、并发查询，通过API接口仅能得到后台响应的时间，前台显示时间如何计算？査看病例详情1、并发查询，通过API接口仅能得到后台响应的时间2、分别测试报告(500K)/胶片(5M)的查询上传病例通过接口无法实现，如需测试并发，需要开发测试接口亲友管理查询亲友列表1、并发测试査询亲友信息1、并发测试添加亲友1、并发测试修改亲友信息不做性能测试姓名、关系、身份证、手机号删除亲友不做性能测试个人中心查询个人信息同查询亲友修改个人信息昵称、密码、手机号忘记密码不涉及XX性能稳定性测试方案文件编号版本A0页码10/20版本AO木页码10/20针对数据库的压力测试，在数据库记录庞大时开展：1、大量查

13、询请求时性能2、大量写入插入数据库操作的性能3、大量更新数据操作的性能针对本地文件库的压力：1、并发写入磁盘操作(这点要在全流程从全院同步文档时测试)2、并发读取文件操作4.1.3. 前置机-云端一、作用：1、WCF服务接收前置机-医院端上传的文件/记录2、将接收的文件/记录写入数据库和磁盘3、定时服务：检测是否有订阅成功的病例，消息推送4、定时服务：定时将订阅记录下发到前置机-医院端5、定时服务：从前置机-医院端下载病例文件/记录二、性能测试点：1、病历本对接多家医院时，所有医院的病例全部传到云端，云端接收文件的能力会是性能瓶颈，这里需要重点测试，要测试多个医院同时推送报告时云端的性能，真实

14、环境搭建两套医院环境与云端对接。备注：要测试多家医院的推送，需要开发工具，通过工具向云端传文件。如果工具暂时无法提供，可以采用修改前置机上传文件线程数的方式，来达到多家医院上传的效果，但这一点依赖与前置机服务器的性能，线程修改太大可能导致CPU处理不了或者网络带宽不足。2、有大量消息推送时，测试消息推送性能，是否会丢失等3、有大量文件需下载时，测试云端从前置机-医院端下载的性能(至少测试并发100个文档的下载)；4、只进不出模式：有大量订阅消息时，在前置机-医院端检查云端下发的这些订阅信息是否柯丽頂XX性能稳定性测试方案文件编号版本A0页码11/20正确（这里要至少两台前置机-医院端来测试，检

15、查云端是否把对应订阅发送到正确医院端）;4.1.4. 前置机-医院端一、作用：1、主服务：接收全院打印的推送通知2、主服务：从全院获取病例文件3、上传服务：上传文件到云端4、内部轮询服务：定时从云端获取订阅的数据5、定时监测全院服务是否正常6、主服务：内部匹配档案记录二、性能测试点：1、全院推送大量打印通知时，测试前置机对消息通知的接收性能；2、从全院下载大量文件时的性能，如测试并发获取100个文件；3、上传文件到云端的性能：同时上传100个文件的性能；【按性能模型中每家医院每天1000个报告，100个用户订阅的，按照上个版本测试结果，前置机每小时可以上传700个报告，这里分析应该不是软件性能

16、瓶颈】4、大量用户订阅时，测试前置机获取订阅数据的正确性，不能有丢失；4.1.5. 全流程1、全院后台-前置机-医院端-前置机-云端的业务：他忡*流程推送换抿谥模型曲卞锐前蛍贾医既站云甲AnpViRIHSh趕塔.it!i怦ii或怡lEkzQMfil住TIIr.MftJ-s-卓口*雨私之带最材兰受宿Hid*件爼碇记議3d申t-"-_»心胡自當记又ftiftI：仙齡现亀北懂找播门于机片ia配gQf吃叱扶麻iiftfI丽电诃*斜1JftHttKH2.I7Wffl*PG思理口«存钙叮问in旦只出不进业务流程性能测试点全院打印作业后推1、全院推送到前置机-医院端全院持续打印

17、1小时，测试这些报柯丽頂XX性能稳定性测试方案文件编号版本A0页码12/20前畫机匪復持】r1芍悴记录1F上传臥列1r上峙文什两舌机云端APP后吕一三文牛送2、前置机-医院端上传到云端告全部推送到云端的性能新增订阅（新注册用户）1、前置机-医院端从云端获取订阅/用户数据2、前置机-医院端根据订阅数据去全院请求数据3、前置机-医院端从全院请求文件流4、前置机-医院端上传文件到云端1、并发订阅，测试这些数据从全院到云端的性能（并发数可以100/200）只进不出：业务流程性能测试点全院打印作业后推送1、全院推送到前置机-医院端2、云端定时下发订阅和亲友数据到前置机-医院端3、云端向前置机请求需要上传

18、的文件数据4、云端从前置机下载文件1、全院持续打印1小时2、并发订阅测试这些报告云端全部下载完的性能新增订阅（新注册用户）1、云端定时下发订阅和亲友数据到前置机-医院端2、前置机-医院端根据订阅数据去全院请求数据3、前置机-医院端从全院请求文件流4、云端向前置机请求需要上传的文件数据5、云端从前置机下载文件1、并发订阅，测试这些数据从全院到云端的性能（并发数可以100/200）柯丽UIXX性能稳定性测试方案文件编号版本A0页码13/20版本AO木页码13/204.2. 指标选择通过现场业务数据统计和业务模型分析，和架构师、系统分析师等交流，最终确认选择如下性能指标进行4.2.1. 吞吐量数据模

19、型：1、每月增加6家医院；2、每家医院每天打印报告数目为1000；3、每家医院每天有10%的报告被订阅，即每天有100份报告的订阅；测试数据：全院：每家医院报告打印速率1000/8，每小时125份，高峰期*3=375份/每小时病历本：接入6家医院时（一个月的数据量）：1）、病历本后台每天订阅600报告，每小时订阅75份，高峰期*3=225份2）、全院主动推送报告共6000-600=5400份，按照服务器每天有6小时处理接收报告，云端每小时需接收900份用户未订阅的报告；3）、每天注册用户数=每月新增用户总数/30，高峰期*3计算，则每天注册用户数=15900*3/30=1590，每小时=159

20、0/8=200；4）、用户登陆的并发数暂时按1000个/小时计算，实际上用户注册后就登陆了，不主动退出，一直处于登陆状态；5）、查询病例列表：按每天订阅的用户数，每人查询3次计算；6）、下载病例，按每天订阅的用户，每人下载1次计算；7）、添加亲友：按每个新注册用户添加两个亲友计算（本人+1个亲友）8）、查询亲友列表：按活跃用户每天查询2次计算9）、查询亲友信息：按活跃用户每天查询2次计算10）、峰值并发：测试每个操作的峰值并发数；运行时间病历本报告数（W）总用户数活跃用户数用户订阅（每小时）云端接收全院推送报告（每小时）3个月10847700524767527006个月378954001049

21、41350540012个月140419080020988270010800XX性能稳定性测试方案文件编号版本A0页码14/20用户注册（每小时）用户登陆（每小时）查询病例列表（每小时）下载病例（每小时）添加亲友（每小时）查询亲友列表（每小时）查询亲友信息（每小时）200100020256754001311.751311.752001000405013504002623.52623.520010008100270040052475247带宽需求：运行时间云端接收报告带宽（下仃）（Mbps）云端处理用户订阅带宽（上行）（Mbps）云服务器总带宽（Mbps）1个月3142个月6283个月82106个

22、月1642012个月328404.2.2. 操作相应时间=I.,JM咯工橫块正辛:Ah?<13<53>3S注册登陆r-i干亦.-?：1.Jt-<208.i.：.as(S：3S用户叠陆畑<205<-soSt>M5第二万昼時<13厂-l'i!1''-d.s<3S>SS®iu*A<13<33>33asW：-S1=:3'as<5S>33as<2S>2S義取储侧已出谓整到需働祥情挥面时间as：3S瓷看<!£；阕;*-1-.1右上伟病例.>?

23、：mes<ES；3S匸"比n<13>3S淖加芋友d.s<3S>3S極找牙主営息姓宕cs；：富借改寺左伯息-至系as：-3£f：-!：as<53>35昼改芾岌伯勲-手机寻缶<3S；阕F:"ds>3S瓷行杀左诒例列喪eg兀?：r，、.tr.中匸-i1：日<33旳r-=:'.itd.s：3S>SSas富降改冲认伯更-手机号asCSS：-3S,i1<2QS：=s用>MS"卩P：；L；F缶<3Si.f舒r>-：*：»as：3S许孟-下找设BEeg畑4&quo

24、t;*1'as0>33以上操作响应时间为在APP终端操作的响应时间，手工测试执行。4.2.3. 操作成功率1.如下测试对APP后台开展，通过LoadRunner对API接口测试功能测试次数成功率要求登录10000次（使用LR工具）99.99%添加本人10000次（使用LR工具）99.99%添加亲友10000次（使用LR工具）99.99%查询亲友列表10000次（使用LR工具）99.99%订阅病例10000次（使用LR工具）99.99%查询病例列表10000次（使用LR工具）99.99%查询病例详情1000次（使用LR工具）99.99%下载病例1000次（使用LR工具）99.99%

25、2.对前置机也要开展操作成功率测试，涉及内容如下：功能测试次数成功率要求全院推送报告1000次（使用报告发送工具）99.99%用户订阅1000次（使用LR工具）99.99%XX性能稳定性测试方案文件编号版本A0页码15/20版本AO木页码15/204.2.4. 并发测试1针对APP后台的并发测试，通过对API接口测试并发功能并发数测试次数登录1000要求所有并发均能成功。性能符合2.1.2指标要求，CPU和内存等符合2.1.5要求。获取病例100添加就诊卡100查询病例列表100查询病例详情100添加亲友100查询亲友列表100查询亲友信息1002针对前置机的并发测试：并发功能并发数前置机-云

26、端接收大量上传的病例文件这里需要开发提供工具，冃匕自动向云端发报告1000从前置机医院端下载大量文件这里需要开发提供工具，云端自动下载报告1000有大量订阅成功的病例，消息推送100将大量订阅信息发送到前置机医院端100前置机-医院端从全院下载大量报告100上传文件到云端的性能100全流程-只出不进全院报告推送1000APP用户订阅1000全流程-只进不出全院报告推送1000APP用户订阅10004.2.5. 资源使用指标XX性能稳定性测试方案文件编号版本A0页码16/20在正常的并发测试中，APP后台服务器/前置机服务器的资源使用指标要求：CPU使用率W80%内存使用率W80%磁盘10使用率

27、W80%4.3. 数据与脚本准备1全院数据准备：report和reportcontext中通过python插入50W数据(具体插入数目依赖数据模型)：#coding=utf-8importsysimportosreport=open("c:report.txt","wb")reportcontext=open("c:reportcontext.txt","wb")a1="212015-02-285566778855667788UnAnaly2015-02-2817-25-19.4081ReportXps2

28、015/2/2817:25:192015/3/2817:25:19UnprintNormalAutoDiscern1"c1="12345678955667788test55667788naobu2013?<NewDataSet><_x0031_><Title/><BarCode>55667788</BarCode><PatientName>test</PatientName><CheckID>55667788</CheckID><CheckTime>201

29、3</CheckTime><CheckPart>naobu</CheckPart></_x0031_></NewDataSet>"foriinrange(1000000000000000006,1000000000000500000):j=i+1000000000000000000printja2=str(i)+a1printa2a3=a2+"n"c2=c1+str(i)+''+str(i)c3=str(j)+c2c4=c3+"n"report.write(a3)rep

30、ortcontext.write(c4)report.close()reportcontext.close()#loaddatainfile'c:/report.txt'intotablereport(ID,StationID,ReportTypeID,ReportPath,PageCount,FileType,PrintFileType,ReceiveTime,PrintLastTime,PrintStatus,ReportStatus,DiscernStatus,Layout,PrintParameterID)XX性能稳定性测试方案文件编号版本A0页码17/20#loadd

31、atainfile'c:/reportcontext.txt'intotablereportcontext(ID,Title,HspsPatientID,BarCode,PatientIDStr,PatientName,Age,Sex,CheckID,CheckPart,CheckTime,ParseData,ReportID,RelationID)2病历本后台数据准备：medicalrecordinfo和medicalrecordattachment中插入30W数据(具体数目依赖数据模型)#coding=utf-8importsysmedicalrecordinfo=open

32、("c:medicalrecordinfo.txt","wb")medicalrecordattachment=open("c:medicalrecordattachment.txt","wb")a1="0SZHSCH1407755301ChaoShengsuTest180054114054114ChaoSheng2015-09-1600:00:002015-09-16654114654114UnAnaly2015-09-1611-44-35.708001"c1="5603251417

33、366109524SZHSCH14077553012015-09-16654114654114UnAnaly2015-09-1611-44-35.708/CH1407755301/Document/2015/9/16/926dcb5b-cc4b-47a7-8504-e37a639a2854.pdf0.7202015-09-1619:27:20/CH1407755301/Thumbnail/2015/9/16/3b24c996-4224-4f8d-be95-2030a49872a2.Jpeg21"foriinrange(4000,300000):a2=str(i)+''

34、+str(i)+''+a1a3=a2+"n"c3=str(i)+''+str(i)+''+c1c4=c3+"n"medicalrecordinfo.write(a3)medicalrecordattachment.write(c4)medicalrecordinfo.close()medicalrecordattachment.close()#loaddatainfile'c:/medicalrecordinfo.txt'intotablemedicalrecordinfo(ID,Repor

35、tID,HspsPatientID,HospitalName,HospitalCode,DepartmentName,PatientName,Age,Sex,BarCode,CheckID,CheckPart,CheckTime,ReportPath,Mobile,PrintStatus,UploadType,IsValid)#loaddatainfile'c:/medicalrecordattachment.txt'intotablemedicalrecordattachment(MRIID,ReportID,FileID,HospitalName,HospitalCode,ReportPath,AttachUrl,AttachSize,PrintStatus,UploadTime,BigImgUrl,SmallImgUrl,AttachType,IsValid)XX性能稳定性测试方案文件编号版本A0页码18/203.LR脚本准备4全院发送报告工具准备4.4. 资源监控本次测试采用windows自带的perform工具监控，监控病历本后台服务器、前置机医院端服务器的资源使用情况，要求如下：病历本后台服务器端（云端和病历本后台部署在一起）