空间管理您的位置: 51Testing软件测试网 » 海量测试学习资料领取 » 日志

1、免费分享软件测试进阶学习资料：自动化测试、性能测试、测试开发 2、ISTQB考证&软考咨询VX：atstudy-51 备注：111 【限时领取】ISTQB考试资料&学习视频，申请入口>>http://testing51.mikecrm.com/qZ95qK4

【经验】ISTQB FL基础级知识体系总结（上）

上一篇 / 下一篇 2022-04-15 10:20:34 / 个人分类：ISTQB

查看( 607 ) / 评论( 0 ) / 评分( 0 / 0 )

ISTQB FL的知识体系，基本涵盖了大家测试工作的所有方面，包括：软件测试基础、软件生命周期中的测试、静态技术、测试设计技术、测试管理、测试工具。随着工作经验和知识的积累会不断加深，学会总结，加深了自己对测试知识体系的认识，希望考取FL和AL（高级）的同学快速通关！下文为整理网络上关于ISTQB考试的经验内容，希望对要考试的各位所有帮助～

ISTQB 考试资料免费领取，备注“ISTQB”，联系方式atstudy-51，或者联系下面微信：

一、ISTQB概况

ISTQB，全称International Software Testing Qualification Board。其培训和认证体系分为三个级别：

基础级Foundation Level （CTFL）：6个月软件测试或开发工作经验可报考
高级Advanced Level （CTAL）：完成CTFL + 3年以上测试工作经验可以报考，共三个考试模块测试管理、测试分析、技术测试分析
专家级Expert Level （CTEL）：完成CTAL + 5年以上测试工作经验可以报考，共四个考试模块测试过程改进、测试管理、测试自动化、安全性测试

目前只能报考前两个级别的考试。

二、ISTQB CTFL的知识体系

从ISTQB整个认证体系的结构大概就能够看出软件测试所涉及的知识域（包括广度和深度），因此对于从事软件测试工作的我们来说，对于完善自身的知识体系和职业发展来看，都有很高的参考价值。里面包含的内容但凡从事软件测试的人，大概都会听说过，实际工作中碰到的问题，里面很多也都给出了一些实践建议。体系的好处，就是能够给人一个系统化的、全局的视角，将自己实际从事的工作和掌握的知识与之对比，找到自己目前处在什么水平和不足，接下来的努力方向在哪里，帮助我们少走弯路。

关于CTFL，一共有六个部分：

软件测试基础
软件生命周期中的测试
静态技术
测试设计技术
测试管理
软件测试工具

三、软件测试基础

1.错误（Error, Mistake）、缺陷（Defect, Bug, Fault）和失效（Failure）

错误：人为原因导致的一个不正确的结果，包括人的思维错误和行为错误。侧重于人为因素（这里有个假定：人都会犯错）。
缺陷：错误的具体表现。由人设计的代码或文档出现错误后就会引入缺陷。侧重于错误的内在表现，即错误产生的直接原因，也是Developer做bug fix要定位的地方
失效：缺陷的外部反映，程序运行过程中由于代码的缺陷导致一个不正确的结果（期望与实际不一致）。侧重于缺陷的外部反映，是Tester工作中要发现的bug

总结一句话：人犯错导致程序缺陷，Tester通过测试活动发现缺陷提交bug，Developer根据bug定位并修复缺陷改正错误。测试的本质就是发现缺陷

2.软件测试的总体目标

软件开发是有生命周期的，在生命周期中不同的阶段，测试会有不同的目标：

早期：预防缺陷 Preventing defects（静态测试）
开发阶段：发现缺陷 Finding defects（组件测试、集成测试、系统测试）
验收：建立信心 Gaining confidence about the level of quality（验收测试）
运行阶段：提供信息 Providing information for decision-making（非功能测试、维护测试）

3.软件测试的7个基本原则

