ISTQB-FL软件测试基础学习笔记

什么是测试

识别典型的测试目标

对于任何给定的项目，其测试目标可以包括：

• 通过评估工作产品以防止缺陷，例如需求、用户故事、设计和代码。

绝大多数中小型企业将测试工作作为验收软硬件质量的其中一个环节，而忽略项目运行工作中的其他工作产品，如各项目文档，代码等。测试一般难以参与到前期的需求评估和设计阶段中，即便是召开需求评估的相关会议，测试也可能会因为平时工作鲜少直接接触客户，对客户需求，使用场景不了解而难以对需求的合理性，正确性做出建议和评价。有时测试甚至在提测之后才了解需求。看懂代码也是其中一个难点，这对测试的专业技能较高。这些原因导致了测试人员难以在前期介入并达到预防缺陷的测试目标。测试的左移能够降低修复缺陷的成本。

• 验证是否实现了指定需求。

这要求测试人员充分了解需求，并根据需求制定测试方案进行充分测试。

• 验证测试对象是否完成，并确认是否按照用户和其他利益相关方那样工作。

有未开发完成的测试对象提测和团队成员错误理解需求导致测试对象没有按照相关方期望的那样工作。

• 建立对被测对象质量级别的信心。
• 发现缺陷和失效，降低软件质量不足的风险。

缺陷和失效是不同的概念，但很多时候我们容易只关注失效，忽略缺陷。

• 为利益相关方提供足够的信息以允许他们做出明智的决策，特别是关于测试对象的质量级别。

比如，公司内部相关方觉得软件的抗弱网能力有些差，有两种方案可以优化，但不确定优化效果如何，需要测试针对每一种优化方案进行测试，以确定最终选取哪一种方案。

• 遵守合同、法律或法规要求或标准，验证测试对象是否符合这些要求和标准。
  在组件测试时，尽可能多地发现失效，以便尽早识别和修复潜在的缺陷可能是其中一个目标。而另一个目标可能是增加组件测试时的代码覆盖率。
  在验收测试时，确认系统能按照预期工作并满足用户需求可能是其中一个目标，而另一个目标可能是为利益相关方提供关于在给定时间发布系统的风险信息。

测试与调试的区别

执行测试可以发现软件缺陷引起的失效。
调试是分析和修复缺陷的开发活动。

质量保证（QA）和测试

质量管理包括质量保证和质量控制。
质量保证的关注点在于遵循正确的过程以使产品达到合适的质量级别，而质量控制涉及包含测试活动在内的各种支持达到适当质量级别的活动。

错误、缺陷和失效

人犯了错误，引入了缺陷，导致测试对象出现失效。
错误存在于非工作产品中，比如人压力太大、本身容易犯错、经验或技能不足等。
缺陷存在于工作产品中，可能是代码、文档，可能会也可能不会导致失效，但真实存在。
执行了存在缺陷的代码，可能导致失效，但失效也可由外部环境因素导致。

比如电磁场异常导致指南针失效。

缺陷、根本原因和影响

缺陷的根本原因是导致缺陷产生的最早的行为或条件。分析缺陷，找出根本原因，以预防此类缺陷再次发生。
这里涉及根本原因分析和过程持续改进概念

比如，某公司接到用户反馈，输入手机号后无法接受短信，导致无法注册。开发查看后发现是由于短信服务器欠费导致。于是建立了一个需求：短信服务器增加欠费告警机制。
但领导对此解决方式并不满意。为什么短信会欠费，是正常使用导致欠费还是异常使用导致欠费？于是问题移交给了高级测试员。
测试要求导出近期在平台上注册的手机号，发现手机号很有规律，类似15700000000、15700000001。发现根本原因是由于短信轰炸导致欠费。根本原因：公司的该网站注册功能未进行短信轰炸的相关防护。
解决方案：增加安全防护。

