软件质量保证和测试技术

1、第一章,软件质量保证,本章目标,定义软件质量和软件质量保证 解释软件开发各个阶段 SQA 的目标 实现软件质量保证 建立质量管理体系 建立质量计划 质量保证 质量控制的输入 质量控制的手段和技巧,开场白,世界上不存在没有缺陷的软件。 可以通过两种途径开发出没有错误的软件： 在一开始就防止引入错误。 识别潜藏在代码中的错误，找到并消灭它们。,什么是软件质量,软件质量是软件产品满足使用要求的程度。对于软件质量的衡量，就是高质量的软件系统能够准时地交付给用户，所耗费的成本不超出预算，并且最重要的是，能够正常地运行。“正常地运行”意味着该软件必须尽可能没有缺陷(bug)。 理解： 软件需求是质量度量的

2、基础，与需求不符就是质量不高 完成的成本和完成的时间都应该在计划范围内 开发出的软件产品应该是可靠的和可维护的,软件质量保证 (SQA),质量保证是一个活动，它向所有有关的人提供证据以确立质量功能正在按需求运行的信心。 软件质量保证是一系列系统性的活动，它提供开发出满足使用要求产品的软件过程的能力证据。,软件开发各个阶段 SQA 的目标 6-1,需求分析： 确保客户所要求的系统是可行的。 确保客户指定的需求确实能够满足他的真正要求。 避免开发者和客户之间的误解。 向用户提供为满足他所提出的需求而实际构建的适当软件系统。,软件规格说明： 通过建立需求跟踪文档，确保规格说明书与系统需求保持一致。

3、确保规格说明书能适当地改进系统的灵活性、可维护性以及性能。 确保已建立了测试策略。 确保已建立了现实的开发进度表，包括预定的评审。 确保已为系统设计了正式的变更规程。,软件开发各个阶段 SQA 的目标 6-2,软件开发各个阶段的 SQA 目标 6-3,设计： 确保已建立用于描述设计的标准，并且确保遵循这些标准。 确保适当地控制并用文档记录对设计进行的变更。 确保在系统设计组件已按照商定的准则得到批准之后才开始编码。 确保对设计的评审按照进度进行。,软件开发各个阶段的 SQA 目标 6-4,编码： 确保代码遵循已建立的风格、结构和文档标准。 确保代码经过适当测试和集成，同时对编码模块的修改得到适

4、当的标识。 查看代码编写是否遵循既定的进度。 确保代码评审按照进度进行。,软件开发各个阶段的 SQA 目标 6-5,测试： 确保测试计划的建立和遵循。 确保创建的测试计划能够满足所有系统规格说明书的要求。 确保经过测试和返工后软件与规格说明书保持一致。,软件开发各个阶段的 SQA 目标 6-6,维护： 确保代码和文档的一致性。 确保对已建立的变更控制过程进行监测，包括将变更集成到软件的产品版本中的过程。 确保对代码的修改遵循编码标准，并且要对其进行评审，不要破坏整个代码结构。,实施质量管理,质量管理的发展和趋势 质量管理体系 建立质量计划 质量保证 质量控制的输入 质量控制的手段和技巧质量控制

5、的输出,质量管理发展五个阶段,1900,手工操作者,专职检验员,1920,过程统计技术,1931,全面质量管理,1960,2000,以顾客为中心,阶 段,时间,质量管理发展趋势,核心：由对结果的检验转向对过程精细的控制 改变： 管理范围的改变：由针对以产品生产制造服务质量管理扩大到行政部门工作质量。 关注焦点的转移： 由面向以产品生存周期的 服务质量管理转向顾客 满意为中心质量管理。,软件产业要经历三个不同时代,结构化生产时代(70年代中期至90年代中期)：结构化分析；结构化设计；结构化程序设计；结构化测试；结构化审查与走查。 以过程为中心的时代(从80年代中期至2010年前后)：寓质量和效率

6、于生产过程之中；关于软件过程的主要流派(ISO 9000，CMM)。 软件工业化生产时代(1995年开始)：基础技术(软件过程技术，面向对象技术，基于构件的开发技术)；主要问题(标准化，产业文化，政策法规)；对前途的估计(我国2005年可以进入软件工业化生产时代)。,项目质量管理总览图,项目质量管理定义,项目质量管理 质量管理需要保证整个项目都要满足设计时的需要 项目质量管理包括了所有的活动，这些活动决定了质量策略、质量目标和责任。而这些都需要被质量计划、质量控制、质量保证和质量改进等活动完成。,项目质量管理的核心过程,三个核心过程: 质量管理确认质量标准是关于项目目的、项目管理者、项目使用者

7、这方面决定的 质量保证评估整个项目满足相关的质量要求 质量控制 监控记过符合相应质量标准，可以进行检查，满足项目管理者以及整个项目组的要求,制定质量计划,质量计划 描述相关质量标准并且说明如何满足相应标准 输入质量计划 质量策略 一个组织中有关管理层对于质量的定义和方向 范围描述 产品说明 标准和规则 其他过程输出 其他领域的相关知识,质量计划的手段和技巧 2-1,质量计划的工具和技巧 效益成本分析 考虑市场，就意味着减少返工;成本是与质量管理活动有关的费用 基本水平标准 比较实际或者计划中其他项目实施中的情况 流程图 因果图,质量计划的手段和技巧 2-2,系统或程序流程图 试验设计 一种分析

