启发式测试策略模型（Heuristic Test Strateg

今天聊聊关于启发式测试策略模型。现今，有太多关于测试技术上介绍，随便搜搜就是各种自动化、各种高大上的框架，却少有介绍测试人员另一种能力的文章： 测试设计。

其实早在12年，国外的测试专家James Bach就做过类似的总结，他提出了一套帮助测试设计的指南，就是启发式测试策略模型（Heuristic Test Strategy Model，简称HTSM）。其核心的部分可以表示为下图：

该模型包含5个重要的部分：大意是需要根据质量定义（Quality Criteria），项目环境（Project Environment），产品元素（Product Elements）选择测试技术（Test Techniques）进行测试，最终我们能够得到的是可感知的质量（Perceived Quality）。

那为什么要有这么一个框架呢？随着需求、产品的复杂上升，其面临的风险也越来越多种多样，只有全面考虑、周密测试才能有效避免线上爆发重大问题。对于测试人员来说，每个人都会有自己的出发点，在设计用例的时候风格也不尽相同，可谓是“百家争鸣”。虽然各有特点，但是如果有一个指导性的框架模型，显然能帮助我们更“容易”的发现产品缺陷。更何况，这还是一个可以定制、容易扩展的模型。无论是移动端，还是pc端异或是其他领域，这套模型都能很好的给出参考，从测试技术、产品元素、项目过程、质量标准等多个角度启发测试设计。

虽然该版本进行过无数次的迭代，但作为一个测试设计的框架，就像前面说的，我们仍然需要自己去扩展才能使用它。单纯的复制并不能解决问题。例如下图是我简单做的一个扩展（图片较大，请点击大图查看原图）：

启发式测试模型

从图中我们可以看到，一切都从基本的四个指导词开始，质量标准、项目环境、产品元素和测试技术，这四个词构成了整个框架的基础。在这个基础上，我们继续分解指导词：

测试技术：

# 生成测试的策略。有效地选择和实施测试技术，需要综合分析项目环境、产品元素和质量标准。
功能测试
域测试
压力测试
流测试
情景测试
声明测试
用户测试
风险测试
自动化测试

项目环境：

# 资源、约束和其他影响测试的项目元素。测试总是受到项目环境的约束。在某个团队运转良好的策略不一定适合另一个相似的团队，以往富有成效的方法未必适应当前的项目。有经验的测试人员会根据当前语境（Context），在约束条件下充分运用资源，以高效地测试。
用户：理解产品的用户
信息：发现测试所需的信息
开发者关系：与开发者协作加速开发
测试团队：利用团队的力量支持测试
设备与工具：可利用的硬件、软件、文档等
进度：项目实施的流程
测试条目：测试范围和重点
交付品：测试的产出

产品元素：

# 需要测试的对象
结构：产品的物理元素（如代码、接口、配置文件、可执行文件等）
功能：产品的功能
数据：产品所操作的数据
平台：产品所依赖的外部元素
操作：产品将被如何使用
时序：影响产品的时间因素

质量标准之操作性标准：

# 面向用户和运营团队
能力
可靠性
可用性
安全性
可伸缩性
性能
可安装性
兼容性

质量标准之开发标准：

# 面向开发团队
可支持性
可测试性
可维护性
可移植性
本地化

介绍到这里我们知道了，启发式测试策略模型其实是由一组指导词汇聚而成的一个测试指南。有一点希望大家清楚，它的作用并不是教导测试人员如何进行测试，而是启发测试人员的思维，发掘测试对象和测试策略。在James的文档Rapid Software Testing中，也强调了HTSM对于测试设计的意义。

1、测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险，设计有针对性的测试策略。
2、在测试设计时，质量标准启发测试先知，项目环境启发测试过程，产品元素启发测试覆盖，观察到的质量启发测试报告。
3、对于测试，HTSM强调测试策略的多样性，平衡代价和收益，利用启发式方法充分发挥测试人员的技能。

当具备了上述条件，相信在制定测试计划初稿时，测试人员可以更完整的地思考产品的方方面面，从而产生系统的测试计划。
在测试过程中，它也可以帮助测试人员组合测试想法、深入探索产品，以开发出强有力的测试策略。
在回归测试中，它同样可以帮助测试人员确定测试范围，制定测试方案。

扫描二维码获取更多