【定义类】三软件测试工程师-526互联

第一部分软件测试概述

软件测试概述——内容概要

软件测试概要

一：软件与系统工程领域标准

2020.4.28，发布软件与系统工程领域5项国家标准，分别是GB/T38634.1~ GB/T 38634.4， GB/T 38639。

 GB/T 38634：适用于各个企业、测评机构规范软件测试过程，建立适合自己情况的软件测试管理和执行能力。其中第1部分规定了软件测试的通用概念；第2部分详细说明了软件测试过程模型；第3部分规定了测试过程中产生的测试文档的模板和实例；第4部分规定了测试过程中使用的软件测试技术。
 GB/T 38639：规定了软件组合测试方法的测试对象、输入预处理、组合强度、种子组合、约束条件表示、组合测试过程以及组合测试输入输出表示。组合测试方法适用于受多因素影响的软件系统在保证测试充分性的前提下，有效地减少测试用例的数量，提升测试效率，降低测试成本。

2021.3.9，发布系统与软件工程性能测试方法标准，标准号为：GB/T 39788-2021。

 GB/T 39788-2021 ：规定了性能测试标准过程、性能测试需求模型、性能测试类型等内容。

38634↓

二：25000的八个质量特性

依从性：现定的标准复核情况

三：软件测试定义

 软件测试（IEEE定义）

 使用人工或者自动的手段来测试软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

 软件测试必要性（38634

 决策者需要有关测试项质量特性的信息;
 被测项并不总是达到预期效果;
 被测项需验证;（验证有现成的依据文档
 被测项需确认;（确认是否符合某种需求[用户需求]）
 被测项的评价需贯穿整个软件与系统开发生存周期。（最晚需求评审测试要参与）
 尽可能多地发现软件中的缺陷；（在发布之前发现测试项的缺）
 检查软件系统是否满足规格说明/用户的需求；（并减轻由产品质量不足带给相关利益方的风险）
 为软件质量评价提供依据（提供有关测试项的质量信息以及与测试项测试数量相关的任何残余风险）；
 确保软件符合行业标准；
 为软件开发过程的改进提供支持。

 软件测试的主要对象

 文档；

（需求文档、设计文档、用户手册、配置文档等）

 程序；
 数据。

四：对软件测试认识的偏差

偏差一：调试等同于测试，没必要进行测试。

 测试与调试的主要区别：

 目的不同（检错和排错）；
 任务、指导方法不同（测试从已知条件开始，使用预先定义的规程并且有可预知的结果；调试的开始条件可能不可知，结果不可预见）；
 操作者不同（测试一般由非程序设计人员完成；调试常常由程序设计人员完成）。

偏差二：可以对程序进行完全的测试。

 无法实现的原因

 所需测试的数量巨大（无法穷举）；
 无法保证测试环境100%满足测试要求；
 没有足够的资源彻底完成软件测试（时间、人员、设备等）。

偏差三：测试后的软件没有缺陷。

 无法实现的原因

 无法通过测试确信测试依据文档100%正确；无法确信测试人员完全理解了软件；
 无法确信测试系统(或环境)的正确性。
 在资源制约和技术限制的条件下，无法保证找到软件中所有的缺陷；

