软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验

上传人:E**** 文档编号:89320630 上传时间:2019-05-23 格式:PPT 页数:40 大小:186KB
返回 下载 相关 举报
软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验_第1页
第1页 / 共40页
软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验_第2页
第2页 / 共40页
软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验_第3页
第3页 / 共40页
软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验_第4页
第4页 / 共40页
软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验_第5页
第5页 / 共40页
点击查看更多>>
资源描述

《软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验》由会员分享,可在线阅读,更多相关《软件工程 第2版 教学课件 ppt 作者 王宜贵 第6章 软件检验(40页珍藏版)》请在金锄头文库上搜索。

1、6.1 软件检验概述 6.1.1 检验的手段,软件检验的目的在于发现其中的错误并及时纠正。发现的错误越多就说明检验的收获越大。目前检验的手段有三种。 动态检验: 指软件测试,是使程序有控制地运行,并从多种角度观察程序运行时的行为,以发现其中的错误。测试的关键是设计测试用例,设计测试用例有黑盒法和白盒法两类方法。测试的目的是发现程序中的错误,但测试只能证明错误的存在,而不能证明错误不存在,也就是说测试不能保证发现程序中的所有错误。,6.1 软件检验概述 6.1.1 检验的手段,静态检验:指人工评审软件文档或程序,以发现其中的错误。比较简单,但效率相当高,80%。评审是软件开发过程中一项必不可少的

2、质量保证措施。由于人工评审的能力有限,因此这种静态检验不可能发现所有错误。 程序正确性证明:正确性证明是从理论上对程序的正确性进行论证,通过证明可以得出程序逻辑上是正确的。程序正确性证明从理论上说是可能实现的,但在实际证明过程中,要花费大量的人力,在一般情况下完全的形式证明是不必要的。,6.1 软件检验概述 6.1.2 软件测试的目标和原则,测试的目标:以尽量少的时间和人力尽可能多地发现软件中潜在的各种错误和缺陷,而不是为了说明程序没有错误。 软件测试的原则: 成立专门的测试小组 测试用例应包括测试输入数据和与之对应的输出结果两部分 设计测试用例时应包括合理的输入和不合理的输入 全面检查每一个

3、测试结果 集中测试容易出错的程序段 严格执行测试计划 保留软件测试文档,6.1 软件检验概述 6.1.3 软件测试常用方法,黑盒法:如果已知该程序应具备的功能,则通过测试来检验它的每一项功能是否都能正常使用。如果想用黑盒法发现程序中的所有错误,则必须用输入数据的所有可能值来检查程序是否都能产生正确的结果,而一个程序的输入域一般是无穷。 白盒法:如果已知程序的内部结构和工作过程,通过测试可来检验产品内部动作是否符合规格说明书的规定。如果想用白盒法发现程序中所有的错误,则必须使程序中每种可能的路径都至少执行一次,而一个程序往往具有数量众多的路径 。,6.1 软件检验概述 6.1.3 软件测试常用方

4、法,无论用黑合法还是白盒法进行测试,都不能证明程序是正确的。在实际应用中,往往将黑盒测试与白盒测试两者结合起来使用,对软件进行有限的测试。设计测试用例是测试工作的关键,必须精心设计测试用例,要从数量极大的可用测试用例中精心挑选出少量的测试数据,使得这些测试数据能够高效率地把程序中的错误检查出来。,6.1 软件检验概述 6.1.4 测试信息流,6.2 软件评审,正规的评审制度对软件的成功是绝对必要的。软件评审应由没有参加本系统开发工作的、但有丰富开发经验、受过软件评审、软件检验等良好训练的人员参加。评审小组一般由30人组成,由开发部门负责人任组长。,6.2 软件评审 6.2.1 软件评审条款,需

5、求分析评审 系统定义的目标是否与用户的要求一致。 系统需求分析阶段提供的文档资料是否齐全。 文档中的所有描述是否完整、清晰、准确地反映了用户的要求。 与所有的其它系统成分的重要接口是否都已描述。 所开发项目的数据流与数据结构是否足够,是否确定。 所有图表是否清楚,在没有补充说明时是否易于理解。 主要功能是否已包含在规定的软件范围之内,是否都已充分说明。 软件的行为和它必须处理的信息、必须完成的功能是否一致。 设计的约束条件或限制条件是否符合实际。 开发的技术风险是什么。 是否考虑过软件需求的其它方案。 是否考虑过将来可能会提出的软件需求。 是否详细制定了检验标准,它们能否对系统定义的成败进行确

