◆版权声明：本文出自胖喵~的博客，转载必须注明出处。
转载请注明出处：http://www.cnblogs.com/by-dream/p/5508428.html
概述
HTSM全称Heuristic Test Strategy Model，翻译过来是启发式测试策略模型，该模型是测试专家James Bach提出的一组帮助测试设计的指南。
下面这幅图很好的说明了HTSM：
HTSM是用户设计测试策略的一组模型。这种模型的直接目的就是为了提醒测试者当他们在测试的时候应该想些什么。他的最终目的就是定制和促进专业测试人员之间的香菇沟通和自学。
Project Environment：项目环境，包括资源、约束以及可以启用或削弱我们测试的其他元素。测试人员在有的时候需要挑战这些约束，有时候则需要遵守这些约束。
Product Elements ：产品元素，是你要测试的东西。软件是负责的并且是不可见的。我们需要格外小心的测试这些，它不只是我们简单看到的那样。
Quality Criteria：质量标准，是规则、价值观，是让一个测试者来确定产品是否有问题的根源依据。质量标准是多方面、往往隐藏或者是自相矛盾的。
Test Techniques：测试技术，启发式的为建立测试，所有技术都涉及到对项目环境、产品元素已经质量标准的某种分析。
Perceived Quality：可以观察到的质量，就是测试结果。你永远无法知道一个软件产品的实际质量，但是通过对各种应用的测试，你可以用知情来评估。
一句话解释就是：测试人员利用 Project Environment（项目环境）、Quality Criteria（质量标准）、Product Element（产品元素）通过，指导 Test Techniques（测试技术）得到Perceived Quality（可以观察到的质量）。
General Test Techniques 通用测试技术
测试就是一种启发式的建立测试。这里有很多有趣的测试。下面有九个通用的技术，通过通用技术，我们希望用简单的技术就可以普遍试用于各个场合。许多具体的技术都是基于这九中技术的。而层出不穷的测试技术都是通过组合下面的这些一个或多个测试方法。
功能测试：
测试它可以做什么
1. 产品可以实现的确定的事情（函数和子功能）。
2. 确保你怎么知道一个函数如何完成工作。
3. 测试每个功能，一次一个。
4. 看到每个函数它能做什么，不能做什么。
声明测试：
挑战每个声明
1. 确定的参考材料，包括产品（隐性或显性）的声明。需要考虑SLAs, EULAs。
2. 分析个人声明，并澄清模糊的声明。
3. 测试有关产品的每项声明的真实性。
4. 如果你按一个明确的规范进行测试，希望它和产品是一样的。
域测试：
分而治之数据
1. 查看产品处理的数据，观察输入和输出。
2. 决定测试特定的数据。需要考虑像边界值，典型值，方便值，无效值，或正常的这些情况。
3. 考虑数据的组合是否值得在一起测试。
用户测试:
涉及用户
1. 确定类别和用户的角色。
2. 确定每个类别的用户将做什么（用例），他们会如何做，他们的测重点是什么。
3. 获取真实的用户数据，或把用户带入真实将测试场景中。
4. 反之，系统模拟一个用户（注意，这是容易觉得你像一个用户，即使你不是）。
5. 强大的用户测试是涉及各种用户和用户角色。
压力测试：
压垮你的产品
1. 寻找一些在有挑战的数据和资源有限的情况下容易过载的子系统和功能。
2. 识别和这些子系统或功能相关的数据和资源。
3. 选择或者制造一些有挑战的数据或者是资源约束条件来进行测试。例如：大型或者复杂的数据结构、高负荷、长时间运行，内存不足。
风险测试：
想象一个可能出现的问题，然后去检查它
1. 产品可能有什么类型的问题？
2. 那种类型最重要？我们需要专注于这些。
3. 如果风险存在，你将如何发现它们？
4. 列出一些有趣的问题列表，然后设计测试用例还发现他们的问题。
5. 它有助于你请教专家、设计文档、past bug 报告, or apply 风险启发。
流测试：
一件一件的事情做
1. 执行一些端到端的活动，然后基于状态模型去观察它。
2. 在操作和操作之间不要重启系统。
3. 不同的时间和顺序，尝试并行线程。
自动检查：
检查成千上万的真实情况
1. 寻找或者开发一个可以执行大量动作并且可以做检查的工具。
2. 是否有工具可以做部分自动化测试覆盖。
3. 是否有工具可以做一部分自动预言的功能。
4. 思考如何自动的改变探测器（什么鬼这是）。
5. 思考如何让数据自动的生成。
6. 思考借助工具让人的测试更加的强大。
场景测试：
以一个故事的形式来进行测试
1. 以围绕产品左右的事情作为思考的开始。
2. 设计测试的时候需要涉及到富又意义并且和产品有着复杂关系的相互影响的案例。
3. 一个好的场景测试师是如何将一些人做和产品相关的事情构造成一个引人入胜的故事。
Project Environment 项目环境
创建和执行测试是测试一个项目的核心。然而有很多的项目环境会影响你需要在创建和执行测试时候需要做特殊的处理。在下面的这些类别中，我们需要考虑这些规则是否会帮助或者阻碍你测试设计的过程，试图利用一切资源。
任务：你和你的客户理解的这个项目的最终目的。
你知道谁是你的客户吗？谁的意见重要？谁会从你的工作中获得收益和影响？
你知道你的客户对你产品的期望吗？你同意它们的看法吗？
也许你的客户有强烈的想法去让你对哪些进行测试。
也许他们和你有冲突的期望，你可能要帮助识别和解决这些问题。
信息：关于你要测试的产品和项目的信息。
我们可以请教谁去了解这个产品？
是否有可用的工程文件？用户手册？网站上的资料？规格说明书？用户投诉？
了解该产品的历史吗？老的问题是已经解决了还是延期解决？客户都怎么吐槽这个产品？
你目前了解到的信息是？你如何获得心的或者变化的信息？
是有有一些竞品可以让我们学习
开发者关系：你和你的开发人员之间的相处。
自负： 开发是否对产品的各个方面都非常的自信？
防御性： 是否有一些开发人员很抵触让测试来测试一部分他们的功能？
荣融洽：你和你的开发人员的相处是否融洽？
循环反馈：你和开发在需求沟通方面是否能快速搞定？
意见反馈： 开放是否认可你的测试策略？
测试团队：团队的每个人什么时候去执行什么，支持什么。
你知道谁适合测试这个任务？测试团队是否有足够的测试人员？
不属于测试团队的人员能否给予我们帮助？一些有着和被测产品相似产品背景的作者，用户，开发人员是否可以帮助我们呢？
测试团队是否有专门的测试技术来应对问题？
是否有培训？是否有用？
人都是在同一地点吗？还是在不同的地方？时区差会影响什么吗？
设备和工具：需要管理的测试硬件、软件、文档。
硬件： 我们有你需要执行测试的所有设备吗？都设置和准备好了吗？
自动化：其他测试工具需要吗？他们是否可用？
探索： 是否还有其他的一些工具可以帮助我们测试产品呢？
检测清单：是否要跟踪或记录测试进度所需的任何文件？
时间表：项目的排序、持续时间已经事件。
测试设计： 你有多少时间可以测试？是否有些测试计划晚创建比早场景要好？
测试执行： 测试什么时候会把执行？一些测试会不会被重复执行？例如做回归测试的时候。
开发： 什么时候可以编译一个可测试的版本？什么时候冻结代码、功能增加等？
文档： 什么时候用户的文档可以完成，让大家来一起看看？
测试项目：要被测试的项目。
适用范围： 产品的哪部分是你测试范围内的？哪些不是你测试范围内的？
可用性： 你有产品需要测试？你是否有可用的测试平台？你什么时候可以得到新版本？
波动： 产品是不是不断在变化？哪些是需要你再重新测试的？
新的东西： 最近产品的改变和附加是什么？
可测性： 产品功能是否足够可靠让你有效的去测试它？
未来的版本：你的测试是哪部分？如果有必要，必须要设计产品未来的版本。
交付物：可已观察到进度的被测项目。
内容：你会写哪一类型的报告？你愿意分析你的工作笔记吗？还是只是最终的结果？
宗旨：你的成果是否会作为一部分的产品进行提供? 别人会运行你的测试吗？
标准：你是否有应该遵循特定的测试文档标准呢？
媒体：你讲如何记录并且传达你的测试报告？
Product Elements 产品元素
最终的产物是提供给客户一个好的体验。产品有很多方面，所以为了测试好，我们必须研究这方面，下面标出的类别，代表一个产品重要和独特的一面。如果只关注其中几个的话，测试人员很容易漏掉一些bug。
结构：产品的物理接口。
代码： 从可执行文件到个别功能的代码结构。
硬件： 产品不可缺少的硬件部分。
非可执行文件：不是媒体文件和可执行程序，而是文本文件、样本数据或者是帮助文档。
抵押品：软件和硬件之外的一些产物，也是属于产品的一部分，如纸质文档，网页链接和内容，包装，许可协议等。
功能：产品的功能。
应用程序： 定义或者区分产品、满足核心功能的任何功能。
运算： 任何嵌入到产品当中的运算函数或者运算操作。
时间相关：超时设置，日报或者月报，夜间要处理任务，时区，假日，利息计算，条款和保修期，计时码表功能。
修改： 修改或者改变的一些功能（例如：设置字体、插入剪贴画、从帐号取钱）。
启动/关闭： 调用或者初始化一个应用的每个函数和接口。
多媒体：音乐、图像、视频，已经嵌入到产品当中任何已图像显示的东西。
错误处理： 检测错误的能力，包括从错误中可以恢复过来。
相互作用： 产品当中功能之间的相互影响。
可测性： 提供帮助测试的一些功能。例如诊断日志、断言、测试菜单等等。
数据：产品所操作的数据。
输入： 由产品处理的所有数据。
输出： 产品处理结果后的数据。
预设： 为部分功能提供数据或者是创建的数据，例如预设的数据库和默认值。
持久性： 内部存储的数据或者是需要持续操作的一些内容。包括产品的模式和状态，例如选项设置，视图设置，文本内容等。
序列/组合： 任何排序或者数据的排列，例如语序，整理与未排序的数据，测试顺序。
基数： 可以变化的 （例如 0，1，很多，最大，没有限制），必须唯一的值 （例如 数据库的键值）。
大/小：变化的大小和数据的聚合。
噪音数据: 任何无效、损坏、不受控制和不是正确产生的数据和状态。
声明周期: 一个数据被创建、访问、修改、删除变化过程的整个生命周期。
接口：产品被访问的一些接口
用户接口： 让数据与用户交流的元素（例如显示屏、按钮，不论是物理的或者虚拟的）。
系统接口： 程序、硬盘、网络等。
API/SDK：（不用解释了把。）
导入/导出：用包去尝试不同的产品，同时用不同的产品去解毒这些数据。
平台：产品所依赖的外部因素
外部设备： 不属于产品本身但是需要的一些硬件设备或者配置（如系统，服务器，存储，键盘，云）。
外部软件： 不属于产品本身但是需要的一些软件设备或者配置（如操作系统，同时执行的应用程序，驱动程序，字体等）。
内部组件：嵌入到你项目当中的库或者组件，这些都是在你项目之外生成的。
操作：产品将被如何使用。
用户：各种用户的属性。
环境：在固定的物理环境中对产品进行操作，例如光、噪声
正常使用：产品通常会遇到的模式和序列。这些改变由用户决定。
不受欢迎的使用：无知，误解、粗心或恶意使用产生的输入。
极端的使用： 具有挑战性的模式和与预期产品不一致的输入序列。
时间：产品和时间相关的所有信息。
输入/输出： 输入和输出之间的一些时间关心（延迟、间隔等）。
快/慢： 测试的时候快速和慢速输入；最快和最慢；将快慢组合在一起。
变化率： 加快和放慢（尖峰，爆裂，挂起，瓶颈，中断）。
并发： 多件事情同时发生（多用户，分时，线程，和信号，共享数据）。
Quality Criteria Categories 质量标准分类
一个质量标准是一些要求，即产品需求的定义。通过思考不同的标准，你讲更好的规划测试来更快的发现一些重要问题。此列表上的项目可以被认为是一个潜在的危险区域。对于下面的每个分类，请确保它是否对你的项目很重要，再想想如果你的产品这方面做的好或者不好，你讲如何重视它。
能力：所有的功能它都可以执行吗？
可靠性：它在遇到异常情况下能否正常的工作呢？
坚固性：产品在合理的条件下一段时间后没有继续恶化。
错误处理： 该产品在抵御错误的情况下是完美的，当系统错误的时候很容易恢复。
数据完整性： 在丢失或损坏的系统中保护好数据。
安全性：产品不会因为运行错误而损害生命和财产。
易用性：一个真正的用户在使用它的时候有多简单？
学习性： 产品的操作可以通过用户手册非常容易的学会。
可操作性： 产品的可以非常容易的操作，即使有时候你是瞎操作。
可访问性： 产品符合相关的无障碍标准并且和操作系统的操作习惯比较接近。
魅力：这个产品到底多吸引人？
美学：产品透漏出来的感官。
独特性： 产品在某些方面是新奇或者特殊的。
必要性： 用户期望的产品具有的功能。
用途： 该产品解决了一个问题，解决的好。
Entrancement: 会使用户上瘾，感觉有趣而充分的使用产品。
形象： 该产品质量所需要的形象。
安全：产品能够如何有效的抵御非认证用户和外部侵扰？
验证： 可以用一种方式验证这个用户是否是他说描述的自己。
授权： 这是在不同的权限级别授予认证用户的权利。
隐私： 用何种方法对未授权的人保密我们的员工和客户的数据。
安全漏洞：在该系统中不能强制安全的方式（例如社会工程漏洞）。
可扩展性：产品能否主动的向上或向下兼容？
兼容性：产品如何与外部的组件和配置良好的工作？
应用程序兼容性： 该产品和其他软件相结合。
操作系统兼容性： 该产品是否可以运行在一个特定的操纵系统。
硬件兼容性： 该产品可与特定的硬件组件和配置工作。
向后兼容性： 产品需要适用于早期的版本。
产品使用方法： 产品没有不必要的内存，存储器，或其它系统资源。
性能：产品的响应是否迅速？
安装能力：能否非常容易的安装到它的对于平台？
系统要求： 产品是否可以辨别出如果一些必要的组件缺失或者不足。
配置： 哪些部分系统是由安装受到影响？文件和资源在哪里存储？
卸载： 当产品被卸载的时候，是否是清理干净？
升级/补丁程序：新的模块和版本很容易被添加？是否考虑过现有的配置？
管理： 安装需要由专人来处理，还是需要在专门的时间进行？
开发该做的：我们如何创建、测试、修改？
支持性： 如何划算的对用户提供技术支持？
可测性： 如何有效的对产品进行测试？
可维护性： 如何划算的去建立、修复或者是增强产品功能？
便捷性： 如何划算的进行技术重用？
本地化分析： 如何经济的让产品在其他地方也适用？
使用
有了这些理论理论之后，那和实际的工作怎么结合起来呢？我个人觉得既然是启发式，那么配合思维导图是最合适不过了。下面是我自己画的思维导图：
当我们接到一款产品的时候，首先需要使用HTSM对产品进行认识，然后使用HTSM的测试策略得到你要测试的内容，分析出你测试的对象，然后使用前面我们介绍过的具体的建模方法，得到测试用例，最终完成测试。
总结
总体来说，HTSM是一系列指导性的词语组成，让测试者从“高度抽象”到“底层细节”对产品和测试进行思考。它不是教你如何去测试，而是启发你如何去思考，从而挖掘出测试对象和策略。