04-性能测试过程

1.  软件测试的定义

l  定义1：1983年IEEE（国际电子电气工程师协会）提出的软件工程标准术语中给软件测试下的定义是：

       “使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。

l  定义2：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去执行程序，以发现软件故障的过程。该定义强调寻找故障是测试的目的。

l  定义3：软件测试是一种软件质量保证活动，其动机是通过一些经济有效的方法，发现软件中存在的缺陷，从而保证软件质量。

2.  性能测试过程

应用系统的性能测试通常有如下过程：

u 1)分析性能需求：了解系统性能需求，建立性能测试数据模型，分析性能需求，确定合理性能目标；

u 2)制定性能测试计划：规划性能测试所需的测试环境、测试程序，测试的人员组织，测试日程等；

u 3)设计场景：设计性能测试的测试案例；

u 4)根据场景编写程序、编写脚本、修改应用系统等；

u 5)执行性能测试：建立测试环境、执行测试案例，记录测试时的系统的各个可能的参数；

u 6)分析测试结果：根据应用系统表现和测试时的系统记录，分析发生的问题和测试结果；

u 7)优化性能：提高系统的性能，使系统在测试时有更好的表现；

u 8)性能回归测试：验证系统的优化以及对相关功能模块的影响；

u  9) 测试报告：对测试进行总结，记录已改进的问题及相关改进的修改，制定未解决问题的对策，提出系统运行、维护和改进建议。

3.  性能测试目的

3.1.  能力验证

l  比如电信计费软件,众所周知,每月二十日左右是市话交费的高峰期,全市几千个收费网点同时启动。如此众多的交易同时发生,对应用程序本身、操作系统、数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。

l  决策者需要模拟系统负载压力, 预见软件的并发承受力, 这是在测试阶段就应该解决的重要问题。

l  这里我们强调真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力。那么在条件不允许的情况下，我们可以使用一种“模拟环境”来做测试，这种环境指与实际真实应用环境基本等级保持一致的测试环境。

3.2.  能力规划

l  检测系统性能强调对系统当前性能的评估。通过评估，可以在应用实际部署之前，预见系统负载压力承受力。

l  这种测试的意义在于指导系统总体设计，既可以避免浪费不必要的人力、物力和财力，又避免硬件和软件的设计不匹配，使系统具有更长、更健壮的生命力。

l  对于系统性能检测，有时我们所从事的工作是仅仅是被动监控一些性能指标，而预见系统负载压力承受力则不可避免会借助自动化的负载压力测试工具。

3.3.  应用程序诊断

l  内存泄漏

l  并发死锁

l  程序错误，系统异常等

3.4.  分析瓶颈、优化系统。

l  瓶颈这个术语来源于玻璃瓶与瓶身相比收缩了的部分。收缩的瓶颈将引起流量的下降，从而限制了液体流出瓶外的速度。类似的，在负载压力测试中，“瓶颈”这个术语用来描述那些限制系统负载压力性能的因素，即应用系统中导致系统性能大幅下降的原因。

l  瓶颈可能定位在硬件中，也可能定位在软件中。硬件瓶颈与软件瓶颈相比，我们更建议先解决软件瓶颈。

l  优化调整系统是发现瓶颈，故障定位之后要完成的事情，实现优化之后即可消除瓶颈，提高性能。

l  导致系统性能下降的因素来自许多方面，例如I/O过载、内存不足、数据库资源匮乏、网络速度低、应用程序架构存在缺陷，软硬件配置不恰当等等。比如是磁盘I/O导致了系统瓶颈，那么消除它的方法可能是重新设计数据库或者改进数据库访问方式。

4.  性能测试需求

性能测试需求必须要包含有多少用户（who）在什么时间（when）或者持续多久（when）进行了什么业务（what），最终需要关注怎样的指标（how）。除此以外，需要根据项目性质和性能测试的目标来获得性能测试需求的来源（where），归纳为4W1H。

4.1.  性能需求信息来源（where）

（1）开发过程相关文档。这是性能测试需求的主要来源，项目开发计划书、需求规格说明书、设计说明书、测试计划等文档都可能涉及性能测试的要求，通过收集这些资料，可以找到初步的性能需求。相关的项目干系人有客户代表、项目经理、需求分析员、系统架构设计师、产品经理等。

（2）相似项目性能需求。公司的其他产品或项目会累积出一些数据，如：**技术论坛一小时最多能发1000新帖；****博客平均每天新增800篇，以这些数据为确认新项目测试需求的基础。

（3）业界公认标准。如响应时间，根据服务器的不同和项目的具体情况可能有两类标准：

A类标准——

4秒以内，用户可以接受

4-9秒，30%用户离开

8-10秒，60%用户离开

超过10秒，90%用户离开

B类标准——

8秒，用户可接受

16秒，50%用户离开

32秒，90%用户离开

（4）用户使用模型。性能测试要通过一系列场景的执行来完成，分析用户的使用模型是获取性能测试需求的有效手段，即定义系统的典型使用方式，考虑哪些用户使用系统的哪些典型业务，在什么时间段和用户数量的估计值，因此需要和最终的用户有很好的沟通，最好能够实地考察用户的应用情况。如某OA系统的每天早上8：00会有200个用户在10分钟内登录系统；每天查询交易的高峰是在9：00-11：00和下午的14：00-16：00等。

4.2.  80～20原则估算测试强度（how）

80～20原理：每个工作日中80％的业务在20％的时间内完成。

举例：

每年业务量集中在8个月，每个月20个工作日，每个工作日8小时即每天80%的业务在1.6小时完成。去年全年处理业务约100万笔，其中15％的业务处理中每笔业务需对应用服务器提交7次请求；其中70％的业务处理中每笔业务需对应用服务器提交5次请求；其余15％的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

每年总的请求数为：(100x15%x7+100x70%x5+100x15%x3)x2=1000万次/年

每天请求数为：1000/(20x8)=6.25万次/天

每秒请求数为：(62500x80%)/(8x20%x3600)=8.68次/秒

即服务器处理请求的能力应达到9次/秒。

4.2.1.   基于在线用户的性能测试需求

该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统，通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问