测试分类
1 按照测试目标分类:
-
界面测试：关注软件的UI设计是否符合规范，元素布局、色彩搭配、交互反馈是否直观统一，核心是保障用户视觉体验与操作流畅性。
-
功能测试：验证软件的功能是否符合需求说明书，比如按钮点击、表单提交、流程跳转等是否正常，是最核心的测试类型之一。
-
性能测试：测试软件在不同场景下的响应速度、并发能力、资源占用等，比如高并发下的接口响应时间、服务器CPU使用率等，避免系统"卡顿""崩溃"。
-
可靠性测试：检验软件在长时间运行或极端环境下的稳定性，比如连续运行72小时是否出现异常，核心是保障系统"不掉线""少故障"。
-
安全测试：排查软件的安全漏洞，比如SQL注入、XSS攻击、权限越界等，保护用户数据与系统安全。
-
易用性测试：站在用户视角判断软件是否"好用"，比如操作步骤是否简洁、提示信息是否清晰，降低用户学习成本。
2 按照执行方式分类
-
静态测试：不运行软件，通过检查代码、文档、设计方案等实现，比如代码走查、规范校验、需求文档审核，能及早发现逻辑漏洞与设计问题。
-
动态测试：运行软件并输入测试数据，观察输出结果是否符合预期，比如功能测试、性能测试大多属于动态测试，能验证软件的实际运行效果。
3 按照测试方法分类
-
白盒测试：测试人员清楚软件的代码逻辑与内部结构，通过代码走查、路径覆盖等方式验证模块正确性，多由开发或白盒测试工程师执行。
-
黑盒测试：测试人员不关注内部结构，仅通过输入输出验证功能是否符合需求，像用户使用软件一样"盲测"，多由黑盒测试工程师执行。
4 按照测试阶段分类
软件测试贯穿研发全流程，每个阶段的测试重点不同，形成"单元-集成-系统-验收"的完整链路：
测试基本流程：单元测试------集成测试------系统测试(冒烟/回归测试)------验收测试
1）单元测试：最小模块功能验证
针对软件中最小的设计单元（如函数、方法、类）开展验证，目标是确保模块编码正确。
-
测试阶段：编码后或编码前（TDD测试驱动开发模式）
-
测试对象：函数、方法、类等最小模块
-
测试人员：开发工程师或白盒测试工程师
-
核心内容：模块接口、局部数据结构、代码路径、错误处理、边界条件测试
（2）集成测试：模块间的"协作验证"
也称联调、组装测试，重点检查模块之间的接口是否正常，避免"模块单独能用，组合就出错"。
-
测试阶段：单元测试后，系统测试前
-
测试对象：模块间的接口
-
测试方法：白盒与黑盒测试结合
-
核心内容：模块间数据传输、功能冲突、组装正确性、全局数据结构影响
（3）系统测试：全系统的"宏观验收"
整合所有模块与外部资源，验证整个系统是否符合需求规格说明书，是黑盒测试的核心场景。其中，冒烟测试与回归测试是系统测试的重要组成部分：
-
冒烟测试：针对新编译版本，快速验证核心功能是否正常，避免无效测试（比如登录、支付等核心流程若失效，后续测试无需开展）。
-
回归测试：代码修改后，验证原有功能是否正常，防止"改旧错出新错"，是测试工作量占比极高的环节。
-
测试阶段：集成测试通过后，系统构建完成后
-
测试对象：整个软硬件系统
-
测试内容：功能、界面、性能、安全等全维度验证
（4）验收测试：交付前的终审
由用户或需求方主导，验证软件是否符合实际使用需求，是交付前的最后一道关卡，分为Alpha测试与Beta测试：
-
Alpha测试：用户在开发环境测试，开发/测试人员可协助，重点发现早期使用问题。
-
Beta测试：用户在实际环境测试，开发/测试人员不在场，验证真实场景下的稳定性。
5 其他测试分类
-
按是否手工测试：手工测试（灵活应对复杂场景）、自动化测试（高效回归重复用例）。
-
按实施组织：α测试（内测，开发团队主导）、β测试（公测，最终用户参与）。
-
按测试地域：国际化测试（多语言、多时区适配）、本地测试（符合特定地区使用习惯）。
BUG管理
什么是BUG？
软件中的BUG指程序存在的错误、缺陷或故障，会导致软件无法正常运行或不符合预期，比如按钮点击无响应、数据计算错误等。
BUG描述
一份合格的BUG描述，能让开发人员快速定位问题，核心要素包括：
-
问题出现的版本、环境（操作系统、浏览器等）；
-
可复现的操作步骤；
-
预期结果与实际结果。
BUG级别分类
根据BUG对系统的影响程度，通常分为4个级别，帮助团队优先处理关键问题：
-
崩溃：系统直接闪退、死机，无法继续使用，需立即修复。
-
严重：核心功能失效（如支付失败），无替代方案，需紧急修复。
-
一般：非核心功能异常（如页面排版错乱），有替代方案，可按计划修复。
-
次要：细节问题（如文字错别字），不影响使用，可延后修复。
BUG生命周期
BUG的生命周期涵盖"发现-处理-验证-关闭"全环节，规范的流程能避免问题遗漏：
-
发现Bug：在测试过程中，测试人员发现系统或软件中的问题，这些问题与预期结果不一致，称之为Bug。
-
提交Bug：测试人员将发现的Bug记录下来，详细描述Bug的属性，包括重现环境、Bug类型、Bug等级、优先级以及重现步骤等。
-
指派Bug ：
Bug被指派给相关的开发人员进行处理。如果测试部门与开发部门独立，Bug可能会先指派给项目组长或经理，再由他们分配给具体的开发人员。 -
确认Bug ：开发人员接到
Bug后，首先对其进行分析和重现。如果确认是Bug，则进入修复阶段；如果不是Bug或无法重现，则将Bug退回给测试人员，并注明原因。 -
修复Bug：开发人员对确认的Bug进行修复。修复完成后，将Bug状态标记为"已修复"，等待测试人员进行回归测试。
-
回归验证 ：测试人员对修复后的Bug进行回归测试，验证Bug是否被彻底修复。如果通过验证，则关闭Bug；如果未通过验证，则重新打开Bug，开发人员继续修复。
-
关闭Bug：经过回归验证，确认Bug已被修复且不再出现，测试人员将Bug状态标记为"关闭"。