（通信与信息系统专业论文）一种web系统性能的脚本测试方法的研究和应用.pdf

摘要 随着w e b 应用技术的发展和w e b 应用程序的迅速普及，w e b 系统的性能和 服务质量显得越来越重要。对某些企业和用户来说，性能甚至比许多功能都更为 重要，比如一个电子商务网站的性能瓶颈将严重制约该企业业务的发展，甚至可 能毁掉企业形象。w e b 系统性能测试是一个w e b 系统开发应用过程中非常重要 的一个环节。 软件测试技术的发展已经有较长的一段历史，而自动化测试技术又是现阶段 软件测试的研究热点。w e b 应用软件是当前各种应用软件发展的主流，因此w e b 测试技术受到了越来越多的关注。但是与传统软件测试相比，w e b 应用测试仍然 是一个鲜有涉足的领域，常常依赖于专门的测试过程。 w e b 应用软件具有异构、分布、并发和平台无关的特性，外在的需求和内在 的复杂性使得对w e b 应用软件的测试要比传统应用程序的测试更加困难，这给 软件测试带来新的挑战。对w e b 测试来说，深入分析和理解h t t p 协议是必不 可少的。本文所提出的自动化w e b 性能测试就是在对h t t p 协议分析基础上的 一种脚本测试法。 w e b 性能从不同的角度采用不同的度量标准。本文在一般常用的测试度量指 标基础上重点突出两个与具体业务相关的最主要的两个指标响应时间和吞 吐率。针对吞吐率，我们采用t p m ( t r a n s a c t i o n sp e rm i n u t e ，每分钟业务数) 作 为衡量w e b 系统一项具体业务的度量指标。然后给出w e b 性能测试的基本步骤。 本文中测试方法的应用是以某大型金融企业电子商务平台为背景的，处于系 统开发已经基本完成阶段，测试研究的重点在于w e b 系统性能方面的测试，所 谓的性能更多地是从相关业务角度来说的。这里引入了一种不同于传统测试工具 的自动化性能测试方法脚本测试法，使用当前流行的脚本语言p y t h o n 加以 实现。 关键词：w e b 性能测试；软件测试；自动化测试；h t t p 协议分析；脚本测 试 a b s t r a c t t h ep e r f o r m a n c ea n ds e r v i c eq u a l i t yo faw e bs y s t e mb e c o m em o r ea n dm o r e i m p o r t a n ta l o n g w i t ht h e d e v e l o p m e n t o fw e ba p p l i c a t i o nt e c h n o l o g ya n d p o p u l a r i z a t i o no fw e ba p p l i c a t i o nr a p i d l y p e r f o r m a n c ec a r tb em o r ei m p o r t a n tt h a n f u n c t i o n st os o m ee n t e r p r i s e sa n du s e r s f o re x a m p l e ，t h ep e r f o r m a n c eb o t t l e n e c ko f a ne - c o m m e r c ew e bs i t ew o u l dr e s t r i c tt h ed e v e l o p m e n ta n di n c r e a s eo f t h ee n t e r p r i s e ， a n de v e nd e s t r o yt h ei m a g eo ft h i se n t e r p r i s ep o s s i b l y w e bp e r f o r m a n c et es t i _ n gi sa v e r yi m p o r t a n ts t e pi nt h ep r o c e s so f aw e bs y s t e md e v e l o p i n ga n di m p l e m e n t i n g i ti sal o n gh i s t o r ys i n c es o f t w a r et c s t i n gt e c h n i q u e sb e g a nt oa p p e a ra n d d e v e l o p t o d a ya u t o m a t i ct e s t i n gt e c h n i q u ei sah o ta r e ai nr e s e a r c ho fs o f t w a r e t e s t i n ga n dw e ba p p l i c a t i o ni sp r e v a l e n ti na l lk i n d so fa p p l i c a t i o n s ，s ot h e r ei sa g r o w i n gc o n c e ma b o u tw e bt e s d n gt e c h n i q u e s b u tc o m p a r e d t ot r a d i t i o n a ls o r w a r e t e s t i n g ，w e ba p p l i c a t i o nt e s t i n gi sa l m o s ta l lu n e x p l o r e da r e aa n du s u a l l yr e l i e ss o l e l y o na dh o ct e s t i n gp r o c e s s e s w e ba p p l i c a t i o nh a ss o m es p e c i a l i t i e ss u c ha sh e t e r o g e n e i t y , d i s t r i b u t i o na n d c o n c u r r e n c e t h ed e m a n df r o mo u t s i d ea n dt h ec o m p l e x i t yi n s i d em a k ei tm o r e d i f f i c u l tt o t e s tw e ba p p l i c a t i o nt h a nt r a d i t i o n a la p p l i c a t i o n ，w h i c hb r i n g sn e w c h a l l e n g eo ns o f t w a r et e s t i n g i ti sn e c e s s a r yt ou n d e r s t a n da n da n a l y z eh t t p p r o t o c o ld e e p l yf o rw e bt e s t i n g t h ea u t o m a t i cw e bp e r f o r m a n c et e s t i n gi nt h i s p a p e r i sa k i n d o f s c r i p t t e s t i n g m e t h o d o n b a s i s o f h t t p p r o t o c o l a n a l y s i s d i f f e r e n tw e bp e r f o r m a n c em e t r i c sw i l lb ea d o p t e di nd i f f e r e n ta s p e c t s t h i st w o m e t r i c sw h i c hr e l a t et os p e c i f i cb u s i n e s s - r e s p o n s et i m ea n dt h r o u g h p u t 一一a i h i g h l i g h t e di nt h i sp a p e ro u to fo t h e rc o m m o nm e t r i c s w ea d o p tt p m ( t r a n s a c t i o n s p e rm i n u t e l 嬲am e t r i ct oe s t i m a t et h es p e c i f i ct r a n s a c t i o np r o c e s s i n gp e r f o r m a n c e t h e nt h eb a s i cp r o c e s so f w e bp e r f o r m a n c et e s t i n gi sg i v e n i nt h i sp a p e r , t h ea p p l i c a t i o no ft e s t i n gm e t h o di so nt h eb a c k g r o u n do f e - c o m m e r c ep l a t f o r mo fal a r g ef i n a n c i a le n t e r p r i s e ，a n dt h es y s t e md e v e l o p m e n th a d b e e nf i n i s h e d t h ee m p h a s i so f t e s t i n gr e s e a r c hi so nw e b s y s t e mp e r f o r m a n c et e s t i n g w h i c hi si n c l i n e d 幻c o n c e r n e db u s i n e s s h e r ew ei n t r o d u c eak i n do fa u t o m a t i c p e r f o r m a n c et e s t i n gm e t h o dw h i c hc a l l e ds c r i p tt e s t i n ga n di sd i f f e r e n tf r o m t r a d i t i o n a lt e s t i n gt o o l s t h i sm e t h o di sr e a l i z e db yu s i n gc u r r e n tp o p u l a rl a n g u e 一一 p y t h o n k e yw o r d s ：w e bp e r f o r m a n c et e s t i n g ；s o f t w a r et e s t i n g ；a u t o m a t i ct e s t i n g ； 2 h t t pp r o t o c o la n a l y s i s s c r i p tt e s t i n g 第1 章前言 1 1 研究背景 近年来，i n t e m e t 上的w e b 应用增长非常迅速，因而它们的服务质量和可靠 性也受到越来越多的关注。w e b 应用测试仍然是一个几乎未有涉足的领域，常常 依赖于专门的测试过程。目前还没有完全适用于w e b 应用测试的软件测试方法。 w e b 应用具有多样性和复杂性，如果不理解这种应用就很难有效地设计出测试案 例和测试数据，尤其是当设计文档不足的时候。而当前w e b 应用软件的种类和 数量不断增加，软件开发周期缩短，软件规模扩大，软件复杂性增加，软件质量 问题越来越重要 2 6 1 。 由于w e b 应用软件具有异构、分布、并发和平台无关的特性，外在的需求 和内在的复杂性使得对w e b 应用软件的测试要比传统应用程序的测试更加困难， 这给软件测试带来新的挑战。 当前的企业正越来越多地将它们的业务放在w e b 平台上，以便可以同所有 i n t e m e t 上的用户都可以方便地处理有关的业务。这对拓展公司业务、降低运营 成本、方便用户以及宣传企业形象等方面非常重要。尤其对于金融企业来说，如 今网上交易已经流行和普及，w e b 交易平台的好坏直接影响到公司业务和经营状 况，而且这种影响有时候甚至是决定性的。 在互联网业界，存在着互联网的“8 秒钟”现象，即3 5 的用户在等待8 秒钟 后放弃交易，8 0 的用户在等待1 2 秒后放弃交易。据统计，在2 0 0 1 年，由于缓 慢的下载和丢包造成的在线交易损失超过2 5 0 亿美元；即使对于压力较小的网 站，因为普遍存在的服务器连接容量限制现象，用户需要更多的时间建立连接， 交易请求的响应速度也相应地变得缓慢【7 】。另据z o n a 的一份研究报告的数据统 计：页面的下载时间减小1 秒，用户的放弃率从3 0 下降到6 8 ；由于性能 问题，超过3 4 的用户没有从最初访问的网站购买商品，而其中的2 1 后来从 别的网站购买了商品。 本研究是基于某大型金融企业电子商务平台为背景的，处于系统开发已经基 本完成阶段，测试研究的重点在于w e b 系统的性能方面测试，所谓的性能更多 地是从相关业务角度来说的。 1 2 本论文的主要工作 通过对h t t p 协议的研究分析和对w e b 系统架构的深入认识，结合软件自 动化测试的理论，通过大量试验并结合对某大型企业的w e b 系统测试的测试实 4 践，研究总结出适用于w e b 自动化性能测试的方法，使用属于自由软件的协议 分析工具和当前流行的脚本语言p y t h o n 加以实现。 w e b 性能从不同的角度采用不同的度量标准。这里我们从最基本的两个方面 考虑：从访问w e b 系统的用户角度看，他们关心的是系统响应时间；从系统管 理员或w e b 系统所属机构来看，他们既要关注系统响应时间问题，又要关注系 统的吞吐率问题。因而，本文选择响应时间和吞吐率作为研究w e b 系统测试的 两项主要指标。 另外，系统的功能和性能还表现出一定的相关性。比如在进行强度测试时， 高负载可能导致系统功能的异常。如果使用传统的测试工具进行性能测试，则很 难发现这种系统功能上的错误或异常的细节。但在基于h t t p 协议分析的脚本测 试中，由于可以随时得到w 曲会话返回页面的具体内容，因而容易定位系统的 问题所在，这对系统性能的改进及功能的调整非常有力。 第2 章软件测试及自动化理论 2 1 软件测试的必要性 随着现代社会信息技术的飞速发展，软件产品在社会中的各个领域都得到了 广泛的应用，软件与人们的生产和生活息息相关，软件产品的质量自然成为人们 共同关注的焦点。不论软件的生产者还是软件的使用者，都生存在竞争的环境中， 软件质量的好坏对他们都具有极其重要的意义。作为软件生产者的软件开发商为 了占有市场，必须把产品质量作为企业的重要目标之一，以免在激烈的竞争中被 淘汰出局。而作为软件使用者的用户为了保证自己业务的顺利完成，当然希望选 用功能满足要求且质量可靠的软件。质量不佳的软件产品不仅会使开发商的维护 费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成公司信誉下 降，业务及客户流失，甚至给软件使用者的正常业务带来致命打击。在一些关键 应用中使用质量有问题的软件，还可能造成灾难性的后果。 事实上，不论采用什么软件开发技术和开发方法，软件中的错误或漏洞总是 难免的。因为软件是由人来完成的，所有由人做的工作都不会是完美无缺的，而 且当多人合作来完成一件事的时候就更容易产生差错和漏洞。采用新的程序设计 语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完 全杜绝软件中的错误，这些引入的错误需要通过测试来找出，软件中的错误密度 也需要测试来进行估计。 进入2 0 世纪6 0 年代，面对愈来愈复杂的大型软件系统开发，出现了“软件 危机”1 4 ，如要表现如下： 软件项目经常无法按期完成，超出经费预算，软件质量难以控制； 开发人员及开发过程之间管理不规范，约定不严密，文档书写不完整， 使得软件维护费用高，有些系统甚至无法进行修改； 缺乏严密的质量检测手段，交付给用户的软件质量差，在运行中出现许 多问题，甚至带来严重的后果； 系统更新换代难度大。 1 9 6 8 年，在北大西洋公约组使得学术会议上第一次创造了“软件工程”这 个词，倡导按照工程化的原则和方法组织软件开发工作。表2 - 1 显示了软件工程 的各个阶段及各阶段的基本情况。 表2 - 1 软件工程各个阶段的基本情况 6 阶段 基本任务工作结果占开发期的参加者 工作量 需求分析理解和表达用 系统说明书2 0 用户、高级程 开发期户的要求、对开序员 发的软件进行 详细的定义 设计建立系统的结模块说明书、1 5 高级程序员 构框架和逻辑数据说明 程序编写 写程序 程序2 0 高级程序员、 初级程序员 测试发现错误和排可运行的系4 5 ( 其中模测试部门 除错误统 块测试2 5 ， 其他测试 2 0 ) 运行期运行与维护期维护改进的系统 用户、程序员 从表2 1 可以看出软件测试在开发期占有非常突出的位置，工作量和开销要 占一半左右。 此外，如今的软件系统的规模变得越来越大，结构也越来越复杂，而从头开 始构建的大系统数量在急剧地减少，很多既存系统正在被逐步地利用。越是庞大、 历史悠久的系统，特别是使用计算机较早的一些重要应用领域如银行、证券、物 流乃至政府、军用部门等，它们沉淀的历史遗产就越雄厚，价值越高，因此就越 不能轻易淘汰。在这一背景和需求下，软件工程进入再工程时代，这种再工程是 对一次工程后的成品软件再次进行开发。软件维护期的适应性、完善性、预防性 维护都属再工程范畴。软件工程和再工程的比例及发展趋势如图2 1 所示。 图2 1 软件工程中一次工程和再工程的比例趋势图 从图2 1 可以看出，软件再工程已经占到软件工程的8 0 左右。而在软件再 工程中，测试过程成为软件再工程的最大瓶颈。软件测试的工作量和成本在软件 开发总工作量和总成本中占有的比例还要增加，如图2 2 所示，达到近6 5 。 一次工程 分析设计实现测试 2 0 1 5 2 0 4 5 | 厂 1 分析 设计实现测试 1 0 1 0 1 5 6 5 再工程 图2 - 2 软件开发过程各阶段一次工程和在工程工作量对比 软件测试( s o f t w a r e t e s t i n g ) 是发现软件中错误和缺陷的主要手段，对于查 找软件缺陷、保证软件产品质量、提高企业效益和改善企业形象具有非常重要的 作用；测试是软件工程过程的一个重要环节，是在软件投入运行前，对软件需求 分析、设计和编码各阶段产品的最终检查，是为了保证软件开发产品的正确性、 完整性和一致性，从而验证软件功能与性能并检测与修正软件错误的过程。软件 开发的目的是开发出满足用户需求的高质量、高性能的软件产品，软件测试以检 8 查软件产品内容和功能特性为核心，是软件质量保证的关键步骤，也是成功实现 软件开发目标的重要保障。 w e b 的出现不仅是互连网络的一次革命，也是软件领域的一次革命，它使得 软件的价值得到了更大程度的体现。w e b 系统和w e b 应用软件往往比传统软件 的使用面更广，用户更多，承担着多更重要的任务，因此对w e b 软件的测试显 得更为重要，整个测试过程相对也更加复杂。 2 2 软件测试基本理论 2 2 1 软件测试的定义 g j m y e r s 关于软件测试的观点至今仍被许多人引用【1 3 】，那就是： 软件测试是为了发现错误而执行程序的过程； 测试是为了证明程序有错，而不是证明程序无错误； 个好的测试用例是在于它能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 这种观点一直为广大的软件测试人员所认可。不过软件测试不仅仅是简单的 程序执行过程，除了动态的软件测试过程之外，它还包括代码审查、代码走读等 静态测试的内容。从广义的角度来看，软件测试还应该包括测试环境准备，测试 文档编写等活动。 在许多有关软件测试的经典书籍都可以查到有关软件测试的定义，尽管各不 相同，但一般来说可以概括为：软件测试是软件生命周期中的一个过程，是为了 发现错误而检查程序代码和执行程序的过程。软件测试的主要目标就是尽可能多 地发现软件表面和潜在的不同类型的错误，并且尽可能耗费较少的时间和工作 量。 随着w e b 应用技术的发展，如今越来越多的软件通过w e b 方式来工作，但 关于传统软件测试测定义仍然可以用到w e b 软件测试的领域。 2 2 2 软件测试的方法 对软件产品，通常可以用两种方法对其进行测试。 白盒测试( w h i t e - b o xt e s t i n g ) 白盒测试又叫做结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程 序界的严密检查，针对特定条件和循环及设计测试用例，对软件的逻辑路径进行 测试。它可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分 是否己经通过检查。 白盒测试一般又分为静态测试与动态测试。静态测试不实际运行软件，主要 是对软件的编程格式、结构等方面进行评估，而动态测试需要在实际环境或实验 9 室模拟环境中实际运行软件，并使用设计的测试用例去探测软件漏洞。 其中的静态测试主要包括代码检查、代码走读、静态结构分析和代码质量度 量等。动态测试主要包括功能确认与接口测试、覆盖率分析和性能瓶颈分析以及 内存分析等。 黑盒测试( b l a c k b o xt e s t i n g ) 黑盒测试是在已知软件的功能设计规格的前提下进行的测试，主要用于验证 每个实现了的功能是否符合要求，黑盒测试又叫做功能测试。它不仅用于开发阶 段的测试，更常用于产品或系统的测试阶段及维护阶段。用这种方法进行测试时， 被测程序被当作看不见内部的黑盒，在完全不考虑程序内部结构和内部特性的情 况下，测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正 确性。 要完整测试验证“任何情况”是做不到的。为此黑盒测试也有一套产生测试 用例的方法，以产生有限的测试用例而覆盖足够多的“任何情况”。由于黑盒测 试不需要了解程序内部结构，所以许多高层的测试如确认测试、系统测试、验收 测试都采用黑盒测试。 由于黑盒测试是功能性测试、数据驱动测试或基于规格说明的测试，是一种 从用户观点出发的测试。对黑盒测试一般有如下基本要求： 1 ) 每个软件特性必须被一个测试用例或一个被认可的异常所覆盖； 2 ) 用数据类型和数据值的最小集测试； 3 ) 用一系列真实的数据类型和数据值运行，测试超负荷、饱和及其他“最 坏情况”的结果； 4 ) 用假想的数据类型和数据值运行，测试排斥不规则输入的能力： 5 ) 针对影响性能的关键模块，如基本算法，应测试单元性能( 包括精度、 时间、容量等) 。 6 ) 不仅要考核“程序应该做什么”，还要考察“程序是否做了不该做的”， 同时还要考察程序在其他一些情况下是否正常。这些情况包括数据类型和数据值 的异常等等。 黑盒测试常用的方法主要有：等价类划分、因果图方法、编制分析法、猜错 法和随机数法等。这几种方法是从更广泛的角度来进行黑盒测试。每一个方法都 力图能涵盖更多的“任何情况”，但又各有长处，综合使用这些方法，可以得到 一个较好的测试用例集。 黑盒测试的基本内容有：功能错误或遗漏、输入和输出接1 2 1 的正确性、数据 结构或外部信息访问错误、性能要求的实现情况以及初始化或中止性错误等。 这两类测试方法是从完全不同的起点出发，并且是两个对立的出发点，可以 i o 说反映了事物的两个极端。两类方法各有侧重，在测试的实践中都有各自的优点 和效用。一般地说，在进行单元测试时大都采用白盒测试，而在产品确认测试或 系统测试中大都采用黑盒测试。从测试方法看，本论文讨论和研究的w e b 性能 测试基本上都属于黑盒测试的范畴。 2 2 3软件测试的种类 通常情况下，一般意义上的软件测试主要分为以下几类【9 】： 功能测试 功能测试是用来检查软件所提供的服务，验证能否正常按照它的设计来工 作。例如添加一个用户帐号、查询列车时刻等。在商业应用中一个最重要的功能 测试是有关数据库的事务处理能力的测试。 强度测试 强度测试主要是针对该软件运行时的实际处理能力所作的测试，这个测试包 括大批量数据测试、长时间处理能力测试和异常情况测试等，以检验系统能力的 最高实际限度。强度测试有时候又称为极限测试。 极限强度测试总是迫使系统在异常的资源配置下运行。比如：当中断的正 常频率为每秒5 次的时候，运行每秒产生5 0 次中断的测试用例；定量地增长 数据输入率直至一个数量级以上来测试输入功能会如何响应；运行需要最大存 储空间或其他资源的测试用例；运行可能导致虚存操作系统崩溃或磁盘数据剧 烈抖动的测试用例；一个w e b 站点在不断增长的大量的负荷下，系统的响应 何时会退化或失败等等。 性能测试 对于那些实时系统或存在多用户并发使用的w e b 应用系统，软件部分即使 满足了功能要求，也未必能够满足性能要求。虽然从单元测试起，每一测试步骤 都包含性能测试，但只有当系统真正集成之后，在真实的现场使用环境中才能全 面、可靠地测试运行性能。系统性能测试就是为了完成这一任务的测试。 性能测试需要与极限测试相结合，经常需要其他软硬件的配套支持。 性能测试的结果将用来衡量系统的响应时间、事务处理速度和其他时问敏感 的需求，并能测出与性能相关的工作负载和硬件配套条件等。 安全测试 安全测试的目的在于验证安装在系统内的保护机制能够在实际中保护系统 不受非法入侵和各种非法的干扰。系统的安全测试要设置一些测试用例试图突破 系统的安全保密措施，检验系统是否有安全保密的漏洞。 安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例 如：想方设法截取或破译口令；专门定做软件破坏系统的保护机制；故意导致系 统失败，企图趁恢复之际非法进入；试图通过浏览非保密数据推导或推测所需信 息等等。 从理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安 全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法入侵者将 因无利可图而放弃。此外也要综合考虑信息保护的代价等因素。 用户界面测试 主要检查用户与软件之间的交互能力，分析软件用户界面的设计是否合乎用 户期望或要求。比如：用户可否达到全部有权访问的功能界面；g u i 对象操作是 否与用户要求相符；界面是否符合企业或行业标准等。 安装卸载测试 安装测试有两个目的，一是确保软件在各种条件下能正确安装，例如初次安 装、升级、完全安装和用户定制安装。二是检查软件安装之后操作的正确性。为 达到这个目的一般是运行一些为测试软件功能而编写的程序。 恢复测试 恢复测试主要检查系统的容错能力，系统在软硬件故障后保存数据和控制并 进行恢复的能力。或者当系统出错时，能否在指定时间间隔内修正错误并重新启 动系统。 恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢 复。对于自动恢复需验证重新初始化( r e i n i t i a l i z a t i o n ) 、检查点( c h e c k p o i n t m e c h a n i s m s ) 、数据恢复( d a t ar e c o v e r y ) 和重新启动( r e s t a r t ) 等机制的正确性；对于 人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。 文档测试 文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述，测 试应检查各阶段文档的合适性。评审文档质量的度量标准有以下六条：完备性： 所有承担软件开发任务的单位，都必须按照标准的规定编制相应的文档，以保证 在开发阶段结束时起文档是齐全的。正确性：在软件开发各个阶段所编写的文 档的内容，必须真实地反映该阶段的工作且与该阶段的需求相一致。简明性： 在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确、简练，适合 各种文档的特定读者。可追踪性：在软件开发各个阶段所编写的各种文档应该 具有良好的可追踪性。文档的可追踪性包括纵向可追踪性与横向可追踪性两个方 面。前者是指在不同文档的相关内容之间相互检索的难易程度；后者是指确定统 一文档某一内容在本文档中的涉及范围的难易程度。自说明性：在软件开发各 个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件 开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品能力。规 范性：在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规 范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。 一致性：在软件开发各个阶段所编写的各种文档应该具有较好的一致性，不能 出现前后不一致的情况。 健全测试 典型的是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以 执行下一步的测试。例如，如果一个新版软件每几分钟与系统冲突，使系统陷入 瘫痪，说明该软件不够健全，目前不具备进一步测试的条件。 衰竭测试 软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测 试，尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。 比较测试 与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。 本论文中讨论和实践的测试以w e b 性能测试为主，既然是性能测试当然也 很容易就会涉及到强度测试。此外也少量涉及到了功能测试和用户界面测试等方 面。 2 2 4 软件测试的原则 在设计有效的测试用例之前，软件工程师必须全面了解软件测试的基本原 则。这些基本原则包括 1 6 1 ： 所有的测试都应追溯到用户需求。正如我们所知，软件测试的目标在于 揭示错误，而最严重的错误( 从用户角度来看) 是那些导致程序无法满足需求的 错误。 应该在测试工作真正开始前的较长一段时间内就进行测试计划设计。测 试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确 定后立即开始。因此，所有测试可以在任何代码被产生前进行计划和设计。 p a r e t o 原则应用于软件测试【2 0 】。简单地讲，p a r c t o 原则暗示着测试发现 的错误中的8 0 很可能起源予2 0 的程序模块中。当然，问题在于如何孤立 这些有疑点的模块并进行彻底的测试。 测试应从“小规模”开始，逐步转向“大规模”。最初的测试通常把焦点 放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最 后在整个系统中寻找错误。 穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量 也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序 逻辑，并确保程序设计中使用的所有条件是有可能的。 为了达到最佳效果，应该由独立的第三方来构造测试。“最佳效果”指最 有可能发现错误的测试( 测试的主要目标) ，所以创建系统的软件工程师并不是 构造软件测试的最佳人选。 软件测试应该遵循尽快执行和重复测试的原则。 2 2 5 软件测试的阶段 软件测试主要可以分为单元测试( u n i tt e s t ) ，集成测试( i n t e g r a t i o n t e s t ) ，系统测试( s y s t e mt e s t ) ，a l p h a 、b e t a 测试等阶段【9 。 单元测试 单元测试是代码阶段最早期进行的测试，是面向软件设计中最小的可测试单 位软件组件，它是进行正确性检验的测试工作，也是软件开发过程中的一种 技术性行为。单元测试应用于软件模块或函数，检查程序的控制流和数据流，其 目的在于发现各模块内部可能存在的各种差错和检查每个程序模块和模块组的 功能是否达到设计要求。 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独 立进行单元测试。 单元测试需要结构化的白盒测试技术和功能化的黑盒测试技术，一般由开发 人员和q a 组完成。 在该阶段我们主要关注软件的可靠性和稳定性，然后是软件的运行性能。测 试的内容包括模块接口、局部数据结构、边界条件、覆盖条件、出错处理等。 集成测试 在单元测试的基础上将模块组装成子系统或系统，测试各单元之间的互操作 性，以及系统完成的功能与设计目标的距离。这是一个随集成程度的不断提高而 迭代进行的过程。组成系统的各单元常常来自于不同的开发部门，不完整的或错 误单元将在集成测试中暴露出来。像单元测试一样，集成测试也是由开发部门或 q a 组来完成，在集成测试中可能用到白盒和黑盒测试技术。 系统测试 用户需求测试，根据用户的实际环境对已经集成好的软件系统进行系统测 试。系统测试是在具备整体功能的软件上进行的，是软件产品在验收出厂和正式 递交给用户使用前必须进行的一种测试行为。它包括从最终用户的角度检查系统 的功能，由开发组织或最终用户完成。如系统测试由用户进行，也称作验收测试 其目的是检验最终产品与预期目标间的吻合情况。在系统测试阶段主要采用黑盒 测试法( b l a c k b o x t e s t ) ，按照客户提出的需求和系统目标确定测试范围和设计测 试方案。 系统测试的内容是测试该构造是否达到了系统需求和功能规格说明中的要 1 4 求，一般需要进行功能测试、性能测试、外部接口测试、人机界面测试、强度测 试、冗余测试、可靠性测试、安全性测试、恢复测试等。 a 1 2 p h a ，b e t a 测试 事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用 户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了 的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用 户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、 有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延 期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称 为a l p h a 、b e t a 测试的过程，以期发现那些似乎只有最终用户才能发现的问题。 a l p h a 测试是指软件开发公司组织内部人员模拟各类用户行对即将开发完成 的软件产品( 称为a l p h a 版本) 进行测试，试图发现错误并修正。a l p h a 测试的 关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努 力涵盖所有可能的用户操作方式。经过a l p h a 测试调整的软件产品称为b e t a 版 本。紧随其后的b e t a 测试是指软件开发公司组织各方面的典型用户在日常工作 中实际使用b e t a 版木，并要求用户报告异常情况、提出批评意见。然后软件开 发公司再对b e t a 版本进行改错和完善。 在本论文中我们讨论的测试基本上不涉及单元测试和集成测试的部分，而是 系统开发基本完成后对一个功能基本健全的可运行w e b 系统的测试，可以说是 处于系统测试阶段或a l p h a 、b e t a 测试阶段。测试并非直接针对代码，而是针对 w e b 应用软件具体相关的业务流程来进行。 2 2 6 软件测试的过程 简单地说，软件测试过程经历以下几个环节：测试准备( 包括测试计划编写、 测试方案编写、测试用例设计和测试环境搭建) 、测试执行和测试报告编写。有 时候，这几个过程里的某些环节可以是交错或重叠或反复进行的。 2 3 自动化软件测试 2 3 1 适合自动化的活动 软件测试的工作量很大( 据统计，会用到4 0 的开发时间：一些可靠性要 求非常高的软件，测试时间甚至占到总开发时间6 0 ) ，但测试却是在整个软件 过程中极有可能应用计算机进行自动化的工作，原因是测试的许多操作是重复性 的、非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完 成这些任务。企业在这方面的投资，会对整个开发工作的质量、成本、和周期带 来非常明显的效果。 2 3 2 软件测试自动化的需求 今天的软件经理和开发人员需要不断紧缩产品周期并试用最少的资源。9 0 以上的开发人员耽误了交货日期。对于6 7 以上的开发人员来说，错过最后期限 已经是司空见惯的事。此外，9 1 的开发者为了赶上最后期限不得不在开发周期 后期取消某些关键功能。s t a n d i s h 集团的一份报告提供了类似的结果。产品投放 市场的早晚可能就意味着产品的生或死，由此也可能就决定了公司的生死存亡 1 7 】。 商务和政府机构也面临着降低成本的压力。解决这一问题的主要途径包括借 助应用软件使业务流程进一步自动化和流水线化。负责应用程序开发的业务经理 和政府领导不希望等一年或更长时间才看到一个可运行的产品：为此，他们制定 软件开发工作规范，旨在缩短开发进度，这常常需要增加软件构件。尽管这些增 加后的软件版本为用户提供了一些可看可用的切实的东西，但是将某一软件构建 版本与后续版本结合的需求将增加测试的工作量和复杂度。 一些企业在尝试低耗高效工作时想在短时间内充分测试它们的软件。为了达 到这一目标，这些企业转向了自动化测试。 2 3 3 自动化测试的定义 自动化测试的一般定义为：各种测试活动的管理与实施，包括测试脚本的开 发与执行，以便使用一种自动化测试工具来验证测试需求。测试活动自动化在许 多情况下可以提供其最大价值，如测试脚本被重复的地方或测试脚本子程序被生 成而后被许多测试脚本重复调用的地方。在开发和集成阶段( 其中可重用脚本可 能运行很多次) ，这种测试有很高的回报f 4 】。 或者说，“自动化测试”就是使用软件工具来代替手工进行的一系列动作。 通常是使用脚本或其他代码驱动应用程序【2 】。这一切可以通过可视用户界面( 如 浏览器) 来完成，也可以通过直接命令( 从客户端发向服务器，以模仿浏览器发 送的命令) 完成。自动化测试将毫无差错地以同一方式多次运行同一测试，但自 动化测试不会执行与脚本编写内容不一样的行为。 1 6 3 1h t t p 协议 第3 章w e b 系统 3 1 1h t t p 协议的基本原理 h t t p 是w e b 应用系统的重要协议，是w e b 工作的基础，它是从客户机服 务器模型发展起来的。客户机服务器是运行一对相互通信的程序，客户与服务 器连接时，首先，向服务器提出请求，服务器根据客户的请求，完成处理并给出 响应。浏览器就是与w e b 服务器产生连接的客户端程序，它的默认端口为t c p 的8 0 端口。浏览器与w e b 服务器之间的通信遵循h t t p 协议。它的第一个版本 是h t t p 0 9 ，然后被h m 1 0 取代。当前最新的版本是h t t p 1 1 ，由r f c 2 6 1 6 定义，当然h t t p f l 0 也仍在使用之中。 目前的w e b 应用系统，无论是显示静态h t m l 页面，还是通过a s p 、p h p 或者c g i 等技术显示动态页面，都是通过h t t p 协议和用户进行交互的。h t t p 协议是应用层协议，在h t t p 协议中，用户通过标定u r l ( u n i f o r n lr e s o u r c e l o c a t o r s ) 来确定访问的页面。如果用户需要访问动态页面，也通过u r l 来传递 参数。u r l 格式如下： h t t p _ u r l 一h t t p ：”h o s t ：”p o r t 】 a b s _ p a t h 【”? ”q u e r y 】 其中，“h t t p ：# ”表明应用层网络协议名称，“h o s t ”表示要访问的主机名称， “p o r t ”表示访问的端口，“a b s 2 a a t h ”表示要访问的页面的路径，“? ”和后面的 q u e r y 表示要传递的参数。用户只是访问静态的h t m l 页面时，u r l 中没有“? ” 和后面的q u e r y 字符串，如果用户访问的是动态页面，那么u r l 中的“? ”和后 面的q u e r y 字符串会传递给下一个动态页面。一般q u e r y 字符串中包含着用户的 查询条件。 q u e r y 字符串是要传递给服务器的参数。h t t p1 1 支持七种类型的请求，它 们是g e t ，p o s t ，h e a d ，o p t i o n s ，p u t ，d e l e t e ，t r a c e 。其 中g e t 与p o s t 是i n t e r n e t 应用中经常用到的二种请求类型。“g e t ”方法通过 环境变量读取用户传递的q u e r y 字符串参数，“p o s t ”方法通过读标准输入 ( s t d i n ) 来获得表单中输入的各项内容，通过写标准输出( s t d o u t ) 来回传客户 端的信息。 3 1 2 h t t p 1 1 的改进 h t m l 指定了文档的数据和结构，但没有指定浏览器怎样对文档进行格式 化，因而对同样的h t m l 文件不同浏览器显示出来的不一定完全相同。h t t p 1 1 1 7 在许多方面比h t t p 1 0 有明显改进。与w e b 性能密切相关的方面主要包括： c a c h e 处理机制、网络带宽优化和连接管理【l 】 2 3 】。 1 c a c h e 处理机制 对于w e b 响应的缓存既是可能的又是必要的。因为不同用户经常请求一些 相同资源，一个特定的用户也可能重复请求相同的资源。所以，缓存这些被重复 请求的资源能够提高w e b 访问效率。绝大多数w e b 浏览器和很多w e b 代理服务 器都采用了c a c h e 机制，有时候c a c h e 也和w e b 服务器一起使用。 c a c h e 通过减少和w e b 服务器的网络通信来减少用户所感受到的延迟，这同 时也减少了网络带宽不必要的消耗，而降低的带宽消耗也因为减少网络拥塞而间 接减少了未被c a c h e 的w e b 交互行为的延迟。此外，c a c h e 机制还能够降低w e b 服务器和中间代理服务器的负载，从而又进一步改善了未被缓存的w e b 交互行 为的延迟。 使用c a c h e 的一个风险就是c a c h e 机制在语义上可能是不透明的，换句话说，