软件工程 第2版 作者 王宜贵 第6章 软件检验.pptVIP

6.1 软件检验概述6.1.2 软件测试的目标和原则 测试的目标：以尽量少的时间和人力尽可能多地发现软件中潜在的各种错误和缺陷，而不是为了说明程序没有错误。 软件测试的原则： 成立专门的测试小组 测试用例应包括测试输入数据和与之对应的输出结果两部分 设计测试用例时应包括合理的输入和不合理的输入 全面检查每一个测试结果 集中测试容易出错的程序段 严格执行测试计划 保留软件测试文档 6.1 软件检验概述6.1.3 软件测试常用方法 黑盒法：如果已知该程序应具备的功能，则通过测试来检验它的每一项功能是否都能正常使用。如果想用黑盒法发现程序中的所有错误，则必须用输入数据的所有可能值来检查程序是否都能产生正确的结果，而一个程序的输入域一般是无穷。 白盒法：如果已知程序的内部结构和工作过程，通过测试可来检验产品内部动作是否符合规格说明书的规定。如果想用白盒法发现程序中所有的错误，则必须使程序中每种可能的路径都至少执行一次，而一个程序往往具有数量众多的路径 。 6.1 软件检验概述6.1.3 软件测试常用方法 无论用黑合法还是白盒法进行测试，都不能证明程序是正确的。在实际应用中，往往将黑盒测试与白盒测试两者结合起来使用，对软件进行有限的测试。设计测试用例是测试工作的关键，必须精心设计测试用例，要从数量极大的可用测试用例中精心挑选出少量的测试数据，使得这些测试数据能够高效率地把程序中的错误检查出来。 6.1 软件检验概述6.1.4 测试信息流 6.2 软件评审 正规的评审制度对软件的成功是绝对必要的。软件评审应由没有参加本系统开发工作的、但有丰富开发经验、受过软件评审、软件检验等良好训练的人员参加。评审小组一般由3~１0人组成，由开发部门负责人任组长。 6.2 软件评审6.2.1 软件评审条款 需求分析评审 系统定义的目标是否与用户的要求一致。 系统需求分析阶段提供的文档资料是否齐全。 文档中的所有描述是否完整、清晰、准确地反映了用户的要求。 与所有的其它系统成分的重要接口是否都已描述。 所开发项目的数据流与数据结构是否足够，是否确定。 所有图表是否清楚，在没有补充说明时是否易于理解。 主要功能是否已包含在规定的软件范围之内，是否都已充分说明。 软件的行为和它必须处理的信息、必须完成的功能是否一致。 设计的约束条件或限制条件是否符合实际。 开发的技术风险是什么。 是否考虑过软件需求的其它方案。 是否考虑过将来可能会提出的软件需求。 是否详细制定了检验标准，它们能否对系统定义的成败进行确认。 有无遗漏、重复或不一致的地方。 用户是否审查了初步的用户手册。 项目开发计划中的估算是否受到了影响。 6.2 软件评审6.2.1 软件评审条款 软件设计评审 可追溯性 接口 风险 实用性 技术清晰性 可维护性 质量 各种选择方案 限制 其他具体问题 6.2 软件评审6.2.2 软件评审特点 与测试技术相比较，软件评审有其自身的特点： 可以早发现错误早纠正错误，从而降低软件开发成本。 可以吸收各家所长，取得良好的效果。 在发现错误的同时可找到错误的原因，排错比较容易。 可以发现成批的错误，并且可成批地纠正。 在开发早期就可发现错误。 6.3 测试用例设计 设计测试用例是测试阶段的关键技术。设计测试用例就是要设计一组最有可能发现某个错误或某类错误的测试数据，以检验系统某个功能是否达到预期要求。测试时应选用尽量少的测试用例来发现软件中尽可能多的错误。 6.3 测试用例设计6.3.1 白盒法 用白盒法设计测 试用例最常用的 是逻辑覆盖法， 根据对程序逻辑 结构的覆盖程度 不同，可分为如 下不同类型的覆 盖标准。 6.3 测试用例设计6.3.1 白盒法 语句覆盖 选择足够的测试用例，使得被测试程序中的每条语句至少执行一次。 测试用例：A＝2，B＝0，X＝8 预期结果 X=5（执行路径sbcef ） 6.3 测试用例设计6.3.1 白盒法 判定覆盖 选择足够的测试用例，使得被测试程序中的每个判定都至少获得一次“真”值和“假”值，或者说使得程序中的每个分支都至少执行一次。判定覆盖又称分支覆盖。 测试用例： A=2,B=0,X=4 预期结果 X＝3 (满足(A＞1)(B＝0)和（A＝2）||(X＞1)为真的条件，可执行路径sbcef) A=1,B=1,X=1 预期结果 X＝1 (满足(A＞1)(B＝0)和（A＝2）||(X＞1)为假的条件，可执行路径scadf) 6.3 测试用例设计6.3.1 白盒法 条件覆盖：选择足够的测试用例，使得被测试程序中的每个判定的每个条件获得各种可能的值（“真”和“假”）。 测试用例： A＝2，B＝0，X=8 预期结果 X＝