结构化测试.pptVIP

（SP）Structured Programming 程序设计语言的选择 系统用户要求 软件执行的环境 工程规模 程序员的知识 软件的可移植性 软件的应用领域 工程和科学计算：Fortran 数据处理与数据库应用：SQL 商业领域：Cobol 系统和实时处理：C、Ada 人工智能：Lisp、Prolog 程序设计风格 源程序文档化 标识符按意取名 程序加注释（序言性注释、功能性注释） 数据说明 次序规范化，易找、易测试、易排错、易维护 语句构造 简单直接、易读易懂、层次缩进 清晰第一、效率第二 尽可能使用库函数；尽量只采用三种基本控制结构 输入和输出 程序效率 算法和存储器对效率的影响 测试的重要性 测试目的 G.Myers的观点： 测试是为了发现错误而执行程序的过程 一个好的测试用例能够发现至今尚未发现的错误 一个成功的测试是发现了至今尚未发现的错误的测试 测试人员的任务 站在使用者的角度上，通过不断地使用和攻击刚开发出来的软件产品，尽量多地找出产品中存在的问题，也就是我们所称的Bug 测试指导原则 测试用例应由输入数据和预期的输出数据两部分组成 测试用例不仅选用合理的输入数据，还要选择不合理的输入数据 除了检查程序是否做了它该做的事，还应检查程序是否做了它不该做的事 应制定测试计划并严格执行，排除随意性 对发现错误较多的程序段，应进行更深入的测试 长期保留测试用例，便于进行回归测试 穷举测试是不可能的。一般选用少量“最有效的”测试数据 程序员避免测试自己的程序 测试方法 黑盒测试（Black Box Testing） 完全不考虑程序的内部结构和处理过程，只在程序界面上对产品的功能进行测试，检查程序功能是否满足需求规格说明书的要求，又称功能测试 白盒测试（White Box Testing） 测试人员必须了解程序的结构和处理过程，针对每一条逻辑路径分别设计测试用例，检查分支和循环情况，又称结构测试 以软件开发人员为主，主要在编码阶段进行 设计测试用例的原则 保证模块中每一独立的路径至少执行一次 保证所有判断的每一分支至少执行一次 保证每一循环都在边界条件和一般条件下至少各执行一次 验证所有内部数据结构的有效性 常用的白盒测试方法 逻辑覆盖测试 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 基本路径测试 条件测试 循环测试 （1）程序的控制流图 使用目的：突出表示程序的控制流 仅仅描述程序的控制流程，完全不表现对数据的具体操作和分支或循环的具体条件 程序流程图?程序控制流图 注意 流图中 一个结点对应一条或多条语句 流程图中，一个顺序执行的处理框序列和一个菱形判断框，可以映射成控制流图中的一个结点。 一条边必须终止于一个结点，哪怕是空语句的结点 在计算流图中的区域数时，应包括图外部未被围起来的敞开区域 若判断框中的条件是复合条件时，则需要将复合条件的判断分解为一系列只有单个条件的嵌套判断 复合条件（and）下的流图 复合条件（or）下的流图 （2）程序环路复杂性V（G） 度量程序的逻辑复杂性，通过流图导出 计算方法 V（G）＝ 流图中的区域数 V（G）＝ P＋1，其中P判断结点数 V（G）＝ E－N＋2，其中E边数，N结点数 （3）独立路径 指包括一组以前没有处理的语句或条件的一条路径。从流图来看，一条独立路径至少包含有一条在其他独立路径中从未有过的边的路径 独立路径条数＝V（G） 是确保程序中每个可执行语句至少执行一次所需的测试用例数目的上界 基本路径集不唯一，但条数是唯一的 上图中的一组独立路径 共4条独立路径 path1: 1-11 path2: 1-2-3-4-5-10-1-11 path3: 1-2-3-6-8-9-10-1-11 path4: 1-2-3-6-7-9-10-1-11 这4条独立路径组成了流图中的一个基本路径集 （4）导出测试用例 主要步骤： 以详细设计或源代码为基础，导出程序的流图 计算得到的流图G的环路复杂性V（G） 确定线性无关的路径的基本集合 生成测试用例，确保基本路径集中每条路径的执行 实例：求=100个在规定值域内的有效数字的平均值 procedure average;i=1;input=valid=0;sum=0;do while value[i]-999 and input100 increment input by 1; if value[i]=min and value[i]=max then increment valid by 1;  sum=sum+value[i]; endif increment i by 1;enddoif valid0 then ave=sum/valid; else ave=-999;endif