Testing shows presence of defects 测试可以显示存在缺陷，但不能证明系统没有缺陷
- 要让领导对测试有一个正确的期望
Exhaustive testing is impossible 穷尽测试不可行
- 实际工作中根据风险分析和不同系统功能的优先级，来确定测试的关注点
Early testing 测试尽早介入
- 越早发现缺陷成本越低
- 需求阶段测试就可以介入
Defect clustering 缺陷的集群性
- 少数模块发现大部分缺陷，80/20法则
- 对发现缺陷的地方进行重点测试，尤其是缺陷集中的地方要增加测试覆盖
Pesticide paradox 杀虫剂悖论
- 采用同样的测试用例多次重复进行测试，最后将不再能发现新的缺陷
- 启示：对测试用例要进行定期评审和修改，同时不断增加新的不同的测试用例
Testing is context dependent 测试活动依赖于测试背景
- 针对不同的测试背景，进行不同的测试活动
- 根据测试的环境和目标实施不同类型的测试，如安全测试、性能测试、压力测试等
Absence-of-errors fallacy 不存在缺陷的谬误
- 若系统无法使用，或系统不能满足客户的需求，发现和修复缺陷没有任何意义
- 在进行测试之前，先确保系统可用

4.基本的测试过程

基本的测试过程主要由以下活动组成：

测试计划和控制
测试分析和设计
测试实现和执行
评估出口准则和报告
测试结束活动

4.1测试计划和控制

测试计划：1）识别测试任务。2）定义测试目标。3）为实现目标和任务确定测试活动。一般测试计划开始于软件需求分析结束阶段

测试控制：持续进行的活动，通过对测试实际进度和测试计划的对比，报告测试的状态，根据需要采取纠正措施或更改原计划

产出：测试计划、日常测试报告

4.2测试分析和设计

将概括的测试目标转化为具体的测试条件（即测试项）和测试用例的一系列活动：

评审测试依据（比如需求分析、系统架构、设计、接口说明等文档）
评估测试依据和测试对象的可测性
识别测试条件并确定优先级
确定测试数据
确定测试所需的基础设施和工具（测试环境）
创建测试依据和测试用例间的双向可追溯性

产出：确定测试条件、测试数据、测试环境、测试条件和需求的映射，只需大方向上的东西，不用具体实现

4.3测试实现和执行

主要包括：测试规程和脚本的设计、测试环境搭建、运行测试（即实现、准备、执行）

实现包括：

Test Case：开发测试用例并确定其优先级，识别测试数据
Test Procedure：开发测试规程（即，一组测试用例）并确定其优先级，创建测试数据。（可选，准备测试框架，开发自动化测试脚本）
Test Suites：根据测试规程创建测试套件

准备包括：

Test Environment：搭建测试环境（服务器的搭建、客户端环境的搭建、测试辅助（测试用例、bug等）管理环境的搭建、自动化测试环境搭建）
确认并更新测试依据和测试用例间的双向可追溯性。（测试用例对于测试需求的覆盖，多对一，可通过工具进行映射）

执行包括：

执行测试规程（跑case，手工或自动）
记录测试执行的结果（手工测试通过工具在跑case的时候进行记录passed或者failed，自动化测试的测试报告会自动记录测试执行结果）
对比实际结果和期望结果
对于实际结果和期望结果不一致的，作为事件上报，并分析确定引起差异的原因（分析问题，报bug）
缺陷修复后，重新进行测试活动（Regression test）

产出：测试用例、测试环境、测试执行记录、bug记录

4.4评估出口准则和报告

评估出口准则是将测试执行结果和已定义的测试目标进行比较的活动，这个活动在测试的各个级别上都需要进行。

评估测试出口准则的主要任务：

按照测试计划中定义的测试出口准则检查测试日志（测试用例是否执行完毕，是否达到功能、语句等计划的覆盖指标，继续测试发现缺陷的数量减少低于度量的标准，是否满足退出标准）
评估是否需要进行更多的测试，或者是否需要更改测试的出口准则（根据bug的情况确定）
为利益相关者提供一个测试总结报告（总结测试执行情况、缺陷情况、测试状态）

产出：测试报告

4.5测试结束活动

从已完成的测试活动中收集整合有用的数据（测试经验、测试件、影响测试的因素等）。实质就是总结和积累的相关活动

测试结束活动的主要任务：

检查是否所有计划的交付物都产生并交付了
事件报告是否关闭、或对未关闭的事件报告提交变更需求
记录系统的验收
记录和归档测试件、测试环境和测试基础设备，便于以后复用
移交测试件到维护部门
分析和记录所获得的经验教训
使用积累的有效信息提高测试的成熟度

