软件测试2-测试模型与过程_第1页
软件测试2-测试模型与过程_第2页
软件测试2-测试模型与过程_第3页
软件测试2-测试模型与过程_第4页
软件测试2-测试模型与过程_第5页
已阅读5页,还剩60页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、本节内容本节内容软件开发模式软件测试模型软件测试流程软件开发模型是软件从最初构思到发布软件产品的全部过程,明确规定要完成的主要活动和任务,是软件项目开发的基础正确、适宜的软件开发方法对开发进程很重要。不同类型的软件的需求及规模不尽相同。不同软件过程采用不同开发流程主流软件开发过程瀑布模型螺旋模型RUP模型敏捷开发模型瀑布模型瀑布模型瀑布模型的核心思想是按工序将问题化简,将功能的实现与设计分开,采用机构化的分析与设计方法将逻辑实现与物理实现分开。软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试、运行维护。规定活动自上而下、相互衔接的固定次序,逐级下落。优点:易于理解;为项目提供

2、了按阶段划分的检查点。强调早期计划及需求调查;确定何时能够交付产品及何时进行评审与测试。缺点:需求调查分析只进行一次,不能适应需求变化;顺序的开发流程,使得在项目各个阶段之间极少有反馈。没有包含任何类型的风险评估;开发中出现的问题直到开发后期才能够显露,因此失去及早纠正的机会。通过过多的强制完成日期和里程碑来跟踪各个项目阶段。传统的瀑布模型,软件测试的地位和价值并没有体现出来,测试只能作为一个事后补救工作。早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。由于开发模型是线性的,用户只有等到整个过程的末期才能见

3、到开发成果,从而增加 了开发的风险。螺旋模式是瀑布模式与边写边改演化模式相结合,并加入风险评估所建立的软件开发模式。 主要思想是在开始时不必详细定义所有细节,而是从小开始,定义重要功能,尽量实现,接受客户反馈,进入下一阶段,并重复上述过程,直到获得最终产品。 每一螺旋(开发阶段)包括5个步骤:确定目标,选择方案和限制条件。 对方案风险进行评估,并能解决风险。 进行本阶段的开发和测试。 计划下一阶段。 确定进入下阶段的方法。优点:严格的全过程风险管理,测试介入早,发现问题早;强调各开发阶段的质量;提供机会评估项目是否有价值继续下去。缺点:螺旋开发需要巨大的回归测试周期,以确定添加的内容是否会对整

4、个系统的运行产生影响螺旋开发模式详细设计风险分析评估方案累计成本提交线制定计划原型1原型2原型3可运行原型风险分析风险分析需求计划开发计划集成与测试软件需求软件产品设计需求确定设计确定实现编码单元测试集成测试验收测试IBM开发的面向对象且基于网络的程序开发方法论:可以远距离网络协同完成开发工作面向对象软件工程的通用业务流程,微型版螺旋开发具有统一的软件流程构架,提供规范的开发任务分配和职责明确分配,其目标是确保可预期和预算内开发满足用户高质量产品RUP认为,所有的阶段(需求及其它)都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。RUP把一个项目分为四个不

5、同的阶段:初始阶段 :包括用户沟通和计划活动两个方面,强调定义和细化用例,并将其作为主要模型。细化阶段 :包括用户沟通和建模活动,重点是创建分析和设计模型,强调类的定义和体系结构的表示构建阶段 :将设计转化为实现,并进行集成和测试发布阶段 :将产品发布给用户进行测试评价,并收集用户的意见,之后再次进行迭代修改产品使之完善。敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试(24小时内),具备可视、可集成和可运行使用的特征。敏捷原则:个体和交互胜于过程与工具;可运行的软件胜于面面俱到的文档,客户合作

6、胜于合同谈判;响应变化胜于教条遵循计划需求变更,日常工作,共享状态,发现潜在问题软件测试生命周期包含在软件生命周期中测试生命周期主要横跨两历程:软件开发阶段的测试历程软件运行维护阶段的测试活动软件测试与软件开发过程的关系测试在开发阶段的作用:项目规划阶段:负责从单元测试到系统测试的整个测试阶段的监控。需求分析阶段:确定测试需求分析、系统测试计划的制定,评审后成为管理项目。详细设计和概要设计阶段:确保集成测试计划和单元测试计划完成。编码阶段:由开发人员进行自己负责部分的测试代码。在项目较大时,由专人进行编码阶段的测试任务。测试阶段(单元、集成、系统测试):依据测试代码进行测试,并提交相应的测试状

