启发式测试二部曲
启发式测试计划语境模型 Heuristic Test Planning Context Model和启发式测试策略模型 Heuristic Test Strategy Model都是来自于测试大师James Bach提出的框架模型用来指导测试计划和测试设计。
- HTSM是测试设计的参考框架，提供了不同维度的指导词来启发测试人员的思维来帮助测试设计和测试策略的制定
- HTPCM是测试计划的参考框架，提供了不同维度的语境关键词来启发测试计划制定人员决定测试过程和测试任务
本文主要记录我对HTSM的学习和理解。
什么是HTSM
上图是HTSM的概要，可以看到整个模型分为四个部分质量标准(Quality Criteria)、项目环境(Project Environment)、产品元素（Product Element）和测试技术(Test Techniques）。通过对前三个部分的考察，能够得应该选择的测试技术，从而执行测试，观察被测试出来的质量Perceived Quality）。
HTSM主要目的的通过提供大量关键词和启发式问题，帮助测试人员进行对特定项目和产品的测试设计。测试人员可以根据htsm了解产品的方方面面、项目的资源情况和限制、质量标准和可用的测试技术。所以说，htsm是一个可用于测试策略设计的参考模型。
HTSM的内容
质量标准(Quality Criteria)、项目环境(Project Environment)、产品元素（Product Element）和测试技术(Test Techniques)各自有自己的处于不同层次的指导词和提问来启发测试设计。下面简要总结如下
测试技术(Test Techniques)
测试技术用来启发创建测试。所有的技术都或多或少的与产品元素、项目环境和质量标准有关联。
下面列出了九种通用的测试技术。“通用的测试技术”是指技术是简单明了的且可以脱离复杂的上下文普遍适用的。很多特殊的技术都可以基于下面九种测试技术中一种或是多种。通过组合通用技术和本模型中其他的元素，我们能够得到很多特殊的测试技术。
- 功能测试 Function Testing
- 描述：测试软件的能力。Test what it can do
- 典型思路
- 辨识产品能做的事情
- 决定你怎么知道产品能工作
- 一次只测试一个功能
- 测试每个功能只做了它应该做的事情而没有做它不应该做的事情
- 域测试 Domain Testing
- 描述： 专注于测试软件所处理的数据 divide and conquer the data
- 典型思路
- 找到产品处理的所有数据。看输出也看输入
- 决定哪些特殊的数据需要测试。考虑边界值、典型值、无效值和最佳代表数据
- 考虑数据的组合
- 压力测试 Stress Testing
- 描述：用极限行为和数据压迫软件。overwhelm the product
- 典型思路
- 寻找极易遭受挑战性数据和被限制的资源破坏的子系统或是功能
- 选择或创建有挑战性的数据或者资源限制条件进行测试。比如庞大或是复杂的数据结构，高负荷，持久测试，大规模测试用例和低内存条件
- 流测试 Flow Testing
- 描述： 测试软件的操作顺序。Do one thing after another
- 典型思路
- 测试多个活动串联以后端到端的流程。比如在状态模型中开展漫游测试
- 不要在活动中重设系统
- 改变时间线和顺序，试试并发
- 情景测试 Scenario Testing
- 描述： 用有说服力的场景来测试软件。Test to a compelling story
- 典型思路
- 开始时思考关于产品的一切
- 设计测试来覆盖与产品有意义的和复杂的互动
- 一个好的场景测试是一个引人注目的故事，这个故事涉及谁做了什么影响产品的事情
- 声明测试 Claims Testing
- 描述： Challenge every claim
- 典型思路
- 调查所有的声明，澄清所有的声明
- 鉴别所有关于产品的参考资料
- 测试关于产品声明的精准性
- 用户测试 User Testing
- 描述：Invovle the users
- 典型思路
- 识别用户的角色分类
- 识别每一类的用户分别会做什么事情，怎么做以及带来的用户价值是什么
- 获取真实的用户数据来进行测试
- 否则，系统性地模拟一个用户(这里有一个坑，就是你很容易自以为你就是真实的用户，而不是你并不是)
- 强有力的用户测试通常都会涉及多个不同类别的用户和不同的角色，并不是某一个
- 风险测试 Risk Testing
- 描述：Imagine a problem, then look for it
- 典型思路
- 这个产品可能会有什么样的问题
- 哪些问题最有严重或是最有可能性发生？先聚焦在这些问题
- 如果这些问题有可能发生，应该怎么去发现他们？
- 列出一个包含一些有趣问题的列表，然后设计测试去揭露他们
- 这个测试能帮助咨询专家，设计文档，历史缺陷报告或者启发风险
- 自动化检查 Automatic Checking
- 描述：Check a million different facts
- 典型思路
- 寻求或开发工具来做大量操作和检查大量结果
- 考虑能部分自动化测试覆盖率的工具
- 考虑能部分自动化测试先知的工具
- 考虑能够自动化感知变更的检测器
- 考虑能够自动化产生数据的创造器
- 考虑能够帮助人工测试的工具
项目环境(Project Environment)
项目环境包括项目资源、项目限制和其他一切都能影响测试的元素。有些时候测试人员需要挑战限制，有时需要接受它。测试总是受到项目环境的约束。有经验的测试人员会根据当前语境，选择合适的测试实践。
测试设计和测试执行是一个项目里测试活动最核心、最关键的部分，而这部分活动极易遭受项目环境的影响。我们的项目需要哪些测试？测试的内容应该是什么？每一部分的测试应该怎么执行？所以这些问题都需要了解到项目的情况。测试人员需要利用当前一切可以利用的资源来帮助测试活动的决定。下面列出一些关于项目环境关键词
- 使命 Mission
- 描述： 测试人员和其服务对象需要就测试人员的任务达成一致意见
- 典型问题： 你的客户或是干系人是谁？谁能做出重要决定？你知道你客户对你在项目上的期望是什么吗？
- 信息 Information
- 描述：测试需要的项目信息
- 典型问题：是不是有关于项目的资料、手册、用户故事和规格文档可用? 你的信息是最新的吗？竞品信息？
- 与开发的关系 Developer Relations
- 描述：你的与开发的关系。如何与开发协作以加速开发
- 典型问题：开发是凌驾于产品规格并且傲慢的吗？你和开发相处得如何？你能快速地与开发交流吗？
- 测试团队 Test Team
- 描述：谁会完成测试或支持测试。利用团队的力量支持测试
- 典型问题： 有谁会进行测试？人员足够吗？有谁能做支持？项目需要的特殊的测试技术有人能胜任吗？
- 设备和工具 Equipment & Tools
- 描述：可利用的硬件、软件和文档等资源
- 典型问题： 所有支持测试的硬件设备都准备好了吗？需要的测试工具都可用吗？
- 计划安排 Schedule
- 描述：项目事件的顺序、时长和同步。项目实施的流程。
- 典型问题：测试设计时间足够吗？测试什么时候被执行？用于测试的构建什么时候能准备好？
- 测试条目 Test Items
- 描述：被测试的产品。测试范围和重点
- 典型问题：产品哪部分需要测试？产品是不断变化的？产品的可测试性？产品最新的特性是什么？产品以后的交付计划是什么？
- 交付物 Deliverables
- 描述：测试项目的产出
- 典型问题：测试交付物也是产品的一部分吗？有哪些测试报告需要呈现？
产品元素（Product Element）
产品元素就是我们的测试对象。软件是复杂且不可见的，我们不能只是测试那些可见的部分。
产品最终会被已体验或是解决方案的形式呈现在客户面前。产品有很多维度，为了很好的测试，我们每个维度都需要检查。下面都是产品重要且唯一的维度。如果测试人员只专注在其中几个维度，很有可能有miss的重要bug
- 结构 Structure
- 描述：一切组成物理产品的部分
- 典型维度
- 代码： 组成产品的代码结构
- 硬件： 产品不可或缺的硬件
- 不可执行文件： 除开多媒体和程序的文件，比如文本文件、数据文件和帮助文件
- 附属物： 除开硬件和软件属于产品的一部分，比如纸质文档、链接和license
- 功能 Function
- 描述： 产品会完成的事情
- 典型维度
- 应用： 任何定义或是区别化产品或完成核心需求的功能
- 计算： 任何嵌入在功能里面的计算
- 时间相关： 比如超时设置、日报月报和每晚批处理作业等
- 转换： 修改或转移东西的功能。比如设置字体
- 启动和关闭： 比如唤醒和初始化产品以及推出产品的方法
- 多媒体： 比如产品中的音频和视频
- 错误处理： 监测错误和从错误中恢复的功能，包括错误信息
- 互动： 产品功能间的互动
- 可测试性： 任何能够帮助测试产品的东西
- 数据 Data
- 描述： 产品处理的数据
- 典型维度
- 输入： 被产品处理的数据
- 输出： 被产品处理后的结果数据
- 预先设置： 产品内建数据或是提供给产品的数据。比如默认值和预先设置好的数据库
- 持久： 被存储在产品内部并且会在多个模块操作中持续存在的数据。比如产品的模式或是状态：选项设置，视角模式等
- 顺序/组合： 被排序或是组合的数据。比如文字顺序和数据排序等
- 基数： 可能会被改变的对象或是字段数。还有像数据库键这样的唯一值
- 大/小： 大小的变化和数据汇总
- 噪音： 无效的、被污染的或是在错误的情况下产生的数据和状态
- 生命周期： 数据生命周期内增查改删的转化
- 接口 Interfaces
- 描述： 所有进入产品的渠道
- 典型维度
- 用户界面： 所有与用户进行数据交换的元素
- 系统界面： 所有除了与用户打交道的界面。比如硬盘或网络等
- API/SDK：通过产品可编程的接口和工具来开发其他新的应用
- 导入/导出：把数据打包给其他产品用的功能或是接受解释来自其他产品的数据
- 平台 Platform
- 描述： 项目的所有依赖，并不是项目本身的一部分
- 典型维度
- 外部硬件： 并不是属于产品交付部分的硬件组件和配置，但是需要他们使得产品能够正常工作。比如服务器，硬盘和键盘灯
- 外部软件： 并不是属于产品交付部分的软件组件和配置，但是需要他们使得产品能够正常工作。比如操作系统
- 内部组件： 来自于外部开发的，但是嵌入在产品中的库或是组件
- 操作 Operations
- 描述： 产品是怎么被使用的
- 典型维度
- 用户： 不同用户的属性
- 环境： 产品运行时的物理环境
- 通用用法： 产品最典型的操作模式和顺序。根据用户的不同而不同
- 不赞同用法： 由无知、错误、粗心和恶意使用产生的输入模式
- 极限用法：挑战产品的通用用法
- 时间 Time
- 描述： 产品和时间的关系
- 典型维度
- 输出/输出： 什么时候输入被提供？什么时候输出被创建？输入输出中任何关于时间的关系，比如延迟、间隔
- 快/慢： 最快和最慢，快慢的组合
- 改变速率： 加速减速，暂停，干扰，瓶颈
- 并发： 同时发生多件事情。比如多用户、共享数据等
质量标准(Quality Criteria)
质量标准就是帮助测试人员判断产品是否有问题的规则和来源。质量标准定义了产品应该做什么。通过不同类型的标准，你可以更好的计划测试来快速挖掘重要的问题。下面列出的维度都可以被当做潜在的风险区域。
对于下面的维度，请先决定它是否对你所在项目的重要性，然后思考怎么识别产品是正确地的在工作。
- 能力 Capability
- 描述: 产品能否完成期望的功能。Can it perform the required functions?
- 可靠性 Reliability
- 描述: 产品能否在期望的条件下稳定的工作。Will it work and resist failure in all requried situations?
- 思考维度
- 健壮性 Robustness: 在合理的情况下，产品能够持续的超时工作，不出现退化
- 错误处理 Error handling：产品在出现错误的情况下能够应付失败，优雅地处理错误，稳定地恢复
- 数据完整性 Data integrity： 产品中的数据能够不被丢失或被污染
- 安全性 Safty：产品不能由于失败而对人生财产造成损害
- 可用性 Usability
- 描述：真实用户能否顺利的使用产品。How easy is it for a real user to use the product?
- 典型维度
- 易学性 Learnability: 产品的操作能够被有意的用户快速掌握
- 可操作性 Operability: 产品的操作不需要太多努力适应，也不会让人忙乱
- 可达性 Accessibility: 产品达到先关的可达性的标准
- 魅力 Charisma
- 描述：产品是否光彩夺目。How appealing is the product?
- 典型维度
- 美学 Aesthetics
- 独特性 Uniqueness： 产品是新的或者在某一方面是独一无二的
- 必然性 Necessity： 产品拥有用户所期待的功能
- 有效性 Usefulness： 产品解决了一些重要的问题，并且处理得很好
- 狂喜 Entrancement： 用户在使用产品时被“套牢”，非常开心，完全沉浸在产品的使用当中
- 想象 image：产品表达了对质量要求的印象
- 安全性 Security
- 描述：产品能否抵御恶意攻击 How well is the product protected against unauthorized use or intrusion?
- 典型维度
- 认证 authentication：系统验证用户真实性的方法
- 授权 authorization：给认证过的用户相应的权利
- 隐私 privacy：用户数据的保护
- 安全漏洞 Security holes： 系统不能实施安全
- 可扩展性 scalability
- 描述：产品能否自如地使用软硬件资源。How well does the deployment of the product scale up or down?
- 兼容性 Compatibility
- 描述：产品能否与外部组件和配置协同工作。How well does it work with external components & configurations?
- 典型维度
- 应用兼容 Application Compatibility: 产品和其他软件一起工作
- 操作系统兼容 Operating System Compatibility：产品和特定的操作系统一起工作
- 硬件兼容 Hardware Compatibility: 产品和特定的硬件组件和配置一起工作
- 向后兼容 Backward Compatibility: 产品和之前版本的产品一起工作
- 资源使用 Resource Usage: 产品不会耗费太多资源比如存储、内存等系统资源
- 性能 Performance
- 描述：产品的速度和响应时间如何？How speedy and responsive is it?
- 可安装性 Installability
- 描述：产品是否易于安装。How easily can it be installed onto its target platforms?
- 典型维度
- 系统需求 System requirements: 产品是否能识别有些必要的组件丢失或不足？
- 配置 Configuration: 系统的哪些部分会被安装影响？文件和资源会被存储在哪里？
- 卸载 Uninstallation: 什么时候产品会被卸载？会被完整删除吗？
- 升级 Upgrade/patches: 新版本能够很容易的增加吗?
- 管理 Administration: 安装流程会被特定的专员还是计划来处理？
- 面向研发团队的特性 Developement
- 描述：研发团队能否方便地编写、测试和修改软件。How well can we create, test, and modify it?
- 典型维度
- 可支持性 Supportability: 能够很好的给产品用户提供支持吗？
- 可测试性 Testability: 产品可以有效地被测试吗？
- 可维护性 Maintainability: 产品可以很好地被构建，修复或增强吗?
- 可移植性 Portability: 产品技术可以在其他地方重用吗？
- 本地化 Localizability: 产品在其他地方的适应性？
观察到的质量(Perceived Quality)
观察到的质量就是测试结果。你永远不可能知道真实的软件产品质量是什么样的，但是你通过一系列的测试能做出评估。
怎么运用HTSM
HTSM由一组指导词组成，从四个不同的角度出发形成了一个模型框架。这个模型可以让测试人员对自己项目和产品有一个从高层抽象到底层细节的系统性思考。这些指导词的作用不是教你怎么测试，而是启发测试人员的思维，发掘测试对象和测试策略。
怎么才能高效的运用此模型来进行适合自己项目和产品的测试设计呢? 可以参考下面的建议：
- 通过HTSM先得出一个适用于自己项目的定制的HTSM。定制HTSM也是应用HTSM的过程。
- HTSM是一个大而全的通用模型，并不适用于所有的IT项目。测试人员应该修改HTSM，以获得符合项目语境的模型。
- 通常我们可以
- 增加我们认为值得考虑的因素
- 删除一些不适用于待测产品或项目的因素
- 增加标记、注释、链接等元素。标记可以突显重要的元素，注释可以增加更多的细节，链接可以指向更详细的信息源
- 对于每个因素，我们可以自问
- 该元素与当前测试任务相关吗？
- 针对该元素，产品会有什么样的风险？可能有什么样的缺陷？危害程度和发生可能性是多少? (风险驱动，分析每个元素的风险)
- 需要什么样的测试可以发现这些缺陷？(针对每个风险，采取的测试手段是什么)
- 依据当前的进度和资源，如何实施这些测试？
- 结合多个元素，一起进行测试设计，开发测试策略
- 在项目启动阶段
- 质量标准启发测试先知
- 项目环境启发测试过程
- 产品元素启发测试覆盖
- 在制订测试计划时，它可以帮助测试人员完整地思考产品，从而产生系统性的测试计划
- 在测试分析阶段
- 帮助测试人员组合测试想法、深入探索产品，以开发出强有力的测试策略
- 在测试执行阶段
- 在回归测试中，它可以帮助测试人员确定测试范围，制定测试方案
- 在测试报告阶段
- 每个测试技术实施后观察到的质量就是很好的测试报告
