软件测试培训课件（ppt 精品）

ISTQB 基础级培训讲义 北京昱达环球科技有限公司 版权所有 北京昱达环球科技有限公司 北京昱达环球科技有限公司 版权所有 2 目录 一、国际软件测试认证委员会(ISTQB) 简介 二、软件测试基础 三、软件测试与软件生命周期 四、软件静态测试技术 五、软件测试设计技术 六、软件测试管理 七、软件测试工具 北京昱达环球科技有限公司 版权所有 3 昱达公司简介 n昱达环球科技有限公司(IGS)是中国首家专注于全球化、国际化和本 地化新兴产业，开展全球化咨询、技术开发和人才培训，为中外企 业提供信息全球化解决方案的供应商，是国际软件测试认证委员会 （ISTQB）中国分会在北京唯一授权培训和认证机构。 n公司地址：北京市朝阳区北苑路68号星河写字楼204室 n邮政编码：100012 n公司网站： n培训邮箱：CSTQB n联系电话n移动电话北京昱达环球科技有限公司 版权所有 4 一、ISTQB CTFL简介 CSTQB软件测试基础级培训教程 北京昱达环球科技有限公司 版权所有 5 ISTQB与CSTQB简介 nISTQB简介 n国际软件测试认证委员会ISTQB (International Software Testing Qualification Board)于2002年在英国成立。 nISTQB是国际唯一权威的软件测试资质认证机构，现有包括美国、德 国、英国、法国、日本等47个成员国。 n中国软件测试认证委员会 (CSTQB)在2006年成为ISTQB的正式成员。 nISTQB培训与认证体系 nISTQB-Certified Tester培训及认证体系分为三个级别： n基础级/Foundation Level n高级/Advanced Level：3年以上测试工作经验 n专家级/Expert Level ：5年以上测试工作经验 n培训者获得基础级证书后，可申请参加更高级别的培训和认证考试， 并获得相应证书。 北京昱达环球科技有限公司 版权所有 6 CSTQB FL 培训内容 课程模块模块内容 第一部分：测试的基础知识 测试的基本原则 基本的测试过 程 测试的理念 第二部分：软件生命周期中的测试 软件开发模型 测试级别 测试类 型 维护测试 第三部分：静态技术 评审的测试过 程 工具支持的静态分析 第四部分：测试设计 技术 黑盒技术 白盒技术 基于经验的技术 第五部分：测试管理 测试的组织结 构 测试计 划的估算 测试进 度监控 配置管理 风险和测试 第六部分：测试的工具支持 测试工具的类型 高效率使用工具 组织中工具的引入 北京昱达环球科技有限公司 版权所有 7 ISTQB CTFL认证考试 n考试形式 n闭卷笔试 n考试卷包含40道单选选择题（给定的答案中只有一项是正确的） n考试时间为1小时 n分数达到65%以上（26题以上含26题）通过考试 n考试内容与比例 章节名称题目数量级别数量百分比 K1K2 K3 测试 的基础知识743018% 软件生命周期中 的测试 642016% 静态技术32107% 测试设计 技术1242629% 测试 管理833221% 测试 的工具43109% 北京昱达环球科技有限公司 版权所有 8 二、软件测试基础 CSTQB软件测试基础级培训教程 北京昱达环球科技有限公司 版权所有 9 目录 n 为什么需要软件测试 n 软件测试与软件质量 n 软件测试的目的与原则 n 软件测试过程 北京昱达环球科技有限公司 版权所有 10 软件测试术语（1） n术语 n错误 Error，Mistake n缺陷 Defect，Bug，Fault n失效 Failure n说明 n程序员可能会犯错误，由此在程序或文档中产生缺陷。 n如果执行了代码中的缺陷，软件将可能无法实现应该实现的功能或者 产生了不应该实现的结果，由此产生失效。 n软件、系统或者文档中的缺陷可能导致失效，但是并不是所有的缺陷 都会导致失效。 n缺陷的产生是因为程序员容易犯错误，可能是因为时间压力，复杂的 代码，架构复杂，技术变更，或者系统交互等引起的。 n失效也可能是环境条件引起的。例如，辐射，磁场，电场，污染导致 硬件故障。或者由于改变了硬件的条件，对软件的执行产生影响。 n软件系统的失效不可能是老化或磨损引起的。 北京昱达环球科技有限公司 版权所有 11 软件测试术语（2） n错误error是广义的概念。错误是人为的原因导致一个不正确的结果 。它可以是程序内的内部错误，也可能是文档内的错误。 n缺陷是错误的具体表现，可以是不正确的文档，程序段，指令或数据 定义，它们可能会引起一个外部的失效(failure) 。 nbug，defect和fault同义。因为存在的缺陷(defect)而导致软件的运 行失败叫失效。 n失效是缺陷在执行测试软件时的外部反映。失效是（规范说明）期望 的值与实际（观察到）的值存在偏差。例如系统的不正确的反应，崩 溃，死机等。 n当缺陷引起了运行错误或对用户产生了消极影响时，它就被称为失效 。对缺陷最大的担心就是它会转变为失效，而失效将会对用户产生损 害。 n有一些缺陷可能永远也不会转变为失效，但有时一个缺陷又可能会引 起上百万的失效。 n缺陷可以通过静态测试发现,而失效只能通过动态测试发现。 北京昱达环球科技有限公司 版权所有 12 软件测试的总体目标 n总体目标 n发现缺陷 n获取对产品质量的信心 n提供用于决策的信息 n预防缺陷 早期测试开发阶段的测试运行阶段的测试 静态测试 组件测试 集成测试 系统测试 验收测试 非功能测试 维护测试 预防缺陷发现缺陷建立信心提供信息 北京昱达环球科技有限公司 版权所有 13 不同测试阶段的测试目的 n软件需求阶段对文档的静态测试是为了预防缺陷 n在开发阶段执行的测试（组件测试、集成测试和系统测试），测试 的主要目的可能是尽可能的使软件失效，从而发现和修改尽可能多 缺陷。 n在验收测试中，主要目的可能是用来确认系统是否按照预期工作的 ，从而在系统是否满足系统需求方面得到信心。 n在有的情况，测试的主要目的可能是对软件的质量进行评估（不是 为了修改缺陷），从而为利益相关人提供这样的信息：在给定时间 内发布系统版本是否存在风险？ n在运行测试阶段，测试的主要目标可能是为了评估系统的特征，比 如可靠性或可用性等。 n维护测试通常是为了验证在变更开发过程中是否有新的错误引入。 北京昱达环球科技有限公司 版权所有 14 测试和调试的区别 n调试（Debug）和测试（Test）是两个不同的概念。 n测试 n测试可以发现由于软件缺陷引起的失效。 n测试员执行测试。 n调试 n调试是一种开发活动，用来识别引起缺陷的原因，修改代码以 及验证是否正确的修改了软件的缺陷。 n开发人员执行调试。 n关系 n开发人员调试后的软件需要测试员进行确认测试，确认修改的 代码已经解决了失效问题。 n开发人员除了调试，也执行某些类型的测试 北京昱达环球科技有限公司 版权所有 15 测试在软件开发、维护和运行中的角色 n测试是软件质量保证的关键活动和方式 n对软件系统和文档进行严格的测试,可以减少软件系统在运行环境中的风险， 假如在软件正式发布之前发现和修正了缺陷，就可以提高软件系统的质量。 n测试对象包括软件产品（软件程序、手册和联机帮助）和开发过程产生的文 档 n测试也可能需要满足合同和法律法规的需求，或者是为了满足特定的行 业标准 n认证测试，微软认证Certification nGB18030测试 nISTQB测试认证 测试的工作产品(Work Product) n测试的工作产品指的测试依据（Testing basis） n例如，业务场景、用例、需求规格说明、设计文档和代码 北京昱达环球科技有限公司 版权所有 16 测试与软件质量 n借助软件测试，可以通过发现的缺陷度量软件的质量， 包括功能和非功能软件需求和特性（例如，可靠性、易 用性、有效性、可维护性以及可移植性）。 n测试如果发现较少或者没有发现缺陷，可以增强对软件 质量的信心。正确设计的测试执行通过后减少了系统的 整体风险级别。测试发现的缺陷修正（Fixed）后提高了 软件系统的质量。 n应该从以前项目中吸取教训。理解其它项目中发现的缺 陷的根本产生原因后，改进流程，这样可以避免再次产 生同样的缺陷，相应地改进了未来软件系统的质量。这 是质量保证的体现。 n测试应该集成为质量保证活动的一个组成部分（与开发 标准、培训和缺陷分析并列）。 北京昱达环球科技有限公司 版权所有 17 软件测试心理学 n软件测试需要独立性 n测试机构的独立有利于关注开发过程中工作产品中可能存在的缺陷， 可以避免开发人员（作者）的偏见 n独立并不等于完全代替开发人员，开发人员能有效的找到自己工作产 品中存在的缺陷 n软件测试独立的优点 n独立的测试员可以做到没有偏见，可以发现一些其他不同的缺陷。 n一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假 设。 n软件测试独立的缺点 n与开发小组脱离（如果完全独立）。 n开发人员可能失去对软件质量的责任感。 n独立的测试员可能是项目的瓶颈或者要为软件发布延时负责。 北京昱达环球科技有限公司 版权所有 18 软件测试独立的方式 n软件测试独立的方式 n测试的设计由开发人员自己完成； n测试由开发队伍的其他开发人员完成； n测试独立于本项目的开发队伍； n测试独立于本开发企业，来自于独立的第三方测试机构。 北京昱达环球科技有限公司 版权所有 19 软件测试与开发如何相处 n合作、沟通、交流、中立、目标一致 n测试人员发现软件工作产品的缺陷某种程度上是对工作产品和其作者 的批评，所以软件测试常常被看成一种消极的活动，尽管软件测试对 软件开发的风险具有很强的规避作用。 n如果测试人员与分析、设计和代码开发人员能很好的沟通，那么他们 对测试人员的不好感将避免。软件工作产品的缺陷信息有助于提高开 发者的技能，也为开发过程节约成本和时间，降低软件开发风险。 n测试人员和测试管理者之间也应该具有好的沟通，通过规则的交流途 径交流测试中的缺陷信息、进展情况和风险。 n如果测试人员把自己发现缺陷作为一个新闻来传播，那么会给沟通带 来麻烦。 北京昱达环球科技有限公司 版权所有 20 软件质量保证 n软件质量保证(SQA)的对象是过程，质量保证的重要工作通过预防、检查与 改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开 展质量保证工作。 n软件测试与软件质量保证的关系 nSQA侧重对流程中过程的管理与控制，是一项管理工作，侧重于流程和方法。 n软件质量保证的职能是向管理层提供正确的可视化的信息，从而促进与协助流 程改进。 nSQA还充当测试工作的指导者和监督者，帮助软件测试建立质量标准、测试过程 评审方法和测试流程，同时通过跟踪、审计和评审，及时发现软件测试过程中 的问题，从而帮助改进测试或整个开发的流程等 n有了SQA，测试工作就可以被客观的检查与评价，同时也可以协助测试流程的改 进。. n测试是对软件产品的检验，是一项技术性的工作，软件测试的对象是产品，测 试人员要“执行”软件，对过程中的产物-开发文档和源代码进行走查，运行 软件，以找出问题，报告缺陷。 n软件测试是寻找缺陷的策略，SQA是规避缺陷的策略。 北京昱达环球科技有限公司 版权所有 21 软件质量保证与软件测试的比较 软件质量保证软件测试 目标 通过监控软件开发过程，保证产品质量 保证开发出来的软件和软件开发过程符合相 应标准与规范 保证软件产品、软件过程中存在的问题得到 处理，必要时将问题反映给高级管理者 确保项目组制定的计划、标准和规范适合项 目组的需要，同时满足评审和审计需要 尽早、尽可能多发现软件系统中存在的缺陷 和问题 内容 建立软件质量保证活动的组织 制定软件质量保证计划 实施各阶段的评审和审计，跟踪结果并作相 应处理 监控软件产品质量 采集软件质量保证活动的数据 度量软件质量保证活动 编写软件测试计划 编写测试用例 对软件开发过程的重要文档进行测试，包括 需求文档和设计文档 执行软件测试 测试结果分析与总结 测试数据的度量 说明测试对过程的监督和控制对过程的产物和开发出的软件产品剖析 北京昱达环球科技有限公司 版权所有 22 软件测试的充分性 n为什么考虑测试的充分性？ n测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被 测软件或系统。软件可以发布表示可以进入下一个开发过程，或将 系统交付给用户。 n测试的特征 n测试是高风险的质量保证活动，测试是不能穷尽的 n在有限的预算、时间、资源下，尽可能多的发现和报告缺陷 n判断测试是否充分的考虑因素 n风险（包括技术风险、商业产品风险和项目的风险等） n项目在时间和预算上的限制等。 北京昱达环球科技有限公司 版权所有 23 软件测试的目的 nGrenford JMyers n测试是程序的执行过程，目的在于发现错误 n一个好的测试用例在于能发现至今未发现的错误 n一个成功的测试是发现了至今未发现的错误的测试 nBill Hetzel n提出了测试目的不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度 量和评估，以提高软件的质量。 n当前业内普遍接受的测试目的 n以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错 误和缺陷提高软件质量，避免软件发布后由于潜在的软件缺陷和错误造成的隐患 所带来的商业风险。简而言之，软件测试的目的是降低软件风险，保证软件质量 n测试是以评价一个程序或者系统属性为目标的活动，测试是对软件质量的度量与 评估，以验证软件的质量满足用户的需求的程度，为用户选择与接受软件提供有 力的依据。 n通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷 ，以便进行软件过程改进。同时，通过对测试结果的分析整理，还可以修正软件 开发规则，并为软件可靠性分析提供依据。 北京昱达环球科技有限公司 版权所有 24 软件测试的原则 1.所有的软件测试都应追溯到用户需求 2.应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭 3.完全测试是不可能的，测试需要适可而止 4.测试只能证明软件存在错误而不能证明软件没有错误 5.充分注意测试中的缺陷群集现象 6.程序员应避免检查自己的程序（测试独立性） 7.测试的“杀虫剂”效应 北京昱达环球科技有限公司 版权所有 25 所有的软件测试都应追溯到用户需求 n从根本上讲，判断软件现象是否是缺陷的依据是是否满足用户需求 n显性需求 n隐性需求 n软件的目的是使用户完成预定的任务，并满足用户的需求 n软件测试所揭示的缺陷和错误使软件达不到用户的目标，满足不了用 户需求 北京昱达环球科技有限公司 版权所有 26 尽早地和不断地进行软件测试 n在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且 应该将关注点放在已经定义的测试目标(test objective)上 n早期发现和修改缺陷成本最小 n每个软件Build都应该被测试，而不是等到最后一个Build才进行测试 n经验数据示例 北京昱达环球科技有限公司 版权所有 27 穷尽测试是不可能的 n测试是有计划的，产品要发布，市场不允许无限期测试 n被测试软件复杂，需要测试的内容很多 n测试预算和资源有限，测试需要适可而止 n除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不 现实的。 n通过运用风险管理(Risk management)和不同系统功能的测试优先级 ，来确定测试的关注点，从而替代穷尽测试 北京昱达环球科技有限公司 版权所有 28 测试显示缺陷的存在 n测试只能表明软件存在缺陷，不能说明软件不存在缺陷 n测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺 陷，也不能证明软件或系统是完全正确的 n由于软件测试不能穷尽测试，因此，经过测试的软件仍然含有未知的 缺陷 北京昱达环球科技有限公司 版权所有 29 缺陷的群集现象 n版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少 数软件模块引起的 n如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应 当花费较多的时间和代价测试这个程序模块。 北京昱达环球科技有限公司 版权所有 30 测试的独立性 n人为心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事 ，不愿否认自己的工作 n由于思维定势，人们难于发现自己的错误 n程序员应该避免全部测试自己的程序和文档 n为达到测试目的，应由客观、公正、严格的独立的测试部门或者独立 的第三方测试机构进行测试 北京昱达环球科技有限公司 版权所有 31 测试的“杀虫剂”效应 n同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺 陷 n为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改 n需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从 而发现潜在的更多的缺陷 n重复测试、不间断测试、更新测试内容和测试用例 北京昱达环球科技有限公司 版权所有 32 软件测试的基本过程 n软件测试计划和控制 n测试分析和设计 n测试实施和执行 n退出测试的标准 n测试报告 n测试结束活动 开始 结束 测试计划 跟踪 控制 分析与设计 实现与执行 评估与报告 完成测试 测试计划 测试进度表 测试方法 逻辑测试用例 测试规格说明 物理测试用例 测试环境. 测试日志 缺陷报告 测试总结报告 北京昱达环球科技有限公司 版权所有 33 软件测试计划和控制 n定义 nANSI/IEEE软件测试文档标准829-1983将测试计划定义为：“一个叙述了预 定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特 征、测试任务、人员安排，以及任何偶发事件的风险。” n作用 n借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试 任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测 试过程中的各种变更。 n内容 n指明测试范围、方法、资源，以及相应测试活动的时间进度安排表。 n包含测试目标、项目概述、组织形式、角色及职责、测试对象、测试通过和失败 的标准（测试何时结束、度量的尺度如何、度量的评价标准等）、测试挂起的标 准及恢复的必要条件、测试任务的安排、应交付的测试工作产品、工作量估计等 。 n特点 n一般开始于软件需求分析结束阶段 北京昱达环球科技有限公司 版权所有 34 软件测试计划内容与实例 n计划内容 n测试项目概述 n需要测试的功能 n不需要测试的功能 n测试策略 n测试中断与恢复的规定 n测试完成后需要提交的内容 n测试环境的设置 n测试人员的工作分配 n测试人员的能力与培训 n测试进度表 n测试风险 n计划实例 n简单的测试计划 n复杂测试计划 n附录A：测试计划模板 北京昱达环球科技有限公司 版权所有 35 软件测试控制 n利用事先定义的度量评估和分析测试结果 n监督和记录： n测试进度 n测试的覆盖状况 n测试的结束条件 n是否偏离计划 n确定是否需要采取纠正措施 n确定是否需要更改原计划 n对测试计划的执行进行反馈 北京昱达环球科技有限公司 版权所有 36 软件测试分析和设计 n不同阶段的分析和设计依据不同 n在组件（单元）测试阶段分析的依据是详细设计规约 n在集成测试阶段分析的依据是概要设计规约 n在系统测试阶段分析的依据是需求分析规约 n在分析过程中规约不是惟一的依据，由于软件开发过程中的文档可能 不是十分的完整，这就要求测试分析人员从其他方面进行分析作为补 充。 北京昱达环球科技有限公司 版权所有 37 软件测试分析和设计 n对测试依据（需求、结构、设计、接口）进行评审/分析，为对所有测试点设 计测试用例做好准备 n以测试分析为基础并结合软件测试方法和技术进行测试设计 n从产品原型分析角度出发，与当事人交流和沟通（开发者和用户等） n对需求和测试对象的可测试性进行评价 n在分析测试对象、规约说明、测试对象间的关系和结构的基础上，确定测试 条件（例如验证需求）以及所需的测试数据 n使用测试策略内规定的测试方法设计逻辑测试用例（测试用例的架构） n测试用例的设计应该从逻辑测试用例到实际测试用例的设计过程，设计用例 的多少应该充分考虑测试子系统或模块在整个系统中的重要性，用例的设计 同时要考虑用例执行应该具备的前提条件设计测试环境，包括必要的基本设 施和工具 n测试设计包括测试用例设计、测试工具设计或选择、测试脚本设计、测试缺 陷管理工具设计或选择，测试管理模板设计 n测试用例设计是测试设计的重要内容，黑盒、白盒、灰盒测试用例设计 n从软件的流程图、功能点、状态图、use-case图等方面进行测试用例的设计 n细化测试进度表 北京昱达环球科技有限公司 版权所有 38 测试的实现与执行 n测试的实现(Implementation) n从测试条件具体到可执行的测试用例（即从逻辑测试用例到实际的测试用例）， 以及必要的测试件（文档和工具） n借助于测试准则，确定测试期望结果 n根据风险判定测试用例的优先级 n生成测试数据 n测试对象的输入值和状态值以及期望值，或在运行有关的测试用例后的期望 结果 n建立和检查测试环境，以确保配置的正确性 n构建测试台(Test bed)和编写测试自动化脚本 n组合成测试套件（Test suites）/测试序列（多个单个测试用例形成的逻辑集） ，并完成测试规程（Test procedure） n测试套件是用于被测组件/系统的一组测试用例。在这些测试用例中，一个 测试用例的后置条件（Post condition）常作为下一个测试的前置条件（ Precondition） 北京昱达环球科技有限公司 版权所有 39 测试的实施与执行 n测试的准备 n测试环境的准备（软件、硬件、网络） n测试对象是否按照规定构建并准备完毕，测试程序、测试脚本是否准备 完毕 n缺陷管理系统和测试文档是否准备完毕 n测试辅助件的准备：测试驱动器和测试桩、测试模拟器及测试工具等。 北京昱达环球科技有限公司 版权所有 40 测试的实施与执行 n测试的执行 n测试某个软件组合或系统并产生实际结果的过程 n按照测试计划和测试规约说明执行手动测试的测试用例和自动测试的测试用例 n比较实际的和期望的结构，分析期望和实际结果偏差的原因（测试对象和测试件 的错误等） n提交事件（Incidents），即在测试过程中出现的，并且在此后还需要检查或者 关注的事件 n记录 n测试结果（测试日期、时间、测试人员、输入的测试数据和期望值、测试对 象的ID标识/版本号，测试工具和测试方法，测试结果和后续动作包括测试 缺陷报告和修改测试用例），如果可能给出错误的原因，记录特殊情况。 n如有必要，补充新的测试用例 n执行确认测试和回归测试，用于确认错误更改是否有效，或者执行已经更改的测 试用例 n测试日志 n即关于测试执行的按时间顺序的详细记录 北京昱达环球科技有限公司 版权所有 41 测试退出的标准 n测试退出的标准 n计划中的测试用例是否执行完毕 n是否达到功能、语句等计划的覆盖指标 n继续测试发现缺陷的数量减少低于度量标准等 n满足测试计划中的测试退出标准 n测试评估 n对每个测试阶段都要进行评估是否达到测试退出的标准 n对测试记录评估，判断测试是否达到了测试计划规定的测试退出准则 n达到测试退出准则后，才进入下一个测试阶段 n评价是否需要继续执行进一步的测试或者需要更改已经定义好的测试退出准则。 例如，准则无法执行或者资源有限（费用、时间和人员）无法达到 n每个测试阶段结束后提供对被测系统和测试过程当前状况的评价 n给相关决策人员提交测试报告（包括测试活动和测试结果的文档，在规定的测试 退出准则下的测试运行的评估） 北京昱达环球科技有限公司 版权所有 42 测试结束活动 n测试结束的条件 n当一个软件产品正式上线应用后 n当开发（或测试）达到一个里程碑（Milestone) n一个维护版本结束时 n测试结束活动的内容 n检查是否所有计划的交付物都产生并交付了，或者产生交付了哪些 n事件报告的完成（缺陷报告，偏差报告.） n为仍然存在的错误/偏差提供变更需求 n系统验收的文档 n测试结果分析，测试总结，测试信息和数据备份（测试规约说明书、数据、测试日志等） n对测试发现的缺陷进行统计分类并分析原因 n制定的测试计划和实际的计划执行的差距并分析原因，哪些事件或风险没预料到，总结好的 经验等 n分析每个测试活动的计划和实施之间的偏差，并判断原因 n统计测试结果与测试开销的关系 n软件、硬件、文档和邮件的备份、销毁和退还 北京昱达环球科技有限公司 版权所有 43 总结 n失效是缺陷在执行测试软件时的外部反映，当缺陷被执行时产生软件失效 n软件测试独立有4种方式 n软件测试和软件开发是合作和交流的关系 n软件测试关注的是产品，软件质量保证关注的是过程 n实施软件测试需要理解和遵守条基本原则： n追溯到用户需求 n尽早和不间断测试 n不可能穷尽测试 n测试不能表明软件没有缺陷 n缺陷的群集现象 n开发人员避免检查自己的程序 n避免杀虫剂效应 北京昱达环球科技有限公司 版权所有 44 总结 n软件测试的内容 n计划和控制 n分析和设计 n实施和执行 n退出测试的标准 n测试报告 n测试结束活动 北京昱达环球科技有限公司 版权所有 45 练习作业 1.什么是软件测试？ 2.软件测试的目的是什么？ 3.软件测试的内容有哪些？ 4.什么是软件缺陷？软件失效？ 5.软件缺陷和软件失效之间有什么关系？ 6.引起软件失效的因素有哪些？ 7.软件为什么会存在缺陷？ 8.软件测试在软件开发、维护和使用中扮演什么角色？ 9.软件测试独立有什么好处？ 10.软件测试独立有哪些形式？ 11.软件测试和软件开发人员应该如何相处？ 12.什么是软件质量？ 13.什么是软件质量保证？ 北京昱达环球科技有限公司 版权所有 46 练习作业 14.软件测试和软件质量保证之间有什么相同和不同？ 15.确定软件测试的充分性的因素有哪些？ 16.软件测试的一般规则有哪些？ 17.软件测试的基本过程包括哪些内容？ 18.在软件测试的基本过程内，各个过程包括哪些内容？ 北京昱达环球科技有限公司 版权所有 47 三、软件测试与软件生命周期 CSTQB软件测试基础级培训教程 北京昱达环球科技有限公司 版权所有 北京昱达环球科技有限公司 版权所有 48 目录 n 软件开发模型 n 软件测试级别 n 软件测试类型 n 维护性测试 北京昱达环球科技有限公司 版权所有 49 软件开发模型 北京昱达环球科技有限公司 版权所有 50 软件开发模型简介 n软件生命周期 n软件需求、分析、设计、实现、测试、部署Deploy/Release、维护和退出的过 程，称为“软件生命周期”（Software Life Cycle） n概述 n软件开发模型是指软件开发所依据的方式和过程 n从事软件测试为什么要熟悉开发模型？ n测试不是孤立存在的，测试活动与开发活动是息息相关的 n每个开发活动都有相对应的测试活动 n不同的开发生命周期模型需要不同的测试方法 n每个测试级别都有其特有的测试目标 n对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计 n在开发生命周期中，测试人员在文档初稿阶段就应该参与文档的评审 n如何选择开发模型？ n根据项目的内容 n根据产品的特征 北京昱达环球科技有限公司 版权所有 51 软件开发V模型图 北京昱达环球科技有限公司 版权所有 52 验证与确认(V c=fun1(a,b); int fun1(int x, int y) return x+y; 问题： 假设这两个函数是两个人分别开发的，二者 开发进度不同，则如何测试？ 驱动模块和桩 驱动模块（driver）:对底层或子层模块 进行测试所编写的调用这些模块的程序 。 桩模块（stub）：对顶层或上层模块进 行测试时所编写的替代下层模块的程序 。 北京昱达环球科技有限公司 版权所有 70 集成测试概述 n概述 n通过单元测试的多个模块组合成更大的模块或子系统或产品，然后进 行测试 n集成测试是对组件之间的接口进行测试，以及测试一个系统内不同部 分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。 n测试依据 n软件和系统设计文档 n系统架构 n工作流 n用例 n测试对象 n子系统数据库实现 n基础设施 n接口 北京昱达环球科技有限公司 版权所有 71 集成测试的级别和内容 n集成级别 n集成测试，可以应用多种集成级别，也可以根据不同的测试对象规模 采用不同的级别。 n组件集成测试 n对不同的软件组件之间的相互作用进行测试，一般在组件测试之后进 行。 n系统集成测试 n对不同系统或软硬件之间的相互作用进行测试，一般在系统测试之后 进行。 n内容 n各单元的接口是否吻合 n代码是否符合规定的标准 n界面标准是否统一等 北京昱达环球科技有限公司 版权所有 72 集成的策略和方式 n策略 n根据系统结构（例如自顶向下或自底向上）、功能任务集、事务处理 顺序或系统和组件的其他方面等制定集成测试策略。 n为了能方便快速地隔离故障和定位缺陷，集成程度应该逐步增加，而 不是采用“大爆炸”式的集成。 n方式 n非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求 一次全部组装起来所要的系统，然后进行整体测试。非渐增式集成测 试是不科学的集成测试方式。 n渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起 来进行测试，测试完以后再把下一个模块结合进行测试 n自顶向下集成（Top-Bottom）：自顶向下集成时，前期完成 的模块将是后期模块的驱动程序（Driver） n自底向上集成：前期完成的模块将是后期模块的桩程序（ Stub） 北京昱达环球科技有限公司 版权所有 73 系统测试概述 n概述 n将经过确认测试的软件，与计算机硬件、外设、支持软件等一起，在实际运行环境下测试。 n系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。 n目的 n充分运行系统，验证系统各部件是否能正常工作，符合软件需求规格说明。 n测试依据 n系统和软件需求规格说明 n用例 n功能规格说明 n风险分析报告 n典型测试对象 n系统、用户手册和操作手册 n系统配置 北京昱达环球科技有限公司 版权所有 74 系统测试类型与方法 n类型 n功能测试 n非功能测试：压力测试/性能测试/容量测试 n用户界面测试 n兼容性测试 n国际化测试 /本地化测试 n测试方法 n基于需求的测试 n从需求导出测试目标和测试条件，设计测试用例，测试检查功能或者非功能特性 （可靠性和可用性）。 n基于业务流程的测试 n从业务流程的说明和对业务流程的理解导出和选择测试用例的测试方法。 n基于用例（Use Cases）的测试 n黑盒测试设计方法，根据实际的场景设计测试用例，进行测试。 n基于风险评估的测试 说明： n在系统测试中，测试环境应该尽量和最终的目标或生产环境相一致，从而减少不能发现和环境相关 的失效的风险。 n系统测试通常由独立的测试团队执行 北京昱达环球科技有限公司 版权所有 75 验收测试概述 n概述 n技术测试的最后一个阶段，在软件产品完成了系统测试之后、产品发布 之前所进行的软件测试活动 n验收测试通常是由使用系统的用户或客户来进行，同时系统的其他利益 相关者也可能参与其中。 n目的 n验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心 。 n验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的 要求，保证系统或软件产品最终被用户接受 n发现缺陷不是验收测试的主要目标。 n测试依据 n用户需求 n系统需求 n用例 n业务流程 n风险分析报告 北京昱达环球科技有限公司 版权所有 76 验收测试的对象和内容 n对象 n基于完全集成系统的业务流程 n操作与维护流程 n用户处理过程 n结构 n报告 n内容 n安装测试 n功能测试 n可靠性测试 n安全性测试 n性能测试 n易用性测试 n可移植性测试 n可维护性测试 n文档测试 北京昱达环球科技有限公司 版权所有 77 验收测试的特点 n验收测试不一定是最后级别的测试。 n可能会在进行某个系统验收测试之后，进行大规模的系统集成测试。 n验收测试可以在多个测试级别上进行 n商业现货软件(COTS)产品可以在安装或集成时进行验收测试； n组件的可用性验收测试可以在组件测试中进行； n增加新功能的验收测试可以在系统测试之前进行。 北京昱达环球科技有限公司 版权所有 78 验收测试的形式 n形式（5种类型） n用户验收测试 n操作验收测试 n系统操作验收测试由系统管理员来进行，测试内容主要包括： n系统备份/恢复测试； n灾难恢复测试； n用户管理测试； n维护任务测试； n数据加载和移植活动； n安全漏洞阶段性检查。 n合同和法规性验收测试 n合同验收测试根据合同中规定的生产客户定制软件的验收准则，对软件进行 测试。应该在合同拟定时定义验收准则。 n法规性验收测试根据必须要遵守的法律法规来进行测试，比如政府、法律和 安全方面的法律法规。 北京昱达环球科技有限公司 版权所有 79 验收测试的形式 nAlpha testing （ 测试） n在软件产品正式商业销售之前，市场或商业现货软件开发人员希望从市 场中潜在的或已经存在的客户中得到关于软件的反馈信息。 nAlpha测试通常在开发组织现场进行，但测试并非由开发团队执行。 nBeta testing（ 测试） nBeta测试或实地测试，是在客户或潜在客户现场进行并由他们执行。 n概念辨析 nAlpha testing （ 测试）：用户在开发环境下进行的测试，也可以是公 司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由 程序员或测试员完成。 nBeta testing（ 测试）：软件的多个用户在一个或多个用户的实际使用 环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员 或测试员完成。 北京昱达环球科技有限公司 版权所有 80 软件测试类型 北京昱达环球科技有限公司 版权所有 81 测试类型概述 n软件类型众多，不同的分类标准对应不同的测试类型 n分类： n功能性测试 n软件产品特性测试（非功能性测试） n软件结构性测试 n变更相关的测试 n确认/验证测试（再测试） n回归测试 n功能性测试和结构性测试可以应用于任何测试级别 北京昱达环球科技有限公司 版权所有 82 功能性测试概述 n概述 n功能性测试是基于软件产品功能和特征，以及专门的系统之间的交互进 行的测试 n可以在各个测试级别进行，既可以用于组件级别、也可以用于集成和系 统测试级别 n功能性测试不考虑程序的具体执行路径，仅关注功能是否实现 n功能测试的特点 n通常采用黑盒测试（Black-box Testing，又称为功能测试或数据驱动测 试），是把测试对象看作一个黑盒子。 n利用黑盒测试法进行动态测试时，只需要测试软件产品外部表现的功能 ，不需考虑软件产品的内部结构和处理过程。 北京昱达环球科技有限公司 版权所有 83 功能性测试的错误类型 n黑盒测试通常可以发现的错误类型 n功能错误或遗漏； n界面错误； n数据结构或外部数据库访问错误； n性能错误； n初始化和终止错误。 n注意： n安全性测试就是功能测试的一种 n对安全性相关的功能（比如防火墙）进行测试，从而检测系 统和数据是否能抵御外部恶意的威胁，如病毒等。 n互操作性测试是另一种功能性测试 n评估软件产品与其他一个或多个组件或系统交互的能力。 北京昱达环球科技有限公司 版权所有 84 非功能性测试 n概述 n为了测量系统和软件的运行特性，需要进行的测试。 n可以在任何测试级别上进行。 n基于产品的性能、负载、可用性、交互性、可维护性、可靠性及可移植 性等方面的测试。 n包括测试产品是否遵从指定的标准、规范和约束，以及操作界面的具体 细节和构造上的限制。 n通过测试，可以在不同尺度上来量化软件和系统的特征，比如进行性能 测试来检验系统和软件的反应时间。 n类型 n非功能测试包括但不限于：性能测试、负载测试、压力测试、易用性测 试、可维护性测试、兼容性、可靠性测试和可移植性测试 北京昱达环球科技有限公司 版权所有 85 结构测试概述 n概述 n结构测试也称白盒测试(White-box Testing，又称逻辑驱动测试)。 n把测试对象看作一个打开的盒子。 n利用白盒测试法进行动态测试时，可通过测试来检测产品内部动作是否按照规格 说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路 是否都能按预定要求工作，而不顾它的功能。 n最好在进行基于规格说明的测试之后使用，以便通过评估结构类型的覆盖，测量 测试的完整性。 n覆盖 n覆盖(coverage)是指通过测试套件检验的结构程度，以覆盖项(item)的百分比来 表示。 n假如覆盖率不是100，可能需要设计更多的测试用例，来测试被遗漏的项，从而 提高测试的覆盖。 n白盒测试的主要方法 n逻辑覆盖：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路 径覆盖 n基本路径测试 北京昱达环球科技有限公司 版权所有 86 结构性测试的特点 n特点 n可以在任何测试级别上进行结构测试。 n在所有的测试级别，特别是在组件测试和组件集成测试中，可以利用工 具来测量单元代码的覆盖，比如语句覆盖(statement coverage)和判定 覆盖(decision coverage)。 n结构测试可以基于系统的结构，比如调用层次结构。 n结构测试方法也可以运用到系统、系统集成或验收测试级别（比如业务 模型或菜单结构）。 n“白盒测试”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试 。 n“白盒测试”法是穷举路径测试。在使用这一方案时，测试者必须检查 程序的内部结构，从检查程序的逻辑着手，得出测试数据。 北京昱达环球科技有限公司 版权所有 87 结构性测试的缺点 n白盒测试的缺点 n穷举路径测试不能查出程序违反了设计规范，即程序本身是个错误的程 序 n穷举路径测试不可能查出程序中因遗漏路径而出错 n穷举路径测试可能发现不了一些与数据相关的错误 n经验与提示 n白盒测试和黑盒测试互相配合 n不同阶段采用不同的测试方法 n测试人员辅助程序员执行白盒测试 n设计白盒测试用例可能耗费很多时间 n大部分软件缺陷是黑盒测试方法发现的 北京昱达环球科技有限公司 版权所有 88 变更相关的测试概述 n 验证测试（再测试） n当发现和修改了一个软件缺陷后，需要重新进行测试以确定已经成功的 修改了原来的缺陷。这种方法称之为确认测试。 n回归测试（Regression Testing） n对已被测过的程序实体在修改缺陷后进行的重复测试，以此来检验在这 些变更后是否有新的缺陷引入系统。 n当软件发生变更或者使用软件的环境发生变化时，需要进行回归测试。 n回归测试的范围可以根据软件修改引起的风险程度来决定。 n假如测试用例是用来进行确认测试和辅助回归测试的，则它们应该是可 以重复进行执行。 n回归测试可以在所有的测试级别上进行，同时适用于功能测试、非功能 测试和基于结构的测试。 n回归测试套件一般都会执行多次，而且没有什么变化和修改通常变化很 少，因此回归测试强烈推荐自动化执行。 n新功能测试 北京昱达环球科技有限公司 版权所有 89 变更相关的测试 n回归测试用例 n能够测试软件的所有功能的代表性测试用例 n专门针对可能会被修改影响的软件功能的附加测试 n针对修改过的软件成分的测试 n经验与提示 n回归测试应当设计为只包括那些涉及在主要的软件功能中出现的一个或 多个错误类的那些测试 n各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗 留到下一测试阶段。 n回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改， 集中执行回归测试 北京昱达环球科技有限公司 版权所有 90 各种测试级别与测试方法对比分析 测试级别测试目的执行者测试环境测试方法 单元测试 从单个模块中 发现逻辑、数据和 运算缺陷 软件开发者单独的；桩和 支撑程序 白盒测试 集成测试 发现模块间接口缺 陷 软件开发者单独的和/或 模拟；桩和支 撑程序 白盒测试，黑盒测 试 系统测试 测定软件是否满足 需求 软件测试者实际的环境（ 可能没有最终 的硬件） 黑盒测试，白盒 测试 回归测试 确认软件经过一些 小的变更或修改后 是否仍满足所有的 需求 软件测试者 实际的环境（ 可能没有最终 的硬件） 黑盒测试 验收测试 确定软件是否满足 客户的需求 客户，软件 质保组和/ 或项目组 实际的环境（ 通常在客户方 ） 黑盒测试（客户可 能有自己的测试方 法） 北京昱达环球科技有限公司 版权所有 91 不同测试类型之间的关系 软件测试 测试级别 运行软件 查看代码 测试类型 组件测试 集成测试 系统测试 验收测试 动态测试 静态测试 黑盒测试 白盒测试 功能性测试 非功能性测试 结构性测试 维护测试 变更相关 的测试 确认测试 （再测试） 回归测试 北京昱达环球科技有限公司 版权所有 92 维护性测试 北京昱达环球科技有限公司 版权所有 93 维护性测试概述 n什么是维护性测试 n软件发布之后,系统通常要运行数年甚至数十年, 在软件生命周期中的维 护阶段，由于业务等方面的变化而进行修改、拓展、移植及部分软件被 淘汰等原因所进行的测试称为维护性测试。 n维护测试是在一个运行的系统上进行，且一旦对软件或系统进行修改、 移植或系统被淘汰时，就需要进行维护测试。 n修改可以是计划中的功能增强（例如：根据版本发布的计划）、修正和 应急变更、环境的变化，比如计划中的操作系统或数据库升级、为商业 现货软件计划升级或由于新发现或暴露的操作系统漏洞而打的补丁等。 n维护性测试可以理解为软件发布后的一种变更测试 n维护性测试和可维护性测试的区别 n维护性测试，由于维护开发,例如修改、拓展、移植及部分软件的退役等 都只是基于原系统的改动,并未从根本上改变系统。 n针对维护开发而进行的测试，完全可以遵从对原系统开发过程中测试的 流程，如组件测试、集成测试、系统测试和验收测试。 n可维护性测试是仅针对系统是否易于维护而开展的测试。 北京昱达环球科技有限公司 版权所有 94 维护性测试的特点 n维护性测试的特点 n维护测试根据变更情况的不同，可以在某一测试级别或所有测试级别和测试类型上 进行。 n维护测试的范围取决于变更后是否有产生新缺陷的风险、系统的规模和变更的大小 。 n维护测试