8、技巧，有助于鉴定哪些变量对整个项目的成果产生最大的影响,质量计划的输出,质量计划的输出 质量管理计划 说明项目管理小组如何具体执行它的质量策略; 操作性定义 用非常专业化的术语描述各项操作规程的含义，以及如何通过质量控制程序对它们进行检测。 审验单 用以证明一系列步骤是否已经得到贯彻实施 对其他程序的输入 可以在其他领域提出更长远的要求,质量计划中的输出总览图,质量保证,质量保证 为了提供信用，证明项目将会达到有关质量标准，而在质量体系中开展的有计划、有组织的工作活动 质量保证的输入 质量管理计划 质量控制结果 操作性定义,质量保证的手段和技巧,质量保证的手段和技巧 质量计划的手段和技巧 质量

9、审查 质量审查是对其他质量管理活动的结构性复查 质量保证的输出 质量改进 质量提高包括采取措施提高项目的效益和效率，为项目相关人员提供更多的利益,质量控制,质量控制 包括监控特定的项目成果，以判定它们是否符合有关的质量标准，并找出方法消除造成项目成果不令人满意的原因。 预防（不让错误进入项目程序）和检验（不让错误进入客户手中） 静态调查（其结果要么一致，要么不一致）和动态调查（其结果依据衡量一致性程度的一种持续性标准而评估） 确定因素（非常事件）和随机因素（正态过程分布） 误差范围（如果其结果落入误差范围所界定的范围内，那么这个结果就是可接受的）和控制界限（如果其成果落入控制界限内。那么该项目

10、也在控制之中。）,质量控制总览图,质量控制的输入,质量控制的输入 项目成果 包括程序运行结果和生产结果 质量管理计划 操作性定义 审查单,质量控制输入图,质量控制的手段和技巧 2-1,检验包括测量、检查和测试等活动，目的是确定项目成果是否与要求相一致 控制表控制表是根据时间推移对程序运行结果的一种图表展示。 排列图是一种直方图，由事件发生的频率组织而成，用以显示多少成果是产生于已确定的各种类型的原因的。如下图。,质量控制的手段和技巧 2-2,抽样调查统计 流程图 趋势分析,质量控制的输出,质量控制输出 质量提高 可接受的决定（接受/拒绝） 返工 返工是有缺陷的、不符合要求的产品变为符合要求和设

11、计规格的产品的行为。 完成后的审验单 程序的调整程序的调整指作为质量检测结果而随时进行的纠错和预防行为。,总结,软件质量的衡量标准是可以准时地交付给用户，所耗费的成本不超出预算，并且最重要的是，能够正常地运行。 SQA 的目标是通过在开发周期的早期阶段发现错误来降低解决问题的成本。 SQA 应用于软件开发的每个阶段，每个阶段都有其自己的质量标准。 实施质量管理中，要注意构建自己的管理体系，包括：构建质量计划、建立质量保证、建立质量控制等,第二章,测试技术,回顾,软件质量的衡量标准是可以准时地交付给用户，所耗费的成本不超出预算，并且最重要的是，能够正常地运行。 SQA 的目标是通过在开发周期的早

12、期阶段发现错误来降低解决问题的成本。 SQA 应用于软件开发的每个阶段，每个阶段都有其自己的质量标准。 实施质量管理中，要注意构建自己的管理体系，包括：构建质量计划、建立质量保证、建立质量控制等,本章目标,定义软件测试 明确软件测试的准则 明确测试的方法 描述软件测试的各个阶段 描述各种测试阶段的测试内容,简介,软件测试是软件工程过程中的关键组件。 软件测试是软件质量保证的要素，可以将其描述为一个运行程序以检测错误（如果有）的过程。,测试的常识与道理 2-1,编程大师说：没有错误的程序世间难求。 （编程之道） 你在学校里学过测试吗？（读到博士可能也不懂测试） 你所在的企业重视测试吗？ （小公司

13、程序员的技能更加全面） 临时抱佛脚行吗？你以为有文档模板就会测试了吗？,测试的常识与道理 2-2,如果不懂得有效地进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。 职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护 所有技能。,测试的目的是什么,测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。 推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。 千万不要将“测试”与“演示”混为一谈。例如科研鉴定会。 如果产品通过了严格的测试，大家不要不吭气，应当好好地宣传一把 。,软件测试原则

14、 2-1,完全测试程序是不可能的 输入量太大 输出结果太多 软件实现途径太多 软件说明书没有客观标准。从不同角度看，软件缺陷的标准不同。,软件测试原则 2-2,软件测试是有风险的行为 测试无法显示潜伏的软件缺陷 找到的软件缺陷越多，就说明软件缺陷越多 并非所有软件缺陷都能修复 软件测试一项讲究条理的技术专业,软件测试方法黑盒和白盒,白盒测试中（有时候称为开盒测试），软件测试员可以访问程序员的代码，并通过检查代码来协助测试可以看到盒子里面。一般在单元测试中采用白盒测试，用于测试模块中所有可能的路径、执行所有循环并测试所有逻辑表达式。 黑盒测试则侧重于软件的整体功能。 它不基于程序的内部结构而基于

