测试用例覆盖率

提高测试用例覆盖率 减少线上问题，提升产品质量。
不能只追求覆盖率数字，还得强调测试的有效性，比如结合缺陷分析来补充用例，避免盲目追求百分比
查漏补缺，优化用例结构，再引入多样化的测试方法和团队协作。这样既解决了眼前问题，也建立了长期改进机制。

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

行覆盖率：多少行代码被执行了。

分支覆盖率：多少分支（如 if-else）被测试到。

条件覆盖率：复杂布尔表达式中的每个条件（如 A && B）的真假值是否都被测试过。

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

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

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

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

 

测试分析与评审阶段：查漏补缺
开发视角：他们最清楚代码的复杂点和边界在哪里，可以指出哪些逻辑需要加强测试。
产品视角：确保所有需求点和用户场景都被覆盖。
其他视角：利用“旁观者清”的优势，发现设计盲区。
提供接口文档：对于API或服务，提供详细的接口文档，这是接口测试用例的主要来源。

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

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

测试用例 文档通常使用 Excel 或专业的测试管理工具（如TestRail, Jira Zephyr）来编写。

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

# 性能测试场景示例
- 并发用户数：1000个用户同时操作
- 响应时间：关键操作 < 2秒
- 吞吐量：每秒处理100个请求
- 资源使用率：CPU < 80%, 内存 < 70%

 

讲解测试用例的设计思路和覆盖情况

评审态度：评审的目的是改进测试用例，而不是批评个人。应保持建设性的态度。
跟踪落实：确保评审提出的问题得到解决，避免流于形式。
确保测试质量，保证软件质量。
评审投入 vs 缺陷发现成本
┌───────────────┬─────────────────┐
│ 评审阶段发现 │ 成本最低 │
│ 测试执行发现 │ 成本中等 │
│ 线上用户发现 │ 成本最高 │

开发工程师 确认技术实现覆盖，指出复杂逻辑点
产品经理 确认业务需求覆盖，验证场景正确性

评审什么内容？(评审检查清单)
1. 正确性检查
测试用例是否准确反映需求？

预期结果是否符合产品设计？

操作步骤是否能够实现预期结果？

测试数据是否合理可用？

self_check_list = [
"所有需求点都有对应用例",
"正常场景覆盖完整",
"异常场景考虑充分",
"边界值测试已添加",
"用例步骤清晰明确",
"预期结果可验证"
]

测试用例设计思路
设计测试用例时，需要系统性地考虑各种测试场景，确保软件质量。测试用例设计思路可以归纳为以下几个核心原则和方法：
基于需求设计：首先深入理解需求，包括功能需求和非功能需求，确保测试用例与需求一致。

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

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

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

风险评估：优先测试高风险、核心功能区域。

迭代更新：

什么是测试用例？
测试用例 是一组为特定目标设计的条件、变量、输入、执行步骤和预期结果，用于验证某个软件功能是否正常工作。它是软件测试的最小执行单位。
核心目的：
验证需求： 确保软件的实现符合产品需求规格说明书。
发现缺陷： 通过执行测试用例来发现软件中存在的Bug。
覆盖测试范围： 确保产品的所有功能点都被测试到，避免遗漏。
作为自动化脚本的基础： 自动化测试脚本通常基于手工测试用例来开发。
提供可重复性： 确保任何人在任何时间执行相同的测试，都能得到一致的结果。