【软件测试】第二章·软件测试的基本概念
🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏：🏀软件测试与软件项目管理_十二月的猫的博客-CSDN博客💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
1. 前言
2. 软件测试的基本概念
2.1 软件质量的内涵
2.2 软件缺陷的定义
2.3 软件缺陷的判断准则
2.4 软件缺陷的产生
2.4 软件缺陷的构成
2.5 修复软件缺陷的代价
3. 软件测试的分类
3.1 几种测试对比
3.2 静态测试和动态测试
3.2.1 产品评审
3.2.2 静态分析
3.2.3 验证与确认
3.3 主动测试和被动测试
3.4 黑盒测试和白盒测试
4. 软件测试的层次
4.1 单元测试
4.2 集成测试
4.3 系统测试
4.4 验收测试
5. 软件测试工作范畴
5.1 测试需求分析
5.2 测试策略指定
5.3 测试计划
5.4 测试设计
5.5 测试执行
5.6 测试结果和过程评估
6. 总结
1. 前言
考试前猫猫又开始更新考试科目了（也就是开始学了bushi）。本学期更新的科目有：
- 软件测试
- 软件项目管理
- 爬虫和Web数据管理
- 数据可视化
本系列【软件测试】将针对软件测试的基础知识进行拆分讲解，既是对自己学习的一次巩固也想为后面学习的猫友们提供一些帮助。如果大家有空可以点个免费的赞和收藏呀~~你的鼓励真的对猫猫很重要。
2. 软件测试的基本概念
- 软件质量
- 软件缺陷
- 缺陷的修复
2.1 软件质量的内涵
内涵： 软件产品具有满足规定的或隐含要求能力有关的特征与特征总和。
软件质量特征：功能、可靠、易用、效率、可维护、可移植。
软件质量特征的三层模型：
不同语境的质量：
2.2 软件缺陷的定义
缺陷就是质量的反义词，了解质量也就明白缺陷。
缺陷定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
2.3 软件缺陷的判断准则
- 需求规格说明书和其他需求、设计规范文档
- 竞争对手的产品
- 启发式测试预言
- 统计测试预言
- 一致性测试预言
- 基于模型的测试预言
- 人类预言
2.4 软件缺陷的产生
- 技术问题：算法错误、计算和精度问题、接口参数传递不匹配。
- 团队工作：沟通不充分，有误解
- 软件本身：文档错误，使用场合不合适
2.4 软件缺陷的构成
大部分的缺陷都是：需求和软件功能不匹配。
缺陷的构成（按频率排序）：需求 》 设计 》其他 》 代码
软件缺陷在不同阶段的分布：
2.5 修复软件缺陷的代价
缺陷带来的成本称为“劣质成本”。其非线性增长，不及时处理所带来的成本很高。
假如一个需求分析阶段的缺陷，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍， 在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是40～1000倍，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。
3. 软件测试的分类
- 按测试的对象或范围分类，如底层测试/单元测试、接口测试/集成测试、系统测试、业务层的验收测试等
- 按测试目的分类（测试类型），如功能测试、性能测试、可靠性测试、安全性测试、兼容性测试、回归测试等
- 按测试方法的分类分为：静态测试和动态测试、白盒测试和黑盒测试、精准测试、变异测试、蜕变测试、MBT等
3.1 几种测试对比
测试方法中按照是否执行被测软件可以分为静态测试和动态测试。静态测试包括测试需求、设计和代码，但是不执行被测软件。
按照测试人员是否需要主动发起测试还是等待接受测试结果可以分为主动测试和被动测试。
按测试人员是手工还是自动化测试可以分为手工测试和自动化测试。
按测试人员使用基于脚本测试还是设计测试用例测试分为脚本测试和探索式测试。
3.2 静态测试和动态测试
静态测试包括对软件产品的需求和设计文档、代码的评审，以及对代码的静态分析。
注意：管理评审和流程评审不属于静态测试，而是质量保证。
- 评审包括：互为评审、走审、会议评审
- 代码的静态分析主要采用工具进行，但是也存在人工的代码评审。
3.2.1 产品评审
软件产品评审包括：需求文档、设计文档和代码的评审。
产品评审的好处：通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂责的后期返工转化为前期的缺陷发现。
产品评审的目标：评审是对软件元素或者项目状态的一种评估手段，以确定其是否与期望的结果保持一致，并使其得到改进。
需求评审的标准：
- 正确性
- 完备性
- 一致性
- 易理解性
- 易测试性
- 易追溯性
设计评审的目标：
保证需求能在设计中得到准确和完整的表示，即保证系统架构设计和产品功能规格说明书的质量。
- 系统架构
- 可测试性
- 系统部署
- 设计规格说明书
3.2.2 静态分析
- 人工检测：人工检测偏重于编码风格、质量的检验，对设计、代码进行分析，有效地发现逻辑设计和编码错误。
- 计算机辅助静态分析：利用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。
通过编译器对程序进行语法、词法、依赖值等分析，可以发现程序存在的较为表面的错误。
3.2.3 验证与确认
Verification：Are we building the product right？是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性。
Validation：Are we building the right product？是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求。
3.3 主动测试和被动测试
主动测试：测试人员主动操作被测对象，如输入数据、发送请求等来驱动被测对象，从而验证被测对象的响应或输出结果。
被动测试：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行而获得系统运行的数据，然后进行分析
3.4 黑盒测试和白盒测试
黑盒白盒与静态动态的结合：
4. 软件测试的层次
软件测试分为四个层次，分布在软件开发的不同阶段：
- 单元测试：组件/模块/类/函数
- 集成测试：单元之间接口
- 系统测试：由单元构成的系统
- 验收测试：系统承载的用户业务
4.1 单元测试
- 单元测试针对程序系统中的最小单元---模块或组件进行测试，一般和编码同步进行。主要采用白盒测试方法，从程序的内部结构出发设计测试用例检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。通常要编写驱动模块和桩模块。
- 单元测试一般由编程人员和测试人员共同完成，而以开发人员为主。
- 单元测试包括代码评审，代码评审可以发现程序50%～70%代码的缺陷。
4.2 集成测试
集成测试，也称联调，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题。
4.3 系统测试
系统测试包括系统功能测试 和 系统非功能测试。
系统功能测试是基于产品功能说明书，针对产品所实现的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用。
系统非功能性测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件和数据等，在实际运行环境下验证系统的非功能性，包括：
- 性能测试
- 安全性测试
- 稳定性测试
- 兼容性测试
4.4 验收测试
验收测试主要有 Alpha 测试 和 Beta 测试。
验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样。
Alpha 测试是一种验收测试；在将最终产品发布给最终用户之前，执行以识别所有可能的问题和错误。Alpha 测试由作为组织内部员工的测试人员执行。主要目标是确定典型用户可能执行的任务并对其进行测试。
Beta 测试是由软件应用程序的“真实用户”在“真实环境”中进行的，它可以被认为是一种外部用户验收测试。这是将产品运送给客户之前的最终测试。来自客户的直接反馈是 Beta 测试的主要优势。此测试有助于在客户环境中测试产品。
5. 软件测试工作范畴
- 测试需求分析
- 测试策略指定
- 测试计划
- 测试设计
- 测试执行
- 测试结果和过程评估
5.1 测试需求分析
明确测试范围：了解哪些功能点需要测试，哪些功能点不需要测试。
明确测试优先级：哪些目标优先级高，哪些目标优先级低
5.2 测试策略指定
制定或选择更合适、更有效的测试方式、测试方法和技术等，其目的是为了以最低的时间或人力成本达到最大程度地揭示产品的质量风险、尽快完成测试等。
- 测试方式：手工方式与自动方式，静态方式与动态方式，基于脚本测试与探索式测试。
- 测试方法：黑盒测试与白盒测试，基于数据流还是基于控制流的方式。
- 测试过程：先测什么，后测什么，对测试阶段的不同划分。
5.3 测试计划
依赖于测试需求分析，和测试策略等结果
5.4 测试设计
测试设计是解决“如何测”的问题，可以分为测试总体设计和测试详细设计：
- 测试总体设计则主要指测试方案的设计、测试结构的设计。
- 测试详细设计主要是指测试用例的设计。
在测试方案的设计中，测试工作涉及的范围比较大，包括选择测试方法、明确测试策略、设计测试技术路线、选择测试工具和规划测试环境等。
5.5 测试执行
- 手工执行：基于详细设计的测试用例来完成测试，也可以在没有测试用例的情况下进行的探索式测试。
- 自动化执行：指采用测试工具来完成，一般都需要开发自动化测试脚本，然后工具执行脚本，在后续“单元测试与集成测试、系统测试和自动化测试框架”等各章会进行详细讨论。
脚本测试：
手工测试：
也就是设计测试用例进行的探索式测试。
5.6 测试结果和过程评估
- 测试结果评估：对测试结果进行分析，如分析测试覆盖率，以了解测试是否充分；也可以基于缺陷的趋势分析和分布分析，了解缺陷是否已收敛，以及基于缺陷来评估当前被测试的版本的质量。
- 测试过程评估：结合测试计划来进行评审，相当于把计划的测试活动和实际执行的活动进行比较，了解测试计划执行的情况和效果。
6. 总结
本篇文章作为【软件测试】系列的第二篇文章，主要用来帮助大家先与软件测试认识一下，见个面~~~后续将一一带大家和软件测试成为好朋友！
如果想持续关注【软件测试】和【软件项目管理】系列文章，可以订阅：
- 软件测试与软件项目管理_十二月的猫的博客-CSDN博客
如果想学习计算机其他方面的核心知识（都是猫猫的优质好文哦），可以订阅：
- 计算机网络_十二月的猫的博客-CSDN博客
- 软件工程与面向对象_十二月的猫的博客-CSDN博客、
- 操作系统与数据库_十二月的猫的博客-CSDN博客
- 编译原理_十二月的猫的博客-CSDN博客
- 算法启示录_十二月的猫的博客-CSDN博客
如果觉得本文对你有帮助，友友们可以点个赞，收个藏呀~