7、态报告和测试结束报告。V模型W模型H模型X 模型测试前置模型(测试驱动模型)V模型是最广为人知的测试模型,由Paul Rook在世纪年代后期提出的,旨在改进软件开发的效率和效果。V模型与瀑布模型有共同特性,开发与测试实现层级对应其重要之处在于从左到右,描述了基本的开发过程和测试行为,非常明确地标明了测试过程中存在的不同级别,描述了这些测试阶段和开发过程期间各阶段的对应关系需求分析需求分析概要设计概要设计详细设计详细设计编码编码单元测试单元测试集成测试集成测试系统测试系统测试验收测试验收测试单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要

8、求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。V模型中的过程从左到右,描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标注了测试过程中存在的不同类型的测试。V模型的缺陷存在局限性,仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,只针对程序进行的寻找错误的活动,忽视了测试活动对需求分析,系统设计等活动的验证和确认的功能,直到后期的验收测试才被发现,违背了测试尽早介入的原则。W模型由Evolutif公司提出。W模型从V模型演化过来,实际上开发是V,测试也是与此并行的V。相对于V模型,W模型增加了软件各开发阶段中应同步进行的验证和确认活动。测试伴随整个软件开发

9、周期,而且测试的对象不仅仅是程序,需求、设计等同样要测试,测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。优点需求分析完成后,就参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。非常明确地标注了生产周期中开发与测试之间的对应关系。缺点W模型也存在局限性。在W模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作工作。这样就无法支持迭代,自发性以及变更调整的开发模型。对于当前软件开发复杂多变

10、的情况,W模型并不能解除测试管理面临着困惑。测试准备测试准备测试执行测试执行测试流程测试流程其他流程(设计、其他流程(设计、编码等流程)编码等流程)测试就绪点测试就绪点测试的“微循环”与前两种模型相比,H模型充分地体现了测试过程。H模型说明:1、软件测试不仅仅指测试的执行, 还包括很多其他的活动。2、软件测试是一个独立的流程, 贯穿产品的整个开发周期, 与其它流程并发进行。3、软件测试要尽早准备, 尽早执行。软件测试可以根据被测物的不同而分层次进行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。很好地处理测试与开发的交接过程(

11、交接的过程是一个时间段,而不是一个点)左边描述的是针对多个单独程序片段所进行的相互分离的编码和测试,通过集成最终合成为可执行的程序,然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封版并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,给有经验的测试人员在测试计划之外发现更多的软件缺陷。但可能对测试造成人力、物力和财力的浪费,对测试员的熟练程度要求比较高。V模型与W模型与开发模型相对应,非常正规,但实践性较弱;H模型代表了迭代,由于没有和开发相对应,有时候难于确认测试就绪点,对

12、于缺乏经验的测试员更是如此;X模型强调了单元测试、集成测试以及探索性测试,实用性较强,但并没有涵盖整个开发周期,比如软件设计阶段,形成不完整的模型。软件开发是一个自顶向下,逐步细化的过程;软件测试则是以相反顺序的自底向上,逐步集成的过程。软件测试工作必须要通过制定测试计划、测试设计、测试开发、测试执行、测试评估几个阶段来完成。测试以下程序: void static main(int argc, char * argv) printf(“Hello world!”);测试用例编号测试用例编号说明说明操作过程操作过程输入值输入值期望结果期望结果1测试程序功能运行软件无在控制台打印出“Hello w

