vlambda博客
学习文章列表

性能测试的工作是基于系统功能已经完备或者已经趋于完备之上的，在功能还不够完备的情况下没有多大的意义（后期功能完善上会对系统的性能有影响，过早进入性能测试会出现测试结果不准确、浪费测试资源）；因此，性能测试首先是基于功能测试的，你必须了解其功能实现才能开展性能测试。

我们还是来逐步分解说明：

一个被测系统来了，我们需要分三块来分析

入口：需要怎么发送请求，施压方应该施加多大的压力，用什么方法施压；

被测系统：系统怎么应对单个请求，系统业务流程是怎么样的，系统网元节点、数据流向等，整体性能需求有没有，需要考察哪些指标，怎么监控；

出口：接收数据有哪些，怎么获取和比对；

OK，是不是感觉就像功能测试差不了多少?是的，就是先分析单个用户的功能流程以及系统的数据流向（包括后台的数据流向）结构图，然后再考虑大量的用户操作。

那么一般系统的性能测试步骤大体如下：

1） 确认测试目标

2） 分析被测系统业务需求

3） 分析被测系统的系统结构

4） 分析被测系统的性能测试点

5） 设计测试方案、检测方案和测试案例

6） 选择测试工具

7） 测试开发

8） 测试执行

9） 测试结果分析

10） 测试调优、测试验证、测试分析

11） 测试报告

测试准备工作越充分后期的测试执行越顺利，一般测试准备工作如下：

1） 确认测试目标

2） 分析被测系统的业务

3） 分析被测系统的结构

4） 分析被测系统可能产生性能瓶颈的节点

5） 设计测试方案、检测方案和测试方案

我们分步来研究一下：

确认测试目标

拿到一个任何任务首先都要确认任务的目标是什么。如果不知道目标，你所做的任何努力得到的结果有可能都不是最终所需要的结果。

性能测试也一样，它首先是有一个目标的。无论是你是随机测试想看看系统的当前性能情况，还是奔着对系统进行优化而去的，还是检验一下系统的性能是否满足需求，等等，这些都是你再做事情之前的一个目标。你后面所做的一切事情，从分析到方案和案例设计，到测试执行监控，再到最后的测试分析和报告，都是要围绕这个目标展开的。

所以，首要的任务就是确认测试的目标要求，需要达到怎样的一个测试目的和目标。

有一些，测试任务没有明确的目标或者要求，并不说明它没有目的和目标，这就需要我们进行沟通和分析了。

沟通就是要和项目组达成一致的目的要求；分析，分析需求，分析系统，最后也是要明确项目或者系统测试任务的目的要求。

分析被测系统的业务

曾经在一次面试中，有一位面试官给了我这样一个题目：“有一个网站，只知道它的总访问量一天是300万，怎么测试它的性能？”，大家想一想要怎么设计方案？

------猜想面试官是想面试者回答，正态分布、二八原理等基本的测试原则应用。

我当时没有回答任何与正态分布、二八原理相关的东西；记得当时面试官对我的回答好像是“蔑视”的笑了笑；可能是觉着“连基本的正态分布、二八原理都不知道，还搞性能测试？”。其实，性能测试并不是想象的那样简单，并不是一个简单的原理的应用就行的，如果这么容易，那岂不是谁都能搞。

性能测试的基础是基于系统的业务功能基本趋于稳定，首要的任务就是性能在系统满足业务功能需求上展开，因此我们必须要分析系统的业务。不管是普通的网站也好还是比较专业的系统也好，它都是有业务功能需求的，所有的性能测试都要基于这些功能才能进行，脱离了业务功能的性能测试没有意义。性能测试所以首要的任务就是分析系统的业务功能，分析系统业务上的性能限制，也就是业务需求。

那么怎么分析系统的业务需求呢？

（1） 如果有用户需求规格说明，首要的任务就是阅读和理解分析用户需求规格说明；

（2） 如果没有用户需求规格说明，那么就需要分析系统功能，提炼出系统的业务需求。如果可能，项目组比较熟悉的人讲述一遍是最好的了。

（3） 最后无论哪一种，最好的方法就是按照自己的理解画出系统的业务流程或者系统的功能结构图，拿到项目组进行确认。一定要进行确认，和整个项目组达成一致的认同。

有人会说，我们自由测试没有项目组可确认的时候怎么办？

