05测试分类-CSDN博客

本文链接：https://blog.csdn.net/douyawen/article/details/149096090

1. 测试用例分类

软件测试是具有较高的复杂性，对于软件测试，可以在不同的角度进行为分类，使开发者在软件开发过程的不同层次、不同阶段对测试工作的更好执行和管理测试的分类方法。

好处：提高效率、便于管理和维护、确保覆盖面、支持自动化测试策略、资源分配、促进团队沟通、增强可追溯性。

2.按照测试目标分类

2.1 页面测试

**页面测试（UI测试，User Interface Testing）：**界面测试是对软件系统的用户界面（UI）进行检查和验证的过程，确保页面元素正常显示、功能可用、布局合理，并且符合用户的操作习惯和预期。

验证界面元素是否正确显示
确保操作流程顺畅
提升用户体验（UX）
保证界面在不同设备/浏览器上的一致性
发现潜在的易用性和可访问性问题

2.2 功能测试

**功能测试（Functional Testing）：**功能测试是通过模拟用户的实际操作行为，对软件的功能进行验证，确保每个功能模块在各种输入条件都能确定运行，并返回预期的结果。

验证功能是否符合需求文档
确保所有功能模块按设计运行
发现功能缺陷或逻辑错误
确认用户操作流程顺畅
覆盖正常和异常输入情况

2.3 性能测试

**性能测试（Performance Testing）：**是一种非功能测试，通过模拟真实用户行为或极端使用场景，来测试系统的响应时间、吞吐量、资源消耗、可扩展性等性能指标，以发现潜在的性能瓶颈或问题。

评估系统性能：测量系统在正常和峰值条件下的响应速度、处理能力等

发现性能瓶颈：找出影响性能的关键点

验证系统稳定性：确保系统在长时间运行或高压环境下不会崩溃

支持容量规划：为服务器配置、带块需求、并发用户数提供数据支持

优化用户体验：提升用户操作的流畅性和影响速度

2.4 可靠性测试

**可靠性测试（Reliability Testing）：**是一种通过模拟真实或极端使用环境，来评估系统在一定时间范围内无故障运行能力的测试方法。它关注的是系统稳定性、容错性、恢复能力和可维护性。

可靠性 = 正常运行时间 / (正常运行时间 + 非正常运行时间) * 100%

评估系统稳定性：验证系统在长时间运行下是否会出现崩溃或性能下贱
发现潜在故障点：找出可能导致系统中断或失败的关键组件或逻辑
验证容错机制：检查系统在出现错误时是否能够正确处理并继续运行
测试回复能力：在系统发生故障后，能否快速恢复正常服务
支持运维决策：提供数据支持容量规划、高可用部署、灾备放到等。

2.5 安全测试

**安全测试（Security Testing）：**是对软件系统的安全性进行评估的过程，目的是验证系统是否能够有效地防止未经授权的访问、使用、泄露、中断、修改或破坏，并确保敏感信息的安全性。

SQL注入（SQL injection）：验证应用程序是否能防止用户输入恶意SQL语句。
跨站脚本工具（XSS，Cross-Site Scripting）：测试网站能否防防御恶意脚本插入到网页中。
跨站请求伪造（CSRF，Cross-Site Request Forgery）：测试应用是否能阻止伪造请求。
暴力破解（Brute Force Attack）：尝试猜测秘密或其他认证凭据
会话管理（Session Management）：确保会话ID的安全性，防止会话劫持
加密存储（Encryption of Stored Data）：确认敏感数据在数据库中是机密存储的
传输层安全（TLS/SSL Security）：验证数据在网络上传输时是否经过适当的加密。

2.6 易用性测试

**易用性测试（Usability Testing）：**易用性测试是一种通过观察真实用户或模拟用户操作来评估产品是否易于使用的过程。它不仅仅是“能否完成任务”，更关注的是“用户完成得有多顺畅、对愉快”。

易用性在 ISO25020 标准中指容易发现，容易学习和容易使用。

易用性包含七个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、正确性和实用性。

