（计算机应用技术专业论文）网格资源负载管理系统软件测试方法研究.pdf

摘要 软件测试是一门黑色艺术，黑色意味着测试人员必须从心理上接受测试是经 历一个对程序施虐和施暴的过程；艺术意味着测试人员必须从经济学的角度巧妙 的制定测试策略，来完成整个测试过程。随着这门黑色艺术在软件开发中演绎得 越来越精彩，软件测试的地位在软件开发生命周期中同趋重要。 测试一个简单的程序是如此，测试一个复杂的网格软件更是如此。l s f 是加 拿大p l a t f o r m 软件公司一款成熟优秀的网格软件，加深对l s f 产品本身的理解， 将有助于本课题各项测试工作的展开。 本文首先研究了软件测试的定义，策略，原则，以及对软件测试过程的制定 的相关理论进行了研究，为后文分析整个l s f 软件测试过程奠定了基础。文章归 纳分析了整个l s f 软件测试过程，从敏捷开发管理的启动，需求文档的分析，用 例的设计，测试计划的撰写与执行，自动化测试用例，提交错误报告，项目的质 量评估，以及a l p h a 测试阶段相关任务的分析介绍，一直到软件最后的发行，对 正确的实施原则以及可能出现的问题进行了研究与分析，并给出了改进方法。 1 在整个测试过程中，用户用例要尽可能在高层次进行抽象；撰写测试计 划需要从不同场景进行展开；自动化用例必须有定义良好的结构；合理 分配测试人员。 2 对测试工作的展丌采用敏捷管理方法，达到快速解决问题的目的，使整 个项目不断向前推进。 3 在集成测试阶段，对测试任务采用负责人的方案，有效解决了集成测试 压力大，资源紧张的局面。 关键词：l s f 网格软件软件测试方法软件测试过程敏捷管理 a b s t r a c t s o f t w a r e t e s t i n g i sab l a c ka r t ，b l a c km e a n st h a tt h et e s t e rh a v et o p s y c h o l o g i c a l l ya c c e p tt h a tt e s t i n gi st om a k eap r o c e d u r eg o i n gt h r o u g hap r o c e s sf u l l o fa b u s ea n dv i o l e n c e ；a r tc a r r i e st h a tt h et e s t e rh a v et od e v e l o ps t r a t e g i 骼f r o mt h e p o i n to fe c o n o m i c sv i e wi no r d e rt oc o m p l e t et h ew h o l et e s t i n gp r o c e s s a l o n gw i t h t h eb l a c ka r tb e c o m em o r ea n dm o r ee x c i t i n gi ns o f t w a r ed e v e l o p m e n t ，t h es t a t u so f s o f t w a r e t e s t i n gi nt h el i f ec y c l eo fs o f t w a r ed e v e l o p m e n tb e c a m em u c hm o r e i m p o r t a n t t e s t i n gas i m p l ep r o c e d u r ei sab l a c ka r t ，s od o e st h ec o m p l e xg a ds o f t w a r e l s fi sm a t u r ea n de x c e l l e n tg a ds o f t w a r et h a tw a sd e v e l o p e db yp l a t f o r ms o f t w a r e c o m p a n yi nc a n a d a e n h a n c i n gt h eu n d e r s t a n d i n go fs o f t w a r ei t s e l fw i l lb eb e n e f i tt o o u rt e s t i n gw o r ki nt h i sp r o j e c t i nt h i sa r t i c l e ，f i r s t l y , is t u d i e dt h ed e f i n i t i o n ，p o l i c y , p r i n c i p l eo fs o f t w a r et e s t i n g ， a n dh o wt op l a nt h es o f t w a r et e s t i n gp r o c e s s ，w h i c he s t a b l i s h e dt h eb a s ef o rt h e a n a l y s i so ft h ew h o l es o f t w a r et e s t i n gp r o c e s s t h ea r t i c l ec o n c l u d e da n da n a l y z e dt h e w h o l el s fs o f t w a r e t e s t i n gp r o c e s si n c l u d i n gt h es t a r to fs e r u md e v e l o p m e n t m a n a g e m e n t ；a n a l y s i so ft h er e q u i r e m e n td o c u m e n t ；d e s i g no ft h eu s ec a s e ；d e s i g n a n de x e c u t i o no ft h et e s tp l a n ；a u t o m a t i o no ft h et e s t c a s e ；s u b m i s s i o no ft h eb u g r e p o r t ；q u a l i t ya s s e s s m e n to ft h ep r o j e c t ；i n t r o d u c t i o no ft h ea l p h at e s t i n gp e r i o d ；t i l l t h er e l e a s eo ft h ep r o d u c t ，d i s c u s s i n gt h ec o r r e c t i m p l e m e n t a t i o np r i n c i p l ea n d p r o b l e ma n a l y s i sa n dg i v i n gp r o p e ra d v i c e s 1 d u r i n gt h ew h o l et e s t i n gp r o c e s s ，d e s i g no fu s ec a s es h o u l db ea b s t r a c t e di n h i g hl e v e la sp o s s i b l e ；w r i t i n gt e s tp l a ni si nn e e do fc o n s i d e r i n gd i f f e r e n t s c e n e r i e s ；t h e r ew o u l db ed e f i n e da v a i l a b l es t r u c t u r ei na u t o m a t i o nc a s e s ； t e s t o rs h o u l db ea l l o c a t e dp r o p e r l yt o o 2 s c r u mw o r ki st a k e ni nt e s t i n gi no r d e rt or e s o l v ep r o b l e ma ss o o na s p o s s i b l ea n dp u s ht h ew h o l ep r o j e c tt om o v i n gf o r w a r ds m o o t h l y 3 i ni n t e r g r a t e dt e s t i n gp h a s e ，t h ee n t i r et a s ki sa s s i g n e dw i t ha no w n e r t h a t r e s o l v e st h ep r o b l e mo fh e a v ys t r e s so fi n t e g r a t i o nt e s ta n dl a c k i n go f r i e s o u r c e s k e yw o r d s ：l s fg a ds o f t w a r e ，s o f t - w a r et e s tm e t h o d ，s o f t w a r et e s tp r o c e s s ，s c r u m m a n a g e m e n t 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取 得的研究成果，除了文中特另t l d n 以标注和致谢之处外，论文中不包含其他 人已经发表或撰写过的研究成果，也不包含为获得天津理工大鲎或 其他教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研 究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。 1口 学位论文作者签名：夕纱圩签字日期：彦髫年肛月汐日 i v 学位论文版权使用授权书 本学位论文作者完全了解 墨盗墨墨盘堂有关保留、使用学位论文 的规定。特授权墨盗墨兰太鲎 可以将学位论文的全部或部分内容编入 有关数据库进行检索，并采用影印、缩印或扫描等复制手段保存、汇编， 以供查阅和借阅。同意学校向国家有关部门或机构送交论文的复本和电子 文件。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名：名也千 导师签名： 签字日期：畅年月彦锣日 彳由扔 q 签字日轧训厂年y 月3 。日 第一章绪论 1 1 背景 第一章绪论 越来越多的企业意识到：在有限的i t 预算中，关键的工作是如何充分利用 已有的计算资源。如何有效的整合，共享，分配使用这些计算资源成为了焦点。 对于分布式企业来说，资源的重新整合，灵活分配将有效的应对同益变更的客户 群体与服务。在制造业中，将计算资源分配给最重要的应用程序将使利润最大化。 而网格计算将带来的平衡和重新分配现有的i t 资源和工作负载的技术，以及由 此产生的巨大生产力与商业利益是息息相关的，因此这种理念蕴含的潜力和生命 力将不言而喻。 另一个现实同样摆在我们面前，众所周知的摩尔定律指出：网络处理能力每 九个月翻一倍，而与此同时集成电路中晶体管的数量每十八个月才翻一倍。填补 处理器的发展速度与网络处理能力之间形成的鸿沟，成为了网格计算肩负的使 命。网格计算的定义：动态多机构虚拟组织中的资源共享和协同问题解决n 1 。资 源的共享形成的虚拟计算平台，以及带来的强大处理能力将弥补处理器发展速度 缓慢这一现实问题。 网格应用领域目前主要有四类：分布式超级计算、分布式仪器系统、数据密 集型计算和远程沉浸。分稚式超级计算是指将多台超级计算机通过高速网络连 接，经由网格协作，形成远超过单台超级计算机计算能力的计算平台。1 9 9 8 年 3 月1 6 同，s fe x p r e s s 集合1 3 台并行计算机之力，使用了l ，3 8 6 个处理器， 终于成功模拟了1 0 0 ，2 9 8 个战斗实体，实现了历史上最大规模的战争模拟。分布 式仪器系统是指通过网格管理各地贵重的仪器系统，提供访问手段，提高仪器的 利用率。由印第安那州大学，a r g o n n e 国家实验室a n l 和劳伦斯市伯克利国家实 验室l b l 共同完成的x p o r t 项目，达到了让远程使用科学仪器达到前所未有的 方便程度，拿他们的话来说，就是“比到那儿用还方便。数据密集型计算与计 算密集型计算相比，更侧重于数据的存贮，传输和处理。由欧洲原子能研究机构 c e r n 研发的大型强子对撞机l h c ( l a r g eh a d r o nc o l l i d e r ) 产生的数据量对计 算能力提出了空前的挑战，欧洲的d a t a g r i d 就是在这种情况下应运而生的。远 程沉浸是一种特殊的网络化虚拟现实环境，是对高性能计算结果或数据的可视 化。中国敦煌莫高窟价值连城的壁画就曾于1 9 9 8 年被数字化成为远程沉浸环境 【2 】 0 加拿大p l a t f o r m 软件有限公司提供一种方法，能使企业无需注入大量资金 就能改善企业经营业绩。这种方法将克服因时空和僵化的基础设施带来的阻碍， 1 6 年来，p l a t f o r m 对该方法网格计算的经营的结晶是：p l a t f o r m 公司的网格计 算产品和解决方案已成为包括g m ，i b m ，h p ，a m d ，s u n ，s g i ，e m c ，f u j i t s u ，n a s a ， b m w ，t o y o t a ，a i r b u s ，b o e i n g ，p r a t t w h i t n e y ，j pm o r g a n ，s h e llo i l ， 第一章绪论 m o t o r o l a ，a t & t ，n o r t e l 和美国国防部等l ，7 0 0 多家世界顶尖级企业及6 0 的世 界5 0 0 强企业所使用n 1 。 l s f 是p l a t f o r m 主打产品之一，是一款对计算密集和数据密集应用程序的负 载处理进行管理和加速的软件。 1 2 课题任务 该课题来源于国际知名的网格软件供应商p l a t f o r m 公司的网格计算产品 l s f 的d e l e g a t eh d m i nr i g h t s 新项目的测试工作。我的任务是：作为该测试项 目的负责人，从该项目需求文档的形成，一直到该项目最终合并在l s f 中被发布 出来，负责所有与该项目相关测试的工作。 d e l e g a t ea d m i nr i g h t s 是l s f 新增加的一项功能，核心是解决用户的权限 分配问题。包括对作业的各种操作权限，涉及到大量的批处理操作命令的权限分 配；另外还包括对主机的操作权限分配。 l s f 作为一款优秀的网格软件，其应用环境将是异常复杂的，充分考虑各种 应用环境下的用户权力分配，是该项目成功测试的关键。 1 3 本人工作介绍及论文组织结构 本文共分六章计划如下： 第一章：绪论，介绍本课题背景，任务。 第二章：软件测试的态度和过程的介绍：包括软件测试的定义，策略，原则， 以及整个测试过程的定义。 第三章：网格计算和l s f 产品的介绍：包括网格计算的起源，l s f 的基本概 念，体系结构以及基本工作原理。l s f 的改进与最新研究状况。 第四章：软件测试过程的制定与改进：对l s f 的软件测试过程进行分析介绍。 第五章：实际测试项目的操作分析：介绍了整个a d m i nr i g h t s 项目的测试 过程，从启动一直到最后的a l p h a 测试阶段。 第六章：总结和展望： 其中本文的重点在第四章和第五章，详细论述了l s f 软件整个测试过程，并 以实际测试项目为例进行了实践操作和分析说明。 本人的工作分两阶段，第一阶段持续到d e l e g a t ea d m i nr i g h t s 项目的 h a n d o v e r ( 包括一系列文档的准备与实例的演示) 。负责该项目有关的所有测试工 作，包括f s 文档的最终定稿，u s ec a s e 的设计，单元测试，t e s tp l a n 的撰写 与执行，测试用例的a u t o m a t i o n 工作，主流平台的s a n i t yc h e c k 工作，b u g 的 提交与跟踪，c s ( c u s t o m e rs p e c i f i c a t i o n ) 文档的审阅，以及最后项目质量的评 估。第二阶段a l p h a 测试阶段，也是测试人员最为忙碌的测试阶段，除了与该项 目相关的b u g 以及f o l l o w - u pi s s u e s 继续跟踪外，该阶段的各项工作都曾实践 操作过，进行过两次a l p h a 阶段的测试实践。后文对相关任务进行了详细介绍与 分析。 2 第二章软件测试的原理和过程 第二章软件测试的原理和过程 无论软件开发采用的什么样的生命周期模型，软件测试作为产品质量控制的 重要一环已是不争的事实。软件测试不同于o u a l i t ya s s u r a n c e ( 质量保证) ， 质量保证并不关注于程序错误，它只要产生一个面向开发团队内部的满足标准的 可交付软件版本。而作为质量控制的软件测试，不能依赖于s u b j e c t i v e a s s e s s m e n t ( 主观评估) ，质量的认可必须基于一个可论证的，可测量的测试方 法和过程。并在客观检测的基础上，确认程序缺陷，提出改进意见，达到确保最 终软件产品高质量的目的。 测试产品的高质量取决于软件测试人员的态度和整个软件测试过程的制定。 2 1 软件测试的定义 软件测试人员对软件测试的不同定义从心理上反映了测试人员对软件测试 的不同态度。他们可能认为h 1 ： 软件测试就是证明软件没有错误的过程 软件测试是为了证明软件完成了其预期的功能 软件测试是建立一个软件完成了其应该完成的信心的过程 作为一名测试人员，这些理解都无助于产品质量的提高。因为测试的最终目 的是为了提高产品的可靠性和质量。而产品的可靠性依赖于程序错误的最终修 复。 企图证明程序能够正确运行的测试过程，对于发现程序错误，提高产品可靠 性和质量而言无异于缘木求鱼。 软件测试的正确定义应该是： “测试是为发现错误而执行程序的过程 h 1 。 表面上分析，这与上面的定义产生了类似的结果，实际上并非如此。深刻理 解软件测试的真正定义，对于成功执行软件测试过程具有很大影响。 人类的活动都具有很强的动机性，强烈的动机产生的心理倾向对人类行为的 指引具有重要的影响。抱着测试是为了证明程序能够j 下确执行的心态进行的测 试，最终的结果将趋向于表明程序能够正确执行。一位急于程序交付的开发人员 进行的测试就很可能采用倾向于证明程序能够正确运行的测试数据和测试结果 分析。与之相比，如果我们的动机在于证明程序中确实存在错误，则我们设计的 测试数据和测试结果分析将有可能更多的发现问题。显然，后一种出发点将更有 可能到达提高产品质量的目的地。 软件测试素有黑色艺术之称，以上定义同样表明软件测试是一个破坏性 的过程，甚至是一个施虐和施暴的过程。这对于测试用例在功能测试，压力 测试，负向测试等测试阶段的设计都有鲜明的指导作用。 成功的测试相当于医生给病人查出了病源。当测试结束时，如果不能给 3 第一二章软件测试的原理和过程 病人诊断出j 下确的病因，看病的结果只能是资源的浪费和产品风险的提 高。因此能够发现错误的测试用例将是值得设计的。 证明软件没有错误的测试过程还将引入另一个问题。即使测试一个极小的程 序，这个过程也是无法完成的，因为测试数据是无法穷举的，如证明某个数能被 2 整除，这样简单程序的测试数据都是无法穷举的。由此导致的庞大的测试任务 还将影响测试人员的效率，原因是高压状态下工作的进展将十分缓慢。 达到软件完成了其应该完成的的测试过程，与其说是建立信心的过程， 不如说是心存侥幸的过程。即使证明了软件做了其应该做的，测试人员也无法确 定程序是否做了其不应该做的，这种隐含的程序错误很容易伴随上面定义的测试 过程。例如测试一条记录是否写入数据库中，当该记录被证明确实完整无误的写 入数据库时，测试人员仍无法确定该写入操作是否做了其它不当的操作如：覆盖 原有的数据，同时写入多个数据表等。 总之，软件测试是一个试图发现程序错误的暴力过程。成功的测试用例 将发现程序的错误，从而改进程序的质量。建立对软件产品质量的信心，不仅要 利用测试过程表明软件做了其应该做的，还要达到表明软件没做其不该做的。在 发现错误的基础的上，对错误的分析将是达到该目的的一条重要途径，如有一项 分析就表明，程序错误集中的地方，发现更多的错误的可能性更大，这在一定程 度上将指引测试人员的测试工作。 2 2 软件测试的策略 结合软件测试的定义，测试人员的下一步目标将是尽量发现软件中存在的错 误。然而众所周知，世界上不存在没有错误的程序，也就是说软件测试不可能完 成发现所有程序错误的任务。相应的表明，软件测试人员面对一个如何平衡软件 测试量和达到被测软件期望值的问题。这也是一个投入与回报的经济学问题。面 对这个挑战，在开始设计测试用例之f j ，必须建立某种策略。目前黑盒与白盒测 试是两种最普遍，最基本的测试策略。 黑盒测试：将程序当作一个黑盒子，不考虑程序的内部机制和结构，测试用 例的设计完全依赖于软件规范。 白盒测试：与黑盒测试正好相反，测试用例的设计由程序逻辑驱动，程序规 范常常被忽略。 然而这两种测试虽然很重要，却都有着致命的弱点。测试用例完全依赖于软 件规范的黑盒测试，若要达到尽量发现程序错误的目标，就必须对测试用例进行 穷举。而穷举在很多情况下都是不可能的，如测试用例是一个无穷数，某航空公 司的数据库等。由程序逻辑驱动的白盒测试，测试用例的设计同样面对一个不可 能和不切实际的局面。不可能穷举所有的测试逻辑，循环和条件的混合结构就很 能说明这个问题。另外所有的逻辑之间不一定是相互独立的，所以这样的测试是 不切实际的，测试人员无需穷举所有逻辑结构。 换个角度，既然测试策略的目标是设计出有效的测试用例，我们可以根据不 4 第二章软件测试的原理和过程 同的测试策略设计出有效的测试用例，并进行合并，达到尽可能发现程序错误的 测试目的。 然而这种简单的由测试策略合并而设计测试用例的方法不一定适用于整个 测试过程。 因为依据什么来选择测试策略仍将是问题。 测试策略由两个组件组成，分别是测试因素和测试阶段酾3 。 测试因素：作为测试策略的一部分对测试程序的风险和问题进行说明。 测试阶段：发生在软件开发生命周期的各个测试阶段。 测试因素在不同的软件中肯定不同，在不同的测试阶段所起的作用也肯定不 同。因此测试人员在构建软件测试策略之前，必须根据软件自身对测试因素进行 选择。并不根据不同的测试阶段对测试因素进行排序。 软件测试的目标，提高产品的质量，换言之就是减少软件产品本身的风险。 软件测试策略的制定必须能够说明这些风险，并提出减少这些风险的测试过程。 软件本身的风险或错误就成为了测试过程的目标。因此制定一个自定义的测试策 略就必须执行以下步骤： 选择并排序测试因素。测试因素的选择应该由系统的客户，用户和测试 小组合作完成并排序。可选择只排序关键测试因素，将其它一般因素与 关键因素进行关联。对于比较特别的测试风险，可以进一步展开测试因 素进行详细描述。 区分软件开发阶段。由丌发小组对开发过程的各个阶段进行划分。测试 因素将与各个开发阶段结合。 基于测试因素标志与系统关联的风险。由丌发人员，关键用户，客户和 测试人员集体讨论与标志。并对风险分级。 将风险与测试阶段相结合。测试人员需要明确在哪个测试阶段注重什么 软件风险，以展开测试工作。 不同的测试策略关注的重点不同，所适应的软件生命周期阶段也不同。黑盒 测试注重软件产品的各种文档规格说明，比较适合f e a t u r e ( 功能) 测试，白盒 测试倾向于依赖程序逻辑，开发人员在前期进行单元测试时经常采用。可选择的 系统性能测试的目标是确定程序不会对系统性能带来新的风险，经常在集成测试 阶段完成。可靠性测试中采用的压力测试，负载测试则一般紧随集成测试，它对 测试范围进行了放大，目标不仅是单个程序而是整个系统。此外还有安全测试， 负向测试，客户场景模拟测试等都具有不同的针对点。 总之，测试策略的制定主要结合测试阶段考虑测试因素，最终形成有效的测 试用例。采用单一固定的测试策略是不可取的。 2 3 软件测试的原则 从宏观的整个软件测试过程分析，以下六种常用的软件测试指导原则，可以 极大地改进软件测试过程n 6 。 5 第- 二章软件测试的原理和过程 ( 1 )软件测试应该降低软件开发风险。软件测试作为控制软件j x l 险的手段， 将要为管理人员提供及时的信息，以便管理人员基于风险报告对资源进 行分配。最高的业务风险将享有最多的测试资源。 ( 2 )应该有效地开展测试工作。对于测试有效的思考来源于不同测试人员执 行每个任务的成本差异。这将意味着对测试过程的改进来减少差异。如 通过个人能力的提高，方法的互相取长补短。时间的管理等。 ( 3 )测试应该能够揭示缺陷。研究表明，缺陷发现的越早，纠正错误的成本 将越少。导致用户或客户产生负面影响的缺陷就成为了故障。用户为纠 正该故障将要花费一定的成本，因此缺陷的代价将是双重的。 ( 4 )基于第三点的考虑，使用业务逻辑进行测试将是必然的。 ( 5 )整个开发生命周期中都应该进行测试。从需求分析开始，测试工作就应 该展开，软件测试中的静态测试即文档测试就需要对需求文档的深刻理 解。即使进入维护阶段，测试工作也不能停止。测试与维护变成了一个 相辅相成的过程。 ( 6 )必不可少的功能与结构测试。功能与结构测试几乎占用了测试时间的半 壁江山。如功能测试中的b a s i cf e a t u r e ( 基本功能) 和( i n t e g r a t i o i l f e a t u r e ) 集成功能测试，为此设计的测试用例，即使对于一个千行的c 程序，有可能达到几百个。这还不包括测试过程中的扩展测试。 从软件测试的定义的微观角度出发，测试是为了发现程序错误。下而的测试 指导原则将非常实用。 ( 1 ) 测试用例必须给出测试的预期输出和结果。原因是多方面的，测试用例的 设计者很有可能不是测试的实施者，倒经常是测试结果的审查者，测试用 例结果的不明确导致的结果是测试用例的无效，或执行者需要花费更多的 时问与设计者进行沟通。甚至有可能测试用例本身设计错误，或没有及时 更新。因此无论是对设计者还是执行者，给出设计结果将足对测试用例的 有力复查。 ( 2 ) 程序员应当避免测试自己编写的程序。编写者可能出于习惯性思维，很难 查出程序错误。编写者若是走入产品理解误区，依靠自身是很难走出误区 的。编写者有可能考虑个人绩效问题，从而尽量避免证明程序是错误的。 虽然阅读别人的代码比自己写一段代码还困难，但发现错误不等于调试错 误，调试是纠正已知的错误，理应由熟悉程序本身的人来完成。 ( 3 ) 编写软件的团队不宜测试自己的软件。原因与第二点类似，还有一点就是： 测试将带来时间和成本的花销，测试工作的不合理，带来的将不仅是测试 工作本身的不理想，还有可能引发管理上困惑。软件可靠性的评估极其困 难，如果不能合理的规划和实施测试过程，开发团队无法就完成进度和成 本目标给出一个客观的评价。但是编程团队发现自己的问题并非不可能， 只是由第三方来评估和测试将更客观和经济。 ( 4 ) 应当彻底检查每个测试的执行结果。虽然每一个测试用例都有自己的针对 6 第二章软件测试的原理和过程 性，但在执行测试的过程中，形成对测试结果进行充分检查的习惯，将对 测试效率有明显改善。很多软件错误的发现，实际上在前面的测试中很可 能已经出现不只一次了。只是由于当时测试重心的不同，导致测试错误发 现的很晚，形成早期测试不充分的局面。 ( 5 ) 测试用例的编写不仅应当考虑正常的情况，还应当考虑异常和无效的情 况。如果仅仅按照正常的逻辑对程序进行测试，错误是很难发现。因为正 向的测试即使全部成功，也不能说明程序有能力处理某种异常情况，或者 是一些隐含在正向测试用例中的问题。相反，往往负向用例更能发现问题。 ( 6 ) 应注意保存测试用例，除非是一次性软件。程序需要重新测试的情况经常 发生，如产品引入了新的功能，需要确定原来的功能是否有被坏；修复了 重要的程序错误，需要验证是否引入了新的错误；从m a i m i n e ( 主干) 中分离出来形成的新版本需要接受验证，以使产品趋于稳定，以待发布； 客户需要选取有效用例来验证产品等，其中因修复程序而要进行的重新测 试最为频繁。此外，在测试过程中，注意保存扩展测试的测试用例也十分 重要，这些测试用例往往能够发现问题。 ( 7 ) 测试定义说明的很重要一点，测试不应该假定某个测试用例不会发现错 误。这种现象即使是经验丰富的高级测试人员也会发生。当一个测试用例 十分简单，而且看起来与周围其它测试用例很类似的情况下，特别容易被 忽略。但有时，错误就这样不期而致，给疏漏过去了。每一个测试用例都 必须认真对待。 ( 8 ) 前面曾提到过，程序某部分存在更多错误的可能性，与该部分已发现错误 的数量成正比。这是一条很容易验证的经验之谈，相信进行过测试工作的 人员都很有体会。当软件某个地方反复出现问题时，表明有可能，软件开 发者在该方向上的知识比较薄弱，或者一丌始的设计就没引起足够重视， 当问题出现时，急于修复错误来不及进行全面考虑。极易导致出现图2 1 所示情况： 发 现 错 误 的 可 能 性 已发现错误的数量 图2 - 1 ：错误数量与可能出错的关系 ( 9 ) 软件测试是一项极富创造性，极具智力挑战性的工作。测试一个大型软件 7 第二二章软件测试的原理和过程 所需要的创造性很可能超过了丌发该软件所需要的创造性h 1 。 ( 1 0 ) 一次好的测试用例执行，是发现了从未发现的问题。所有的原则最终只有 一个目标，发现错误。发现了从未发现的错误，足以表明该方法可行。 软件测试的原则是对软件测试的深刻理解，和测试人员长期工作的总结。当 测试工作具体到某一类测试时，如某一种语言，某一种平台，某一特点环境，应 以发现问题为宗旨，总结出自己的测试原则。测试原则应该是条条道路通向发现 b u g ( 错误) 之路的。 软件测试的定义，策略，原则，具有很强的主观能动性，测试人员需要正确 理解软件测试的内涵，充分发挥自己创造力，控制产品质量。 2 4 软件测试过程 软件测试过程与软件开发的生命周期是紧密结合的，软件开生命周期的模型 多种多样，普遍采用的模型有： v 字模型。软件测试将分别在开发的主要四个阶段，需求分析，结构设计， 详细设计，代码设计，进行相应的测试。 瀑稚模型。最大的特点是软件测试丌发的详细设计之后才开始进行。 渐进模型。与上面两个不同的是分阶段对产品进行交付，实际证明该模型具 有更好的灵活性和适应性，v 字和瀑布模型则过于理想化。在我测试过的项 目中都采用过该模型。它不仅可以从一定程度上让丌发人员和测试人员同步 以便于人员管理，还可以降低一次交付的风险以及充分利用测试推动丌发工 作。 迭代模型。在需求不是很明确的情况下，该模型的优势体现比较明显。 要达到软件测试在软件开发生命周期中很好的实施，就必须制定可行有效的 软件测试过程。 软件测试过程是指j 下确实施测试策略的途径。测试人员遵循定义良好的测试 过程有利于开发出更好的测试方法，结合更新的测试方法可以不断改进软件测试 过程。 软件测试过程及其目的： 1 测试的组织： 确定测试的范围：一个完善的软件测试过程肯定对各个测试阶段进行了划 分，而每一个划分如功能测试，平台测试等均有其测试范围，这一点应该很 容易明确下来。 组织测试人员：一个测试团队很有可能在同时进行好几个项目的测试，合理 分配人员是一项关键的任务。在测试之前应该确定该项目将有多少 r e s o u r c e s ( 资源) 投入进去。 评估测试计划和状况：在开展测试工作前必须对整个计划有初步的估计，以 确保项目能够合理，高效，按时的完成。如过早启动项目，预计的时间根本 无法完成，未经适当培训的测试人员导致的测试差异没有考虑到等。 8 第二章软件测试的原理和过程 2 开发测试计划 开发测试计划包括测试用例的设计，实际中测试用例的设计之前有很多 的文档检验工作，如功能描述文档，功能需求文档，客户需求文档等的检验。 测试项目分析：进行b r a i ns t o r m i n g 会议，发动整个团队的力量，明确该 测试项目涉及的方方面面。参加会议的人员不一定要对该项目进行测试。 撰写测试计划：测试用例的设计，这也是整个测试过程的核心，测试用例的 好坏直接关系到测试过程的失败与成功。 3 检验测试 这里的检验测试主要是指文档测试，而实际中，文档的确认工作贯穿整个 开发和测试阶段。 测试需求文档，需求的不完整，不清楚只能导致后期开发测试成本的增加， 主要在早期完成，但在项日结束时都有可能会重复进行。 测试软件设计，这个时期，测试人员很有可能关心如某个查询算法是否真正 有效，某种存储模式是否会引起内存过大开销等。 4 确认测试 占据测试过程大部分时间的测试计划的执行。 执行测试，根据测试计划中测试用例指定的步骤，方法及工具，执行测试计 划。 记录测试结果，测试结果需要归档，以方便高级测试人员进行审查，和需要 重新测试时作为参考。 5 分析并报告测试结果 分析测试结果：将实际结果与预期结果进行比较，找出不一致的地方，进行 分析。分析的测试结果可能来源于手动的或自动运行的测试。 丌发测试报告：将发现的程序或文档的错误以书面的形成提交。定期以会议 的形式对项目的进展，以及质量情况进行汇报。 6 验收和操作测试结果 高级测试人员对测试结果进行复查以确保测试结果的正确性，并对测试 用例进行抽样测试和进一步的扩展测试。 7 实现后分析 每次项目结束后，测试人员和开发人员都要对整个测试过程进行回顾， 分析项目可以发扬和改进的地方。 9 第三章网格计算和l s f 系统介绍 第三章网格计算和l s f 系统介绍 正如因特网起源一样，网格的研究同样源于科学研究的需要。因特网之前科 学研究环境是单一的实验室，及一组小的团队。因特网之后，使得构建大型数据 库，实现需要大量数据的场景模拟实验，以及海量数据的及时分析成为可能。正 是这些需求驱动着网格计算的研究开发口】。 互联网的兴起对于商业同样是一场革命。在此之前，商业信息处理十分集中， 此后，商业信息处理量急骤增加，对商业信息的处理复杂度及高效性提出更高要 求，不仅如此，企业计算出现了新的特点，分布性和异构性。如何高效收集，分 配，调度，利用好企业资源成为越来越多的企业急需解决的问题。 3 1l s f 简介 网格体系结构对于网格计算具有决定性作用，但是不管何种体系结构都要具 有资源管理模块。资源负载正是网格管理的核心对象所在，资源管理关心的并不 资源能够为用户提供什么类型的服务，而是如何将资源合理分配给用户使用。l s f 正是一款成熟优秀的网格资源管理软件鼬1 。 l s f ( l o a ds h a r i n gf a c i l i t y ) 是网格应用环境下，位于操作系统之上的分布 式资源负载管理软件。其作用是通过对网络中不同计算机操作系统创建一个单一 的系统映像来管理网络计算机资源。 在介绍l s f 之前需要理解l s f 的一些基本概念，集群，作业，队列，守护进 程引。 集群：由多台计算机组成，这单的集群并没有同类型的要求，是一组作为单 一工作单元的计算机。能够组合利用计算能力而不仅仅是主机与主机问的协作， 可以深入到c p u ，内存之间的协作；能够在各种策略的驱动下进行负载和资源的 共享。 作业：这个概念覆盖的范围比较广，它既可以是指一个简单的命令，也可以 是一个很复杂的场景模拟实验，一次很庞大的天文观测数据处理。 队列：一个基于策略驱动的对作业进行调动和发配的容器，并不管理作业生 命周期中的任何状态。 主机：一台有效的计算机就是主机。但是主机的分类却很多，从主机完成的 功能上来看主机有主从( m a s t e r ，s l a v e ) 之分，一个集群中只有一台m a s t e r ， 可以有多个s l a v e 。s l a v e 型主机可以完成收集资源信息以及提交，执行作业， m a s t e r 的不同之处在于它要负责作业的集中调度和资源的分配。s l a v e 型主机还 可细分为服务型和客户型，客户型主机只有提交作业功能，不能够运行作业也就 是说它不能为资源和负载的调度作贡献。从作业的角度来看可分为提交主机和执 行主机，作业的提交主机并不一定是作业的执行主机。 守护进程：可以简单理解为一个套接字端口监听程序。但是它不仅对资源信 1 0 第三章阿格计算和l s f 系统介绍 息进行监听，还对各种负载( 作业) 进行管理，包括前面提及的整个作业生命周 期的状态管理。由各个守护进程间的协作完成资源和负载的共享与调度。l s f 的 基本守护进程有：负责资源收集的l i m ( 1 0 a di n d i c e sm a n a g e r ) ，m l i m ( m a s t e r l i m ) ，负责作业调度执行的有r e s ( r e m o t ee x e c u t i o ns e r v e r ) ，s b d ( s l a v eb a t c h d a e m o n ) ，m b d ( m a s t e rb a t c hd a e m o n ) ，m b s c h d ( m a s t e rb a t c hs c h e d u l ed a e m o n ) 。 3 2l s f 基本框架 l s f 组件可以基本划分为如下三部分西1 ：l s fb a s e ，l s fb a t c h ，l s f l i b r a r i e s 。 l s fb a s e 基于不同操作系统的计算机资源组成的网络提供负载共享服务。 换言之，b a s e 部分对下集成不同平台的资源，对上提供统一的服务接口。 l s fb a t c h 是b a s e 部分的延伸，在b a s e 整合网络中不同计算机资源的基础上， b a t c h 部分将整个计算机网络当作一台网络批处理计算机。不仅具有批处理系统 整个流程的主要特征，而且还提供负载平衡和策略驱动的资源分配控制。 它从b a s e 部分获得的信息主要包括：资源和负载信息，集群配置信息，文件传 输所需的文件选项信息等。 l s fl i b r a r i e s 包括l s l i b 和i s b l i b 两部分，均是向上层应用程序提供a p i 。 l s l i b 对应b a s e 部分，l s b l i b 对应b a t c h 部分。 l s f 体系结构国1 i u s e f p r o g r a m s 锄d c 咖m a n d s 一 l 嘶s f 曲旧l s f 曲一川l s f 心蛔盯忙l s f 归8 = ，旧g u i l s l i b d i n f o 肺a t i o n m 柚a g 盯 l 0 t e e x e c u t i o n s e 一 c m y s9 燃i 篱旧i b m l l i n u x i 删s g x i9 躲l 邺| a p p l i c a t i o n s s e r v e rd l l n l o n 8 o p e r a t i o ns y s t e m s 图3 1 ：l s f 体系结构 b a s e 部分主要由l s l i b ，l i m ，r e s 三部分组成。l s l i b 处于b a s e 部分的上 层，是上层应用程序访问b a s e 子系统的直接接口，为上层的访问提供了一个统 一，主机独立的环境。l i m 负责收集主机资源负载信息，并将信息报告给m a s t e r l i m 。r e s 负责作业的远端执行。 l s fb a t c h 的结构如下： l s b l i b 提供访问b a t c h 子系统的直接接口，保证所有操作具有平台独立性， 并屏蔽所有上层应用程序与l s f 的交互细节。m b a t c h d 位于m a s t e r 型主机上， 第三章网格计算和l s f 系统介绍 负责作业的调度和执行，s b a t c h d 位于s e r v e r 型的主机上，控制作业的执行， 并向m b a t c h d 报告作业生命周期中的状态。 u s e r j 。b s 怛蛐旧g u il 麓删。卜 l s b l l b m b a t c m i s b 8 t c h d l s fs e r v i c e 沙 3 3l s f 基本工作原理 图3 - 2 ：l s f 批处理结构 下面以最简单的情况考虑一个作业提交执行的流程陋1 ，假设作业提交主机与 执行主机是同一台主机，而且此主机是集群中的m a s t e r 型主机。 首先用户利用提交作业命令向l s b l i b 提交一个作业，然后l i m 将这条负载 信息向m l i m 转发，m l i m 基于各种情况将资源可用情况反馈给l i m 。前面提到 l s b l i b 将屏蔽应用程序和l s f 的交互细节，所以此处6 和7 并没有和用户进行 交互。l s b l i b 从l i m 得到资源信息后，作业将提交给m b d ，m b d 将作业置于某个 队列，综合当前资源情况将作业调度到s b d ，s b d 再将作业在r e s 上执行。 图3 3 ：作业处理流程 上面是一个作业的简单执行过程，从作业提交开始作业要成功执行要依赖于 很多条件： 首先是用户，用户在不同层级的优先级及执行权限将会约束作业的执行。指 定的作业应用程序配置参数，所处队列，及环境变量设置是影响作业调度策略的 主要因素。当然作业的成功执行最终要依赖于主机的可用性。 3 3 1 资源收集和管理 1 2 第三章嘲格计算和l s f 系统介绍 资源信息的收集由各个主机上的l i m 守护进程负责。对于一个集群，为了应 对网络环境地的复杂性，主机可以被动态或静态的添加与删除。为了提高资源管 理效率，提供了对具有同一条