ISTQB学习笔记

学习ISTQB大纲
此文记录初次阅读时不够明确的地方

第一章：软件测试基础
1. 引起软件缺陷的原因
人都会犯错误（error,mistake），因此人设计的代码或文档中会引入缺陷（defect, fault, bug）；当存在缺陷的代码被执行时，系统可能无法实现期望功能或实现了未期望的功能，引起软件失效（failure）。

产生缺陷的原因：人们本身容易犯错误、时间压力、复杂的代码、复杂的系统架构、技术的革新、以及/或者许多系统之间的交互等。
失效也可能是由环境条件引起的：如：辐射、电磁场和污染等都有可能引起固件中的故障，或者由于硬件环境的改变而影响软件的执行。

2. 进行软件测试的原因：
可以减少软件系统在运行环境中的风险，
提高软件的质量，
为了满足合同或法律法规的要求，
为了满足行业标准的要求。

3. 软件质量特性：
功能、可靠性、可用性、可移植性、可维护性、效率

4. 测试和质量
通过测试发现的缺陷评估质量；
测试发现缺陷很少或没有，测试可以帮助树立对质量的信心；
合理的测试顺利通过，可降低系统存在的风险；
修改了缺陷则提升了质量；
分析缺陷及其原因可改进软件开放过程，反过来可提升以后产品质量。

测试是质量保证工作不可或缺的一部分。

5. 质量保证包括：
开发标准、培训和缺陷分析

6. 测试活动包括：
计划和控制，
选择测试条件、设计和执行测试用例，
检查测试结果，
评估出口准则，
报告测试过程及被测系统，
在一个测试阶段完成后要进行测试结束和总结工作，
同时也包括文档/代码的评审、执行静态分析。

7. 测试的目标：
发现缺陷，
增加对质量的信心，
为决策提供信息，
预防缺陷。

8. 不同的测试阶段考虑不同的测试目标：
软件生命周期早起的测试设计的思维过程和活动：可以避免将缺陷引入代码；
对文档的评审，并识别和解决问题：有助于防止代码中出现缺陷；
开发测试（组件测试、集成测试和系统测试）：尽可能多的发现失效，从而识别和修正尽可能多的缺陷；
验收测试：确认系统是否按照预期工作，建立满足了需求的信心；
维护测试：验证开发过程中的变更是否引入新的缺陷；
运行测试：评估系统的特征，如可靠性或可用性等。

9.杀虫剂悖论
采用同样的测试用例多次重复进行测试，最后将不在能够发现新的缺陷。为了克服杀虫剂悖论，测试用例需要进行定期评审和修改，同时需要不断增加新的不同的测试用例来测试系统的不同部分，从而发现潜在的更多的缺陷。

10. 测试的7个原则：
测试显示存在缺陷（但不能证明系统不存在缺陷）；
穷尽测试是不可行的；
测试尽早介入；
缺陷集群性；
杀虫剂悖论；
测试活动依赖于测试背景（如对安全关键的软件进行测试，跟对一般软件的测试是不一样的）；
不存在缺陷（就是有用系统）的谬论（如果系统无法使用，或不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的）。

11. 基本的测试过程：
测试计划和控制；
测试分析和设计；
测试实现和执行；
评估出口准则和报告；
测试结束活动。
以上活动逻辑上连续，但实际可能会重叠或同时进行；可适当剪裁。

12. 测试计划的主要活动是：
识别测试任务，
定义测试目标，
为了实现目标和任务确定必要的测试活动。

13. 测试控制是持续进行的活动（整个生命周期）：
报告测试的状态，包括与计划的偏差；
采取必要措施以满足测试任务和目标。

14. 测试分析和设计阶段的主要任务：
评审测试依据（如需求、软件完整性级别（风险等级）、风险分析报告、系统架构、设计和接口说明）；
评估测试依据和测试对象的可测性；
通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定其优先级；
设计测试用例并确定优先级；
确定测试条件和测试用例所需要的测试数据；
规划测试环境的搭建和确定测试需要的基础设施和工具；
创建测试依据和测试用例间的双向可追踪性。