符合标准和规范（Compliance With standards and regulations）：系统是否遵循行业或国家相关的设计规范、可用性标砖等。
直观性（Suitability and clarity）：用户能否直观理解页面元素和操作方式，是否需要额外培训即可完成任务。
一致性（Consistency）：在不同页面、模块之间，交互方式、视觉风格、术语表达是否保持一致，减少用户认知负担。
灵活性（Flexibility）：是否支持不同用户的使用习惯？是否允许个性化设置？是否适用于不同的技能水平？
舒适性（Operability）：操作是否流畅？流畅是否自然？界面布局是否合理？是否避免不必要的复杂操作？
正确性（User error protection）：是否具备防止用户犯错的设计？如输入校验、确然提示、撤销功能等。
实用性（Accessibility）:是否满足所有用户群体的需求，包括残障人士？是否符合可访问性标准？

3. 按照执行方式分类

3.1 静态测试

**静态测试（Static Testing）：**涉及对软件工程中产生的各种工件进行评审和分析，包括需求文档、设计文档、源代码等，以确保这些工件符合规范满足预期目标。与动态测试不同，静态测试不需要执行程序本身。

早期问题发现
提高代码质量
确认一致性
降低风险

3.2 动态测试

**动态测试（Dynamic Testing）：**是指在软件开发过程总，通过向被测系统提供特定输入并运行该系统，然后比较实际输出与预期输出之间的差异来检查错误的过程。它关注的是 “系统做了什么”，而不是仅仅停留在设计或代码层面

验证功能正确性
评估性能指标
发现缺陷和漏洞
保证兼容性和稳定性

4.按照测试方法

4.1白盒测试

**白盒测试（White Box Testing）：**主要关注的是软件内部的逻辑结构和实现细节，而不是仅仅依赖于外部的行为表现。测试人员通常需要具备一定的编程知识，以便能过编写测试用例来覆盖尽可能多的代码路径。

在这里插入图片描述

白盒测试主要用于单元测试阶段

先执行静态设计用例的方法，在再执行动态设计测试用例的方法

设计用例一般使用路径覆盖测试，重点模块追加使用逻辑覆盖方法

动态测试方法主要包含六种测试方法：语句覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

语句覆盖（Statement Coverage）：确保程序中的每一条可执行的语句至少被执行一次。
条件覆盖（Condition Coverage）：要求每个布尔表达式的每个字条件都至少有一次为真和一次为假。
判定/决策覆盖（Decision/Branch Coverage）：确保每个控制流结果中的真假分支都被执行至少一次。
判定/条件覆盖（Decision-Condition Coverage）：结合了判定覆盖和条件覆盖的要求，即不仅覆盖所有的判断，还要覆盖每个条件的所有可能取值。
条件组合覆盖（Multiple Condition Coverage）：要求测试所有条件的所有肯能组合
路径覆盖（Path Coverage）：覆盖程序中所有啃的执行路径。

4.2 黑盒测试

黑盒测试（Black Box Testing）：也称数据驱动测试，主要依赖于软件的需求规格说明书和功能描述，通过提供各种输入并检查实际输出是否符合预期来发现测试。不需要了解代码的具体实现细节，黑盒测试通常由测试工程师执行。

黑盒测试的测试方法：等价类划分、边界值分析、决策表测试、因果图、场景法、错误猜测法

优点：

无需了解内部实现
从用户角度出发
易于理解和实施

缺点：不可能覆盖所有代码

4.3 灰盒测试

**灰盒测试（Gray Box Testing）：**介于黑盒测试与白盒测试之间的测试策略，它要求测试人员对被测系统的内部工作原理有一定的了解，但不需要安全掌握所有的细节。

提高效率、增强覆盖范围、优化资源利用

5. 按照测试阶段分类

5.1 单元测试

**单元测试（Unit Testing）：**是对软件中的最小功能单元进行验证的过程，主要用于白盒测试方法。这个“单元”可以是一个函数、一个方法、一个类或一个模块。

测试阶段：编码后或者编码前（TDD）

测试对象：最小模块

测试人员：白盒测试工程师或开发工程师

测试方法：白盒测试

测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

5.2 集成测试

**集成测试（Integration Testing）：**也称联合测试（联调）、组装测试，主要目的是验证不同模块不同模块或组件之间的接口是否正确工作，并确保它们能过作为一个整体协同用作。检测模块间的数据传递、接口兼容性以及系统架构设计有效性等问题。