这里定义的测试结束活动在实际工作中可能会有所裁剪。

5.测试的心理学

独立测试，即开发和测试分离开来，单独进行。独立测试可以应用于任何测试级别。可以从低到高定义不同级别的独立：

开发人员自己写自己测
由同组的其他开发人员测
由专门的测试团队（同一组织内）测
测试外包（外部组织）

开发是建设性思维，测试是破坏性思维，如何避免二者的冲突？

测试人员以建设性的态度对发现的缺陷或失效与开发人员进行沟通
确立共同目标（追求高质量的产品），以合作而不是斗争的方式开始项目
对事不对人，对产品中发现的问题以中性和以事实为依据的方式来沟通，而不要指责引入这个问题的小组或个人
换位思考，尽量理解其他成员的感受以及他们为什么会有这种反应
确信其他成员已经理解你的描述，同时确保自己正确理解了其他人的描述

四、软件生命周期中的测试

1.软件开发模型

软件开发模型是软件开发所依据的方式和过程。软件测试不是孤立存在的活动，而是存在于软件开发生命周期中。因此需要了解软件开发模型，根据不同的模型，选择不同的测试方法。

V模型（顺序开发模型）

依次包括：用户需求、需求分析与系统设计、概要设计、详细设计、编码实现、模块测试、集成测试、系统测试、验收测试
此开发模型对应四种测试级别：组件/单元测试、集成测试、系统测试、验收测试

迭代-增量开发模型

由需求建立、设计、构建和测试等一系列相对较短的开发周期构成
常见模型：原型开发、快速应用开发（RAD）、统一软件开发过程（RUP）和敏捷开发模型（目标比较常用）

生命周期模型中的测试

每个开发活动（不仅仅是代码的开发，也包括需求文档、系统设计等）都有对应的测试活动
每个测试级别都有特有的测试目标
对于每个测试级别，都要进行相应的测试分析和设计
测试要参与文档的评审（文档初稿阶段）

2.测试级别

对于各个测试级别需要明确的内容：测试目标、测试依据、测试对象、典型缺陷和失效、对测试用具的需求、测试工具的支持、专门的方法和职责

1）组件测试/单元测试

测试目标：检查代码是否符合设计和规范，发现缺陷
测试依据：组件需求说明、详细设计文档、代码
测试对象：代码（组件、程序、数据转换/移植程序、数据库模型）
典型缺陷和失效：TBD
对测试用具的需求：会用到桩模块、驱动模块和模拟器
测试工具：单元测试框架，如JUnit
专门的方法：TDD测试驱动开发，先编写测试用例，测试覆盖率
职责：由开发人员完成

2）集成测试

测试目标：检查组件之间交互的接口，以及一个系统内不同部分的相互作用，发现缺陷
测试依据：软件和系统设计文档、系统架构、工作流、用例
测试对象：子系统、数据库实现、基础结构、接口、系统配置和配置数据
典型缺陷和失效：TBD
对测试用具的需求：有多种的集成级别：组件集成（组件之间的交互测试）、系统集成（不同子系统或软硬件之间的交互测试）
测试工具：集成的规模越大，定位缺陷的难度越大
专门的方法：集成程度逐步增加（自顶向下、自底向上），避免采用大爆炸式的集成
职责：由测试人员完成

3）系统测试

测试目标：在实际运行环境中充分运行系统，严重系统各部件是否能正常工作，符合软件需求规格说明，发现缺陷
测试依据：系统和软件需求规格说明、用例、功能规格说明、风险分析报告
测试对象：系统、用户手册和操作手册，系统配置和配置数据
典型缺陷和失效：TBD
对测试用具的需求：自动化测试
测试工具：功能测试、非功能测试（压力、性能、容量）、用户界面测试、兼容性测试、国际化测试、本地化测试等测试工具
专门的方法：基于需求的测试、基于业务流程的测试、基于用例的测试、基于风险评估的测试
职责：由独立的测试团队完成

4）验收测试

