性能测试设计之业务模型

　　性能测试业务模型主要是用于指导如何将具体的业务变成可重复运行的代码，主要从四个方面分析：业务流程列表、交易列表、百分比模型和交易量评估。

　　业务流程列表：创建关键业务流程列表，以反映最终用户在系统上执行的活动，见表1-1。业务流程表需要反映每个业务在高峰期时操作的用户数，这些问题主要是通过后台的历史数据来获取，获取这些历史数据的目的是做为新一轮测试的参考数据。

　　交易列表：交易业务流程需要确定关键业务(如“登录”或“转移资金”等)的负载情况、交易量等相关信息，见表1-2

　　通过交易列表可以确定业务的优先级，这样在性能测试过程中可以确定哪些业务是需要优先测试的。如上例登录、更新订单、发货是优先级最高的业务。

　　如何获得这些指标是很重要的：

　　日常业务：可以通过后台数据来统计，可以分析三个月、半年或一年的数据，得到这些业务每小时或每秒钟操作的笔数。

　　高峰期业务：选择峰值情况下，单位时间内业务操作的笔数。

　　Web服务器和数据库服务器负载情况，这个测试很难得到，需要与开发工程师进行沟通，确定每个业务对Web服务器和数据库服务器负载的情况。

　　风险：是指当该业务失效或发生错误时，对客户的影响。

　　百分比模型：是指被测试的业务交易的笔数所占整个业务交易笔数的百分比，见表1-3

　　表13-3描述的是银行业务的百分比，但只是摘取了部分业务，在业务中可以看到一些业务名称一样但业务编号不一致，这是因为操作的方式不同，如查询，同样是查询有的是在柜台机上查询，有的是在ATM自动取款机上查询，所以都统称为查询，但业务的编号不同。

　　如果在场景设计过程中使用的是百分比模型，那么在场景设计之前就必须先确定待测试业务的百分比模式，否则无法确定每个业务所占的百分比。每个业务操作的笔数主要是通过后台日志文件来获取，如果该系统是第一次测试那么可以参考其公司类似的系统，或者试上线运行一段时间，这样可以得到一个粗略的百分比模型。

　　交易量评估：通过历史数据来估算系统负载能力，通常使用的方法为80～20原理。

　　80～20原理是指每个工作日中80%的业务在20%的时间内完成。每年业务量集中在8个月，每个月集中在20个工作日中完成，每个工作日8小时，每天80%的业务在1.6小时完成。

　　实例：如去年全年处理业务约100万笔，其中15%的业务处理中每笔业务需对应用服务器提交7次请求;其中70%的业务处理中每笔业务需对应用服务器提交5次请求;其余15%的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

　　每年总的请求数为：

　　(100x15%×7+100×70%x5+100×15%×3) ×2=1000万次/年

　　每天请求数为：1000/160=6.25万次/天

　　每秒请求数为：(62500×80%)/(8x20%×3600)=8.68次/秒

　　即服务器处理请求的能力应达到约9次/秒，如果需要满足3年后的业务增长，那么服务器处理请求的能力应达到约18次/秒。