测试阶段：一般单元测试之后进行

测试对象：模块间的接口

测试人员：白盒测试工程师或开发工程师

测试依据：单元测试的模块 + 概要设计文档

测试方法：黑盒测试与白盒测试相结合

内容模块：模块之间数据传输、模块之间功能冲突、模块组装正确性、全局数据结构、单模块缺陷对系统的影响。

5.3 系统测试

**系统测试（System Testing）：**属于动态测试盒黑盒测试的范畴。是软件开发完成后，在真实或模拟的运行环境中对整个进行全面测试的过程。

测试阶段：集成测试通过之后

测试对象：整个系统（软、硬件）

测试人员：黑盒测试工程师

测试依据：需求规格说明书

测试方法：黑盒测试

内容模块：功能、界面、可靠性、易用性、性能、兼容性、安全性等。

5.4 冒烟测试

**冒烟测试（Smoke Testing）：**是一种轻量级的初步测试，旨在快速验证构建的基本功能是否正常工作。通常在新版本或补丁发布后立即执行，目的是确保核心功能没有重大缺陷，从而决定是否值得进一步进行全面测试。

快速核心功能
防止浪费资源
提高效率
早期发现重大缺陷

5.5 回归测试

**回归测试（Regression Testing）：**是指修改旧代码，重新进行测试以确认修改引入新的错误或导致其他代码产生错误。在软件发生变更之后，重新运行部分或全部已有的测试用例，以确认变更没有引入新的问题，并且原有功能仍然正常工作。

保证软件稳定性
检查副作用
支持持续继承
提高产品质量

5.6 验收测试

验收测试（Acceptance Testing）： 也称交付测试，是软件开发周期中的一个关键阶段，旨在验证软件系统是否满足业务需求，并确认其是准备部署到生产环境。

测试阶段：系统测试通过之后

测试对象：整个系统（硬件）

测试人员：主要是最终用户或需求方。

测试依据：用户需求、验收标准

测试方法：黑盒测试

内容模块：同系统测试（功能…各类文档）

6.手动测试与自动测试

手动测试（Manual Testing）：由测试人员手动执行测试用例的过程，不借助任何自动化工具来运行测试。测试人员根据预定先定义好的测试计划和测试用例，一步一步地操作软件，并记录下测试结果

优点：
灵活性高：能够快速适应需求的变化或探索性测试
用户体验测试：更接近真实用户的体验，有助于发现UI/UX方法的问题
无需编程知识：不需要具备写代码的能力，适合非技术人员进行测试
适用于复杂逻辑测试

局限性：
效率低下
难以覆盖所有的情况
不适合大规模的回归测试

**自动测试（Automation Testing）：**利用特定的软件工具自动执行预定的测试用例的过程。自动化测试通常用于回归测试、性能测试等领域。

优点：
提高效率
一致性与可靠性
支持持续续集
可重复性强

局限性：
初期投入大
维护成本高
不适合所有类型的测试

7.按照实施组织划分

**α测试（Alpha Testing）：**又称a测或内侧，在软件开发周期接近尾声进行的一种体验测试形式，主要目的是在开发者控制的环境下检测软件的功能性、可靠性、性能等方面的问题。通常由公司内部员工完成，不能由程序员或测试员完成。

验证系统是否符合《需求规格说明书》的要求

发现并修复潜在Bug

确保系统稳定性和用户体验良好

**β测试（Beta Testing）：**在软件发布前的一个重要测试阶段，通常在真实或接近真实的环境中由目标用户群体进行使用。β测试强调在实际应用场景中发现潜在问题，从而验证系统的可用性、稳定性和用户满意度。

验证系统在真实环境下的运行表现

收集用户反馈，改进用户体验

发现并修复α测试未能覆盖的问题

确认系统是否具备正式上线的能力

α测试和β测试的区别：

特征	α测试	β测试
目的	验证功能、发现Bug	获取用户体验反馈，发现潜在问题
环境	开发环境	实际使用环境
参与者	内部团队	外部用户
发现的问题类型	功能性错误、性能瓶颈、UI设计问题	UI设计问题、兼容性问题、性能问题、需求不匹配