软件性能测试基本概.docVIP

第1章 软件性能测试基本概念 1.1 什么是软件性能 当我们提到软件性能测试的时候，有一点是很明确的：测试关注的重点是“性能”。那么，本书要解决的第一个问题就是：究竟什么是“软件性能”？ 一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量。 性能的及时性用响应时间或者吞吐量来衡量。响应时间是对请求作出响应所需要的时间。 对于单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到端的时间。比如，“用户单击OK按钮后2秒内收到结果”就是一个对用户任务响应时间的描述，具体到这个用户任务中，可能有多个具体的事务需要完成，每个事务都有其单独的响应时间。 对交互式的应用（例如典型的Web应用）来说，我们一般以用户感受到的响应时间来描述系统的性能，而对非交互式应用（嵌入式系统或是银行等的业务处理系统）而言，响应时间是指系统对事件产生响应所需要的时间。 通常，对软件性能的关注是多个层面的：用户关注软件性能，管理员关注软件性能，产品的开发人员也关注软件性能，那么这些不同的关注者所关注的“性能”的具体内容是不是都完全相同呢？如果不同，这些不同又在哪里？最后，作为软件性能测试工程师，不同层面的软件性能都需要关注，在关注全部这些层面的性能体现的时候，又应该注意哪些内容呢？下面我们从3个不同层面来对软件性能进行阐述。 1.1.1 用户视角的软件性能 从用户的角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮、发出一条指令或是在Web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。图1.1以一个Web系统为例，说明了用户的这种印象。 图1.1 Web系统的响应 必须要说明的是，用户所体会到的“响应时间”既有客观的成分，也有主观的成分。例如，用户执行了某个操作，该操作返回大量数据，从客观的角度来说，事务的结束应该是系统返回所有的数据，响应时间应该是从用户操作开始到所有数据返回完成的整个耗时；但从用户的主观感知来说，如果采用一种优化的数据呈现策略，当少部分数据返回之后就立刻将数据呈现在用户面前，则用户感受到的响应时间就会远远小于实际的事务响应时间（顺便说一下，这种技巧是在C/S结构的管理系统中开发人员常用的一种技巧）。 关于响应时间的进一步讨论请见1.2.1节对“响应时间”的解释。 1.1.2 管理员视角的软件性能 从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，这一点和用户视角是一样的。但管理员是一种特殊的用户，和一般用户相比，除了会关注一般用户的体验之外，他还会关心和系统状态相关的信息。例如，管理员已经知道，在并发用户数为100时，A业务的响应时间为8秒，那么此时的系统状态如何呢？服务器的CPU使用是不是已经达到了最大值？是否还有可用的内存？应用服务器的状态如何？我们设置的JVM可用内存是否足够？数据库的状况如何？是否还需要进行一些调整？这些问题普通的用户并不关心，因为这不在他们的体验范围之内；但对管理员来说，要保证系统的稳定运行和持续的良好性能，就必须关心这些问题。 另一方面，管理员还会想要知道系统具有多大的可扩展性，处理并发的能力如何；而且，管理员还会希望知道系统可能的最大容量是什么，系统可能的性能瓶颈在哪里，通过更换哪些设备或是进行哪些扩展能够提高系统性能，了解这些情况，管理员才能根据系统的用户状况制定管理措施，在系统出现计划之外的用户增长等紧急情况的时候能够立即制定相应措施，进行迅速的处理；此外，管理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不间断地提供业务服务等。 因此，从管理员的视角来看，软件性能绝对不仅仅是应用的响应时间这么一个简单的问题。 表1-1给出了管理员关注的部分性能相关问题的列表。 表1-1 管理员关注的部分性能相关问题 管理员关心的问题 软件性能描述 服务器的资源使用状况合理吗 资源利用率 应用服务器和数据库的资源使用状况合理吗 资源利用率 系统是否能够实现扩展 系统可扩展性 系统最多能支持多少用户的访问？系统最大的业务处理量是多少 系统容量 系统性能可能的瓶颈在哪里 系统可扩展性 更换哪些设备能够提高系统性能 系统可扩展性 系统能否支持7×24小时的业务访问 系统稳定性 1.1.3 开发视角的软件性能 从开发人员的角度来说，对软件性能的关注就更加深入了。开发人员会关心主要的用户感受——响应时间，因为这毕竟是用户的直接体验；另外，开发人员也会关心系统的扩展性等管理员关心的内容，因为这些也是产品需要面向的用户（特殊的用户）。但对开发人员来说，其最想知