15. 测试实现和执行阶段的任务：
通过特定的顺序组织测试用例来完成测试规程和脚本的设计，并且包括测试执行所需的其他任何信息，以及测试环境的搭建和运行测试。

16. 评估出口准则和报告
主要任务：
按照测试计划中定义的测试出口准则检查测试日志；
评估是否需要进行更多的测试，或是否需要更改测试的出口准则；
为利益相关者提供一个测试总结报告。

17. 测试结束活动
进行测试结束活动的情况：
软件系统正式发布、
一个测试项目完成（或取消）、
达到一个里程碑或一个维护版本完成。

18. 测试结束活动的主要任务：
检查提交了哪些计划的可交付产品；
事件报告是否关闭、或对未关闭的时间报告提交变更需求；
记录系统的验收；
记录和归档测试件、测试环境和测试基础设备，以便以后的重复使用；
移交测试件到维护部门；
分析和记录所获得的经验教训，用于以后的项目和测试成熟度改进；
使用为测试成熟度的提高所收集的信息。

19. 从低到高定义不同级别的测试独立：
测试由软件本身的编写人员来执行；
测试由一个其他开发人员来执行（可能来自同一个开发小组）；
测试由组织内的一个或多个其他小组成员（如独立的测试小组）或测试专家（如可用性和测试专家）来执行；
测试由来自其他组织或其他公司的成员来执行（如测试外包或其他外部组织的鉴定）。

20. 发现失效需要测试员具有：
好奇心，
专业的怀疑态度，
一双挑剔的眼睛，
对细节的关注，
与开发人员良好的沟通能力，
对常见的错误进行判断的经验。

21. 职业道德：
公共：测试工程师应当以公众利益为目标；
客户和雇主：在保持与公正利益一致的情况下，应注意满足客户和雇主的最高利益；
产品：产品发布版本符合最高的专业标准；
判断：维护职业判断的完整性和独立性；
管理：对软件测试合乎道德规范的管理；
专业：推进其专业的完整性和声誉；
同事：对同事持平等、互助、支持的态度，促进与开发人员的合作；
自我：参与终生职业实践的学习，并促进合乎道德的职业实践方法。

第二章：软件生命周期中的测试
1. 软件开发模型：
V模型（顺序开发模型）；
迭代-增量开发模型：原型开发、快速应用开发、统一软件开发过程、敏捷开发模型等；

2. 每个测试级别都需要明确的内容：
测试的总体目标，
测试用例设置需要参考的产品（即测试的依据），
测试的对象，
发现的典型缺陷和失效，
对测试用具的需要，
测试工具的支持，
专门的方法和职责等。

3. 组件测试/单元测试
依据：组件需求说明、详细设计文档、代码。
典型测试对象：组件、程序、数据转换/移植程序、数据库模型。

桩、驱动器和模拟器：底层打桩，中间驱动，上层行为模拟

可能包括：功能测试、特定的非功能特征测试，如资源行为测试（如内存泄漏）、健壮性测试和结构测试（如分支覆盖）

4. 集成测试
依据：软件和系统设计文档、系统架构、工作流、用例；
典型测试对象：子系统、数据库实现、基础结构、接口、系统配置和配置数据。

5. 集成级别不同：
组件集成测试对不同的软件组织之间的相互作用进行测试，一般在组件测试之后进行；
系统集成测试对不同系统或软硬件之间的相互作用进行测试，一般在系统测试之后进行。

6. 系统测试：
依据：系统和软件需求规格说明、用例、功能规格说明、风险分析报告；
典型测试对象：系统、用户手册和操作手册，系统配置和配置数据。

通常由独立的团队进行。

7. 验收测试
依据：用户需求、系统需求、用例、业务流程、风险分析报告；
典型测试对象：基于完全集成系统的业务流程、操作与维护流程、用户处理过程、结构、报告、配置数据。

通常由使用系统的用户或客户来进行。

