软件评测师第二版知识点记录

前言

本文为学习自用，内容仅供阅读参考，互相学习，共同进步。

不积跬步，无以至千里，不积小流，无以致江海，文章持续更新，与君共勉。

目录

前言

一、第一篇软件测试概述

1.第1章软件测试概述

1.1软件测试的背景

2.第2章软件测试基础

2.1软件测试的基本概念

2.1.1什么是软件测试

2.1.2验证与确认

2.1.3软件缺陷

---

24.01.05更新

一、第一篇软件测试概述

1.第1章软件测试概述

1.1软件测试的背景

·“软件工程”概念的提出，希望以工程化的原则、规范、方法，在技术和工具的支持下开展软件的生产，并保证软件的质量。

·为了保证软件的质量，软件测试成为了软件生产活动中必不可少且至关重要的工程活动。

·在软件测试兴起的初期，对于软件测试的目的有两种观点：

        （1）检验软件是否满足规定的需求，是否达到了预期的结果；

        （2）软件测试是为了发现错误而开展的一些活动及过程。

        总体上以保证软件产品的质量为目的，涵盖软件生产过程中更为全面的活动，同时兼顾成本及风险控制。

2.第2章软件测试基础

2.1软件测试的基本概念

2.1.1什么是软件测试

·针对软件产品的检测，称为软件测试。

·软件测试应当竭尽所能去发现尽可能多的错误。

·软件测试的目的为保证软件质量。具体来讲就是要保证软件或系统符合相关的法律法规、技术标准、应用需求，降低软件的产品风险及应用风险。

·软件测试的对象是软件，包含程序、数据和文档，但孤立的软件无法进行全面的测试，特别是动态的测试。

2.1.2验证与确认

·验证为Verification，确认为Validation，很多时候用V&V来代表验证与确认。

·验证——通过提供客观证据来证实规定需求已经得到满足。

·确认——通过提供客观证据来证实针对某一特定预期用途或应用需求已经得到满足。

        理解：验证就是说保证系统或软件的功能项和需求项一致，不论系统或软件的功能项结果是否正确。确认是保证系统或软件的功能项所得到的结果与需求中要求的保持一致。

2.1.3软件缺陷

·软件缺陷的含义十分广泛，人们尝尝将软件的问题（Problem）、错误（Error），以及因软件而引起的异常（Anomaly）、故障（Fault）、失效（Failure）、偏差（Variance）等均称为软件缺陷。

·IEEE729-1983对缺陷的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

·国家标准GB/T32422-2015《软件工程 软件异常分类指南》将缺陷定义为：工作产品中出现的瑕疵或缺点，导致软件产品无法满足用户需求或者规格说明书，需要修复或者替换。

·错误较多时候是软件缺陷的静态表现，是存在于软件中的一种缺陷。

·故障是软件缺陷的动态表现，是因为软件的缺陷造成软件工作时出现的问题。

·失效是软件因缺陷而导致的后果。

·缺陷产生阶段及比例，需求分析阶段引入的缺陷通常超过40%，设计阶段引入的缺陷在30%以上，编码产生的缺陷低于30%。

·一般而言，在软件工程活动中，缺陷从产生到发现的间隔时间越短，修复的代价越小，但缺陷从一个工程阶段跨入后一个工程阶段时，修复的代价将以指数级增长。

·软件工程活动中要努力做到缺陷早发现早排除，对应的测试活动就不能是编码完成之后的一个阶段性工作，而是贯穿软件工程的各个阶段，力争通过测试尽早地发现缺陷。

·在国家标准GB/T32422-2015《软件工程 软件异常分类指南》中定义软件异常为：从文档或软件操作观察到偏离以前验证过的软件产品或引用的文档的任何事件。

·问题可能由失效引起，失效由故障引起，而故障是软件缺陷的子集。

·缺陷的优先级：紧急、高、中、低、无。（对应书中P16表2-1）

·缺陷的严重性：阻塞、严重、一般、轻微、可忽略。（对应书中P16表2-2）

24.01.08更新

2.1.4测试与质量保证

·质量保证：ISO8402:1994中定义为“为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”；美国质量管理协会（ASQC）的定义为“QA是以保证各项质量管理工作实际地、有效地进行与完成为目的的活动体系”

·软件质量：GB/T25000.1-2021《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第1部分：SQuaRE指南》对软件质量的定义为“在规定条件下使用时，软件产品满足明确的或隐含的要求的能力”

