Tech导读
测试，没有分析与设计就失去了灵魂；
测试人员在编写用例之前，该如何进行测试分析与设计呢？本文将介绍由测试领域专家James Batch总结的测试分析与设计模型，HTSM启发式测试策略模型。
(me)>
01 什么是HTSM
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！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.
图1.HTSM概念示意下面是HTSM和2W1H分析法进行的对比，通过对比可以看出HTSM可以与2W1H进行对应，通过分析项目环境，了解为什么测试这个项目，了解项目背景；通过分析产品元素，确定了测试范围，明确要测什么；然后通过测试技术和质量标准指导该怎么去测。
02 HTSM与2W1H对比
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
03 HTSM模型概览
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。在HTSM模型中，项目环境、产品元素、质量标准、测试技术每一项都列出了很多子项；其中【项目环境】和【产品元素】不需要按照模型提供的子项进行全量的分析，所以大家可以作为参考，挑选对自己有用的信息进行分析即可；也会结合个人的经验增加一些内容；【质量标准】和【测试技术】参考的价值会更大一些，对原文进行了详细的翻译；因为只是模型，所以作者也不会对每一种测试方法或测试标准进行详细的讲解说明，只是作者根据他的经验进行的总结，大家都可以结合自己的经验总结更具体的方法；但测试技术和质量标准的每一个子项是可以作为测试人员进行测试设计的参考标准，质量标准也可以参考ISO9126软件质量模型。总之，模型不是详细的知识讲解，而是指导大家进行测试分析和设计的思路方法集合。
04 ISO9126软件质量模型
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目图4.ISO9126软件质量模型示意（备注：图片来源百度图片）下面分别讲解HTSM的四个领域：项目环境、产品元素、质量标准、测试技术。大家也可以按照这个顺序去使用HTSM，按照2W1H的方法去分析，参考HTSM提供的子项和经验，最终形成完整的测试方案。
05 测试第一步：【项目环境】
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。测试之前一定要先了解项目背景，了解我们为什么做这个项目？
项目产生背景：为什么要做这个项目？项目产生的背景原因是什么？通过了解背景，能够更好的帮助我们分析需求，了解最原始的需求和目的；了解了最原始的需求，才能去分析PRD中的功能设计是否能够满足用户最原始的需求，也才能更好的理解业务，理解需求，从而可以去挖掘需求文档中存在的问题或不足。项目所属级别：是战略项目？还是技术维护升级项目？了解项目的级别也就是重要程度，也决定了应该投入的资源；对质量的要求是什么级别，用户对质量的要求是什么样的。项目期望完成的时间：对完成时间的了解，可以决定后续会采取什么样的测试策略，哪些测试方法是必须采用的，哪些可以不用或者上线后再使用等等。比如时间特别紧张，最重要的还是要保障功能，其他性能可以根据上线的方案决定；是一上线就会有大量用户使用还是只有少部分种子用户；兼容性是否可以上线后进行，还是说针对C端的，兼容性必须保障；自动化测试可能就无法做了，也或者自动化技术已经非常成熟，有录制相关的工具，且经验丰富，那这个时候自动化录制工具或录制回放工具就可以起到很大的作用。系统用户情况：系统的用户是谁？用户量有多大？关注用户量，第一是了解系统是否有性能压测方面的需求，第二是了解系统的用户量级是几个，几十个、几百个人还是成千上万？用户的数量不同，他的价值必然不同。系统客户是谁：系统的客户是谁？客户最原始的述求是什么？下面的是HTSM【项目环境】的具体内容，部分内容做了补充和调整。
06 测试第二步：【产品元素】
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。测试人员必须保证覆盖所有的产品元素，而且不仅仅是我们所看到的部分。
产品最终就是为客户提供的一种经验或解决方案；产品有多个维度，要测试好，我们覆盖的维度必须要全面。每一个维度都代表了产品独特的一个面。如果测试只是覆盖了一部分，就有可能错过严重的bug。分析产品的元素，就是分析测试范围，有哪些方面或内容是需要测试的。一般人确定测试范围都来自于需求文档，其实需求文档之外还有很多东西需要关注，需要测试。下面是HTSM的【产品元素】：HTSM模型【产品元素】列出的内容比较多，也比较复杂，这些内容可以作为参考，绝不是要求完全按照下面的内容进行测试。
图6.HTSM模型【产品元素】的内容
这一部分我觉得是最容易忽略的，大部分时间都是在测试软件，硬件部分很容易忽略；另外容易忽略的就是非执行文件，例如帮助文档、许可协议等，这些虽然很多都是业务提供，但出于对公司负责、对产品负责、对用户负责，还是需要再检查一下这些非执行的文档；帮助文档是否简单易懂，是否有缺失，是否有错误或与系统功能不符；因为上线前对系统最熟悉的不是产品经理，也不是研发，而是测试人员。另外分享一下一些经验；首先，测试范围的确定是非常重要的，大部分人会忽略这一步，这样就有可能会导致漏测。这一步容易忽略，是因为测试依据就是PRD，所以测试范围都在PRD里；但实际情况是，大部分测试范围都在PRD里，还有一部分是在设计文档中，或者在文档之外。对于从0开始的新项目，可以从两个角度去考虑测试范围：一、产品角度，通过分析PRD基本就够了；当然有些内容PRD可能也会疏忽遗漏，就需要对需求进行分析，挖掘出可能存在的隐性需求。二、技术角度，除了用户看到的可以操作的功能，有些功能是用户无法直接用到的，或者是给其他系统技术开发用户使用的；例如对外提供的接口服务、系统后台异步处理的任务、定时执行的任务、上线前刷的基础数据、前置数据等。除了正常的测试范围评估，最重要也是最难的就是回归测试范围的评估了，也就是对原有系统的影响范围是最难评估的。对于回归测试范围的确定，其实就是成本与质量的博弈；对于质量要求非常高的软件，每一次测试都会要求进行全量的回归，所以这种场景下，自动化回归测试是非常重要的；对时间要求非常紧急质量风险可承受或可控的，回归范围可以缩小到本次修改的相关功能即可；但大部分场景是时间要求比较紧，但质量也不能出现问题。这时如何圈定范围，首先是本次修改的相关功能的回归必不可少；其次就是要守住系统的底线，也就是确定这个系统哪些功能是不能出问题的，这些功能就需要作为这个系统每一次回归的必选范围。另外还可以通过代码diff的功能，分析本次改动点，影响到的功能。除了功能回归范围的评估，对于升级项目，一定要注意对原有数据的兼容验证；大概有以下几种情况：1）功能变化，对原有进行中的数据的操作是否会影响；2）流程变化，对流程中的数据或驳回重新提交的数据是否可以正常进行；3）数据传输对象（PO、VO、DTO等）发生变化，进行中的数据或重新编辑后的数据是否能正常操作，最主要时要验证数据的传输或存储。4）底层数据库表发生变化，是否影响原有数据的展示、操作；新增字段是否需要刷数；刷数后功能是否正常。
07 测试第三步：【质量标准】
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。确定具体的测试策略，明确系统应该进行什么类型的测试；
质量标准就是产品定义的应该满足的一些要求，测试人员判断一个系统是否验证通过的规则；通过考虑不同类型的标准，你可以更好地规划测试，并可以快速发现重要问题。下面的每一个类型都可以被视为是潜在的风险区域。功能性（Capability）：系统功能是否正确，是否满足了用户需求？可靠性（Reliability）：在任何情况下是否都可以正常工作？健壮性（容错性）：系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。错误处理：产品在出现坏数据的情况下能够抵抗失败，在失败时能保持优雅，并易于恢复。（在失败时，也能够给出准确的提示信息，并告知用户如何进行处理解决）数据完整性：系统中的数据是受保护的，不会发生数据丢失或数据损坏。安全性：系统发生故障后，不会造成较大金额上的损失。
易用性（Usability）：真实用户使用产品是否很容易？可访问：产品符合相关的可访问性标准，并与 O/S 可访问性功能配合使⽤。
安全性（Security）：产品对未经授权的使用或入侵的保护程度如何？授权：用户的权限是否进行了控制，根据不同角色或级别进行授权隐私：客户或员工数据是否进行了加密保护
可扩展性（Scalability）：是否有合理的规划，应对系统的增长（数据量、流量、复杂性）兼容性（Compatibility）：与外部的组件以及配置等是否可以兼容，正常工作？在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常的运行。应用程序兼容性：该产品与其他软件产品是否可以协同⼯作。操作系统兼容性：产品是否能够在不同类型的操作系统中工作。浏览器的兼容性：产品是否能够兼容不同类型、不同版本的浏览器。向后兼容性：产品可与自身的早期版本是否可以同时使用，数据、功能是否能够兼容。
性能（Performance）：系统的响应速度是否够快？性能测试很多时候是由专门的性能测试人员负责，但作为功能测试人员也一定要关注；性能测试除了常见的并发压测，其实更多的场景是由于系统的数据量大，最终导致查询、导入、导出等功能响应很慢；尤其再同时发生并发，或多任务并行，最终就很有可能导致一个导出任务，需要几天之后才能完成。易安装性（Installability）：系统是否能够很容易得安装到对应的平台。系统要求：产品是否能够识别某些必要组件缺失或不足？配置：系统的哪些部分会受到安装的影响？⽂件和资源存储在哪里？升级/补丁：可以轻松添加新模块或升级新版本吗？他们是否会影响现有的配置吗？管理：安装是否是由专门的管理人员处理，还是按照特殊的时间表进行的？
易维护性（Development）：系统是否容易进行开发、测试、维护？可支持性：是否可以以较低的成本向产品用户提供协助支持可维护性：构建、修复或增强产品的难易程度及成本如何？可移植性：在其他地方移植或复用该技术的经济性如何？
08 测试第四步：【测试技术】
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。确定我们怎么来测，通过哪些手段、方法进行测试，以保障系统的质量符合质量标准、要求。
测试技术就是进行测试的策略分析，常用的测试技术有下面九种。Function Testing功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。Claims Testing 约束测试：挑战每一项声明！保证用户看到的任何资料中提到的功能的正确性及一致性。1）明确相关的参考资料，如 SLA、广告、说明书、 帮助文本、操作手册等 ；（SLA一般指服务级别协议。服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。）2）参照上面的资料，测试产品的每⼀项声明
Flow Testing 流测试：按照一定的顺序操作执行的测试3) 改变时间和顺序，并且进行并发操作
2）确定测试采用的数据进行测试。例如边界值、典型值、常用值、无效值、以及最具代表性的值。 2）设计测试用例，包括对产品有意义的功能，以及复杂交互的场景 3）一个好的场景测试是一个引人入胜的故事，讲述一个重要的人如何 做一些对他来说很重要的操作 1）确定压测的范围，这个子系统或功能可能会承受量非常大的数据压力，或由于资源受限，出现大并发导致系统过载或“损坏”； 3）选择或生成具有挑战性的数据，或限定条件下的资源；例如，大型或复杂的数据结构、高负载、长时间的测试运行、大量测试用例的执行、低内存情况下运行１）思考产品可能会出现哪些问题、风险？
２）哪种问题出现的可能性会最多？专注于这些出现几率较多的问题
３）如果它们存在，你将如何检测并发现它？
４）列出这些问题并设计相应的测试用例，专门用来挖掘他们
５）另外还可以咨询相关的专家、查看设计文档、过去的缺陷报告或应用风险启发式方法，这些可能都会有所帮助
2）确定每个类别的用户都会做什么操作，他们一般会如何操作，他们重点使用的功能有哪些？3）获取真实的用户数据，或引⼊真实的用户，提前使用系统进行测试4）系统地模拟真实用户使用场景（虽然你不是真实用户，但也很容易把自己想象成用户去使用）5）最好的用户测试是涉及多种用户角色，并且多用户并行、交叉操作，不仅仅是单一一种用户或一个用户操作。
09 结束语
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。测试模型，是测试专家通过多年的经验总结出来的一套可复用的方法原则；通过学习别人总结的测试方法，就相当于站在巨人的肩膀上，可以以更高的视角去看待眼前的问题；当然任何别人的沉淀也是需要不断的去消化，并不是看完一遍就一定会有飞跃的提升；也必须要有不断地实践总结，直到消化吸收才能变成自己的。
比如HTSM模型第一步，需要了解项目的环境、背景，这一步是否能体验到他的价值，也还要看对自己的定位；自己的定位是测试工程师还是测试1号位？测试1号位其实除了团队赋予的职责和权力，在没有授权的情况下，自己也是可以赋予自己这个职责的；只有自己把自己放在1号位，通过更高的视角，才能发现不一样的问题，也才能真正起到质量保障的作用。
测试中，主动站在1号视角，去了解项目的背景、用户、使用场景，项目能为用户解决什么问题，能够为用户带来什么价值；这样下一步就需要考虑当前系统是否能满足用户，满足用户的场景，是否能解决用户的问题,系统的易用性、性能等各种质量指标怎么样；只要把自己放到1号位视角，你就可以考虑得更全面，HTSM测试模型也才会更有价值；站得更高，看得更远；HTSM就可以帮助大家站在测试专家的视角，让大家以更专业的角度去测试分析与设计，以帮助大家更快速的成长。
打造SAAS化服务的会员徽章体系，可以作为标准的产品化方案统一对外输出。结合现有平台的通用能力，实现会员行为全路径覆盖，并能结合企业自身业务特点，规划相应的会员精准营销活动，提升会员忠诚度和业务的持续增长。▪底层能力：维护用户基础数据、行为数据建模、用户画像分析、精准营销策略的制定▪功能支撑：会员成长体系、等级计算策略、权益体系、营销底层能力支持
▪用户活跃：会员关怀、用户触达、活跃活动、业务线交叉获客、拉新促活