8. 验收测试的典型类型：
用户验收测试：由商业用户验证系统可用性；
操作（验收）测试：由系统管理员来进行，包括：系统备份/恢复测试、灾难恢复测试、用户管理测试、维护任务测试、数据加载和移植活动、安全漏洞阶段性检查；
合同和法规性验收测试：根据合同规定、根据必须遵守的法律法规进行测试；
Alpha和Beta测试：
    alpha测试在开发组织现场进行，但由潜在用户测试；
    beta测试或实地测试，在客户现场又客户执行；
    也可称为工厂验收测试和现场验收测试。
    
9. 从测试的级别划分：
组件测试/单元测试、
集成测试、
系统测试、
验收测试

10. 根据特定的目标或测试原因：
功能测试：主要考虑软件的外部表现行为（黑盒）；可以包括：
    安全性测试：系统和数据是否能抵御外部恶意威胁；
    互操作性测试：与其他组件或系统交互能力的测试；
非功能测试：测试系统运行的表现如何；
    包括但不限于：
    性能测试
    负载测试
    压力测试
    可用性测试
    可维护性测试
    可靠性测试
    可移植性测试

11. 软件结构/架构测试（结构测试）：可以在任何测试级别使用；最好在进行基于规格说明测试之后使用，以便通过评估结构类型的覆盖来测量测试的完整性；

12. 确认：
当发现和修改了一个缺陷后，应进行再测试以确定已经成功的修改了原来的缺陷，称之为确认。

13. 维护测试
在现有的运行系统上进行，且一旦对软件或系统进行修改（功能增加、修正和应急变更、环境的变化（如升级、漏洞））、移植（平台迁移）或退役处理（数据移植、存档测试）时，就需要进行维护测试。
维护测试的范围取决于变更的风险、现有系统的规模和变更的大小。

第三章 静态技术
1. 静态测试技术：
通过手工检查（评审）或自动化分析（静态分析）的方式对代码或者其他的项目文档进行检查而不需要执行代码。

2. 评审：
更容易发现：与标准之间的偏差、需求内的错误（需求遗漏）、设计错误、可维护性不足和错误的接口规格说明等等。

3. 评审过程：
评审过程的正式性和以下因素有关：开发过程的成熟度、法律法规方面的要求或审核跟踪的需要。
评审的目标：发现缺陷、增加理解、培训测试员和团队新成员或对讨论和决定达成共识等。

4. 正式评审的阶段：
1）计划阶段：
定义评审标准，
选择人员，
分配角色，
为更加正式的评审类型（比如审查）制定入口和出口准则，
选择需要进行评审的文档内容，
核对入口准则（针对更正式的评审类型）。
2）预备会阶段：
分发文档，
向评审参与者解释评审的目标、过程和文档。
3）个人准备阶段：
先行评审文档，为评审会议做准备；
标注可能的缺陷、问题和建议。
4）检查/评价/记录结果（评审会议阶段）：
讨论和记录，并留下文档化的结果或会议纪要（针对更正式的评审类型）；
标注缺陷、提出处理缺陷的建议、对缺陷做出决策；
在任何形式的会议期间或跟踪任何类型的电子通信期间检查/评价和记录问题。
5）返工阶段：
修改发现的缺陷（通常由作者进行）；
记录缺陷跟踪的状态（在正式评审中）；
6）跟踪结果阶段：
检查缺陷是否已得到解决；
收集度量数据；
核对出口准则（针对更正式的评审类型）。

5. 角色和职责
经理（管理者）；
主持人；
作者；
评审员；
记录员。

从不同的角度评审软件和其相关工作产品并使用检查表可以提高评审的效果和效率。

6. 评审类型：
非正式评审；informal review；
走查；walkthrough；
技术评审；technical review;
审查；inspection；通常是同行检查：peer review；

7. 静态分析的工具支持
静态分析通常发现的是缺陷而不是失效，静态分析工具分析程序代码（控制流和数据流），以及产生如HTML和XML的输出。