·产品质量模型和使用质量模型：GB/T2000.10-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第10部分：系统与软件质量模型》定义为：（1）产品质量模型将质量属性划分为八个质量特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性，每一个特性由相关的若干子特性组成；（2）使用质量模型包含了与系统交互结果有关的五个特性：有效性、效率、满意度、抗风险和周境覆盖，其中满意度、抗风险和周境覆盖还个字包含了一些特性。

·软件测试更多的表现为技术性活动，而软件质量保证则是管理性活动特征更明显。

2.1.5测试用例

·软件测试应该是有计划有组织的活动，软件是一种逻辑产品，对其开展测试可能是存在“组合爆炸”的，引测不能随心所欲地进行。

·测试设计必须包括对全部测试用例（Test Case）的设计。

·测试用例：国家标准GB/T25000.51-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》的定义：为某个特定目标（例如，为演练具体的程序路径或验证对特定需求的依从性）而开发的输入、执行条件以及预期结果的集合。

·测试用例定义要点：（1）测试用例是测试人员针对具体目标设计或开发出来的，有非常强的目的性；（2）测试用例将体现软件的某一个具体运行实例或场景，包括输入的测试数据、执行条件、逻辑过程以及预期的逻辑结果等；（3）测试用例需提供准确的判定准则，即依照该用例实施测试获得实际结果时如何判定。

·与测试用例相似的是测试脚本（Test Script）,它可以被看成是测试工具执行的测试用例，但而知是有很大的差异的。测试脚本通常是指一个特定测试的可以被自动化工具执行的一系列指令，脚本可以在工具中通过录制测试操作生成，也可以使用脚本语言直接编写。

2.1.6测试策略

·从方法论的角度看，软件测试策略可以划分为：基于分析（如风险分析、需求规格分析）的策略、基于模型（如业务模型、软件质量模型、系统性能演化模型）的策略、基于标准规范（如GB/T25000.51标准、软件验收标准）的策略以及基于自动化的回归测试策略等等。

·测试策略的输入包括如下方面：

测试所需软硬件资源的详细说明。

针对测试和进度约束，需要的人力资源的角色和职责。

测试方法、测试标准和完成标准。

目标系统的功能性和非功能性需求、技术指标。

系统局限（即系统不能够满足的需求）等。

·测试策略的输出包括如下方面：

已批准或审核的测试策略文档、测试用例、测试计划。

需要解决方案的测试项目。

·制定测试策略的过程为：

确定测试的需求。需要注意以下几点：（1）测试需求必须是可观测、可测评的。（2）软件需求与测试需求以及测试用例不是一对一关系。（3）测试需求可能有许多来源。

评估风险并确定测试优先级。为了确定测试工作优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。

确定测试策略。一个好的测试策略应该包括：实施的测试类型和测试目标、实施测试的阶段、技术、评估测试结果和测试是否完成的标准、对测试工作存在影响的特殊事项。

24.01.10更新

2.2软件测试的原则

·溯源性原则：不同阶段的测试有不同的阶段性目标，但汇集起来后的总目标是保证软件质量，这主要通过对需求的符合性验证和确认（V&V）来体现，因此测试应当溯源到原始需求，而不是仅仅只盯着眼前。

·工程性原则，测试不是某一个阶段的活动，而是贯穿软件生产的各阶段，需要以工程化的四项和方法来组织和实施。按照2.1.3节中对缺陷修复代价的分析，需尽早按照计划开展测试，甚至进行预防性测试，以避免测试延迟带来的巨大代价。

·独立性原则，应当避免开发工程师测试自己的程序，自己测试自己的程序会受到定势思维和心理因素的影响，测试质量将大打折扣，企业应设立独立的测试工程师岗位或测试部门去承担测试工作。有一些大规模的企业在遵循独立性原则时也会注重交叉性，即可能会在不同的项目中互换开发工程师和测试工程师，这有利于开发和测试质量的提高。需要注意到是，长时间的合作可能造成测试与开发的同化，从而慢慢丧失测试的独立性原则，应努力避免。

·合理性原则，对软件进行完全测试是不可能的，给予有限的时间和有限的资源，无法对软件开展穷举式的测试。基本规律是测试成本与测试强度成正比，遗留缺陷与测试强度成反比，因此正确的策略是在质量要求和测试强度之间寻找合理的结合点，获得最优的测试效费比，避免测试不足和过度测试。这需要合理地设定测试的终止条件。

·不完全性原则，不管强度有多大，测试都不能暴露全部的缺陷，这是由测试自身决定了的。测试能做的是尽可能多地发现错误，但不能证明软件不再包含错误。因此，任何人或者机构对软件测试后的评价只能描述为“未发现错误”，而不能描述为“没有错误”。