15、系统功能。犹如一个人站在黑盒子外面，只知道系统输入一定数据，得到一定的输出，而不必清楚这个黑盒子中进行了哪些操作和运算。,软件测试方法静态和动态,静态检查 确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查。通常包括需求评审、设计评审、代码走查和代码检查。 动态检查 在生命周期中进行测试（运行）。通常包括单元测试、集成测试、系统测试、用户的验收测试。,静态测试,审查 (Inspection) 软件的一种基本测试方法，它以一系列典型问题为依据进行检测。 走查 (Walkthrough) 一对一的审查，比审查更加仔细。 回顾(Review) 以发现软件中存在的错误和缺陷为目的的一

16、种软件测试方法，它是在软件证实执行之前完成。,静态和动态测试进行结构和功能测试,测试技术,测试产品说明书,对于产品说明书的制定是个很重要的设计阶段，产品说明书的质量会直接影响到整个产品开发。 测试产品说明书属于静态黑盒子测试。,常用测试用语测试用例,测试用例：编写用于输入输入的实际数制和预期结果。测试用例还明确指出使用具体测试用例产生的测试程序的任何限制 。 使用目的： 测试用例应该设计为能够快速容易地发现尽可能多的错误。 应该通过使用和产生正确和错误的输入和输出来“检验”程序。 其目标是要使用合理范围内的条件，尽可能全面地测试所有模块乃至整个系统。,测试与调试什么是缺陷,缺陷：最终产品同用户

17、的期望不一致 缺陷的分类 错误 遗漏 超出需求的部分 缺陷（未触发）VS.错误（应首先解决）,测试与调试调试的准则,调试的方法：归纳法、演绎法和回溯法。 常用调试技术使用诊断输出语句 (diagnostic output statement)、快照转储 (snapshot dump) 以及跟踪指令的断点 (instruction-dependent breakpoint)。,测试的分类与比较,开发与测试的 V 型关系 如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系 。,需求开发,高层设计,详细设计,编程,单元测试,集成测试,系统测试,验收测试,测试阶段 2-1,单元测试

18、、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。 单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。,测试阶段 2-2,系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。 验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。,测试内容,测试内容一般包含 接口与路径测试。 功能测试、健壮性测试、性能测试

19、、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试,测试阶段对应表,接口与路径测试 3-1,接口测试：数据一般通过接口输入和输出，接口测试一般是白盒测试的第一步。 输入参数有“典型值”、“边界值”、“异常值” 输出包括函数的返回值和输出参数。 实际输出与期望的输出不一致，那么说明程序有错误。 一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。所以应该根据经验选择关键的路径测试。,接口与路径测试 3-2,路径测试的检查表 数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理 预防一些重要的路径没有被测试的措施有： 观察是否有程序语句从来没有被执行过。 要特

20、别留意函数体内的错误处理程序块。,接口与路径测试 3-3,接口与路径测试用例的参考模板,功能测试 3-1,功能测试的基本方法是构造一些合理输入（在需求范围之内），检查输出是否与期望的相同。如果两者不一致，即表明功能有误。 难点在于如何构造有效的输入。,功能测试 3-2,功能测试的测试方法：等价划分法和边界值分析法。 等价划分是指把输入空间划分为几个“等价区间”，在每个“等价区间”中只需要测试一个典型值就可以了。等价划分法来源于人们的直觉与经验，可令测试事半功倍。 “缺陷遗漏在角落里，聚集在边界上”。边界值测试法是对等价划分法的补充。如果A和B是输入空间的边界值，那么除了典型值外还要用A和B作为

21、测试用例。,功能测试 3-3,功能测试用例的参考模板,性能测试 3-1,性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考。 绝对值考虑：如数据送输速率是每秒多少比特。 “相对值”考虑：如某个软件比另一个软件快多少倍。 性能测试中考虑运行环境的影响：例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。,性能测试 3-2,性能测试的一些注意事项： 应当编写一段程序用于计算时间以及相关数据。 应当测试软件在标准配置和最低配置下的性能。 应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。 应当分档记录。例如传输文件的容量从

22、100K到1M可以分成若干等级。 同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。,性能测试 3-3,性能测试用例的参考模板,压力测试 2-1,压力测试也叫负荷测试，即获取系统能正常运行的极限状态。 压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。 压力测试的一个变种是敏感测试。在某种情况下，微小的输入变动会导致系统的表现（如性能）发生急剧的变化。,压力测试 2-2,压力测试用例的参考模板,其他测试内容,健壮性测试 用户界面测试 信息安全测试 可靠性测试 安装和反安装测试,问题1：有了“黑盒”测试为什么还要“白盒”测试？ 问题2：由于单元测试要写测试驱动程

23、序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？ 问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？,测试常见问题 2-1,测试常见问题 2-2,问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试? 问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？ 问题6：能否将系统测试和验收测试“合二为一”？,总结 2-1,测试可以将测试描述为一个运行程序以发现错误的过程。 软件测试的准则:不完全测试、风险测试、无法显示潜伏错误、发现错误成线性增长、缺陷不能

