从测试分类到缺陷管理
目录
1.多维测试分类：覆盖测试全场景
1.1 按测试目标分类
1.2 按执行方式分类
1.3 按测试方法分类
1.4 按测试阶段分类
1.5 按实施组织分类
2. 测试用例设计
2.1 用例设计万能公式
2.2 六大核心设计方法
3. 测试核心流程与 bug 管理
3.1 软件测试生命周期
3.2 bug 的核心要素与生命周期
3.3 手工测试与自动化测试
4. 总结
1.多维测试分类：覆盖测试全场景
软件测试可从目标、执行方式、方法、阶段、实施组织等多个维度划分，不同分类对应不同测试场景和目标。
1.1 按测试目标分类
（1）界面测试（UI 测试）：
以设计稿为基准，验证界面的完整性、一致性和友好性。涵盖布局排版、控件可用性、自适应适配等，核心是保证界面符合设计规范，提升用户直观体验。
（2）功能测试：
核心是验证产品功能是否符合需求规格。不关注内部实现，只检查输入输出是否匹配预期，是测试中最基础、占比最高的类型。
（3）性能测试：
评估系统在不同负载下的运行表现，核心指标包括响应时间、吞吐量、稳定性。解决系统卡顿、响应慢、并发崩溃等问题，保障高负载下的可用性。
（4）可靠性测试：
衡量系统正常运行的能力，常用 “可用率”（正常运行时间 / 总时间）衡量。高端系统需达到 99.999% 的可用性，全年故障时间仅 5 分钟左右。
（5）安全性测试：
防范数据泄露、恶意攻击等风险，覆盖 SQL 注入、权限漏洞、数据篡改等场景，通过代码评审、渗透测试等方式执行。
（6）易用性测试：
基于 ISO25020 标准，评估产品是否易学习、易操作。重点检查规范性、直观性、灵活性、舒适性，贴合用户使用习惯。
1.2 按执行方式分类
（1）静态测试：
不运行程序，仅通过代码走查、文档审查、工具扫描等方式，检查代码规范、逻辑漏洞、文档错误，适用于开发早期，提前规避问题。
（2）动态测试：
实际运行程序，输入测试数据，对比实际结果与预期结果。绝大多数功能、性能测试都属于此类，是验证功能有效性的关键。
1.3 按测试方法分类
（1）白盒测试：一般适用于单元测试
关注程序内部结构和逻辑，又称结构测试。通过语句覆盖、路径覆盖等方式，检查代码逻辑的正确性，主要用于单元测试，由开发或白盒测试工程师执行。
（2）黑盒测试：一般适用于系统测试、验收测试
不关注内部代码，仅从用户视角验证输入输出。常用等价类、边界值等方法，覆盖功能、界面、系统测试，是黑盒测试工程师的核心工作。
（3）灰盒测试：一般适用于集成测试、接口测试
介于两者之间，既关注输入输出正确性，又兼顾部分内部逻辑。多用于集成测试，平衡测试效率与代码覆盖度。
1.4 按测试阶段分类
软件测试一般按照 单元→集成→系统→验收 的递进顺序
（1）单元测试：
针对最小代码单元（方法、类）测试，采用白盒测试，由开发执行，精准定位代码级 bug。
集成测试：将模块组装后，测试模块间接口和数据传输，采用黑白盒结合，重点排查接口冲突、数据异常。
（2）系统测试：
对完整系统进行端到端测试，采用黑盒测试，覆盖功能、性能、安全等全维度，是上线前的全面体检。
（3）冒烟测试：
系统测试前的 “快速校验”，仅测核心流程，判断系统是否具备详细测试条件，不通过则直接打回开发。
（4）回归测试：
代码修改后，重新测试原有功能，验证修改未引入新 bug，贯穿开发全阶段，自动化测试可大幅提升效率。
（5）验收测试：
上线前最后一步，由用户或需求方执行，确认系统符合业务需求，分为内部 α 测试和外部 β 测试。
1.5 按实施组织分类
（1）α 测试（内测）：
公司内部模拟真实环境测试，可控性强，提前发现产品缺陷。
（2）β 测试（公测）：
邀请真实用户在实际场景使用，反馈线上潜在问题，环境不可控，覆盖范围广。
（3）第三方测试：
由独立机构执行，客观公正评估产品质量，常用于合规性、安全性验收。
2. 测试用例设计
2.1 用例设计万能公式
功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试
这六个维度可以作为思考起点，覆盖绝大多数被测对象（无论是桌面软件、Web应用、移动app还是命令行工具）
2.2 六大核心设计方法
（1）等价类划分法：
将输入划分为 “有效等价类”（符合需求）和 “无效等价类”（不符合需求），每类选 1 个用例代表，避免穷举，大幅减少用例数量。
例如：某字段要求输入整数1~100 - 有效类：50；无效类：0、101、-5、abc
（2）边界值分析法：
重点测试输入的边界点（如长度最大值 / 最小值、数值临界值），边界是 bug 高发区，作为等价类的补充。
例如：同上 — 边界值：1、100；次边界：0、2、99、101
（3）场景法：
模拟用户真实业务流程，覆盖正常场景和异常场景，串联多个功能点，避免碎片化测试，贴合实际使用场景。
例如：在线购物：正常下单 - 库存不足 - 优惠券失效 - 支付超时
（4）判定表法：
梳理多个输入条件与输出结果的逻辑关系，覆盖所有条件组合，适合多条件联动的复杂需求。
例如：根据用户等级（普通/VIP）和消费金额（≥100/<100）决定是否包邮
（5）正交法：
针对多因素、多水平的场景，选取代表性组合，用最少用例覆盖最多组合，解决用例爆炸问题。
例如：某搜索功能有3个筛选条件，每个条件有2种状态 — 用正交表生成4~5条用例而非8条
（6）错误猜测法：
基于测试经验，推测易出错场景（如特殊字符输入、异常操作），补充边缘用例，依赖经验积累。
例如：文件名包含特殊字符、网络中断时提交表单、快速重复点击按钮
3. 测试核心流程与 bug 管理
3.1 软件测试生命周期
测试贯穿软件全生命周期：需求分析—测试计划—用例设计—测试执行—缺陷管理—测试评估—上线维护
3.2 bug 的核心要素与生命周期
（1）bug 描述五要素：
版本（发现问题的软件版本号）、环境（操作系统、浏览器、设备型号等）、步骤（可复现问题的详细操作路径）、预期结果（按照需求或常识应该发生的结果）、实际结果（实际观察到的现象），清晰描述才能让开发精准定位问题。
（2）bug 级别划分：
崩溃（系统死机、崩溃、主要功能完全不可用、数据丢失）、严重（功能部分丧失、关键流程阻断、安全问题）、一般（非核心功能异常但可绕过，或性能明显下降）、次要（界面错位、错别字、提示不友好等建议性问题），优先级从高到低处理。
（3）bug 生命周期：
新建→确认→修复→回归验证→关闭，未通过验证则重新打开，形成闭环管理。
3.3 手工测试与自动化测试
（1）手工测试：
人工执行用例，灵活度高，适合探索性测试、界面校验，缺点是效率低、重复性差。
（2）自动化测试：
通过工具 / 脚本执行，适合回归测试、性能测试，效率高、一致性强，但技术要求高，适合稳定功能。
4. 总结
掌握测试分类有助于在不同阶段采用合适的策略。掌握用例设计方法能让测试覆盖更全面、效率更高。掌握缺陷管理流程则能保障问题被有效跟踪和解决。