为满足瞬息万变的资讯化时代需求，电信业务变化层出不穷，业务支撑系统每月一到两次大版本更新，紧急版本更不在话下了。为保障系统的正常稳定，性能测试是版本上线前最后一道重要保障。作为开展性能测试的首要任务，需求分析阶段决定了性能测试的目标是否正确、方法是否合理、度量是否得当。更确切地说，需求分析决定了测试是否能得出客户所希望要的结果。
需求分析阶段需要与客户进行反复地讨论，是一个循环的过程：从需求捕获->需求整理->需求验证->再需求捕获……这项工作既要求有理解能力、设计能力，更要求具有一种与人交往、沟通的能力。
1沟通
需求分析第一步：了解客户的痛点、难点，以便对症下药为客户解决问题。但往往不是每个“病人”都能确切地说出病在哪里，需要细心聆听、耐心沟通，逐步深入问题根源。对于电信这类业务繁多、关系复杂的系统，初入门的需求分析人员会经常遇到由于业务不精的问题，导致过于顺从客户，客户怎么说就怎么执行，最后做得很苦很累，结果却不能让客户满意。
经历了多个项目的实践，与电信客户交往密切后，总结经验得出：在与客户沟通前必须先在电信业务上下苦功，搞清楚业务需求、使用场景、操作步骤、业务系统关联、业务执行路径。多向客户问为什么，可以更深入地理解这些领域知识，站在客户的视角去思考问题，更确切地理解客户提出业务需求的原因。此外，与客户打交道过程中发现：从客户嘴中得到的需求，只是整个测试需求中的冰山一角，还有一些隐藏的需求需要我们自己去挖掘，例如：客户嘴里没说出来的需求，客户未曾想到过的需求。
1.1没说出口的需求
对于客户没有说出来的需求，并不是客户故意卖弄玄虚不愿说出来，而是在客户所在业务领域已经约定俗称，就像人每天都必须吃饭、睡觉一样，根本就不用说出来，行内都自觉遵循的业务规则。然而，作为刚刚步入该领域的需求人员，并不了解这些规则。如果采用被动的方式硬生生地记录客户提到的需求，这部分需求肯定会被忽略掉，这就是为什么累死累活地得出测试结果后，仍然得不到客户满意的结果，并提出大量疑问的原因。遇到这类困境的正确做法应该是先向客户了解清楚业务，摸清楚业务是什么类型，业务规则都有哪些，日常用户的操作习惯，高峰时段等。其中用户群的操作习惯和体验是最重要的，它体现了系统需要承载多少压力，达到怎样的响应速度。多问为什么，因为客户深受该问题困扰，收集整理客户口中的“痛点”可以深入地理解问题产生的根源，从中学习相关领域知识，站在客户的视角去思考问题，从而更准确地理解客户为什么要提出他们的那些业务需求。
1.2没想到的需求
另一种就是客户从没有想到过需求。这种没有想到过的，实际是在业务需求阶段还没有呈现出来的问题，并不代表客户不需要解决或不会出现。很多需求管理员经常抱怨客户的想法一直在变，不断增加新内容。而客户并非专业的测试人员，当新问题被发现，或问题被修复后都需要重新作评估，验证问题产生的原因或修复后的效果。这些都是客户考虑需求前不可能预测到的，当执行到这一阶段，问题出现的时候，很多他们起初没有想到的需求就会源源不断地被提出来。但这时候，性能测试人员的工作量变得很大，被动接受所产生的需求分析工作对项目执行及后续工作埋下巨大风险。解决这类问题要求需求分析人员精通系统架构原理，并结合业务领域知识与需求的充分理解基础上，通过分析提前发现这部分需求，制定测试模型、测试方法，最终形成需求的测试方案。通过从获取、理解、分析、设计、成形的各个阶段，得出高质量的需求分析，才能有效地引导整个测试执行过程，规避各种可能存在的项目风险。可以说，需要分析就是性能测试的蓝图，决定着测试的质量和成败。
2分析&设计
理解了客户的真正想法、掌握真正需求后，需要结合测试思维、环境特性深入分析测试方法及度量指标，定立测试目标，并与客户反复确认。因为测试目标必须要各方都保持清晰一致，才能确保测试得到客户认可的结果。
2.1业务分析
业务分析必须要建立在熟悉业务的基础上，了解为什么需要这个业务，这个业务是做什么的，该业务的使用人群，影响对象等。这些业务背景往往很容易在繁重的测试任务中被忽略掉，必须要时时刻刻铭记这个关键步骤，否则得不偿失。例如：有一次接到某个需求要对群组网添加黑白名单开头，黑名单是针对订购了某类型业务的用户对象，限制他们的业务操作。因为未搞清楚这个黑白名单开头的作用，直接执行了测试，得出开头状态下的结果都是一样，被客户痛批一顿。后来弄清楚是针对特定用户群体这业务规则后，花了几个通宵才把结果修正过来。这案例说明了测试技术再利害，在没搞清楚业务的前提下是无法发挥出来。此外，熟悉业务、了解业务规则可以避免犯错，还有利于提高工作效率。例如：每次性能测试都需要准备大量测试数据，了解业务规则可以很容易地找到捷径获取数据，或得出获取数据的方式。有需要客户出面协调的时候，清晰的业务逻辑表达也有利于提高客户对你工作的认可，提高配合程度。
总之，测试是否得到客户的认可，并不是取决于技术能力的高低，而是取决于测试工作是否从业务原理、客户想法和需求出发。
2.2确定测试类型
在充分了解测试目的，完成需求分析后，需要选择一种合适的测试方式。从压力变化模型中可分为4种测试类型：
●性能测试。在a点与b点之间的系统性能，验证系统在资源可用范围内，是否能达到性能预期的目标。
●负载测试。b点的系统性能，验证在一定的压力下持续一段时间，直到系统的某项或多项指标达到极限。
●压力测试。b点到d点的系统性能，验证在超过安全负载的条件下，不断对系统进行加压，直到系统不能再接受请求。
●稳定性测试。a点到b点的系统性能，验证系统在一定压力下运行一段时间，以此检测系统是否稳定。
性能测试通常使用先单业务场景测试、再执行综合业务场景测试。
单业务场景主要用于测试该业务的基础性能指标，作为同类型业务的横向比较，或该业务的基线指标，做版本间的对比。单业务场景适用于性能测试、负载测试、压力测试、稳定性测试；
混合业务场景用于模拟生产线上运行的业务压力或用户使用场景，测试系统的整体性能是否满足实际性能需求。它是将经过一定规则筛选的性能测试点，按照合乎实际逻辑的虚拟用户请求、并发，组合而成的业务场景。混合业务场景通常包含两个或者两个以上的脚本组，执行时间较长。混合场景通常在稳定性测试、负载测试中使用。
2.3.1关键指标
●响应时间，是指操作该业务时的系统响应速度，直接影响用户体验。这个指标一般会有设计规范值，或用户体验的反馈值。
●业务处理速度，是指系统每秒能处理多少笔该类型的业务。由于每个地市的用户数量都不一样，所以数量级别有所区别，可通过以下公式计算：
●获取地市该业务的高峰月工单问题，假设80%的工单在4小时的时间内处理完：
（当月前台业务工单总数×80%）/30天/（4×60×60）
例如：某地市前台**的开户业务月工单总数2615537。
2615537×80%/30/（4×60×60）=4.84笔/秒
●并发数，广义的并发数是指系统同一时间内处理的业务数量，狭义是指系统同一时间内处理的某一业务数量。通常会取后者作为单业务场景的并发数作参考指标。
●系统资源消耗指标：CPU、内存、磁盘IO。在某些情况下，业务指标都让客户满意，但资源消耗指标却反映出可能有风险存在。例如：业务的处理速度、响应时间都达标的情况下，CPU的使用量达到90%以上。如果这种情况持续一段时间，或者用户数量有所增加的情况下，服务器有宕机、运算速度下降的风险。
客户的想法通常是覆盖面越广越好，但理想与现实总是有差距，往往受限于留给测试的窗口时间有多少。在接收测试任务之前必须先建立准入标准原则，例如：完成测试环境的配置确认，约定其它开发、测试工作使用测试资源的时间段，每次接收的用例数、最后接收时间点等。只有把好准入规范才有可能保证测试的高质量。
在时间和覆盖面之间衡量，除了要考虑完成质量，更重要是考虑风险和问题跟踪机制。例如：某个业务模块的测试结果不达标，但该业务必须按时上线。这就存在一个测试->调优->测试验证的循环，虽然测试脚本不需要重复修改，但需要考虑准备测试数据的工作量。修改次数、最后上线时间及测试结果都必须与客户确认，提供风险判断的数据支持，让客户对上线的风险有个清晰的认知，把风险产生的机率降到最低。
此外，如果有多个团队参与或支持的时间，需要明确划分好各团队的职责分工，以便出现紧急情况时各施其职，齐心协力化解问题，而不是乱作一团。
3方案确立
经过沟通、分析和设计阶段，得出的测试方案需要文档化知会各方，得到认可后才开展测试。
以下是方案的模板内容，供大家参考。
1、测试目标，说明测试的目的是什么，或需要产生怎样的效果；
1.1测试背景，说明业务原理，产生背景，让测试人员了解测试目的；
2、测试环境，描述测试环境架构，服务器，施压机配置情况，测试工具等；
3、测试场景，说明测试业务的侧重点；
3.1测试用例，描述用例操作步骤，入参、出参，业务规则。
3.2测试指标，描述具体指标及阀值，以判断测试是否通过；
4、团队分工，描述各个参与团队的工作范围、内容；
5、执行时间，规定环境的执行测试时间段、释放时间点等；
6、交付物，测试后的产出物（如：测试报告）。