到此为止，根本原因分析已经完成。错误的根本原因导致不适当的解决方案，可能出现治标不治本的情况，或无益于解决问题。

此时，该测试员又提出，排查公司所有系统，确认是否存在该问题。开发进行排查后，发现公司其他平台也存在该问题，于是针对所有出现问题的平台都进行了修正。

到此为止，缺陷和修复工作由点及面，进行了过程持续改进。
这个案例中，问题的发现是在上线后用户使用阶段，该问题无疑非常严重，造成的影响和修复成本是相当大的。
如果结合上文提到的，以预防缺陷为目标，参与评估工作产品如需求、设计、代码，事情可能是这样的：

平台开发时，大家一起开会评估设计方案，测试发现开发对注册功能的设计缺少安全防护，提出可能出现短信轰炸的可能性，给公司造成损失。开发接收到建议，及时修改。

这样影响和修复问题的成本就会小很多了。测试左移的重要性毋庸置疑。

七项测试的基本原则

• 原则1 测试说明缺陷的存在，而不能说明缺陷不存在。

测试工作降低了软件中存在未发现缺陷的可能性，但不能证明软件的正确性。测试人员不必因为被其他人发现缺陷而羞愧，而应该将此视作一次改进机会，改进测试用例，改进测试场景。

• 原则2 穷尽测试是不可能的。

领导往往很希望做穷尽测试，简单来说，测得越多越好。然而进行穷尽测试是不可行的，除非是小型案例。应利用风险分析、测试技术和优先级确定工作量，而不是试图进行穷尽测试。

• 原则3 测试的尽早介入可以节省时间和成本。

测试的左移能够节省时间和成本，为了尽早发现缺陷，应在软件生命周期中尽早开展静态测试和动态测试。但实际上测试很少能做到在早期的介入。团队成员可能没有这个意识，及测试本身可能存在限制。

• 原则4 缺陷的集群效应。

通常在少数模块中包含了大部分在发布前测试中发现的缺陷，或者是造成大部分运行失效的原因。预测的缺陷集群效应或实际观察到的缺陷集群效应，应作为风险分析的重要输入，并进行集中测试。

• 原则5 杀虫剂悖论。

同一款杀虫剂用多了，虫子产生耐药性。多次重复同样的测试，终将不能再发生新的缺陷。故而测试用例和测试数据需要不断更改或增加新的测试用例。

• 原则6 测试活动依赖于测试周境。

测试在不同周境下是不同的，如敏捷项目中的测试不同于顺序软件开发生命周期中进行的测试。

• 原则7 不存在缺陷的谬论。

组织通常期望测试员能够运行所有可能的测试，发现所有可能的缺陷，但期望仅仅发现并修复大量缺陷就能保证系统的成功，是一个错误的信念。穷尽测试之下，仍然可能会产生出一个难以使用或无法满足用户需求和期望，或与其他竞品相比更差的系统。

测试过程

没有统一的测试过程，但一些常见的测试活动可组成一个测试过程。特定的测试过程取决于很多因素。一个测试过程中应该有哪些测试活动，可以在组织的测试策略中讨论。

测试活动和测试任务

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

• 测试计划
• 测试监督与控制
• 测试分析
• 测试设计
• 测试实施
• 测试执行
• 测试结束
  每个活动组由多个活动构成，每个活动可能由多个独立任务构成。

测试计划

测试计划包含的活动有定义测试目标、周境下达到测试目标的方法（如制定适当的测试技术和适当的测试任务，并制定满足截止期限的测试进度表）。根据测试监督与控制活动组的反馈可重新审议测试计划。

测试监督与控制

根据测试计划中定义的测试监督度量，对实际进度和计划进度进行持续性比较。
通过评估测试执行的出口准则来支持测试监督与控制活动。在测试进度报告中向利益相关方通报测试进度、包括偏离计划的情况和帮助决定结束测试的信息。

测试分析

