软件测试之性能测试

性能测试是与时间相关的。

主要内容

性能测试基础
概念和术语介绍
性能测试模型
性能测试分类介绍
性能测试实施与管理

性能测试基础

为什么要进行性能测试（WHY）（最重要）

应用程序是否能够很快的响应用户的要求？
应用程序是否能处理预期的用户负载并有盈余能力？
应用程序是否能处理业务所需要的事务数量？
在预期和非预期的用户负载下，应用程序是否稳定？
是否能够确保用户在真正使用软件时获得舒服的体验？问题的根源一般是：在多种平台上的数百个服务器；异构系统、多种应用；数千个工作站；局域网、广域网和其它分类型的分布式网络体系机构；交错的故障点。误区：提高一下硬件配置就可以提高性能了，因此性能测试不重要？该说法是错误的。只能是临时解决问题，而不能从根本上解决问题。

进行性能测试时，要关注什么？（WHAT）

并发用户数、吞吐量
平均响应时间
服务器资源占用情况
可靠性、可扩展性
发现引起系统问题的原因，关注采用何种技术提高系统性能
软、硬件配置是否合适（容量规划、硬件选型）

谁来关注？（WHO）

开发人员
- 系统架构：架构是否合理？
- 数据库设计：数据库设计是否存在问题？
- 代码：代码是否存在性能问题？系统中是否存在不合理的内存使用方式？
- 设计和代码：系统中是否存在不合理的线程同步方式和不合理的资源竞争？
系统管理人员
- 资源利用率：应用服务器和数据库使用状况合理吗？
- 系统容量：系统最多能支持多少用户的访问？最大的业务处理量是多少？
- 系统稳定性：系统能否支持7*24小时的业务访问？
- 系统可拓展性：系统能否实现拓展？系统性能可能的瓶颈在哪？
用户
- 响应时间过长会是用户烦躁不安（3/5/8）。
- 系统稳定性：出现HTTP 500 错误或数据库崩溃会让用户对系统失去信心。
业务人员
- 参数：如何向用户提供参数，例如：支持多少用户使用？响应时间是多少？
测试人员
- 以上都要关注
- 能否发现系统中出现的瓶颈？
- 能否真实有效的评估系统性能能力？

关注的领域主要是？（WHERE）

能力验证
- 性能测试中最简单也是最常用的一种。主要关心：在给定的条件下，系统能否具有预期的表现？
规划能力
- 主要关心：应该如何才能使系统具有我们要求的性能能力？
性能调优
- 性能调优活动回合其他领域的活动交杂在一起。是一种在开发阶段和测试阶段都可能会涉及到的性能测试应用领域。
发现缺陷误区：性能测试独立于功能测试。此说法是不对的。性能测试是依赖于功能测试。
- 主要目的是：通过性能测试的手段来发现系统中存在的缺陷。

何时进行性能测试？（WHEN）

一般在功能测试的中后期进行。

概念和术语介绍

性能测试是通过自动化的测试工具模拟各种正常、峰值以及异常负载条件来对系统的各项性能指标的测试。

做性能测试一般关注的性能指标是什么？

并发数

系统用户数：该系统的注册用户数。例如，QQ有100个注册用户。
在线用户数：即登录的用户数。例如，100个人里面有60个人为在线状态。
并发用户数：是对服务器产生压力的用户。例如，这60个人里面只有20个人在进行通信或其他操作。这20个人就是并发用户数。并发用户数：同一时间进行同一操作的用户数。

响应时间又叫请求响应时间：TTLB 对请求做出响应所需要的时间一般为：

复制

事务响应时间事务是一组密切相关的操作组合。登录就是一个事务。

每秒事务通过数 TPS是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户数的增减而改变。

点击率每秒点击数代表用户每秒向Web服务器提交的HTTP请求数。点击率越大，服务器压力越大。

吞吐量单位时间内系统处理的客户请求的数量。（根据业务来说的）直接体现软件系统的性能承载能力，一般来说用请求数或页面数来衡量。

从业务角度，吞吐量也可以用访问人数/天或是处理的业务数/小时来衡量；从网络角度，吞吐量可以用字节/天来衡量。

思考时间就是用户两个执行动作之间停留的时间。

资源利用率不同系统资源的使用情况。CPU，网络，磁盘，网络。

性能测试模型

曲线拐点模型

总结：随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加的并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

性能测试分类

基准测试、性能测试、负载测试、压力测试、配置测试、并发测试、可靠性测试、失效恢复测试、大数据量测试

基准测试有基础的标准，这样能通过对比发现系统的不同点与变化。应用场景：

可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。
系统进行基准测试可以在较早的阶段发现性能问题。
某系统从来没有进行任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。

狭义性能测试通过模拟生产运行的业务压力和使用场景组合，测试系统的性能能否满足生产系统要求。是一种常见的测试方法。

负载测试负载测试是在被测系统上不断增加压力，直到性能极致。例如：响应时间已经超过预定指标或者某种资源使用已将达到饱和状态。主要目的是：找系统的负载极限，为系统调优提供数据。

压力测试压力测试的目的是：找出高负载下系统的问题，例如资源竞争、同步问题、内存泄露等。

负载测试和压力测试两者可以结合进行。负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加是，系统各项性能指标的变化情况。压力测试，是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

配置测试是通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最有分配原则。

并发测试是通过模拟用户的并发访问，测试多用户并发访问同一应用，同一模块或者数据记录时是否存在死锁或者其他性能问题。

并发用户数和并发数是不一样的。

可靠性测试是通过给系统加载一定的业务压力的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

失效恢复测试

失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。
一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常发挥作用。
.不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统。

大数据量测试有两种类型：