还是一样，需要从分析入手。如果不分析，你就不会知道系统的功能数据流向，请求的数据构成，系统的网元结构，以及系统可能出现的瓶颈在哪一个节点，你又怎么进行优化呢？

当然面对一种全新的知识领域的时候，可能需要我们多积累经验，更多的进行分析；我们可能需要结合实践，多次实际运行系统或者执行测试，在测试中不断的进行优化和完善我们的分析过程、分析结果、测试方案、测试开发甚至是测试执行等等。

分析被测系统的业务，有时候不是一蹴而就，需要我们进行多次反复的分析、确认和再分析、再确认，直到把系统弄明白，甚至有可能在测试执行的最后阶段你还需要再次进行分析和确认，然后重新规划测试。

分析被测系统的结构

系统的结构和系统的业务一样重要，不知道系统的网元结构可能就没有办法进行监控，就没有办法知道瓶颈在哪个节点，就不能进行优化。

分析系统的结构，最好的方法就是项目组提供系统的部署和构成图；如果项目组不能提供或者没有项目组，那就需要用TCPDUMP等抓包工具，分析数据流向。

TCPDUMP的使用：

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型

(2)-i eth1 : 只抓经过接口eth1的包

(3)-t : 不显示时间戳

(4)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包

(5)-c 100 : 只抓取100个数据包

(6)dst port ! 22 : 不抓取目标端口是22的数据包

(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

从第一个节点分析流向到哪，确定第二层的节点；

然后从第二层每个节点分析第三层节点，逐层分析，完善系统的数据流向的所有机构层次和节点；

然后再弄明白每个节点部署的应用程序或者进程队列；

对每一个节点的应用程序或者进程队列进行测试监控；

最后才能得出哪些应用或者进程队列需要进行优化。

弄明白系统的节点构成之外，还需要弄明白各个节点之间的通讯协议和数据格式，后面的测试工具选择和测试数据准备以及测试脚本开发就需要你明白这些。

这一切的基础就是要分析和弄明白系统的所有节点，也就是要分析清楚系统的结构。

分析系统可能的性能瓶颈

分析系统的业务需求和系统的结构组成，同时预判系统可能存在的性能瓶颈，这是分析中的一个目标；得到预判的性能瓶颈后我们后面需要在监控的时候多注意一下这些节点。

当然有一些常见的可能会是系统瓶颈的节点我们需要注意:

（1） 登录，一般系统登录要进行多种校验，可能数据交互比较频繁；

（2） 下单，抢单、抢红包这个时候会有一定量的并发需求；

（3） 大数据的查询、统计和报表分析，会对系统产生压力；

（4） 视频、动画等会对网络产生压力；

（5） 消息比较集中的系统功能节点，会对系统产生压力；

（6） 一些特殊的业务需求会对系统产生压力；

常见的瓶颈：

（1） 数据库的瓶颈一般在磁盘IOPS过高造成进程阻塞

（2） 系统进程数过多一般会消耗系统的内存空间

（3） 消息队列和缓存服务，开启持久化后会需要考察磁盘IOPS，不开启持久化则需要考察内存占用

（4） 频繁的管道开辟和销毁会导致CPU占用较高

（5） 有部分程序结构上不能利用多个CPU

等等！！！

在分析业务和系统结构的过程中，我们就需要考虑这个业务点或者结构点会不会有大量的数据访问，会不会产生压力，我们的设计会不会产生性能瓶颈。

方案和案例设计

测试方案的以及最后测试方案文档的形成，实际就是上面所有分析工作的总结。

你写测试方案的过程就是明确测试目的目标、分析业务需求、系统结构以及评估测试方法、测试安排、测试风险等等的过程总结。而这些全部来源于你在测试执行之前的分析，有时候可能你在测试过程中还需要做出一些分析和调整。

测试方案包含了这些你分析和整理的各个方面。

一个好的测试方案包含的内容：测试目的目标、内容（可能包含业务性能、可靠性、稳定性等等），业务需求目标，系统业务构成，系统节点构成，测试方法流程，需要监控的指标要求和节点等等。

测试案例，实际上一般需要包含在测试方案中；测试案例，实际上就是普通的业务操作流程，用测试工具或者其他测试手段来模拟大的数据量业务操作，并对系统的各个节点进行监控，获取监控数据。预期的监控数据和实际监控数据的对比，满足要求就是预期要求，实际对比结果就是测试结果。