24、完全修复、测试有条理规程 测试的方法:黑盒/白盒、静态/动态 软件测试的各个阶段：单元测试、集成测试、系统测试、验收测试,总结 2-2,测试的内容包括：接口/路径测试、功能测试、性能测试、压力测试、可靠性测试、安全性测试、用户界面测试、安装/反安装测试,第三章,测试工具,回顾 2-1,测试可以将测试描述为一个运行程序以发现错误的过程。 软件测试的准则:不完全测试、风险测试、无法显示潜伏错误、发现错误成线性增长、缺陷不能完全修复、测试有条理规程 测试的方法:黑盒/白盒、静态/动态 软件测试的各个阶段：单元测试、集成测试、系统测试、验收测试,回顾 2-2,测试的内容包括：接口/路径测试、功能测试、

25、性能测试、压力测试、可靠性测试、安全性测试、用户界面测试、安装/反安装测试,本章目标,讨论测试工具的好处 介绍测试工具的种类及实质 讨论测试工具的局限 介绍市场上比较流行的测试工具: Rational系列和 Panorama工具,什么是测试工具,定义：辅助测试整个过程的工具软件 单元测试可以有两种方式 自己编写代码 使用单元测试工具 整个过程包括： 静态分析，测试计划，测试设计，测试执行，测试缺陷跟踪，测试报告和质量度量等,单元测试工具的种类,单元测试工具的种类 静态分析工具 代码规范审核工具 内存和资源检查工具 测试数据生成工具 测试框架工具 测试结果比较工具 测试度量工具 测试文档生成和管

26、理工具,自动测试工具,自动测试工具 好处 速度和效率 准确度和精确度 耐性、不休息、可重复 局限 对软件变更，尤其是代码变更比较敏感 先期的测试开发比较费时 有些测试结果无法用工具比较和分析 有些工具的脚本/代码会使程序运行环境不纯净,使用自动测试工具的目的,测试工具提高测试效率，节省测试成本 测试设计提高测试效果，同时也可以提高测试效率，节省测试成本 有些测试单靠手工很难完成 压力测试，模拟并发测试等 多数的单元测试 有些测试使用测试工具更合适 回归测试 大量测试数据的生成、部分测试结果的比较 缺陷管理和测试用例管理 质量度量,如何引入自动测试工具 3-1,选择自动测试工具是一个重要的步骤，

27、所以一定要谨慎 因为测试工作经常会涉及到管理流程和开发流程的改变、涉及到人员的考评标准，所以它有时会对整个企业产生影响。 测试工具应该能够管理测试过程和测试文档，并生成各种测试报告。 自动测试工具应该允许用户把自动测试数据和流程与手工的测试数据和流程结合到一起。,如何引入自动测试工具 3-2,自动测试工具应该能够将业务需求与测试计划、测试设计和测试结果相关联，允许最终用户根据测试结果来评估应用程序的完成情况。 自动测试工具中的各功能模块应该紧密集成到一起，共享和重用测试数据，支持回归测试。 工具应该可以很容易地利用过去的或者其他人员的测试资料。 工具内部应该使用一致的脚本语言和数据格式。,如何

28、引入自动测试工具 3-3,自动测试工具的体系结构和文件格式应该是开放的，可以很容易地与其他技术或工具进行交互和集成。 自动测试工具厂商应该有比较完善的科室培训和技术支持机制，能够为自动测试工具的实施提供咨询和支持。,Panorama产品内容,产品背景及功能 产品术语基础 应用原理及环境 工具介绍 OO-Test 其它工具请按照上机安排操作,测试工具Panorama,Panorama-2 C/C+ 是一个软件测试工具。 它也用来 QA 维护环境 它运行在 Sun OS/Solaris 和 Windows NT/95 上，支持 Sun C、C+。,Panorama产品背景及功能 3-1,产品背景

29、集成了8个产品/32个工具的软件包，一般用于： 1、新系统开发过程中的质量保证和单元测试； 2、旧系统维护过程中质量保证与测试 3、再工程中的系统分析,Panorama产品背景及功能 3-2,Panorama产品背景及功能 3-3,OO-Test：测试用例生成和管理： 1、记录和生成测试用例 2、最小化测试用例集 3、测试覆盖分析,OO-Browser：系统结构分析： 1、生成系统中类和函数的继承/调用关系图 2、实现代码与关系图的双向对应和跳转 3、显示系统结构测试覆盖结果,OO-Diagrammer：流程结构分析： 1、生成控制流程图、逻辑流程图、代码流程图 2、实现代码与流程图的双向对应

30、和跳转 3、显示流程结构测试覆盖结果,OO-SQA：质量度量分析： 1、设定质量度量标准和指标 2、生成质量度量数据 3、显示质量度量结果,OO-Analyzer：系统文档生成： 1、生成100多种设计文档和质量文档,OO-Playback：GUI测试过程回放： 1、捕获并记录测试过程 2、回放测试过程 3、比较回放结果,OO-MemoryChecker：内存泄漏和非法使用检测： 1、检测内存泄漏和非法使用 2、记录错误发生的语句位置 3、生成检测报告,OO-DefectTracer：缺陷定位和追溯： 1、检测并记录缺陷(包括死机)发生的路径和语句位置 2、生成缺陷定位报告,产品背景及功能,产

31、品功能应用： 新系统开发支持 旧系统维护支持 系统再工程支持 其他,1、设计支持 -系统结构/流程结构自动生成与维护 -多重复杂性度量及分析 -生成复杂性度量报告 2、编码及调试支持 -确定编码顺序 -保证编码和设计的双向对应 -生成代码逻辑结构 -显示测试路径和频率 -显示错误(尤其是意外中止)的语句位置和执行路径 3、测试支持 -确定单元测试顺序 -生成并管理测试用例 -执行测试用例并显示结果 -测试分析和度量 -支持回归测试 -生成质量报告,1、复杂性度量支持 -多重复杂性度量及分析 -生成复杂性度量报告 2、代码修改支持 -系统结构/流程结构自动生成与维护、编码和设计的双向对应、错误定

