应用软件效率测试策略设计剖析
效率测试基本概念
目前，在软件测试行业，效率测试习惯于称作性能测试，效率测试与性能测试的关系应该是包含与被包含的关系。性能测试仅仅衡量了与时间相关的各项指标，没有衡量与资源相关的各项指标。第三方效率测试目的是验证系统是否达到了开发文档或用户提出的各项性能指标，同时发现系统可能存在的瓶颈，起到优化系统的目的。
性能测试是对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。性能测试可以分为负载测试、强度测试和容量测试。
负载测试是一种性能测试。其目标是确定并确保系统在超出大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。例如响应时间、事务处理速率和其他与时间相关的方面。
强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象可能会表现出一些在正常条件下并不明显的缺陷，而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的大工作量。
容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的大负载或工作量。
除了有关时间的监测外，对系统资源的监控主要包括处理器、内存、网络、磁盘和系统等。
应用软件效率测试的执行策略
目前，为了适应各种不同系统的需求，根据性能测试的时间特性和资源特性，对应用软件制定了几个方面的效率测试策略。
1．基准测试
基准测试是指测试环境确认以后，对业务模型中涉及的每种业务做基准测试，目的是获取单用户执行时的各项性能和资源使用量指标，为多用户并发和混合场景的性能测试性能分析提供参考依据。
2．并发测试
并发测试是指并发不同数目的虚拟用户执行检查点操作，目的是对检查点进行压力加载测试。预测系统投入使用后在一定用户压力情况下的系统响应时间，根据此响应时间分析，确定系统存在的性能瓶颈，为系统的优化和调整提供依据。
3．递增测试
递增测试是指每隔一定时间段（如5秒、10秒）并发不同数目的虚拟用户执行检查点操作，对检查点进行递增用户压力加载测试，从而模拟系统真实的使用情景，使用户预知系统投入使用后的性能水平。
4．场景测试
根据历史数据统计结果以及系统用户的分布和使用频率，模拟不同用户执行不同操作，如10%的用户执行登录操作，50%的用户执行查询操作，40%的用户执行数据库更新操作，大限度地模拟系统的真实场景，使用户预知系统投入使用后的真实性能水平。从而对系统做出相应的优化及调整，避免实际情况中出现系统长时间不响应及崩溃的情况。
5．极限测试
极限测试是指对系统核心功能点及可能存在压力瓶颈的功能点进行性能极限测试，即该功能点所能承受的大用户并发数。通过极限测试，用户可预知系统投入使用后，能否满足实际的需求。
6．疲劳强度测试（稳定性测试）
该测试是指对系统核心功能点进行疲劳强度测试，即用系统稳定运行情况下能够支持的大并发用户数，持续执行一段业务时间（如48小时），记录交易平均响应时间，交易正确率，应用服务器和数据库服务器CPU利用率、内存使用情况等参数，考察应用服务器和数据库服务器是否出现宕机、内存泄漏等情况。该测试通常需要和场景测试进行结合，从而可以大限度地模拟真实环境下，系统长时间连续运行条件下，系统是否能够保持在稳定运行状态。
7．数据存储容量测试
使用工具持续执行各类任务，使数据库存储一定容量后，在不同的数据存储量情况下，重新执行各项操作，求得系统响应时间。比较不同数据存储容量情况下，执行不同任务操作的系统响应时间，使用户预知未来一段时间随着数据存储容量的变化，执行不同任务操作响应时间所发生的变化。
8．内存泄漏检测
使用工具模拟系统的测试点在单用户和多用户并发以及长时间运行时的使用情况，记录系统的内存分配和资源调用情况，从而判断系统的测试点在单用户和多用户并发时是否存在内存泄漏现象。
第三方软件测试机构中效率测试工作的开展
作为第三方的测试机构，与开发公司内部进行的效率测试存在一定的区别。首先是对系统所实现的功能不熟悉，其次对业务流程不熟悉，再次是对系统目前存在的性能瓶颈和可能存在性能瓶颈的功能点不熟悉。因此，在开始效率测试前要通过各种渠道来确定系统所需的测试点。另外测试工具的选用也至关重要，不是每种测试工具都能适应所有效率测试。
第三方效率测试一般的执行步骤为：
1．分析系统并确定测试点
通常情况下，用户会给出一个性能指标，但是在很多情况下，委托方是实际使用系统的用户，因此没有足够的能力提出性能指标。这需要尽可能快地了解系统，并制定出相应的测试指标和测试点。在制定测试点的同时要遵循几个原则，既要满足用户的需求并尽可能多地发现系统的瓶颈，又要充分考虑时间、人力和资金的限制。
低成本原则：性能测试只是全部测试工作的一部分，低成本的衡量标准主要是指“投入的测试成本能否使系统满足预先确定的性能测试目标”，只要经过反复的“测试??系统调优??测试”后，系统符合性能需求并有一定的扩展空间，可以认为性能测试工作是成功的。
策略为中心原则：在实际工作中会遇到各种突发性问题，导致时间的延误，因此需要为测试用例根据重要程度安排优先级。
适当剪裁原则：对于测试点比较多的系统，具有相同效果的测试点或者不重要的测试点可以进行适当剪裁。
2．选择适当的测试工具
QALoad、LoadRunner以及Performance Tester都是一种预测系统行为和性能的工业级标准性能测试负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。但是，不同的测试工具有不同的特点，并不是一个测试工具对所有系统都能够适用。
3．准备测试环境
配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。
一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。
4．建立虚拟用户脚本并进行适当的修改
通过测试工具录制系统交易的执行过程，例如登录测试，在录制完脚本前一定要将退出系统的步骤也录制进去，这样才能保证测试脚本能够顺利执行。另外，在录制完测试脚本后执行一次，以便确定脚本是否需要修改。如果脚本不能正确执行，要检查脚本中哪些地方存在动态ID。确定动态ID的位置后，要进行相应的替换。替换的方式通常有两种：如果系统变化的范围可预知并按照一定规则顺序变化，则可以直接采用数据池的技术直接替换；通过在脚本中插入变量，该变量可以获取从服务器传来的动态ID，并以此来替换。
另外，在进行并发测试时，登录系统的用户好采用不同的用户。
5．根据性能指标创建测试场景
设计测试场景的目的是为了更加真实地模拟系统实际运行的状况，从而更加准确地评估系统的性能指标。
例如登录点，系统要求每分钟支持600个用户并发登录，登录的响应时间在10秒之内。据此，可以设计递增测试的场景，从第一秒钟开始，用测试工具每秒钟登录10个用户，并保持连接，直到1分钟结束，从终端向系统一共发送600个用户的登录请求，系统在1分钟内建立了600个连接。同时，测试场景还要限制登录的响应时间小于10秒。这些策略对于LoadRunner和QALoad均能够实现。
除了递增测试外，还可以通过测试系统所能承受的大瞬时并发用户登录连接数来从另一个方面反映系统在瞬间所能承载的极限值。这一结果与递增测试结果共同反映系统的登录处理能力。
6．运行测试场景、同步监测应用性能
在运行测试场景前，要根据测试需求监测客户端、网络、web服务器、应用服务器、数据库和所有服务器硬件等各项指标。
在每执行完一个测试场景后，要粗略地查看一下性能和资源指标是否异常。
7．性能测试的结果分析和性能评价
结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。在性能测试中，需要注意的是，能够执行的性能测试方案并不一定是成功的，成败的关键在于其是否精确地对真实世界进行了模拟。
性能测试结果分析，是性能测试过程中困难，也是重要的步骤。它需要分析人员对测试结果中的各项数据有准确的认识，明确各指标之间的关系。如果各项数据指标间没有明显联系，在多数情况下需要综合考虑各种因素，才能得出终结论。
