| 编辑推荐: |
本文主要介绍了HTSM的内容与应用
。
本文来自于博客园，由火龙果软件Linda编辑推荐。 |
|
启发式测试策略模型（Heuristic Test Strategy Model，简称HTSM）是测试专家James
Bach提出的一组帮助测试设计的指南（guideline）。本文将介绍HTSM的内容与应用。
为什么需要HTSM
根据产品的风险（risk）设计测试是一种常见的测试设计思路。在复杂的现实世界，产品面临的风险多种多样，只有全面考虑、周密测试才能避免风险暴露导致的严重后果。因此，测试人员需要一个相对完整、可以定制、容易扩展的风险列表或参考模型，来帮助他们发现产品风险。HTSM就是一个结构化的、可定制的参考模型，从测试技术、产品元素、项目过程、质量标准等多个角度启发测试设计。
HTSM能够在测试全程提供有益的提示。在制定测试计划初稿时，它可以帮助测试人员完整地思考产品的方方面面，从而产生系统性的（systematic）测试计划。在测试过程中，它可以帮助测试人员组合测试想法、深入探索产品，以开发出强有力的测试策略。在回归测试中，它可以帮助测试人员确定测试范围，制定测试方案。
HTSM的内容
上图是HTSM的概要描述，测试人员利用质量标准（Quality Criteria）、项目环境（Project
Environment）、产品元素（Product Element），指导测试技术（Test Techniques）的选择与应用，并产生观察到的质量（Perceived
Quality）。
HTSM是层次结构，其顶层元素（质量标准、项目环境、产品元素、测试技术）可以分解为次层元素，而次层元素可进一步分解为第三层元素。本文只概要介绍次层元素，更多的细节请参考James
Bach的文档。
测试技术：生成测试的策略。有效地选择和实施测试技术，需要综合分析项目环境、产品元素和质量标准。
功能测试（Function Testing）
域测试（Domain Testing）
压力测试（Stress Testing）
流测试（Flow Testing）
情景测试（Scenario Testing）
声明测试（Claims Testing）
用户测试（User Testing）
风险测试（Risk Testing）
自动测试（Automatic Testing）
项目环境：资源、约束和其他影响测试的项目元素。测试总是受到项目环境的约束。在某个团队运转良好的策略不一定适合另一个相似的团队，以往富有成效的方法未必适应当前的项目。有经验的测试人员会根据当前语境（Context），在约束条件下充分运用资源，以高效地测试。
用户（Customers）：理解产品的用户
信息（Information）：发现测试所需的信息
开发者关系（Developer Relations）：与开发者协作加速开发
测试团队（Test Team）：利用团队的力量支持测试
设备与工具（Equipment & Tools）：可利用的硬件、软件、文档等
进度（Schedule）：项目实施的流程
测试条目（Test Items）：测试范围和重点
交付品（Deliverables）：测试的产出
产品元素：需要测试的对象
结构（Structure）：产品的物理（physical）元素（如代码、接口、配置文件、可执行文件等）
功能（Functions）：产品的功能
数据（Data）：产品所操作的数据
平台（Platform）：产品所依赖的外部元素
操作（Operations）：产品将被如何使用
时序（Time）：影响产品的时间因素
质量标准之操作性标准（Operational Criteria）：面向用户和运营团队
能力（Capability）
可靠性（Reliability）
可用性（Usability）
安全性（Security）
可伸缩性（Scalability）
性能（Performance）
可安装性（Installability）
兼容性（Compatibility）
质量标准之开发标准（Development Criteria）：面向开发团队
可支持性（Supportability）
可测试性（Testability）
可维护性（Maintainability）
可移植性（Portability）
本地化（Localizability）
由以上介绍可知，HTSM由一组指导性词语（guide word）组成，它们构成一个层次结构，让测试人员从高层抽象到底层细节对产品和测试进行思考。这些指导性词汇是测试的指南，其作用不是教导如何具体地测试，而是启发测试人员的思维，发掘测试对象和测试策略。
下图摘录自James Bach的培训教材Rapid Software Testing，体现了HTSM对于测试设计的意义。
测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险，设计有针对性的测试策略。
在测试设计时，质量标准启发测试先知（Oracles），项目环境启发测试过程（Procedures），产品元素启发测试覆盖（Coverage），观察到的质量启发测试报告（Reporting）。
对于测试，HTSM强调测试策略的多样性（Diversification），平衡代价和收益（Cost
vs. Value），利用启发式方法（Heuristics）充分发挥测试人员的技能（Skill）。 
定制HTSM
在定制化之前，HTSM对测试人员的帮助很小，因为此时的HTSM是“James Bach的模型”，而不是符合当前语境的模型。HTSM是通用的模型，虽然能够普遍使用，但是不能快速、高效地指导具体的测试工作。测试人员需要将其“本地化”，才能发挥其威力。
Cem Kaner教授在教程Blank Box Software Testing 中提出利用思维导图（Mind
Map）定制HTSM。他将HTSM作为图的为中心，将Quality Criteria、Project
Environment、Product Elements和Test Techniques作为主干。
在分支上，Cem Kaner添加了他觉得重要的节点。例如，他在Product Elements下增加了Benefits节点和Time节点，使HTSM符合他的工作需要。
恰如Cem Kaner所说：“大多数严肃对待此模型的人会定制它以符合自己的需要”（Most people
who work seriously with this model customize it t
meet their needs），测试人员可以也应该修改HTSM，以获得符合项目语境的模型。
增加节点：增加与当前项目相关的测试技术、测试想法、测试对象和任何测试人员认为有价值的元素。
删减节点：忽略一些与项目或任务无关的元素。
增加标记、注释、链接等图元：标记可以突显重要的元素，注释可以增加更多的细节，链接可以指向更详细的信息源。
定制HTSM是理解并掌握HTSM的过程。与大多数方法一样，测试人员需要修改它，加入自己的风格和元素，才能正真掌握它。
测试专家Michael Larsen在XMind.net提供了他制作的HTSM思维导图，为测试人员制作自己的HTSM提供了很好的基础。
应用HTSM
定制HTSM就是应用HTSM的过程。测试人员遵循HTSM的结构化指南，深入地思考产品、项目与测试，添加自己的想法、评论、标记和启发式问题。这本身就是极好的测试学习过程。作为学习的结果，定制化的HTSM为进一步地测试设计提供了坚实的基础。在测试过程中，测试人员会接触新信息，学习新知识。他应该持续地将新知补充到HTSM中，以迭代地优化测试略模型。从这个角度，HTSM既是测试想法的源头，也是测试过程的产出。
在测试设计时，测试人员可以逐个检查HTSM中的每个元素（指导性词语），阅读相关标记、注释和链接，以启发测试思路。他可以自问：
该元素与当前测试任务相关吗？
针对该元素，产品有什么风险？可能会有什么缺陷？
通过什么测试可以发现这些缺陷？
依据当前的进度和资源，如何实施这些测试？
另一种更有威力的方法是综合HTSM中的多个元素，开发测试策略。当开发人员用单元测试检查了组件，测试人员需要在系统层面检查产品。此时，产品的缺陷往往存在于组件的交互和复杂的流程。综合产品的多个方面，开发多样化的测试，以更深入地测试产品，才能够更好地体现测试人员的价值。一些有帮助的启发式问题包括：
该元素与哪些元素相关？
元素的组合有没有揭示出新的风险？
如何设计测试，以同时测试这些元素？
能否让来自元素A的信息帮助元素B的测试？ |