13、orld!”将程序编译、连接形成可执行程序Hello.exe,然后运行它,由于测试不要求输入值,因此运行软件即是执行测试。程序在控制台打印出“Hello world!”字样测试的实际结果与期望的结果一致,程序的打印功能是正确的。软件测试生命周期 回归测试回归测试制定测试计划制定测试计划 测试设计测试设计 测试开发测试开发 执行测试执行测试评估测试评估测试缺陷缺陷测试策略是制定测试计划的重要参考依据目的:如何以最少的人力、物力和时间等资源投入来达到最佳测试效果的综合方法,原因在于完全的测试是不可能的,对任何程序的测试必定是不完全的。那么,最显然的测试策略就是努力使测试尽可能完全。影响因素: 测试

14、完成的标准成本、人力、时间等资源状况针对需求定义测试类型、方法及工具等由于时间和成本的约束,软件测试的最关键问题是: 所有可能的测试用例中,哪个子集所有可能的测试用例中,哪个子集最有可能发现最多的错误?最有可能发现最多的错误?代表性、典型性正确和错误的或者异常的输入多考虑用户实际使用场景避免含糊的测试用例(三种状态)尽量将具有相类似功能的测试用例抽象并归类尽量避免冗长和复杂的测试用例软件测试的主要评测方法包括:覆盖评测测试覆盖是对测试完全程度的评测,它建立在测试覆盖基础上。覆盖指标提供了“测试的完全程度如何?”这一问题的答案。最常用的覆盖评测是基于测试需求和测试用例基于测试需求和测试用例的测试

15、覆盖和基于已执行代码基于已执行代码的测试覆盖。质量评测质量是对测试对象的可靠性、稳定性以及性能的评测。评估测试对象的性能时,侧重于获取与行为相关的数据,如响应时间、事务处理数、内存占用率、操作可靠性等。立项会议需求评审测试工作启动测试设计阶段设计内容评审测试交接测试交接测试实施测试实施阶段阶段回归测试回归测试同行评审同行评审测试总结报告测试验收测试归档工作总结由工程技术委员会召开立项会议,会议主要对项目的可行性进行分析,并且确定项目经理及项目测试组长。过程要点过程要点详细说明详细说明输入条件立项会议工作内容 项目(产品)可行性分析。 项目经理的确定. 根据项目信息,测试经理确定测试组长。退出标

16、准测试组长确定责任人测试经理(确定测试组长)注: 1需求定义基本完成,此时应在评审会议召开之前发给测试团队,预留时间给测试相关人员熟悉、理解。 2测试部参与人员由测试部经理指定,主要由测试组长、测试设计等人员组成(还应包括配置管理人员、质量保证人员)。过程要点过程要点详细说明详细说明输入条件需求定义完成工作内容测试团队成员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题,相关人员解答并确认。退出标准所有人员对需求无异议参与人员需求调研人员,工程技术委员会,开发组,测试部责任人工程技术委员会过程要点过程要点详细说明详细说明输入条件项目(产品)开发计划完成工作内容1项目/产品经理邮件通知测试

17、组长正式测试交接时间,测试规模预估等,同时提交相关最新项目资料:项目需求及软件规格定义文档、项目开发计划、开发设计过程中提供概要设计、详细设计文档等其他相关资料2组建测试小组,确定小组成员。并指定测试设计工程师及测试实施工程师。3召开测试启动会议,开发团队提供需求规格说明书和开发计划,确认开发组与测试组对需要交接的测试内容、测试目标达成一致,统一项目组的目标和测试的工作重点。 退出标准测试小组成立,双方对测试目标及内容达成一致。责任人产品(项目)经理,测试组长在正式测试任务下达前,开发团队应在项目(产品)开发计划完成后及时向测试团队下达预通知,告之较为确切的测试日期,提供当前最新的相关资料。部

18、门经理和测试组长组建测试小组,并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。测试小组成员可预先熟悉必要的项目(产品)资料。过程要点过程要点详细说明详细说明输入条件项目需求文档建立,项目开发计划完成工作内容根据项目的需求文档、设计文档,按照测试计划文档模板编写测试计划。测试计划中应该至少包括以下关键内容:依据项目背景及要求,确定测试环境。测试需求需要测试的范围,估算出测试所花费的人力资源和各个测试需求的测试优先级测试策略确定项目的测试计划内容,整体测试的测试方法和每个测试需求的测试方法,同时做好测试进度安排及人员调整。测试资源本次测试所需要用到的人力、硬件、软件、技术的资源测试

