搜索
ISTQB基础知识ISTQBCTFL简介ISTQB与CSTQB简介ISTQB简介国际软件测试认证委员会ISTQB(InternationalSoftwareTestingQualificationBoard)于2002年在英国成立。ISTQB是国际唯一权威的软件测试资质认证机构，现有包括美国、德国、英国、法国、日本等47个成员国。中国软件测试认证委员会(CSTQB)在2006年成为ISTQB的正式成员。ISTQB培训与认证体系ISTQB-CertifiedTester培训及认证体系分为三个级别：基础级/FoundationLevel高级/AdvancedLevel：3年以上测试工作经验专家级/ExpertLevel：5年以上测试工作经验培训者获得基础级证书后，可申请参加更高级别的培训和认证考试，并获得相应证书。CSTQBFL培训内容课程模块模块内容第一部分：测试的基础知识测试的基本原则基本的测试过程测试的理念第二部分：软件生命周期中的测试软件开发模型测试级别测试类型维护测试第三部分：静态技术评审的测试过程工具支持的静态分析第四部分：测试设计技术黑盒技术白盒技术基于经验的技术第五部分：测试管理测试的组织结构测试计划的估算测试进度监控配置管理风险和测试第六部分：测试的工具支持测试工具的类型高效率使用工具组织中工具的引入ISTQBCTFL认证考试考试形式闭卷笔试考试卷包含40道单选选择题（给定的答案中只有一项是正确的）考试时间为1小时分数达到65%以上（26题以上含26题）通过考试考试内容与比例章节名称题目数量级别数量百分比K1K2K3测试的基础知识743018%软件生命周期中的测试642016%静态技术32107%测试设计技术1242629%测试管理833221%测试的工具43109%软件测试基础目录为什么需要软件测试什么是测试软件测试的目的与原则软件测试过程软件测试术语（1）术语错误Error，Mistake缺陷Defect，Bug，Fault失效Failure说明程序员可能会犯错误，由此在程序或文档中产生缺陷。如果执行了代码中的缺陷，软件将可能无法实现应该实现的功能或者产生了不应该实现的结果，由此产生失效。软件、系统或者文档中的缺陷可能导致失效，但是并不是所有的缺陷都会导致失效。缺陷的产生是因为程序员容易犯错误，可能是因为时间压力，复杂的代码，架构复杂，技术变更，或者系统交互等引起的。失效也可能是环境条件引起的。例如，辐射，磁场，电场，污染导致硬件故障。或者由于改变了硬件的条件，对软件的执行产生影响。软件系统的失效不可能是老化或磨损引起的。软件测试术语（2）错误error是广义的概念。错误是人为的原因导致一个不正确的结果。它可以是程序内的内部错误，也可能是文档内的错误。缺陷是错误的具体表现，可以是不正确的文档，程序段，指令或数据定义，它们可能会引起一个外部的失效(failure)。bug，defect和fault同义。因为存在的缺陷(defect)而导致软件的运行失败叫失效。失效是缺陷在执行测试软件时的外部反映。失效是（规范说明）期望的值与实际（观察到）的值存在偏差。例如系统的不正确的反应，崩溃，死机等。当缺陷引起了运行错误或对用户产生了消极影响时，它就被称为失效。对缺陷最大的担心就是它会转变为失效，而失效将会对用户产生损害。有一些缺陷可能永远也不会转变为失效，但有时一个缺陷又可能会引起上百万的失效。缺陷可以通过静态测试发现,而失效只能通过动态测试发现。什么是测试？测试包含：测试执行之前和之后的一些活动，包括计划与控制、选择测试条件、设计与执行测试用例，检查测试结果、评估出口准则、报告测试过程及被测系统、在一个测试阶段完成后要进行测试结束和总结工作。测试同时也包括文档的评审（包括源代码）和执行静态分析。测试分为动态分析和静态分析两种手段软件测试的总体目标总体目标发现缺陷获取对产品质量的信心提供用于决策的信息预防缺陷早期测试开发阶段的测试运行阶段的测试静态测试组件测试集成测试系统测试验收测试非功能测试维护测试预防缺陷发现缺陷建立信心提供信息不同测试阶段的测试目的软件需求阶段对文档的静态测试是为了预防缺陷在开发阶段执行的测试（组件测试、集成测试和系统测试），测试的主要目的可能是尽可能的使软件失效，从而发现和修改尽可能多缺陷。在验收测试中，主要目的可能是用来确认系统是否按照预期工作的，从而在系统是否满足系统需求方面得到信心。在有的情况，测试的主要目的可能是对软件的质量进行评估（不是为了修改缺陷），从而为利益相关人提供这样的信息：在给定时间内发布系统版本是否存在风险？在运行测试阶段，测试的主要目标可能是为了评估系统的特征，比如可靠性或可用性等。维护测试通常是为了验证在变更开发过程中是否有新的错误引入。测试和调试的区别调试（Debug）和测试（Test）是两个不同的概念。测试测试可以发现由于软件缺陷引起的失效。测试员执行测试。调试调试是一种开发活动，用来识别引起缺陷的原因，修改代码以及验证是否正确的修改了软件的缺陷。开发人员执行调试。关系开发人员调试后的软件需要测试员进行确认测试，确认修改的代码已经解决了失效问题。开发人员除了调试，也执行某些类型的测试软件测试的原则1.所有的软件测试都应追溯到用户需求2.应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭3.完全测试是不可能的，测试需要适可而止4.测试只能证明软件存在错误而不能证明软件没有错误5.充分注意测试中的缺陷群集现象6.程序员应避免检查自己的程序（测试独立性）7.测试的“杀虫剂”效应所有的软件测试都应追溯到用户需求从根本上讲，判断软件现象是否是缺陷的依据是是否满足用户需求显性需求隐性需求软件的目的是使用户完成预定的任务，并满足用户的需求软件测试所揭示的缺陷和错误使软件达不到用户的目标，满足不了用户需求尽早地和不断地进行软件测试在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义的测试目标(testobjective)上早期发现和修改缺陷成本最小每个软件Build都应该被测试，而不是等到最后一个Build才进行测试经验数据示例穷尽测试是不可能的测试是有计划的，产品要发布，市场不允许无限期测试被测试软件复杂，需要测试的内容很多测试预算和资源有限，测试需要适可而止除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不现实的。通过运用风险管理(Riskmanagement)和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试测试显示缺陷的存在测试只能表明软件存在缺陷，不能说明软件不存在缺陷测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的由于软件测试不能穷尽测试，因此，经过测试的软件仍然含有未知的缺陷缺陷的群集现象版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个程序模块。测试的独立性人为心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作由于思维定势，人们难于发现自己的错误程序员应该避免全部测试自己的程序和文档为达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试测试的“杀虫剂”效应同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺陷为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷重复测试、不间断测试、更新测试内容和测试用例软件测试的基本过程软件测试计划和控制测试分析和设计测试实施和执行退出测试的标准测试报告测试结束活动开始结束测试计划跟踪控制分析与设计实现与执行评估与报告完成测试测试计划测试进度表测试设计规格说明测试用例规格说明测试规程规格说明测试日志/事件报告...测试总结报告软件测试计划和控制定义《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”作用借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。内容指明测试范围、方法、资源，以及相应测试活动的时间进度安排表。包含测试目标、项目概述、组织形式、角色及职责、测试对象、测试通过和失败的标准（测试何时结束、度量的尺度如何、度量的评价标准等）、测试挂起的标准及恢复的必要条件、测试任务的安排、应交付的测试工作产品、工作量估计等。特点一般开始于软件需求分析结束阶段软件测试计划内容与实例计划内容测试项目概述需要测试的功能不需要测试的功能测试策略测试中断与恢复的规定测试完成后需要提交的内容测试环境的设置测试人员的工作分配测试人员的能力与培训测试进度表测试风险计划实例简单的测试计划复杂测试计划附录A：测试计划模板软件测试控制利用事先定义的度量评估和分析测试结果监督和记录：测试进度测试的覆盖状况测试的结束条件是否偏离计划确定是否需要采取纠正措施确定是否需要更改原计划对测试计划的执行进行反馈软件测试分析和设计不同阶段的分析和设计依据不同在组件（单元）测试阶段分析的依据是详细设计规约在集成测试阶段分析的依据是概要设计规约在系统测试阶段分析的依据是需求分析规约在分析过程中规约不是惟一的依据，由于软件开发过程中的文档可能不是十分的完整，这就要求测试分析人员从其他方面进行分析作为补充。软件测试分析和设计对测试依据（需求、结构、设计、接口）进行评审/分析，为对所有测试点设计测试用例做好准备以测试分析为基础并结合软件测试方法和技术进行测试设计从产品原型分析角度出发，与当事人交流和沟通（开发者和用户等）对需求和测试对象的可测试性进行评价在分析测试对象、规约说明、测试对象间的关系和结构的基础上，确定测试条件（例如验证需求）以及所需的测试数据使用测试策略内规定的测试方法设计逻辑测试用例（测试用例的架构）测试用例的设计应该从逻辑测试用例到实际测试用例的设计过程，设计用例的多少应该充分考虑测试子系统或模块在整个系统中的重要性，用例的设计同时要考虑用例执行应该具备的前提条件设计测试环境，包括必要的基本设施和工具测试设计包括测试用例设计、测试工具设计或选择、测试脚本设计、测试缺陷管理工具设计或选择，测试管理模板设计测试用例设计是测试设计的重要内容，黑盒、白盒、灰盒测试用例设计从软件的流程图、功能点、状态图、use-case图等方面进行测试用例的设计细化测试进度表测试的实现与执行测试的实现(Implementation)从测试条件具体到可执行的测试用例（即从逻辑测试用例到实际的测试用例），以及必要的测试件（文档和工具）借助于测试准则，确定测试期望结果根据风险判定测试用例的优先级生成测试数据测试对象的输入值和状态值以及期望值，或在运行有关的测试用例后的期望结果建立和检查测试环境，以确保配置的正确性构建测试台(Testbed)和编写测试自动化脚本组合成测试套件（Testsuites）/测试序列（多个单个测试用例形成的逻辑集），并完成测试规程（Testprocedure）测试套件是用于被测组件/系统的一组测试用例。在这些测试用例中，一个测试用例的后置条件（Postcondition）常作为下一个测试的前置条件（Precondition）测试的实施与执行测试的准备测试环境的准备（软件、硬件、网