·相关性原则，基于大量的测试统计和分析，人们发现一个软件（模块）中被找到的缺陷越多，则这个软件（模块）中残留的缺陷也越多，或者说缺陷常常有聚集现象。这个原则则提醒测试工程师对暴露错误多的模版应该加强测试。

·可接受性原则，测试的直接目标是发现软件缺陷，但更进一步的目的是修复发现的缺陷，然而修复缺陷是有代价的，因为时间或修复风险等方面的原因，已发现的缺陷不一定全部修复。在各方可以接受的前提下，可以允许某些缺陷遗留在软件中。当然这并不表明不披露易发现的缺陷，而应该交给由恰当的人员或会议进行决策。

·风险性原则，测试虽然是为了降低或化解软件对的质量风险，但必须认识到测试本身也是有风险的。鉴于上述的测试合理性原则，测试工作实际上是对软件进行采样测试，采样必然存在风险。这需要在做测试设计及构造测试用例时考虑如何规避和减少风险。同时，在一些测试（特别事宜交付投产的系统的升级、补丁测试）中，存在影响软件正常工作甚至中止服务的风险，这需要测试团队做好充分准备，开展风险评估，明确风险化解的有效方法，然后才能实施测试。

24.01.11更新

2.3软件测试模型

2.3.1V模型

·软件测试的V模型对应于开发的瀑布模型。瀑布模型将软件的开发明确地划分为需求分析、概要设计、详细设计、编码和测试等阶段，需要在完成前一阶段的工作后才能进入下一阶段，因此测试成了一个阶段性的工作，是最为典型的V&V活动。（P22 图2-1）

·在V模型中，测试活动对应于瀑布模型的每一个工程阶段，即单元测试对应编码、集成测试对应详细设计、系统测试对应概要设计、验收/交付测试对应需求分析。传统的测试划分就是因此产生，这就是V模型的重要贡献。

·V模型的局限性，他把测试标定位软件工侧灰姑娘的一个阶段性活动，而是编码结束之后才开始的活动，启动时间太晚，不符合尽早开始测试的原则。

2.3.2W模型

·W模型是对V模型的一个重要改进，充分体现了今早开展测试的原则，并将V模型中一发现缺陷为目标上升为保证软件质量为目标。（P23 图2-2）

·W模型实际上是两个V的叠加，一个V描述开发过程，另外一个V描述测试过程。开发过程的下降依然是需求分析、概要设计、详细设计和编码，测试过程的上升边也依然是单元测试、集成测试、系统测试以及验收/交付测试，但测试的起始时机不再是编码结束之后，而是从需求分析时开始，且与开发的每一个阶段活动同步进行，通过适时的评审，可以尽早发现和处理软件过程中的缺陷，降低缺陷修复的代价，保障产品各生产阶段的质量，从而更充分地保证最终软件的质量。

·显然W模型优于V模型，它体现了更多的软件测试原则。W模型中测试分布于软件过程的每一个阶段，与开发的同步也可以第一时间生成测试的各类文档，从而加快后期测试的进度。

·同时W模型也表明，测试的对象不仅仅只是程序，还包括各个阶段的文档和数据，因此对软件的验证和确认活动事实上也很早就开始了。

·W模型的局限性，高度依赖于开发的瀑布模型，活动具有明显的串行特征。事实上，即使是采用瀑布模型开发的软件，也不一定是如此清晰的串行化，而是存在大量的交叉活动，更不用说采用快速开发或敏捷开发方法的软件了，因此W模型不能适用于所有的软件项目。

2.3.3H模型

·H模型吧测试活动从软件开发过程中独立出来，在软件过程的任何一个时间点上，只要测试条件满足即可开展测试。（P23 图2-3）

·测试的流程与其他流程是并行的。H模型也更充分地反馈了每一个测试的完整活动，包括测试准备及测试执行。

2.3.4敏捷测试模型

·敏捷测试员与敏捷开发。当前敏捷开发是一种比较流行的方法，该方法以用户的需求进化为核心，以迭代、循序渐进的方式进行软件开发，主张简单、拥抱变化、递增、快速反馈等原则。敏捷测试时敏捷开发的组成部分，需要与开发流程良好融合。（P24 图2-4）

·敏捷测试在整个敏捷开发过程中，需要与项目的其他人员甚至用户保持紧密协作，时刻关注需求变化并实施测试，已提现测试的时效性和适应性，这对测试人员有比较高的能力要求。

·其他软件测试模型:TMMi测试成熟度模型集成、TPI测试过程改进、CTP关键测试过程、STEP系统化测试和评估过程等模型。自行查阅具体内容。