19、组角色明确测试组内各个成员的角色和相关责任可交付工件在测试组的工作中必须向项目组提交的产物,包括测试计划、测试报告等等风险管理列举出测试工作所可能出现的风险测试计划编写完毕后,必须提交给项目组全体成员,并由项目组组中各个角色组联合评审。退出标准测试计划由项目组评审并通过.在项目开发过程中,要适时的对测试计划进行跟踪,以及评估此计划的完整性、可行性,在项目结束时还要最后评估一下测试计划的质量责任人测试设计工程师 过程要点过程要点详细说明详细说明输入条件测试需求明确,测试计划明确工作内容根据测试计划设计测试用例,设计参考原则:等价类划分边界值分析错误推测等业务知识及相关流程退出标准 测试用例需要覆

20、盖所有的测试需求 测试用例集需进行评审并通过 项目进行过程中,适时的根据需求变更来对测试用例进行维护责任人测试组成员在需求分析文档确立基线以后,测试组需要针对项目的测试需求编写测试用例,在实际的测试中,测试用例将是唯一实施标准。过程要点过程要点详细说明详细说明输入条件测试计划、测试用例集完成工作内容评审测试计划内容的正确性及合理性:测试环境、测试资源;测试需求范围,各个测试需求的优先级;测试策略及风险管理等;评审测试用例集:测试用例优先级测试用例集基于需求的覆盖程度退出标准测试计划及测试用例集评审通过责任人同行测试组,项目经理,测试计划及测试用例的设计工作完成后,需通知项目组相关成员召开评审会

21、议。在这之前需要将待评审的内容发给相关人员熟悉和理解。过程要点过程要点详细说明详细说明输入条件测试设计内容评审完毕,开发团队编码工作完成,并已完成内部测试;工作内容1. 开发组根据测试启动会上所规定的内容,填写送测单,向测试组提交测试内容。2. 测试小组检查提交部件的完整性和可测性: 检查接收的测试内容(按照测试启动会上所规定的交接内容); 检查程序是否有病毒; 能否正确安装/卸载; 检查送测的软件是否完整,能否进行测试;退出标准提交部件经测试组检验通过责任人产品(项目)经理,测试组长过程要点过程要点详细描述详细描述输入条件测试组长于前一工作日定出当日的测试计划,确定可用的测试用例。工作内容

22、测试实施工程师根据测试计划中分配给自己的测试任务和提供的测试用例,实施相应的测试用例。 记录实施用例的结果,提交当日测试纪录。 提交缺陷。退出标准测试用例中的所有任务被执行,结果被记录。责任人测试组成员实施测试用例将花费测试组大部分时间,这些工作都是建立在前期很多计划工作的基础上。过程要点详细描述输入条件测试组完成了预定周期的测试任务工作内容测试组长根据此轮测试的结果,编写阶段性测试报告,主要应包含以下内容:测试报告的版本、测试的人员和时间测试所覆盖的缺陷测试组在这轮测试中所有处理的缺陷,报告测试组长处理的缺陷和实施工程师验证的缺陷。不仅要写出覆盖缺陷的总数,还要写明这些缺陷的去向测试新发现的

23、缺陷数量、上一版本活动缺陷的数量经过此轮测试,所有活动缺陷的数量及其状态分类测试评估写明在这一版本中,哪些功能被实现了,哪些还没有实现,只需写明和上一版本不同之处即可急待解决的问题写明当前项目组中面临的最优先的问题,可以重复提出退出标准在每轮测试结束之后应尽快将符合标准的测试报告发给全项目组责任人测试组长在约定的测试周期完成之后,测试组长需要总结此次测试的结果,编写阶段性测试报告。过程要点过程要点详细描述详细描述输入条件在每轮测试中,按照现有的测试用例没有新的缺陷被发现,测试报告中全部的活动缺陷都被解决。工作内容 测试组将按照测试计划中对于回归测试的策略对产品进行回归测试,回归测试的用例属于测