8. 通过静态分析发现的典型缺陷如下：
引用一个没有定义值的变量；
模块和组件之间接口不一致；
从未使用的变量；
不可达代码或死代码；
逻辑上的遗漏与错误（潜在的无限循环）；
过于复杂的结构；
违背编程规则；
安全漏洞；
代码和软件模型的语法错误。

第四章 测试设计技术
1. 测试用例由：
一组输入值、
执行的前置条件、
预期结果、
执行的后置条件

测试条件：
能通过一个或多个测试用例进行验证的一个条目或事件（比如功能、事务处理、质量特征或结构元素等）

2. 测试规格说明书
包含：测试用例的开发、实现、确定优先级和组织（执行的顺序，如果是自动化用例，应该体现在测试脚本中）

3. 黑盒测试技术：
基于规格说明的方法，
特点：
使用正式或非正式的模型来描述需要解决的问题、软件或其组件等；
根据这些模型，可以系统地导出测试用例。

4. 白盒测试技术：
基于结构的方法，
特点：
根据软件的结构信息设计测试用例，比如软件代码和详细设计信息；
可以通过已有的测试用例测量软件的测试覆盖率，并通过系统化的导出设计用例来提高覆盖率。

5. 基于经验的方法：
特点：
用例根据参与人员的经验和知识来编写；
测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和环境等方面所掌握的知识作为信息来源之一；
对可能存在的缺陷及其分布情况的了解作为另一个信息来源。

6. 等价类技术：
输入覆盖和输出覆盖

7. 边界值分析：
输入、时间段的范围、表的边界等

8. 决策表测试：
识别系统的条件和动作；
优点：生成测试条件的各种组合。
适用于：软件的行为由一些逻辑决策所决定的情况。

9. 状态转换：
通过状态转换图来表示系统的特征。
设计的测试可以覆盖：一个典型的状态序列，或覆盖每个状态，或执行每个状态转换，或执行特定顺序的状态转换或测试无效的状态转换。
适用于：嵌入式和自动化行业，和有特定状态的业务对象的建模或测试对话框状态转换流的系统。

10. 用例测试（Use Case）
用例基于系统最可能使用的情况描述了过程流；
有助于设计用户/客户参与的验收测试。

11. 基于结构的或白盒技术（structure-based testing）
代码覆盖：code coverage
判定覆盖：decision coverage
语句覆盖：statement coverage

12. 基于结构的测试/白盒测试是根据识别软件或系统的结构：
组件级别：软件组件的结构，比如：语句、判定、分支或每个不同的路径；
集成级别：结构可能是调用树（模块调用关系图）；
系统级别：结构可能是菜单结构、业务过程或web页面结构。

13. 语句覆盖和覆盖率：
评价一个测试用例套件中已经执行的可执行语句的百分比；

14. 判定覆盖和覆盖率：
评价在一个测试用例套中已经执行的判定输出的百分比。

15. 其他的基于结构的技术：
程度更高的基于结构的覆盖：条件覆盖和多重条件覆盖；
覆盖的概念可以应用于其他的测试级别：在一个测试用例套件中被执行的模块、组件或类覆盖的百分比可以分别称为：模块覆盖、组件覆盖或类的覆盖。

16. 基于经验的技术
错误推测法：
    缺陷攻击：列举可能的错误，并设计测试来攻击这些错误；
探索性测试：指依据包含测试目标的测试章程来同时进行测试设计、测试执行、测试记录和学习，并且在规定时间内进行。

17. 选择测试技术
测试技术的选择基于：系统类型、法律法规标准、客户或合同的需求、风险的级别、风险的类型、测试目标、文档的可用性、测试员的技能水平、时间和成本预算、开发生命周期、用例模型和以前发现各类缺陷的经验等。

测试技术可能运用于特定的环境和测试级别，有些可能适用于所有级别。

第五章：测试管理
1. 测试计划受到以下因素影响:
组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。

2. 测试计划是持续性活动，需要在整个生命周期过程和活动中进行。从测试得到的反馈信息可以识别变化的风险，从而对计划做出调整。

3. 入口准则：
测试环境已经准备就绪并可用；
测试工具在测试环境中已经准备就绪；
可测的代码可用；
测试数据可用。

