性能案例.docx
《性能案例.docx》由会员分享，可在线阅读，更多相关《性能案例.docx（9页珍藏版）》请在冰豆网上搜索。
性能案例
某信息平台性能测试案例
一、系统性能分析
ID
性能需求
1
三年规划，客户开户总数40万，其中参与交易的客户达到10万，其中活跃客户数达到4万
2
3年时每个交易日委托单24万，其中，现货委托单4万，递延委托单16万，交割委托单4万，整个清算过程用时不找过一小时（包括下载交易所流水）
3
平均峰值交易25笔/秒，要求可支持的并发交易量至少150笔（其中各种委托交易60笔，客户查询交易60笔，其它系统交易30笔）系统午市、下午休市及晚上夜市交易量最多（9:
00~2:
00）
4
在最大并发交易量下，交易相应时间不得大于6秒
5
系统运行稳定，保证7*24小时运行需要（包括周六日）
6
根据3年规划计算可能达到的历史数据量，在这种情况下主机清算时间性能，服务器资源等是否达到运营要求及系统的扩展能力。
7
根据规划，分行将由30家拓展到45家，保证分行风险监控的性能
系统背景：
有两个交易渠道，分别是柜台和网络交易平台，由于柜台交易量很小，假设甲乙两全部来源于网络从网银发起。
第一条性能要求，银行当前客户量为5万，根据同行的了解，第一年客户增长率大约在50%左右，第一年7.5万，第二年11万，第三年16万，考虑需求要求，均按照翻倍计算。
根据行业规则活跃客户按照10%计算。
第二条性能要求，由于交易所产生的数据和流水下载的不同，流水下载是通过专线网络进行，因此在性能测试时需要考虑到这种情况带来的影响。
第三条性能要求，需要满足150个客户的并发要求，在实际策划中还应进行细化，细化到每秒交易25笔的交易峰值，同时还需要每天峰值的产生时间段。
第四条性能要求为处理时间不大于6秒，建议修改为响应时间不大于6秒，这样各环节不会理解中产生歧义
第五条性能要求7*24小时保障，但周六日无交易也要开机运行，所以会有这样的要求，在测试中仅需考虑五天的实际情况。
第六条性能要求只要针对3年后的历史数据检索，只要满足3年后的处理能力和扩展能力，也就是说给出处理能力和扩展能力的结论即可。
第七条性能要求由于是内部人员使用，没有明确给出风险性能指标的响应时间要求，因此需要考虑性能指标是多少？
客户能否接受测试结果。
二、测试场景设计与开发
首先应对测试性能指标进行分析，确定性能测试指标。
多个指标间所存在的关联，制定出测试模型。
业务：
由客户分析历史数据确定典型业务和具体业务所占据的比例。
测试数据：
数据是否来源于实际数据？
往往由于保密等原因需要测试人员构造测试数据，就需要考虑测试数据间有没有关联关系等。
业务基础数据：
在测试数据输入前一般会有基础测试历史数据，这些数据来源于哪里需要考虑和进行分析
测试方法：
采用的测试类型和各类型的执行顺序都可以在模型中表现出来。
性能指标和资源数据采集：
在测试执行过程中采集那些性能指标，那些指标验证具体哪个性能要求
根据以上分析建立测试模型，构造除测试模型后需要构造测试基础数据为测试性能做全准备工作。
目前5万客户，每天交易总量为1000笔委托，以此为基数计算3年后40万客户的月结单总量为3*40万=120万条记录。
建立数据使用sql写操作数据库方式进行。
三、规划测试环境
在完成数据准备工作后，需要针对性的规划出测试环境，尽可能模拟真实场景的环境。
测试环境的有效性分析以银行实际运营环境为参考。
分析设置的场景是否与真实环境存在差异，这些差异是否影响测试结果的准确性。
四、测试策略的制定
测试策略在制定之初，我们首先制定基准测试策略。
在与运营环境相同或近似的环境下运行测试。
分别录制典型单业务运行脚本。
在单业务脚本上无其他负载运行1个用户，取事物平均响应时间数值作为该业务基准数据进行记录，资源数据包括CPU、内存的利用率，网络吞吐量，服务器时间和网络时间等。
典型业务是指现货委托、递延委托、当日委托查询、当日成交查询、历史委托查询、历史成交查询、资金查询、持仓查询、行情查询、月结单查询和客户信息变更。
在基准数据获取后应准备进行性能的各项测试策略
首先是单一业务的压力负载测试，对单一业务的测试并发数以120、160、200并发，分别记录测试结果数据。
依据业务和数据产生的先后顺序制定测试进行顺序。
在完成单一测试后就要进行相关的组合测试，也就是混合业务测试。
混合业务测试需要考虑使用200并发按照一定比例等比例减少问题。
分别记录平均事物响应时间，交易成功数量等数据。
监控系统资源与单一测试相同。
在完成混合业务测试后需要进行需求中所要求的大数据量测试。
大数据量测试中就不仅需要考虑压力负载测试，同时还需要考虑恢复和备份策略。
以及大数据量下的稳定性测试。
五、测试场景设计
单业务场景设计中首先构造36万个人用户，4万法人客户，并构造24万笔日委托交易数据，在测试中分别执行120、160、200并发交易和查询事务的响应时间。
在所有场景中均不设置迭代测试，迭代间隔为0，增压采用每10秒增加10用户，持续5分钟。
减压采用每10秒减少10用户，延时时间设定为0，忽略思考时间，负载生成器为4台。
六、脚本录制
根据用户提出的测试要求和提供的测试工具综合考虑，本次测试采用lr软件进行性能方面测试。
在网银登陆时用户需要输入用户名、密码、验证码。
为了测试方便，与开发协商，请开发团队协助关闭验证码效验，并将密码设置为统一，这样可以省略密码部分的参数化。
首先需要针对性的录制测试脚本，脚本录制是自动化测试软件所提供的一个强大的功能，很大程度上解决了测试人员花费在写脚本代码上的时间浪费问题。
脚本录制完成后应回放脚本用以检查脚本有无错误以及是否需要做关联。
通过脚本回放可以确定当前所录制的脚本是否需要添加关联，如没有提示需要关联项和提示脚本运行错误则可以进行下一项工作。
脚本中许多地方依据测试要求或测试流程，需要进行参数化，找出这些代码位置，依据需求进行参数化设置。
结合当前项目，由于是单点登录，因此在参数化时需要注意用户名唯一，因密码统一可以不做考虑。
参数化设置完成后，可以开始基准测试，基准测试至少需要两次。
其原因是需要对这两次结果进行比对，如一致则可进行下一项测试，如存在差异则有可能是网络问题或本机问题引起的，此时应首先排除周边问题后在进行多次测试对比，直至可以取得一组最接近的结果作为测试基准。
对于历史数据的查询的测试，很多人会问到是否应该在大数据量下进行测试，个人认为，如果有条件应该在具有少量数据条件下进行一次测试，并在百万或千万数据级条件下再次进行测试，以两次测试的结果对比分析数据量的改变对系统测试指标产生多大的影响，这个影响是否合理。
七、测试结果
在这里我们列出部分基准测试的结果数据进行分析。
场景
业务功能
运行时间
成功完成交易总数
未完成交易总数
交易数/秒
交易平均响应时间
个人业务
行情查询
16
10
0
0.588
1.012
现货委托申报
24
10
0
0.400
0.468
延期合约委托申报
31
10
0
0.313
0.520
撤销委托申报
96
10
0
0.103
1.539
当日委托查询
29
10
0
0.333
1.467
当日成交查询
31
10
0
0.313
1.139
历史委托查询
35
10
0
0.298
1．384
历史成交查询1天
27
10
0
0．313
1.273
历史成交查询一个月
47
10
0
0.270
1.930
保证金出金
44
10
0
0.222
0.847
保证金入金
30
10
0
0.323
0.802
出入金明细查询
58
10
0
0.169
1.541
资金查询
18
10
0
0.526
1.387
库存查询
22
10
0
0.435
1.868
持仓查询
34
10
0
0.286
2.868
签约信息查询
32
10
0
0.303
1.808
法人业务
行情查询
18
10
0
0.526
1.089
现货委托申报
24
10
0
0.400
0.474
延期合约委托申报
31
10
0
0.313
0.582
撤销委托申报
57
10
0
0.172
0.530
当日委托查询
24
10
0
0.400
0.581
当日成交查询
39
10
0
0.250
1.970
历史委托查询
37
10
0
0.264
1.860
历史成交查询1天
37
10
0
0.263
1.860
历史成交查询一个月
39
10
0
0.250
2.099
资金查询
21
10
0
0.455
1.027
库存查询
25
10
0
0.385
1.998
持仓查询
25
10
0
0.385
1.826
我们从上面的测试结果可以看出，当日委托查询和历史委托查询两个单业务在200用户并发时，超过了相应时间不大于6秒的性能指标。
特别是历史委托查询在160用户时就已经超出了6秒的性能指标。
对于这些相关信息，测试工程师应全盘考虑，但并不意味着可以不上报。
升级会员 