聊一下从需求到性能测试全过程 测试需求规格说明

摘要

在性能测试项目中将大部分时间花费在获取需求、验证需求以及实现需求上，只有这样才能为性能测试打下坚实的基础。其余的时间则用于录制事务脚本、执行性能测试和分析测试结果。

诸如构建和调试一个合适的测试环境此类的活动，过于复杂，而且还要视情况而定，所以很难给出一个有意义的指导，但是，对于某些关键任务，我可以在可能的时间尺度上给予您以下指导。·录制性能测试脚本：每一个事务需要半天的时间。事实上，有些事务可能会耗时较多，有些则相对少些。但从本人的性能测试经验来看，半天的时间是较为合理的。

创建验证测试阶段或者测试场景：一般需要一到两天。这可是个重活，因为您要把已经确定的每一个性能测试的结构和内容作为需求分析的一部分。更多的时间会花在测试预演上，以保证测试的准确性。

执行性能测试：需要至少五天时间。在这个阶段，为了验证某些问题要重新测试多少次还是一个未知数。另外，在这之间重建数据库也会耗费相当多的时间。但是如果你能准确地定位需求，并确保软件不出现一些明显的错误，在五天的时间里你还是能够做相当多的性能测试的。

数据收集（以及软件卸载）：需要一天的时间。如果是内部测试，那么卸载不是必需的。如果您是提供测试服务的，那就需要执行卸载测试软件了。给自己一天的时间来卸载并收集测试结果和（关键性能指标）KPI监控数据。

第一步：需求分析

在任何性能测试中，第一步应该是准备好以下的任务。

在弄清楚其他要求之前，最起码您要同意并认可以下需求。

如果在性能测试执行过程中发现了软件问题，您要确保计划中为额外测试环节和缺陷解决方案预备了意外事件处理机制。这种预防机制经常被人忽视。

如果完成了这些活动，那么您就可以继续其他步骤了。所有提到的事情不一定都会满足您具体的测试需求，但是事情的顺序是很重要的。

为性能测试设定一个截止日期，包括已经计划好的时间安排。

决定用外部资源还是用内部资源来执行测试。这更大程度上依赖于时间进度和自身是否拥有相应的技能。

要有一项测试环境设计方案。记着，测试环境应该尽量接近你所能取得的真实环境，创建测试环境所耗费的时间可能会比预计的要长。

确保在每一个测试周期中，都会把代码冻结并应用于测试环境。

确保测试环境不会受到其他用户活动的影响。当执行性能测试的时候保障其他用户不能使用测试环境。

第二步：搭建测试环境

您应该早已为您的测试环境准备好了硬件、软件和网络设备。记得前面说过，您应该努力把测试环境搭建的尽量与真实环境相似。但这是不可能的，那么您搭建的环境至少要能够反映真实环境中的服务器级别部署，您的目标数据库在内容和规模上要与实际的环境中的数据库规模相符。这个活动要尽早地进行，因为它耗费的时间经常比预期的要长得多。

搭建一个测试环境需要以下步骤：

为搜索相关设备和配置，为搭建环境准备足够的时间。

把所有配置模型都考虑进去。您可能需要在局域网和广域网环境上测试软件的不同配置，所以您要确保这两种环境都能够在您的测试环境中实现。

把外部系统的链接都考虑进去。任何时候都不要忽视外部链接，

因为它们往往是产生性能瓶颈的主要所在。

为目前的测试规模准备足够的负载生成能力。考虑一下要进行负载生成器的位置。如果这些位置对被测应用程序来说并不都是本地的，那么您必须确保负载生成器能够被远程控制或者确保在远程工作站能够配置本地人员，进行操作。

确保被应用程序在测试环境中进行正确配置。我曾多次在性能测试项目中遇到过这方面的问题，本来应该正确准备好了的被测应用程序，却发现配置错了。

为被测应用程序和支持应用程序的软件准备足够的软件许可协议（比如：Citrix或者SAP许可）。如果您忽视这方面，等出现问题的时候您将很难处理这些问题。

配置调试性能测试工具。确保它们正确安装，并依据预先设计的性能测试方案进行了配置。

配置（关键业务指标）KPI监控工具。这可能是你性能测试解决方案中性能测试工具的一部分，或者是一个完全独立的工具包。不论是哪种情况，都要确保他被正确配置，并能返回性能测试过程中需要监控的数据。

第三步：录制事物脚本

在进行事务脚本录制之前，对于选定的事务必须完成以下任务：

验证事务的运行时数据需求。POC活动可以提供这些信息的部分内容，虽然这只是针对一小部分事务。在很多情况下，只有当您开始录制脚本时，您才能确定其他事务的运行时数据需求。

确定并运用事务输入数据需求。这些应该被当作项目前需求分析的一部分，并对其进行验证。

决定如何为事务需要特别监控的部分添加检查点（Checkpoint），以评估特定事务的响应时间。这很重要，因为它会为您提供事务最可能出现错误的地方供您分析。在识别项目需求分析中的关键事务后，你应该着手解决这些问题。

识别并应用所录制的脚本之间的不同，这些是事务成功回放所必需的。如果您已经执行了一个POC，那么您应该留意这些改变的意义，以及执行它们所用的时间。

在决定把某个事务纳入到整个性能测试中之前，您要确保事务无论从单用户或者多用户的角度都能回放成功。确保您能通过检查数据库的更新是否成功或者检查回放日志文件的正确性，来验证整个回放过程。

第四步：创建性能测试场景

对于您所创建的每一个性能测试，您要考虑到以下几点。

