ISTQB知识体系中的测试策略与测试价值

ISTQB知识体系中的测试策略与测试价值

作为测试人员我们工作的价值究竟是什么？是输出用例？是输出测试脚本？还是测试执行的数量？且听下分析。

如下图所示：在ISTQB的只是体系中，测试人员的商业价值可以分为定量价值和定性价值。不同的测试价值，我觉得应该通过不同的测试策略来实现。

1.分析型测试策略来实现定量及定性价值：

1.1基于架构化的测试测试分析与测试设计：

如：邰晓梅的MFQ&&PPDCS的知识体系中都提到了KYM->TCO->Modeling->TCON->TC->TE这样的结构化的从测试分析到测试执行的过程。在KYM->TCO重点是分析测试在项目中的上下文环境，持续收集测试信息，并进行结构化的梳理，识别测试覆盖要点。Modeling->TCON->TC阶段进行测试建模，识别测试条件输出测试用例。

这套测试过程重点在于单功能、和功能交互的识别，更适合从测试广度的方向（个人理解），做功能覆盖，从而发现产品缺陷。当然作为广度功能覆盖的测试类型，我们也可以借此测试分析和测试设计的结果来进行自动化和CI的部署。

产品从早期大量CI用例大量失败，持续耕耘，到最后自动化执行成功率、功能覆盖率等达到一个理想的程度，也是研发项目对于产品质量信心不断积累的一个过程。

ISTQB知识体系中提到的测试分析和测试条件等概念，与MFQ&&PPDCS中的应该概念大体一致。并不冲突。

2.1RBT基于风险的测试：

RBT分为风险识别、风险分析、风险控制三个部分。在基于测试不可穷尽性的大背景下，考虑质量和成本的平衡以及测试资源的优化配置的，我们可以借助团队的经验、项目相关干系人的群体智慧去识别风险、基于风险优先级去制定风险控制的策略从而更优化的去配置测试资源，但本质上它还是聚焦于缺陷发现和风险识别和控制的，当然通过设计测试去发现缺陷并推动缺陷的修复本身也是风险控制的一个方式。

2.应对性测试策略来实现定量价值：

应对型测试策略最典型的例子就是ET(探索性测试)。它是典型的面向缺陷发现的测试策略，ET通常是从测试深度的角度，发挥测试人员的主观能动性通过敏锐的测试思维、全面的领域知识、被测系统的背景知识主动去挖掘深藏的缺陷。不同于功能覆盖（CI或手工方式），它不拘泥于用例和文档，考虑简要的ET章程之后就可以开始测试探索，根据被测系统的反馈出来的信息，决定下一步探索的范围和方式。

3.基于模型的测试策略来实现定性价值：

在测试中，我们常常会模拟被测软件的商用部署时的流量模型、用户模型来考察被测系统在这些典型场景的性能、压力，并将这些信息反馈项目干系人甚至是真实用户，这些测试也有可能是用户指定或者要求的。通过这样的典型模型的性能相关的数据，让用户建立起对于被测软件系统的信心。

4.系统化测试策略来实现定性价值：

定义产品必须满足的规范、指标，通过CheckList的方式对产品进行评估。常见的有，代码安全性审查、合规性审查、协议一致性测试等。有人工审查方式也可以借助一些工具。如:C代码规范KW,PC-LINT等等。

5.咨询式测试策略实现定性价值：

根据项目干系人、用户的要求的测试场景、测试条件进行测试，目的是为了获取被测软件的特定信息。用于评估产品对于感兴趣、关注的功能和产品的满足程度。

6.回归型测试策略实现定量及定性价值：

现在常见的回归测试的方式是CI自动化测试回归+手工测试探索。CI自动化测试回归是为了保证已覆盖的基本功能不受影响。通过度量的方式，统计缺陷解决率，为项目建立信心。同时要充分考虑代码变更产生的波及，基于波及的相关信息，进行手工测试探索，挖掘更多的缺陷或风险也是回归测试的重要目标。

总结：

回到文章开头的问题写更多的用例、写更多的脚本，执行更多的用例本身是没有价值的。换句话来说，聚焦于“定量”和“定性”这两部分收益的测试活动才是有价值的（应该考虑测试设计、测试执行的有效性问题,此处不展开）。优先将资源保证在高价值的事情之上。优先保证项目干系人和用户都关注的度量指标。