前言
　　性能测试的工作的有效开展，离不开性能测试工作正式开展之前的精心准备工作。由于性能测试工作自身的特点，往往呈现出倒金字塔的结构。一但一个依赖条件准 备失当，由此引发的系列事项都有可能推倒重来。故而在性能测试的准备过程中，每一个步骤都得做好细致的考量后，稳扎稳打的逐步推进。而不是一旦接到性能测 试任务后，拿起工具风风火火的开始操弄起来，终耗费了大量时间做的确是无用功，或者效率低下，终不得不草草收场。来八一八性能测试开始前的一 系列准备工作，挂一漏万，欢迎同行斧正。
　　需求确认
　　性能测试准备的第一事项是发起者（可能是客户，可能是产品/项目经理）提供的性能测试需求。没有很好的理解需求开始做性能测试，像是无源之水。本来要 做压力测试的，结果没很好的理解需求，做成了疲劳测试这种事情，是前期没有和发起者做好沟通导致的，虽然费劲了气力，然而却不被买账。
　　前期针对性能测试的需求调研进行充分的沟通确认，是保证性能测试过程有效开展的重中之重，这点怎么强调都不过分。但也不是说非得死扣每一个细节，到底多大 的并发量才合适，需要持续压力多少时间什么的都确认的清清楚楚之后才能开展性能测试，有时候这个度也是一个经验积累判断的过程，究竟多详细才好也是灵活掌 握。
　　一些基本的背景信息确实得明确落实，是项目经理想知道现在的系统，在怎样的硬件条件限定下，究竟能承载多少用户的业务量？还是说客户需要知道业务密集发生 时，我的核心业务在现有的环境下是否能有效开展，或者是找出现在程序过慢的瓶颈问题所在。这种针对性能测试定基调的事项一定是越早确定越好。
　　另外强调一点，一般性能测试的发起方大多都不是专业的性能测试人员，在测试目的描述上面很可能不是如上文举例所说的那么明确，此时得发挥性能测试人员自 身的主动性，去沟通，调查了解，不要等着别人给你提供，别人的专职不在这儿，不可能对性能测试如测试人员一般上心，多想起来的时候问一句怎么样了？性能 测试新人，往往在目标，详细需求都还没确定下来开始准备测试，后得到的结果基本都不理想的主要原因估计在这儿。
　　测试方案
　　接下来的工作则是要制定详细的测试方案。设定性能测试场景，是单场景执行还是混合场景执行？单场景要测试哪些功能？混合场景有哪些功能需要涵盖进来，各占多少比例？
　　如果是上线前的性能的测试，混合测试中各种功能的占比也是越接近实际使用过程中的比例越好。如果占比失调，测试的效果要大打折扣。由于还没有相关的统计信息，一般都采用80/20原则。
　　要是在已经上线的项目上开展性能测试，好还是先调查清楚各测试项的实际占比来确定，简单的统计方式是把系统业务活跃时间段内的日志拿到进行汇总统计，拿熟悉的脚本语言写个脚本，分分钟统计出来了。
　　还有一个注意事项是加压策略，根据测试目的不同，是逐步加压到一定的虚拟用户数稳定执行，还是一直稳定加压，直至系统拐点，根据测试目标的不同，加压的策略也是需要仔细确定。这个将来有机会再展开讲，一两句话也说不清楚。
　　硬件
　　硬件好是越接近真实环境越好，好是真实的生产环境上测试。
　　但现实往往是测试环境和实际环境有较大差异，这种情况下也并不说性能测试没办法开展了。此时需要基于目标环境，合理配置测试硬件环境。性能测试结果则是在测试机器性能的基础之上进行合理的估算，计算出实际环境的业务承载能力。
　　除了常见的数据库服务器，应用服务器，测试客户端机器性能的考量外，网络环境、带宽、网络延迟也是在性能测试过程中需要充分考量的。
　　如果测试环境有虚拟化主机，关于硬件资源的设置也是需要仔细设定，避免因为设定不当导致主机之间的性能互相之间受到影响。
　　软件
　　相应的软件平台一类的东西也是接下来需要确定下来的东西。比如操作系统的类型和版本，数据库的类型和版本。如果测试目标中已经确定是哪种环境下，则尽量按 照既定目标中的来配置，避免因为不一致而导致测试结果的偏差。待测软件的部署工作也是性能测试人员需要熟知的一个事项。没准因为版本不太稳定，换好几 个版本也说不定。这块多说一句，有条件用脚本部署的尽量用脚本。虽然编写调试脚本需要耗费一定的时间。但好处是避免人工操作引入错误，比如测试半天了才 发现数据库没还原什么的问题。用脚本的话，一个双击，一条命令搞定了。还有是做好待测软件的版本记录。哪次测试是用的哪个版本的程序要保留好记录，避 免因为版本反复更迭，导致结果记录混乱。后，用来做性能测试的主机上无关程序均应停止。避免因为运行了其他的程序对性能测试过程造成影响，特别是像杀毒 软件防火墙之类会对网络传输进行监听的软件应尽量关闭。
　　性能测试工具
　　性能工具的选型，往往是没的选，要么是用工业标准LoadRunner一类的商业软件，要么因为授权问题用JMeter一类的开源软件。
　　商业软件的优势是资源充足，需要什么材料，打开搜索引擎基本上都能找到相关的信息，实在找不到还可以联系原厂做支持。劣势是费用高昂，不多虚拟用户的授权 需要大笔的费用开支，不是一般的企业所能承担的。用盗版的话，性能测试报告为了规避法律风险，也要把工具的一些标志性的信息去掉，内部看看的话也都没问 题，一旦要对外发布，存在一定的商务风险。
　　退而求其次，改用开源的软件之后，费用倒是不成问题，但相关的资源搜索起来比较费劲。近这几年还好一点，常用的开源性能测试工具有了一定的用户基础， 相关的问题也能通过搜索询问解决一部分。但如果是社群中没有人遇到过的问题，或是无论怎么搜都没个的结果问题，好死不死这问题卡住性能测试的关键节点。能 绕过去的问题还好，绕不过去让人欲哭无泪了。成了出了问题不知道该找谁。
　　近看到一种性能测试工具的商业模式，像HyperPacer一类的：软件免费提供下载，升级。但性能测试过程中遇到的问题的协助解决，或做定制化开发则 需要一定的费用。说新其实说新也不算太新，Red Hat一类的Linux发行版早是这么玩儿了。是不知道能折腾出多大的市场了。尝试一下倒也不错，到底有一个团队做支援，还是会心安一些。
　　测试数据
　　如果有一定数量的历史数据，性能测试的数据准备还略微好做一些。常用的手段是写SQL数据翻倍之类的方式使数据达到测试所需的量级，如果对表结构不是太熟悉的测试人员，还需要联系相关的开发人员协助此项工作。
　　要是还没有上线的项目，没有历史数据，此时需要生造数据。往往会出现一些数据分布不合理一类的情况，这里需要提前联系相关的业务人员对数据的量级做一个预估，大程度的减少数据偏差。
　　若是数据表之间还存在关联引用的话，无论以上的哪种方式造数，都要尽量保持数据关联的准确性，例如主子表之间的关联，一条主表数据平均关联几条子表数据一类的设定也是要提前做好调研的事项。
　　脚本录制开发
　　以上全部准备停当，得开始用工具录制调试脚本了。因为cookies，session id一类的东西，需要对录制下来的脚本进行参数化处理，多个不重名的用户，选项之类的也需要参数化。这块得对性能测试工具和相关的背景知识相当了解，否则 会耗费大量的时间在脚本调试方面。所以在性能开始之前，要对性能测试软件的相关设置和待测软件系统都有一定程度的了解后，再开始着手测试，所谓磨刀不误 砍柴工。待到脚本调试完毕，场景都逐一按照方案正确设置保存后。正式的性能测试总算能有条不紊的开始了。