ISTQB基础级学习笔记
2023-08-24 10:35:01 1 举报AI智能生成
ISTQB基础级学习笔记涵盖了软件测试的基础知识，包括测试的定义、原则、过程和策略。学习者将了解不同类型的测试方法，如功能测试、性能测试、安全测试等，以及如何设计和执行有效的测试计划。此外，笔记还涉及了缺陷管理、测试用例设计技巧和测试工具的使用。通过学习ISTQB基础级课程，您将掌握软件测试的基本概念和技能，为成为一名优秀的软件测试工程师奠定坚实的基础。
作者其他创作
大纲/内容
测试技术分类和特点
测试技术分类
有效等价类
无效等价类
可以应用在所有测试级别
等价类之前没有交集
等价类内可以划分子分区
注意域的取值
选取选取代表值
细分类
确定基本类
规定取值范围或值得个数时，可以确定一个有效等价类和两个无效等价类
确定输入值的集合或规定了“必须如何”，可以确定一个有效等价类和一个无效等价类
布尔量，可以确定一个有效等价类和一个无效等价类，可能无无效等价类
规定了输入数据的一组值，对每个输入值分别处理的情况下，可以确定n个有效等价类和一个无效等价类
规定输入数据同时遵守多条规则，可确定一个有效等价类（符合规则）和n个无效等价类（从不同角度违反规则
已知划分等价类中，根据处理的方式不同，进一步划分更小的等价类
划分原则
为每一个无效等价类设计测试用例，无效等价类代表值仅与有效等价类代表值组合
最小组合设计有效等价类，最小组合（尽量少的用例覆盖尽量多的等价类）
划分等价类，得到等价表，为等价表进行唯一编号
划分步骤
划分等价类
等价类划分
等价类的最大和最小值
等价类的第一和最后的值
等价类的扩展，适用于等价类是有序的、有数字或顺序数据组成的
适用于所有的测试级别
到边界值之前
正好到边界
刚超过边界的值
考虑健壮性
区分开区间、闭区间和半开闭区间的取值，取值一个有效值，一个无效值
边界值分析
条件部分至少有一个条件项
动作部分至少有一个动作项
最小覆盖标准是每个判定规则至少有一个测试用例
完整性
冗余
具有相似的规则却又有不同的行动指示
同样的结果行为，规则只有一个不同的，可以进行合并
谨慎对待合并不关心条件值
或者系统条件逻辑存在问题
不一致性问题
只能使用一次else
等价类并不能覆盖所有情况，如果条件之间存在制约关系，输入（条件值）和输出（动作）为布尔值
可以在任何测试级别进行
判定表测试（决策表）
正交实验法（针对复杂系统情况下进行的判定表方法）
开始状态（强制的），指定一个入口作为开始
通过输入或事件触发
导致可能的输出
状态转换
结束状态（选项）
可以设计逆向的测试用例
常用于嵌入式系统
借助转换树生成测试用例
增加error状态，包含健壮性的状态转换树
画出状态转换树
列出状态转换表
换出状态转换图
步骤
状态转换测试（状态图）
因果图（复杂的判定表）
测试前置条件
后置条件
用例编号需要与需求编号对应
分析用户会怎样与系统交互
用例间的关系可以是包含的也可以是扩展的，扩展的条件并不是总是执行的
可以用于所有测试级别，多用于验收测试、系统测试（冒烟测试）、集成测试
用例测试（基于用户场景测试）
黑盒测试技术（不关注内部结构）
适用于所有测试级别，结合控制流图使用
组件测试阶段，基于代码
集成测试
网页的关联结构
系统测试
在更高测试阶段的原则
100%的语句覆盖，也可能发生遗漏
语句测试和覆盖
判定覆盖的覆盖率比语句覆盖要高
实现100%的判定覆盖可保证100%的语句覆盖，反之不成立
语句和判定测试的价值
100%的判定覆盖，也可能发生遗漏
不仅仅是执行语句，还有判定结果的情况
判定测试和覆盖
逻辑覆盖率
白盒测试技术（基于内部结构）
系统化方法：创建一个可能的错误、缺陷和失效的列表
对人员经验依赖大
错误推测（缺陷攻击）
测试章程
依据经验来动态的设计和执行测试
全局探索式测试方法（漫游测试）
探索性测试
要及时更新
覆盖度更高，重复率更低
新人使用，漏测率会很高
作为黑盒或白盒的辅助
设计、实施和执行测试来覆盖检查表中发现的检查条件
基于检查表的测试
基于经验的测试技术
测试技术
独立测试人员，不同的背景、技术视角和观察
可以在系统说明和实施过程中验证、质疑或反驳干系人的假设
客观报告结果，不会收到其他压力
优点
如果完全独立，与开发团队缺乏协作或可能形成对抗关系
让开发人员感受到测试人员需要为质量共同负责
开发人员可能丧失对软件质量的责任感
最好拟定书面规范，共同遵守
可能被视为瓶颈或延迟发布而被责备的对象
可能缺少一些重要的信息
缺点
测试的独立性不是越高越好
独立测试
制定或评审测试方针和测试策略
考虑背景和理解测试目标和风险来规划测试活动，包括规划测试缺陷管理
编写和更新测试计划
与其他相关方协调测试计划
共享测试视角
启动测试活动，监督测试进度和结果，检查出口准则
收集信息和提交测试进度报告和测试结果报告
调整测试计划并采取所需的行动并进行调整
建立缺陷管理系统和测试件的配置管理
度量测试进度和评估测试和产品质量
选择和实施测试工具，分配时间和工具，工具方面的支持
决定测试环境的实施
促进和支持测试人员
培养测试人员的技能和关心职业发展
总体负责测试过程和成功管理测试活动
测试经理
评审和参与测试计划的制定
分析、评估和评估可测试性，强调参与
获取测试条件、测试用例和测试依据之间的可追溯性，强调跟踪
设计、监理和验证测试环境，强调建立环境
设计和实施测试用例和测试规程，拟定测试规程
测试数据的准备，准要工作
创建详细的测试执行进度表，执行用例
进行所有级别的测试，评估测试结果，记录和预期的结果的偏差
使用适当的工具来促进测试完成
依据需求实施自动化
评估非功能特性
评审他人开发的测试
测试员
测试人员也可能代替测试经理汇报测试进度
测试经理和测试员的任务
测试组织
描述测试环境和期望的结果，测试通过的标准
测试设计规格说明
执行顺序，包括每项预置条件和接下来执行的步骤
测试规程规格说明
测试对象
功能/非功能测试需求，是否需要采购工具
测试组长结构，明确测试的独立程度
其他，基于风险，基于基准
测试计划的目的
组长的测试方针和测试策略
使用的开发生命周期和方法
测试范围
测试目标
风险
约束
重要性
可测试性
资源的可用性
影响的因素
测试的范围、目标和风险
定义总体测试方法
测试活动集成和协调到软件生命周期活动中
确定测试内容、人员资源
项目风险
...
测试计划的内容
测试计划的目的和内容
基于对某些因素
基于分析
基于产品的某些需求方面的模型设计，如业务过程模型、状态模型
基于模型
依赖于预定义的测试集和测试条件，游戏测试领域最为常见
基于方法
包括基于外部规则和标准的分析、设计和实施测试
基于过程和标准一致性的策略（符合流程/标准）
使用利益相关方、业务领域专家或技术专家的建议、指导或指示驱动
指导性（基于专家的方法）
重用现有测试件、回归测试的广泛自动化以及标准测试套件
规避回归性（面向可重复）
比较被动， 应对测试期间发生的事件，不是预先的计划，强调灵活性
应对型（动态和启发性）
测试策略和测试方法
定义了什么时候可以开始测试
上一阶段的活动是否已经通过
测试环境是否就绪，是否可以展开后续的测试工作
必要测试工作的可用性
测试数据和其他必要资源的可用性
入口准则定义了特定测试活动的前置条件
已执行计划的测试
已实现规定的覆盖级别
若达不到出口准则，但利益相关方/业务负责人接收上线风险
未解决的缺陷数量在商定的限度内
遗留缺陷数量足够低
其他相关非功能质量特性的评估级别是否已足够
出口准则定义了声明测试基本或一组测试完成必须达成的条件
每个级别和每个类型都可以定义入口和出口准则‘
入口准则和出口准则（就绪的定义和完成的定义）
确定了不同测试类型的优先顺序
生成测试用例和测试规程，组装到测试套件中，进度表定义了测试套件的运行顺序
测试执行进度表
与产品有关的因素
与过程有关的因素
与人有关的因素
与测试结果有关的因素
影响测试工作量的因素
借助历史类似项目的度量
基于典型值来估算测试工作量，如燃尽值（敏捷开发模型）、缺陷移除模型（顺序开发模型）（DRM、DRE）
基于度量的估算技术
例如计划扑克（敏捷开发模型）、宽带德尔菲估算（匿名估算）（顺序开发模型）
有任务的测试负责人或专家的经验来估算工作量
测试估算方法
测试计划和估算
根据计划时间表和预算取得的进展
对象的当前质量
测试方法的充分性
与目标相关的测试活动有效性
测试活动期间和结束时收集度量
用例准备，计划工作完成的百分比
环境准备，计划工作完成百分比
测试用例执行的各种度量
缺陷信息
需求、用户故事、验收准则、风险或代码的测试覆盖率
任务完成、资源分配和使用以及工作量
测试成本
常见的测试度量
定期的度量测定和评估可以形成状态判定是趋势分析和预测的可靠基础
测试中使用的度量
测试活动期间和结束时，总结和传达测试活动信息
目的
说明当前阻塞测试的情况
测试活动期间准备的信息
测试进度报告
测试能说明缺陷的存在，而不能说明缺陷的不存在
不能保证所有的阻碍已经被解决
剩余风险
生成的可重用的测试工作产品，知识库
结束时候，一般包括测试进度报告的内容
测试总结报告
内容
可以根据周境和受众裁剪
受众
测试报告的目的、内容和受众
测试监督和控制
所有测试件项都有唯一的标识、版本控制、变更跟踪并彼此相互关联
所有测试件项都有唯一的标识、版本控制、变更跟踪并彼此相互关联并且关联到测试项版本，以便保持可追溯性
已识别的文档和软件项在测试文档中明确引用
配置管理
高低权衡优先级的影响因素
考虑事件发生的可能性
人员伤亡，财务损失
形象的损害，顾客信任的损失
修理费用
对其他系统的影响
考虑事件的影响程度
对未发生事件的预估
风险涉及未来可能发生负面后果的事件
风险的定义
质量风险
产品的失效
与测试对象直接关系的风险
外在的可能性
产品风险
项目事件
组织事件
政治事件
技术事件
供应商事件
与项目管理控制的相关的风险
内在的风险
产品和项目的风险
要时刻进行跟踪
风险不是一成不变的
风险识别
可能性*影响的严重程度
风险级别的排序
风险分析
风险缓解
风险管理是一个在项目或组织内的系统的确认，分析/评估控制知道客服风险的循环过程
基于风险的测试和产品质量
风险和测试
发现、分析、修改、修改的确认
实现系统化和管理化不可缺少的工具
缺陷数据库，缺陷管理工具
生命周期内要对缺陷进行跟踪
缺陷严重程度的定义
缺陷优先级
简洁易懂
可重现和可定位
可定位测试环境
好的缺陷报告
缺陷生命周期
缺陷管理
测试管理
ALM
测试管理工具和应用生成周期管理工具
Rational DOORS
青铜器RDM
需求管理工具
Marntis，bugzila，jira，禅道
缺陷管理工具
Chef，SVN，Git
配置管理工具
是一种软件开发实现，如持续集成、持续部署、持续交付
GitLab，Jenkins，TeamCity
持续集成工具 D
测试管理工具
SonarQube，Pylint
静态测试工具 D
静态测试工具
UML活动图，用例图
基于模型的测试工具（建模工具）
自动化工具中随机数据的生成
自动生成指定文件大小和文件类型
测试数据准备工具
测试设计和实施工具
自动化回归，Selenium
测试执行工具
多使用测试管理工具
需求覆盖
Coverage，DotCover
语句覆盖/条件覆盖/判定覆盖
代码覆盖 D
覆盖率工具
也成测试桩，目的是利用工具快速创建测试桩
Python中的Mock包
Java中的Mockito
测试用具 D
测试执行和日志记录工具
LoadRunner，Jmeter
性能测试工具
Profiler，Nmon
动态分析工具 D
性能测量和动态分析工具
属于定制化的工具
可达性测试（无障碍测试），用户界面可达性测试工具AccChecker
支持专业测试要求的工具
测试工具分类
减少重复性的工作量
更好的一致性和可重复性
客观的评估
容易得到测试和测试的相关信息
对工具抱有不切实际的期望
低估首次引入工具所需要的时间、成本和工作量（包括培训和额外的专业知识成本）
低估从工具中获得较大和持续性收益需要付出的时间和工作量（可能需要更改测试过程，并不断改进）
低估了对工具生成的结果进行维护所需要的工作量
对工具过分依赖
忽视了工具中对测试对象的版本控制
忽视了多个重要工具之间的关联和互操作性，可能需要二次开发工具供应商的破产、停止维护或卖给其他供应商的风险
供应商对工具的支持、升级和缺陷修复反应不给力
开源/免费工具工具项目的中止风险
工具可能不支持新的平台或新技术的风险
工具所有权不清晰带来的风险，可能升级需要二次付费
潜在风险
测试自动化的收益和风险
需要记录测试人员操作
需要开发方面的知识
使用自动化测试脚本执行测试对象
实现了（测试数据+预期结果）和测试脚本的分离
测试输入和期望结果保存在一个表中的脚本技术
数据驱动
允许不熟悉脚本语言的测试人员进行维护
所使用的数据文件包括关键词+测试数据+预期结果
关键字驱动
基于模型MBT的测试工具
客观收益
都需要比较预期结果和实际结果
执行自动化的开销主要在创建脚本和维护脚本上
以便生成符合组织所需格式的有用信息
为了维护需求管理工具中针对需求的一致可追溯性
为了链接到配置管理工具中测试对象的版本信息
需要与其他工具和表格有接口
测试执行和测试管理工具的特殊考虑
测试工具的考虑
组织的成熟度越高，引入工具的优点和缺点考虑越多
识别引入工具能改进测试过程的机会
了解测试对象所使用的技术，以便选择与此技术兼容的工具
了解组织内使用的构建和持续集成工具，以便确认工具的兼容和集成
根据需求和客观准则对工具进行评估
考虑工具是否提供免费试用期
评估供应商或非商业性工具
针对工具使用的指导和培训，识别内部需求
评估培训需求，考虑使用工具人用的测试技能
考虑各种许可证模式的优缺点
根据实际情况估算成本-收益比
工具选择的主要原则
深入了解工具
试用工具，评估是否适合现有的工具和过程
建立标准
目标
完成选择和可行性研究后，通过试点项目开始工具引入
组织引入工具的试点项目
推广工具
调整和改进过程配合工具使用
提供培训和指导
定义工具的使用指南
实施实际使用中收集工具使用信息的方法
监督工具的使用和收益
为测试团队使用工具提供支持
收集经验教训
工具的成功因素
工具的有效使用
测试的支持工具
牢记（remember）
K1
理解（understand）
K2
应用（apply）
K3
更适合开发人员使用的工具 D
学习目标/知识认知级别
防止缺陷
验证是否实现了所有指定的需求
检查测试对象是否完成
建立对被测对象质量级别的信心
发现缺陷和失效，从而降低软件质量不足的风险
为利益相关方提供足够的信息以允许他们做出明智的决策，特别是关于测试对象的质量级别
遵守合同、法律或法规的要求，测试对象符合这些要求或标准
组件测试中，尽可能多的发现失效，以便尽早识别和修复潜在的缺陷
增加组件测试时的代码覆盖率
验收测试时，确认系统能够按照预期工作并且满足用户需求
验收测试为了给利益相关方提供关于在给定时间发布系统的风险信息
典型的测试目标
测试与调试
什么是测试
测试对成功的贡献
质量保证和测试
错误、缺陷和失效
缺陷、根本原因和影响
为什么需要测试
测试说明缺陷的存在，而不能说明缺陷不存在
穷尽测试是不可能的
测试的尽早介入可以节省时间和成本
缺陷的集群效应
杀虫剂悖论
测试活动依赖于测试周境
不存在缺陷的谬论
七项测试的基本原则
周境中的测试过程
测试计划
可以使用黑盒测试技术、白盒测试技术、基于经验的测试技术进行分析
歧义
遗漏
不一致
不准确
矛盾
典型缺陷
需求规格说明书
设计和实现信息
组件或系统本身的实现
风险分析报告
分析所考虑测试级别的测试依据
测试什么
测试分析
设计测试用例和测试用例集，并确定优先级
识别所需的测试数据以支持测试条件和测试用例
设计测试环境并识别所需的基础设施和工具
攫取测试依据、测试条件和测试用例之间的双向追溯性
主要活动
涉及使用到黑盒测试技术、白盒测试技术、基于经验的测试技术
如何测试
测试设计
开发并确定测试规程的优先级
根据测试规程和自动化测试脚本来创造测试套件
在测试执行进度表中，以促进有效测试执行的方式安排测试套件
构建测试环境，并验证一切所需都已经正确设置
准备测试数据并确保在测试环境中正确的加载
确认并更新测试依据、测试条件、测试用例、测试规程和测试套件之间的双向可追溯性
测试设计和测试实施任务通常结合在一起
我们是否已经有了运行测试所需的一切条件
测试实施
记录测试项或测试对象、测试工具及测试件的ID和版本
手动或者使用测试执行工具执行测试
将实际结果与预期结果进行比较
分析异常现象以确定他们可能发生的原因
根据实际观察到的失效报告缺陷
记录测试执行的结果（通过、失败或阻塞）
作为对异常现象采取行动的结果，或者作为计划要测试的一部分，重复测试活动
确认并更新测试依据、测试条件、测试用例、测试规程和测试结果之间的双向可追溯性
测试套件按照测试执行进度表运行
测试执行
检查是否所有的缺陷报告已关闭，为执行测试结束时仍未解决的缺陷，是否已创建需求变更或产品待办事项
创建测试总结报告，并将信息转达给利益相关方
最后确定并归档测试环境、测试数据、测试基础设施以及其他相关测试件，以便以后重复使用
将测试件移交给维护部门、其他项目团队和/或其他可以从使用测试件中获益的利益相关方
从已完成的测试活动中，分析所获得的经验教训来确定以后迭代、版本和项目所需的变更
使用收集到的信息来改进测试过程的成熟度
测试结束
测试过程主要的活动
测试活动和测试任务
测试工作产品
分析变更的影响
测试的可审计
符合IT管理标准
提高测试进度报告和测试总结报告的易理解性，包括测试依据中元素的状态
测试依据和测试工作产品之间的可追溯性
测试过程
心理学和测试
测试和开发的思维方式
测试心理学
软件测试基础
验证：针对过程
确认：针对结果
验证和确认的思想
顺序模型
包含全部增量的内容
自动化方式，迭代增加回归
回归测试重要性
迭代-增量模型
软件开发和软件测试
必须根据项目周境和产品特性来选择和调整
可能需要合并或重组测试级别和/或测试活动
模型本身会组合起来
系统产品的风险不同（复杂或简单项目）
许多业务单元可以使项目或程序的一部分（顺序开发和敏捷开发的结合）
一个产品交付市场的时间短（合并测试级别或测试级别中结合不同测试模型）
软件开发模型必须适应周境的原因
周境中的软件开发生存周期模型
软件开发生存周期模型
降低风险
验证组件功能和非功能性为是否符合设计和规定
建立对组件质量的信心
发现组件中的缺陷
防治缺陷遗漏到更高的测试级别
详细设计
代码
数据模型
组件规格说明
依据
组件、单元或模块
代码和数据结构
类
数据库模块
对象
功能不正确
数据流问题
代码和逻辑不正确
典型缺陷和失效
通常由开发人员执行，也可以是测试人员
检查单一的软件组件
TDD测试驱动
组件测试
减少风险
验证接口功能和非功能行为是否符合设计和规定
建立对接口质量的信心
发现缺陷
防治缺陷遗留到更高的测试级别
组件集成测试
系统集成测试
不同级别的集成测试
软件和系统设计文档
序列图
接口和通信协议规范
用例
组件或系统级别的架构
工作流
外部接口定义
子系统
数据库
基础结构
接口
API
微服务
数据不正确、数据丢失或数据编码不正确
接口调用的顺序或时序不正确
接口不匹配
组件间通信失效
组件间未处理或处理不当的通信失效
关于组件间传递的数据含义、数据单位或数据边界的假设不正确
系统间的消息结构不一致
系统间的通信失效
系统间未处理或处理不当的通信失效
关于系统间传递的数据定义、数据单元或数据边界的假设不正确
未遵守强制性的安全规定
典型失效和缺陷
检查这些组件的协调
验证系统的功能和非功能性为是否按照设计和指定的要求进行
确认已完成系统集成且系统按预期工作
建立对整个系统质量的信心
防治缺陷遗漏到更高级别或生产
系统和软件需求规格说明（功能和非功能）
史诗和用户故事
系统行为模型
状态图
系统和用户手册
应用程序
硬件/软件系统
操作系统
被测系统
系统配置和配置数据
计算不正确
不正确或者非预期的系统功能或非功能行为
系统内在控制流和/或数据流不正确
不能正确完整的开展端到端功能任务
系统在系统环境中不能正常工作
系统不能按照系统和用户手册中的说明进行工作
从用户的角度检查整个系统
确认系统是否完整且系统将按预期工作
验证系统的功能和非功能行为符合规范
用户验收测试
运行验收测试
合同和法规验收测试
Alpha和Beta测试
常见形式
业务流程
用户或业务要求
法律、法规、合同和标准
用例和/或用户故事
系统需求
系统或用户文档
安装规程
测试依据
完整集成系统的业务流程
恢复系统和热站点
操作和维护流程
表格
报告
现有和转换的生产数据
系统工作流程就不符合业务或用户要求
业务规则未正确实现
系统不满组合同或法规要求
非功能失效
增强用户对项目的信心
根据合同，与用户一道进行测试
验收测试
测试级别
所有测试级别上都能进行
多采用黑盒测试技术
功能测试
性能效率
可靠性
维护性
可移植性
易用性
安全性
兼容性
包括但不限于
非功能测试
单元测试的时候使用
白盒测试
只针对缺陷本身
对指定缺陷进行测试，不进行发散测试
确认测试
完全重复
周边影响法
指标达成法
选择性重复
测试策略
适合自动化
考虑测试风险和有效性
回归测试
与变更相关的测试
测试类型和测试级别
测试类型
功能增强
纠正和应急变更
环境变化
修改
换操作系统
迁移
可能需要进行回归测试
保留和归档
退役
维护的触发因素
维护的影响分析
特殊的测试级别，在系统交付之后，需要在多个级别上进行多种类型的测试
维护测试
软件开发生存周期中的测试
由静态测试检查的软件工作产品
静态测试的好处
需求缺陷
设计缺陷
代码缺陷
与标准的偏差
错误的接口规格说明
安全漏洞
测试依据的可追溯性或覆盖率的差距或不准确性
直接发现软件工作产品中的缺陷
缺陷所在的路径可能很少被执行或难以到达，静态测试可能付出更少的工作量就能找到缺陷
可用于提高软件工作产品的一致性和内部质量
静态测试
是在运行软件时识别由缺陷引发的实效
侧重于外部可见行为
动态测试
静态测试和动态测试的差异
静态测试基础
计划
评审启动会
独立评审（个人准备）
事件交流和分析
修正和报告
工作产品的评审过程
创建工作产品
修复缺陷
作者
制定评审计划
决定是否需要进行评审
分派人员、预算和时间
监督成本-效益
执行控制决策
经理（管理者）
保证评审会议的有效进行
不同观点之间的协调
评审成功与否的关键
促进者（主持人）
全面负责评审
决定哪些人参加评审，组织何时何地进行评审
评审组长
同事评审-》同行评审
可能是相关专家、项目工作人员、利益相关方、特定技术或业务背景人员
识别工作产品的潜在缺陷
可能代表不同视角
评审员
独立评审活动期间，收集发现的潜在缺陷
记录评审会议中新发现的潜在缺陷、未解决问题和决策
书记（记录员）
正式评审的角色和职责
可能不包含评审会议
小型、非正式的
可能记录评审结果
检查表是可选的
敏捷开发中非常普遍
附加目的：产生新的想法或解决方案，快速解决小问题
目的：检测潜在缺陷
伙伴检查、结对、结对评审
非正式评审
个人准备是可选的
会议主持通常是作者
必须指定书记
可能采用场景、演练或模拟的形式
生产潜在的缺陷记录和评审报告
可能从非正式到非常正式
附加目的：交换关于技术或风格变化的想法、参与者培训、达成共识
目的：发现缺陷、改进软件产品、考虑替代实施、评估与标准和规范的符合程度
走查
评审员是作者同行，或技术专家
需要进行个人准备
评审会议是可选的，最好是经过培训的促进人主持，通常不是作者
必须指定记录员，最好不是作者
进一步目的：评估质量和建立对工作产品的信心、产生新想法、激励和使作者能改进未来的工作产品、考虑替代实施
目的：获得共识、发现潜在缺陷
技术评审
最正式
遵循已定义的过程，基于规则和检查表，正式地记录输出
使用明确定义的角色，可能包括专门的朗读者
评审参与人是作者的同行或者相关的学科专家
使用已规定的的入口和出口准则
评审会有经过培训的支持人引导，不是作者
作者不能担任评审组长、朗读者或书记
收集度量并用于改进
进一步目的：激励和使作者能够改进未来的工作产品和软件开发过程、达成共识
目的：检测潜在缺陷，评估质量并建立对软件工作产品的信心，通过学习和根本原因分析防止未来出现类似缺陷
审查
评审类型
顺序阅读
依赖于评审员的技能
临时评审
检查表来自于经验
特定于所评审的工作产品类型
需要定期维护更新
基于检查表的评审
场景和演练的评审
希望使用检查表
基于视角
基于角色的评审
独立评审（个人准备）活动期间的评审技术
评审技术的应用
评审的成功因素
评审过程
ISTQB
收藏
收藏
0 条评论
回复 删除
下一页
