class="blogpost-body

减少线上问题，提升产品质量。

不能只追求覆盖率数字，还得强调测试的有效性，比如结合缺陷分析来补充用例，避免盲目追求百分比
查漏补缺，优化用例结构，再引入多样化的测试方法和团队协作。

这样既解决了眼前问题，也建立了长期改进机制。

理解

覆盖率的问题
代码覆盖率：最常用的指标，衡量代码被测试执行的程度。

分支覆盖率：多少分支（如

路径覆盖率：所有可能的执行路径是否都被覆盖（通常很难达到100%）。

需求/功能覆盖率：测试用例是否覆盖了产品需求规格说明书（PRD）中的所有功能点。

接口/API覆盖率：对于前后端分离或微服务架构，所有API接口和参数是否都被测试。

业务场景覆盖率：从用户实际使用场景出发，覆盖主要的业务流和异常流。

测试分析与评审阶段：查漏补缺
开发视角：他们最清楚代码的复杂点和边界在哪里，可以指出哪些逻辑需要加强测试。

产品视角：确保所有需求点和用户场景都被覆盖。

其他视角：利用“旁观者清”的优势，发现设计盲区。

提供接口文档：对于API或服务，提供详细的接口文档，这是接口测试用例的主要来源。

编写单元测试：单元测试是测试金字塔的底层，是开发必须编写的“代码级”测试用例。

需要权威又接地气的指导，降低理解门槛，同时保持专业度

测试用例

浏览器兼容性（对于Web应用）：如Chrome、Firefox、Safari、Edge等。

#

评审态度：评审的目的是改进测试用例，而不是批评个人。

应保持建设性的态度。

跟踪落实：确保评审提出的问题得到解决，避免流于形式。

确保测试质量，保证软件质量。

评审投入

缺陷发现成本
┌───────────────┬─────────────────┐
│

评审阶段发现

测试用例设计思路
设计测试用例时，需要系统性地考虑各种测试场景，确保软件质量。

测试用例设计思路可以归纳为以下几个核心原则和方法：
基于需求设计：首先深入理解需求，包括功能需求和非功能需求，确保测试用例与需求一致。

多维度覆盖：从不同角度设计测试用例，包括功能、性能、安全、兼容性、易用性等。

使用系统化的测试设计技术：如等价类划分、边界值分析、判定表、状态转换、场景法等。

考虑用户场景和业务流程：从用户实际使用场景出发，覆盖正常的业务流和异常的异常流。

迭代更新：

是一组为特定目标设计的条件、变量、输入、执行步骤和预期结果，用于验证某个软件功能是否正常工作。

它是软件测试的最小执行单位。

核心目的：
验证需求：

通过执行测试用例来发现软件中存在的Bug。

覆盖测试范围：

确保产品的所有功能点都被测试到，避免遗漏。

作为自动化脚本的基础：

自动化测试脚本通常基于手工测试用例来开发。

提供可重复性：

确保任何人在任何时间执行相同的测试，都能得到一致的结果。