测试人员在编写用例之前，该如何进行测试分析与设计呢？上次在《测试的底层逻辑》中讲到了【输入输出测试模型】，还讲到了【2W+1H测试分析法】，但2W1H分析法是初步的分析方法，具体在测试中如何落地，还需要更细的设计。
什么是HTSM
HTSM是一套测试思路启发的方法，旨在帮助测试人员更好地思考测试策略，指导测试人员在进行测试分析和设计的时候如何去思考，思考哪些点。HTSM包括四个重点领域：测试技术、项目环境、产品元素和质量标准。James Batch建议：你可以随意地使用它们，它对任何类型的软件都是通用的，另外在落地应用的时候，建议根据实际场景调整模型的内容，以适应自己的组织环境。
Heuristic Test Strategy Model is a set of patterns for designing and choosing tests to perform. The immediate purpose of this model is to remind testers of what to think about during that process。
HTSM与２W１H对比：
HTSM模型概览：
我也会结合自己的经验增加一些内容；【质量标准】和【测试技术】参考的价值会更大一些，我对原文进行了详细的翻译；因为只是模型，所以作者也不会对每一种测试方法或测试标准进行详细的讲解说明，只是作者根据他的经验进行的总结，大家都可以结合自己的经验总结更具体的方法；但测试技术和质量标准的每一个子项是可以作为测试人员进行测试设计的参考标准，质量标准也可以参考ISO9126软件质量模型。
ISO9126软件质量模型
测试第一步：【项目环境】，测试之前一定要先了解项目背景，了解我们为什么做这个项目
项目产生背景： 为什么要做这个项目？项目产生的背景原因是什么？
所解决的问题： 这个项目解决了什么问题？
项目所属级别： 是战略项目？还是技术维护升级项目？了解项目的级别也就是重要程度，也决定了我们应该投入的资源；对质量的要求是什么级别，用户对质量的要求是什么样的。
项目期望完成的时间： 对完成时间的了解，可以决定我们后续会采取什么样的测试策略，哪些测试方法是必须采用的，哪些可以不用或者上线后再使用等等。比如时间特别紧张，最重要的还是要保障功能，其他性能可以根据上线的方案决定；是一上线就会有大量用户使用还是只有少部分种子用户；兼容性是否可以上线后进行，还是说针对C端的，兼容性必须保障；自动化测试可能就无法做了，也或者自动化技术已经非常成熟，有录制相关的工具，且经验丰富，那这个时候自动化录制工具或录制回放工具就可以起到很大的作用。
系统用户情况： 系统的用户是谁？用户量有多大？关注用户量，第一是了解系统是否有性能压测方面的需求，第二是了解系统的用户量级是几个，几十个、几百个人还是成千上万？用户的数量不同，他的价值必然不同。
系统客户是谁： 系统的客户是谁？客户最原始的述求是什么？
测试第二步：【产品元素】，就是我们计划要测试的内容；测试人员必须保证覆盖所有的产品元素，而且不仅仅是我们所看到的部分
。如果测试只是覆盖了一部分，就有可能错过严重的bug。 分析产品的元素，就是分析我们的测试范围，有哪些方面或内容是需要我们测试的。一般人确定测试范围都来自于需求文档，其实需求文档之外还有很多东西需要我们关注，需要我们测试。下面是HTSM的【产品元素】：
Structure结构：产品所包括的一切；
另外分享一下我的一些经验；首先，测试范围的确定是非常重要的，大部分人会忽略这一步，这样就有可能会导致漏测。这一步容易忽略，是因为我们的测试依据就是PRD，所以测试范围都在PRD里；但实际情况是，大部分测试范围都在PRD里，还有一部是在设计文档中，或者在文档之外。
对于从0开始的新项目，可以从两个角度去考虑测试范围：
一、产品角度，通过分析PRD基本就够了；当然有些内容PRD可能也会疏忽遗漏，我们就需要对需求进行分析，挖掘出可能存在的隐性需求。
二、技术角度，除了用户看到的可以操作的功能，有些功能是用户无法直接用到的，或者是给其他系统技术开发用户使用的；例如对外提供的接口服务、系统后台异步处理的任务、定时执行的任务、上线前刷的基础数据、前置数据等。
从1.X到1.（X+1）或2.0的升级维护项目：
对于回归测试范围的确定，其实就是成本与质量的博弈；对于质量要求非常高的软件，每一次测试都会要求进行全量的回归，所以这种场景下，自动化回归测试是非常重要的；对时间要求非常紧急质量风险可承受或可控的，回归范围可以缩小到本次修改的相关功能即可；但大部分场景是时间要求比较紧，但质量也不能出现问题。这时如何圈定范围，首先是本次修改的相关功能的回归必不可少；其次就是要守住系统的底线，也就是确定这个系统哪些功能是不能出问题的，这些功能就需要作为这个系统每一次回归的必选范围。另外还可以通过代码diff的功能，分析本次改动点，影响到的功能。
一定要注意对原有数据的兼容验证；大概有以下几种情况：
2）流程变化，对流程中的数据或驳回重新提交的数据是否可以正常进行；
4）底层数据库表发生变化，是否影响原有数据的展示、操作；新增字段是否需要刷数；刷数后功能是否正常。
测试第三步：【质量标准】，确定具体的测试策略，明确系统应该进行什么类型的测试；
功能性（Capability） ：系统功能是否正确，是否满足了用户需求？
可靠性（Reliability） ：在任何情况下是否都可以正常工作？
-
健壮性（容错性） ：系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。
- 错误处理： 产品在出现坏数据的情况下能够抵抗失败，在失败时能保持优雅，并易于恢复。（在失败时，也能够给出准确的提示信息，并告知用户如何进行处理解决）
- 数据完整性： 系统中的数据是受保护的，不会发生数据丢失或数据损坏。
- 安全性： 系统发生故障后，不会造成较大金额上的损失。
易用性（Usability）： 真实用户使用产品是否很容易？
-
易学性： 产品的操作可以被⽬标⽤⼾快速掌握
- 易操作： 产品可以轻松操作
- 可访问： 产品符合相关的可访问性标准，并与 O/S 可访问性功能配合使⽤。
安全性（ Security ）： 产品对未经授权的使⽤或⼊侵的保护程度如何？
-
身份验证： 登录用户是否经过系统验证
- 授权： 用户的权限是否进行了控制，根据不同角色或级别进行授权
- 隐私： 客⼾或员⼯数据是否进行了加密保护
可扩展性（ Scalability ）： 是否有合理的规划，应对系统的增长（数据量、流量、复杂性）
兼容性（ Compatibility ）： 与外部的组件以及配置等是否可以兼容，正常工作？在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常的运行。
-
应⽤程序兼容性： 该产品与其他软件产品是否可以协同⼯作。
- 操作系统兼容性： 产品是否能够在不同类型的操作系统中工作。
- 浏览器的兼容性： 产品是否能够兼容不同类型、不同版本的浏览器。
- 硬件兼容性： 该产品适⽤于特定的硬件组件和配置。
- 向后兼容性： 产品可与⾃⾝的早期版本是否可以同时使⽤，数据、功能是否能够兼容。
性能（ Performance ）： 系统的响应速度是否够快？
易安装性（ Installability ）： 系统是否能够很容易得安装到对应的平台。
-
系统要求： 产品是否能够识别某些必要组件缺失或不⾜？
- 配置： 系统的哪些部分会受到安装的影响？⽂件和资源存储在哪里？
- 卸载： 产品卸载时，是否能够清除干净？
- 升级/补丁： 可以轻松添加新模块或升级新版本吗？他们是否会影响现有的配置吗？
- 管理： 安装是否是由专⻔的管理⼈员处理，还是按照特殊的时间表进行的？
易维护性（ Development ）： 系统是否容易进行开发、测试、维护？
-
可测试性： 是否可以用尽可能简单的方法进行快速测试
-
可维护性： 构建、修复或增强产品的难易程度及成本如何？
-
可移植性： 在其他地⽅移植或复⽤该技术的经济性如何？
-
可本地化： 将产品应⽤于其他地⽅的经济性如何？
可⽀持性： 是否可以以较低的成本向产品用户提供协助支持
测试第四步：【测试技术】，确定我们怎么来测，通过哪些手段、方法进行测试，以保障系统的质量符合质量标准、要求
Function Testing功能测试： 对产品的各功能进行验证，根据_功能测试_用例，逐项测试，检查产品是否达到用户要求的功能。
Claims Testing 约束测试： 挑战每⼀项声明！保证用户看到的任何资料中提到的功能的正确性及一致性。
2）参照上面的资料，测试产品的每⼀项声明
Flow Testing 流测试：按照一定的顺序操作执行的测试
-
在相关操作或处理间不要重设系统
Domain Testing领域测试：
2）确定测试采用的数据进行测试。例如边界值、典型值、常用值、无效值、以及最具代表性的值。
Scenario Testing场景测试
2）设计测试用例，包括对产品有意义的功能，以及复杂交互的场景
Stress Testing压力测试
2）识别与这些⼦系统和功能相关的数据和资源；
Automatic Checking自动化测试
Risk Testing风险测试
２）哪种问题出现的可能性会最多？专注于这些出现几率较多的问题
４）列出这些问题并设计相应的测试用例，专门用来挖掘他们
User Testing用户测试
2）确定每个类别的用户日都都会做什么操作，他们一般会如何操作，他们重点使用的功能有哪些？
4）系统地模拟真实用户使用场景（虽然你不是真实用户，但也很容易把自己想象成用户去使用）
作者：京东零售 张强
内容来源：京东云开发者社区