软件性能测试脚本案例,性能测试案例(银行).pdf

某信息化系统性能测试案例

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 年后的性能指标要求，主要是指清算时间，另一个考虑服务器的处

理能力和