测试原理

测试分级

• 单元测试
• 集成测试
• 端到端测试

测试核心指标

• 缺陷密度是衡量软件质量的重要指标，定义为每千行代码中的缺陷数量。测试阶段发现的缺陷密度越高，说明测试越有效；生产环境发现的缺陷密度越低，说明质量保障越充分。
• 缺陷逃逸率指发布后发现的缺陷占总缺陷的比例，是衡量测试完整性的核心指标。
• 测试通过率反映系统稳定性。如果测试套件经常失败，可能是测试本身不稳定（flaky test）或者代码质量确实存在问题。
• 测试执行时间影响开发效率，理想的单元测试套件应该在几分钟内完成，集成测试在十几分钟内完成。测试维护成本常被忽视，但却是影响测试可持续性的关键因素。
• 缺陷修复周期反映开发效率。从缺陷发现到修复、验证、上线的时间越短，说明团队响应越快。测试驱动开发和持续集成能够显著缩短这个周期，因为缺陷在早期被发现且容易定位。
• 缺陷重现率则反映缺陷报告的质量，无法重现的缺陷是测试和开发流程中的浪费。

测试分类维度

按测试目标分类，功能测试验证软件功能是否符合需求，性能测试评估系统响应时间、吞吐量、资源消耗，安全测试检查系统漏洞和数据保护，兼容性测试确保系统在不同环境下正常运行。每种测试类型需要不同的工具和技能组合，工程团队需要根据产品特性选择侧重点。

按测试执行方式分类，手工测试依赖测试人员手动操作，适合探索性测试和用户体验验证；自动化测试由脚本或工具执行，适合回归测试和性能测试。现代软件工程强调自动化，但手工测试在某些场景下不可替代，尤其是需要人类判断的主观体验评估。

按测试时机分类，单元测试由开发者编写并运行，通常在代码提交前完成；集成测试验证模块间协作，在功能开发完成后进行；系统测试验证完整软件系统，在发布前执行；验收测试由用户或代表用户的测试人员进行，是发布前的最后一道关卡。这种时间顺序的划分体现了质量保障的逐步深入。

测试覆盖率

测试覆盖率是衡量测试完整性的量化指标。最常见的是行覆盖率，即代码中被测试执行到的比例。其他指标包括分支覆盖率、函数覆盖率、条件覆盖率等。覆盖率工具通过代码插桩收集运行信息，生成报告展示哪些代码行被执行、哪些分支被触发。

覆盖率指标的局限

高覆盖率不等于高质量测试。一个测试可以执行每一行代码，但如果没有正确断言输出结果，它只能检测到程序崩溃而无法发现逻辑错误。更隐蔽的是，测试可能执行了代码但验证了错误的预期。覆盖率指标只能告诉我们代码有没有被测试运行，而不能告诉我们测试是否充分验证了代码行为。

分支覆盖率比行覆盖率更有意义。考虑一个条件语句 if (x > 0)，行覆盖率只需要任意输入就能达到，但分支覆盖率需要分别测试 x > 0 和 x <= 0 两种情况。实践中推荐将分支覆盖率作为主要指标，它更能发现边界条件处理的问题。

合理的覆盖率目标

追求 100% 覆盖率往往得不偿失。最后几个百分点通常需要大量工作来测试极端情况，而这些情况在实际运行中几乎不会发生。更合理的做法是设定差异化目标：核心业务逻辑和复杂算法要求 80% 以上覆盖率，简单的数据类或配置代码可以适当降低。

覆盖率应该作为辅助工具而非终极目标。它的价值在于识别未被测试的代码区域，引导测试补充。但在达到一定阈值后（如 70-80%），继续追求数字提升的边际收益递减，不如将精力投入到提高测试质量上。

覆盖率与代码复杂度

圈复杂度（Cyclomatic Complexity）与测试难度直接相关。圈复杂度是代码中独立路径的数量，可以通过控制流语句（if、for、case）的数量计算。复杂度越高，需要测试的路径越多，越容易出现未被覆盖的边界情况。

高复杂度函数往往违反单一职责原则，应该考虑重构。将复杂函数拆分为多个简单函数，不仅降低了测试难度，也提高了代码可读性。覆盖率工具通常会标记高复杂度且低覆盖率的代码，这些是重构和补充测试的重点区域。

白盒与黑盒

白盒测试（也称透明盒测试或结构测试）基于对内部代码结构的了解来设计测试。测试者可以访问源代码，了解逻辑流程和数据结构，据此设计覆盖各种执行路径的测试用例。白盒测试关注代码实现的正确性，确保每条语句、每个分支、每个条件都被验证过。单元测试通常是白盒测试，因为开发者需要了解函数内部逻辑来编写测试。

黑盒测试（也称功能测试）基于对软件功能的规格说明来设计测试，不关心内部实现。测试者将软件视为一个黑盒子，只关注输入和输出的对应关系。黑盒测试通过等价类划分、边界值分析、决策表等方法设计测试用例，目标是验证软件功能是否符合需求规格。端到端测试和用户验收测试通常是黑盒测试。

灰盒测试是介于两者之间的混合方法。测试者部分了解系统内部结构（如架构图或数据流），但无法访问完整源代码。灰盒测试常用于集成测试场景：测试者了解模块间的接口和交互方式，可以针对这些接口设计更有针对性的测试，而不需要了解每个模块的内7；部实现。

可测试性

可测试性是指软件被测试的难易程度。高可测试性的代码容易被拆分、容易被模拟依赖、容易被验证行为。影响可测试性的因素包括代码结构的模块化程度、依赖关系的清晰度、状态管理的复杂度等。可测试性差的代码往往表现为难以隔离测试、难以构造测试数据、测试运行缓慢且不稳定。

提高可测试性首先需要良好的代码设计。依赖注入是最有效的技术手段：通过接口而非具体实现来声明依赖，使得测试时可以注入轻量级的 fake 对象替代真实的重量级依赖（数据库、网络服务）。函数式编程风格也有助于可测试性：纯函数无副作用、相同输入总产生相同输出，测试时不需要复杂的 setup 和 teardown。

控制全局状态是可测试性的大敌。全局变量、单例模式、静态可变状态都会增加测试难度，因为测试之间会产生隐式依赖，难以并行执行且难以保证结果可重复。解决方法是尽量使用局部状态和参数传递，将显式依赖作为函数参数而非隐式依赖全局状态。