测试，没有分析与设计就失去了灵魂；

测试人员在编写用例之前，该如何进行测试分析与设计呢？上次在《测试的底层逻辑》中讲到了【输入输出测试模型】，还讲到了【2W+1H测试分析法】，但2W1H分析法是初步的分析方法，具体在测试中如何落地，还需要更细的设计。

今天就给大家介绍一下由测试领域专家James Batch总结的测试分析与设计模型，HTSM启发式测试策略模型。

什么是HTSM？

HTSM是一套测试思路启发的方法，旨在帮助测试人员更好地思考测试策略，指导测试人员在进行测试分析和设计的时候如何去思考，思考哪些点。HTSM包括四个重点领域：测试技术、项目环境、产品元素和质量标准。James Batch建议：你可以随意地使用它们，它对任何类型的软件都是通用的，另外在落地应用的时候，建议根据实际场景调整模型的内容，以适应自己的组织环境。

James Batch原文解释：The 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和2W1H分析法进行的对比，通过对比可以看出HTSM可以与2W1H进行对应，通过分析项目环境，了解为什么测试这个项目，了解项目背景；通过分析产品元素，确定了我们的测试范围，明确我们要测什么；然后通过测试技术和质量标准指导了我们该怎么去测。

HTSM与２W１H对比：

HTSM模型概览：

在HTSM模型中，项目环境、产品元素、质量标准、测试技术每一项都列出了很多子项；其中【项目环境】和【产品元素】不需要按照模型提供的子项进行全量的分析，所以大家可以作为参考，挑选对自己有用的信息进行分析即可。

我也会结合自己的经验增加一些内容；【质量标准】和【测试技术】参考的价值会更大一些，我对原文进行了详细的翻译；因为只是模型，所以作者也不会对每一种测试方法或测试标准进行详细的讲解说明，只是作者根据他的经验进行的总结，大家都可以结合自己的经验总结更具体的方法；但测试技术和质量标准的每一个子项是可以作为测试人员进行测试设计的参考标准，质量标准也可以参考ISO9126软件质量模型。

总之，模型不是详细的知识讲解，而是指导大家进行测试分析和设计的思路方法集合。

ISO9126软件质量模型

下面分别讲解HTSM的四个领域：项目环境、产品元素、质量标准、测试技术。大家也可以按照这个顺序去使用HTSM，按照2W1H的方法去分析，参考HTSM提供的子项和经验，最终形成完整的测试方案。

测试第一步：【项目环境】，测试之前一定要先了解项目背景，了解我们为什么做这个项目？

项目产生背景： 为什么要做这个项目？项目产生的背景原因是什么？

所解决的问题： 这个项目解决了什么问题？

通过了解背景，能够更好的帮助我们分析需求，了解最原始的需求和目的；了解了最原始的需求，才能去分析PRD中的功能设计是否能够满足用户最原始的需求，也才能更好的理解业务，理解需求，从而可以去挖掘需求文档中存在的问题或不足。

项目所属级别： 是战略项目？还是技术维护升级项目？了解项目的级别也就是重要程度，也决定了我们应该投入的资源；对质量的要求是什么级别，用户对质量的要求是什么样的。

项目期望完成的时间： 对完成时间的了解，可以决定我们后续会采取什么样的测试策略，哪些测试方法是必须采用的，哪些可以不用或者上线后再使用等等。比如时间特别紧张，最重要的还是要保障功能，其他性能可以根据上线的方案决定；是一上线就会有大量用户使用还是只有少部分种子用户；兼容性是否可以上线后进行，还是说针对C端的，兼容性必须保障；自动化测试可能就无法做了，也或者自动化技术已经非常成熟，有录制相关的工具，且经验丰富，那这个时候自动化录制工具或录制回放工具就可以起到很大的作用。

系统用户情况： 系统的用户是谁？用户量有多大？关注用户量，第一是了解系统是否有性能压测方面的需求，第二是了解系统的用户量级是几个，几十个、几百个人还是成千上万？用户的数量不同，他的价值必然不同。