测试目标：建立信心
测试依据：用户需求、系统需求、用例、业务流程、风险分析报告
测试对象：基于完全集成系统的业务流程、操作与维护流程、用户处理过程、结构、报告、配置数据
典型缺陷和失效：TBD
对测试用具的需求：验收测试可以在多个级别上进行（组件测试、集成测试、系统测试）
测试工具：根据需求和实际情况而定
专门的方法：用户验收测试、操作测试、合同和法规性验收测试、Alpha和Beta（现场）测试
职责：由用户或客户进行，其他利益相关者可能参与其中

3.测试类型

1）功能测试

功能测试基于功能和特征以及专门的系统之间的交互，可以在各个级别的测试中进行
功能测试主要考虑软件的外部表现行为，不考虑程序的具体执行路径
通常采用黑盒测试（又称为功能测试、数据驱动测试）
安全性测试是功能测试的一种，关注安全相关的功能（如防火墙）
互操作性测试是功能测试的一种

目前很多公司所做的测试基本都会包含功能测试

2）非功能测试

包含但不限于：性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试、可移植性测试
非功能测试测试系统运行的表现如何，可以在任何级别上执行
非功能测试关注的是软件的外部行为表现，通常采用黑盒测试设计技术来实现测试用例

公司中做的较多的就是性能测试

3）软件结构/架构测试（结构测试）

结构测试也称为白盒测试、逻辑驱动测试
结构测试可以在任何测试级别上进行（不局限于组件测试/单元测试，也可用于系统测试、集成测试、验收测试）
覆盖coverage：指结构通过测试套件检验的程度，以项被覆盖的百分比来表示。若覆盖率不足100%，可能需要设计更多测试用例来测试被遗漏的项，提高测试的覆盖
白盒测试的主要方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖，基本路径测试

4）与变更相关的测试（再测试和回归测试）

再测试：当发现和修复一个软件缺陷后，需要重新进行测试以确定已经成功修复了原来的缺陷，这称之为确认测试，再测试
回归测试：对已被测过的程序在修改缺陷后进行的重复测试，以发现在这些变更后是否有新的缺陷引入或被屏蔽。
- 回归测试的规模可以根据以前正常运行的软件中发现新的缺陷的风险大小来确定
- 回归测试可在所有测试级别上进行，同时适用于功能测试、非功能测试和结构测试

4.维护测试

软件发布之后，系统通常要运行数年甚至数十年，在软件生命周期中的维护阶段，由于业务等方面的变化而进行修改、拓展、移植及部分软件被淘汰等原因所进行的测试称为维护性测试
维护性测试是在一个运行的系统上进行，且一旦对软件或系统进行修改、移植或系统被淘汰时，就需要进行维护性测试

五、静态技术

1.静态技术和测试过程

静态测试技术：通过手工检查（评审）或自动化分析（静态分析）的方式对代码或其他项目文档进行检查而不需要执行代码
评审：对软件工作产品（包括代码）进行测试的一种方式，可以在动态测试之前进行
- 在生命周期早期的评审过程中发现并修改缺陷的成本比在动态测试中发现并修复缺陷的成本低
- 评审可以完全以手工方式进行，也可以通过工具的支持来进行。人工评审是检查工作产品，并对其做出评估
- 评审的目的在于发现工作产品的缺陷和需要改进之处
与动态测试的对比
- 评审、静态分析和动态测试具有共同的目标：识别缺陷。它们之间是互补的，不同的技术可以发现不同类型的缺陷。
- 静态技术发现的是软件失效的原因（缺陷），动态测试发现的是失效本身
- 评审发现的典型缺陷：与标准之间的偏差、需求内的错误、设计错误、可维护性不足和错误的接口规格说明等
静态测试技术分类：评审（非正式评审、正式评审（走查、技术评审、审查））、静态分析（词法和语法分析、静态错误分析）

2.评审过程

评审的类型：
- 非正式评审：不需要遵循明确定义的过程
- 正式评审：遵循明确定义的过程，参与人员由明确的职责和检查表，有明确定义的进入和完成评审的准则（结构化和规范化）
  - 正式评审包括：走查 Walk Through（作者主持）、技术评审 Technical Review（有专门主持人、无管理者参与）、审查 Inspection（管理者参与、引入度量项）