4. 出口准则：
完整性测量：比如代码、功能或风险的覆盖率；
对缺陷密度或可靠性度量的估算；
成本；
遗留风险：如没有被修改的缺陷或在某些部分测试覆盖不足；
进度表：如基于交付到市场的时间。

5. 测试估算
基于度量的方法：根据以前或相似项目的度量值或典型的数据进行估算；
基于专家的方法：由任务责任人或专家进行工作量估算。

6. 测试的工作量取决于多种因素：
产品的特点：规格说明或用于测试模型的其他信息（测试依据）的质量、产品的规模、问题域的复杂度、可靠性和安全性的需求和文档的需求；
开发过程的特点：组织的稳定性、使用的工具、测试过程、参与者的技能水平和时间紧迫程度等；
测试的输出：缺陷的数量和需要返工的工作量。

7. 测试方法的选择取决于：
风险、危害和安全、可用资源和人员技能、技术、系统类型、测试对象和相关法规。

8. 典型的测试方法：
分析的方法：如风险测试；
基于模型的方法：如随机测试利用失效率（如可靠性增长模型）或使用率（允许情况）的统计信息；
系统的方法：如基于失效的方法（错误推测和故障攻击），基于检查表的方法和基于质量特征的方法；
基于与过程或符合标准的方法：如行业标准规定的方法或各类敏捷的方法；
动态的启发式的方法：类似探索性测试；
咨询式的方法：如测试覆盖率主要根据小组以外的业务领域和/或技术领域专家的建议和指导来推动的；
可重用的方法：如重用已有的测试材料、广泛的功能回归测试自动化、标准测试套件等。

9. 测试过程的监控
提供测试活动的反馈信息：
测试用例准备工作完成的百分比；
测试环境准备工作完成的百分比；
测试用例执行情况：执行/未执行的测试用例数、通过/失败的测试用例数；
缺陷信息：如缺陷密度、发现并修改的缺陷、失效率、回归结果；
需求、风险或代码的测试覆盖率；
测试员对产品的主观信心；
测试里程碑的日期；
测试成本，包括寻找下一个缺陷或执行下一轮测试所需成本与收益的比较。

10. 测试报告：
内容：
测试周期内发生了什么？比如：达到出口准则的日期；
通过分析和度量为下一步活动提供建议或做出决策：如：对遗留缺陷的评估、是否继续测试的经济效益、未解决的风险以及被测试软件的置信度等。

11. 在测试级别的过程中和完成时度量信息用来评估：
该测试级别的测试目标实现的充分性；
采用的测试方法的适当性；
针对测试目标的测试的有效性。

12. 测试控制措施：
如：
基于监控信息来做出决策；
如果一个已识别的风险发生，重新确定测试优先级；
根据测试环境可用性，改变测试的时间进度表；
设定入口准则：如规定缺陷修复后需开放在测试后才能发布新版本。

13. 配置管理可以确保：
测试件的所有相关项都已经被识别，版本受控，相互之间有关联以及和开发项（被测对象）之间有关联的变更可跟踪；
在测试文档中，所有被标识的文档和软件能被清晰明确的引用。

14. 风险级别
风险级别取决于发生不确定事件的可能性和产生的影响。

15. 项目风险
围绕项目按目标交付的能力的一系列风险。如：
组织因素：技能、培训和人员的不足；个人问题；政策因素等；
技术因素：需求定义错误、环境没有准备好、工具造成的延迟、低质量的设计、编码、配置、测试等；
供应商因素：第三方、合同问题等。

16. 产品风险
在软件或系统中的潜在失效部分（即将来可能发生不利事件或危险），对产品质量的风险。如：
故障频发、没有实现既定的功能、劣质的软件特性等。

17. 事件管理
实际结果和预期结果之间的差异需要作为一个事件被记录，必须进行调查以确定是否是缺陷。