系统客户是谁： 系统的客户是谁？客户最原始的述求是什么？

下面的是HTSM【项目环境】的具体内容，部分内容我做了补充和调整。

测试第二步：【产品元素】，就是我们计划要测试的内容；测试人员必须保证覆盖所有的产品元素，而且不仅仅是我们所看到的部分。

产品最终就是为客户提供的一种经验或解决方案；产品有多个维度，要测试好，我们覆盖的维度必须要全面。每一个维度都代表了产品独特的一个面 。如果测试只是覆盖了一部分，就有可能错过严重的bug。 分析产品的元素，就是分析我们的测试范围，有哪些方面或内容是需要我们测试的。一般人确定测试范围都来自于需求文档，其实需求文档之外还有很多东西需要我们关注，需要我们测试。下面是HTSM的【产品元素】：

HTSM模型【产品元素】列出的内容比较多，也比较复杂，这些内容可以作为我们的参考，绝不是要求完全按照下面的内容进行测试。

Structure结构：产品所包括的一切；

这一部分我觉得是我们最容易忽略的，我们大部分时间都是在测试软件，硬件部分很容易忽略；另外容易忽略的就是非执行文件，例如帮助文档、许可协议等，这些虽然很多都是业务提供，但出于对公司负责、对产品负责、对用户负责，我们还是需要再检查一下这些非执行的文档；帮助文档是否简单易懂，是否有缺失，是否有错误或与系统功能不符；因为上线前对系统最熟悉的不是产品经理，也不是研发，而是测试人员。

另外分享一下我的一些经验；首先，测试范围的确定是非常重要的，大部分人会忽略这一步，这样就有可能会导致漏测。这一步容易忽略，是因为我们的测试依据就是PRD，所以测试范围都在PRD里；但实际情况是，大部分测试范围都在PRD里，还有一部是在设计文档中，或者在文档之外。

对于从0开始的新项目，可以从两个角度去考虑测试范围：

一、产品角度，通过分析PRD基本就够了；当然有些内容PRD可能也会疏忽遗漏，我们就需要对需求进行分析，挖掘出可能存在的隐性需求。

二、技术角度，除了用户看到的可以操作的功能，有些功能是用户无法直接用到的，或者是给其他系统技术开发用户使用的；例如对外提供的接口服务、系统后台异步处理的任务、定时执行的任务、上线前刷的基础数据、前置数据等。

从1.X到1.（X+1）或2.0的升级维护项目：

除了正常的测试范围评估，最重要也是最难的就是回归测试范围的评估了，也就是对原有系统的影响范围是最难评估的。

对于回归测试范围的确定，其实就是成本与质量的博弈；对于质量要求非常高的软件，每一次测试都会要求进行全量的回归，所以这种场景下，自动化回归测试是非常重要的；对时间要求非常紧急质量风险可承受或可控的，回归范围可以缩小到本次修改的相关功能即可；但大部分场景是时间要求比较紧，但质量也不能出现问题。这时如何圈定范围，首先是本次修改的相关功能的回归必不可少；其次就是要守住系统的底线，也就是确定这个系统哪些功能是不能出问题的，这些功能就需要作为这个系统每一次回归的必选范围。另外还可以通过代码diff的功能，分析本次改动点，影响到的功能。

除了功能回归范围的评估，对于升级项目，一定要注意对原有数据的兼容验证；大概有以下几种情况：

1）功能变化，对原有进行中的数据的操作是否会影响；

2）流程变化，对流程中的数据或驳回重新提交的数据是否可以正常进行；

3）数据传输对象（PO、VO、DTO等）发生变化，进行中的数据或重新编辑后的数据是否能正常操作，最主要时要验证数据的传输或存储。

4）底层数据库表发生变化，是否影响原有数据的展示、操作；新增字段是否需要刷数；刷数后功能是否正常。