评审的目标：发现缺陷、增加理解、培训测试员和团队新成员、对讨论和决定达成共识
正式评审的阶段：典型的正式评审又以下六部分组成
- 计划阶段：定义评审标准、选择人员、分配角色、制定入口和出口准则、选择要进行评审的文档内容、核对入口准则
- 预备会阶段：分发文档、向评审参与者解释评审的目标过程和文档
- 个人准备阶段：先行评审文档，为评审会议做准备；标注可能的缺陷、问题和建议
- 检查/评价/记录结果（评审会议阶段）：讨论和记录；标注缺陷、提出处理建议、对缺陷做出决策；检查、评价和记录问题
- 返工阶段：修改发现的缺陷、记录缺陷更新的状态
- 跟踪结果阶段：检查缺陷是否已得到解决，收集度量数据，核对出口准则
角色和职责：经理（拍板的）、主持人（协调的）、作者（责任人）、评审员（发现问题和给出建议）、记录员（会议记录）
评审成功的因素：明确的目标、合适的评审人员、对发现的缺陷持欢迎态度、不对参与者进行评价、合适的检查表、提供评审技术培训、管理层支持、强调学习和过程的改进

3.静态分析的工具支持

静态分析的目的：发现软件源代码和软件模型中的缺陷
静态分析通常发现的是缺陷而不是失效
静态分析工具能够分析程序代码（比如控制流和数据流），以及产生如HTML和XML的输出
静态分析工具发现的典型缺陷：
- 引用一个没有定义值的变量
- 模块和组件之间接口不一致
- 从未使用的变量
- 不可达代码
- 逻辑上的遗漏与错误（潜在的无限循环）
- 过于复杂的结构
- 违背编程规则
- 安全漏洞
- 代码和软件模型的语法错误
静态分析的策略：开发人员在组件测试和集成测试之前或期间、或当代码签入配置管理工具时使用静态分析工具；设计人员在软件建模期间使用静态分析工具

六、测试设计技术

1.测试开发过程

1）测试开发过程

之前测试过程中也有介绍，这里侧重于测试的开发过程，大体分为：分析阶段、设计阶段和实现阶段
分析阶段：确定测什么（即明确测试条件），将测试条件定义为能通过测试用例进行验证的一个条目或事件，建立测试条件到需求的可追溯性
设计阶段：定义和记录测试用例和测试数据。完成测试设计规格说明和测试用例规格说明。
- 测试用例包括：一组输入值、执行的前提条件、预期结果、执行的后置条件、输出、数据和状态的变化等
实现阶段：测试用例的开发、实现、确定优先级和组织包含在测试规程说明中。测试规程描述了测试用例执行的顺序，即执行测试选取的case和执行顺序
总结：测试开发过程就是确定测什么、设计怎么测试、以及决定如何执行测试的过程

2）测试设计规格说明、测试用例规格说明、测试规程规格说明：分别是测试条件（测试项）、测试用例、一组包含优先级和顺序的测试用例

3）如何评价测试用例的质量：建立测试条件和需求的可追溯性（便于需求变更时的影响分析和测试用例集的需求覆盖率分析）、期望结果

2.测试设计技术的种类

使用测试设计技术的目的：识别测试条件、开发测试用例（即确定测试什么和怎么测）

测试设计技术的分类：

基于规格说明的测试技术（黑盒）：依据文档来选择测试条件、测试用例和测试数据的技术。包含功能和非功能的测试。
基于结构的技术（白盒）：基于分析被测组件或系统的结构的测试技术
基于经验的技术：根据测试人员对相似的应用或技术的经验以及知识和直觉进行的测试

3.基于规格说明的或黑盒测试技术

等价类划分：基于一个假定，将软件或系统的输入分成不同的组，对于同一组输入，软件或系统应该有相似的表现。进而划分为有效等价类和无效等价类
- 等价类的划分可以基于输入、输出、时间相关的值（例如在事件之前或之后）、接口参数等进行
- 确定等价类的步骤：
  - 分类：将输入按照相同特性或者类似功能进行分解
  - 抽象：在各子类中抽象出相同特性并用实例表征该特性
  - 确定有效等价类（测试程序实现了规定的功能）和无效等价类（测试程序的容错性，对异常情况的处理）