32、位和追溯 -加强代码理解、避免修改的副作用 -帮助代码静态分析技术的实施 3、测试支持 -确定单元测试顺序 -生成并管理测试用例 -执行测试用例并显示结果 -测试分析和度量 -支持回归测试 -生成质量报告,1、系统设计分析 -系统结构/流程结构自动生成与维护，加强设计理解 -编码和设计的双向对应，加强代码理解 2、系统复杂性分析 -多重复杂性度量及分析 -生成复杂性度量报告 3、系统性能分析 -分析模块执行性能和执行瓶颈 4、文档报告生成 -生成多种系统分析报告和质量报告,1、支持工程管理和进度估算 -代码文件和设计文档的一致性维护 -多种度量分析方法 2、训练项目组新进人员 -理解系统结构和

33、流程结构 -方便阅读和理解代码 3、支持验收评估 -自动生成设计和编码文档 -自动生成测试分析报告 -自动生成质量度量报告,产品术语基础 2-1,基本概念 1、块，也叫基本段、可视段 2、不可视段 基本不可视段： if,switch 高端循环边界(执行0次循环体) 低端循环边界(执行1次循环体) 3、段，也叫标准段 包括可视段与基本不可视段 4、增强段 包括可视段和不可视段,产品术语基础 2-2,质量保证度量规范 1、代码可读性度量 2、复杂性度量 3、测试覆盖度量 IEEE度量标准 1、环形复杂性 2、测试覆盖度量,1、程序行数 2、代码行百分比 3、注释行百分比 4、空格间隔行百分比,1、

34、环形复杂性 2、块测试复杂性JC0 3、段测试复杂性JC1 4、增强段测试复杂性JC1+ 5、条件段测试复杂性JC2 6、继承树深度DIT 7、子类数目NOC 8、类耦合数目CBO 9、类中方法数目 10、类中响应方法数目RFC 11、使用类中方法的函数数目 12、类中重用基类代码行数 13、类中重用基类代码百分比,1、块测试覆盖SC0 2、段测试覆盖SC1 3、增强段测试覆盖SC1+ 4、J-覆盖 5、条件真覆盖 6、条件假覆盖 7、总条件覆盖 8、分支覆盖,1、定义： -环形复杂性C -区域数目RG -边数目E -节点数目N -分支节点数目SN 2、计算公式： -C=RG -C=E-N+2

35、 -C=SN+1,1、原语 -程序 -功能 -数据 -需求 -测试用例 2、测试覆盖TC计算公式： -TC=(测试的需求原语数目) /(需求原语总数) * (测试的程序原语数目) /(程序原语总数),应用原理与环境 2-1,使用流程,.mak文件是C/C+编译文件,.hsi文件是Panorama内部使用的输入缓冲区文件，用于记载C/C+文件结构信息,.dbs文件是Panorama内部使用的数据库文件，用于记载C/C+文件分析和测试结果信息，一般与his文件配合使用,应用原理与环境 2-2,应用原理,工具的局限性,局限性 1、中文显示问题 2、使用自己的脚本技术，但这种脚本技术与其他的测试工具不

36、兼容 3、需要执行 .mak 文件，而不是编译 C 程序后生成的 .obj 文件 4、仅能处理 C / C+ 程序 5、界面不够友好,OO-Test 2-1,输出结果 测试用例最小集合 测试结果分析数据 作用： 生成并管理测试用例 最小化测试用例集 测试结果记录和分析,OO-Test 2-2,生成并保存测试用例 加载测试用例 执行测试用例 测试结果分析 测试覆盖结果 测试用例效率 最小化测试用例集,总结,测试工具是辅助测试整个过程的工具软件。 单元测试工具的种类和优势、缺陷。 健壮的测试工具的引入应该具有一定的设计原则。 介绍Panorama产品内容和运行环境、使用原理、各个工具的简单运用以及

37、缺陷。,第四章,测试计划和单元测试,回顾,测试工具是辅助测试整个过程的工具软件。 单元测试工具的种类和优势、缺陷。 健壮的测试工具的引入应该具有一定的设计原则。 介绍Panorama产品内容和运行环境、使用原理、各个工具的简单运用以及缺陷。,本章目标,计划测试过程 制定单元测试说明书 明确测试用例设计技术 单元测试的测试手段,基本测试过程,基本测试过程原则：尽早测试、经常测试、充分测试。 开发过程与测试过程：分析、测试、设计、测试、编码、测试 。 测试计划应该是按照开发者的要求并用具体例子来描述一个测试计划的层次结构以及各个测试计划相联系的标准模版。,测试的五个问题,谁执行了测试？ 测试什么？

