模板
教程
环境
性能
功能
管理
软件性能测试的重要性及策略
1.2.1 性能测试在软件测试的周期位置
首先，软件性能测试属于软件测试范畴，存在于软件测试的生命周期中。一个软件的生产过程通常遵循V型图，如图1-3所示。
图1-3 软件开发-测试V型图
在通常的软件生产周期中，先由用户提出用户需求或经系统分析核定以后提出系统需求，开发人员再经过需求分析提出软件需求规格说明，进行概要设计，提出概要设计说明，进行详细设计，提出详细设计说明，最后就是对每个模块进行编码。到测试阶段，测试按照开发过程逐阶段进行验证并分步实施，体现了从局部到整体、从低层到高层逐层验证系统的思想。对应软件开发过程，软件测试步骤分为代码审查、单元测试、集成测试、系统测试。
而性能测试就属于软件系统级测试，其最终目的是验证用户的性能需求是否达到，在这个目标下，性能测试还常常用来做：
(1)识别系统瓶颈和产生瓶颈的原因;
(2)最优化和调整平台的配置(包括硬件和软件)来达到最高的性能;
(3)判断一个新的模块是否对整个系统的性能有影响。
系统瓶颈：
瓶颈本来是指玻璃瓶中直径较小并影响流水速度的一段，用它来比喻软件系统中出现性能问题的节点是很形象的，比如一个典型的分布式系统架构如图1-4所示。
图1-4 软件系统压力流动图
如果把软件系统看做是交通系统，那么网络就是一条条大道，客户端、防火墙、负载均衡器、Web服务器、应用服务器(中间件)、数据库等各个系统节点就是交通要塞，客户的请求和数据就像在道路上行驶的车辆，如果在某处发生堵车，那么整个交通系统都会不畅。在这个时候，我们就要分析是哪里出了问题，是道路不够宽，还是某处立交桥设计不合理而引起堵塞等。找到问题的关键点，那么此关键点就是本系统的瓶颈。软件系统也是如此，我们做性能测试的大部分工作都是为了寻找这个瓶颈到底在何处。
需要注意的是，软件的性能瓶颈可能不止一处。
作为软件测试的一种，软件测试的规则同样适用于性能测试中：
(1)确定预期输出是测试必不可少的一部分
如果事先无法肯定预期的测试结果，往往会把看起来似是而非的东西当作正确结果。必须提倡用事先精确对应的输入和输出结果来详细检查所有的输出。对于性能测试来说，预期输出就是用户的性能需求，一份明确的性能需求是成功性能测试的先决条件。
(2)必须彻底检查每一个测试结果
事实上，在最终发现的错误，有相当一部分在前面的测试中已经暴露出来了，然而由于人们未能细心检查先前的测试结果而遗漏了。
一段程序中存在的错误概率与在这段程序中发现的错误数呈正比。
这是pareto原则应用于软件测试，也包括性能测试，即性能测试发现的错误中的80%很可能集中在20%的程序模块中。
(3)穷举测试是不可能的
在性能测试中不可能覆盖每一个功能部分，这也意味着有性能问题的模块可能被忽略掉，这样的话，我们在设计性能测试案例时，应该采取一些策略和技巧，使用尽可能少的性能测试用例，发现尽可能多的bug。这方面内容我们将在本书的第10章中介绍。
在具有软件测试共性的同时，性能测试也有自身的一些特点。
1.性能测试不是功能测试
性能测试不要求也无法做到覆盖软件所有的功能，通常我们只是对系统中某些功能或模块做性能测试。一般的，我们在选择性能测试案例时需要遵循以下的原则：
(1)基本且常用的
比如，一个E-mail系统，基本且常用的功能有注册、登录、收邮件、查询邮件，用户使用这些功能的频率较高，要做性能测试。而高级查询、过滤器、邮件列表等功能被使用的次数较少，就可以不做性能测试，或者进行性能测试的优先级低一些。
(2)对响应时间要求苛刻的
这样的要求经常出现在金融和电信等对实时性要求比较高的系统中。比如，从手机呼叫开始，经过基站、核心网，再到被叫手机响铃，整个系统的处理时间应该在用户能接受的范围内。另外，一个负责和手机通信的基站在发生故障或掉电后，要能很快地恢复工作状态。这些功能都对时间有着严格的要求，一定要做性能测试，当然实际运作时，电信系统上线时所做的性能测试不仅仅限于这些功能。
将这些功能细分就是性能测试中的事务(Transaction)。关于事务这个概念我们在后面的章节中将详细阐述。
2.性能测试属于系统级测试
从V型图可以看到，性能测试属于系统级测试。那么性能测试是基于单元测试、集成测试、功能测试等都已经完成的基础上，站在用户的角度去测试整个系统的。这包含两个含义：
第一，性能测试是“两头在外”，软件性能需求不仅直接来自用户，最终目的也是服务于用户。通过性能测试这个过程，从上面我们讲到用户的需求和性能测试指标的对应关系，就可以看出。
第二，性能测试开始的必要条件是软件系统已经处于一个比较稳定的状态，系统架构、主要代码、中间件等都不再有大的变化，否则会给性能测试带来很大的风险。
思考
基于以上事实，我们应该在软件流程什么阶段开始性能测试?结合自己的实际工作进行分析。
