1、ISTQB 基础级培训讲义,北京昱达环球科技有限公司 版权所有,,昆山研达电脑科技有限公司,目录,一、国际软件测试认证委员会(ISTQB) 简介二、软件测试基础三、软件测试与软件生命周期四、软件静态测试技术五、软件测试设计技术六、软件测试管理七、软件测试工具,一、ISTQB CTFL简介,,CSTQB软件测试基础级培训教程,ISTQB与CSTQB简介,ISTQB简介 国际软件测试认证委员会ISTQB (International Software Testing Qualification Board)于2002年在英国成立。 ISTQB是国际唯一权威的软件测试资质认证机构，现有包括美国、德国
2、、英国、法国、日本等47个成员国。 中国软件测试认证委员会 (CSTQB)在2006年成为ISTQB的正式成员。 ISTQB培训与认证体系 ISTQB-Certified Tester培训及认证体系分为三个级别： 基础级/Foundation Level 高级/Advanced Level：3年以上测试工作经验 专家级/Expert Level ：5年以上测试工作经验 培训者获得基础级证书后，可申请参加更高级别的培训和认证考试，并获得相应证书。,CSTQB FL 培训内容,ISTQB CTFL认证考试,考试形式 闭卷笔试 考试卷包含40道单选选择题（给定的答案中只有一项是正确的） 考试时间为1
3、小时 分数达到65%以上（26题以上含26题）通过考试 考试内容与比例,二、软件测试基础,,CSTQB软件测试基础级培训教程,目录,为什么需要软件测试什么是测试软件测试的目的与原则软件测试过程,软件测试术语（1）,术语 错误 Error，Mistake 缺陷 Defect，Bug，Fault 失效 Failure 说明 程序员可能会犯错误，由此在程序或文档中产生缺陷。 如果执行了代码中的缺陷，软件将可能无法实现应该实现的功能或者产生了不应该实现的结果，由此产生失效。 软件、系统或者文档中的缺陷可能导致失效，但是并不是所有的缺陷都会导致失效。 缺陷的产生是因为程序员容易犯错误，可能是因为时间压力
4、，复杂的代码，架构复杂，技术变更，或者系统交互等引起的。 失效也可能是环境条件引起的。例如，辐射，磁场，电场，污染导致硬件故障。或者由于改变了硬件的条件，对软件的执行产生影响。 软件系统的失效不可能是老化或磨损引起的。,软件测试术语（2）,错误error是广义的概念。错误是人为的原因导致一个不正确的结果。它可以是程序内的内部错误，也可能是文档内的错误。 缺陷是错误的具体表现，可以是不正确的文档，程序段，指令或数据定义，它们可能会引起一个外部的失效(failure) 。 bug，defect和fault同义。因为存在的缺陷(defect)而导致软件的运行失败叫失效。 失效是缺陷在执行测试软件时的
5、外部反映。失效是（规范说明）期望的值与实际（观察到）的值存在偏差。例如系统的不正确的反应，崩溃，死机等。 当缺陷引起了运行错误或对用户产生了消极影响时，它就被称为失效。对缺陷最大的担心就是它会转变为失效，而失效将会对用户产生损害。 有一些缺陷可能永远也不会转变为失效，但有时一个缺陷又可能会引起上百万的失效。 缺陷可以通过静态测试发现,而失效只能通过动态测试发现。,什么是测试？,测试包含： 测试执行之前和之后的一些活动，包括计划与控制、选择测试条件、设计与执行测试用例，检查测试结果、评估出口准则、报告测试过程及被测系统、在一个测试阶段完成后要进行测试结束和总结工作。 测试同时也包括文档的评审（包
6、括源代码）和执行静态分析。 测试分为动态分析和静态分析两种手段,软件测试的总体目标,总体目标 发现缺陷 获取对产品质量的信心 提供用于决策的信息 预防缺陷,早期测试,开发阶段的测试,运行阶段的测试,静态测试,组件测试,集成测试,系统测试,验收测试,非功能测试,维护测试,预防缺陷,发现缺陷,建立信心,提供信息,不同测试阶段的测试目的,软件需求阶段对文档的静态测试是为了预防缺陷 在开发阶段执行的测试（组件测试、集成测试和系统测试），测试的主要目的可能是尽可能的使软件失效，从而发现和修改尽可能多缺陷。 在验收测试中，主要目的可能是用来确认系统是否按照预期工作的，从而在系统是否满足系统需求方面得到信心
7、。 在有的情况，测试的主要目的可能是对软件的质量进行评估（不是为了修改缺陷），从而为利益相关人提供这样的信息：在给定时间内发布系统版本是否存在风险？ 在运行测试阶段，测试的主要目标可能是为了评估系统的特征，比如可靠性或可用性等。 维护测试通常是为了验证在变更开发过程中是否有新的错误引入。,测试和调试的区别,调试（Debug）和测试（Test）是两个不同的概念。 测试 测试可以发现由于软件缺陷引起的失效。 测试员执行测试。 调试 调试是一种开发活动，用来识别引起缺陷的原因，修改代码以及验证是否正确的修改了软件的缺陷。 开发人员执行调试。 关系 开发人员调试后的软件需要测试员进行确认测试，确认修改
8、的代码已经解决了失效问题。 开发人员除了调试，也执行某些类型的测试,软件测试的原则,所有的软件测试都应追溯到用户需求 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭 完全测试是不可能的，测试需要适可而止 测试只能证明软件存在错误而不能证明软件没有错误 充分注意测试中的缺陷群集现象 程序员应避免检查自己的程序（测试独立性） 测试的“杀虫剂”效应,所有的软件测试都应追溯到用户需求,从根本上讲，判断软件现象是否是缺陷的依据是是否满足用户需求 显性需求 隐性需求 软件的目的是使用户完成预定的任务，并满足用户的需求 软件测试所揭示的缺陷和错误使软件达不到用户的目标，满足不了用户需求,尽早地和
9、不断地进行软件测试,在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义的测试目标(test objective)上 早期发现和修改缺陷成本最小 每个软件Build都应该被测试，而不是等到最后一个Build才进行测试 经验数据示例,穷尽测试是不可能的,测试是有计划的，产品要发布，市场不允许无限期测试 被测试软件复杂，需要测试的内容很多 测试预算和资源有限，测试需要适可而止 除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不现实的。 通过运用风险管理(Risk management)和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试,测试显
10、示缺陷的存在,测试只能表明软件存在缺陷，不能说明软件不存在缺陷 测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的 由于软件测试不能穷尽测试，因此，经过测试的软件仍然含有未知的缺陷,缺陷的群集现象,版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的 如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个程序模块。,测试的独立性,人为心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作 由于思维定势，人们难于发现自己的错误 程序员应该避免全部测试自己的程序和文档 为
11、达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试,测试的“杀虫剂”效应,同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺陷 为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改 需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷 重复测试、不间断测试、更新测试内容和测试用例,软件测试的基本过程,软件测试计划和控制 测试分析和设计 测试实施和执行 退出测试的标准 测试报告 测试结束活动,开始,结束,测试计划,跟踪 控制,分析与设计,实现与执行,评估与报告,完成测试,测试计划 测试进度表,测试设计规格说明 测试用例规格
12、说明,测试规程规格说明 测试日志/事件报告.,测试总结报告,软件测试计划和控制,定义 ANSI/IEEE软件测试文档标准829-1983将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。” 作用 借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 内容 指明测试范围、方法、资源，以及相应测试活动的时间进度安排表。 包含测试目标、项目概述、组织形式、角色及职责、测试对象、测试通过和失败的标
13、准（测试何时结束、度量的尺度如何、度量的评价标准等）、测试挂起的标准及恢复的必要条件、测试任务的安排、应交付的测试工作产品、工作量估计等。 特点 一般开始于软件需求分析结束阶段,软件测试计划内容与实例,计划内容 测试项目概述 需要测试的功能 不需要测试的功能 测试策略 测试中断与恢复的规定 测试完成后需要提交的内容 测试环境的设置 测试人员的工作分配 测试人员的能力与培训 测试进度表 测试风险 计划实例 简单的测试计划 复杂测试计划 附录A：测试计划模板,软件测试控制,利用事先定义的度量评估和分析测试结果 监督和记录： 测试进度 测试的覆盖状况 测试的结束条件 是否偏离计划 确定是否需要采取纠
14、正措施 确定是否需要更改原计划 对测试计划的执行进行反馈,软件测试分析和设计,不同阶段的分析和设计依据不同 在组件（单元）测试阶段分析的依据是详细设计规约 在集成测试阶段分析的依据是概要设计规约 在系统测试阶段分析的依据是需求分析规约 在分析过程中规约不是惟一的依据，由于软件开发过程中的文档可能不是十分的完整，这就要求测试分析人员从其他方面进行分析作为补充。,软件测试分析和设计,对测试依据（需求、结构、设计、接口）进行评审/分析，为对所有测试点设计测试用例做好准备 以测试分析为基础并结合软件测试方法和技术进行测试设计 从产品原型分析角度出发，与当事人交流和沟通（开发者和用户等） 对需求和测试对
15、象的可测试性进行评价 在分析测试对象、规约说明、测试对象间的关系和结构的基础上，确定测试条件（例如验证需求）以及所需的测试数据 使用测试策略内规定的测试方法设计逻辑测试用例（测试用例的架构） 测试用例的设计应该从逻辑测试用例到实际测试用例的设计过程，设计用例的多少应该充分考虑测试子系统或模块在整个系统中的重要性，用例的设计同时要考虑用例执行应该具备的前提条件设计测试环境，包括必要的基本设施和工具 测试设计包括测试用例设计、测试工具设计或选择、测试脚本设计、测试缺陷管理工具设计或选择，测试管理模板设计 测试用例设计是测试设计的重要内容，黑盒、白盒、灰盒测试用例设计 从软件的流程图、功能点、状态图
16、、use-case图等方面进行测试用例的设计 细化测试进度表,测试的实现与执行,测试的实现(Implementation) 从测试条件具体到可执行的测试用例（即从逻辑测试用例到实际的测试用例），以及必要的测试件（文档和工具） 借助于测试准则，确定测试期望结果 根据风险判定测试用例的优先级 生成测试数据 测试对象的输入值和状态值以及期望值，或在运行有关的测试用例后的期望结果 建立和检查测试环境，以确保配置的正确性 构建测试台(Test bed)和编写测试自动化脚本 组合成测试套件（Test suites）/测试序列（多个单个测试用例形成的逻辑集），并完成测试规程（Test procedure）
17、测试套件是用于被测组件/系统的一组测试用例。在这些测试用例中，一个测试用例的后置条件（Post condition）常作为下一个测试的前置条件（Precondition）,测试的实施与执行,测试的准备 测试环境的准备（软件、硬件、网络） 测试对象是否按照规定构建并准备完毕，测试程序、测试脚本是否准备完毕 缺陷管理系统和测试文档是否准备完毕 测试辅助件的准备：测试驱动器和测试桩、测试模拟器及测试工具等。,测试的实施与执行,测试的执行 测试某个软件组合或系统并产生实际结果的过程 按照测试计划和测试规约说明执行手动测试的测试用例和自动测试的测试用例 比较实际的和期望的结构，分析期望和实际结果偏差的原
18、因（测试对象和测试件的错误等） 提交事件（Incidents），即在测试过程中出现的，并且在此后还需要检查或者关注的事件 记录 测试结果（测试日期、时间、测试人员、输入的测试数据和期望值、测试对象的ID标识/版本号，测试工具和测试方法，测试结果和后续动作包括测试缺陷报告和修改测试用例），如果可能给出错误的原因，记录特殊情况。 如有必要，补充新的测试用例 执行确认测试和回归测试，用于确认错误更改是否有效，或者执行已经更改的测试用例 测试日志 即关于测试执行的按时间顺序的详细记录,测试退出的标准,测试退出的标准 计划中的测试用例是否执行完毕 是否达到功能、语句等计划的覆盖指标 继续测试发现缺陷的数
19、量减少低于度量标准等 满足测试计划中的测试退出标准 测试评估 对每个测试阶段都要进行评估是否达到测试退出的标准 对测试记录评估，判断测试是否达到了测试计划规定的测试退出准则 达到测试退出准则后，才进入下一个测试阶段 评价是否需要继续执行进一步的测试或者需要更改已经定义好的测试退出准则。例如，准则无法执行或者资源有限（费用、时间和人员）无法达到 每个测试阶段结束后提供对被测系统和测试过程当前状况的评价 给相关决策人员提交测试报告（包括测试活动和测试结果的文档，在规定的测试退出准则下的测试运行的评估）,测试结束活动,测试结束的条件 当一个软件产品正式上线应用后 当开发（或测试）达到一个里程碑（Mi
20、lestone) 一个维护版本结束时 测试结束活动的内容 检查是否所有计划的交付物都产生并交付了，或者产生交付了哪些 事件报告的完成（缺陷报告，偏差报告.） 为仍然存在的错误/偏差提供变更需求 系统验收的文档 测试结果分析，测试总结，测试信息和数据备份（测试规约说明书、数据、测试日志等） 对测试发现的缺陷进行统计分类并分析原因 制定的测试计划和实际的计划执行的差距并分析原因，哪些事件或风险没预料到，总结好的经验等 分析每个测试活动的计划和实施之间的偏差，并判断原因 统计测试结果与测试开销的关系 软件、硬件、文档和邮件的备份、销毁和退还,三、软件测试与软件生命周期,CSTQB软件测试基础级培训教
21、程,北京昱达环球科技有限公司 版权所有,,目录,软件开发模型软件测试级别软件测试类型维护性测试,软件开发模型,软件开发模型简介,软件生命周期 软件需求、分析、设计、实现、测试、部署Deploy/Release、维护和退出的过程，称为“软件生命周期”（Software Life Cycle） 概述 软件开发模型是指软件开发所依据的方式和过程 从事软件测试为什么要熟悉开发模型？ 测试不是孤立存在的，测试活动与开发活动是息息相关的 每个开发活动都有相对应的测试活动 不同的开发生命周期模型需要不同的测试方法 每个测试级别都有其特有的测试目标 对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分
22、析和设计 在开发生命周期中，测试人员在文档初稿阶段就应该参与文档的评审 如何选择开发模型？ 根据项目的内容 根据产品的特征,软件开发V模型图,V模型分析,概述 最早由Pual Rook于80年代末提出。 其左右分支形成了V字型，因此称作V模型。 含义 V 模型指出软件测试不仅仅是软件开发的一个独立阶段，而应贯穿于整个软件生命周期中 V 模型中的右分支列出的软件测试任务和相应的左分支列出的软件开发任务在整个软件项目中有着同等的重要性 该模型描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 V模型的缺点 仅仅把测
23、试过程作为在需求分析、系统功能设计、系统架构设计及编码之后的一个阶段 容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的系统测试和验收测试才被发现。 说明 在测试实践中，V模型中的各个开发及测试阶段可往往会根据具体情况有所增减甚至组合或重新排列,迭代-增量模型图,原型开发模型 快速开发模型 RUP（Rational Unified Process），统一软件开发过程 Agile Development敏捷开发,迭代-增量模型分析,在每次迭代过程中,对迭代产生的系统可能需要在不同的测试级别上进行测试。 通过将增量模块加入到以前开发
24、的模块中，形成一个逐渐增大的系统，这个系统同样需要进行测试。 在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。 验证和确认可以在每个增量模块中进行。,其它模型,X模型 提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序 前置测试模型 体现了开发与测试的结合，要求对每一个交付内容进行测试,软件测试级别,测试级别概述,软件开发的不同阶段对应不同级别(Level)的测试 组件测试（单元测试） 在软件编码结束后，对编写的每一个程序模块进行测试 集成测试（组装测试，联合测试 ） 在模块集成后，对集成在一起的模块组件，有时也可称为“部件”进行测
25、试 系统测试 将整个程序模块集成为软件系统安装在运行环境下，对于硬件、网络、操作系统及支撑平台构成的整体系统进行测试 验收测试（交付测试，确认测试） 在上述测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求,良好的测试所具有的特征,特征 每个开发活动都有相对应的测试活动 每个测试级别都有其特有的测试目标 对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计 在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审 注意： 根据项目的特征或系统的架构，可以对测试级别进行合并或重新进行组合。 比如，对于商业现货软件(COTS)产品集成到某个系统，购买者可以在系统级别（例
26、如：与基础设施集成、与其他系统的集成或与系统应用的集成）进行集成测试和验收测试（功能的和/或非功能的测试，用户和/或运行测试等）。,各个测试级别需要明确的内容,测试的总体目标 测试用例设计需要参考的工作产品（即测试的依据） 测试的对象（即测试什么） 发现的典型缺陷和失效 对测试用具的需求 测试工具的支持 专门的方法和职责等 注意： 如果某些数据属于系统的一部分，那么在测试计划时就应当考虑是否对系统配置数据进行测试。,组件测试概述,概述 组件测试是对软件基本组成单元进行的测试，一般在代码完成后由开发人员完成，测试人员辅助。 组件测试的目的是检查代码是否符合设计和规范。 测试依据 组件需求说明 详
27、细设计文档 代码 测试对象 组件 程序 数据转换/移植程序,组件测试的特征和测试内容,特征 组件测试可能包括功能测试和特定的非功能特征测试，比如资源行为测试（如内存泄漏）或健壮性测试和结构测试（比如分支覆盖）。 根据工作产品，例如组件规格说明、软件设计或数据模型等设计测试用例。 测试内容 模块接口测试 检查局部数据结构能否保持完整性 模块边界条件测试 模块执行路径测试 检查模块内部错误处理是否有效,组件测试的测试方法,测试框架和调试工具 通过开发环境的支持，比如组件测试框架或调试工具(debugging tool)，组件测试会深入到代码中，而且实际上设计代码的开发人员通常也会参与其中。 在这种
28、情况下，一旦发现缺陷，就可以立即进行修改，而不需要正式的缺陷管理过程。 测试优先的方法或测试驱动开发 在编写代码之前就完成编写和自动化测试用例 这是高度迭代的方法，并且取决于如下的循环周期： 测试用例的开发 构建和集成小块的代码 执行组件测试 修正任何问题并反复循环，直到它们全部通过测试。,集成测试概述,概述 通过单元测试的多个模块组合成更大的模块或子系统或产品，然后进行测试 集成测试是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。 测试依据 软件和系统设计文档 系统架构 工作流 用例 测试对象 子系统数据库实现 基础设施 接口,
29、集成测试的级别和内容,集成级别 集成测试，可以应用多种集成级别，也可以根据不同的测试对象规模采用不同的级别。 组件集成测试 对不同的软件组件之间的相互作用进行测试，一般在组件测试之后进行。 系统集成测试 对不同系统或软硬件之间的相互作用进行测试，一般在系统测试之后进行。 内容 各单元的接口是否吻合 代码是否符合规定的标准 界面标准是否统一等,系统测试概述,概述 将经过确认测试的软件，与计算机硬件、外设、支持软件等一起，在实际运行环境下测试。 系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。 目的 充分运行系统，验证系统各部件是否能正常工作，符合软件需求规格说明。 测试依据
30、系统和软件需求规格说明 用例 功能规格说明 风险分析报告 典型测试对象 系统、用户手册和操作手册 系统配置,系统测试类型与方法,类型 功能测试 非功能测试：压力测试/性能测试/容量测试 用户界面测试 兼容性测试 国际化测试 /本地化测试 测试方法 基于需求的测试 从需求导出测试目标和测试条件，设计测试用例，测试检查功能或者非功能特性（可靠性和可用性）。 基于业务流程的测试 从业务流程的说明和对业务流程的理解导出和选择测试用例的测试方法。 基于用例（Use Cases）的测试 黑盒测试设计方法，根据实际的场景设计测试用例，进行测试。 基于风险评估的测试 说明： 在系统测试中，测试环境应该尽量和最
31、终的目标或生产环境相一致，从而减少不能发现和环境相关的失效的风险。 系统测试通常由独立的测试团队执行,验收测试概述,概述 技术测试的最后一个阶段，在软件产品完成了系统测试之后、产品发布之前所进行的软件测试活动 验收测试通常是由使用系统的用户或客户来进行，同时系统的其他利益相关者也可能参与其中。 目的 验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心。 验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，保证系统或软件产品最终被用户接受 发现缺陷不是验收测试的主要目标。 测试依据 用户需求 系统需求 用例 业务流程 风险分析报告,验收测试的对象和内容
32、,对象 基于完全集成系统的业务流程 操作与维护流程 用户处理过程 结构 报告 内容 安装测试 功能测试 可靠性测试 安全性测试 性能测试 易用性测试 可移植性测试 可维护性测试 文档测试,验收测试的特点,验收测试不一定是最后级别的测试。 可能会在进行某个系统验收测试之后，进行大规模的系统集成测试。 验收测试可以在多个测试级别上进行 商业现货软件(COTS)产品可以在安装或集成时进行验收测试； 组件的可用性验收测试可以在组件测试中进行； 增加新功能的验收测试可以在系统测试之前进行。,验收测试的形式,形式（5种类型） 用户验收测试 操作验收测试 系统操作验收测试由系统管理员来进行，测试内容主要包括
33、： 系统备份/恢复测试； 灾难恢复测试； 用户管理测试； 维护任务测试； 数据加载和移植活动； 安全漏洞阶段性检查。 合同和法规性验收测试 合同验收测试根据合同中规定的生产客户定制软件的验收准则，对软件进行测试。应该在合同拟定时定义验收准则。 法规性验收测试根据必须要遵守的法律法规来进行测试，比如政府、法律和安全方面的法律法规。,验收测试的形式,Alpha testing （ 测试） 在软件产品正式商业销售之前，市场或商业现货软件开发人员希望从市场中潜在的或已经存在的客户中得到关于软件的反馈信息。 Alpha测试通常在开发组织现场进行，但测试并非由开发团队执行。 Beta testing（ 测
34、试） Beta测试或实地测试，是在客户或潜在客户现场进行并由他们执行。 概念辨析 Alpha testing （ 测试）：用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。 Beta testing（ 测试）：软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。,软件测试类型,测试类型概述,软件类型众多，不同的分类标准对应不同的测试类型 分类： 功能性测试 软件产品特性测试（非功能性测试） 软件结构性测试 变更相关的测试 确认/验证测试（再测试） 回归
35、测试 功能性测试和结构性测试可以应用于任何测试级别,功能性测试概述,概述 功能性测试是基于软件产品功能和特征，以及专门的系统之间的交互进行的测试 可以在各个测试级别进行，既可以用于组件级别、也可以用于集成和系统测试级别 功能性测试不考虑程序的具体执行路径，仅关注功能是否实现 功能测试的特点 通常采用黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试），是把测试对象看作一个黑盒子。 利用黑盒测试法进行动态测试时，只需要测试软件产品外部表现的功能，不需考虑软件产品的内部结构和处理过程。,功能性测试的错误类型,黑盒测试通常可以发现的错误类型 功能错误或遗漏； 界面错误； 数据
36、结构或外部数据库访问错误； 性能错误； 初始化和终止错误。 注意： 安全性测试就是功能测试的一种 对安全性相关的功能（比如防火墙）进行测试，从而检测系统和数据是否能抵御外部恶意的威胁，如病毒等。 互操作性测试是另一种功能性测试 评估软件产品与其他一个或多个组件或系统交互的能力。,非功能性测试,概述 为了测量系统和软件的运行特性，需要进行的测试。 可以在任何测试级别上进行。 基于产品的性能、负载、可用性、交互性、可维护性、可靠性及可移植性等方面的测试。 包括测试产品是否遵从指定的标准、规范和约束，以及操作界面的具体细节和构造上的限制。 通过测试，可以在不同尺度上来量化软件和系统的特征，比如进行性
37、能测试来检验系统和软件的反应时间。 类型 非功能测试包括但不限于：性能测试、负载测试、压力测试、易用性测试、可维护性测试、兼容性、可靠性测试和可移植性测试,结构测试概述,概述 结构测试也称白盒测试(White-box Testing，又称逻辑驱动测试)。 把测试对象看作一个打开的盒子。 利用白盒测试法进行动态测试时，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求工作，而不顾它的功能。 最好在进行基于规格说明的测试之后使用，以便通过评估结构类型的覆盖，测量测试的完整性。 覆盖 覆盖(coverage)是指通过测试套
38、件检验的结构程度，以覆盖项(item)的百分比来表示。 假如覆盖率不是100，可能需要设计更多的测试用例，来测试被遗漏的项，从而提高测试的覆盖。 白盒测试的主要方法 逻辑覆盖：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖 基本路径测试,结构性测试的特点,特点 可以在任何测试级别上进行结构测试。 在所有的测试级别，特别是在组件测试和组件集成测试中，可以利用工具来测量单元代码的覆盖，比如语句覆盖(statement coverage)和判定覆盖(decision coverage)。 结构测试可以基于系统的结构，比如调用层次结构。 结构测试方法也可以运用到系统、系统集成或验
39、收测试级别（比如业务模型或菜单结构）。 “白盒测试”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。 “白盒测试”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。,变更相关的测试概述,验证测试（再测试） 当发现和修改了一个软件缺陷后，需要重新进行测试以确定已经成功的修改了原来的缺陷。这种方法称之为确认测试。 回归测试（Regression Testing） 对已被测过的程序实体在修改缺陷后进行的重复测试，以此来检验在这些变更后是否有新的缺陷引入系统。 当软件发生变更或者使用软件的环境发生变化时，需要进行回归测试。 回归测试的范围可以根据
40、软件修改引起的风险程度来决定。 假如测试用例是用来进行确认测试和辅助回归测试的，则它们应该是可以重复进行执行。 回归测试可以在所有的测试级别上进行，同时适用于功能测试、非功能测试和基于结构的测试。 回归测试套件一般都会执行多次，而且没有什么变化和修改通常变化很少，因此回归测试强烈推荐自动化执行。 新功能测试,变更相关的测试,回归测试用例 能够测试软件的所有功能的代表性测试用例 专门针对可能会被修改影响的软件功能的附加测试 针对修改过的软件成分的测试 经验与提示 回归测试应当设计为只包括那些涉及在主要的软件功能中出现的一个或多个错误类的那些测试 各测试阶段发生的修改一定要在本测试阶段内完成回归，
41、以免将错误遗留到下一测试阶段。 回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中执行回归测试,各种测试级别与测试方法对比分析,不同测试类型之间的关系,软件测试,测试级别,运行软件,查看代码,测试类型,组件测试,集成测试,系统测试,验收测试,动态测试,静态测试,黑盒测试,白盒测试,功能性测试,非功能性测试,结构性测试,维护测试,变更相关 的测试,确认测试 （再测试）,回归测试,维护性测试,维护性测试概述,什么是维护性测试 软件发布之后,系统通常要运行数年甚至数十年, 在软件生命周期中的维护阶段，由于业务等方面的变化而进行修改、拓展、移植及部分软件被淘汰等原因所进行的测试称为维护
42、性测试。 维护测试是在一个运行的系统上进行，且一旦对软件或系统进行修改、移植或系统被淘汰时，就需要进行维护测试。 修改可以是计划中的功能增强（例如：根据版本发布的计划）、修正和应急变更、环境的变化，比如计划中的操作系统或数据库升级、为商业现货软件计划升级或由于新发现或暴露的操作系统漏洞而打的补丁等。 维护性测试可以理解为软件发布后的一种变更测试 维护性测试和可维护性测试的区别 维护性测试，由于维护开发,例如修改、拓展、移植及部分软件的退役等都只是基于原系统的改动,并未从根本上改变系统。 针对维护开发而进行的测试，完全可以遵从对原系统开发过程中测试的流程，如组件测试、集成测试、系统测试和验收测试
43、。 可维护性测试是仅针对系统是否易于维护而开展的测试。,维护性测试的特点,维护性测试的特点 维护测试根据变更情况的不同，可以在某一测试级别或所有测试级别和测试类型上进行。 维护测试的范围取决于变更后是否有产生新缺陷的风险、系统的规模和变更的大小。 维护测试通常始于客户对系统变化或发布下一个版本需求的确认。软件测试管理人员也会以这些确认文档为基础设计维护测试计划。 为移植（如从一个平台移植到另外一个平台）而进行的维护测试应该包括新环境的运行测试(operational testing)，以及对变更以后的软件的运行测试。 当数据从另一个应用程序移植到正在维护的系统时，需要移植测试（转换测试）。 为
44、系统退役而进行的维护测试应该包括数据移植测试，或当数据要长时间的保存时还须存档测试。 经验与提示 维护测试应该着重测试系统的变化和这些变化是否影响了原始系统的已有功能及性能。后者通常利用回归测试来实现。 除了对已变更的部分进行测试外，维护测试还包括对系统没有发生变更的其他部分进行大范围的回归测试。 确定变更如何影响现有系统的过程，称之为影响分析，它可以帮助决定实施回归测试的广度和深度。 如果规格说明遗失、过时或测试人员没有具备领域知识，进行维护测试将是一件困难的事情。,静态测试与动态测试,静态测试（Static Testing）简介 不实际运行被测试软件，只是静态地检查程序代码、界面或文档中可
45、能存在的缺陷的过程。 对于代码测试，测试代码是否符合相应的规范和标准 对于界面测试，测试程序的实际界面和需求规格说明（规约）是否一致 对于文档测试，测试用户手册和联机帮助是否满足客户的实际需求 静态测试中检查代码规范的工具 某些白盒测试工具包括检查代码规范的功能 Telelogic的LogiScope可以检查C/C+，Java的编码是否规范 Parasoft的C+ Test可以检查C/C+的编码规范性,动态测试,动态测试(Dynamic Testing)简介 实际运行被测试软件，输入相应的测试数据，检查实际输出结果和预期结果是否符合的过程。 动态测试、静态测试、黑盒测试与白盒测试之间的关系 黑
46、盒测试有可能是动态测试，也可能是静态测试（不运行程序，只查看界面） 白盒测试有可能是动态测试，也可能是静态测试 动态测试有可能是黑盒测试，也可能是白盒测试（运行程序，并分析代码结构） 静态测试有可能是黑盒测试（不运行程序，只查看界面），也可能是白盒测试 这些测试类型只是分类角度不同，同一个测试，既有可能属于黑盒测试，也有可能属于动态测试；既有可能属于静态测试，也有可能属于白盒测试,静态测试与动态测试的比较,静态测试和动态测试的区别：是否执行被测试软件 动态测试和静态测试这两种手段都可以提供信息来改进被测试软件系统的质量，以及改善开发和测试的过程。,功过手工检查（评审）或自动化分析（静态分析）的
47、方式对文档进行检查直接发现缺陷（引起失效的原因）发现的缺陷类型：与标准之间的偏差、需求内的错误、设计的错误、接口规格说明错误等,通过执行被测软件对软件进行检查发现失效（缺陷的外部表现）发现的缺陷类型：软件运行过程中与规格说明、用户需求之间的偏差,静态测试,动态测试,随机测试,Ad Hoc Testing，又称“基于经验的测试”，根据被测试软件特点和以往实践经验，对容易产生缺陷的部分进行测试 是基于测试用例测试的补充，可以发现测试用例不能发现的缺陷 在基于测试用例的测试执行完后，需要安排随机测试 提高测试覆盖率，提高测试的有效性 具有测试经验或者对被测试产品熟练的测试人员进行,四、软件静态测试技
48、术,CSTQB软件测试基础级培训教程,北京昱达环球科技有限公司 版权所有,,目录,静态测试技术概述评审技术概述走查技术评审静态测试工具,静态测试技术概述,概述 静态测试技术通过手工检查（评审）或自动化分析（静态分析）的方式对代码或者其他的项目文档进行检查而不需要执行代码。 静态测试分为评审和静态分析两种形式 评审 评审是对软件工作产品（包括代码）进行测试的一种方式，可以在动态测试执行之前进行。 在生命周期早期的评审过程中发现并修改缺陷（例如发现需求中的缺陷）的成本会比在动态测试中才发现并修改这些缺陷的成本低的多。 评审可以完全以人工的方式进行，也可以通过工具的支持来进行。人工进行评审的主要活动
49、是检查工作产品，并对工作产品做出评估。 特点 相对于动态测试而言，静态测试成本更低，效率较高 可以在软件开发生命周期早期发现缺陷 静态测试是一种非常有效的测试技术,静态测试技术的工作产品和关系,工作产品 需求规格说明 设计规格说明 代码 测试计划(test plan) 测试规格说明(test specification) 测试用例 测试脚本 用户指南 WEB页面等 评审、静态分析和动态测试之间的关系 评审、静态分析和动态测试具有共同的目标：识别缺陷。 它们之间是互补的：不同的技术可以有效和高效地发现不同类型的缺陷。 与动态测试相比，静态技术发现的是软件失效的原因而不是失效本身。,静态测试分类小
50、结,静态测试技术,评审,工具支持的静态测试（静态分析）,非正式评审,正式评审,走查,技术评审,审查,评审技术概述,概述 通过一个过程或一个会议，向项目相关人员、管理人员、用户、客户及其相关人员陈述一件软件产品，并征求大家的评论或认可。 其他开发人员对被评审开发人员的工作产品（程序代码、文档），按照事先定义的规程进行的评估和审查 评审的目的在于发现工作产品的缺陷和需要改进之处 评审的好处 尽早发现和修改缺陷、改善开发能力、缩短开发时间、缩减测试成本和时间、减少产品生命周期成本、减少缺陷以及改善沟通等。 评审也可以在工作产品中发现一些遗漏的内容，例如发现需求有遗漏，而这在动态测试中是很难被发现的。 评审发现的典型缺陷 与标准之间的偏差 需求内的错误 设计错误 可维护性不足 错误的接口规格说明等等。,