38、 什么时候测试？ 怎样测试？ 测试应进行到何种程度？,测试方案设计,良好的测试设计由以下的若干个方面组成： 测试策略 测试计划 测试说明书 测试规范 这些方案适用于从单元测试到系统测试等各个级别的测试。测试设计需要根据软件说明书来进行。,单元测试 2-1,概况 定义： 检验程序最小单位有无错误。一般在编码之后，由开发人员完成。 单元：软件开发中的最小的独立部分 C语言中的单元：函数或者是子过程 C+语言中的单元：类,单元测试 2-2,单元测试目前状况： 实施效果非常好，但是实施阻力比较大(主要是人员和管理因素)，一般只在关键的程序单元中实施 有比较系统的理论和方法，但也依赖于系统的特殊性和开发

39、人员的经验 有大量的辅助工具，开发人员也经常自己开发测试代码和测试工具 主要使用白盒测试和静态分析，也使用黑盒测试,单元测试流程,管理流程 主要指动态测试应用流程,针对测试目标，规定测试任务、资源分配、人员角色、进度安排等。,根据测试计划，设计测试用例，包括：测试步骤、测试场景、测试代码、测试数据(包括预期结果)。,根据测试计划，配置测试环境，并手动或者自动执行测试设计。,根据测试计划，忠实地记录测试执行的过程和结果。,分析测试记录，如果发现与预期结果不同，确定并重现缺陷。,检查测试设计是否全部执行完毕，缺陷是否全部关闭。,记录、分发、评估、关闭缺陷报告。,分析测试过程和缺陷报告，评估测试质量

40、和测试效果，给出是否通过测试的建议。,测试用例 2-1,测试用例是数据输入和期望结果组成的对 。,测试用例 2-2,ANSI/IEEE829标准列出了测试用例应该包含在内的重要信息： 标识符 测试项 输入说明 输出说明 环境要求 特殊要求 用例依赖性,单元测试说明书的组成,单元测试说明书由一系列单元测试用例组成。每个单元测试用例都应该包括四个基本要素（对照ANSI/IEEE标准）： 单元的初始状态说明 单元的输入 测试用例实际要测试的内容 测试用例的预期结果,单元测试说明书(例)测试计划,编号 如：stb-tp0013 标题 如：文字排版功能.字间距.MayCourse 版本号 如：V1.0

41、执行状态 如：未执行 修改记录 如：2003年7月28日；编制/修改；原因 测试目标 如：语句覆盖 测试人员 如：1负责执行测试用例xxx；2负责执行测试用例xxx 测试用例编号(多个) 如：stb-fg00021/stb-fg00031/stb-fg00035 被测试单元代码位置 如：$tag1/layout/MayCourse.cpp,单元测试说明书(例) 测试用例,编号 如：stb-tp00014 标题 如：测试“文字排版功能.字间距.MayCourse” 版本号 如：V1.3 执行状态 如：已经执行 修改记录 如：2003年7月29日；编制/修改；原因 测试步骤 如：配置运行环境；输入

42、测试数据；执行X功能/测试代码；观察/记录XX 测试场景 如：在联网的环境下 测试代码 如：stb-tp00021(位置)/stb-tp00035(位置) 测试数据 如：输入数据(输入文件、文字描述)；预期结果(性能、图片、文字描述),单元测试说明书(例) 测试记录,编号 如：stb-tp00015 标题 如：记录测试“文字排版功能.字间距.MayCourse”结果 填写记录 如：2003年7月30日；填写；原因 测试用例编号 如：stb-tp0015 输出结果 如：图片、文字描述 测试观察 符合/不符合期望结果,单元测试说明书(例)缺陷跟踪报告,编号 如：stb-tp00016 标题 如：文

43、字排版功能.字间距.MayCourse计算错误 版本号 如：V1.3 执行状态 如：空白/草稿/提交/审批/分发/正在修改/修改完毕/正在确认/关闭 修改记录 如：2003年7月31日；编制/修改；原因 测试环境和版本号码、程序编写人员 错误严重程度和优先级别 错误详细描述 重现步骤和方式、对应的测试记录编码 附件 建议修改方式 修改内容、结果及修改人员签字/日期 确认内容、结果及确认人员签字/日期,单元测试说明书(例) 总结报告,编号 如：stb-tp00017 标题 如：文字排版功能.字间距.MayCourse单元测试总结报告 版本号 如：V1.5 执行状态 如：已经提交 修改记录 如：2

44、003年8月1日； 编制/修改；原因 测试计划编号 计划执行情况 缺陷统计(缺陷总数/未解决数目)及为解决缺陷列表 后续处理措施 是否通过单元测试,制定单元测试说明书步骤,包含一组单独的单元测试用例的单元测试说明书的设计过程： 步骤 1 运行简单测试用例 步骤 2 正面测试 步骤 3 负面测试 步骤 4 考虑特殊事项 步骤 5 覆盖完成率测试 步骤 6 完善说明书，进行相对完整测试,测试用例设计技术,测试用例设计技术可以大体分成两个主要类别： 黑盒技术使用的是单元的接口和对功能的描述，而无需知道单元内部是如何构建的。 白盒技术使用的是有关单元内部如何工作的信息。 此外还有其他的技术，它们都不能

45、归入上面的类别中，例如错误猜测。,黑盒测试测试手段 2-1,根据说明书进行的测试 测试用例是通过通读相关的说明书而设计得到的。每个测试用例都应该测试说明书的一条或多条陈述。 等价划分 基本做法是将要测试的软件的输入和输出分成若干部分，对于特定部分中的任意值，软件行为都是等价的。,黑盒测试测试手段 2-2,边界值分析 它使用与等价划分相同的方法分析各个部分。但是，它假定错误最可能出现在各部分之间的边界处。 状态变换测试 当软件被设计成状态机或者软件实现的是以状态机为模型的需求的时候，状态变换测试特别有用。 测试用例通过生成导致转变的事件来测试状态之间的转换。,白盒测试测试手段 2-1,分支测试