- 根据等价类设计测试用例
边界值分析：是等价类法的有效补充，在各等价类的边界通常更可能出现不正确的行为，因此边界是测试可能发现缺陷的地方。
- 每个划分的最大和最小值就是它的边界，有效部分的边界就是有效边界值，无效部分的边界就是无效边界值
- 边界值分析可以应用于所有的测试级别
- 边界值的选择方法：若输入条件规定了值的范围，则取刚达到这个范围的边界的值，以及刚刚超过这个范围边界的值作为测试输入数据
决策表测试：决策表也叫判定表，用来表示和分析复杂逻辑关系，适合描述不同条件组合下采取行动的若干组合情况

建立决策表时，要分析规格说明，识别系统的条件和动作
决策表通常由4部分组成：条件桩（列出问题的所有条件，不强调条件的顺序）、动作桩（列出问题规定可以采取的操作）、条件项（列出条件桩的取值：真或假）、动作项（列出在条件项的各种取值情况下应该采取的动作）
任何一个条件组合的特定取值及其相应要执行的操作，可视为一条规则，可设计为一条测试用例
在设计决策表时可以将动作项相同的规则合并，减少冗余

状态转换测试：将软件运行或操作的过程看作是其状态不断发生变化的过程，可以根据软件的状态、状态间的转换、触发状态变化的输入或事件、状态转换导致的可能的行动来进行测试。
- 被测系统或对象的状态时独立的、可确认的，并且数量有限
- 一个状态表描绘了状态和输入之间的关系，并能显示可能的无效状态转换
- 设计的测试可以覆盖一个典型的状态序列、覆盖每个状态
- 执行每个状态的转换、执行特定的状态转换顺序、执行无效的状态转换
用例测试：用例描述了参与者之间的相互作用，基于系统最有可能使用的情况描述了过程流，可以从用例中得到测试用例。
- 用例都有前置条件（用例成功执行的必要条件）和后置条件（用例执行完后能观察到的结果和系统的结束状态）
- 用例测试便于发现不同组件之间相互作用而产生的集成缺陷，可用于验收测试
- 用例通常都有一个主场景（最有可能发生的场景）和可选的分支

4.基于结构的技术或白盒技术

结构测试的级别：基于结构的测试/白盒测试可应用于所有测试级别，不仅仅局限于组件级（平时大家说的白盒测试多指组件级的单元测试）
- 组件级别：结构是指软件组件的结构，比如：语句、判定、分支或每个不同的路径
- 集成级别：结构可能是调用树（模块调用关系图）
- 系统级别：结构可能是菜单结构、业务过程或Web页面结构
语句覆盖：设计若干测试用例运行所测程序，使得每一条可执行语句至少执行一次
- 语句覆盖率：被（设计或执行）测试用例覆盖的可执行语句数量除以被测代码中所有可执行语句数量
- 语句覆盖不能发现判断中逻辑运算中出现的问题，语句覆盖是最弱的逻辑覆盖
判定覆盖：设计若干测试用例运行所测程序，使得程序中每个判定的取真分支和取假分支至少经历一次
- 判定覆盖率：被（设计或执行）测试用例覆盖的所有判定出口数量除以被测代码中所有可能的判定出口数量
- 判定覆盖比语句覆盖更全面，100%的判定覆盖可以保证100%的语句覆盖，反之则不行
条件覆盖：判定条件中，保证每个条件至少有一次取真、取假。
- 条件覆盖是对判定覆盖的有效补充，可以覆盖判定覆盖中遗漏的判定条件
- 白盒测试要求同时满足判定覆盖和条件覆盖

5.基于经验的技术

概念：根据测试人员对相似应用或技术的经验以及知识和直觉来进行测试，是对系统化生成测试用例的一个有效补充，其效果取决于测试人员的经验
错误推测法：预测缺陷，列出可能的错误，并设计测试来攻击这些错误，称之为缺陷攻击
- 可以根据经验、已有的缺陷和失败数据、有关软件失败的常识等设计缺陷
探索性测试：根据测试计划中包含的测试目标，同时进行测试设计、测试执行的测试活动。非形式化的测试方法，由测试人员积极的参与和控制测试的设计，利用在测试过程中获得的信息设计出新的、更好更完善的测试。（最近探索性测试在网络上大家讨论的比较火）
- 常用于缺少有价值的测试文档、测试时间压力大的场合
- 可作为对其他正式的测试的增加或补充
- 可作为测试过程中的检查，有助于发现严重的缺陷

