MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'; mso-bidi-font-family: 宋体">摘要：本文从性能测试的过程着手，将性能测试过程划分为性能测试准备和组织、性能测试设计、性能测试结果分析三个阶段，并介绍了每个阶段的主要工作内容和方法。

       关键字：软件性能测试 性能测试过程 性能测试设计

性能测试的重要性是随着网络应用的发展而发展的，在单机应用占据主导地位的时代，软件性能基本上都可以通过提升硬件配置来改善，而且由于硬件设备的快速更新，软件性能并没有成为制约软件成功的主要因素。而在网络应用高度发展和吸引用户眼球越来越难的今天，系统的性能受到应用开发商和运营商的高度重视；但与此同时，由于网络环境、数据库环境、应用服务器环境、系统平台和技术等的复杂性和多样性，软件性能又非常难于控制，例如，对一个部署在Internet环境下的Portal来说，由于Internet复杂的网络环境、无法控制的访问者等因素，如果没有好的性能控制手段，要想让其达到好的性能简直是天方夜谈。    当然，改善系统性能不是单单依靠性能测试就能完成的，需要从需求、设计、代码到测试的整个过程中贯穿性能工程的实践，对产品进行全过程的性能控制。不过，到目前为止，性能测试仍然是控制性能的非常有效的手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

       本文拟结合本人的经验和体会，从性能测试的过程入手，讨论性能测试的过程。

1.       性能测试准备和组织

性能测试的准备和组织是性能测试过程的第一步，在这个阶段，我们需要明确性能测试的目标和性能测试需求，并组织起合适的人员，制订性能测试计划。

一般来说，性能测试的应用领域分为能力验证、能力规划、性能调优和缺陷修复四个方面，其中能力验证表明测试的目的是验证系统能力是否达到预期的性能标准；能力规划意味着测试的目的是考察系统的可扩展性；性能调优则表示性能测试的目的是通过性能测试手段，找到系统的性能瓶颈，为性能调优提供依据；缺陷修复应用领域是指通过性能测试手段，找出系统中存在的并发等方面的缺陷。

明确性能测试的目标也就是要把性能测试的目的归到相应的应用领域，而确定性能测试需求则是要更详细地确定性能测试的基准。对产品的性能测试需求的来源是软件需求、设计文档或是用户备忘录等设计和需求相关的文档。当然，并非所有的性能测试需求都在这些文档中以明确的方式标识出来了，此时就需要根据不十分明确的文档描述进行进一步的细化。我们的经验是在文档评审时高度关注所有与性能相关的描述，例如“要求操作响应时间小于……”、“要求……能够快速……”、“要求……能够支持……用户访问”、“要求……能快速稳定运行”等，然后依据表1进行进一步的细化，细化后的测试需求就可以作为测试的依据。

性能测试涉及的设备、环境、技术、工具较多，性能测试人员的组织也必须兼顾这些方面，根据我们的经验，一个性能测试组最好包括系统工程师（负责测试环境搭建、服务器和应用服务器的配置）、网络工程师（负责网络环境的维护和验证）、性能分析工程师（负责测试计划的拟定，负责对性能测试结果进行分析，给出性能测试报告）、自动化工程师（负责测试脚本的编写和测试工具实施），数据库工程师（负责对数据库层进行性能问题定位）；在条件允许的情况下，还可以包括开发工程师和客户代表，辅助对性能测试结果进行分析和确认。

性能测试计划是用来指导性能测试过程的主要文档，在测试计划中除了要写明本次测试的测试目标、测试需求外，还需要测试计划中给出明确的测试退出条件和测试的时间和资源计划。

2.       性能测试设计

与功能测试一样，测试设计也是性能测试过程中的主要内容。性能测试的测试设计一般基于测试场景（Test Scenario）进行，一个测试场景就是一个用户的实际使用系统的剖面。例如，对一个用于开发人员工作的OA系统，该系统在每天9:00 - 9:30期间，用户主要是在执行查看邮件和查看BUG操作，在上午的其他时间主要是修改BUG状态和处理邮件，则从对该系统的简单使用分析中，我们至少可以得到两个不同的应用场景：一个是“用户查看邮件和查看BUG”场景，另一个是“用户发送邮件、接收邮件、修改BUG状态”场景。

在性能测试过程中，明确每个场景的参与者人数、比例和具体行为是非常重要的，这些都是构成性能测试脚本的基础。我们的经验是可以从应用服务器如IIS的日志中分析用户行为，例如，对我们作为示例的这个OA系统，我们从日志中分析出在上午9:00 – 9:30时段内有200查看邮件页面的page view，且查看时间基本集中在前10分钟；而在9:00 – 9:30时间段内对BUG显示页面的查看量是300个page view，对页面的访问基本平均分配在整个时间段，则我们可以建立两个脚本，前一个脚本模拟查看邮件操作（脚本1），后一个脚本模拟查看BUG操作（脚本2），考虑运行15分钟的测试场景，则只需在前5分钟运行脚本1，在整个过程中运行脚本2，通过调整think time使得page view达到实际的数值即可。

当然，测试场景的提取需要测试设计人员对用户的行为和业务有较为深入的了解，并不是每个不同的用户应用剖面都需要作为测试场景来设计，在多数情况下，我们可以通过对测试场景出现的几率、重要性、风险等进行分析，从而最终确定需要设计的测试场景。

明确了性能测试包括的场景之后，根据性能测试应用领域的不同，可以采用不同的性能测试方法来达到性能测试的目标。例如，对性能调优和能力规划应用领域，可以通过配置测试的方法，应用相同的测试场景，针对不同配置的系统进行测试，通过一次性修改少数配置参数或是硬件配置的方法，找到对性能影响最大的因素，从而对其进行优化和规划。

最后还需要提醒的是，性能测试设计还应该包括测试环境、测试数据等的设计，因为影响系统性能的因素很多，保持测试过程中环境和数据的可控性是非常重要的。

3.       性能测试结果分析

性能测试结果分析是性能测试过程中最困难，然而也是最重要的步骤。性能测试结果分析需要分析人员对测试结果中的各项数据有准确的认识，明确各指标之间的关系。性能测试结果的各项数据指标并没有显而易见的联系，在多数情况下都需要综合考虑各种因素，才能得出最终的结论。

       根据我们的经验，在性能测试过程中最容易发生的问题主要是数据库访问层问题（未优化的SQL语句和存储过程）、应用服务器配置问题（不合理的配置）以及网络问题（状况差的网络），因此我们建议的一般原则是“从简至繁”的原则，即首先排除网络问题，其次对应用服务器配置进行分析，确认不是由于应用服务器本身的配置引起的性能问题，然后在数据库访问层进行性能分析，重点是索引、数据库Cache、死锁等问题的分析，在确认所有这些因素都不是性能瓶颈的情况下，才对代码进行分析和检查，找出导致性能问题的因素。

文章来源于领测软件测试网 https://www.ltesting.net/