全国咨询热线：136-9172-9932
在我们测试工作中，多多少少都是会接触到性能测试，那么接手一个项目，究竟怎么做性能测试，又要如何性能测试工作呢?今天就一起来看看!
性能测试的工作是基于系统功能已经完备或者已经趋于完备之上的，在功能还不够完备的情况下没有多大的意义(后期功能完善上会对系统的性能有影响，过早进入性能测试会出现测试结果不准确、浪费测试资源);因此，性能测试首先是基于功能测试的，你必须了解其功能实现才能开展性能测试。
我们还是来逐步分解说明：一个被测系统来了，我们需要分三块来分析
入口：需要怎么发送请求，施压方应该施加多大的压力，用什么方法施压;
被测系统：系统怎么应对单个请求，系统业务流程是怎么样的，系统网元节点、数据流向等，整体性能需求有没有，需要考察哪些指标，怎么监控;
出口：接收数据有哪些，怎么获取和比对;
OK，是不是感觉就像功能测试差不了多少?是的，就是先分析单个用户的功能流程以及系统的数据流向(包括后台的数据流向)结构图，然后再考虑大量的用户操作。
那么一般系统的性能测试步骤大体如下：
1) 确认测试目标
2) 分析被测系统业务需求
3) 分析被测系统的系统结构
4) 分析被测系统的性能测试点
5) 设计测试方案、检测方案和测试案例
6) 选择测试工具
7) 测试开发
8) 测试执行
9) 测试结果分析
10) 测试调优、测试验证、测试分析
11) 测试报告
测试准备工作越充分后期的测试执行越顺利，一般测试准备工作如下：
1)确认测试目标
2)分析被测系统的业务
3)分析被测系统的结构
4)分析被测系统可能产生性能瓶颈的节点
5)设计测试方案、检测方案和测试方案
2.1确认测试目标
拿到一个任何任务首先都要确认任务的目标是什么。如果不知道目标，你所做的任何努力得到的结果有可能都不是最终所需要的结果。
性能测试也一样，它首先是有一个目标的。无论是你是随机测试想看看系统的当前性能情况，还是奔着对系统进行优化而去的，还是检验一下系统的性能是否满足需求，等等，这些都是你做事情之前的一个目标。你后面所做的一切事情，从分析到方案和案例设计，到测试执行监控，再到最后的测试分析和报告，都是要围绕这个目标展开的。
所以，首要的任务就是确认测试的目标要求，需要达到怎样的一个测试目的和目标。有一些，测试任务没有明确的目标或者要求，并不说明它没有目的和目标，这就需要我们进行沟通和分析了。
沟通就是要和项目组达成一致的目的要求;分析，分析需求，分析系统，最后也是要明确项目或者系统测试任务的目的要求。
2.2分析被测系统的业务
性能测试的基础是基于系统的业务功能基本趋于稳定，首要的任务就是性能在系统满足业务功能需求上展开，因此我们必须要分析系统的业务。不管是普通的网站也好还是比较专业的系统也好，它都是有业务功能需求的，所有的性能测试都要基于这些功能才能进行，脱离了业务功能的性能测试没有意义。性能测试所以首要的任务就是分析系统的业务功能，分析系统业务上的性能限制，也就是业务需求。
那么怎么分析系统的业务需求呢?
(1) 如果有用户需求规格说明，首要的任务就是阅读和理解分析用户需求规格说明;
(2) 如果没有用户需求规格说明，那么就需要分析系统功能，提炼出系统的业务需求。如果可能，项目组比较熟悉的人讲述一遍是最好的了。
(3) 最后无论哪一种，最好的方法就是按照自己的理解画出系统的业务流程或者系统的功能结构图，拿到项目组进行确认。一定要进行确认，和整个项目组达成一致的认同。
2.3分析被测系统的结构
系统的结构和系统的业务一样重要，不知道系统的网元结构可能就没有办法进行监控，就没有办法知道瓶颈在哪个节点，就不能进行优化。
分析系统的结构，最好的方法就是项目组提供系统的部署和构成图;如果项目组不能提供或者没有项目组，那就需要用TCPDUMP等抓包工具，分析数据流向。
从第一个节点分析流向到哪，确定第二层的节点;然后从第二层每个节点分析第三层节点，逐层分析，完善系统的数据流向的所有机构层次和节点;然后再弄明白每个节点部署的应用程序或者进程队列;对每一个节点的应用程序或者进程队列进行测试监控;最后才能得出哪些应用或者进程队列需要进行优化。
弄明白系统的节点构成之外，还需要弄明白各个节点之间的通讯协议和数据格式，后面的测试工具选择和测试数据准备以及测试脚本开发就需要你明白这些。这一切的基础就是要分析和弄明白系统的所有节点，也就是要分析清楚系统的结构。
2.4分析系统可能的性能瓶颈
分析系统的业务需求和系统的结构组成，同时预判系统可能存在的性能瓶颈，这是分析中的一个目标;得到预判的性能瓶颈后我们后面需要在监控的时候多注意一下这些节点。
当然有一些常见的可能会是系统瓶颈的节点我们需要注意:
(1) 登录，一般系统登录要进行多种校验，可能数据交互比较频繁;
(2) 下单，抢单、抢红包这个时候会有一定量的并发需求;
(3) 大数据的查询、统计和报表分析，会对系统产生压力;
(4) 视频、动画等会对网络产生压力;
(5) 消息比较集中的系统功能节点，会对系统产生压力;
(6) 一些特殊的业务需求会对系统产生压力;
常见的瓶颈：
(1) 数据库的瓶颈一般在磁盘IOPS过高造成进程阻塞
(2) 系统进程数过多一般会消耗系统的内存空间
(3) 消息队列和缓存服务，开启持久化后会需要考察磁盘IOPS，不开启持久化则需要考察内存占用
(4) 频繁的管道开辟和销毁会导致CPU占用较高
(5) 有部分程序结构上不能利用多个CPU等等!!!
在分析业务和系统结构的过程中，我们就需要考虑这个业务点或者结构点会不会有大量的数据访问，会不会产生压力，我们的设计会不会产生性能瓶颈。
测试方案的以及最后测试方案文档的形成，实际就是上面所有分析工作的总结。
你写测试方案的过程就是明确测试目的目标、分析业务需求、系统结构以及评估测试方法、测试安排、测试风险等等的过程总结。而这些全部来源于你在测试执行之前的分析，有时候可能你在测试过程中还需要做出一些分析和调整。
测试方案包含的内容：测试目的目标、内容(可能包含业务性能、可靠性、稳定性等等)，业务需求目标，系统业务构成，系统节点构成，测试方法流程，需要监控的指标要求和节点等等。
测试案例，实际上一般需要包含在测试方案中;测试案例，实际上就是普通的业务操作流程，用测试工具或者其他测试手段来模拟大的数据量业务操作，并对系统的各个节点进行监控，获取监控数据。预期的监控数据和实际监控数据的对比，满足要求就是预期要求，实际对比结果就是测试结果。