第六章：软件测试工具
1. 测试工具的类型
配置管理工具configuration management tool
覆盖率工具coverage tool
调试工具debugging tool
动态分析工具dynamic analyzsis tool
时间管理工具incident management tool
负载测试工具load testing tool
建模工具modeling tool
监控工具monitoring tool
性能测试工具performance tool
需求管理工具requiement management tool
评审工具review tool
安全性工具security tool
压力测试工具stress testing tool
测试比较器test comparator
测试数据准备工具test data preparation tool
测试设计工具test design tool
测试用具test harness
测试执行工具test execution tool
测试管理工具test management tool
单元测试框架工具unit test framework tool

2. 测试工具的作用：
直接用于测试的工具：如测试执行、测试数据生成、结果比对等；
测试过程管理工具：如测试管理、缺陷管理、配置管理；
用于观测的工具或探索：如监控应用程序文件活动的工具；
任何对测试有帮助的工具。

3. 测试管理的工具支持：
测试管理工具：QC、禅道；
需求管理工具：QC；
事件管理工具（缺陷跟踪工具）：QC、bugzilla、Jira；
配置管理工具：CC。

4. 静态测试的工具支持：
评审工具：taskfree；
静态分析工具：？
建模工具：ERWin、UML；

5. 测试规格说明的工具支持：
测试设计工具：正交用例设计工具、PICT（组合测试）;
测试数据准备工具：？

6. 测试执行和记录工具：
测试执行工具：RobotFramework、QTP;
测试用具/单元测试框架工具：JUnit、TestNG；
测试比较器：Notepad++-Compare、diff；
覆盖率测量工具:EclEmma：
安全性测试工具：？

7. 性能和监控工具：
动态分析工具：？
性能测试/负载测试/压力测试工具：JMeter、LoadRunner；
监控工具：IPtraf；sysstat；

8. 特定应用领域的测试工具：
数据质量评估；？
可用性工具：？

9. 有效使用工具：
潜在收益：
    减少重复性工作：如自动化回归测试；
    更好的一致性和可重复性：如工具按相同的顺序和频率执行测试；
    客观的评估：如静态测量、覆盖率；
存在的风险：
    对工具抱有不切实际的希望；
    低估首次引入工具的成本、时间、工作量；
    低估从工具中获得较大和持续性收益需要付出的时间和工作量；
    低估对工具生成的结果进行维护的工作量；
    对工具过分依赖；
    忽视了多个重要工具之间的关联和互操作性：如：需求管理、时间管理、版本控制和其他从不同供应商获得的工具；
    工具供应商：停止工具维护、支持、升级和缺陷修复不力；
    开源/免费工具项目终止的风险；
    其他不可预知的：如不能支持新平台。
    
10. 一些工具类型的特殊考虑
测试执行工具：
    录制：并不稳定；
    数据驱动：测试输入与测试用例分离；随机数；
    关键字驱动：关键字和测试数据；
    需要脚本开发；
    需要储存预期结果进行比较。
静态分析工具：
    产生大量警告信息需要过滤。
测试管理工具：
    需要与其他工具和表格有接口，以便产生符合组织所需格式的有用信息。
    
11. 组织内引入工具考虑的关键点：
评价组织的成熟度、引入工具的优缺点、认识引入工具能改善过程的可能性；
根据清晰的需求和客观的准则进行评估；
概念验证，在评估阶段确认在现有情况下使用工具对被测软件是否有足够效果，或使用工具现有的基础设施需要怎样改变；
评估供应商；
收集内部需求，评估需求时考虑自动化测试技能；
估算成本-收益比。

12. 引入工具从试点项目开始：
对工具有更多的认识；
评估工具与现有过程和实践的配合程度，确定哪些方面需要修改；
定义一套标准的方法来使用、管理、储存和维护工具及测试资产；
评估在付出合理的成本后能否得到预期收益。

13. 成功的因素：
逐步推广；
调整并改进过程来配合工具的使用；
为新使用者提供培训；
定义使用指南；
收集工具使用情况；
监控工具的使用和收益情况；
为测试团队使用工具提供支持；
在所有团队内收集经验和教训。

转载于:https://www.cnblogs.com/workingdiary/p/6867110.html