24、试用例的一部分或者是全部测试用例,但不能超出原先预定的测试用例的范围。 记录用例实施结果,提交回归测试记录。退出标准 回归测试所运行的用例全部通过 缺陷经过验证 所有缺陷都被指明处理方式责任人测试实施工程师 在每轮测试结束之后,由测试组重新拷贝修改后的最新版本,进行回归测试。过程要点过程要点详细描述详细描述输入条件回归测试结束,所有缺陷都被关闭。工作内容1.进行对测试组所测试项目或产品的测试审查工作.基本原则:不依据所设计测试用例,进行自由测试.测试时间保持在3个正常工作日以内.如发现严重缺陷,则一轮测试结束后,更新版本,执行回归测试.2.提交当日测试纪录.3.编写同行审查总结报告(报告以简单

25、为好).退出标准同行审查没有新的缺陷或没有严重缺陷产生.责任人同行测试组过程要点过程要点详细描述详细描述输入条件测试组完成了所有的测试实施工作,同行审查结束.工作内容测试组长根据测试的结果,按照测试总结报告的文档模板编写测试总结报告,测试报告必须包含以下重要内容:测试资源概述多少人、多长时间。测试结果摘要分别描述各个测试需求的测试结果,产品实现了哪些功能点,哪些还没有实现缺陷分析按照缺陷的属性分类进行分析测试需求覆盖率原先列举的测试需求的测试覆盖率,可能一部分测试需求因为资源和优先级的因素没有进行测试,那么在这里要进行说明测试评估从总体对项目质量进行评估测试组建议从测试组的角度为项目组提出工作

26、建议退出标准测试组长完成了符合标准的测试报告,发送给全项目组。责任人测试组长在回归测试结束之后,测试组长将要编写测试总结报告,对测试进行总结,并且提交给全体项目组,为产品的后续工作提供重要的信息支持。过程要点过程要点详细描述详细描述输入条件测试组完成了所有的测试实施工作,测试组长完成符合标准的测试总结文档工作内容由测启会上约定的验收组成员,对本次测试收进行验收,验收内容包括:测试效果验收测试是否达到预期目的测试文档验收测试过程文档是否齐全,可信,符合标准测试评估从总体对测试的质量进行评估测试建议对本次测试工作指出不足,需要在以后工作中改进的地方宣布测试结束测试验收组成员签字宣布本次测试结束退出

27、标准测试验收通过,测试验收会议记录整理完毕参与人员验收组人员,测试经理,测试组长,产品(项目)经理测试验收工作是在以上工作全部结束后,对测试的过程,效果进行验收,宣布测试结束。过程要点过程要点详细描述详细描述输入条件测试验收通过工作内容归类、存档测试过程涉及到的文档,主要包括以下文档(必须)测试任务书测试计划书测试用例书阶段性测试报告测试总结报告测试验收会议记录退出标准全部文档归类完毕,版本号封存责任人测试组长测试归档是在测试验收结束宣布测试有效,结束测试后,对测试过程中涉及到各种标准文档进行归类,存档。过程要点过程要点 详细描述详细描述输入条件项目验收工作完成。工作内容由质控部经理,测试组长

28、召开项目测试工作总结会议,会议内容主要为:测试组长对项目期间的整个测试组的工作情况进行总结,指出测试工作中存在的问题,同时也对工作中表现好的地方给与肯定。(具体包括整个测试情况、流程实施、人员安排、测试方法等)参与本次项目测试工作的所有成员个人体会和建议。讨论测试工作中出现的问题,寻求更好的解决办法。宣布解散测试小组。退出标准所提问题寻求到较好解决方式,测试小组解散参与人员测试部所有成员测试归档是在测试验收结束宣布测试有效,结束测试后,对测试过程中涉及到各种标准文档进行归类,存档。软件测试的周期性是“测试-改错-再测试-再改错”这样一个循环过程,如下图所示。测试周期测试周期开发开发/ 改错改错改错改错测试周期测试周期改错改错串行方式串行方式开发者开发者: .开发者:开发者:并行方式并行方式测试者:测试者:开发开发/ 改错改错开发开发/ 改错改错最终回归测试最终回归测试回归测试回归测试1测试周期测试周期1功能冻结功能冻结代码冻

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论