st-第3章 测试用例设计.ppt

需求评审和测试计划并行进行 更重要是测试计划是建立在需求之上、对需求理解的基础之上 保证软件需求的可测试性 评估测试覆盖率 测试覆盖率是用来衡量测试完成程度、或评估测试活动覆盖产品代码的一种量化的结果 由测试需求覆盖率和代码覆盖率等两部分组成 可对被测试的程序代码语句、代码块、类、函数、路径或条件的覆盖率分析 示例 基于软件缺陷的质量评估 缺陷密度，在软件规模上的缺陷分布，如每千行代码（KLOC）或每个功能点的缺陷数 缺陷清除率 质量 = D2/F； 缺陷注入率 = D/F； 整体缺陷清除率= D1/D； 示例 测试报告的内容 介绍测试项目或测试对象（软件程序、系统、产品等）相关信息，包括名称、版本、依赖关系、进度安排、参与测试的人员和相关文档等。 描述测试需求，包括新功能特性、性能指标要求、测试环境设置要求等。 说明具体完成了哪些测试、以及各项测试执行的结果。 根据测试的结果，对软件产品质量做出准确、全面的评估，列出所有已知的且未解决的问题、测试有待完善的计划和产品质量改进建议等。 基本条目 产品标识； 用于测试的计算机系统； 使用的文档及其标识； 产品描述、用户文档、程序和数据的测试结果； 与要求不符的清单； 针对建议的要求不符的清单，产品未作符合性测试的说明； 测试结束日期。 本章内容 10.1 测试的原则 10.2 测试计划 10.3 测试范围分析和工作量估计 10.4 资源安排和进度管理 10.5 测试风险的控制 10.6 测试报告 10.7 测试管理工具 测试管理系统的构成 能管理整个测试过程，提高管理的效率和准确性，并提供一个协同合作的环境 测试管理系统以测试用例库、缺陷库为核心 测试管理系统的构成 在需求/功能点、测试用例、缺陷等之间建立必要的映射关系 主要工具 商业性工具：HP Mercury TestDirector，IBM Rational Test Manager和Team Test，Compuware QADirector、Borland SilkCentral Test Manager和Microsoft Visual Studio Team System等。 开源工具：TestLink、Bugzilla Test Runner、FitNesse、JtestCas、Eclipse TPTP。其它一些测试管理框架，如TestMaker、SalomeTMF、JTR （Java Test Runner）、Jetif、Marathon、Grinder、TESTARE等。 Q A /Kerryzhu 本章内容 10.1 测试的原则 10.2 测试计划 10.3 测试范围分析和工作量估计 10.4 资源安排和进度管理 10.5 测试风险的控制 10.6 测试报告 10.7 测试管理工具 测试范围分析 总体上可分为功能测试范围和非功能测试范围分析 功能测试范围可以借助流程图和框图按功能层次分解，也可以按功能区域、功能逻辑进行分解 非功能性测试范围可以分别从性能测试、兼容性测试、适用性测试和安全性测试等各个方面进行分析 示例 测试范围的确立 优先级最高的需求功能 新功能和改动较大的旧功能 运用有效的测试技术去提高测试效果 经常容易出现问题部分的功能 一些经常被用户使用的功能和配置 /Kerryzhu 工作量估计 测试任务由质量需求、测试目标决定 测试范围由产品（新）功能特性或测试任务决定。 代码质量越低，测试越要充分，回归测试次数与频率加大。 处在不同的开发阶段测试工作量不同。 自动化程度高，测试工作量就越低。 针对不同的应用领域、技术、编程语言，其估算方法不同。 测试工作量是根据测试范围、策划任务和开发阶段来确定的，测试范围和测试任务是测试工作量估算的主要依据。 /Kerryzhu 工作量估算过程 估算方法 工作分解结构表方法 功能点方法、 对象点方法 代码行预估 历史数据推算（相似规模、同类型） 经验法 （资深人员或专家小组） 综合方法 工作分解结构表方法WBS 列出本项目需要完成的各项任务：测试计划、需求和设计评审、测试设计、脚本开发、测试执行等。 对每个任务进一步细分，可进行多层次的细分，直到不能细分为止。这建立在对于每一阶段工作的细致把握。 列出需要完成的所有任务之后，根据任务的层次给进行编号，就形成了完整的工作分解结构表。 测试工作量的估算依赖于测试任务的细化，对每项测试任务进行分解，然后根据分解的子任务进行估算。通常分解粒度越小，估算精度越高。 /Kerryzhu 工作分解结构表 /Kerryzhu 功能点估算法 功能点是其中一个比较可靠的工作量估算方法，它先估算每个功能点所需要的工作量，然后进行累加获得总的工作量