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

本文主要是介绍ISTQB-FL软件测试基础学习笔记，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

什么是测试

识别典型的测试目标

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

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

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

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

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

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

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

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

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

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

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

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

测试与调试的区别

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

质量保证（QA）和测试

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

错误、缺陷和失效

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

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

缺陷、根本原因和影响

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

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

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

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

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

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

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

七项测试的基本原则

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

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

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

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

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

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

原则4 缺陷的集群效应。

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

原则5 杀虫剂悖论。

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

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

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

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

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

测试过程

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

测试活动和测试任务

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

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

测试计划

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

测试监督与控制

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

测试分析

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

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