6、认。 有无遗漏、重复或不一致的地方。 用户是否审查了初步的用户手册。 项目开发计划中的估算是否受到了影响。,6.2 软件评审 6.2.1 软件评审条款,软件设计评审 可追溯性 接口 风险 实用性 技术清晰性 可维护性 质量 各种选择方案 限制 其他具体问题,6.2 软件评审 6.2.2 软件评审特点,与测试技术相比较,软件评审有其自身的特点: 可以早发现错误早纠正错误,从而降低软件开发成本。 可以吸收各家所长,取得良好的效果。 在发现错误的同时可找到错误的原因,排错比较容易。 可以发现成批的错误,并且可成批地纠正。 在开发早期就可发现错误。,6.3 测试用例设计,设计测试用例是测试阶段的关键技

7、术。设计测试用例就是要设计一组最有可能发现某个错误或某类错误的测试数据,以检验系统某个功能是否达到预期要求。测试时应选用尽量少的测试用例来发现软件中尽可能多的错误。,6.3 测试用例设计 6.3.1 白盒法,用白盒法设计测 试用例最常用的 是逻辑覆盖法, 根据对程序逻辑 结构的覆盖程度 不同,可分为如 下不同类型的覆 盖标准。,语句覆盖 选择足够的测试用例,使得被测试程序中的每条语句至少执行一次。 测试用例:A2,B0,X8 预期结果 X=5(执行路径sbcef ),6.3 测试用例设计 6.3.1 白盒法,判定覆盖 选择足够的测试用例,使得被测试程序中的每个判定都至少获得一次“真”值和“假”

8、值,或者说使得程序中的每个分支都至少执行一次。判定覆盖又称分支覆盖。 测试用例: A=2,B=0,X=4 预期结果 X3 (满足(A1)&(B0)和(A2)|(X1)为真的条件,可执行路径sbcef) A=1,B=1,X=1 预期结果 X1 (满足(A1)&(B0)和(A2)|(X1)为假的条件,可执行路径scadf),6.3 测试用例设计 6.3.1 白盒法,条件覆盖:选择足够的测试用例,使得被测试程序中的每个判定的每个条件获得各种可能的值(“真”和“假”)。 测试用例: A2,B0,X=8 预期结果 X5 (满足T1,T2,T3,T4,执行路径sbcef) A=1, B=1, X=1 预期

9、结果 X1 (满足F1,F2,F3,F4, 执行路径sacdf),6.3 测试用例设计 6.3.1 白盒法,判定/条件覆盖:选择足够的测试用例,使得被测试程序中的每个判定中的每个条件都取到各种可能的值,并使每个判定也都取到各种可能的值。它是可同时满足判定覆盖和条件覆盖这两种逻辑覆盖标准。 测试用例: A2,B0,X8 预期结果 X5 A1,B1,X1 预期结果 X1,6.3 测试用例设计 6.3.1 白盒法,条件组合覆盖:指选择足够的测试用例,使得被测试程序中的每个判定中所有可能的条件取值组合至少出现一次。 测试用例: A2,B0,X8 预期结果 X5 (满足(1)、(5)两种组合,执行路径s

10、bcef) A2,B1,X1 预期结果 X=2 (满足(2)、(6)两种组合,执行路径 sacef) A=1,B=0,X=2 预期结果 X3 (满足(3)、(7)两种组合,执行路径 sacef) A=1,B=1,X=1 预期结果 X1 (满足(4)、(8)两种组合,执行路径 sacdf),6.3 测试用例设计 6.3.1 白盒法,路径覆盖:选择足够的测试用例,使得被测试程序中的每条可能的路径都至少执行一次。 测试用例: A1,B1,X1 预期结果 X1 (执行路径为sacdf) A=1,B=0,X=2 预期结果 X3 (执行路径为sacef) A=4,B=0,X=1 预期结果 X=0.25 (

11、执行路径为sbcdf) A=2,B=0,X=8 预期结果 X5 (执行路径为sbcef),6.3 测试用例设计 6.3.1 白盒法,用黑盒法设计测试用例的方法: 等价类划分法 边界值分析法 错误推测法,6.3 测试用例设计 6.3.2 黑盒法,6.3 测试用例设计 6.3.2 黑盒法,1.等价类划分法 把所有可能的输入数据划分成若干个等价类,然后从每个类中挑选出有代表性的数据作为测试数据。 (1)划分等价类 有效等价类 无效等价类,1.等价类划分法 等价类划分的启发性规则 : 如果规定了输入值的取值范围或数据的个数,则可划分出一个有效等价类和两个无效等价类。 如果规定了输入数据的一组值,而程序

