性能测试案例(银行).pdfVIP

某信息化系统性能测试案例 Manok/飞雪连天 软件测试中文站 9.10.1 分析性能需求 下面是某金融行业软件系统性能测试案例的需求，下面列出了需求并进行了性能 测试需求分析。 表：性能需求表 需求 ID 性能需求 三年规划：客户开户总数 40 万，其中参与交易的客户数为 10 万，其中活跃客户数为 4 1 万。 3 年时每个交易日委托单 24 万。其中：现货委托单 4 万、递延委托单 16 万、交割委托 2 单 4 万，整个清算过程用时不超过 1 个小时（包括下载交易所流水）。 平均峰值每秒交易 25 笔/秒，要求可支持的并发交易量至少为 150 笔(其中各种委托交 3 易 60 笔，客户端查询 60 笔，其它系统处理 30 笔)。系统午市和下午有休市、晚上夜 市（9:00-2:00）交易最多。 4 在最大并发交易量下，交易响应时间不多于 6秒。 5 系统运行稳定，保证 7*24 小时运行（周六和周日虽然不开市，但是系统仍运行）。 根据未来 3 年客户量和交易量规划，计算可能达到的历史业务数据量，在这种情况下 6 的主机清算时间性能，服务器资源等是否达到运营要求以及系统的扩展能力。 根据行方规划，分行数量将由现在的 30 家发展为 45 家左右，保证分行风险监控的性 7 能。 我们根据客户的需求文档整理性能需求，此时客户还没有进行概要设计，性能指 标在需求文档有一些描述，但是不够详细，我们同客户进行了多次深入沟通，整 理出上面的性能需求列表。 系统背景：系统有两个交易渠道，一个柜面，另一个是网络。由于柜面页面量很 小，假设所有业务都是从网银发起。 第一条性能需求： 在整理需求与客户进行沟通过程中，我们了解到客户目前有客户大约 5 万，根据 客户企业的做信息化系统的要求，要做出 3 年系统规划。原来客户在文档列出的 是 50 万客户，我们同业务人员沟通后，分析一期系统上线一年多来客户大概以 50%的速度递增，则按照这个估计，系统上线后，第一年未 7.5 万、第二年末达 到 11.25 万、第三年末达到 16.88 万左右，考虑到上系统上线增加的新业务可能 会带来更高的增长速率，所以是按照 100%的业务增长率计算，新系统上线 3 年 后的客户量为 40 万。根据目前系统中企业客户所占的比例不到 1%，在估算是按 照 1%的法人客户进行估计。经常做交易的活跃用户占所有开户总量的 10%左右。 第二条性能需求： 根据目前系统 5 万用户，大约只有 1000 笔现货和递延委托单（一期只有法人可 以做递延委托交易），实际上只占开户客户总量的2% ，考虑到二期系统上线，将 对个人客户开放递延委托交易，而 5 万客户中只有 1%不到的客户做递延交易， 所以交易笔数不多，如果对个人开放递延委托业务后，则可能迎来一个井喷式增 长，且递延业务的特点是客户可能更多是选择当天买入当天卖出，所以选择 4 万活跃客户每天做 4 笔买入卖出，同时做 1 笔现货买入或卖出，做 1 笔交割。统 计为每天有 24 万笔交易。而在清算时，主要是对每天的交易进行清算。清算时， 交易流水要从交易所下载到企业的交易系统，交易系统与交易所通过专线远程连 接，所以客户要求清算总体时间测试时也要考虑远程传输的网络消耗。 第三条性能需求： 系统要求可以承担 150 个客户并发，客户根据一期生产系统中的各业务的比例关 系，从三个方面的进行估计业务比例，需要在后面设计阶段要更加细化业务比例， 25 笔/秒交易峰值。且给出每天的峰值交易时间段。 第四条性能需求： 原来需求中描述为处理时间不多于 6 秒，对于处理时间的理解存在歧义，我们建 议修改为响应时间。对业务和科技人员讲解响应时间的含义，这样使理解上不存 在歧义，测试工具也能直接获得这个指标。 第五条性能需求： 由于客户的系统为实时交易系统，一周5 天都进行交易，周六和周日虽然不交易， 也不关服务器，所以要求系统 7*24 小时运行稳定。 第六条性能需求： 主要是考虑 3 年后的性能指标要求，主要是指清算时间，另一个考虑服务器的处 理能力和