（计算机应用技术专业论文）软件测试管理系统的研究与开发.pdf

北京邮电大学硕士学位论文软件测试钙理系统的研究与7 1 ：发 软件测试管理系统研究与开发 摘要 随着软件产业的飞速发展，软件的规模变得越来越大，同时软件 的复杂度也变得越来越高。软件测试作为软件质量保证体系中重要一 环，其工作的重要性也逐渐被国内大型软件企业所认可。但是，重开 发、轻测试的观念还是没有得到根本的改变，测试工作还是以开发工 作的配角身份出现，软件测试过程的管理也具有很大的随意性，软件 测试过程的规范性和有效性无法得到保证，从而造成软件质量、开发 费用，以及交付日期都得不到保障。因此建立有效、规范的软件测试 管理体系，减少软件测试过程管理的随意性是提高软件质量，从而提 高软件企业竞争力的首要因素。 “亿阳测试管理系统”是作者负责设计和开发的软件测试管理系 统。该系统已经在亿阳信通公司网络技术事业部正式投入使用。管理 的项目包括省级移动通信网络管理系统( 包括g s m 网络、c d m a 网络、v o l p 网络，以及小灵通网络等网络管理系统) ，计费系统和 资源管理系统等。实际使用结果表明，亿阳测试管理系统v1 0 可以 对软件测试的所有活动和文档进行管理，并管理软件测试各个阶段的 阶段测试报告和软件发布前的软件测试报告。不但大大提高了软件测 试的效率，减少了软件测试的人力和时间，而且可以对每个测试人员 的： 作量和每个项目消耗的测试工作量进行统计，并对软件测试阶段 各个活动的执行效果进行评估。该系统为亿阳信通建立了有效、规范 的软件测试管理体系，减少了软件测试过程管理的随意性，很好地满 足了相关部门对软件测试管理系统的需求。 本文第一章为论文的绪沦部分，主要介绍i ：仑文的研究背景、 会文 期问作者的主要工作，以及论文的内容和结构简介。在第二章，作者 首先介绍软件测试理论和软件川。靠性评估理沦，然后根据亿阳信通现 北京邮电大学硕二l _ 学位论文软件测试管理系统的研究与”发 在的软件测试流程需求，对软件测试过程进行了描述。在第三、第四 常，作者对“亿i s h n 试管理系统”的发计。和开发实现进行了洋细的介 绍。具体内容包括系统需求分析、实现策略、系统接口、用户界面设 计及功能实现等部分。第五章是文章的结论部分，在这一章，作者总 结了论文工作的成果与不足，并对后续的改进工作提出了相应的建 议。 作者在“亿阳测试管理系统”的设计开发过程中，首次提出了在 软件测试管理系统中添加软件可靠性评估功能的建议。该测试系统的 设计和开发经验对企业开发软件测试管理系统具有参考和借鉴作用， 并在软件测试方面有了一定的技术积累。 关键词：软件测试软件可靠性评估软件测试管理系统缺陷跟踪管 理 北京邮r 乜大学坝。l 学位论文软件测试管理系统f t ：ji ) l , l - j 4 1 发 d e s i g na n di m p l e m e n t a t i o no f s o f t 、m r et e s t i n gm a n a g e m e n ts y s t e m a b s t r a c t w i t ht h ed r a s t i c d e v e l o p m e n t o fs o f t w a r e i n d u s t r ya n di t s i n c r e a s i n g l yl a r g e rs c a l e ，s o f t w a r eh a sb e c o m em o r ec o m p l i c a t e d a sa n i m p o r t a n tl i n ki ns o f t w a r eq u a l i t yg u a r a n t e es y s t e m ，s o f t w a r et e s t i n gh a s g o tr e c o g n i t i o nf r o mn a t i o n a lm a i ns o f t w a r ee n t e r p r i s e s h o w e v e r , t h e o p i n i o ni nw h i c hs o f t w a r ed e v e l o p m e n to u t w e i g h ss o f t w a r et e s t i n gh a s n t g o tr a d i c a lc h a n g e t e s t i n gw o r ks t i l ls e r v e sa sas u p p o r t i n gr o l eo f s o f t w a r ed e v e l o p m e n tw o r k ，a n dt h em a n a g e m e n to v e rs o f t w a r et e s t i n gi s q u i t ea tw i l l ，l e a d i n gt on oi n s u r a n c eo ft h er e g u l a t i o na n de f f e c t i v e n e s so f s o f t w a r et e s t i n g c o n s e q u e n t l y , s o f t w a r eq u a l i t y , d e v e l o p m e n tc o s ta n d d e l i v e r yt i m ec a l ln o tb ea s s u r e d t h e r e f o r e t oe s t a b l i s ha ne f f e c t i v ea n d r e g u l a t e ds o f t w a r et e s t i n gm a n a g e m e n ts y s t e mi st h em o s ti m p o r t a n t f a c t o ri ni m p r o v i n gt h ec o m p e t i t i o na b i l i t yo fs o f t w a r ee n t e r p r i s e s t h i sp a p e rb e g i n sw i t hi n t r o d u c t i o no fs o f t w a r et e s t i n gt h e o r ya n d s o f t w a r e r e l i a b i l i t ya s s e s s m e n tt h e o r y , a n dt h e n g i y e s d e t a i l e d i n t r o d u c t i o no ft h ed e s i g na n dd e v e l o p m e n to fb o c oi n t e r t e l e c o m s o f t w a r et e s t i n gm a n a g e m e n ts y s t e mi nc h a p t e rt h r e ea n df o u r , a n dt h e r e i sac o n c l u s i o ni nt h e1 a s tc h a p t e r b o c oi n t e r t e l e c o ms o f t w a r et e s t i n g m a n a g e m e n ts y s t e mi s as y s t e m m a i n l yd e s i g n e da n dd e v e l o p e db y a u t h o r t h i ss y s t e mh a sb e e np u ti n t ou s ei nb o c oi n t e r - t e l e c o mc o r p p r o j e c t sm a n a g e db yt h i ss y s t e mi n c l u d ep r o v i n c i a lw i r e l e s sn e t w o r k m a n a g e m e n ts y s t e m ，b i l l i n gs y s t e ma n dr e s o u r c em a n a g e m e n ts y s t e m b o c oi n t e r t e l e c o ms o f t w a r et e s t i n gm a n a g e m e n ts y s t e mh a s s a v e da1 0 tf o r t h ec o m p a n yw i t hn on e e d o fp u r c h a s i n ge x p e n s i v e s o f t w a r et e s t i n gm a n a g e m e n ts y s t e m ，a n df o rt h ef i r s tt i m e ，i tg i v e st h e s u g g e s t i o no fa d d i n gs o f t w a r er e l i a b i l i t ya s s e s s m e n tf u n c t i o ni ns o f i w m l e t e s t i n gm a n a g e n a e n ts y s t e m k e y x v o r d s ：s o f t w a r e l e s l i l ：_ l g s o f t w a l 。e l e l i a b i l i l y a s s e s s m e n l s o f t w m et e s t i n gm a n a g e m e n ts y s t e m b u gm a n a g e m e n ts y s t e m 北京邮f 乜大学硕士学位论文 工5 8 8 1 3 8 软4 1 ：测试管驯系统的研究j ”发 独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究，1 作及 取得的研究成果。尽我所知，除了文中特别加以标注和致谢中所罗列 的内容以外，论文中不包含其他人已经发表或撰写过的研究成果，也 不包含为获得北京邮电大学或其他教育机构的学位或证书而使用过 的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中 作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名： 日期： 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文 的规定，即：研究生在校攻读学位期间论文工作的知识产权单位属北 京邮电大学。学校有权保留并向国家有关部门或机构送交论文的复印 件和磁盘，允许学位论文被查阅和借阅；学校可以公布学位论文的全 部或部分内容，可以允许采用影印、缩印或其它复制手段保存、汇编 学位论文。( 保密的学位论文在解密后遵守此规定) 保密论文注释：本学位论文属于保密在一年解密后适用本授权 书。非保密论文注释：本学位论文不属于保密范围，适用本授权书。 本人签名： 导师签名： 日期： 口期： 北京邮电大学硕士学位论文软件测试管理系统的研究t j 玎毁 第一章绪论 计算机软件作为一种产业，其生产具有共性。软件生产包括六个环节：软件 开发( 定义，设计，实现) 、软件生产管理、软件质量控制、软件配罱管理、软件 测试、软件维护。第一个环节加工软件产品，后五个环节决定软件生产的质量和 软件产品的质量： 软件生产管理：维护软件开发过程的有序性，决定软件生产的资源消耗 ( 人，物，信息，时闻) ，从而决定软件产品的价格： 软件质量控制：维护软件资源消耗与软件产品质量之间的均衡； 软件测试：保障软件产品的可接收性，为评价软件产品质量的提供依据； 软件配置管理：保障软件产品( 或其中间产品) 的可标识。陛、完整性和 一致性，为其它环节提供中介服务： 软件维护：保障软件产品的“售后服务”，为软件产品的更新提供信息。 缘于软件生产的特性，软件测试是软件生产的一个重点和难点。软件测试具 有四个层次的作用：找错、确认、组装和评估，其中确认和评估的意义与难度在 规模化的软件生产中远远大于找错和组装。软件生产迫切需要脱离手工作坊方式 的软件调试，在规范化软件测试的基础上实现规模化软件测试，达到提高软件产 品质量、降低软件生产消耗的目的。软件测试的方法学和软件测试的管理学应是 软件测试工作者关注的重点。 1 1引言 美国质量保证研究所对软件测试的研究结果表明：如果越早发现软件中存在 的问题，软件开发的费用就越低：在编码后修改软件缺陷的成本是编码前修改软 件缺陷的成本的1 0 倍，而在产品交付后修改软件缺陷的成本是在交付前修改软 件缺陷的成本的1 0 倍：软中l 二质蛾越离，软件发和后的维护费用越低。因此软中i ： 测试工作需要尽早进行，而且测试：l ：作做的越细致越好。 根撕对国际著名i t 企业的统汁它们的软件测试费用占整个软件工程所有 研发赞刚的5 0 以上。而中国的i t 企业的软件测试费用仅仅占整个软件工程 所有研发费用的2 0 左右。 千比之l _ _ j ，中困软件企业稿- 软件测试方谢引瑚际水准仍存在较大差距。这些 茇异j 兰要米源j j 咀下三个方叫：首先，在认以上歪”发、轻测试。没有认识到软 北京邮电大学硕【学位论文软件测试锚烈系统的研究与 发 件项目的如期完成不仅取决于丌发人员，更取决于测试人员：奠次，在铃理上随 意、简单，没有建立有效、舰范的软件测试管理体系：再者，软什测试缺少自动 化工具的支持，使得软件测试具有很大的随意性和不确定性，同时，也大大增加 了软件测试的时间和测试所需的费刖。所以对国内软伺：企业来说，需要提高对软 件测试的认识的同时，建立起完善的软件测试管理体系。 1 2研究背景 虽然国内软件企业和国外软件企业在软件测试这一环节上还存在不小的差 距，但随着国内软件业逐渐认识到软件测试的重要性后，国内专门研究软件测试 的部门相继产生，不少国产软件测试工具和软件测试管理系统也丌发出来了。 不过还是鲜有大型软件企业使用软件测试管理系统管理软件测试过程。不少软件 企业还在使用配置管理软件( 如：s o u r c es a f e ) 和质量控制软件( 如：r a t i o n a l r o s e ) 中的有关测试部分的模板来管理软件测试过程。但是这些软件，都没有 充分强调测试的价值，也没有给测试以足够的重视。 造成这种状况的原因主要有以下两个：首先，软件测试管理系统价格昂贵而 且介绍软件测试管理系统的书籍也是风毛麟角；其次，通用的软件测试管理系统 不一定符合某些公司的个别需要。 基于软件测试管理系统的这些特点，出于减少软件费用和开发符合公司功能 需要的软件考虑，亿阳公司需要开发软件测试管理系统“亿阳测试管理系统”。 作者的论文工作就是围绕这一项目展丌的。包括丌始设计和开发符合公司需要的 软件测试管理系统“亿阳测试管理系统”。 1 3论文期间主要工作 固内外软件测试管理系统虽然不少，但是还没有软件测试管理系统有软件可 靠性评估功能。提交给用户的软件产品的质量也无法得到保证。因此作者在7 1 ：发 亿测试管刊系统i 搏，对软件的可靠性理论进行了褶关研究。并将该功能加入了 亿测试管州系统的开发功能点c h 确：沦文研究期闷，作者首先研究了软件测试理论和软件可靠性评估理论。然 后根据亿川倍通公刊提出的软1 t ：测试管理系统的功能要求，砹计并丌发了亿阳测 试管理系统。在完成亿阳软件测试系统v 1 0 的) 1 ：发后，作者对所进行的研究和 了 ：发二 ：作进行了总结。 沦文蚓l i ；j - e 作的具体时j 1 _ i j 进度安排如下： 北京邮电大学硕士学位沦文软件测试管理系统的研究与丌发 2 0 0 2 年4 月至2 0 0 2 芏l i9jj ：查找软件测试和软r b j 稚性评估圳沦文章， 并进行研究。 2 0 0 2 年1 0 月至2 0 0 3 年5 门：亿阳测试管理系统殴计及编码实现。 2 0 0 3 年6 月至2 0 0 3 年8 月：测试管理系统自测试后投入使用，刀：始进一 步的软件测试。 2 0 0 3 年9 月至2 0 0 4 年1 月：根据提出的新需求增加新的模块，根据测试 发现的缺陷对亿阳测试管理系统进行修改。 2 0 0 4 年2 月至2 0 0 4 年3 月：整理静期理论研究和软件设计丌发的相关文 档，完成论文编写工作及论文答辩。 1 4论文内容及结构简述 本文的内容是作者对亿阳测试管理系统设计与开发工作的总结。总共分为五 童。 第一章为绪论部分。作者介绍了软件的研究背景，并阐述了论文期间的主要 工作。 第二章为理论部分。作者主要介绍软件测试相关理论，以及软件可靠性评估 的理论和关键技术。 第三章和第四章为本文的重点。在这两章中作者对亿阳测试管理系统的设计 和实现进行了描述。其中第三章介绍的是亿阳测试管理系统的设计，第四章介绍 的是亿阳测试管理系统的开发实现。 第五章是论文的结论部分，实际测试和使用情况表明本系统各功能模块很好 地实现了软件测试管理系统的基本要求，相关部门使用后反映良好。本章总结了 工作的成果以及不足。并提出了后期的改进建议。 ：f e 京l | | | 5 咆大学颁：i ：学位论文软件测试管理系统f l t t i j f 究与j 1 ：发 第二章软件测试技术及可靠性理论研究 本章首先介绍了软件测试i 1 s e l t 沦平测试原则，然后在结合亿阳信通现有的软 件测试流程和测试管理办法的基础上，提出了在实际进行软件测试的过程中，软 件缺陷跟踪管理和软件需求变更的十同关要求和定义。在本章的最后一节，给出了 软件可靠性评估采用的理论和实例。 2 1软件测试理论 本节对软件测试的定义、软件测试的目标和规则等理论和技术进行了介绍， 研究了软件测试的方法和软件测试的过程。在描述软件测试相关理论的同时，对 亿阳信通现在的软件测试流程、软件需求变更流程等方面的内容进行了介绍。 2 1 1 软件测试的定义的目标 很多人在定义软件测试的时候，都引用g r e n f o r dj m y e r s 在( t h ea r to f s o f t w a r et e s t i n g 一书中的观点： 软件测试是为了发现错误而执行程序的过程； 测试是为了证明程序有错，而不是证明程序无错误； 一个好的测试用例是在于它能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 这种观点一直为广大的软件测试人员所认可。但是软件测试不仅仪是简单的 程序执行过程，除了动态的软件测试过程之外，它还包括代码审查、代码走读等 静态测试的内容。从广义的角度来看，软件测试还应浚包括测试环境准备，测试 文档编写等活动。 因此壬啊门对软件测试给m 的定义是：软件测试是软件生命刷期巾的一个过 程，是为了发现错曝而检查翟l 序代码和执行程序的过程。 我们的软件测试的目标就是尽叫能多地发现软件表孤利潜在的不同类黝q 错误，弗目耗费最少时问和 ：作量。 北京邮f 黾大学硕士学位论文软件测试管理系统的研究与外发 2 1 2 软件测试的方法 软件测试的方法有白盒测试和黑盒测试两种。在下面我们将简单介绍这两种 软件测试方法。 白盒测试 白盒测试是己知软件的内部工作过程，可以通过测试证明每种内部操作是否 符合设计规格要求，所有内部成分是否已经通过检查。白盒测试又叫做结构测试。 自盒测试一般又分为静态测试与动态测试。静态测试不实际运行软件，主要 是对软件的编程格式、结构等方面进行评估，而动态测试需要在实际环境或实验 室环境中实际运行软件，并使用设计的测试用例去探测软件漏洞。 其中静态测试包括： 代码检查 代码走读 静态结构分析 代码质量度量 动态测试包括： 功能确认与接口测试 覆盖率分析 性能瓶颈分析以及内存分析 黑盒测试 黑盒测试是己知软件的功能设计规格的前提下进行测试，验证每个实现了的 功能是否符台要求，黑盒澳4 试又叫做功能测试，它不仅用于开发阶段的测试，更 常用于产品的测试阶段及维护阶段。用这种方法进行测试时，被测程序被当作看 不见内部的黑 盒。在完全不考虑程序内部结构和内部特 l f l - l i ；j 情况下，测试者仅依 掘程序功能的需求规范考虑确定测试j l j 例和推断测试结果的证确性。 完整的“任何情况”是无法验证的。为此黑盒测试也确一套产生测试用例的 方法，以产生有限的测试用例而覆盏足够多的“任何情况”。由于黑盒测试不需 要了解程序内部结构，所以许多高层的测试如确认测试、系统测试、验收测试都 采用掣盒测试。 燃盒测试首先是程序通常n 0 功能性测试。要求： 北京邮电大学硕士学位论文软件测试管理系统的例究0 发 每个软件特性必须被。个测试用例或个铍认r 叮的异常所覆n ： 用数据类型和数捷 值的最小集测试； 用一系列真实的数据类型和数摒值运行，测试超负荷、饱和及其他“最 坏情况”的结果： 用假想的数据类型和数据值运行，测试排斥不规则输入的能力： 对影响性能的关键模块，如基本算法、应测试单元性能( 包括精度、时 间、容量等) 。 不仅要考核“程序应该做什么? ”还要考察“程序是否做了不浚做的”， 同时还要考察程序在其他些情况下是否正常。这些情况包括数据类型 和数据值的异常等等。 黑盒测试常用下述几种方法： 等价类划分 因果图方法 边值分析法 猜错法 随机数法 这几种方法是从更广泛的角度来进行黑盒测试。每一个方法都力图能涵盖更 多的“任何情况”，但又各有长处，综合使用这些方法，会得到一个较好的测试 用例集。 黑盒测试检测的基本内容有： 功能错误或遗漏； 输入和输出接口的正确性； 数抛结构或外部信息访问错误： 性能要求实现情况； 初始化或终l j ：性错误。 2 1 3 软件测试的种类 功能测试 北京1 1 t l l l _ i r k 大学碳：【j 学位论文软件测试管理系统的 j f 究j l ：发 功能测试赴用来检查软什提“i 们j j | _ 务，例如，增加个新的客户帐0 。红：商 业应用中一个鼓重要的功能测试灶囱天数据库的事务处列! 能力的测试。 用_ 白界面测试 用户界面测试主要检查用户与软件之间的交互能力： 用户可否到达所有有权访问的功能界面? g u i 对象搡作是否与用户要求相符? 界面是否符合企业或工业标准? 极限测试 极限测试主要是针对该软件运行时处理的能力所做的测试，这个测试包括大 批量数据测试，长时间处理能力测试，异常情况等等的测试。 极限强度测试总是迫使系统在异常的资源配置下运行。例如： 当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用 例； 定量地增长数据输入率，检查输入子功能的反映能力； 运行需要最大存储空问( 或其他资源) 的测试用例； 运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例； 一个w e b 站点在大量的负荷下，何时系统的响应会退化或失败等等。 安装卸载测试 安装测试有两个目的。一是确保软件在各种条件下能正确安装，例如初次安 裴、升级、完全安装和客户定制安装。二足检查软件安装之后操作的证确性。为 达到此目的二般是运行一些为测试软件功能丽编写的程序。 恢复测试 恢复测试主要检查系统的容错能力。系统在软硬件敞障后保存数捌和控制爿 进行恢复的能力。 当系统出错时，能否在指定时m j 川隔内修i 错跌并m 新胴动系统。 北京邮电大学硕：【：学位论文软件测试管理系统的研究与开发 恢复测试首先要采用器种办法强迫系统失败，然后验汪系统是否能尽快恢 复。对于自动恢复需验证重新初始化( r e i n i t i a l i z a t i o n ) 、检务点( c h e c k p o n t i n g m e c h a n i s m s ) 、数据恢复( d a t ar e c o v e r y ) 乘l 重新启动( r e s t a r t ) 等机制的正确性； 对于人工干预的恢复系统，还需估测平均修复时问，确定其是否在可接受的范围 内。 一 安全测试 检查系统对于用户使用权限进行管理、控制和监督以防非法进入、篡改、 窃取和破坏等行为的能力。 安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例 如： 想方设法截取或破译口令： 专门定做软件破坏系统的保护机制； 故意导致系统失败，企图趁恢复之机非法进入； 试图通过浏览非保密数据，推导所需信息，等等。 理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全 设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无 利可图。 性能测试 对于那些实时系统，软件部分即使满足功能要求，也未必能够满足性能要求， 虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后， a ! 真实环境中爿能全面、可靠地测试运行性能系统性能测试是为了完成这一任 务。 性能测试需与极限测试棚结合，经常需要其他软硬件的配套支持。 川来衡餐系统i r , jz l l ；, j 应时间、，扣务处理述度和其。e , i l , jm 敏感n j 需求。 并能测 n ：与性能相关的工作负载和硬件配筒条件等。 文档测试 文档起软件的重婴组成部分，是软件生存周蚓各个1 i ：介段的产品描述。监 检玲各阶段文档的合适性。 北京邮电大学硕士学位论文软件测试管理系统的研究1j 段 评审文档质量的f 遽量准则有以i j 六条： 完备性：所有承担软件开发任务的单位，都必须按照标准的舰定编制干 应的文档，以保证在丌发阶段结束时其文档是齐全的。 f 确性：在软件丌发各个阶段所编写的文档的内容，必须真实地反映该 阶段的工作且与该阶段的需求相一致。 简明性：在软件开发各个阶段所编写的各种文档的语言表达应该清晰、 准确简练，适合各种文档的特定读者。 可追踪性：在软件开发各个阶段所编写的各种文档应该具有良好的可追 踪性。文档的可追踪性包括纵向可追踪性与横向可追踪性两个方面。酊 者是指在不同文档的相关内容之间相互检索的难易程度；后者是指确定 同一文档某一内容在本文档中的涉及范围的难易程度。 自说明性：在软件开发各个阶段所编写的各种文档应该具有较好的自说 明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表 达该软件其相应阶段的阶段产品的能力。 规范性：在软件开发各个阶段所编写的各种文档应该具有良好的规范性。 文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合 有关规范的规定。 一致性：在软件开发各个阶段所编写的各种文档应该具有较好的一致性， 不能出现前后不一致的情况。 健全测试 典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以 执行下一步大的测试努力。例如，如架一个新版软件每5 分钟与系统冲突，使系 统陷于泥潭，说明该软件不够“健全”，目前不其各进一步测试的条件。 衰竭测试 软r i ：或环境的修复或堕j f i 后的“佴测试”。可能很难确定需要多少避再次测 试。尤其在接近) f ：发刷j ! j t i ! i 束时。自动测试：| 刑这类测试尤其有用。 兼容测试 洲i j - t ：4 9 c q ! 一i l 个牝“l f i j f i , h ；牛软f im j 系统i i t q 络等j 牛搅州i o p _ - i - f j 蜘i f i g 。 北京邮电大学硕士学位论文软件测试篱删系统的研究与 发 比较测试 与竞争伙伴的产品的比较测试，如软件的弱点、优点或史力。 2 1 4 软件测试阶段 软件测试分如下几个阶段： 单元测试( u n i tr e s t ) 集成测试( i n t e r g r a t i o nt e s t ) 系统测试( s y s t e mt e s t ) a l p h a 、b e t a 测试 单元测试 单元测试是代码阶段最早期进行的测试，是面向软件设计中最小的可测试 单位一软件组件，是进行正确性检验的测试工作，是软件开发过程中的一种技术 性行为，它应用于软件模块或函数，检查程序的控制流和数据流，其目的在于发 现各模块内部可能存在的各种差错和检查每个程序模块和模块组的功能是否达 到设计要求。 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独 立进行单元测试。 单元测试需要结构化的白盒测试技术和功能化的黑盒测试技术，一般由开发 人员和q a 组完成。 在该阶段我们主要关注软件的可靠性和稳定性，然后是软件的运行性能。测 试的内容包括模块接口、局部数捌结构、边界条件、覆盖条件、出错处理等。 集成测试 在单元测试的基础上将模块组装成子系统或系统，测试各单元之间的互 操作盹，以及系统完成的功能与没计目标的距离。这是个随集成程度的不断提 ，荔而迭代逊行的过程。常常组成系统的各单元来自于不j 刊的丌发 ! | j 门，不完整的 或错嵌单元将在集成测试中暴露f j 来。象单元测试一样，集成测试也是由开发部 门或q a 完成，在集成测试中可能用到自盒和黑盒测j j t 技术。 0 一 北京邮电大学硕0 ：学位论文软件测试管理系统的研究与开发 系统测试 用户需求测试，根抛用户的实际环境进行系统测试。 系统i 9 1 4 试是在具备整体功能的软件上进行的，是软件产品在验收出厂和正式 递交给用户使用自# 必须进行的一种测试行为。它包括从最终用户的角度检查系统 的功能，出丌发组织或最终用户完成。如系统测试由用户进行，也称做验收测试。 其目的是检验最终产品与预期目标问的吻合情况。在系统测试阶段主要采用黑盒 测试法( b l a c kb o xt e s t ) ，按照客户提出的需求和系统目标确定测试范围和设 计测试方案。 系统测试的内容是测试该构造是否达到了系统需求和功能规格说明中的要 求，一般需要进行功能测试、性能测试、外部接口测试、人机界面测试、强度测 试、冗余测试、可靠性测试、安全性测试、恢复测试等。 a l p h a 、b e t a 测试 事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如， 用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明 了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应出 用户进行一系列“验收测试。验收测试既可以是非正式的测试，也可以有计划、 有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延 期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称 为a 、1 3 测试的过程，以期发现那些似乎只有最终用户才能发现的问题。 a 测试是指软件刃= 发公司组织内部人员模拟各类用户行对即将面市软件产 品( 称为a 版本) 进行测试，试图发现错误并修正。a 测试的关键在于尽可能逼 真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过e l 测试调整的软件产品称为p 版本。紧随其后的p 测试是 指软件丌发公司组织各方面的典型用户在h 常工作中实际使用p 版本，并要求用 户报告异常情况、握出批评意见。然后软r ：r i ：发公司再对b 版爿i 进行改错和完蒋。 2 1 5 软件测试的过程及软件测试模型 软件测试过程 软件测试过程包括以下j l 个环= 袖 f ，测试准备。包含的内容：仃： 北京邮电大学硕士学位论文软件测试管理系统的研究与”发 测试计划编写 测试方案的编写 测试用例设计 测试环境搭建 测试执行 测试报告编写 软件涸试模型 就象开发有开发模型一样，测试也有测试模型，尽管这些方法鲜为人知。 软件专家们不断在提供新的开发模型，这也是实际开发需要使然，与此同时， 在开发过程中也不断感受到这些已存在的方法的不足，例如，还没有比r u p 更 充分的方法，但r u p 也存在一些明显的不足，例如，r u p 没有对测试计划进行 定位。 v 模型 v 模型只得到软件业内比较模糊的认可。v - 模型宣称测试并不是一个事后弥 补行为，而是一个同开发过程同样重要的过程。v 模型如图2 1 所示： 雷蒙分斩 验收测试 i鎏 ” 擐萋设计 戆凇 麓 译缓设计 垂成嚣试 爹 o 编码 单元测试 图2 - 】v 模掣示意h v 模型最早由已故的p a u lr o o k 在8 0 年代后划提出，v 楔型被包禽在蜒心 团家计算中心文献中发却旨氆改进软什”发的效率和效果。v 模黔矧t 煳叫皓c 是英刚被接受，并被认为是瀑布模型的替代l 记，而在美刚则被瞑解为越之种潍 北京邮电大学硕士学位论文软件测试钳邢系统的研究与) i ：发 和模型。 在传统丌发过程中，仪仅把测试过程作为在需求分析、概要设 1 、详细设汁 及编码之后的一个阶段，事实上，v 模型的推出也是对此所进行的改进。在瀑前i 模型中，确实给人们造成了这样的不良影响，即在很多重要丌发活动完成后，测 试只是收尾工作，而不是主要的过程，尽管有时测试会占据项目周期一半的时f l j ， 很多项目主管却仍然还是坚持这么认为。 v 模型描述了一些不同的测试级别，并说明了这些级别所对应的生命周期中 不同的阶段。如图2 - 1 所示，左边下降的是开发过程各阶段，与此相对应的是 右边上升的部分，即各测试过程的各个阶段。请注意在不同的组织中，对测试阶 段的命名可能有所不同。 在模型图中的开发阶段一侧，先从定义业务需求丌始，然后要把这些需求不 断地转换到概要设计和详细设计中去，最后开发为程序代码。在测试执行阶段一 侧，执行先从单元测试开始，然后是集成测试、系统测试和验收测试。 v 模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清 楚地描述了这些测试阶段和开发过程期间各阶段的对应关系： 单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输 入验证过程中的边界值的错误。 集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与 其它程序部分之问的接口上可能存在的错误。 系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运 行，例如在产品设置中是否达到了预期的高性能。 验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上 的需要。 在不同的开发阶段，会f l j 现不同类型的缺陷和错误，所以需要不同的测试技 术和方法束发现这些缺陷。 在v 模型中，单元测试：j | ! = 基于代码的测试，最初山丌发人员执行，以验证 其可执行震序代码的并个部分足否已达剑了预期的功能要求； 集成测试验妊了2 个或多个单元之问的集成是否正确，并有 | 对性地对详细 设汁巾所定义的各单元之l u 埔q 接 i 进行检查； 。 在所有，元洲试硐i 集成测试完成后系统测试丌始以客户环境模拟系统n 勺运 行，以验汪系统灶含达到了在概要发h 。”所定义的功能和性能： 最后，；_ 技术部r j 完成了所有测试：r ：作后 = | = 业务专家或用户进行验l 改测试， 北京邮电大学硕士学位论文 软件测试管理系统的研究与，l ：发 咀确保产品能真诈符合用，o 业务1 l r , i 篮。 不。 参照软件测试模型的v 模型，改计的亿信通的软件测试流程如图2 2 所 图2 - 2 亿阳信通测试流程剧 4 一 北京邮电大学坝士学位论文软件测试管理系统的研究与) r 发 2 1 6 软件测试的原则 在设计有效的测试用例之前，软件1 ：程师必须全面了解软件测试的基本原 则。这些基本原则包括： 所有的测试都应追溯到用户需求。正如我们所知，软件测试的目标在于 揭示错误。而最严重的错误( 从用户角度来看) 是那些导致程序无法满 足需求的错误。 应该在测试工作真j 下丌始前的较长一段时间内就进行测试计划设计。测 试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计 模型被确定后立即开始，因此，所有测试可以在任何代码被产生前进行 计划和设计。 测试应从“小规模”开始，逐步转向“大规模“。最初的测试通常把焦点放在 单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错 误，最后在整个系统中寻找错误。 p a r e t o 原则应用于软件测试。简单而言，p a r e t o 原则暗示着测试发现 的错误中的8 0 很可能起源于程序模块中的2 0 。当然，问题在于如 何孤立这些有疑点的模块并进行彻底的测试。 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也 非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆 盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。 为了达到最佳效果，应该由独立的第三方来构造测试。“最佳效果”指 最可能发现错误的测试( 测试的主要目标) 。创建系统的软件工程师并不 是构造软件测试的最佳人选。 软件测试应该遵循尽快执行和重复测试的原则。 2 2缺陷跟踪管理 软件测试并不是一个简单的过程，在经历了一个宽整的测试生命周j l | j 之厉， 每一个阶段都会有相应的结果文档、脚本程守、志报告、软件缺陷记录产：_ i ， 那么针对这些内容我们如何管理，如何让这些测试的资产在后期维护阶段发攒 作用是很重要的。在测试的管到中缺陷管删( 软件缺陷跟踪) 是。个很重要n f | 【 成部分。 软件缺陷跟踪是从测试汁戈j j i ；【们训定到测试阼t i m 0 个耀体的j 三! _ 糕报告洲试 北京邮电大学硕= 二学位论文软件测试管理系统的研究与门：发 中发现的问题、查找原因并提供解决方案。 在b u g 跟踪过程中应当考虑的内容包括： 整理出有关错误的完整的信息 错误标识 错误的当前状况 错误出现时的情况 详细的错误描述 问题严重的程度( 通常使用分5 级或者用从”严重”到”低”的分类方法) 等等 网络上有很多免费缺陷管理工具：如b u z i l l a 、m a n t i s 等，一个缺陷管理系 统应具备的基本功能是记录产品缺陷、查询缺陷、处理解决缺陷、跟踪缺陷、统 计缺陷并产生报表等功能。 亿阳测试管理系统中也包括软件缺陷跟踪管理功能。该缺陷跟踪管理模块在 实现了缺陷跟踪管理系统的所有基本功能的基础上，还添加了缺陷日志记录等功 能。下面将详细介绍亿阳软件测试管理系统中的软件缺陷管理模块。 2 2 1 软件缺陷管理流程图 测试过程中的软件缺陷报告流程图如图2 3 所示。 北京邮电大学硕士学位论文 软件测试锐理系统的研究与) i ：发 2 2 2 缺陷生命周期 图2 - 3 亿阳信通软件缺陷报告流乖一! i 纠 在亿阳测试管理系统中的缺陷管理模块中，将软件缺陷的状念定义为5 种， 即：n e w ，f i x e d ，i s s u e ，b yd e s i g n 和a c t i v e 。缺陷的生命周期如图2 3 所示： c l o s e 测试人员填写 图2 3软件缺陷生命周期 2 2 3 缺陷严重级别 亿阳测试管理系统中的缺锔心踪模块将软件缺陷分成了5 级。用来表示软 件的缺陷严重程度。具体分级的标准如表2 1 所示： t fb u g 类m ? 北京邮电大学硕士学位论文软件测试铽理系统的研究7 ”发 重级别 在系统运行中出现严重错误导致系统陷于罐痪，并闷 无法自行恢复i f 常的缺陷。般，这类缺陷的出现辑i 消除 都无法控制，只有通过重启系统爿。能恢复j 下常。l i s j j ， 系统运行中出现的死机、系统瘫痪、通信链路频繁或长期 ；中断、系统的关键功能在某些情况丧失、系统关键性能不 ! 能达到设计指标等。 系统功能出现严重错误，严重影响系统运行和用户使 ! 用，但无需重启系统就可以恢复或者无法自行恢复，但对 系统影响相对较小的缺陷。比如，局部死机后自动复位恢 2 复、系统资源吊死导致的业务无法进行、系统状态或者数 j 据区混乱影响正常运行、操作维护性能数据或告警无法上 报、系统某些重要功能不稳定或者丧失、系统重要性能不 i j i 达到设计指标等。 系统功能实现上出现错误，导致某些功能不能正常使 ；用，或者系统某些功能未能实现，但对系统其他功能没有 3。严重影响的缺陷。比如，切换算法错误导致的不能正常切 换、操作维护配黄无法进行、程序中对异常缺乏保护导致 l 的功能不完善、系统某些提及的功能未实现等。 系统的重要和基本功能都已实现，但存在某些界面问 题，或者功能实现不合理，功能使用不方便，容易引起用 4户歧义或者误操作，对系统功能实现没有大的影响的缺陷。 比如，没有提供错误信息打印或者信息打印错误、缺乏对 某些输入参数的合法性检查、多余的功能实现等。 期望、建议( 不影响r e l e a s e ) ，系统功能、性能、 界碰、操作、工艺、组嘲、服务等各力面存在的需改进的 5地方，测试人员j , - t f l 沩d 类缺陷提交。这是希望系统有所 改进的建议，浚类问题一般不会对系统正常运行造成不良 影n m 但有可能涉及到系统安全性、稳定性方耐的隐患。 襄2 1 “软件缺陷的芬级标准 一 北京邮电大学硕二 学位论文软件测试管删系统的研究与j i ：发 2 。2 。4 缺陷优先级 亿阳测试管理系统中的缺陷跟踪模块将缺陷的优先级分成了4 级。用米表 示软件缺陷修改的优先程度。具体分级的标准如表2 2 所示： 优先级b u g 类型 1 ( m u s t f i x ) 这类b u g 对产品影响非常大，造成产品 不能移交。 这类b u g 对产品影响比较大，如果产品 12 ( s h o u l df i x ) 带着苦u g 发布给用户将会产量麻烦。 ； ； ； 这类b u g 对产品影响般，如果b u g ；3 ( f i xi f t i m e ) | 兰0 嚣筹盏篇嚣：潲? i 一定要f i x 。 1 m 一“m 。一，_ n 。h “k 一 _ w 、_ ； 这类b