vlambda博客
学习文章列表

1） 确认测试目标

2） 分析被测系统的业务

3） 分析被测系统的结构

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

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

我们分步来研究一下：

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

性能测试也一样，它首先是有一个目标的。无论是你是随机测试想看看系统的当前性能情况，还是奔着对系统进行优化而去的，还是检验一下系统的性能是否满足需求，等等，这些都是你在做事情之前的一个目标。

你后面所做的一切事情，从分析到方案和案例设计，到测试执行监控，再到最后的测试分析和报告，都是要围绕这个目标展开的。

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

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

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

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

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

我当时没有回答任何与正态分布、二八原理相关的东西；记得当时面试官对我的回答好像是“蔑视”的笑了笑；可能是觉着“连基本的正态分布、二八原理都不知道，还搞性能测试？”。

其实，性能测试并不是想象的那样简单，并不是一个简单的原理的应用就行的，如果这么容易，那岂不是谁都能搞。

性能测试的基础是基于系统的业务功能基本趋于稳定，首要的任务就是性能在系统满足业务功能需求上展开，因此我们必须要分析系统的业务。

不管是普通的网站也好还是比较专业的系统也好，它都是有业务功能需求的，所有的性能测试都要基于这些功能才能进行，脱离了业务功能的性能测试没有意义。

性能测试所以首要的任务就是分析系统的业务功能，分析系统业务上的性能限制，也就是业务需求。

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

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

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

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

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

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

分析系统的结构，最好的方法就是项目组提供系统的部署和构成图；如果项目组不能提供或者没有项目组，那就需要用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

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

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

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

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

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

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

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

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

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

常见的瓶颈：

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

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

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

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

一个好的测试方案包含的内容：

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

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

预期的监控数据和实际监控数据的对比，满足要求就是预期要求，实际对比结果就是测试结果。