软件测试-----性能测试
Posted 优雅的心情
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试-----性能测试相关的知识，希望对你有一定的参考价值。
文章目录
一.性能测试的指标
性能测试常用的指标包括响应时间、吞吐量、并发用户数、TPS等
1.1、响应时间
响应时间是指系统对用户请求做出响应所需要的时间。这个时间是指用户从软件客户端发出请求到用户接收到返回数据的整个过程所需要的时间，包括各种中间件(如服务器、数据库等)的处理时间。
1.2、吞吐量
吞吐量是指单位时间内系统能够完成的工作量，他衡量的是软件系统服务器的处理能力。吞吐量的度量单可以是请求数/秒、页面数/秒、访问人数/天、处理业务数/小时等。
吞吐量是软件系统衡量自身负载能力的一个很重要的指标，吞吐量越大，系统单位时间内处理的数据就越多，系统的负载能力就越强。
1.3、并发用户数
并发用户数是指同一时间请求和访问的用户数量。
1.4、TPS
TPS是指系统每秒钟能够处理的事务和交易的数量，它是衡量系统处理能力的重要指标。
1.5、点击率
点击率是指用户每秒向web服务器提交的HTTP请求数，这个指标是web应用特有的一个性能指标，通过点击率可以评估用户产生的负载量，并且可以判断系统是否稳定。点击率只是一个参数指标，帮助衡量web服务器的性能。
1.6、资源利用率
资源利用率是指软件对系统资源的使用情况，包括CPU使用率、内存使用率、磁盘利用率等。资源利用率是分析软件性能瓶颈的重要参数。例如某一个软件，预期最大访问量为1w，但是当达到6000访问量的时候内存使用率就已经达到80%，限制了访问量的增加，此时就需要考虑软件是否有内存泄露等缺陷，从而进行优化。
二、性能测试的种类
性能测试是一个系统，它其实包含多种类型，主要有负载测试、压力测试、并发测试、配置测试等，每种测试类型都有其侧重点。
2.1、负载测试
负载测试是指逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能质变的情况下，系统所能承受的最大负载量。
对于负载测试来说，前提是满足性能指标要求。例如一个软件系统的响应时间要求不超过2s，则在这个前提下，不断增加用户访问量，当访问量超过1万人时，系统的响应时间不超过2s的前提下最大负载量是1万人。
2.2、压力测试
压力测试也叫强度测试，它是指逐步给系统增加压力，测试系统的性能变化，是系统某些资源达到饱和或系统崩溃的边缘，从而确定系统所能承受的最大压力。
压力测试与负载测试是有区别的，负载测试是在保持性能指标要求的前提下测试系统能够承受的最大负载，而压力测试则是是使系统性能达到极限的状态。例如软件系统正常的响应时间为2s，负载测试确定访问量超过1万时响应时间变慢。压力测试则继续增加用户访问量观察系统的性能变化，当用户增加到2万时系统响应时间为3s，当用户增加到3万时响应时间为4s，当用户增加到4万时，系统崩溃无法响应。由此确定系统能承受的最大访问量为4万。
压力测试可以测试那些只有在高负载条件下才会出现的bug，如同步问题,内存泄露等。
性能测试中还有一种压力测试叫做峰值测试，它是指瞬间（不是逐步加压）将系统压力加载到最大，测试软件系统在极限压力下的运行情况。
2.3、并发测试
并发测试是指通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
2.4、配置测试
配置测试是指调整软件系统的软硬件环境，测试各种环境对系统性能的影响，从而找到系统各种资源的最优分配原则。配置测试不改变代码，只改变软硬件配置，例如安装版本更高的数据库，配置性能更好的CPU和内存等，通过更改外部配置来提高软件的性能。
2.5、可靠性测试
可靠性测试是指给系统加载一定的业务压力，使其持续运行一段时间，测试系统在这种条件下是否能够稳定运行。由于加载有业务压力且运行时间较长，因此可靠性测试通常可以检测出系统是否有内存泄露等问题。
2.6、容量测试
容量测试是指在一定的软硬件及网络环境下，测试系统所能支持的最大用户数，最大存储量等。容量测试通常与数据库、系统资源（如CPU、内存、磁盘等）有关，用于规划将来需求增长（如用户增加、业务增加等）时，对数据库和系统资源的优化。
三、性能测试的流程
3.1、分析性能测试需求
性能测试需求分析是整个性能测试工作的基础，测试需求不明确则整个测试过程都是没有意义的。在性能测试需求分析阶段，测试人员需要收集有关项目的各种资料，并与开发人员进行沟通，对整个项目有一定的了解，针对需要性能测试的部分进行分析，确定测试目标。例如客户要求软件产品的查询功能响应时间不超过2s，则需要明确多少用户量情况下响应时间不超过2s。
3.2、制定性能测试计划
性能测试计划是性能测试工作中的重中之重，整个性能测试的执行都要按照测试计划进行。在性能测试计划中，核心内容主要包括以下几个方面：
<1> 确定测试环境：包括物理环境、生产环境、测试团队可利用的工具和资源等。
<2> 确定性能验收标准: 确定响应时间、吞吐量和系统资源(CPU、内存等)利用总目标和限制。
<3> 设计测试场景：对产品业务、用户使用场景进行分析，设计符合用户使用习惯的场景，整理出一个业务场景表，为编写测试脚本提供依据。
<4> 准备测试数据：性能测试是模拟现实的使用场景，例如模拟用户高并发，则需要准备用户数量、工作时间、测试时长等数据。
3.3、设计性能测试用例
性能测试用例是根据测试场景为测试准备数据，例如模拟用户高并发，可以分别设计100用户并发量、1000用户并发量等，此外还要考虑用户活跃时间、访问频率、场景交互等各种情况。测试人员可以根据测试计划中的业务场景表设计出足够的测试用例以达到最大的测试覆盖。
3.4、编写性能测试脚本
测试用例编写完成之后就可以编写测试脚本了，测试脚本是虚拟用户具体要执行的操作步骤，使用脚本执行性能测试免去了手动执行测试的麻烦，并且降低了手动执行的错误率。在编写测试脚本时，要注意一下几个事项：
<1> 正确选择协议，脚本的协议要与被测试软件的协议保持一致，否则脚本不能正确录制与执行。
<2> 性能测试工具一般可以自动生成测试脚本，测试人员也可以手动编写测试脚本，而且测试脚本可以使用多种语言编写，如Java、Python等，具体可根据工具的支持情况和测试人员熟悉程度选取脚本语言。
<3> 编写测试脚本时，要遵循代码编写规范，保证代码的质量。另外，有很多软件在性能测试上有很多类似的工作，因此脚本复用的情况也很多，测试人员最好做好脚本的维护管理工作。
3.5、测试执行及监控
测试人员按照测试计划执行测试用例，并对测试过程进行严密监控，记录各项数据的变化。在性能测试执行过程中，测试人员的关注点主要有以下几个：
<1> 性能指标：本次性能测试要测试的性能指标的变化，如响应时间、吞吐量、并发用户数量等。
<2> 资源占用与释放情况：性能测试执行时，CPU、内存、磁盘、网络等使用情况。性能测试停止后，各项资源是否能正常释放以供后续业务使用。
<3> 警告信息：一般软件系统在出现问题时会发出警告信息，当有警告信息时，测试人员要及查看。
<4> 日志检查：进行性能测试时要经常分析系统日志，包括操作系统、数据库等日志。在测试过程中，如果遇到与预期测试结果不符合的情况，测试人员要调整系统配置或修改程序代码来定位问题。
3.6、运行结果分析
性能测试完成以后，测试人员要收集整理测试数据并对测试数据进行分析，将测试数据与客户要求的性能指标进行对比，若不满足客户的性能要求，需要进行性能调优然后重新测试。直到产品性能满足客户需求。
3.7、提交性能测试报告
性能测试完成以后需要编写性能测试报告，阐述性能测试的目的、性能测试环境、性能测试用例与脚本使用情况、性能测试结果及性能测试过程中遇到的问题和解决办法等。软件产品不会只进行一次性能测试，因此性能测试报告需要备案保存，作为下次性能测试的参考。
以上是关于软件测试-----性能测试的主要内容，如果未能解决你的问题，请参考以下文章