46、测试用例被设计为检验对单元中的流分支或判定点的控制。 通常来说它的目的是要达到目标级别的判定覆盖率。 条件测试 条件测试的目标是设计测试用例以表明逻辑条件的单个组件和单个组件的组合是正确的。,白盒测试测试手段 2-2,数据定义 使用测试 它将测试用例设计为对成对的数据定义和使用进行测试。 设置数据项的值的地方就是数据定义，读取或使用数据的地方就是数据使用。 次边界值测试 很多情况下，各部分和它们的边界可以通过单元功能说明书来识别。 但是，单元可能会有内部边界值，它只能通过结构说明书来识别。,错误猜测,错误猜测主要是凭经验，同时还需要诸如边界值分析等其他技术的一些辅助。 凭借经验，测试设计者猜测

47、特定类型的软件中可能出现的错误类型，并设计测试用例来找到它们。 由有经验的工程师来进行错误猜测可能是最有效地设计能发现错误的测试的唯一方法。相反，任用不合适的人来进行错误猜测可能会浪费时间。,总结,良好的测试设计由若干个防范组成。 在单元测试中，测试应设计为检验各个单元是否实现了该单元的设计说明书中的所有设计判定 。 单元测试说明书由一系列单元测试用例组成。 测试用例设计技术可以大体分成黑盒和白盒两个主要类别。 错误猜测主要凭借测试设计者的经验。,第 五 章,度量测试结果与缺陷管理,回顾,良好的测试设计由若干个防范组成。 在单元测试中，测试应设计为检验各个单元是否实现了该单元的设计说明书中的所

48、有设计判定 。 单元测试说明书由一系列单元测试用例组成。 测试用例设计技术可以大体分成黑盒和白盒两个主要类别。 缺陷猜测主要凭借测试设计者的经验。,本章目标,对测试本身信任程度的量度 明白何时进行测试和使用覆盖率 进行缺陷管理,简介,测试全貌：测试计划、实际测试和写测试报告 度量是软件工程过程的一个关键要素。 度量标准用于理解所创建的模型的属性。,监视测试覆盖率,对于测试结果的评价，需要监视测试覆盖率。 要减少要测试的条件的数量，可以将系统分成多个独立的部分。 这样可以为代码测试的各个部分分别生成不同的条件组合。,逻辑覆盖测试方法 4-1,语句覆盖 选择足够的测试用例，使得程序中每一条可执行语

49、句至少被执行一次。 判定覆盖 选择足够的测试用例，使得程序中每一个分支判断的每一种可能结果(主要指switch-case情况)都至少被执行一次。判定覆盖也叫分支覆盖。 条件覆盖 选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的可能结果都至少被执行一次。,逻辑覆盖测试方法 4-2,判定/条件覆盖 选择足够的测试用例，使得同时满足判定覆盖和条件覆盖。 条件组合覆盖 选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的每一种可能组合结果都至少被执行一次。 路径覆盖 选择足够的测试用例，使得程序中所有的可能路径都至少被执行一次。,逻辑覆盖测试方法 4-3,逻辑覆盖测试方法 4-4,

50、需要完成的各种测试包括： 单元测试 集成测试 系统测试 验收测试 回归测试 在验收和回归测试后，对于覆盖率测试达到一定标准后，我们即发布软件。,测试覆盖率涉及的测试,什么是缺陷？,缺陷可以定义成： 没有实现预定的使用需求或合理期望 与规格说明书或标准存在偏差 在与标准的一致性方面导致客户不满的任何问题,为什么需要缺陷管理？,客户期望以较少的时间/成本获得较高的质量。 规格说明书在项目开发生命周期的后期往往会被修改。 测试所发现的缺陷常常会招致大量的软件开发成本。 新的开发方法、工具不断地实现。 软件管理不能让测试成为瓶颈并减慢开发速度。 测试需要快速、灵活和可靠。 我们需要有关测试充分性的证据

51、。,缺陷的生命周期,缺陷管理Defect级别,致命性缺陷（Critical） 数据丢失，数据计算缺陷、系统崩溃和非常死机 严重功能性缺陷(Serious) 规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运营 警告性缺陷(Moderate) 不影响业务运营的功能问题 建议性缺陷(Suggestion,Cosmetic) 软件设计和功能实现等不甚合理之处提出建议,缺陷管理修改的优先级,高优先级 中优先级 低优先级,缺陷管理缺陷描述,缺陷管理与缺陷跟踪有关项,缺陷管理缺陷分发对象,项目管理者 测试管理者 被分配修改缺陷的人 组件代码的编写人 测试小组中的其他成员,缺陷管理的实现阶段

