MILY: 宋体; mso-ascii-theme-font: minor-fareast; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-fareast">软件测试中性能测试过程概述

每个系统都肯定会对性能有要求，这些要求大致被分为3类：

1.   可接受的响应时间

2.   吞吐量和并发用户

3.   未来对性能增长要求

首先，我们先看一下性能测试的周期是怎样的：

一阶段、规划

规划这部分最核心的，我觉得是对用户行为的分析和剖析。因为这是为第二个环节建立可依据的标准。对用户行为的分析和剖析，大致分为以下3类。

1.1、吞吐量和并发用户数设计目标

    获取这些数据的途径可以是：网站服务器的日志文件、系统监视数据、数据库活动监视数据、市场调研等等。调研出来的数据，可以按照功能点来进行划分，以便清楚的知道各个功能点的使用比率、使用次数/小时，由此来确定并发数和吞吐量的分布。

2.2、性能增长分析

    这部分的数据可以是通过市场调研来预测的，也可以是通过之前的经验来下的定论，也可以通过系统运行一段时间以来，用户的增长速度来确定。通过对增长趋势的分析，同时考虑到特殊情况（如：特定节日，特定事件）对系统的冲击，可以适当增加用户的增长趋势。至于增长趋势持续的时间，可以按照实际情况而定，由此来定出系统最终的吞吐量和并发用户数。

2.3、用户活动剖析

    分析用户活动，我常用的是以下的几种方法：

1)   通过在程序中写代码，把登录用户的相关信息（登录名、IP地址、访问页面、功能操作、停留时间。。。等等）记录在数据库中

2)   通过IIS日志来记录用户活动记录，然后再对IIS日志进行分析。这个过程当然少不了必备的工具，当前市面上的工具很多。诸如AWStats、Analog、Summary、Webalizer、WebTrends等。这些工具虽然都是现成的，但是有的配置复杂，有的功能不够强大和灵活。所以更多的是把IIS日志导入到SQL SERVER中，自行写查询语句进行分析，这样灵活简单。但是如果日志文件过大，或者数量众多的时候，这个方法稍微有点麻烦，所以我推荐使用另外一个工具Log Parser。对于这个工具的使用说明，我会在后面进行介绍。

二阶段、创建脚本、运行脚本

这个阶段，根据第一阶段的分析结果，对需要进行性能测试的场景录制脚本，再根据环境分析结果对脚本进行微调（例如：加入虚拟IP、创建多用户登录等，各类情况根据实际决定，这里不多说）。脚本调试好，在运行之前，打开各性能指标的计数器，SQL Server开启跟踪，然后运行脚本，并实时监控，以及手工N+1测试。

关于计数器，我常用的如下，不含特殊情况下需要用到的一些指标：

三阶段、分析优化

    运行完脚本，关闭跟踪。接下来就是分析日志，分析跟踪结果了。这部分很复杂，涉及很多方面的知识。以B/S结构为例，整个网络的体系架构大致如下：

参照上图，我大致把整个过程的时间简单的分为以下的几部分：

客户端与服务器间的网络传输时间：T1+T7

服务器执行时间：T2+T4+T6

服务器间网络传输时间：T3+T5

客户端运行呈现时间：T8

当然并不是每次访问都是由这些时间相加，例如WEB和DB在同一台服务器，或者此次访问根本就没有对数据库进行访问。

对每个部分的时间都需要用不同的方法进行确认，初步分析出最耗时的环节进行优化。优化所需的技能和知识就多了，例如：你发现在内存不断减少，怀疑有内存泄漏，那么怎么判断是什么导致内存泄漏？某次访问的时候耗时很久，那么到底是哪部分耗时最久？当前系统所采用的技术是否是制约性能瓶颈？硬件是否是瓶颈，哪部分造成瓶颈？

优化需要大量的技能，是个需要不断的、长期的积累的过程。

路，还长的很啊。