偏差四：测试发现的问题越多，剩下的问题就越少。

 原因

 缺陷率水平与开发能力、复杂性等存在关联。
 发现问题越多地方, 潜在的问题也更多。缺陷存在聚集效应，适用于80-20定律；(冒烟测试）

 思考：发现问题少就是无效测试？

偏差五：测试是“silver bullet”（万金油），能够解决一切软件质量问题。

 测试不是“silver bullet”，它具有有效范围，它不能替代其它

软件工程方法的作用。

软件测试方法

软件测试方法 - 按是否需要内部代码信息

黑盒测试& & 白盒测试

 黑盒测试像中医：使用望、闻、问、切
 白盒测试像西医：使用X光、CT扫描
 目的都是发现病人的病症

黑盒测试方法

 黑盒测试/基于规格说明的测试：

 不涉及程序结构，把程序看成黑盒子
 依据需求规格说明生成测试需求和用例
 某些代码段得不到测试，需要用白盒测试加以补充

黑盒测试的优点

 黑盒测试是在程序或软件界面上进行测试，相比白盒测试，主要有三个优点：

 简单，无需了解代码细节，测试效率较高；
 黑盒测试与软件如何实现无关，如果编码实现发生变化，黑盒测试用例仍然可用；
 用例设计可以与软件的实现同时进行，加快了软件测试与开发的速度。

黑盒测试的缺点

只能找到缺陷，难以查找错误的具体原因和位置；（不如白盒测试）
没有清晰的需求文档，测试用例很难被设计；
相比白盒测试，测试用例产生遗漏或冗余的可能性大大增加

白盒测试

 白盒测试属于代码级测试。一般用在单元测试和集成测试阶段。
 白盒测试可以借助白盒自动化测试工具去完成测试。在国内，白盒测试通常需要软件开发人员支持进行。

白盒测试优缺点

 优点

 迫使软件测试人员深入到程序内部进行测试，易于定位错误的
原因和具体的位置；
 检查代码中的每条分支和路径，进行较彻底测试；
 揭示隐藏在代码中的错误，如：内存泄漏、数组越界等等；
 优化代码，如：去掉冗余代码，规范代码（命名、注释等）。

 局限性

 很难查出程序中设计的缺陷，如遗漏了某些功能或业务；
 时序问题、中断相关的缺陷
 可能发现不了一些数据敏感性错误，如边界值很难考虑全面。
 很难查出程序中兼容性、易用性等问题；

黑盒测试和白盒测试的结合

 白盒测试是代码级测试，测试员需要深入了解代码的具体实现。通过白盒测试，测试员不仅可以找到代码级的缺陷，像内存泄漏、数组越界、空指针误用、代码不可达、代码规范性等等缺陷，还可以通过代码深入了解系统的功能、性能等，从而设计出高效的测试用例。
 黑盒测试可以从宏观上把握系统，全面测试系统的功能，并且测试周期短，测试人力成本低。
 在实际的测试过程中，最好采用黑白盒结合的策略，即测试员从整体上把握系统的功能和性能，又能在一定程度上了解软件的实现细节，设计出高效的测试用例。

软件测试方法 - 按照执行方式分类

 静态测试

 不动态执行程序代码，而寻找程序代码中可能存在的缺陷或评估程序代码的过程。

 动态测试

 需要运行测试项的测试。实际运行被测试程序，取得程序运行的真实情况和动态情况，进行分析

静态测试特征

 可以由人工进行, 充分发挥人的逻辑思维优势；（如代码走查、审查）
 可以借助软件工具自动完成部分工作, 提高测试的一致性和效率；（静态分析工具）
 对测试环境的要求较低；（最多编译下）
 测试成果取决于测试人员的能力和态度。

静态测试类型

 需求(文档）或设计评审/审查；921、38634
 代码质量度量；
 静态代码分析。
 代码审查/走查；

动态测试过程

动态测试特征

 使用测试用例运行程序，取得程序运行的真实情况
 生成测试用例、分析测试结果工作量大
 动态测试的关键在选择测试用例，测试的质量依赖于使用的测试数据；（数据充分性、代表性）
 主要包括黑盒测试和白盒测试

软件测试方法 -按测试手段分类

 手工测试
 自动化测试

 自动化测试是计算机代替人进行软件测试的技术，

即利用测试工具来开展和实施测试。

软件测试方法 -按开发过程分类

 按照开发过程，分成四种测试方法：

 单元/组件测试
 软件集成测试/部件测试
 软件配置项测试（文档分开？？？？主要测试内部功能和外部接口，配置项外部接口是一部分，）
 软件系统测试

 从单元测试到系统测试，是测试对象是由小到大的过程，也叫四个测试级别

软件测试级别

与软件开发过程相适应

 单元/组件测试；
 集成测试；
 软件配置项测试；
 系统测试

用户需求--------------------------验收测试

↓ -------------------------- ↑

系统需求分析---------------------配置项测试和系统测试

↓ -------------------------- ↑

概要设计--------------------------集成测试

↓ -------------------------- ↑

详细设计--------------------------单元/组件测试

↓ -------------------------- ↑

→ 编码 →

软件测试级别设置建议

 军工企业常用测试级别

 单元测试、集成测试、配置项测试、系统测试；

 非军工企业常用测试级别

 单元测试、集成测试、系统测试；

 三方测试机构常用测试级别

（确认测试？？）单元测试、集成测试、确认测试。

软件测试过程

软件测试过程模型-W模型

W模型：尽早、全面、全程。

软件测试过程模型 - H模型

 H模型：独立、灵活

软件测试一般流程

1. 测试策划

（设计评审；测试需求分析；测试计划设计等）

2. 测试设计

（测试用例编写、测试脚本开发等）

3. 测试执行

（搭建测试环境、准备测试数据、执行测试用例、测试执行记录、缺陷处理与回归测试等）

4. 测试总结

（测试报告编写、测试总结、文档归档等）

软件测试完成准则

 当时间用光时；
 当继续测试没有发现新的缺陷时；
 当测试的回报很小时；
 当达到所要求的覆盖时；（动态单元、集成）
 当所有发现的缺陷都已经清除时。

软件测试管理

测试组织管理

 独立性级别

 开发人员的测试；
 专职测试人员的测试；（开发部的测试人员）
 专职测试团队的测试； (测试部)
 用户的测试；（验收测试）
 独立机构的测试。（第三方测试）

 组织结构与独立性级别匹配

测试需求管理-测试需求分析

 任务

 依据收集的原始需求，明确测试范围、测试类型和测试重点等，编制测试需求。

 输入

 需求规格说明书、需求评审记录等测试需求分析依据文档；
 同类产品历史遗留问题。

测试需求管理-测试需求技术要求

 充分性：测试需求必须充分的覆盖软件需求所有的功能性要求和非功能性要求，不能有遗漏。
 准确性：测试需求当中的每一项内容都必须是描述清楚的，且正确地反应了测试任务和用户的要求。
 可追溯性：从测试需求可向上回溯到原始需求，向下追踪到测试用例。
 一致性：测试需求中各部分内容的描述是一致的，不存在相互矛盾的地方。
 可行性：每一项测试需求在已有的条件下都是可以测试、可以实施的，可以作为编写测试用例的依据。

测试需求管理-测试需求分析步骤

1. 阅读需求规格说明书等测试依据文档，明确测试的内容和测试类型；
2. 从需求中提取测试项，对测试项进行细化和分解，形成可测试的测试要点；
3. 针对测试要点确定产品的质量要求，对每条质量要求分析确定出不同的测试内容，形成测试项说明；
4. 找出用户关注点，明确验收关键指标，制定测试的重点，确定测试项的优先级；
5. 编制测试需求文档。在编制测试需求时，优先复用已有测试需求库中的测试项，然后再补充其它的新的测试项。

测试需求管理-测试需求变更管理

测试缺陷管理

 常见缺陷分类（不同企业分类项可能不同）

 按缺陷状态分：新建、拒绝、打开、已修改、重新打开、已关闭；
 按严重程度分：关键、重要、一般、建议等；
 按测试类型分：文档审查、代码质量度量、静态代码分析、动态单元测试、集成测试、功能测试、性能测试、界面

测试、接口测试、安全性测试等。

包含缺陷状态的软件缺陷处理流程（举例）

 假设项目组包含四种角色，分别是：
测试经理、测试人员、开发经理和开发人员。

 测试人员针对程序中的缺陷(BUG)编写软件缺陷问题报告单，将其指派给开发经理，并将缺陷的状态设置为“新建”；
 开发经理收到通知后，查看新建的缺陷。如果确认的确是一个缺陷，开发经理就将这个缺陷指定给某位开发人员处理，并将缺陷的状态改为“打开”。如果发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作缺陷的时候，开发经理将这个缺陷返回给测试经理，并将缺陷的状态设置为“拒绝”；
 开发人员收到通知后，查看并处理该缺陷。当开发人员进行处理并认为已经解决之后，就可以将这个缺陷的状态设置为“已修正”，并将其返还给测试人员；
 测试人员收到通知后，查看并验证缺陷修改情况。如果经过再次测试发现缺陷仍然存在，测试人员将缺陷再次传递给开发人员，并将缺陷的状态设置为“重新打开”。如果测试人员经过再次测试确认缺陷已经解决，就将缺陷的状态设置为“已关闭”；
 如果测试经理收到某缺陷被拒绝通知，验证该缺陷，如果确实不能算作缺陷，关闭缺陷，将缺陷状态设置为“已关闭”。如果认为的确是一个缺陷，修改缺陷描述，并将其重新指派给开发经理，并将缺陷的状态设置为“新建

缺陷状态变化图