（计算机软件与理论专业论文）分布式软件性能测试工具设计及其关键模块的实现.pdf

西南交通大学硕士研究生学位论文第1 页 摘要 当今软件规模和复杂度急剧增加，手工的软件测试越来越不能满足软件 测试需求，促使人们开发测试工具，实现测试自动化。随着网络在应用中的 地位越来越重要，分布式结构能更好地整合网络功能，所以分布式系统被日 益广泛地使用。国内在测试工具方面相关的研究工作已经展开，但针对分布 式软件的测试工具仍然有待进一步实现和增强。本文在分布式软件性能测试 工具设计和实现方面进行探讨。 论述了分布式软件性能测试的概念。通过分析分布式软件性能测试工具 的测试流程确定其系统模块构成和关系，设计出系统总体框架。结合分布式 结构的特点，提出了把测试工具设计成总的测试控制台加分布于多台机器上 的测试代理的结构。重点讨论了其中测试用例生成模块、脚本生成模块、测 试执行和测试结果处理模块的实现。 为了利用测试管理工具中对软件建模的u m l 图，尝试在测试工具中引 入由u m l 顺序图生成测试用例的功能。从r a t i o n a lr o s e 的m d l 文件中解 析出顺序图用x m l 格式表示，然后从x m l 格式文件中分析出测试用例。 测试开发模块是测试工具中最关键的模块，通过运行被测试程序把被测 试程序调用的a p i 记录下来，经过处理形成脚本，这样就记录程序的行为， 测试过程中运行脚本便可以模拟程序行为。记录测试程序的a p i 要利用 w i n d o w sa p i 钩子技术，测试工具进程通过安装钩子用代理函数地址把被测 试程序中导入地址表中加载的动态链接库函数地址替换掉，这样程序中调用 函数的时候转到代理函数地址调用代理函数而不是调用原函数，代理函数具 有记录a p i 的功能和调用原函数功能。记录下来的a p i 要经过a p i 封装和代 码封装，形成高级语言的脚本文件。接着对脚本进行定制，在其中添加辅助 测试的语句，还可以对脚本某些字段参数化，脚本运行的时候用参数文件中 的对应值替换脚本的参数。参数文件可以手工建立，也可借助上述生成的测 试用例生成。最后把脚本编译成动态链接库形式。 在测试执行模块中，提出一种分层的结构，把测试脚本、性能计数器和 调度参数组织成测试单位的方案。测试控制台配置好测试并下发到测试代理 后，以虚用户为单位调度测试执行。脚本和性能计数器以并发线程方式运行 便于收集性能指标。 西南交通大学硕士研究生学位论文第1 i 页 测试结果处理模块以文件上传和整合的方法得出系统总体性能指标。测 试结果以图表等友好方式反馈给用户。 关键字：软件测试软件性能分布式软件性能测试工具a p i 钩子技术 西南交通大学硕士研究生学位论文第1 ii 页 a b s t r a c t n o w a d a y sw i t ht h ei n c r e a s i n gi ns i z ea n dc o m p l e x i t yo fs o f t w a r e ，t h em a n u a l s o f t w a r et e s t i n gb e c o m e sm o r ea n dm o r eu n s u i t a b l et od e m a n d t h ec o n d i t i o n c o m p e l su st or e s e a r c ha n dd e v e l o ps o f t w a r et e s t i n gt o o l s ，s ot h a ts o f t w a r et e s t i n g a u t o m a t i z a t i o nc a nb et u r n e di n t or e a l i t y i nt h i st h e s i s ，t h ed i s t r i b u t e ds o f t w a r e p e r f o r m a n c et e s t i n gt o o l si sd i s c u s s e da n dr e s e a r c h e d a tf i r s t ，t h et h e s i sw i l l a n a l y s et h e w o r k f l o wo fd i s t r i b u t e ds o f t w a r e p e r f o r m a n c et e s t i n gt o o l s f r o m t h ew o r k f l o w , t h es t r u c t u r eo ft e s t i n gt o o l s p r o g r a mi sd e s i g n e d t h e s t r u c t u r em a n i f e s t st h er e l a t i o n s h i p sb e t w e e nc o m p o s i n g m o d u l e so f t e s t i n gt o o l sa n dt h ef u n c t i o n so f t h e s em o d u l e s t h e nt h er e a l i z a t i o n so fs e v e r a lk e ym o d u l e sa led i s c u s s e d n e ya r et e s t i n g u s ec a s ep r o d u c t i o nm o d u l e ，t e s t m gs c r i p tc r e a t i o nm o d u l e ，t e s t i n ge x e c u t i o n m o d u l ea n d t e s t i n gr e s u l tp r o c e s sm o d u l e t h et e s t i n gu s ec a s ep r o d u c t i o nm o d u l ed i s t i l l su m ls e q u e n c ed i a g r a m sf r o m r a t i o n a lr o s em d lf i l e a n dt h e nt e s t i n gu s ec a s e sa r ed i s t i l l e df r o mt h e s e s e q u e n c ed i a g r a m s t e s t i n gs c r i p tc r e a t i o nm o d u l eu s e st e c h n o l o g yo ft h ew i n d o w sa p ih o o kt o r e c o r do r i g i n a lt e s t m gs c r i p t t h eo r i g i n a lt e s t i n gs c r i p tw i l lb ep r o c e s s e dd u r i n g a p ie n c a p s u l a t i o na n dc o d ee n c a p s u l a t i o ns t a g e s a f t e rt h es c r i p ti sp r o c e s s e d , t h e o r i g i n a lt e s t m gs c r i p tw i l lb e c o m ea d v a n c e dl a n g u a g ep r o g r a mf i l e a tl a s t ，t h e a d v a n c e dl a n g u a g ep r o g r a mf i l es c r i p tc a nb ec u s t o m i z e da n dp a r a m e t e r i z e d t e s t i n ge x e c u t i o nm o d u l ec o l l e c t st e s t i n gr e s u l td a t af r o ma l lo ft h et e s t i n g a g e n tm o d u l e s t h er e s u l td a t aa r ep r o c e s s e da n df e e d b a c k e dt ou s e rb yt a b l e so r d i a g r a m se t c k e yw o r d s ：s o f t w a r et e s t i n g , s o f t w a r ep e r f o r m a n c e , d i s t r i b u t e d s o f t w a r e p e r f o r m a n c et e s t m gt o o l s ，t e c h n o l o g yo f a p ih o o k 西南交通大学 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校 保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和 借阅。本人授权西南交通大学可以将本论文的全部或部分内容编入有关数据库 进行检索，可以采用影印、缩印或扫描等复印手段保存和汇编本学位论文。 本学位论文属于 1 保密口，在年解密后适用本授权书； 2 不保密囤，使用本授权书。 ( 请在以上方框内打“4 ”) 学位论文作者签名：倚鹰铭 日期：力嘞厂、2 占 指导老师签名- 童3 雾 日期卅夕- 彩 西南交通大学学位论文创新性声明 本人郑重声明：所呈交的学位论文，是在导师指导下独立进行研究工 作所得的成果。除文中已经注明引用的内容外，本论文不包含任何其他个 人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和 集体，均已在文中作了明确的说明。本人完全意识到本声明的法律结果由 本人承担。 本学位论文的主要创新点如下： ( 1 ) 本文提出了根据u m l 顺序图生成测试用例的方法。从r a t i o n a lr o s e 的m d l 格式文件中提取出顺序图，用x m l 格式表示，然后再从x m l 格 式文件中提取测试用例。 ( 2 ) 在脚本参数化中，尝试用测试用例来自动生成参数化文件。 ( 3 ) 通过分析分布式系统的结构特点，确定测试工具为由测试控制台和多 个测试代理组成的结构。结合这样的测试工具结构，在测试结果收集阶段， 提出了一种层次化的收集和汇总结果的方法。 西南交通大学硕士研究生学位论文第1 页 1 1 问题提出 第一章绪论 随着计算机处理速度的飞速提高，内存和外存容量的快速增加，软件在 整个系统中变得越来越重要，软件规模越来越大。可视化编程环境、日益完 善的软件分析设计方法( 如面向对象设计概念的产生) 以及新的软件开发过 程模型的提出( 如螺旋模型，增量模型等) 使得大型软件的开发成为可能。 同时，由于软件规模和复杂度的急剧增加，软件可靠性和质量面临危机。软 件测试被作为一种基本的、有效的消除软件故障的手段，是软件可靠性和质 量保证过程的关键元素【l 引。 在过去的数年中，软件测试主要靠手工进行。随着软件工程的发展，开 发过程已经从瀑布式开发转向迭代式开发，而且体现出巨大的好处。迭代式 开发已经成为目前最流行的软件开发过程。在迭代开发中，强调在较短时间 间隔内产生多个可执行、可测试的软件版本，这就意味着测试人员必须为每 次迭代产生的软件系统进行测试。测试周期被缩短，测试频率被增加。在这 种情况下，传统的手工测试已经远远不能满足软件开发的需求。当第一个可 测试的软件版本产生后，测试人员开始对这个版本的系统进行测试。很快第 二个版本在第一个版本的基础上产生了，测试人员需要在第二次测试时重复 上次的测试工作，还需要对新增加的功能测试例。如此下去，将很难保证测 试工作进度和质量。因此，运用良好的自动化测试工具进行自动测试势在必 行。 在软件性能测试或者其他测试过程中，难以用手工的方法模拟测试过程 和收集测试指标，而用自动化测试工具则能很好解决这些问题。如，在负载 测试中，为了在被测系统上不断增加压力，直到性能指标，例如“响应时间 超过预定指标或者某种资源使用已达饱和状态，需要把测试脚本下发到多个 代理中，控制多个代理同时并发执行脚本，通过多进程集中地跟服务器通信 增加系统压力，确定系统性能指标。控制多个进程并发运行，用手工方法模 拟既复杂又不够精确。 因此，进行软件测试的自动化是必要的，也就是通过自动化软件测试工 西南交通大学硕士研究生学位论文第2 页 具，按照某种指定的软件开发标准，对整个软件测试过程进行统一的安排， 从而促进软件测试工作的开展。 目前测试工具市场被国外产品占据，主要希t e s t d i r e c t o r ，l o a d r u n n e r 等。这些工具满足了测试功能的大部分，但是由于价格昂贵、提供的用户数 受限制、不能满足一些特定应用领域软件测试指标要求、没有为用户开发提 供便利接口等方面的原因，难以满足国内的需求。而且为了摆脱国外测试工 具的垄断地位，我们需要开发出有自己知识产权的产品。 在国内，目前对软件测试工具的需求也随着业界对软件测试工作的重视 和软件测试规范的推广、认证有了很大的增加。相关的研究和开发工作已经 展开，但仍然处于初步阶段，当前的测试工具远远满足不了市场的需求。 软件的应用范围极其广泛，体系结构多种多样，即使对一个软件进行测 试也可以分为对其功能或性能方面的测试。所以对于现存的测试，没有一个 工具具有包罗万象的功能，来满足各种测试要求。 针对这种情况，本文在分布式软件性能测试方面讨论测试工具的设计和 开发。根据分布式软件特点，讨论分布式软件性能测试工具的总体框架设计 及其模块的实现。 本文的主要工作就是探讨分布式性能测试工具的设计和实现，希望对测 试工具的设计与开发提出一套较好的解决方案，使之适用于分布式的系统环 境并提供较好的开发和部署方面的灵活性。 1 2 研究内容 探讨软件测试的基本理论，说明性能测试的概念和内容。描述软件测试 工具工作流程和体系结构，设计分布式软件性能测试工具的总体框架，研究 其关键模块的实现。具体包括以下内容： ( 1 ) 讨论分布式软件测试工具体系结构，设计其总体框架。根据分布式 结构的特点，是把测试工具结构设计为总控制台和分布于多台机器上的测试 代理的形式。在总控制台进行测试脚本开发和测试配置，调度测试，把测试 下发各代理，测试代理执行测试并记录结果。测试完成后代理把性能数据文 件上传总控制台，由它分析处理结果，反馈给用户。 ( 2 ) 测试管理平台中有对软件u m l 建模，测试工具可以利用这些资源， 因此在测试工具中提出了由u m l 顺序图生成测试例的模块【l l 】。从r a t i o n a l 西南交通大学硕士研究生学位论文第3 页 r o s e 的m d l 文件中解析出u m l 顺序图，用x m l 格式表示。然后再从x m l 生成测试脚本。 ( 3 ) 脚本生成模块，根据测试需求选择适当的脚本录制协议，利用 w i n d o w sa p i 钩子技术，运行被测试程序，通过捕获其调用的a p i 记录程序 行为，形成a p i 记录文件。a p i 记录文件经过a p i 封装和脚本封装转化成可 编译执行的源程序代码。进入脚本定制阶段，在这些源程序代码中插入检查 点或其他功能语句定制脚本，在需要情况下进行脚本参数化。脚本参数化的 时候可以利用上述生成的测试用例自动生成参数文件。这样得到的脚本更好 地完成性能测试需求。 ( 4 ) 测试执行模块和结果分析模块。提出一种分层的结构把测试脚本、 性能计数器和调度参数合理地组织起来组成一个测试单位结构。建立和配置 好测试，把测试下发各测试代理，测试运行完后测试代理上传数据到测试控 制台，在此设计一种数据文件的上传方法。这些数据文件经过合并和数据处 理，以图表或者表格的形式把性能指标呈现给用户。 西南交通大学硕士研究生学位论文第4 页 第二章分布式软件性能测试技术 2 1 软件测试分类 许多科学家从不同的角度给出了软件测试的定义。m y e r s 认为：程序测试 是为了发现错误而执行程序的过程。1 9 8 3 年，i e e e 给出的软件测试定义为： 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否 满足规定的需求或是弄清预期结果与实际结果之间的差别。软件测试方法 和技术多种多样，根据不同角度，可以将测试方法分为不同种类。 2 1 1 白盒测试和黑盒测试 从测试是否针对系统内部结构和具体实现算法的角度，可以分为白盒测 试和黑盒测试，这是测试的方法n 到。 白盒测试就是由程序内部逻辑结构及有关信息来设计和选择测试用例， 对程序的逻辑路径进行测试。白盒测试一般可分为静态分析和动态分析两类 技术。 静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功 能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。纠正软件系 统在描述、表示和规格上的错误。因此，是任何进一步测试执行的前提。静 态分析覆盖程序语法的词汇分析，并研究和检查独立语句的结构和使用。主 要有以下3 种不同的程序测试可能性： ( 1 )检查程序内部的完整性和一致性： ( 2 )考虑预定义规则； ( 3 )把程序和其相应的规格或文档进行比较。 动态分析包含了系统的执行，当软件系统在模拟的或真实的环境中执行 之前、中、后，对软件系统行为的分析是动态分析的主要特点。动态分析包 含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一 个系统在检查状态下是正确还是不正确。在动态分析技术中，最重要的技术 是路径和分支测试。在路径测试中，使程序能够执行尽可能多的逻辑路径。 西南交通大学硕士研究生学位论文第5 页 路径测试度量程序的最主要性质特征是复杂度。分支测试需要程序中每个分 支至少被经过一次。分支测试中出现的问题可能会导致今后程序缺陷。 黑盒测试把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求 规格说明书的要求来检查程序的功能是否符合它的功能说明。尽管黑盒测试 是围绕着用户需求文档进行的，但是黑盒测试不一定必须要用户来参与测试。 在绝大多数没有用户参与的黑盒测试中，常见的测试有：功能性测试、性能 测试、安全性测试、恢复性测试等。 2 1 2 单元测试、集成测试和系统测试 从实际测试的前后过程来看，软件测试是由一系列的不同测试组成，这 些软件测试的步骤分为单元测试、集成测试和系统测试，这是测试的策略和 步骤。这种分类方法在软件开发过程中的具体关系如图2 一l 所示路3 。 图2 1 软件单元、集成和系统测试与软件开发过程的关系 单元测试的对象是模块。单元测试依据详细设计，对模块内所有重要的 控制路径设计测试用例，以便发现模块内部的错误。单元测试中，软件的独 立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试采用白盒 测试技术。 集成测试是组装软件的测试技术，按概要设计和详细设计要求把通过单 元测试的各个模块组装在一起之后，进行集成测试以便发现与接口有关的各 种错误。集成测试以黑盒测试为主以白盒测试为辅。集成测试有以下两种方 式。 ( 1 ) 一次性集成方式是一种非增殖集成方式，也叫整体拼装。首先对每 个模块分别进行模块测试，然后再把所有模块集成在一起进行测试，最终得 到要求的软件系统。 ( 2 ) 增殖集成方式，也称递增集成法。即逐次将未曾测试的模块和已测 西南交通大学硕士研究生学位论文第6 页 试的模块或子系统结合成程序包，然后将这些模块集成为较大系统，在集成 的过程中边连接边测试，以发现连接过程中产生的问题。最后增殖逐步集成 为要求的软件系统。这种方式又有3 种集成策略。 ( a ) 自顶向下集成。采用和设计一样的顺序对系统进行测试，它第一时 间内对系统的控制接口进行了验证。首先集中测试项层组件，然后逐步测试 底层组件。集成方式可采用深度优先和广度优先策略。 ( b ) 自底向上集成。从具有最小依赖性的底层组件开始，按照程序模块 设计的依赖关系树的结构，逐层向上集成。 ( c ) 混合集成方式。是把以上两种集成方式结合起来进行集成的测试方 式。 系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个 元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结 合在一起，在实际运行环境下，按照需求分析和概要设计要求验证系统各部 件是否都能正常工作并完成所赋予的任务。系统测试主要采用黑盒测试方法。 系统测试的方法很多，有功能测试、性能测试、恢复性测试、兼容性测试、 安全性测试等。 2 1 3 性能测试和功能测试 按照软件所要达到的用户需求可分为功能测试、性能测试。功能测试 保证软件达到用户需求规格说明书上规定的功能要求，既不能多加也不能减 少。性能测试主要测试软件的在一定条件下响应速度、稳定性、可靠性等性 质指标或者瓶颈数据。性能能测试贯穿单元测试、集成测试、系统测试整个 测试阶段。虽然每一测试步骤都包含性能测试，但只有在集成测试和系统测 试阶段中才能全面、可靠地测试运行性能。下面详细介绍性能测试。 2 1 3 1 性能的分类 软件的性能不仅仅由自身反映出来的性能来衡量，要考虑用它运行过程 中所在的软件和硬件运行环境所体现的性能来刻画才全面。所以在软件性能 测试过程中需要考虑的性能有，被测试软件本身的性能、运行环境的硬件性 能、运行所依赖的软件环境的性能。 西南交通大学硕士研究生学位论文第7 页 被测试软件本身的性能主要包括服务请求响应时间，服务请求成功率等， 软件自身的服务指标。 软件运行的硬件环境性能包括处理器、内存、硬盘、网络等方面的性能， 可调用操作系统自身提供的计数器接口来收集这些性能参数。 被测试软件通常要建立在一些软件的基础上，如操作系统、数据库、服 务器( 如工i s 服务器、t o m c a t h 艮务器) 。这些性能的收集同样调用软件或者系 统自身提供的计数器接口。 2 1 3 2 性能测试的常用方法 下面介绍性能测试一些常用方法l 。 压力测试，测试系统在一定的饱和状态下，如c p u 、内存等在饱和使用情 况下，系统能够处理的会话能力，以及系统是否出现错误。 配置测试，通过对被测试系统的软硬件环境的调整，了解各种不同环境 对系统性能影响的程度，从而找到系统各项资源的最优分配原则。 负载测试，通过在被测系统上增加压力，直到性能指标，如响应时间超 过预定指标或者某种资源使用已经达到饱和状态。这种方法可以找到系统的 处理极限，为系统调优提供数据。 并发性测试，通过模拟用户的并发访问，测试多用户并发访问同一个应 用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。 可靠性测试，通过给系统加载一定的业务压力，例如资源在7 0 - 9 0 的使 用率，在这种况下，让系统运行一段时间，测试系统在这种条件下是否能稳 定运行。 失效恢复测试，是针对有冗余备份和负载均衡的系统设计的。这种测试 方法可以用来检测如果系统局部发生故障，用户是否能够继续使用系统；以 及如果这种情况发生，用户将受多大程度影响。 2 1 3 3 性能测试应用领域 能力验证，在已确定的运行环境下，根据典型场景设计测试方案和用例， 验证应用在给定条件下是否具有规定的能力。 规划能力，考虑应该对系统如何规划，才能使其具有要求的性能能力， 西南交通大学硕士研究生学位论文第8 页 或者在某种可能发生的条件下，系统具有怎样的性能。例如，系统能否支持 未来一段时间内用户增长，或如何调整系统配置，使它满足增长的用户数需 要。 性能调优，先确定系统运行基准环境和基准性能指标，执行测试，记录 并分析性能指标。然后调整应用运行环境和实现方法，改进性能。周而复始 地执行这些工作，直到得到满意的系统性能指标。 发现缺陷，通过性能测试手段来发现系统中存在的缺陷。在某些情况下， 应用在测试环境下非常正常，一旦交付给用户就出现大量莫名其妙的错误。 虽然这并不完全由并发或是性能问题引致，但多人访问时速度时快时慢，多 人访问时应用崩溃的几率明显增大等问题，多数是由于并发时的线程锁、资 源竞争或是内存问题引起的。性能测试的这个应用领域一般可以作为系统测 试阶段的一种补充测试手段，或是作为在系统维护阶段的问题定位手段，对 系统运行过程中已出现问题进行重现和定位。 2 2 分布式软件性能测试 软件测试还可以根据被测试软件种类的不同分为分布式软件测试、嵌入 式软件测试等。本文着手开发一个针对分布试软件性能的测试工具，在此先 探讨分布式软件性能测试的概念。 2 2 1 分布式结构 分布式系统是在由通信网络互联的多处理机体系结构上执行任务的系 统，对于用户来说就像是单个相关系统。分布式系统的信息处理分布在许多 计算机上而不是局限在单一机器上。相对于运行在个人计算机或者工作站而 设计的个人系统，在分布式系统中，系统软件运行在一组松散的、通过网络 连接的、协调运行的处理器上。分布式系统具有资源共享、开放、并发、易 扩展性、容错、透明的特性。但在复杂性、安全保密性、可管理性、不可预 测性方面存在不可避免的缺点。在分布式系统的设计中需要考虑分散在不同 计算机上的资源标识、通信方法以及如何选择正确的体系结构、实现要求的 服务鳓。 西南交通大学硕士研究生学位论文第9 页 m a c h i n eam a c h i n ebm a c h i n ec 图2 2 分布式系统结构 图2 2 呈现了分布式系统结构。分布式系统是由网络互连起来的计算机组 成的，计算机上运行着各种操作系统，这些计算机系统通过中间件为上层应 用提供了统一的访问整个分布式系统的接口。分布式应用程序分散在这些计 算机系统上，通过调用中间件接口用统一的方法交互，应用程序的各部分之 间就象在一个统一的计算机系统中运行，从而构成了一个整体，而不是分散 的各个部分。 最简单的分布式系统模型是多处理机的体系结构模型。多处理器组成的 系统可以运行在不同的处理器上，处理的进程分布或是预先定义的次序，或 由分发器控制。实际应用中许多大型实时系统采用这种体系结构模型。目前 的分布式体系结构，为客户端明艮务器体系结构和分布式对象体系结构。前者 是分布式的服务在客户端调用，提供服务的服务器针对使用不同服务的客户， 进行不同处理。后者则使客户端和服务器没有区别，系统的对象可以提供和 使用其他对象的服务，对象通信通过中间件系统完成。 现在流行的分布式应用普遍采用客户机n 务器以及浏览器n 务器模 式，所以分布式软件的测试主要针对这两种模式。 2 2 2 分布式软件性能测试及其测试工具 分布式系统软件性能测试就是收集分布式软件运行过程中的各项性能指 西南交通大学硕士研究生学位论文第10 页 标，分析这些性能指标及其变化趋势， 而得出那些需要考察性能方面的结论， 能。 判断与系统运行有关的性能情况，从 通过这些结论提出方案来改善软件性 分布式性能测试工具是在分布式软件性能自动化测试过程中所采用的工 具。本文研究分布式软件性能测试技术，为分布式应用软件性能测试设计相 应的测试工具。具体涉及到下面的内容。 本文讨论的分布式性能测试工具考虑和现有的测试管理平台集成，利用 测试管理平台的数据资源。而测试管理平台一般有u i l 对软件系统建模部分。 因此，可以借助u m l 顺序图生成测试用例【l 。 本文的测试工具用v c 开发，主要用于w i n d o w s 系统上软件的测试。在录制 脚本模块中采用w i n d o w s 的a p i 钩子技术。脚本录制的目标是运行待测试程序， 选择相应的协议以a p i 的形式把程序的执行动作记录下来。脚本录制下来后， 工作还没有结束，需要对脚本参数化和脚本定制。 建立测试项目，把录制好的脚本和性能收集器添加到测试项目中，由用 户代理执行这些测试项目，收集性能数据。操作系统本身会提供一套接口函 数，以帮助用户进行收集，w i n d o w s 采用的是p d h ( p e r f o r m a n c ed a t ah e l p e r ) 接口。以性能收集器的形式把这些接口( 或者称性能计数器) 添加到测试项 目中以收集性能指标。并介绍对脚本运行调度和控制参数的设置 3 4 1 。 设计一种脚本上传和数据收集处理的模式。数据处理后显示给测试人员 的形式和分析的方法。 西南交通大学硕士研究生学位论文第11 页 第三章分布式软件性能测试工具设计 下面先讨论测试工具在测试自动化中的地位。然后分析测试工具的测试 流程，根据测试流程概括设计测试工具的结构和功能模块组成。最后规划测 试工具运行的部署环境。这一章为测试工具实现提供总体设计。 3 1 软件测试自动化 软件测试自动化就是测试人员按照预定计划，借助测试工具对软件进行 功能、性能等方面测试。软件自动化测试目的是用自动化测试工具来实现测 试的流水线化，达到在短期内充分测试软件的目标，从而减轻手工测试的劳 动，提高软件质量h 。 在自动化测试过程的某些阶段需要使用测试工具完成自动化测试工作， 测试工具不等同于测试自动化，更不能够期望测试工具涵概自动化测试的方 方面面。通常测试自动化阶段的测试管理工作并不是由测试工具来完成的， 有专门针对测试管理方面的软件。测试工具和测试管理平台集成，相互利用 对方的数据，为对方提供接口，可以更高程度实现测试过程计算机化n 。 本文设计和实现一个分布式软件性能测试工具，下面提到的测试均指分 布式软件性能测试。 3 2 测试工具工作流程 分析测试工具的工作流程，从测试流程中归纳出测试工具的结构和模块 组成，确定这些模块之间的关系。具体测试流程参见图3 1 。下面细述流程 各环节。 测试工具启动进行必要的参数配置或者初始化，测试网络是否连通。 测试工具利用测试管理平台上对软件建模的u m l 顺序图，生成测试用 例。测试用例生成这个部分是测试工具可选的功能，为后面自动生成脚本参 数文件服务。本文提出了一种自动生成测试用例的方法，用r a t i o n a lr o s e 工 具通过u m l 语言对配置项典型场景建模 2 9 】。从r a t i o n a lr o s e 的m d l 文件中 西南交通大学硕士研究生学位论文第12 页 提取出顺序图部分，转化为x m l 表示形式存放到文件中。然后从x m l 格 式表示的文件中解析出测试用例。 调用脚本生成模块录制测试脚本，其步骤是，由测试模块启动待测试程 序，测试人员根据确定的测试用例来操作程序、输入参数，与此同时，测试 工具把待测试程序的行为记录下来，形成测试原始脚本。 原始脚本并不是可执行文件，只是测试工具记录下来的a p i 。为此要经 过a p i 封装和脚本封装，把这些记录转化为可编译执行的高级语言程序代码， 这便是初始脚本。 尽管初始化脚本已经可以用于测试了，但有时候这个脚本并不符合我们 的测试要求。脚本中有许多数值，它们中的很大一部分是与测试用例中要求 的参数对应的( 当然测试人员也可以另外设立自己的参数) 。如果让脚本中每 个参数都给予确定的数值，则脚本只能按照这个模式运行，而无法根据测试 要求动态地改变这些值来执行脚本。所以要把脚本中需要改变的值设置为参 数，参数的值放在一个文件中，脚本运行时读取文件中的数据改变参数值。 对于需要参数化的脚本可由测试人员自行手工编写参数文件，也可以根 据测试用例自动生成。在自动生成过程中，测试工具会对选取的测试用例进 行分析，对那些只给出类型和取值范围的字段，随机生成值，填写到参数文 件中。 对参数化后的脚本进行定制，在脚本中添加输出提示信息或者日志记录 的代码，辅助测试工作，添加分支或者循环控制条件控制脚本运行。 由上面分析可见测试脚本是一个程序文件，这个文件记录了被测试程序 在特定测试用例下的行为，测试过程中执行脚本就可以模拟程序的行为收集 性能参数。为什么不直接调用原程序来收集昵? 首先，调用原程序收集过程 中要根据测试用例手工操作程序，录制不方便，而且由于人为因素的干扰， 给测试结果造成偏差。其次，测试软件本身的性能( 如响应时间) ，必须在代 码中插入采集语句，这对于一个编译好了的可执行文件来说是难以做到的。 最后，采集数据过程中需要记录日志、输出测试信息，也必须在代码中添加 语句。 经过以上步骤工作就得到最终脚本了。测试工具不是单独运行脚本来进 行测试的，而是建立一个测试项目，把脚本添加到其中的任务组中作为一个 任务。测试项目中除了脚本构成的任务组外，还可添加性能收集器进任务组 中作为一个任务，性能收集器里面设置性能计数器，在测试脚本运行过程中 西南交通大学硕士研究生学位论文第13 页 收集并记录性能数据。在测试项目中还要确定诸如任务组的虚拟用户数、启 动时间、结束时间等调度参数，以控制任务组执行。 测试以虚用户为单位，按照参数调度执行。确定需用户线程什么时候启 动，分几批启动，每一批启动的数目，以什么方式结束等。收集器线程在和 脚本线程并发执行中收集性能数据。 基于分布式结构的特点，测试结果文件是分散在多台机器上的，要把这 些文件集中到一台机器上，合并整理这些分散的数据，成为反映系统总体情 况的结果。 测试工具用表格、图表等方式把数据呈现给用户，提供良好的界面，便 于测试人员分析这些结果。 3 3 测试工具框架设计 分布式系统体系结构中的系统、子系统是一个虚拟的概念，运行环境中 实际存在的是一个个独立进行部署和运行的配置项( 进程) ，基于典型应用场 景的系统、子系统执行流程表现为配置项之间的协同执行过程。针对这特 点，分布式性能测试工具设计为由两个子系统构成，一个测试控制台，另一 个是用户代理。测试控制台进行测试的开发和设计，测试控制台把建立好的 测试项目下发到各用户代理，并给用户代理发送控制命令。用户代理接受测 试项目和控制命令，运行测试项目，记录性能指标，测试项目运行结束后， 把记录数据的文件传回测试控制台，由测试控制台统一处理。 把分布式软件测试工具分为两个子系统的设计方案，符合分布式结构这 个特点。配置项分布在许多不同的机器上，把用户代理安装到这些机器上， 分别管理这些机器上配置项的测试，这样就可以减少测试控制台分散过多的 精力处理这些庞杂的工作，测试控制台只通过文件传输和命令下发管理用户 代理，而不直接插手测试运行和性能数据监控与采集工作。简化了系统的设 计，明确分工使得管理上也简便。 分布式性能测试工具总体设计的框架结构见图3 - 2 ，由测试控制台、用 户代理两个子系统组成。根据上一节介绍的测试工具工作流程，经过功能整 合，设计出测试工具系统功能模块。框图内显示了模块的归属和模块之间的 关系。 西南交通大学硕士研究生学位论文第1 4 页 3 - 1 测试工具工作流程图 西南交通大学硕士研究生学位论文第15 页 j _ 9 * | i d 霸风扛i l r j 口 测试用例生成 1r 脚本生成 1 l 测试结果反馈测试建立和配置 一l 1 r 测试结果处理测试调度和执行控制 一l 用户代理 1r 接收指令 j 执行脚本 上 数据收集 1 l i 一 、 i文件上传 1r 被涌试的软件 图3 - 2 系统框架图 为了便于设计，对框架图中的部分模块展开进一步分析。 测试用例生成模块的功能由图3 - 3 所示。 叵三固测篇鬟妹回基珊酬例一 三三司 图3 - 3 测试用例生成模块功能 输入r a t o n a l r o s e 的m d l 文件，提取出其中的顺序图部分，用树结构的 x m l 格式表示顺序图，再从x m l 文件中解析出测试用例。可以把这个模块分 西南交通大学硕士研究生学位论文第16 页 成两个组成部分，一部分是把u m l 顺序图解析成x m l 树表示。另一个部分是 从x m l 树中提取测试用例。 脚本生成模块是由脚本录制、脚本转换、定制脚本和脚本编译这几部分 功能整合而成的模块。模块的构成和关系见下图。 图3 - 4 脚本生成模块构成 脚本生成首先从脚本录制这个模块开始。选择录制的协议，然后根据测 试用例运行被测试程序。在程序运行中通过记录a p i 把程序的行为记录下来。 在记录a p i 模块中使用了w i n d o w sa p i 挂钩技术。 记录下来的a p i 要经过脚本转换模块处理。把这些a p i 封装成脚本中定 义的一套a p i ，形成高级语言函数调用序列。然后通过代码封装，把这些函 数序列代码封装到一个函数中，添加一些辅助语句。运行脚本的时候是把这 个函数放在动态链接库中调用的。 经过转换处理的脚本还要进行定制，包括在脚本中设置检查点收集服务 请求响应时间，添加流程控制、日志记录等语句。在脚本中设置参数，运行 脚本时从参数文件中读取脚本参数。 最后，对脚本进行编译，编译成动态链接库的形式。 西南交通大学硕士研究生学位论文第17 页 3 4 测试工具部署环境 为了更好说明测试工具结构，有必要讨论测试工具是如何部署到测试环 境中的。图3 5 给出了分布式软件性能测试工具的部署环境结构图【8 】。 一 待测试的系统 3 - 5 测试工具部署结构图 测试控制台，部署在一台测试服务器中，负责测试用例生成、脚本开发、 测试配置、测试调度、控制用户代理和数据处理等工作。 代理客户端，可部署在没有安装待测软件的代理客户端机器上，也可部 署在安装有被测试软件的客户端和服务器上。 在服务器上运行被测试软件的服务器端，然后在测试控制台上启动客户 i。i。1ii。i。一 西南交通大学硕士研究生学位论文第1 8 页 端录制脚本。建立和配置好测试后，控制台会根据调度参数把脚本下发到相 应的测试代理，给测试代理发送控制命令。 测试代理以虚用户为单位，根据参数调度运行脚本收集性能数据并记录 在结果文件上。测试执行完毕后，把结果文件上传到测试控制台，并发送命 令告诉控制台测试运行结束。 测试控制台发现各测试代理上的测试完成后，便合并这些结果文件，对 数据进行综合处理。最后，把结果以图表等友好界面的方式反馈给用户。 西南交通大学硕士研究生学位论文第19 页 第四章测试用例生成模块 进行分布式软件性能测试首先根据测试的要求和特点分析测试涉及到的 配置项，对配置项进行u m l 建模，在此基础上生成测试用例。本文中，提 出基于切v i i 。顺序图生成测试用例以达到提高测试自动化程度，是对测试工 具研发的一个探讨。生成的测试用例在脚本参数化阶段可用来生成脚本参数 文件。在生成测试用例的时候测试工具也可以利用测试管理平台上对软件建 模的u v l l 资源。 4 1 基于u m l 对配置项建模 用自然语言描述测试用例显然难以准确无异义地对其严格定义，也不适 合进行自动化。为此可选用切儿语言来形式化描述。 统一建模语言( u 沮。) 是一个通用的可视化建模语言，用于对软件进行 描述，可视化处理，构造和建立软件系统制品的文挡。它是面向对象软件系 统建模的工业标准，眦模型在测试自动化方面有着很大的应用潜力，基于 眦的软件测试是基于规格说明的软件测试的一个分支，其最大优点就是它 比其他形式化方法具有更为广泛的适用性。在软件开发的各个阶段，通过将 系统的分析，设计和实现等工作转化为眦( 或是i m ，的扩展) 的规格说 明，并把它们作为测试需求的直接来源，驱动测试整个过程。因此我们基于 u m l 2 0 规范，使用顺序图模型对典型应用场景建模，顺序图描述了系统中 对象交互。在顺序图中，典型应用场景被定义为在相互交互过程中的各对象 间传递的一个消息序列，每个消息序列代表一个可能的事件流。通过解析顺 序图模型文件生成测试用例。 对分布式应用典型场景进行建模，解析应用场景模型文件，提取出该场 景的条件约束、对象状态等语义信息来自动生成测试用例。所以在进行场景 建模时需要综合考虑该模型的可测试性。模型可测试性是指，仅用模型中给 出的信息，设计和实现一定的算法来产生就绪运行的测试用例的难易程度。 可测试的模型应当既支持手工生成测试用例又支持自动生成测试用例。一个 可测试的模型需要满足以下要求【2 j ：( i ) 它应该完整而准确地反映被测系统， 并描述了要测试的所有功能特性。( 2 ) 它是对细节的抽象，这些细节会使得测 西南交通大学硕士研究生学位论文第2 0 页 试成本过分高昂。( 3 ) 它保留被测系统中有助于发现错误和验证系统一致性的 关键细节。( 4 ) 对状态模型而言，它描述了所有的事件、动作和状态，并对各 状态进行了明确定义。 u m l 语言能够准确、详细地描述应用场景，符合上述模型可测试性的要 求。结合分布式软件测试，通过分析所涉及到的场景建立u m l 模型，便可 从中分解出测试用例。 让我们来研究一个销售系统，这个系统有一个服务器，许多由它提供数 据和服务的客户端系统，如前台收款系统、财务系统、进货系统等，其中自 动饮料销售系统安装在饮料销售机上，也是其中一个客户端系鲥2 7 1 。在这里 我们的测试只涉及到自动饮料销售系统跟服务器之间的性能，而自动饮料销 售系统可以独立部署运行，可以作为一个配置项来对待。下面对它进行详细 分析建模。 自动饮料销售机有三部分：前端( f r o n t ) 、钱币记录仪( r e g i s t e r ) 负责收 集顾客投的钱币，以及分配器( d i s p e n s e r ) 。 前端的功能： ( 1 ) 接收顾客的选购和现钞。 ( 2 ) 显示诸如o u to f s e l e e t i o n ( 所选饮料已售完) 、u s ec o r r e - tc h a n g e ( 使 用合适零钱) 的信息。 ( 3 ) 从记录仪接收找回的零钱并返还给顾客。 ( 4 ) 返还现钞。 ( 5 ) 从分配器接收一罐饮料并把它交给顾客。 钱币记录仪的功能： ( 1 ) 从前端获取顾客输入信息：选购的饮料种类和现钞。 ( 2 ) 更新现钞存储。 ( 3 ) 找零钱。 分配器功能： ( 1 ) 检查选购的饮料是否还有货。 ( 2 ) 分发一罐饮料。 饮料销售机是这三个部分的组合，建立类图反映配置项的构成和各组成 部分的关系，具体见图4 1 自动饮料销售机的类图。 类图只是对配置项构成的静态描述，无法反映其各部分间消息传递的动 态特征，而测试用例是对这些特征的具体反映。顺序图提供了一种动态视角， 西南交通大学硕士研究生学位论文第2 1 页 展示消息从一个实体传递到另一个实体。顺序图强调消息的时间顺序