6.选择测试技术

测试技术的选择，在实际设计测试用例过程中需要根据实际情况进行交叉使用，保证对测试对象足够的覆盖率
ISTQB大纲中给出的考量因素有：系统类型、法律法规标准、客户或合同的需求、风险的级别、风险的类型、测试目标、文档的可用性、测试人员的技能水平、时间和成本预算、开发生命周期、用例模型和以前发现各类缺陷的经验等

七、测试管理

1.测试的组织结构：

涉及两个角色：测试组长和测试员
测试组长：主要负责测试计划、监督与控制、协调
- 可能的任务：测试策略、测试方针、测试计划、测试监督和控制、测试进度、自动化选取、测试报告、各种问题的协调
测试员：主要负责测试分析、设计与执行
- 可能的任务：测试规格说明、测试环境、测试数据、测试执行和记录、自动化实施

2.测试计划和估算

测试计划
- 测试计划受到以下因素影响：组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测性、资源的可用性等
- 测试计划是个持续的活动，需要在整个生命周期过程和活动中，从测试中不断得到反馈识别风险，从而对计划做相应的调整
- 测试计划活动包括：
  - 确定测试范围和风险，明确测试目标
  - 决定总体测试方法，包括测试级别、入口和出口准则的界定
  - 决定测什么？谁来测？怎么测？如何评估测试结果？
  - 为测试分析、设计、实现、执行和评估安排时间进度
  - 为已定义的不同测试活动分配资源
  - 定义测试文档的数量、详细程度、结构和模板（确定输出）
  - 为监控测试准备和执行、缺陷解决、风险问题选择度量项
入口准则：定义什么时候可以开始测试，主要包括：
- 测试环境准备就绪并可用
- 测试工具准备就绪
- 测试对象可用
- 测试数据可用
出口准则：定义什么时候可以停止测试，主要包括：

完整性测量，比如代码、功能或风险的覆盖率
对缺陷密度或可靠性度量的估计
成本
遗留风险，比如没有修复的缺陷或在某些区域缺少测试覆盖
进度表，如基于交付到市场的时间

测试估算：这里介绍了两种估算方法，基于度量的方法（基于相似项目和典型数据）和基于专家的方法（依赖于专家）
- 实际估算过程：将软件测试工作进行WBS分解，通过分解定义的任务，并根据以前项目测试的经验和历史数据确定任务的工作量，根据工作量并结合企业生产率估算出成本
- 一旦估算了测试工作量，就可以识别资源和制定时间进度表
- 测试工作量的内容：测试用例设计、测试环境设置、测试用例执行、测试缺陷报告
测试策略、测试方法
- 测试策略通常是描述如何测试软件的总体方法和目标，包括确定测试环境、阶段、类型、方法和技术。
- 制定测试策略的目的：确定合理的测试方案、识别测试主要任务和风险，使得测试更有效
- 测试方法是测试策略的具体实现，在测试计划和设计阶段被定义并逐步细化的，通常取决于测试目标和风险评估
- 典型的测试方法：分析的方法、基于模型的方法、系统的方法、基于过程或符合标准的方法、动态和启发式的方法、咨询式的方法、可重用的方法。

注：实际工作中，我们用到的出口准则：

测试执行对于功能的覆盖达到100%（在设计测试用例时就提前做好了全覆盖，只是对于不同轮次的测试会有所剪裁，比如第一轮覆盖100%，回归测试只覆盖新功能和bug出现的模块）
严重及以上级别bug为0（将bug的严重级别分为5个级别：5极其严重（系统崩溃）、4非常严重（功能模块不可用）、3严重（功能部分可用）、2中度（不影响使用但影响用户体验）、1轻微（其他））
遗留的bug作为变更请求已经提交

3.测试过程监控

测试监控的目的：为测试活动提供反馈信息和可视性。测试监控包括监督（搜集数据）和控制（纠正偏差）
监控的对象：测试覆盖率（需求、风险、代码）、进度（测试用例执行）、缺陷（数量、趋势）
监控的体现形式：测试报告

4.配置管理

配置管理的目的：在整个项目和产品的生命周期内，建立和维护软件或系统产品（组件、数据、文档）的完整性
对测试的作用：保证测试件被识别，版本受控，变更可跟踪可追溯

