《第四部分软件测试与维护ppt课件.ppt》由会员分享,可在线阅读,更多相关《第四部分软件测试与维护ppt课件.ppt(120页珍藏版)》请在三一办公上搜索。
1、第四部分 软件测试与维护,问题,软件测试的目的是什么?有哪些过程?什么是黑盒技术?什么是白盒技术?有哪些方法?什么是集成测试?有哪些集成策略?各有什么特点?如何构造测试用例?什么是调试技术?有哪些方法?测试有哪些模型?各有什么特点?因果图方法用于什么情况?什么是逻辑覆盖?如何进行基本路径测试?什么是软件可维护性?维护有哪些类型?如何提高可维护性?,第12章 软件测试,软件测试的目的是什么?软件测试有哪些过程?什么是黑盒技术?什么是白盒技术?有哪些方法?什么是集成测试?有哪些集成策略?各有什么特点?因果图方法用于什么情况?如何构造测试用例?测试有哪些模型?各有什么特点?什么是逻辑覆盖?如何进行基
2、本路径测试?什么是调试技术?有哪些方法?,软件测试三个最佳实践,尽早测试连续测试自动化测试,软件测试的定义,软件测试是为了发现缺陷而执行程序的过程 测试是为了证明程序中有错误,而不是证明程序中无错误 一个好的测试用例指的是它可能发现至今尚未发现的缺陷 一次成功的测试指的是发现了新的软件缺陷的测试,验证与确认,验证(Verification)是指已经实现的软件产品是按照它的需求做的,是符合需求说明书的。确认(Validation)是指已经实现的软件产品或产品组件在用户环境下实现了用户的需要。验证测试指测试人员在模拟用户环境的测试环境下对软件进行测试确认测试是指测试人员在真实的用户环境下检查软件同
3、行评审及测试是主要的验证方法确认主要是对中间及最终产品的检查与验收确认与验证紧密结合,测试人员组织,测试工作的组织形式,分为:测试主管:负责全面地组织和协调工作测试组:测试组由业务人员组成,负责测试案例的编写、具体的测试操作、测试问题的记录与反馈,以及对已修改问题的回归测试和验收等工作。支持组:支持组由业务人员和技术人员共同组成,一方面负责对测试问题进行分析,提交问题解决方案,并作相应修改,软件测试目的、任务,目的:确认软件的质量提供信息软件测试不仅是在测试软件产品的本身,而且还包括软件开发的过程任务:寻找Bug避免软件开发过程中的缺陷衡量软件的品质关注用户的需求,软件测试原则,Pareto法
4、则: 80的成就仅仅源于20的人的努力,也称8020法则木桶理论:强调改进我们木板最短的那一块. 只有短木板变为长木板,桶装水才会更多测试不能证明软件无错完全测试软件是不可能的软件测试是有风险的行为测试无法显示潜伏的软件缺陷程序中存在错误的概率与该程序中已发现的错误数成比例软件缺陷的免疫力并非所有软件缺陷都能修复,测试最佳平衡点,软件测试完成标准,覆盖评测:测试的完全程度如何基于需求的测试覆盖测试覆盖 = T(p,i,x,s) / RfT其中:T 是用测试过程或测试用例表示的测试 (Test) 数(已计划的p、已实施的i或成功的s)。RfT (Requirement for Test)是测试需
5、求的总数基于代码的测试覆盖:已经执行的代码的多少测试覆盖 = Ie / TIic其中:Ie 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数;TIic (Total number of Items in the code) 是代码中的项目总数,软件测试完成标准,质量评测:测试完全程度的评测缺陷报告:缺陷分布(密度)报告允许将缺陷计数作为一个或多个缺陷参数的函数显示,描述当前软件的质量状态。缺陷龄期报告是一种特殊类型的缺陷分布报告。缺陷龄期报告显示缺陷处于特定状态下的时间长短,表示研发团队对质量的反应能力缺陷趋势报告按照状态将缺陷计数作为时间的函数显示,用来标识软件
6、质量变化的趋势性能评测:侧重于获取与软件行为相关的数据动态监测 - 实时获取并显示正在执行的各测试脚本的状态响应时间/吞吐量 - 特定主角和/或用例的响应时间或吞吐量的评测百分位报告 - 数据已收集值的百分位评测/计算比较报告-两个(或多个)数据集之间的差异或趋势,软件测试过程模型,V 模型:展示了在软件生命周期中何时开始测试W模型:测试伴随着整个开发周期H模型:改进缺陷,V模型,V 模型的特点就是根据瀑布模型的阶段划分V 模型揭示了软件测试活动分层和分阶段的本质特性,W模型,测试的对象不仅仅是程序,需求、功能和设计同样要测试,H模型,H模型是一个软件测试管理模型贯穿于整个产品周期,与其它流程
7、并发的进行当某个测试时间点就绪时,软件测试即从测试准备阶段进入测试执行阶段,软件测试策略,单元测试:测试软件中的基本组成单位采用白盒测试方法,尽可能发现模块内部的程序差错工作量较大单元测试越早越好集成测试:是把多模块按照一定的集成方法和策略,逐步组装成子系统,进而组装成整个系统的测试多模块集成方式一般都采用渐增式,有自顶向下、自底向上和混合式(“三明治”)三种确认测试:确认已组装的程序是否满足软件需求规格说明书系统测试:保证所实现的系统确实是用户所想要的,单元测试,单元测试任务包括:模块接口测试模块局部数据结构测试保证临时存储在模块内的数据在程序执行过程中完整、正确模块边界条件测试采用边界值分
8、析技术模块中所有独立执行通路测试保证模块中每条语句至少执行一次模块的各条错误处理通路测试基本路径测试和循环测试,单元测试,应为测试模块开发:一个驱动模块(driver)若干个桩模块(stub)面向对象的软件:最小的可测试单元是封装起来的类和对象不能再孤立地测试单个操作,而应该把操作作为类的一部分来测试,集成测试,原因:多模块程序的各模块之间可能有比较复杂的接口单元测试中往往使用了测试软件,即“驱动”模块或/和“桩”模块模块组装后的积累误差可能达到了不能容忍的地步集成测试策略自顶向下:优点是能较早展示整个程序的概貌,取得用户的理解和支持;缺点是测试上层模块时要使用桩模块,很难模拟出真实模块的全部
9、功能自底向上测试从下层模块开始,设计测试用例比较容易,但是在测试的早期不能显示出整个程序的概貌混合式测试的优点综合了以上两种测试策略的长处,确认测试,目的是确认已组装的程序是否满足软件需求规格说明书(SRS)的要求有效性测试主要采用黑盒测试方法配置复审主要采用人工评审方法确认测试是由软件开发单位组织实施的最后一项开发活动,系统测试,包括:功能测试:也称为需求测试,主要测试系统的功能性需求性能测试:主要测试系统的非功能性需求强度测试安全性测试安全性测试恢复测试 软件配置审查 兼容性测试验收测试安装测试,测试用例设计,测试用例被看作是有效发现软件缺陷的最小测试执行单元,也被视为软件的测试规格说明书
10、设计好测试用例,也是保证测试工作的最关键的因素之一目的:尽可能地找出软件错误杜绝冗余的测试寻找最佳测试方法使得程序失效显而易见,设计测试用例,分为:白盒设计方法逻辑覆盖法语句覆盖、判定覆盖、条件覆盖基本路径覆盖法黑盒设计方法等价类划分法边界值划分法错误推测法因果图法阶段是测试策略、测试计划、测试描述和测试过程,如何编写可测试的程序,分离界面和实现契约式设计注意模块的粒度减少模块之间的耦合控制随机因素为支持测试提供额外的函数,黑盒测试技术,黑盒测试是根据程序组件的规格说明测试软件功能的方法,所以也称为功能测试被测对象作为一个黑盒子,它的功能行为只能通过研究其输入和输出来确定,所以又称为软件输入/
11、输出接口测试黑盒测试注重于功能和数据信息域的测试黑盒设计测试用例的原则:对于有输入的所有功能,既要用有效的输入来测试,也要用无效的输入来测试。经过菜单调用的所有功能都应该被测试,包括通过同一个菜单调用的组合功能也要测试。设计的测试用例数量,能够达到合理测试所需的“最少”(减少测试成本)。设计的测试用例,不仅能够告知有没有错误,而且能够告知某些类型的错误存在或不存在(提高测试效率),黑盒测试技术,等价类划分边值分析法错误推测法因果图法,等价类划分,等价类划分是一种典型的黑盒测试方法等价类划分的办法是把程序的输入域划分成若干等价类,然后从每个部分中选取少数代表性数据当作测试用例两类:有效等价类无效
12、等价类原则:pp208举例:ATM机,边界值分析,边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值,设计测试用例包含全部边界值的方法几条原则:输入条件规定了取值范围,或是规定了值的个数,则应以该范围的边界内及刚刚超出范围的边界外的值程序规范中提到的输入或输出域是个有序的集合(如顺序文件、表格等)就应注意选取有序集的第一个和最后一个元素作为测试用例,举例,某程序读入a、b、c三个代表三角形三条边的整数值,根据a、b、c值判断组成三角形的情况。请列出a、b、c变量所有输入不合理的等价类,使用边界值分析方案设计测试用例,不合理的等价类 测试数据( a,b,c) 非三角形 (10,1
13、0,21) (10,21,10) (21,10,10) 退化情况 (10,5,5) (5,10,5) (5,5,10) 零数据 (0,0,0) (0,11,0) (0,10,12) 负数据 (-5,6,7) (-5,-5,10) (-10,-10,-10) 遗漏数据 (,) (10,) (10,10,)无效数据 (A,B,C) (+,=,*) (10.6,A,7e3),错误推测,错误推测法采用的是一种凭借先验知识对被测对象做类比测试的思路错误推测法还常被用于“错误成群”现象的处理,因果图法,等价类划分法并没有考虑到输入情况的各种组合因果图法步骤:从程序规格说明书的描述中找出因(输入条件)和果(
14、输出或程序状态的改变)因果图转换为判定表为判定表中的每一列设计一个测试用例,因果图法符号与关系,举例,问题描述:有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下橙汁或啤酒的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示零钱找完的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示零钱找完的红灯灭,在送出饮料的同时退还5角硬币。,分析列出原因和结果,原因: 1. 售货机有零钱找 2. 投入1元硬币 3. 投入5角硬币 4. 押下橙汁按钮 5. 押下啤酒按钮建立中间结点,表示处理中间状态
15、:11. 投入1元硬币且押下饮料按钮12. 押下橙汁或啤酒的按钮12. 应当找5角零钱并且售货机有零钱找12. 钱已付清结果:21. 售货机零钱找完灯亮 22. 退还1元硬币 23. 退还5角硬币24. 送出橙汁饮料25. 送出啤酒饮料,画出因果图,加上约束条件,由于 2 与 3 ,4 与 5 不能同时发生,分别加上约束条件E其他或、与关系,转换成判定表,白盒技术,白盒测试是有选择地执行(或覆盖)程序中某些最有代表性路径的测试方法,所以也称为逻辑覆盖测试软件自身的缺陷:逻辑错误和该错误存在的路径被运行的可能性成反比程序的逻辑流可能是违反直觉的书写或打印错误出现在主流和非主流逻辑路径上的可能性是
16、一样的白盒测试方法是从程序的控制结构路径导出测试用例集的,白盒测试和黑盒测试的方法对比,白盒测试技术,逻辑覆盖法基本路径测试法循环测试方法,逻辑覆盖法,语句覆盖:选择足够的测试用例,使得程序中每个语句至少都能执行一次判定覆盖:执行足够的测试用例,使得程序中每个判定至少都获得一次“真”值和“假”值,即使得程序中的每一个分支至少都通过一次条件覆盖:执行足够的测试用例,使得判定中每个条件获得各种可能的结果判定条件覆盖:执行足够的测试用例,同时满足判定覆盖和条件覆盖的要求条件组合覆盖:执行足够的测试用例,使得每个判定中条件的各种可能组合都至少执行一次,举例,Procedure Example(Var
17、A,B,x:real)begin if(A1)and(B=0) then x:=x/A; if(A=2)or(x1) then x:=x+lEnd;,逻辑覆盖举例,语句覆盖:路径ace,选择输入数据为:A=2,B=0,x=3判定覆盖:选择输人数据为:(1)A=3,B=0,x=l(沿路径acd执行)(2)A=2,B=1,x=3(沿路径abe执行)条件覆盖:(1)A2,Bo,x4(沿路径ace执行)(2)A1,Bl,xl(沿路径abd执行)判定条件覆盖(1)A=2,B=0,x=4(沿路径ace执行)(2)A=1,B=l,x=l(沿路径abd执行),逻辑覆盖举例,条件组合覆盖:八种组合结果(1)A1
18、,B=0 (5)A=2,x1(2)A1,B0 (6)A=2,x2,x1(4)A0 (8)A2,x1四种测试用例来覆盖:(1)A2,Bo,x4(2)A2,B1,xl(3)Al,Bo,x2(4)A1,B1,xl,基本路径测试,基本路径测试法是根据程序的控制流路径设计测试用例的一种最基本的白盒测试技术考察测试路径的有用工具:程序控制流图任何过程设计描述方法(如PDL、流程图、N-S图、PAD图等)都可以映射到一个相应的程序控制流图描述,其映射要点为:一个或多个顺序语句可映射为程序图的一个节点,用带标识的圆表示。一个处理框序列和一个判别框可映射为程序图的一个节点。程序控制流向可映射为程序控制流图的边(
19、或称为连接),用方向箭头表示(类似于流程图中的方向箭头)。一条边必须终止于一个节点,即使该节点不代表任何语句。有边和节点限定的范围称为区域(区域应包括图外部的范围)。,控制流图,确定程序图的环形复杂性,环形复杂性是一种以图论为基础的,为程序逻辑复杂性提供定量测度的软件度量独立路径是指程序中至少引进一个新的处理语句集合,或一个新条件的任何一条路径,程序流程图映射程序流图,程序图G的环形复杂性V(G)计算,三种方法:V(G)等于程序图G的区域数。V(G)= EN + 2,E是程序图G的边数,N是程序图G的节点数。V(G)= P + l,P是程序图G中判定的节点数,图矩阵,程序图还常用一种表格形式的
20、数据结构辅助描述程序图的这种表格表示形式,称为图矩阵(Graph Matrix)图矩阵是一个方阵,其大小,即行、列数等于程序图的节点数每行、每列对应于标识的节点,矩阵项对应于标识节点间的连接,即节点之间的边在每个矩阵项再加入连接权值,为控制流提供额外的一些信息,这种形式的图矩阵称为连接矩阵,程序流图的图矩阵示例,举例,控制流图,确定环形复杂性度量V(G),1)V(G)= 6 (个区域)2)V(G)=EN+2=1612+2=6其中E为流图中的边数,N为结点数;3)V(G)=P+1=5+1=6其中P为谓词结点的个数。,确定基本路径集合,路径1:1-2-9-10-12路径2:1-2-9-11-12路
21、径3:1-2-3-9-10-12路径4:1-2-3-4-5-8-2路径5:1-2-3-4-5-6-8-2路径6:1-2-3-4-5-6-7-8-2,为每条独立路径设计测试用例,1)路径1(1-2-9-10-12)的测试用例: scorek=有效分数值,当k 100, k i;期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average6)路径6(1-2-3-4-5-6-7-8-2)的测试用例:scorei=有效分数, 当i50;期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average,循环测试,简单循环嵌套循环串接循环无结构循环,循环结构,简
22、单循环,零次循环:从循环入口直接跳到循环出口。一次循环:查找循环初始值方面的错误。二次循环:检查在多次循环时才能暴露的错误。m次循环:此时的mn,也是检查在多次循环时才能暴露的错误。n(最大)次数循环、n+1(比最大次数多一)次的循环、n-1(比最大次数少一)次的循环。,嵌套循环,从最内层循环开始,设置所有其他层的循环为最小值;对最内层循环做简单循环的全部测试。测试时保持所有外层循环的循环变量为最小值。另外,对越界值和非法值做类似的测试。逐步外推,对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值,所有其它嵌套内层循环的循环变量取“典型”值。反复进行,直到所有各层循环测试完毕。
23、对全部各层循环同时取最小循环次数,或者同时取最大循环次数。对于后一种测试,由于测试量太大,需人为指定最大循环次数,串接循环,如果各个循环互相独立,则串接循环可以用与简单循环相同的方法进行测试。如果有两个循环处于串接状态,而前一个循环的循环变量的值是后一个循环的初值。则这几个循环不是互相独立的,则需要使用测试嵌套循环的办法来处理,集成测试技术,集成测试,也叫组装测试或联合测试集成策略:自底向上集成测试自顶向下集成测试Big-Bang集成测试核心集成测试,自顶向下集成,自顶向下集成是构造程序结构的一种增量式方式,它从主控模块开始,按照软件的控制层次结构,以深度优先或广度优先的策略,逐步把各个模块集
24、成在一起深度优先策略首先是把主控制路径上的模块集成在一起广度优先的策略按照层来测试模块具体步骤:以主控模块作为测试驱动模块,把对主控模块进行单元测试时引入的所有桩模块用实际模块替代;依据所选的集成策略(深度优先或广度优先),每次只替代一个桩模块; 每集成一个模块立即测试一遍;只有每组测试完成后,才着手替换下一个桩模块;进行回归测试,示例,自顶向下集成特点,优点:在于能尽早地对程序的主要控制和决策机制进行检验,因此较早地发现错误。缺点:是在测试较高层模块时,低层处理采用桩模块替代,不能反映真实情况解决办法:第一种是把某些测试推迟到用真实模块替代桩模块之后进行第二种是开发能模拟真实模块的桩模块第三
25、种是自底向上集成模块第一种方法又回退为非增量式的集成方法,使错误难于定位和纠正,并且失去了在组装模块时进行一些特定测试的可能性;第二种方法无疑要大大增加开销;第三种方法比较切实可行,自底向上集成,自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。模块是自底向上进行组装的,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)事前已经完成组装并经过测试,所以不再需要编制桩模块步骤:按照概要设计规格说明,明确有哪些被测模块按时间线序关系,将软件单元集成为模块,并测试在集成过程中出现的问题将各软件模块集成为子系统(或分系统)将各子系统集成为最终用户系统,核心系统先行集成测试,思想:
26、先对核心软件部件进行集成测试,在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。步骤如下:对核心系统中的每个模块进行单独的、充分的测试,必要时使用驱动模块和桩模块对于核心系统中的所有模块一次性集合到被测系统中,解决集成中出现的各类问题按照各外围软件部件的重要程度以及模块间的相互制约关系,拟定外围软件部件集成到核心系统中的顺序方案外围软件部件添加到核心系统以前,外围软件部件应先完成内部的模块级集成测试按顺序不断加入外围软件部件,排除外围软件部件集成中出现的问题,形成最终的用户系统,高频集成测试,高频集成测试是指同步于软件开发过程,每隔一段时间对开发团队的现有代码进行一次集成测试
27、步骤:选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化设置版本控制工具,以确保集成测试自动化工具所获得的版本是最新版本。 测试人员和开发人员负责编写对应程序代码的测试脚本。 设置自动化集成测试工具,每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试,并将测试报告汇报给开发人员和测试人员。 测试人员监督代码开发人员及时关闭不合格项,接口测试,接口测试的目的是为了测试接口,尤其是那些与系统相关联的外部接口重点是要检查数据的交换,传递和控制管理过程,还包括处理的次数步骤:定义通用的命令接口结构,用文本文件记录接口相关结构信息通过对该文本文件进行逐行的
28、语法解析,将文件中的描述转化为统一结构的链表验证来自外层的数据是否正确根据提示用户输入的信息验证发送到其它层的数据是否正确,自动测试工具,白盒测试工具:针对代码进行测试静态测试工具:代表有Panorama系列、Telelogic公司的Logiscope软件、PR公司的PRQA软件等。动态测试工具:代表有Rational公司的Purify系列、Compuware公司的DevPartner软件等。黑盒测试工具:利用脚本的录制(Record)回放(Playback),模拟用户的操作,然后将被测系统的输出记录下来同预先给定的标准结果比较功能测试工具:Rational公司的TeamTest、Robot、
29、Quantify,Compuware公司的QACenter,MI的WinRunner等。性能测试工具;Radview公司的WebLoad,MS公司的WebStress、Application Center Test,IBM的LoadRunner等,调试,调试(debug)又称排错或纠错调试的任务就是根据测试时所发现的错误,找出原因和具体的位置,进行改正调试工作:对错误进行定位并分析原因,即诊断;对于错误部分重新编码以改正错误;重新测试,调试过程,调试策略,试探法:凭借经验猜想故障的位置,然后使用适当的调试技术回溯法:检查错误症状,确定最先发现症状的地方,然后沿着源程序的控制流往回追踪程序代码,
30、直到找出错误根源或确定故障范围为止对分查找法:在程序“中点”附近加入这些变量的正确值,然后检查程序的输出进行对分查找归纳法:系统化的推理方法,即从个别或特殊推断一般的方法演绎法:一种系统化的推理方法,即从一般前提条件出发,经过不断排除过程导出结论的方法,归纳法,归纳法调试策略是从线索出发,通过分析这些线索之间的关系找出故障四个步骤:收集有关数据:列出程序中已经知道的,对或不对的一切数据组织数据:整理数据以便发现规律导出假设:分析研究线索之间的关系,力求找出它们的规律,提出故障的一个或多个假设验证假设:解释所有原始的测试结果,演绎法,演绎法调试策略是先列出所有可能成立的原因或假设,然后逐一排除不
31、正确的原因,直到最后证明出剩下的原因确实是错误根源为止。四个步骤:列举可能的原因:根据已有的测试信息和测试数据,列举出所有可能产生该错误的原因排除不正确的原因:分析已有的信息/数据,列出原因,排除原因,选取最大可能性的那个原因为假设。细化假设:利用已知的线索进一步细化确定的假设,使之更具体化,以便确定故障的位置验证假设:做法与归纳法的相同,ATM取款机测试分析,基本事件流插入银行卡输入该银行卡的密码输入取钱金额系统同步银行主机用户提款,银行卡自动退出,ATM机场景,等价类划分,边界值分析,测试用例(第一组),测试用例(第二组),测试用例(第三组),测试用例(第四组),测试用例(第五组),测试用
32、例(第六组),测试用例(第七组),测试用例(第八组),测试用例(第九组),测试用例(第十组),测试用例(第十一组),测试用例(第十二组),测试用例(第十三组),小结,软件测试的目的是发现程序的错误,但是不能证明程序没有错误。软件中的错误情况非常复杂,主要分为语法错误、结构错误、功能错误和接口错误四种错误类型。测试和调试是软件测试两个关系极为密切的任务,它们通常交替进行。软件测/调试也可利用适当的软件工具辅助测/调试过程,提高效率。测/调试计划、测/调试方案、测/调试结论是软件配置的重要部分,它们对软件的可维护性影响很大,因此,必须正式存档,供以后维护时使用。大型软件的测试应该分级进行,通常分为
33、单元(模块)测试、集成测试、确认测试和系统(验收)测试四个层次的测试。测试发现的软件错误必须正确地加以改正,这就是调试过程。错误定位是一个分析与推理的过程,需要周密、审慎地思考和推理,当然,经验也很重要。,第13章 软件维护,软件维护工作处于软件生命期的最后阶段维护阶段是软件生存期中最长的一个阶段,所花费的人力、物力最多,其花费高达整个软件生命期花费的约60-70,软件维护概述,软件维护主要工作就是在软件运行和维护阶段对软件产品所进行必要的调整和修改维护的原因:在运行中发现在测试阶段未能发现的潜在软件错误和设计缺陷;根据实际情况,需要改进软件设计,以增强软件的功能,提高软件的性能;要求在某环境
34、下已运行的软件能适应特定的硬件、软件、外部设备和通信设备等新的工作环境,或是要求适应已变动的数据或文件;为使投入运行的软件与其它相关的程序有良好的接口,以利于协同工作;为使运行软件的应用范围得到必要的扩充,软件维护概述,特点:软件维护是软件生产性活动中延续时间最长、工作量最大的活动软件维护不仅工作量大、任务重,甚至引入新的错误软件维护活动实际是一个修改和简化了的软件开发过程软件维护和软件开发一样,都需要采用软件工程原理和方法,软件可维护性,软件的可维护性是衡量软件(产品)维护容易程度的一种软件质量属性软件可维护性定义为软件的可理解、可测试、可修改性的难易程度特性:可理解性可测试性可修改性可靠性
35、可移植性可使用性效率,软件维护类型,纠错性维护(Corrective Maintenance):对在测试阶段未能发现的,在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错以及验证、修改的回归测试过程。纠错性维护占整个维护工作的21%。完善性维护(Perfective Maintenance):为了满足这些日益增长的新要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性等。完善性维护所占的比重最大,大约占总维护量的50%以上。适应性维护:为了适应计算机的飞速发展,使软件适应外部新的硬件和软件环境或者数据环境(数据库、数据格式、数据输入/输出方式、数
36、据存储介质)发生的变化,而进行修改软件的过程。适应性维护占整个维护工作的25%。预防性维护(Preventive Maintenance):为了提高软件的可维护性和可靠性等,主动为以后进一步维护软件打下良好基础的维护活动。大约占总维护量的5%。,软件维护的技术,面向维护的技术涉及到软件开发的所有阶段。维护支援技术支持软件维护阶段的技术。维护档案记录做好维护档案记录,才能为维护评价提供有效的数据。维护评价确定维护的质量和成本,软件维护过程,维护申请制定维护计划进行维护活动建立维护文档复审/评价维护,软件维护机构,软件维护申请报告,维护申请单(MRF,Maintenance Request For
37、m),或称为软件问题报告(SPR,Software Problem Report),提交给软件维护机构软件变更报告(SCR,Software Change Report),SCR的内容包括: 所需修改变动的性质; 申请修改的优先级; 为满足该维护申请报告,所需的工作量(人员数、时间数); 预计修改后的结果。,维护工作流程,确认维护类型实施相应维护维护评审,维护流程,实施维护, 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试(回归测试) 确认测试 软件配置评审等,维护评审, 在目前情况下,设计、编码、测试中的哪些方面可以改进? 哪些维护资源应该有而没有? 工作
38、中主要的或次要的障碍是什么? 从维护申请的类型来看,是否应当有预防性维护?,非结构化维护和结构化维护,非结构化维护只有源代码,没有或少量的文档,维护活动只能从阅读、理解、分析程序源代码开始。通过阅读和分析程序源代码来理解系统的功能、结构、数据、接口、设计约束等。这样做势必要花费大量的人力、物力,而且很容易出错,很难保证程序的正确性。结构化维护存在软件开发各阶段的文档,这对于理解和掌握软件的功能、性能、结构、数据、接口和约束有很大帮助。进行维护活动时,从需求文档弄清系统功能、性能的改变。从设计文档检查和修改设计。根据设计改动源代码,并从测试文档的测试用例进行回归测试。这对于减少维护人员的精力和花
39、费,提高软件维护效率有很大作用。,提高可维护性,提高软件可维护性,可以从两方面考虑:在软件开发期的各个阶段、各项开发活动进行的同时,应该时时、处处努力提高软件可维护性,保证软件产品在发布之日有尽可能高水准的可维护性;在软件维护期进行维护活动的同时,也要兼顾提高软件的可维护性,更不能对可维护性产生负面影响技术途径:建立完整的文档明确质量标准采用易于维护的技术和工具加强可维护性复审,面向对象的软件维护,面向对象范型极大地提高了软件可维护性设计良好的对象能体现概念上的封装特性,即独立性对象良好的独立性对象的信息隐蔽技术困难:面向对象的类的继承性对于开发来说是好的特性,但对某一对象的维护会因继承关系涉
40、及到其他部分,并不能做到真正意义上的独立面向对象软件的多态性和动态联编特性,小结,软件维护的基本目标和任务是改正错误、增加功能、提高质量、优化软件、延长软件寿命,以及提高软件产品价值。软件维护活动可分为改正性维护、完善性维护、适应性维护和预防性维护四种类型。软件维护过程主要有提交维护申请报告、确定软件维护工作流程、编制软件维护文档和评价软件维护性能。软件的可理解性、可测试性和可修改性是定义软件可维护性的基本要素。文档是影响软件可维护性的决定因素。提高软件可维护性的技术途径主要有建立完整的软件文档、确立正确的质量指标、采用易维护的开发/维护的方法和工具,以及加强可维护性复审等。,第四部分实验安排
41、,实验8-9WinRunner界面测试工具实验10-11LoadRunner负载测试工具实验12-13PurifyPlus代码测试工具,实验8WinRunner界面测试工具,实验目的掌握WinRunner的基本测试流程了解WinRunner基本测试要点熟练掌握利用WinRunner进行对象识别和脚本录制熟练掌握GUI Map对象的查找及GUI Map文件的保存掌握脚本的执行及查看结果方法实验内容结合一个小应用软件,分别应用Context sensitive模式和Analog模式进行测试,给出测试流程和测试结果。学习WinRunner测试工具的缺省模式。使用已录制的Flight 4A应用来测试发
42、生更改的Flight 4B找出存在的问题。用WinRunner测试一个小软件,描述学习、查找GUI Map对象及加载、保存GUI Map文件的过程。使用GUI Map Editor学习一个窗口上的对象,生成脚本,并解释每条脚本语句的含义。使用Debug和Update分别执行上面的测试,观察它们的不同。,实验9WinRunner工具高级(选做),实验目的进一步了解和学习WinRunner高级测试方法与策略实验内容WinRunner高级测试策略用WinRunner测试一个小软件学习同步点测试使用上面的例子进行多项数据驱动测试学习WinRunner检查点测试学习手工和自动合并脚本文件,实验10Loa
43、dRunner负载测试工具,实验目的了解LoadRunner的工作原理和组织架构,掌握LoadRunner的脚本录制与回放,以及对脚本的修改。实验内容运用VuGen录制、回放脚本(进行必要的录制和回放设置)对录制脚本进行修改(事务、参数化、内容检查、集合点)将上述实验中座位的类型参数化,并将运行时迭代次数设置为4次,回放脚本并进行相关的修改,最后能成功回放,并记录相关信息,实验11LoadRunner工具高级(选做),实验目的了解LoadRunner负载测试的原理和工作方式,掌握简单的场景设计和运行,并在测试时在线监控相关的资源,分析测试结果并生成报告。实验内容掌握利用LoadRunner自带
44、的Basic_Script脚本进行负载设置、以及负载运行及资源的监控,并生成测试报告的步骤和操作;修改Vuser用户数、运行时设置、编辑计划等,再进行比较两次的测试结果;利用实验六中所录制编辑的脚本进行上述的负载测试,并记录相关信息。对测试案例计划进行多次不同负载压力的测试。,实验12PurifyPlus代码测试工具,实验目的了解PurifyPlus的应用场景及各测试组件用途掌握PureCoverage基本测试流程掌握Purify基本测试流程掌握Quantify基本测试流程实验内容结合教学和实验过程,查阅Rational PurifyPlus软件相关测试网站,了解代码覆盖测试,内存测试,性能测
45、试的基本原理、意义、方法。通过网络了解现有各种软件自动化测试工具的功能、用途和基本方法,给出它们之间比较。自编一个应用程序或利用已有的应用程序,分别应用Rational PureCoverage、Rational Purify、Rational Quantify进行测试,给出测试流程和测试结果,并对产生的测试数据做简单的分析。运用分析结果,改进程序或给出改进方案,重新测试,比较测试结果的不同。,实验13PurifyPlus代码测试工具,实验目的了解PurifyPlus的相关高级测试特性和应用场景掌握PureCoverage的精确粒度数据采集、覆盖数据比较掌握Purify的可定制过滤器生成、在线错误修订掌握Quantify的精确粒度数据采集,性能数据比较实验内容本实验主要围绕测试工具中的精确粒度数据采集、可定制过滤器生成、采集数据的合并与比较这三个高级测试特性展开实验操作。结合教学和实验过程,查阅Rational PurifyPlus软件相关测试网站,了解精确粒度数据采集、可定制过滤器生成、采集数据的合并。自编一个应用程序或利用已有的应用程序,在测试过程中使用精确粒度数据采集、可定制过滤器生成、采集数据的合并与比较这三个高级测试特性,给出测试流程和测试结果,并对产生的测试数据做简单的分析。运用分析结果,改进程序或给出改进方案,重新测试,比较测试结果的不同。,第四部分(完),
链接地址:https://www.31ppt.com/p-1356981.html