您的性能测试属于哪种类型的性能测试：基准测试、负载测试、渗透测试还是压力测试？对于标准场景，首先要作为一个单用户为每一个事务独立地进行基准测试，直到这个事务当前目标最大化，或者吞吐量达到最大值。如果在这个阶段出现了错误，那么您可能需要运行每一个单独的测试来定位并解决这些问题。其次集合所有的事务，对其进行负载测试，直到出现错误，并对其作更进一步的独立的测试。然后您可能想为最后测试环节做渗透和压力测试，在上述这些测试类型完成之后在最后可能会做一些与性能无关的测试，这些测试将会注重于优化负载平衡配置或者对不同的灾难恢复机制进行验证。

决定如何在测试中体现每一个事务的思考时间和步进时间（Pacing），正常情况下要在所有测试类型（压力测试除外）里设置思考时间和步进时间（Pacing），否则您所获得的事务吞吐量的值将不能反映用户真实的情况。

对于每一个事务，您要决定部署多少负载生成器，每个负载生成器上部署多少虚拟用户。正如上文提到的，如果您已经大规模地部署了负载生成器，那么您要保证当出现问题时，会有本地专家（负载生成器本地）来解决他们。

为每一个负载生成器部署“爆炸式（Big Bang）”，“渐进（ramp up）”，“渐进（ramp-up）”/“渐退（ramp-down）”等负载生成类型。根据您的测试目标，负载类型可能会包含用来表现静止负载的“爆炸式（Big Bang）”类型与用于测试扩展性的一个或多个“渐进（ramp up）”/“渐退（ramp-down）”的变量类型。图表3-2展示了一个采用这种方法的性能测试计划。底部暗色的长方形代表“爆炸式（Big Bang）”部署创建的静态负载，在此之上的各种其他的负载是部署的“渐进（ramp up）”类型。

测试能否在指定的时间内一直执行，还是会因为测试数据的不足而中断，事务可以多次重复，还是需要用户的干预？如果你的测试是由数据驱动的，那么要保证你已经创建了足够的数据用于测试。

您是否需要使用IP地址欺骗来准确实现程序负载均衡的需求？如果需要的话，那么用户需要提供一份合法的IP清单。

第五步：执行性能测试

运行并监控测试。您需要对每一个性能测试进行预演，以保证在最后测试的过程中软件不会出现问题，或者确保测试配置不会出问题。本阶段应该是整个性能测试项目中最简单的一部分。您已经花费了很大的功夫来准备测试环境，录制事务脚本，满足数据需求以及创建性能测试实例。在理想的情况下，执行性能测试仅仅是来验证软件的性能目标。它不应该变成一个确定并修复Bug的过程。

有一点不明确的是在达到性能测试目标之前您需要运行多少次测试场景。我希望我能回答这个问题，但是这个问题正如人生中的许多事情一样。如果您能严格遵循测试清单上的要求，我相信您能成功实现性能测试目标。

正式测试之前您需要预演一下，以确定能为当前目标生成足够的负载，除非当前测试目标不需要很大负载，否则您都要检查负载生成器的上限。如果您连最低限度的负载能力都达不到，那么这次测试很容易就失败了。一个预演还能检查您是否能链接到程序，确定您没有忘记性能测试中最基本的东西，比如，忘记把脚本需要的外部数据加入到性能测试中。·执行基准测试为性能测试建立一个响应时间的理想值。这通常是每个事务单用户运行一定时间或者多次重复一个事务获得的响应时间。

在执行负载测试时，一般都要在完成一次测试后，在执行下一个之前重置数据库。一旦建立了性能基线，下一步就是要执行负载测试了：所有事务要分配给多个目标虚拟用户。

在负载测试中发现的问题需要执行单独的测试进行仔细分析，然后将结果提交给开发人员和软件厂商。这就是为什么说在测试计划中安排意外事件处理时间是非常重要的，因为即使是很小的问题都会对整个项目执行时间造成很大影响。

通过渗透测试来发现任何内存泄露或者发现与高数据交互事务执行相关的问题。我强烈建议您尽可能把渗透测试包含到性能测试中，虽然这并不总是可行的。

从系统容量的角度来说，执行压力测试是很重要的。您应该很清楚要在应用程序环境中设置多少备用容量，为以后测试中增长的事务容量和最终系统用户提供数据的参考，您还可以利用压力测试为处于特定应用级别的服务器设定水平扩展性限制。

执行其他与性能无关的测试。例如，试验一下配置不同的负载平衡性。

第六步：分析测试结果、撰写测试报告和环境恢复

数据收集（如果是为客户提供服务的话，那么我们在完成测试后还需要卸载软件）。保证您收集并备份了所有在性能测试项目中生成的数据。往往当人们准备测试报告的时候才会发现它们其实忽略了许多重要的软件度量。

通过对比根据项目需求设定的性能目标和测试结果，来确定整个性能测试是否成功。项目开始之前在性能目标和交付上达成一致，才不会在提交测试结果以及软件是否符合应用的问题上造成麻烦。

用您喜欢的报告模板将测试结果整理成文档。报告的格式可以是您喜欢的风格，或者是根据公司或者客户的要求进行设计，但无论是哪种格式，都要包含满足每一个性能测试指标的部分。换句话说，性能测试项目的产出应该清楚地包含于测试前的需求分析中。然后测试结果报告会根据协定的性能目标调整测试流程和测试结果。这就使得向客户提交报告和解释测试结果变得相当简单了。

将最终结果作为基线数据并用于跟踪最终用户体验（EUE）。如果您手头上有一个EUE跟踪解决方案的话，那么性能测试项目的结果会为新的或者早已配置好的应用程序建立EUE SLA。