计算机软件测试技术书籍(郑人杰)

所需积分/C币:16 2012-04-01 5.31MB PDF
评分

经典书籍,高校教程,适合各种测试人群学习
方案;对可供开发使用的资源<如计算机馊、软件、人力等)、成本、可取 得的效益和开发的进度作出佔计;制定完成开发任务的实施计划 (Implementation Plan) ②需求分析:对开发的软件进行详细的定义,由软件人员和用户共同 讨论决定,哪些需求是可以满足的,并且给予确切的描述;写出软件需求 说明书( Software Requirement Specifications)或称软件规格说明书,以及初 步的用户手册( System User' s Manual),提交管理机构审查。 ③软件设计:设计是软件工程的技术核心。在设计阶段应把已确定的 各项需求转换成相应的体系结构,在结构中每一组成部分是功能眀确的模 块。每个模块都能休现相应的需求。这一步称为概要设计( Preliminary Design)。进而进行详细设计( Detail Design),即对每个模块要完成的工作 进行具体的描述,以便为程序编写打下基础。上述两步设计工作均应写出 设计说明书,以供后继工作使用并提交审查。 ④程序编与:把软件设计转换成计算机可以接受的程序,即写成以某 个程序设计语言表示的源程序清单。这一工作也称为编码。当然,写出的 程序应该是结构良好、清晰易读,且与设计相一致的。 ⑤测试:测试是检验开发工作的成果是否符合要求,它是保证软件质 量的重要手段。通常测试工作分为三步,即: 单元测试( Unit Testing)—一单独检验各模块的工作 集成测试( Integrated Testing)—将已测试的模块组装起来进行检验。 确认测试( Validation Testing)-一按规定的需求,逐项进行有效性测试, 以决定开发的软件是否合格,能否提交用户使用 ⑥运行和维扩:已交付用户的软件投入正式使用以后便进入运行阶 段。这阶段可能持续若干年,甚至几十年。在运行中可能有多种原因需要 对它进行修改。其原因包括:运行屮发现了软件屮有错误,需要修正;为 了适应变化了的软件工作环境,需要作相应的变更;为进·步增强软件的 功能,提高它的性能,使它进一步完善和扩充 以上6步表明每个软件从它的酝酿开发,直至使用相当长时间以后, 被新的软件代替而退役的整个历史过程。按此顺序逐步转变的过程可用 个软件生存期的瀑布模型加以形象化描述。图1.1给出了这一瀑布模型 从图中可看出,从左上到右下如同瀑布流水 计划 定义 阶段 需求分析 设计 开发 阶段 编码 测试 维护阶段 行维护 图1.软件生存期的瀑布模型 逐级下落。在最后的运行中可能需要多次维护,图中用环形箐头表示。此外,在 实际的项目开发中,为了确保软件的质量,每一步骤完成以后都要进行复查,如 果发现了问题就要及时解决,以免问题积压到最后造成更大的困难。每一步骤的 复查及修正工作正是图中给出向上箭头。此外, 评价 运行 图中还指明了6个步骤,划分的3个阶段:软件定 义阶段、软件开发阶段及软件维护阶段。 计划 测试 值得注意的是,上述软件维护工作不可简单地 看待。原因在于维护工作不仅仅是修改程序。在软 件运行的过程中若有必要修改,得提出充分的修改 需求分析 编码 理由,经过审核,才能肯定下来。接着需要经历制 设计 订修改计划、确定新的需求、修改软件设计、修改 编码、进行测试以及重新投入运行等一系列步骤 图12软件生存周期 这些步骤正是上述开发个新软件的步骤。若是运 行中多次提出修改,将多次经历这些步骤。我们把 这一过程用图1.2来表示,并称此为软件生存周期。实际上软件生存,周期和 软件生存期表达的是同一内涵,为简便起见通常只称为软件生存期。 1.2软件测试的意义 软件测试在软件生存期中占有非常突出的重要位置,究其原因是多方面的 根据 Boehm的统计,软件开发总成木中,用在测试上的开销要占30%到50% 如果我们把维护阶段也考虑在内,讨论整个软件生存期,开发测试的成本比例公 有所降低,但不要忘记,维护工作相当于二次开发,乃至多次开发,其中必定也 包含有许多测试工作。因此,有人估计软件工作有50%的吋间和50%以上的成 本花在测试工作上。 软件测试究竞是什么意思,它包括哪些工作?这些问题常常被一般人误解 甚至从事计算札工作的人员也可能弄不清楚。 测试(Test)-词最早出于占拉丁字,它有“罐”或“容器”的含义。人们当 吋用·种特殊的容器检验金属中含有某种元素是多少。到现在测试·词已经普遍 使用了,在工业。生产和制造业中测试被当作一个常规的生产活动,它常常和产 品的质量检验密切相关。在这些行业中测试的含义似乎是明确的,但在计算机软 件领域内则不然。比如,什么是程序测试,什么是软件测试,它们之间有什么差 別?测试和调试是一回事吗?它们之间又有什么差別?对于这些概念的不同解释可 能会涉及到测试的目的和方法。 “程序测试”的说法最早几乎是和“程序编写”同时出现的。从当时的观点 来看,谁写出的程序,谁去测试它,谁去使用它,测试被当作编写程序以后很自 然要做的一步工作。并且在测试时不仅要发现程序里的错误,而且要排除错误。 这时测试与调试混为一谈,完全不加区分。一段时间里人们谈论和写文章所涉及 到的测试一词,实际上是调试即排错( debug请参看木节最后两段)。其实这两者 是完全不同的两个概念。我们还注意到,那时的计算机多用来完成数值计算任务。 程序运行后所得的计算结果常常采用以手工计算其中一部分数据的办法来比较, 从而判断程序的正确性。这在当时还是简单易行的。但随着计算机应用领域的拓 ,所写程序要解决的问题也不仪仅限于数值计算了。上述手工计算进行校验的 办法难于适应了,然而对于程序正确性检验的基本模式并没有改变。这就是给出 测试数据,运行被测程序,将所得结果与预期结果进行比饺,从而判断程序的正 确性。我们称此为程序正确性测试(参看图1.3)。 程序 计算机 测试数据 比较 SOFTWARE X,Y TIONS 需求规格说明已知的输入 输出数据 图1.3程序正确性测试 70年代中以来,形成了软件生存期概念。这时人们对于软件测试的认识更 泛也更深刻了。这对于软件产品的质量保障以及组织好软件开发工具有着重要 的意义。首先,由于能够把整个开发工作明确地划分成若干个开发步骤,就把复 杂的问题按阶段分别加以解决。使得对于问题的认识与分析、解决的方案与采用 的方法以及如何具体实现在各个阶段都有着明确的目标。其次,把软件开发划分 成阶段,就对中间产品给出了若干个监控点,提高∫开发过程的可见度,为各阶 段实现目标的情况提供了检验的依据。各阶段完成的软件文档成为检验软件质量 的主要对象。这时对软件质量的判断决不只限于程序本身。即使只淡程序本身的 正确性,它也和编码以前所完成的需求分析及软件设计工作进行得如何密切相 关。很显然,表现在程序中的错误,并不·定是编码所引起的。很可能是详细设 计、概婁设计阶段,甚至是需求分析阶段的问趣引起的。因此,即使针对源程 序进行测试,所发现的问题其根源可能在开发前期的各个阶段。解决问题、纠正 错误也必须追溯到前期的工作。正是考虑到这一情况,我们通常把测试阶段的工 作分成若干步骤进行。这些步骤包括:模块测试,集成测试、确认测试和系统测 试。对程序的最小单位——模块进行测试时,检验每个模块能否单独工作,从而 发现模块的编码问题和算法问题;进而将多个模块联结起来,进行集成测试,以 检验概要设计中对模块之间接口设计的 决定软件与系统的 问题;确认测试则应以需求规格说明书中 配合关系 的规定作为检验尺度,发现需求分析的问 题;最后进行的系统测试是将开发的软件 需求分析 与硬件和其它相关因素(如人员的操作, 数据的获取等)综合起来进行全面的检 验,这样的作法必将涉及到软件的需求以 概要设计 及软件与系统中其它方面的关系。图1.4 给出了测试工作与软件开发前期工作的 详细设计 关系。图中开发工作是自上而下进行的, 而几种不同的测试都会涉及到前期工作 编码 的不同阶段。 如果我们着眼于整个软件生存期,特 别是着眼于编码以前各开发阶段的工作 模块测试 来保证软件的质量,就需要突破原来对测 试的理解。也就是在开发的过程中,需要 集成测试 不断地复查与评估、不断地进行检验,以 利于把发现的错误和问题得到及时的解 决,而不让这些错误和问题隐藏起来,影 确认测试 响后期的开发工作。总之,贯穿在整个开 发各阶段的复查、评估与检测活动,远远 系统测试 地超出了程序测试的范围,可以统称为确 认、验证与测试活动(V,V& T Validation, 图1.4测试与开发前期工作的关系 erificationand testing)时为了方便,也 简称为测试,不过这是广义的测试概念 所谓确认,它是指如何决定最后的软件产品是否正确无误。比如,编写出的 程序相对于软件需求和用户提岀的要求是否符合,或者说程序输岀的信息是用户 所要的信息吗?这个程序在整个系统的环境屮能够正确稳定地运行吗?这里自然 包含了对软件需求满足程度的评价。在软件宀品开发完成以后,为了对它在功能 性能、接口以及限制条件等方面是否满足需求作出切实的评价,需要在开发的初 期,在软件需求规格说明书中明确地规定确认的标准。 所谓验证,它是指如何决定软件开发的每个阶段、每个步骤的产品是否正确 无误,并与其前面的开发阶段和开发步骤的产帛相一致。验证工作意味着在软件 丌发过程中开展·系列活动,旨在确保软件能够正确无误地实现软件的需求。 确认和验证是有联系的,但也有明显的差别。 Boehm在1981年是这样来描 述两者差别的:确认要回答的是:我们正在开发一个正确无误的软件产品吗?而 验计要回答的是:我们正开发的软件产品是正确无误的吗? 总之,确认、验证与测试在整个软件开发过程中作为质量伓证的手段,应当 最终保证软件产品的正确性、完全性和一致性。我们可以把确认、验证与测试活 动分为三类(见图1.5) ①完整性检验—一验证每一开发阶段(或开发步骤)中产品的完整性;分析每 一产品,确保其内部的一致与完全。例如,分析需求规格说明书,以找出不一致 的需求或矛盾的需求。比如,其中规定输出报告,但该报告所需要的数据是无法 得到的 ②进展检验—一保证各个开发阶段(或开发步骒)之间其规格说明书的完全 性和一致性。例如,后一阶段的工作确是前阶段工作的进一步细化。 ③适用性与充分性检验——把取得的结果与对问题的理解作比较,保证所完 成的结果是必要而充分的解。 在整个软件生存期各阶段中确认、验证与测试活动包括: ①需求分析阶段 制定项目的V,Ⅴ&T计划:确定V,V&T的目标;安排V,V&T的活动; 选择采用的方法和工具;制定进度并作出预算 确定与测试用例相关的需求:这些需求构成∫一组基础的测试用例。从而 有助于澄清并且确定软件需求的可度量性,同时也作为验收测试的基础。 复审并分析需求:其目的 在于确保规定的需求能够对整个 软件产品 问题取得有指望的和可用的结 果,针对问趣叙述的清晰性、完 全性、正确性、一致性、可测试 )完整性检验 性和可跟踪性进行复审。 ②概要设计阶段 复审并修订V,V&T计划。 想格说明/扩展与细化 规格说明 针对要执行的逻辑功能而 生成的测试数据,补充软件需求。 复审并分析概要设计:确 保内部的一致性、完全性、正确 (b)进展检验 性及清晰性;是否满足需求 ③详细设计阶段 ·针对功能测试数据进行设 当前对问 计:设计要考虑到基于系统物理 题的理解 所得成果 结构的测试数据。 复审并分析详细设计规格 说明:确保内部的一致性、完全 c)适用性与充分性检验 性、正确性及清晰性; 检验详细设计是否对概要设 图1.5三类确认、验证与测试活动 计做出∫正确无误的细化;确认所做的设计满足于需求 ④编码及测试阶段 完成测试用例规柊说明:针对编码过程中对设计的修改补充或修正测试用 例规格说明。 复审、分析并测试程序:检査是否遵循了编码标准;自动或手工分析程序; 运行测试用例,以保证满足验收要求 进行产品验收 ⑤运行及维护阶段 ·软件评佔:对软件的运行情况作出评仁,以保证它能继续满足用户的需求。 软件修改评估:当提出修改 、J的要求时也要进行评估,修改以后 要进行复审和测试,以确保修改正 确无误。 回归测试:重新运行前口正 (a)项目开发前的设想 b)分析员的描述 确无误的测试用例,以便消除由于 软件修改而带来的各种错误 最后,为了较为形象地措述软 件开发面临的实际问题,请读者参 看图1.6。虽然这只是一个比喻, 但的确在定程度上反映了实际 (c)完成的设计 ()程序员做出的产品 情况。软件项日的实践一再告诉我 们,为了确保软件产品能够符合用 户的需要,必须着眼于整个软件生 存期,在每个开发阶段采取措施, 进行各个阶段的V,V&T活动。 使之不致在开发完成后,发现和用 (e)现场的安装 P)用户原来的需要 户的需求有如此大的差距。 图 软午开发面临的实际问题 在这一节的最后,我们讲一下 关于排错( debug)-词的来源。程序 中排错,我们现在都称为 debug,其原始意义是提住小虫(bug)。这里有关于该词 的一件轶事,它对理解排错与测试的区别是有益的。 1945年夏在美国弗吉尼亚某地海军水上武器研究中心运行着 MarkII计算 机,这是以继电器为元件的老式计算工具。由于没有空调设备,夏夜中的机房很 热。当时正值大战期间,计算任务十分繁忙。可是 MarklE突然停止了工作,在 多方查找后发现了原因:一只飞蛾从窗外进入,落在继电器的触点上。电磁式继 电器触头将其打扁,纹使电路中断而停札。机务人员捉到飞蛾,放于札器运行臼 志,并记载了这一情况。G.M. Hopper为此创一新词,把排除机器运行的故障 统称为“捉虫”—— debuggin。此后,人们也用该术语称呼程序排错。其实, 它和测试一词的含义完全不同 3什么是软件测试 经过了多年的软件开发实践,积累了许多成功的开发经验,同时也总结出不 注:图1.6引自伦敦人学《计算中心通讯》,第53期( The University COmputer Centre Newsletter,NO.53)。 少失败的教训。在此过程中,软件测试的重要意义逐渐被人们普遍认识。看到软 件测试在开发成本中占有如此大的比例,同时它又是保证软件质量的主要手段 因而逐渐受到重视。然而,究竞什么是软件测试,这一基本概念很长时间以来存 在着不同的观点。一些人为软件测试给出了定义,但由于强调的方面不完全一致 至今难于给出统一论述。即使那些公认的测试定义,也还存在问题。特别是目前 仍然有许多人对于“什么是软件测试?”持有不正确的观点,这也恰恰是不能很 好地做好软件测试工作的原因 回答这一问题的典型说法有: ·对照规格说明检查程序; 找出程序中的隐藏错误: 确定用户接受的可能性 确认系统已经能够提供使用了; 取得该软件已能工作的信心 表明程序执行得正确无误; 表明程序中错误并未岀现 ·理解程序运行的限制; 弄清该软件不能做什么 检验该软件的能力; 验证软件文档 使自己确信开发任务L经完成; 等等。 必须承认,以上这些说法并非都错,有的也有其正确的方面,但毕竟含有缺 陷 1973年W. Hetzel曾经指出,测试是对程序或系统能否完成特定任务建立 信心的过程。这种认识在·段吋间内曾经起过作用,但后来有人提出异议。认为 我们不应该为了对一个程序建立信心或显示信心而去作测试。此后他又修正了自 己的观点,他说:“测试是目的在于鉴定程序或系统的属性或能力的各种活动, 它是软件质量的一种度量”。这一定义实际上是使测试依赖于软件质量的概念。 但软件质量又是什么呢?对于很多从事实际工作的人员来说,质量一词和测试 样抽象,也难以捉摸。事实上,尽管我们可以为软件质量的含意给岀确切的解释, 但影响软件质量的因素也不是一成不变的。在某一环境下得到的高质量产品,在 换了另一环境以后,很可能变成低质量的,甚至是完全不适用的。如果我们把质 量理解成“满足需求”,那将是可以接受的。假定软件项目的需求是完全的,开 发出的产品又能满足这些需求,那就是高质量的软件产品。1983.年IEEE提 出的软件工程标准术语中给软件测试下的定义是:“使用人工或自动手段来运行 或测定某个系统的过程,其日的在于检验它是否满足规定的需求或是弄清预期结 果与实际结果之间的差别”。这就非常明确地提出了软件测试以检验是否满足需 求为目标。 G.J. Myers则持另外的观点,他认为:“程序测试是为了发现错误而执行 程序的过程”。这一测试定义明确指出“寻找错误”是测试的目的。相对于“程 序测试是证明程序中不存在错误的过程’, Myers的定义是对的。因为把证明程 序无错当作测试的目的不仅是不正确的,是完全做不到的,而且对做好测试工作 没有任何益处,甚至是十分有害的(关于这一点我们在本章下一节还要进一步说 明)。从这方面讲,我们接受 Myers的定义以及所蕴含的方法论和观点。不过, 这个定义规定的范围似乎过于狭窄,使得它受到很大限制。因为如前所述,除去 执行程序以外,还有许多方法去评价和检验一个软件系统。按照 Myers的定义, 测试似乎只有在编码完成以后才能开始。另一方面,“测试”归根结底包含“检 ”“评价”和“测验”的意思,这和“找错”显然是不同的。 以上讨论的软件测试定义都是强调软件的正确。有些测试专家认为软件测试 的范围应当包括得更广泛些。J.B. Goodenough认为测试除了要考虑正确性以 外,还应关心程序的效率、健壮性( robustness等因素,并且应该为程序调试提供 更多的信息。他列出了一张测试组成表(图1.7) 软件测试 可接受性测试 诊断信息测试 效率测试 〔调试) (性能评价 正确性 可箪性 有用性 健壮性 性触 理论课题 测试工具 路径制导 符号执行 图1.7 Goodenough关于软件测试的定义 S.T. Redwine认为,软件测试应该包含以下几种测试覆盖 ①功能覆盖 ②输入域覆盖 ③输出域覆盖 ④函数交互覆盖; ⑤代码执行覆盖 他还给出」检查表。 ①验训技术(目前验证技术仅适用于特殊用途的小程序, 至于测试的范围,AE. Westley将测试分为四个研究方向 ②静态测试(应逐步从代码的静态测试往高层开发产品的静态测试发展); ③测试数据选择; ④测试技术的自动化 为了进一步明确测试的范围和具体目标,G· I. Myers和B. Beizer都详细列出了 各种软件错误的炎型,并指出软件测试的目的就是要找出这些错误。 14应该怎样认识软件测试 如何正确地认识和对待软件测试常常是做好软件测试工作的前提。事实上,到现

...展开详情
立即下载 最低0.43元/次 身份认证VIP会员低至7折
举报 举报 收藏 收藏
分享
img
meixihan

关注 私信 TA的资源

上传资源赚积分,得勋章
相关内容推荐