《cstqb测试课件》由会员分享，可在线阅读，更多相关《cstqb测试课件（300页珍藏版）》请在金锄头文库上搜索。
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道单选选择题（给定的答案中只有一项是正确的）
3、考试时间为1小时 分数达到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） 测试套件是用于被测组件/系统的一组测试用例。在这些测试用例中，一个测试用例的后置条件（Post condition）常作为下一个测试的前置条件（Precondition）,测试的实施与执行,测试的准备 测试环境的准备（软件、
