性能测试

CI(持续集成)

持续集成是一种软件开发实践，即团队开发人员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能发生很多次集成。每次集成都通过自动化的编译、发布、自动化回归测试来验证，从而尽快的发现集成错误。许多团队发现这个过程可以大大减少集成问题，让团队能够更快的开发内聚的软件。

注：没有单元测试的持续集成基本无意义

CD(持续部署)

持续部署是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境。比如：我们完成单元测试后，可以把代码部署到测试环境中，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段

分析需求的具体方法

1.快速理解需求的捷径：需求串讲

2.验证需求
需求文档也需要测试：正确性、必要性、完整性、一致性

3.从设计需求中提取测试需要

测试方案主要包括以下内容：

1.测试范围：由需求分析而来

2.测试策略：包括针对不同部分的测试方法、测试用例

3.测试控制：包括测试流程，测试执行，缺陷跟踪

4.其他：环境、版本管理等

5.测试风险

整个测试流程

需求分析—-测试计划(测试方案、测试策略)—-需求测试—-测试用例编写—-测试执行(搭建环境、准备数据、冒烟测试、系统测试、回归测试、交叉测试、自由测试)—-测试报告(缺陷分析、测试结论)

性能测试的基础(5W)

• WHY:为什么进行性能测试
  为了保证软件在以下集中场景下仍能正常使用，所以需要对软件的性能进行测试。
  在多种平台上的数百个服务器
  异构系统、多种应用
  数千个工作站
  局域网、广域网和其他分类型的分布式网络体系结构
  交错的故障点

• WHAT:关注的性能测试内容
  并发用户数/吞吐量
  平均响应时间
  服务器资源占用情况
  可靠性、可扩展性
  发下引起系统问题的原因，关注采用何种技术提高系统性能
  软硬件配置是否合理

• WHO:哪些人员关注性能
  开发人员
  系统管理人员
  用户
  业务人员
  测试人员

• WHERE:性能测试的关注领域
  能力验证：在给定的条件下，系统能否具有预期的表现
  规划能力：应该如何才能使系统具有我们要求的性能能力/在某种可能发生的条件下，系统具有如何的性能能力
  性能调优：对系统性能进行调优
  发现缺陷：通过性能测试的手段发现系统中存在的缺陷

• WHEN:何时进行性能测试
  功能测试中后期

关于性能测试的概念和术语介绍

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

• 作用：用来保证产品上线或发布后系统的性能满足用户需求，性能测试在软件质量保证中起重要作用

性能测试的监控指标

并发数

系统用户数：该系统的注册用户数
在线用户数：登录系统的用户
并发用户数：同一时间进行同一操作的用户数

并发数如何估算？

C–>平均并发用户数，n–>login session的数量，L–>login session 的平均长度
T–>值考察的时间长度，C’–>并发用户数峰值

（1）平均并发用户数为：C = nL/T
（2）并发用户数峰值：C’ = C+3*根号C

响应时间

又叫请求响应时间：TTLB(time to last byte)
对请求做出响应所需要的时间

• 网络传输(请求)时间 + 服务器处理(一层或多层)时间 + 网络传输(响应)时间

事务响应时间(Transaction Response Time)

事务是指一组密切相关的操作组合，例如：一次登录包含多个HTTP请求，要判断用户是否存在，密码是否正确，是否已经登录

每秒事务通过数(Transaction Per Second)

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

点击率(Hit Per Second)–>注重请求

每秒点击数代表用户每秒向Web服务器提交的HTTP请求数。点击率越大，服务器压力越大。
这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求

吞吐量(Throughput)–>注重处理

单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。

• 一般来说用

  请求数/秒
  页面数/秒

• 从业务的角度

  访问人数/天
  处理的业务数/小时

• 从网络的角度

  字节数/天

思考时间(Think Time)

思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间(即操作时的等待时间)，是为了更加真实的模拟用户的操作场景

资源利用率

不同系统资源的使用情况。如：CPU、磁盘、内存

性能测试的分类

基准测试

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

狭义性能测试

通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能能否满足生产系统要求。是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。是一种正常的测试，主要是测试系统正常使用时是否满足要求

负载测试

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

压力测试

• 压力测试是测试系统在一定饱和状态下，系统能够处理的会话能力，以及系统能否会出现错误，压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景。

• 目的：为了揭露高负载下的问题

配置测试

配置测试方法是通过被测系统的软硬件环境的调整(使软、硬件资源达到最大化被利用)，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最优分配原则

并发测试

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

可靠性测试

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

失效恢复测试

1.失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及这种情况发生，用户将受到多大的影响

2.一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常发挥作用

3.不是所有的系统都需要进行这种类型的测试，尤其是没有明确给出系统需要持续运行指标的系统

大数据量测试

• 两种类型：
  1.独立的数据量测试(针对一个功能)
  针对某些系统存储、传输、统计、查询等业务进行大数据量测试

  2.综合数据量测试

  • 两个维度：
    （1）多个业务场景一起，如：查询、登录…

    （2）从性能测试分类：和压力测试、负载测试、并发测试、可靠性测试相结合

区分负载、压力、并发测试

性能测试实施与管理

性能测试前期准备

1.系统基础功能验证

2.组件测试团队

3.测试工具需求确认

测试工具引入

1.工具选择

2.工具应用技能培训

3.确定工具应用过程

测试方案

1.调研测试需求

（1）测试业务范围
（2）测试环境
（3）测试目的
（4）性能指标

2.测试策略和测试资源需求

（1）测试工具、测试方式、测试执行
（2）人力资源
（3）硬件资源

3.性能测试计划

测试设计与开发

1.测试环境设计
2.测试场景设计
3.测试用例设计
4.脚本和辅助工具开发

测试执行与管理

1.建立测试场环境
2.部署测试脚本和测试场景
3.执行测试和记录结果

测试分析与调优

根据测试结果进行分析，给出调优方案

测试报告

1.测试目标
2.测试概要描述
3.测试结果和数据
4.测试结论