12、对每个输入值分别进行处理,则每个合法的输入值为一个有效等价类,所有非法输入值作为一个无效的等价类。 如果规定了输入数据必须遵循的规则,则可划分出一个符合规则的有效等价类和若干个从各种角度违反规则的无效等价类。 如果确知已划分的等价类中各元素在程序中的处理方式不同,则就将此等价类进一步划分为更小的等价类。,6.3 测试用例设计 6.3.2 黑盒法,6.3 测试用例设计 6.3.2 黑盒法,1.等价类划分法 (2)测试用例设计步骤 划分出等价类以后,再通过以下两个步骤来设计测试用例: 设计一个新的测试用例以尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步骤直到所有有效等价类都被覆盖为止。 设计一个

13、新的测试方案,使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类,重复这一步骤直到所有无效等价类都被覆盖为止。,6.3 测试用例设计 6.3.2 黑盒法,2.边界值分析法 根据被测程序的功能,选择一些边界值做测试数据。 用边界值分析法设计应遵循以下原则 如果输入条件规定了值的范围,则应取刚好在边界上,稍大于这个边界和稍小于这个边界的数据作测试用例。 如果输入条件规定了数据的个数,则应用最大个数、最小个数,比最大个数大1的数,比最小个数少1的数设计测试用例。 针对规格说明中的每个输出条件使用上述第1条原则。,2.边界值分析法 针对规格说明中的每个输出条件使用上述第2条原则。 如果程序规格说明给出的

14、输入域或输出域是有序集合(如有序表,顺序文件等),则应选取有序集合的第一个元素和最后一个元素作测试用例。 如果程序规格说明中规定使用一个内部数据结构,则当选择这个内部数据结构的边界上的值作为测试用例。 分析规格说明,找出其他可能的边界条件。,6.3 测试用例设计 6.3.2 黑盒法,3.错误推测法 不同类型不同特点的程序通常又有一些特殊的容易出错的情况,测试人员可以依靠经验和直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误的测试用例。这就是错误推测法。 错误推测法列举出程序中可能有的错误和容易发生错误的特殊情况,并且根据它们选择测试用例。它没有固定步骤,要靠测试经验的不断积累。

15、,6.3 测试用例设计 6.3.2 黑盒法,6.4 测试的过程与策略,软件测试的4个步骤: 单元测试 集成测试 确认测试 系统测试 由测试的过程可以看出,最早犯下的错误最晚才能发现。,对程序的最小单位模块进行的测试,又称为模块测试。 1.单元测试内容 模块接口 局部数据结构 重要路径测试 错误处理 边界条件 2.单元测试的步骤 两类辅助测试模块: 驱动模块 桩模块,6.4 测试的过程与策略 6.4.1 单元测试,在单元测试的基础上,将模块按照总体设计时的要求组装成子系统或整个系统进行测试,也称为组装测试。 1.非渐增式集成测试 在分别对每个模块进行单元测试后,再把所有模块按总体设计要求放在一起

16、进行集成测试。,6.4 测试的过程与策略 6.4.2 集成测试,2.自顶向下集成测试 自顶向下集成测试 自底向上集成 混合的集成测试 在进行集成测试时,应该识别出关键模块,使其尽早地得到测试。,6.4 测试的过程与策略 6.4.2 集成测试,在集成测试后对检验软件的功能和性能及其他特性是否与用户所合理期待的要求一致,也称为验收测试,又可称为有效性测试 。 1.测试准则:确认测试要以用户为主进行,用户应参加设计测试用例,并同用户一起对测试结果进行评价。 2.测试的可能结果 :一是软件的功能和性能与用户要求一致;另一种结果是系统的功能和性能与用户需求有差距,解决起来比较困难,必须与用户充分协商。 测试和测试是产品发布之前经常需要进行的两种不同类型的测试。 3.软件配置复查 :目的是为保证软件配置的所有

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 高等教育 > 大学课件

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号