【毕业学位论文】基于多组件的Web服务系统性能模型研究

目 录 I 目 录 1 绪论 . 1 究背景及意义 . 1 内外研究现状 . 3 文的研究重点 . 4 文结构安排 . 4 2 基于多组件的 务系统 . 6 务系统的三层结构 . 6 种典型的 务系统模型 . 7 层 模型 . 7 层 客 户 /服 务 器 应 用模型 . 7 层 客 户 服 务 器 应 用模型 . 8 件技术 . 8 件 简 介 . 8 件 简 介 . 9 介 . 10 种类 . 11 术 的 优 点 . 11 3 务系统性能测试 . 13 件测试 . 13 能测试 . 14 务 系 统请 求 处 理 过 程 . 15 能 评测 的重要指 标 . 15 能 测试 的 步骤 . 18 能测试工具 . 18 能 测试 工具介 绍 . 18 要介 绍 . 20 局限性 . 22 4 务系统性能模型 . 23 件资源消耗研究 . 24 件的 资 源需求 . 25 程 调 用的 开销 . 27 目 录 组 件 间 通信延 迟开销 . 28 他相 关问题 . 30 能模型介绍 . 31 吐量 预测 . 31 应时间 预测 . 31 5 测试软件平台部署 . 33 目简介 . 33 署步骤 . 33 6 性能模型验证 . 37 试环境搭建 . 37 拟用户行为 . 37 能测试步骤 . 38 试结果及分析 . 39 致 谢 . 44 参考文献 . 45 附 录 . 49 1 绪论 1 1 绪论 究背景及意义 随着现在互联网的发展，越来越多的人生活和工作越来越依靠网上的 务系统。因此，各个领域的 务系统如雨后春笋般的出现，影响着我们的生活和工作。随着 不断发展，人们在注意 务系统可用性的同时，由于功能需求也使其变的越来越复杂，同时提 高服务质量和可靠性方面没有得到足够的重视，从而导致了有些 务系统响应时间缓慢，甚至是出现停止运行这样的严重错误。可想而知，在这样的情况下，用户自然会放弃使用而转投他家。于是，在当前网站的复杂性逐渐增加的情况下，如何衡量和评估 务系统的性能就成为一个重要的需求。 软件测试是用来保证软件可用 性和质量的必要技术手段。随着计算机的发展，在人们的生活和工作的方方面面都用到了计算机软件，例如超市的收银系统，学校的管理系统等等。随之而来的是，人们对于软件的可靠性，可用性都提出了越来越高的要求，正是由于软件系统 的稳定性不尽如人意，所以必须要采用规范的软件测试流程来保证软件的质量。不稳定的软件系统很有可能导致用户放弃使用，从而直接影响企业或者部门的经济收益，软件测试可以在一定程度上的发现错误，帮助提高系统的可用性和可靠性。所以，在一个软件系统上线之前经过严格的软件测试已经成为 的共识。性能评测是通过测试工具模拟各种负载条件来对软件系统的各项性能指标进行测试。性能评测包含了负载测试和压力测试，两者一般配合进行。负载测试主要用来评测在各种工作负载下系统的性能，目的是评测当输入负载逐渐增加时，系统各项性能指标如何变化 。压力测试主要是为了得到系统能提供的极限负载数据，一般通过确定一个系统的瓶颈或者不能接收的性能点得到。 性能评测的必要性是显而易见的，大多数的 务系统使用者也都了解性能评测的重要性，但是如果性能评测需要花费大量的时间和金钱 时，评测往往会被精简甚至略过。资料 1表明一般性能评测需要的硬件和软件投资从数千美元到数十万美元不等，不仅需要大量资金的投入，更需要具备专业知识的测试人员和详尽的评测计划。一般而言，完整的性能评测需要的专业人员有：产品应用专家，系统管理员， 务系统管理员，市场部人员，数据库专 家。 务系统的重要性对于主要功能需求为商贸的公司来说更是不言而喻，因为它们的绝大多数收入都来自在线交易，如果出现性能问题，哪怕是是几分钟，也会导致灾难性的后果。根据易观智库近期发布数据显示，淘宝网 2010 年第四季度服装交易规模迅猛增长达到 429 亿元，同比 2009 年四季度 167 亿元增长 156%，比 2010 年第三季度 1 绪论 2 服装交易金额 192 亿元增长 2010 年全年淘宝网服装品类交易额为 962 亿元，约占淘宝网 2010 年全年交易额（ 4000 亿）的四分之一 2。如此庞大的交易额，可以想象即使淘宝网出现 短暂的几分钟的性能问题，后果也是相当严重的。性能评测能帮助用户发现，分析系统瓶颈，错误，提高系统稳定性。虽然不能直接给公司带来经济利益，但是可以帮助公司避免因为性能问题出现而导致的客户流失和收益流失。 相对于客户端服务器模式而言， 务器系统的性能评测有自己的特殊性。 （ 1）不确定的负载 。 负载指 务系统在一个时间段内处理的信息请求。负载量的确定在性能评测中是一个重要步骤，它决定了测试结果的准确性和可靠性。传统的客户端服务器模式的软件一般基于局域网或广域网，来自用户的服务请求是可以预测的，请求时间和 方式也是相对稳定的。但是， 务系统一般基于互联网，用户的服务请求是复杂的不可知的，请求时间和防止也是不尽相同。所以负载的不确定性是 （ 2）复杂的构架 。 务的发展一日千里，技术日新月异，不断有新成功，使用的技术，平台和框架也众多。例如 技术都广泛运用于 务系统。有些时候甚至不同的平台和技术要在一起使用，这给 务质量增加了不可控制的因素。 （ 3） 多样 的组成成 分 。 一个 用系统的组成部分通常包括了： 件，本， 本， 格， 序， 件， 等。 （ 4） 不同 的运行机制 。 务系统的运行机制有分布式，并发性，实时交互的特点。典型的运行流程是：用户提出服务请求，服务器响应并处理请求，将结果发回客户端。 （ 5）不一致的运行过程 。 议是无状态的，所以每一个服务请求都是相对独立的，之间没有联系，请求的目的性不一致所以导致了运行过程的不尽相同。 由于 务系统性能评测的特殊性加上 务 系统的广泛应用，因此做好性能评测研究具有异常重要的意义： （ 1）尽早的开始性能评测有利于提前发现程序的性能问题，事实上现在的软件测试甚至先行于软件开发，这样可以避免投入过多的人力物力资源而不能得到满意的软件质量。 （ 2）性能评测可以及时的发现程序的性能问题和系统的瓶颈，可以为解决系统的瓶颈提供可靠的支持，从而诊断问题之所在和及时优化系统。 （ 3）经过性能评测，来对 务系统进行性能优化，最终可以达到提高系统可用性，可靠性和性能，减少服务质量下降以及因此带来的各种损失。 1 绪论 3 内外研究现状 近些年 来 务系统测试研究主要有一下的趋势 ： （ 1）随着模型驱动方式程序开发技术（ 广泛使用，模型驱动测试技术也随之出现，也被认为是 用测试自动化将来的发展方向。 推荐在 用自动化测试时使用这一技术。模型驱动测试的核心在于测试设计，而不是实现，重点在于模型的建立。模型驱动测试一般由控制模型，用例模型，配置模型，结果分析及生成模型，执行引擎组成 3。 议使用 .0 称为 2为模型的描述语言， 以用于 用的系统测试，单元测试和集成测试。设想，测试人员在需求明确的情况下建立测试模型，甚至在 用开发完成之前，测试模型可以先行搭建，测试模型搭建完毕，后续测试工作由测试工具完成。因为模型驱动的高效，这一技术正成为当前学术界研究的一个重要方向。 经发布一个基于模型驱动测试的工具包。 （ 2） 务技术（ 简称 面向服务构架技术（ 简称 发展，使得针对 测试也成为 用测试研究的一个重要方向。 针对 试研究主要有以下几个方面： 试， 测试， 试。这三个方面 试是最核心的，因为 发现，发布，帮顶是动态的，即 动态狗将，这就要求 试必须是动态的。现在 测试还没有实时测试，动态测试的手段，仅在静态测试，模拟验证阶段。因此不能完全保证测试是可信的。文献 4给出了目前 试面临的许多问题，比如 基础功能测试， 议有效性测试，面向服务架构技术的发布，查询，绑定功能的测试， 务质量测试， 能测试还有 全测试等。这些问题的解决与否决定了 用是否能够成功。 （ 3）近几年，由于面向代理（ 发成为一个新的学科领域，基于代理（ 测试技术也越来越受到重视。文献 5介绍了这方面的研究工作。基于代理的测试技术核心思想是，将 用中的测试任务分解为小单元，利用不同的测试代理实现分工协作，这样不仅可以用于功能测试，也同样可以用于性能测试。这样带来的好处就是测试的自动化程度得到 了提高，所以基于代理的测试工具可以提高测试效率，降低成本。不过，由于面向代理开发技术发展不完全成熟，面向代理测试技术也 有 待人们进行深入研究 6。 （ 4）性能测试负载模型的如果能够准确模拟真实，那么 用性能测试的准确度就会大大提高。由于 用类型是多样的，不同类型的 用负载也不尽相同， 1 绪论 4 所以测试人员必须为不同的应用去设计不同的负载模型。当前还不存在一个普片适用的负载模型。对于已经确定的应用，负载模型的精确与否取决于用户会话的数据集合是否准确，因为用户会话数据集合可能存在太大，太小的情况，针对这 些情况，一定要采取对应的算法或是策略来对用户会话数据集进行增加或是减少，而且还要考虑将来应用系统可能会出现的扩张，这样才可能使负载模型尽可能的合理和准确，进而实施有效的性能测试 7。 文的研究重点 之前的一些研究已经认识到了使用性能模型来指导依照服务供应来分配系统资源的价值，研究表明影响系统性能的常见因素包括：软件本身的资源消耗， 负载 ，系统管理策略，还有运行软件主机本身的性能。不过，之前的研究在预测多组件构成的网络服务软件的性能上还存在一些缺陷，主要有以下几点原因，首先，不同的程序组件往往有不同的 资源需求，组件之间的交互方式比较复杂。第二，不同于单一组件的程序，多组件网络服务软件的性能还取决于组件在集群之上的布局和冗余政策。 本文主要研究方向是设计一个性能模型， 使得这个 性能模型能够全面精确预测基于多组件 务系统 的吞吐量和响应时间。 本文的基本理念是，首先评测每个组件的资源消耗，评测在 负载 输入下时组件之间通信消耗。具体来说，本文侧重于评测那些可能对服务的吞吐量和响应时间影响很大的方面，包括 存的使用，远程调用的开销，组件间的网络带宽和阻断式通信。通过操作系统级的工具进行评测，这样对软件以 及中间件来说就没有什么影响。当给定了软件概要信息，还有组件布局的策略，性能模型就可以预测系统 的吞吐量，同时给出系统瓶颈在哪里。 通过分析组件间的阻断式通信造成的网络延迟，对集群节点的队列建模来预测系统平均反应时间。 本文介绍了一种新的针对基于多组件 台性能评测方法， 使用一种由组件性能分析驱动的性能模型，包括了组件资源需求分析、组件间调用模式分析、通讯延迟开销分析。在给定了组件的部署模式和冗余策律，就可以精确 的预测该系统的吞吐量和请求反应时间。 文结构安排 本论文主要分为以下六个部分 ,具体结构安排如下： 第一章，绪论，论文中的第一章首先性能测试对于 务系统的重要性做了简要的介绍，对于其意义进行了说明，也简要的总结了一下当前国内外的研究现状，并概括说明本文研究重点。 1 绪论 5 第二章，基于多组件的 务系统，本章主要介绍了 务系统技术的三层架构以及组件技术，特别介绍了 件技术。 第三章， 务系统性能测试 ,本章主要介绍了 务系统性能测试背景知识，性能测试中的重要指标以及常见测试工具。 第四章， 务系统性能模型， 本章介绍了一种新的针对基于多组件 台性能评测方 法 ， 主要阐述了组件性能分析驱动的性能模型 。 第五章，软件测试平台部署，本章介绍了性能模型的验证平台 统的部署过程。 第六章，模型验证，本章用实验数据来验证了本文提出的性能模型的准确性。 第七章，总结与展望，本章总结了整个研究工作并展望了将来的研究方向。 2 基于多组件的 务系统 6 2 基于多组件的 务系统 务系统的三层结构 全称为 文翻译过来为万维网。 定义有很多中，在此选择两种大家比较认可的解释 8： （ 1） 互联网上的一种服务，利用超文本链接 技术把互联网上的各种资源信息联系起来为互联网用户服务。 （ 2） 用是一个包含有 务器，网络， 议和浏览器的系统，用户在系统中输入信息来从事各种活动。 务系统是一种基于 议来进行信息资源交换的特殊的 C/S 软件应用系统。在 务系统中，用户通过浏览器来访问网页，进行各种业务操作和事务处理。 务系统与传统的 C/S 构架的软件应用程序相比，最大的区别在于用户需要处理的事务和业务逻辑从客户端转移到了服务器，用户与 览器只作为客户端负责显示从服务器返回的 件或是其他脚本。随着技术的发展，客户端可以执行的脚本数量和功能都有很大提高，但是事务逻辑仍然全部在服务器端实现。 系统中主要组成部分有：客户端， 务器，应用服务器，数据库服务器，网络设备等。客户端通过互联网与 务系统通信， 务系统的服务器一般处于一个局域网中，协作处理来自客户端的请求。 务系统 的功能代码及其资源，按照其在应用程序中的功能，可以简单分解成为三个部分：用户界面 (业务逻辑 (数据存取 (应用程序的基本功能单元如图 示。 图 2 基于多组件的 务系统 7 种典型的 务系统模型 随着时代的发展和计算机技术应用的深入，不断发展的应用程序编程模型，已经出已经出现：单层模型 ， 二 /三层客户机 /服务器应用模式 ， 多层应用模型 ， 分布式系统 。 层模型 早期针对大型机设计的程序，无需独立三个程序组成部分，没有单独的用户界面，业务逻辑和数据访问层。这和那时的计算机发展和应用需求有关，当时的用户通过哑终端共享主机资源，哑终端没有处 理能力，用户界面，业务逻辑和数据访问功能是在主机上实现的，所以当使用单层结构是合理的 9。应用层的结构如图 示。 图 层模型 层客户 /服务器应用模型 个人电脑的大力发展和广泛应用为程序开发带来了巨大的推动力，这时出现了客户机服务器模式，对于客户端和服务器端，应用程序代码和资源也有了区别。随着个人电脑处理能力的增强，一些原来原来只能在大型机运行的程序以及执行的业务逻辑转移到了到个人电脑上运行（我们把这种运行在个人电脑端的应用程序叫做客户端），此时大型机的负责提供一些业 务逻辑处理和数据访问函数（我们把这种运行在大型机上的应用程序叫做服务器）。随着个人电脑处理能力正在逐步提高，客户端任务逐渐增加，在服务器端上需求的硬件资源也逐渐减少。 根据客户端和服务器端上运行的业务逻辑的不同，分为图 示的几种形式。 图 层客户 /服务器应用模型的两种形式 2 基于多组件的 务系统 8 值得注意的是客户机 /服务器应用程序通常在不同的计算机客户端和服务器上运行，但在同一台计算机，也可以实现客户端 /服务器应用程序。 层客户服务器应用模型 两层应用模式的出现大大提高了应用程序的灵活性，而 且提高了应用程序可维护性。然而，在两层应用程序模式下，还有维护不方便的缺点，在客户端或客户端的嵌入式 可能会出现一旦改变了业务逻辑，就必须重新实现和发布一个新的客户端，也就是说，两层模型依然比较脆弱。三个或更多层应用模型解决了这个问题。 在三层应用程序模型中，业务逻辑，用户界面和数据访问清晰分离，客户端的用户界面和服务器端数据访问清晰分离，这样大大提高了应用程序的可维护性。值得注意的是，虽然最常用的多层客户机 /服务器模型是一个三层模型，不过现在业务逻辑层和数据访问层更加清晰分层也 是发展趋势，这样可以越来越提高系统的性能维护，而且还增加了集成的分布式系统的可能性和对系统的可重用性。 如图 示 图 件技术 件简介 组件的英文是 “ ，也称为元件或是构件 10。组件不是一个新概念，其实，2 基于多组件的 务系统 9 它在很多成熟的工程领域得到了广泛应用。例如，我们组装电脑，不需要了解 板，光驱的深层运行机制，只需要知道如何将这些部分组合在一起就可以了。 相对于较成熟的其他工程领域，软件产业的组件化发展较为缓慢。在 计算机软件开发的初期，应用系统通常是一个独立的应用程序。随着软件和硬件发展以及更复杂的应用需求日益增加，应用系统系统变得越来越庞大开发也已变得越来越困难。 由于模块化开发应用软件的想法，人们试图将庞大的应用系统分割成为大量模块，每个模块完成一个独立的功能模块而且模块可以协同工作。这个模块我们称之为组件。这些组件要求可以独立设计，独立编译 ，独立测试，并且可以组装成一个完整的应用系统。在行业内部人们普遍 认为未来的应用系统都将使用这样的开发方式来实现。 基于组件的软件体系结构给我们带来很大的好处。但是，为了能够以 开发组件的方式来设计实现应用系统，我们必须解决几个关键技术的问题 11： （ 1） 使用一个标准来规范组件的设计目的与功能，这将大大减轻工作人员的培训成本，提高组件的通用性。 （ 2）提供不同组件之间协作的标准方法。程序员不用考虑组件的部署方式，在这样的情况下也不妨碍它们之间的相互作用，即“部署方式透明性。” （ 3） 组件的版本要易于管理。保证元件的灵活性，即使在升级更新现有元件的情况下，应用程序不会受到操作影响。 （ 4）满足用户安全性的需求。 件简介 范将“组件 软件”的概念引入到 程的领域。组件是自含的、可重用的软件单元；而 件，则可以使用可视的应用程序开发工具，可视地将它们编写到 序中。 “软件组件 ”的概念引入到 程领域 12。组件是自包含的，可重用的软件模块 ;对于 件而言，可以使用可视化应用开发工具，以直观的方式来开发序。 规范为 序员们把 “组件化”提供了具体的指导： ，只要具有某种特性和事件接口约定的 都可以是一个 3。 在越来越注重软件重用的今天，如果 满足某些约束，那么它们就可以作为 实上，在开发任何新的应用系统之前，都应当考虑是否使 开发它。如果希望软件模块可以被可视化的操作，而且还可以进行定制以实现某些结果，那么该软件模块应当用 开发。 2 基于多组件的 务系统 10 如果是使用 开发的组件会有以下优点： （ 1） 可以多次重用 （ 2） 可以和其他 件一起重用协作使用 （ 3） 可以使用 如 类的软件）使用 是在 程环境下可重复使用的组件，由于是基于 计，所以它可以适用于客户端或服务器计算机上运行。由于支持 具，同时 一个图形用户界面（ 组件，因此该 件可以作为客户端技术考虑。然而， 此它们也可以在服务器环境中使用。 作为 一般具有以下特点 14： （ 1） 使用规范设计模式。设计模式就是方法和接口的编码约定。 （ 2） 支持 发工具。 必须将变量（称为属性）、方法和事件展 示出来。 （ 3） 可以定制开发。定制开发指提供了变量（属性）编辑器，提供确定的定制规则。这样可以使开发人员在不更改 源码的情况下更改 行为。 （ 4） 是持久的。持久的含义是允许在一个 定制开发一个 后以其定制之后的状态保存。 介 企 业级 可以管理的 用 于 构筑企 业级 服务端 应 用的 组 件 9。 业 版 提供了 对 规 范。 一个封装有 具有指定 业务逻辑 的 服 务 器端 组 件的应用程序软件包。 的在于 规 范的 为 企 业及 应 用开 发 人 员 提供一个 标 准方式 实现 后台 业务 ， 来 解决一些 在业务流程中 重复 发 生的 问题 。 一个 标 准方式自 动处 理了 诸 如数据持久化，事 务 集成，安全 对 策等不同 应 用的共有 问题 ，使得 软 件开 发 人 员 可以 专 注于 该方案的具体 需求而不 用去考虑除了业务逻辑以外的问题 。 技 术 上而言不是一种 产 品 ，而是一种业务规范。 一种 标 准 ， 描述了构建 应 用 组 件要解决的 下列问题 : （ 1） 可 扩 展 (（ 2） 分布式 (（ 3） 事 务处 理 (（ 4） 数据存 储 (（ 5） 安全性 (2 基于多组件的 务系统 11 种类 器可以接受三 类 5 （ 1） 会 话 无状 态 会 话 有状 态 会 话 （ 2） 实 体 （ 3） 消息 驱动 无状 态 会 话 一 类 不包含状 态 信息的分布式 对 象，允 许 来自数个客 户 端的并 发 存取。 实 例 变 量的内容在前后数次呼出中不被保留（确切地 说 是不保 证 保留）。由于不必控制与用 户间 的 对话 信息而减少了开 销 ，无状 态 会 话 像有状 态 会 话 样 具有 资 源集 约 性。 举 例来 说 ，一个 发 送 邮 件的 可被 设计为 一个无状 态 会 话 整个会 话期，用 户 只向服 务 器提交一 个 动 作： 发 送指定 邮件 到指定地址 16。 有状 态 会 话 包含状 态 的分布式 对 象，即是 说 ， 贯 穿整个会 话 它 们 都要保有客 户端信息。 举 例而言，在一个网上商店 进 行 实 施 结账 很可能就需要一个有状 态 会 话 为结账 是一个多步 动 作，服 务 器端必 须 可以随 时 了解到用 户 已 经进 行到了哪一步。此外，尽管有状 态 会 话 状 态 信息可被保持，但始 终 只能同是由一个用 户 来 访问 之。 实 体 含有持久化状 态 的分布式 对 象。 这 个持久化状 态 的管理既可以交 给 也可以托 付于外部机制（ 消息 驱动 支持异步行 为 的分布式 对 象。它 们 并不 对请 求 进 行当即响 应 。比方 说 ，某网站用 户 点 击 “ 请 通知我更新信息”按 钮 ，将会触 发 某个 这 名用 户 加入到数据库 的希望 获 得更新信息用 户 列表中。 这 个 动 作就是一个异步的消息 驱动过 程，因 为 用 户 不必等待当 时 会返回某个 结 果。 消息源来自 息服 务 （ 供的消息 队 列或消息主 题 。自 范起， 加入 进 来以允 许 在容器内部 实 施事件 驱动处 理。与其他 同， 存在一个用 户视图 （如需要用 户 引用的 远 程接口），用 户 也不能通过资 源定位 获 得一个 例。 在后台 监 听消息源并 实 施自 动处 理 17。 术的 优点 下面列出了采用 术所带来的好处 18： 2 基于多组件的 务系统 12 （ 1） 使用 件让开发应用系统变得更加简单。虽然 系结构复杂，不过程序员一般都不需要再花时间去编写访问系统服务的代码。 件访问系统服务的任务可以交给 器的系统组件来实现。 （ 2） 服务器端业务逻辑可以移植。 由于采用 言开发， 生具有可移植性，系结构还在 支持的容器之间提供了一套标准化的应用程序编程接口。这样的话，程序员不需要重新编码就能够将现有的 一种操作环境直接移植到另一种操作环境。 (3)为一种组件技术，无论是在服务器端或是客户端都可以轻易实现重用 (4)系结构支持分布式对象、事务处理、数据 库、安全和全局命名等典型企业级系统所需要的服务。 (5)系结构在业内被广泛应用，所以客户几乎可以不用担心无法找到配套的 器或是服务器。由于 有标准的体系规范，即使是不同的供应商提供的 器都是可以相互兼容的。 （ 6） 由于组件严格分离，使用 件搭建的应用系统可以轻松从一个服务器移植到不同的服务器环境，支持伸缩性。 3 务系统性能测试 13 3 务系统性能测试 件测试 软件测试根据不同的角度 ,可以有不同的分类 19: （ 1）按是否需要执行被测软件的角度 ,软件测试可分为静态测试 (动态测试 (前者不执行被测程序而应用其他手段实现测试目的 ,如代码走查 :而动态测试则通过运 行被测试软件来达到目的。 （ 2）按软件开发周期划分 ,软件测试可分为单元测试 (集成测试(系统测试 (验收测试 ( 单元测试是对软件中的最基本的组成单位进行的测试 ,如一个模块、一个函数或过程等。单元测试以被测试单位的规约为基准 ,其目的是检验软件基本组成单位的正确性 ,一般由程序员来完成。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等20。 集成测试是在软 件系统集成过程中进行的测试 ,其目的是检查软件组成单位之间的接口是否正确。它根据集成测试计划 ,一边将模块或其他软件单位组合成越来越大的系统 ,一边运行该系统 ,以分析所组成的系统是否正确。 系统测试针对已经集成好的软件系统进行彻底的测试 ,以验证软件系统的正确性和性能等是否满足其规约所指定的要求。系统测试的输入、输出和其它动态运行行为应该与软件规约进行对比。软件系统测试主要有功能测试、性能测试、随机测试等。 验收测试目的是向软件的购买者或使用者展示软件系统是否满足需求 ,目标是验证软件的功能和性能及其它特性与用 户的要求是否一致。它的测试数据通常是系统测试的测试数据的子集。 （ 3）按测试方法划分 ,软件测试可分为白盒测试 (黑盒测试( 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试 21。白盒测试将被测程序看作一个打开的盒子 ,测试人员可以看到被测的源代码 ,可以分析被 测程序的内部构造。此时测试人员不考虑程序的功能 ,只根据其内部构造来设计测试用例。 黑盒测试又称功能测试或数据驱动测试 22。黑盒测试把任何被测程序都看作是从定义域映射到 值域的函数。该观点将被测程序看作一个关闭的黑盒子 , 里面的内容对测试人3 务系统性能测试 14 员而言是未知的。在用黑盒测试方法设计测试用例时 ,测试人员所使用的惟一信息就是软件系统的需求说明书 ,只依靠被测程序输入和输出之间的关系或程序的功能来设计测试用例。 本文研究的 用程序性能测试需要执行程序 ,是动态测试 ,属于系统测试范畴 ,采用黑盒测试方法。 能测试 性能测试是使用特定软件收集分析应用软件系统信息的过程，在这个过程中收集 到的数据用来预测何种程度的负载水平将耗尽系统资源 23。 性能测试的主要目的是找出软件应用 程序的性能瓶颈，为改善系统性能提供依据和修改方向，保证应用程序具有良好的性能。性能测试考察在不同的用户负载水平下系统的吞吐量，请求响应时间等主要指标来确保将来系统运行时的执行高效。 务系统性能测试是收集分析 用软件系统信息的过程 24。 务系统性能测试主要考察在用户可接受的请求响应时间内系统所能承受的负载量（同时能够服务多少并发用户和并发业务），系统负载的临界点和系统的瓶颈。性能测试的过程也是系统实时运行的过程，一个成功的性能测试需要一个尽量真实运行环境（在真实的运行环境实施为最佳）， 还需要贴近真实的用户操作（一般通过大量过往发生的记录修改得出）。一般过程是模拟一定用户量的负载对 务系统进行访问生成测试结果，对测试结果进行分析得出结论，根据结论来分析系统的瓶颈所在，然后修改被测的 务系统。 务系统性能测试的目的主要有 25： （ 1）评测系统性能：测试中得到的负载临界点和请求响应时间都可以用来衡量 （ 2）发现系统瓶颈：测试中得到的数据可以发现系统性能瓶颈所在或是资源短板，从而指导性能调优。 （ 3）系统性能调优：在性能测试之后修改完善系统，然后 进行重复测试验证系统调整是否达到预期，从而提高系统性能。 （ 4）验证系统稳定性和可靠性：在正常范围内的负载下，执行一定量的测试行为可以评估系统稳定性和可靠性。 3 务系统性能测试 15 务系统请求处理过程 务系统性能测试的首要任务是研究和理解一般事务中请求的处理过程。 一个典型的请求处理过程如下： (1)用户通过输入地址或者点击链接向服务器发送请求 (2)客户端通过本机指定的 名解析服务器）解析服务器的 址，连接到服务器，发送一个请求 (3)数据由客户端传送到服务器 (4)请求数据送达服务 器，并被解析处理。 (5)服务器相应请求，客户端所需要的数据被发回 (6)客户端接受返回的数据 以上过程如图 示。 图 能评测的 重要指标 从最初诞生到 务系统结构越来越复杂的今天，性能一直是衡量软件质量的重要3 务系统性能测试 16 指标。下面介绍一些关于 能评测的术语，只有掌握了这些基本的概念，才能进一步的进行性能评测 26。 并发用户：并发一般分为两种情况。一个是严格并发，即在同一时间若干用户都做同样的操作，例如在银行业务中，不同的操 作员可以同时对同一个账户进行操作。另一种并发是广义的并发，即同一时间若干用户都进行了操作，但不一定是相同的，例如在网上银行业务中，有的用户在查询余额的时候，有的用户在进行转帐。这个时候，对于系统来说，即使用户的操作不相同，但是发生在同一时间，所以属于并发。可以得出结论，广义并发包括严格并发。因此在实际情况中在大多数系统只有一小部分用户进行严格并发操作。对于 用系统性能评测而言， 两种行为都是并发的 27。 并发用户数：严格意义上来讲凡是在线用户数就是并发用户数，即使某些在线用户对性能影响不大，例如仅仅 只是浏览静态网页的用户 28。 请求响应时间：一个从客户端发出请求经过服务器的处理然后客户端得到响应整个过程所消耗的时间就是请求相应时间。请求响应时间计量单位一般为“秒”或者“毫秒”。 事务响应时间：一个事务可能由若干个请求组成，事务相应时间指一系列若干请求从客户端发出到客户端相应的总共消耗时间 29。 吞吐量：在性能评测过程中传输的数据量的总和。 吞吐率：吞吐量 /传输时间即为吞吐率。 资源利用率： 务系统所在的硬件环境资源消耗情况，例如服务器的 用率，磁盘利用率等。资源利用率是性能评测改善 性能的主要依据，是 能评测工作的重点。 本文着重研究的两个指标： （ 1）请求响应时间： 从用户的角度来看，它是一个从客户端请求发出直到收到服务器的响应时间。通常时间单位为秒或毫秒。一般情况下，等待时间和系统空闲资源之间呈反比，和系统负载成正比。通常当并发用户增加或是请求数增加时，请求响应时间会慢慢延长，随着请求数的增加，一旦超过了系统 负载 的临界点，请求响应时间会迅速上涨。一般是因为系统的某一资源（例如 是内存资源）消耗完全而导致出现临界点。如果请求数持续超过系统 负载 ，很可能会导致 务系统的崩 溃 30。 响应时间和用户之间的负载关系见图 3 务系统性能测试 17 图 应时间和用户负载关系 （ 2） 吞吐率 吞吐率是指在某一个时间段内系统成功处理的用户请求数量。常用的单位是请求数 /秒。在一些大的 务系统的实际应用中 ,吞吐率可以用每分钟甚至是每秒用户访问量来表示 30。 一般情况下 ,在没有到达系统 负载 临界点时 ,随着用户负载的增长，吞吐率也会增长。 而在越过系统 负载 临界点后 ,吞吐率将会固定在一个数值上（一般而言我们认为此时的数字就是系统最大负载）或者是下降。如果临界点的到来是由于网 络设备的吞吐限制引起的话 ,吞吐率会保持不变 ,这时如果改善网络状况 ,吞吐率可能会随着用户负载的上升继续增加 ;如果临界点是由硬件服务器所受压力过大资源紧张时 ,吞吐率会有可能会下降。此时 ,务系统不会继续处理用户请求甚至有可能崩溃 ,这时需要改进服务器的软硬件配置来优化性能。 吞吐率和用户负载之间关系曲线如图 示。 图 吐率和用户负载的关系 从上面可以得出，吞吐率和响应时间之间是息息相关的，它们都会因为用户负载的变化而变化。一般而言，吞吐率较小的 务系统必然有较长的响应 时间。另一方面来看，3 务系统性能测试 18