测试分析是为了定义“测试什么”，哪些可测试，需要哪些相关的测试条件。
测试分析主要包括以下活动：

• 分析所考虑测试级别的测试依据，如需求规格说明、设计文档、组件或系统本身的实现、风险分析报告。
• 评估测试依据和测试项，以识别各种类型的缺陷，如歧义、矛盾、遗漏、不一致、不准确、多余的表述。
• 识别被测特征和特征集。
• 根据对测试依据的分析，并考虑功能、非功能和结构特征、其他业务和技术因素以及风险级别，界定每个特征的测试条件并确定其优先次序。
• 在测试依据的每个元素与相关测试条件之间获取双向可追溯性。
  在测试分析过程中，可使用黑盒测试技术、白盒测试技术、基于经验的测试技术，更精准和准确的定义测试条件。
  在测试分析过程中识别缺陷是一个重要的潜在收益，验证需求是否一致、表达是否正确和完整、需求是否满足客户期望。

测试设计

测试设计解决“如何测试”的问题。
测试设计主要包含以下活动：

• 设计测试用例和用例集，并确定优先级。
• 识别支持测试用例和测试条件的测试数据。
• 设计测试环境并识别测试用的基础设施和工具。
• 获取测试依据、测试条件、测试用例之间的双向可追溯性。

测试实施

测试实施解决“我们现在是否已经有了运行测试所需的一切条件”的问题。
测试实施主要包含以下活动：

• 开发并确定测试规程优先级，或创建自动化脚本。
• 根据测试规程和自动测试脚本来常见测试套件。
• 在测试执行进度表中，以促进测试有效执行的方式安排测试套件。
• 构建测试环境并验证设置正确。
• 准备测试数据并确保数据在测试环境中正确加载。
• 确认并更新测试依据、测试条件、测试用例、测试规程、测试套件之间的双向可追溯性。

测试执行

测试执行包括以下主要活动:

• 记录测试项或测试对象、测试工具及测试件的ID和版本
• 手工或者使用测试执行工具执行测试
• 将实际结果与预期结果进行比较
• 分析异常现象以确定它们可能发生的原因(例如，出现失效可能是由于代码中的缺陷，但也可能出现假阳性结果
• 根据实际观察到的失效报告缺陷
• 记录测试执行的结果(例如通过、失败、阻塞)
• 作为对异常现象采取行动的结果，或作为计划要测试的一部分(例如，执行修正后的测试、确认测试和/或回归测试)，重复测试活动
• 确认并更新测试依据、测试条件、测试用例、测试规程和测试结果之间的双向可追溯性

测试结束

测试结束包括以下主要活动:

• 检查是否所有的缺陷报告已关闭，为测试执行结束时仍未解决的缺陷，是否已创建需求变更或产品待办事项
• 创建测试总结报告，并将信息传达给利益相关方
• 最后确定并归档测试环境、测试数据、测试基础设施及其他相关测试件，以便以后重复使用
• 将测试件移交给维护部门、其他项目团队和/或其他可以从使用测试件中获益的利益相关方
• 从已完成的测试活动中，分析所获得的经验教训来确定以后迭代、版本和项目所需的变更
• 使用收集到的信息来改进测试过程的成熟度

测试心理学

1. 团队成员从合作而不是斗争的方式开展项目。
2. 强调测试的好处。
3. 以中性的、以事实为中心的方式去沟通测试结果和其他发现，而不应该指责。
4. 去理解其他成员的感受，确认他们是否存在态度消极及原因。
5. 确认其他成员已经理解你的表述，或确认你已经理解其他成员的表述。

开发容易认为测试工作是给他们增加解决缺陷的工作量，他们可能消极对待缺陷，出现明知有问题但不承认不修改，缺陷轻易标成won’t fix的情况。开发和测试可能认为自己是底层最受压迫的群体。追求更高更好的质量应该是团队中所有成员的共同目标。