5.风险和测试

风险：事件、危险、威胁或情况等发生的可能性，以及由此产生的不可预料的后果，即一个潜在的问题（未实际发生）
风险级别：由发生不确定事件的可能性和产生的影响（事件引发的不良后果）来确定
项目风险：项目按目标交付的能力方面的风险
- 从组织因素、技术因素、供应商因素来考虑
产品风险：软件或系统中的潜在失效的部分
风险和测试的关系：风险通常可以用来决定从什么地方开始测试，什么地方需要更多的测试。测试可以降低风险或减少负面事件的影响

6.事件管理

事件：实际结果和预期结果之间的差异需要作为一个事件被记录。（即我们通常所说的bug、defect）
事件和缺陷：事件可能由于缺陷导致，也可能不是；缺陷是已经确认需要修复的实际问题。（我们实际工作中被接受的bug才算作缺陷）
事件可能发生在任何地方（需求文档、开发文档、测试文档、用户文档、代码等），不局限于测试执行过程中发现的不一致
事件报告的目的：提供问题反馈、跟踪系统质量和测试进度、为测试过程改进提供资料
事件报告的内容包括：预期和实际的结果、识别测试项和环境、软件所处的生命周期阶段、事件描述（日志、数据库备份或截屏）、影响范围、严重程度、修复的紧迫性/优先级、事件状态、结论、全局的影响、变更记录、参考

八、软件测试工具

1.测试工具的类型

测试工具的意义：支持测试活动
- 根据不同类型的测试活动，就有了不同的测试工具。大体包括：直接用于测试的工具、测试过程管理工具、用于观测的工具、对测试有帮助的工具
- 测试框架：被大量的应用于工业界，它至少包含以下三个含义
  - 可重用、可扩展的测试库，可用于搭建测试工具（也叫测试用具）
  - 设计测试自动化的设计类型（比如，数据驱动、关键字驱动）
  - 测试执行的全过程
测试工具的分类：可分为功能测试工具（白盒测试工具/黑盒测试工具）、性能测试工具、测试管理工具（测试流程管理、缺陷跟踪管理、测试用例管理）
测试管理工具：测试管理工具、需求管理工具、事件管理工具（缺陷跟踪工具）、配置管理工具。实际应用中的TD、JIRA、RTC等
静态测试工具：评审工具、静态分析工具、建模工具
测试规格说明的工具：测试设计工具、测试数据准备工具。QTP、WinRunner、Robot、RFT、Selenium
测试执行和记录工具：测试执行工具、测试用具/单元测试框架工具、测试比较器、覆盖率测量工具、安全性测试工具
性能和监控工具：动态分析工具、性能测试/负载测试/压力测试工具、监控工具。LoadRunner、JMeter、Nmon

2.有效使用工具：潜在的利益和风险

收益：
- 减少重复性的工作（比如执行回归测试、重新输入相同测试数据、代码规则检查）
- 更好的一致性和可重复性
- 客观的评估（比如，静态测量、覆盖率）
- 容易得多测试和测试相关的信息（比如，测试进度的统计和图表、事件发生率和性能等）
风险：
- 对工具抱有不切实际的期望（功能性和易用性）
- 低估首次引入所需的时间、成本和工作量（包括培训和额外的专业知识）
- 对工具过分依赖（对适合手工测试的任务使用自动化工具）
- 忽视了在工具中对测试对象的版本控制

3.组织中工具的引入

组织选择工具所需考虑的关键点：
- 组织的成熟度、引入工具的优缺点、引入工具能改善测试过程的可能性
- 根据清晰的需求和客观的准则进行评估
- 基础设施是否需要改变，及如何改变
- 评估供应商
- 收集内部需求
- 测试团队的自动化测试技能
- 成本收益比
将选择的工具引入组织要从一个试点项目开始（增加认识、收集反馈进行改进、定义使用标准、评估投入产出）
在组织内成功部署工具的因素：逐步推广、过程改进的配合、提供培训、定义使用指南、监控工具的使用和收益、提供支持、收集经验和教训

【经验】ISTQB FL基础级知识体系总结（上）

相关阅读:

用户菜单

我的栏目

标题搜索

日历

我的存档

数据统计

RSS订阅