52、2-1,这些阶段如下所示： 缺陷标识、记录和报告 缺陷的消除和跟踪 缺陷测量和根由分析 缺陷预防/过程改进 软件开发生命周期所有阶段的测试 安装测试工具,缺陷管理的实现阶段 2-2,缺陷管理问题包括： 缺陷遗漏 同类缺陷重复 精力分散 效率低 数据库更新不完全 分类不严谨 - 每个缺陷都被划分为缺陷的类型 用来攻击项目分类的缺陷数据 很多不负责任的缺陷 重置是一个瓶颈 相同的缺陷卷土重来,缺陷状态信息,缺陷状态信息应该包含下列信息： 缺陷的当前状态和状态历史记录描述 状态历史记录，包括描述日期、操作、执行者、实际工作量、结果状态和指定的下一个步骤的行。 下一个步骤估计需要付出的努力 完成的期望

53、日期 缺陷分析和度量 缺陷生命周期分布有助于深入了解缺陷结束所花天数、修复缺陷所需付出的努力和进度分析 对预计付出的努力相对于实际付出的努力的分析,缺陷报告 3-1,进行缺陷报告前执行的过程： 获取空白的缺陷表格 指定可用的信息 信息可用时不断更新 对缺陷信息进行分类，包括 一般信息 缺陷检测信息 缺陷消除信息 状态信息 估计要投入的努力、预计日期、实际日期以及缺陷在其整个生命周期中的变化。,所需的缺陷信息有： 有关缺陷性质、它的修复优先级等的基本信息； 描述 - 简要的文字 优先级（紧急、普通、不急）您的优先级，客户的优先级 严重程度（主要、次要、不严重）您的优先级，客户的优先级 原因关键字

54、（用于进一步分析） 症状（数据库损坏、可视数据缺陷、界面缺陷、等等）,缺陷报告 3-2,起源的阶段 找到的阶段 报告的数据 期望和实际的结束日期 描述 版本、日志、周期、过程、用例 - 发现缺陷的地方 报告者：（姓名、公司） 硬件操作系统 - 发现缺陷的平台 测试位置 附件/附加信息,缺陷报告 3-3,缺陷报告（印）,总结 2-1,度量是软件工程过程的一个关键要素。 可以在源代码中插入语句以收集程序数据，例如计算每个分支的每一侧被遍历了几次，或者每一段代码是否都被执行过，执行了几次。 测试覆盖率是对最后的测试结果提供度量的信任标准。 理解缺陷的定义和测试过程中对缺陷管理的必要性,总结 2-2,

55、软件缺陷的生命周期：打开、解决和关闭。 缺陷管理报告中应该包含对于整个缺陷涉及到的各种因素进行管理。,第 六 章,能力成熟度模型,回顾,度量是软件工程过程的一个关键要素。 可以在源代码中插入语句以收集程序数据，例如计算每个分支的每一侧被遍历了几次，或者每一段代码是否都被执行过，执行了几次。 测试覆盖率是对最后的测试结果提供度量的信任标准。 理解缺陷的定义和测试过程中对缺陷管理的必要性,回顾,软件缺陷的生命周期：打开、解决和关闭。 缺陷管理报告中应该包含对于整个缺陷涉及到的各种因素进行管理。,本章目标,理解能力成熟度模型 理解能力成熟度模型中的不同等级 理解ISO的流程体系,简介,“能力成熟度模

56、型”是 SEI 在 1986 年开发的过程，用于改善组织的软件技术的应用过程。 这个过程分为五个定义良好的顺序提高的等级： 初始级 可重复级 已定义级 已管理级 优化级,CMM的产生背景,当今的软件组织工作在一个竞争和变化日益加剧的环境中。 成功的软件组织通过为现有产品开辟新的市场或满足新的需求来积极有效地面对变化。 许多公司面对变化没能采取主动有效的措施，而被其产品开发工作的缺乏控制所牵掣。 许多公司不能够正确地预测、控制和改进特定产品或合同的利润空间、产品装运日期或产品质量。,CMM,CMM 是设计用来帮助组织解决这些问题的。 CMM 提供了一种有效的和可验证的方法，用以不断地加强对产品开

57、发过程的控制，并改进产品开发过程。 CMM 提供了一个标尺，使组织能够根据该标尺对其生产过程进行定期的测量，也提供了进行优化及管理改进工作的数据。 CMM 描述了软件特有的产品开发实践和所有组织必须遵守的通用管理实践。,SECAT,SECAT 支持应用于行业中的大部分主要的 CMM模型，特别是： 集成产品开发能力成熟度模型 (IPD-CMM) 软件能力成熟度模型 (SW-CMM) 软件获取能力成熟度模型 (SA-CMM) 系统工程能力成熟度模型 (SE-CMM) EIA I/S 731：系统工程能力模型 (SECM) 系统安全工程能力成熟度模型 (SSE-CMM),CMM 等级,1 级：初始级 2-1,开发团队对每个项目采用不同的处理方式。 可能取得巨大的成功，但以后可能不会成功。 某些时间/成本估算是准确的，但大多数估算与实际相去甚远。 成功依赖于杰出的人员和他们的努力。,1 级：初始级 2-2,杰出的人员离开后，很难再次获得成功。 经常出现危机和紧急修改工作。（许多人认为这是软件开发过程中不可避免的。但是 CMM 不这样认为。） 大多数的软件开发组织处于1级。,2 级：可重复级 3-1,纪律化的过程 用于管理软件项目的方针和实施这些方针的规程都已制定。 项目级想法，可造，类似项目成功经验可重用。,2 级：可重复级 3-2,软件项目标准均已确定，并