启发式测试策略模型HTSM在面向车车通信ATS上的应用

谢娟 朱程辉 刘锦峰

（卡斯柯信号有限公司 上海市 200072）

随着铁路信号系统的日益复杂与智能化，对信号系统产品测试人员的要求也越来越高。测试人员仅仅按照产品文档编写测试用例，执行测试已不能满足需求。测试人员需要从产品的方方面面深入探索产品，了解足够多的信息，才能更好的制定测试策略，发现更多的产品缺陷，避免缺陷逃逸到现场。

怎样才能深入了解到足够多的信息，制定一个完整的测试策略呢？本文将介绍HTSM 模型，及将其应用于面向车车通信ATS 产品来制定测试策略。

启发式测试策略模型（Heuristic Test Strategy Model），简称HTSM，是测试专家James Batch 提出的一组帮助测试分析与设计的指南。HTSM 是一个结构化的、可定制的参考模型，从测试技术、产品元素、项目过程、质量标准等多个角度启发测试设计。

面向车车通信ATS(iTS600)是新一代的ATS 产品，ATS 作为地铁信号控制系统的一个重要组成系统，与轨旁资源管理器、轨旁列车控制器、车载控制器设备等其他信号系统设备一起工作，实现信号设备的集中监控，并控制列车按照预先制定的运营计划在正线和车辆段/停车场内自动运行。

1 HTSM的内容

HTSM是层次结构，图1是其最上层元素，包括项目环境(Project Environment)、产品元素(Product Elements)、质量标准(Quality Criteria)和测试技术(Test Techniques)。测试人员利用项目环境、产品元素和质量标准，指导测试技术的选择与应用，最终产生测试质量。

图1

每层元素又可分为多个次层元素，而次层元素又可进一步分解为第三层元素，本文只介绍到次层元素。

项目环境(Project Environment)，包含了项目中一系列可能影响或制约测试的资源、限制等其他元素，测试人员需识别项目环境的各项元素，在约束条件下充分运用资源，以更高效的测试。项目环境可用CIDTESTED 这几个引导词来概括，分别是：

（1）用户（Customers）：产品的用户；

（2）信息（Information）：发现测试所需的信息；

（3）开发者关系（Developer Relations）：与开发者的关系；

（4）测试团队（Test Team）：利用团队的力量支持测试；

（5）设备与工具（Equipment & Tools）：可利用的硬件、软件、文档等；

（6）进度（Schedule）：项目实施的进度；

（7）测试项（Test Items）：测试范围和重点；

（8）交付件（Deliverables）：测试的产出。

产品元素(Product Elements)，包含产品本身及产品和外部的关系。软件本身是复杂和无形的，需要考虑产品的方方面面，而不仅仅是容易看见的部分。

（1）结构（Structure）：产品的物理元素如代码、硬件、非可执行文件等；

（2）功能（Functions）：产品的所有功能，包含应用相关的功能、计算相关的功能、时间相关的、安全相关的等等；

（3）数据（Data）：产品所操作的数据；

（4）接口（Interfaces）：产品所有的接口，用户接口、系统接口、导入导出等；

（5）平台（Platform）：产品所依赖的外部元素；

（6）操作（Operations）：产品将被如何使用；

（7）时序（Time）：影响产品的时间因素。

质量标准(Quality Criteria)，是用于决定产品价值的多方面，也可将其视作产品不同的风险，质量标准通常是多维度的及带有主观性的。

（1）能力（Capability）：实现产品的功能；

（2）可靠性（Reliability）：产品在规定的条件和时间完成规定功能的能力；

（3）可用性（Usability）：产品处于可工作或可使用状态的程度；

（4）吸引力(Charisma)：产品的魅力和吸引力；

（5）安全性（Security）：产品不导致人员伤亡、系统损坏、财产损失等能力；

（6）可伸缩性（Scalability）：产品部署实施是否可裁剪；

（7）性能（Performance）：产品性能；

（8）可安装性（Installability）：安装简易程度；

（9）兼容性（Compatibility）：产品与外部元素或环境的兼容性；

（10）开发标准(Development)：包含可支持性（Supportability、可测试性（Testability）、可维护性（Maintainability）、可移植性（Portability）、本地化（Localizability）。

测试技术(Test Techniques)，用于启发测试设计，使用测试技术需要依赖于对项目环境、产品元素和质量标准的分析。通常，包含以下测试技术：

（1）功能测试（Function Testing）；

（2）域测试（Domain Testing）；

（3）压力测试（Stress Testing）；

（4）流测试（Flow Testing）；

（5）情景测试（Scenario Testing）；

（6）声明测试（Claims Testing）；

（7）用户测试（User Testing）；

（8）风险测试（Risk Testing）；

（9）自动测试（Automatic Testing）。

HTSM 是一个通用的模型，是一系列启发思考的指导性词汇，用于启发测试人员的思维，发掘测试对象和测试策略。但是，在使用HTSM 前，需要结合自身产品进行定制，模型中有些指导性词汇可能也并不适用于自身产品，便可直接跳过该项；有时候也可能需要增加模型的节点。HTSM 模型是定制及修改的，定制的过程即应用的过程。

2 面向车车通信ATS的项目环境

图2 通过思维导图梳理了面向车车通信ATS 的项目环境，在对这些问题都一一有了解答之后，便对该项目的项目环境，包括用户、项目、任务有了一定的了解。HTSM 实际上就是通过问问题的方式来了解用户、了解项目、了解任务，识别其中的风险，识别风险后，便可提前预防风险，或者在风险处加强测试设计与分析，这便是基于风险的测试了。

图2

用户：在了解了用户最关心的功能、用户的痛点之后，后续便可在这些功能处加强测试设计与执行；在了解了基于车车通信的ATS 与既有的ATS 操作上的变化之后，便可关注这些操作变化是否合理，是否与原先的操作方式差别太大导致用户不习惯等。

信息：在了解了与既有ATS 架构的变化，以及外部接口的变化之后，便可重点从这方面入手，首先可以更系统的了解车车ATS产品，另外，从架构、接口的变更考虑哪些地方可能有风险需要加强测试。

开发者关系：有新开发人员加入或者开发人员负责的模块有变更之后，测试时也需要重点关注其负责的模块。

测试团队：以计划的测试人力如果无法满足发布计划的话，便需要提前申请更多的人力，或者根据测试条目的优先级来调整测试计划了。

设备与工具：Wireshark 如果没有现成的带解析工具，提前识别后，测试人员便自己可准备好；PIS/PA 模拟工具没有，也可提前看是否能开发相关工具？测试团队可提前识别自己需要培训的内容并提交培训计划并实施培训；如果目前实验室的硬件环境无法满足车车通信ATS 的环境需求的话，也可提前计划并采购。

交付品：如果需要ISA 认证，并且为国外认证公司的话，文档英文化是必须的，这必然对测试的时间计划有所影响。

3 面向车车通信ATS的产品元素

HTSM给出的产品元素的关键字分别为结构、功能、数据、接口、平台、操作、时间，图3 中除了这几个关键字，还加入了界面及数据库。就像前面提的，HTSM 是可定制的，可以加入任何适用本产品的关键字，因为对于ATS 是一个信号监控系统，界面尤其重要，所以加入了界面这个节点；其次，基于以往的经验，数据库相关的操作也是经常出现Bug 的地方，所以也有必要加入该节点进行梳理。对于ATS 来说，目前平台是基本固定的，暂时也不具备可移植性等相关特性，便可直接删除该节点。

图3

对ATS 的结构进行梳理，首先可以从与既有ATS 的结构进行比对开始，了解两者的差别，再进行内部软件结构及外部系统接口的梳理，这样便能对产品有系统的认识；另外，现场的设备的布置也同样重要，用户的使用场景当然需要了解，也能从中抽取出适用于实验室的测试环境。

ATS 是一个功能多的大系统，对其功能的梳理可单独进行，同样，ATS 的接口也较多，接口与功能又在功能上有其关联性，两者可以合并进行测试点的梳理。

对于ATS 这样一个大系统来说，对于功能点的梳理，仅使用HTSM 可能还不够，可以结合另一个测试专家邰晓梅在其《海盗派测试分析》中提出的方式MFQ 来进行更深入、系统的分析和探索。

单功能（M）、功能交互（F）、质量属性（Q）的测试分析与测试设计，就是针对大系统提出的，功能多且复杂、功能交互多、质量属性要求高，这与ATS 的特点也非常契合。MFQ 同样可用思维导图方式，针对一个大的功能，可梳理出单个的功能M1/M2/M3/M4…，不同的功能点有交互的地方列到F 里，质量属性相关的列到Q 里。如何应用MFQ，作者也给出了一个建议，即越早期的测试（LLT-Lower Level Testing），关注的测试对象可以多一些，即M 多一些，F 和Q 少一些，单功能的质量有保证之后，后续更高级别的测试（HLT-High Level Testing），可以更多的关注F 和Q。如图4所示。

图4

回到HTSM 的产品元素，对于数据来说，需要确认测试时使用的数据是真实的项目数据，还是为了测试方便制作的测试数据。基于数据的测试不是产品测试的重点，可暂不作其他考虑。在操作上，不仅需要针对正常操作测试，也需要考虑一些异常操作和极端操作的方式，同时需要了解不同用户的操作习惯。与时间相关的，包含运行/操作的快/慢相关功能，变化率包含一些中断与重连，以及某个时间点的峰值的数据量等，可支持或不可支持的并发性操作也需要整理出进行验证。

4 面向车车通信ATS的质量标准

如图5所示，质量标准是我们测试很少考虑到的一方面，或者说不会特意去考虑，有些可能也不太适用于ATS 产品，但正因为很少从这方面入手，说不定能得到一些意想不到的结果。

图5

质量标准可分为开发标准和操作标准，操作标准包含能力、可靠性、可用性等，开发标准包含可支持性、可测试性、可维护性、可移植性及本地化。开发标准是开发人员在设计之初就应该要考虑的点，测试人员也可以从这几方面确认是否满足这些标准并提出相应的改进意见。操作标准中的能力项即产品要实现的功能，已在产品元素章节中阐述；可靠性由RAM 团队负责，可不包含在ATS 测试范围内；可用性，既有的测试更多的关注在功能实现上，至于是否容易使用，或者是否操作简单，可能考虑的并不多，以及为了满足功能的安全等级，是否使得可用性变差了？吸引力，界面美不美观？ATS 产品是否与其他竞争产品相比有其独特性而不是重复的雷同的？这些方面确实需要测试人员更多的关注；安全性，因ATS产品为安全产品，所以更需要充分的准备和测试，并需要提前准备好故障注入的场景及相应的故障注入工具，信息安全也是一方面，需要测试人员提前储备好相关知识；可伸缩性指的是产品是否可规模化，对铁路产品来说目前不适用；性能，对于ATS 产品来说是需要重点考虑的一部分，需求中性能部分描述较简单，可能需要更多的从经验入手，结合以往发生过的性能案例进行测试设计提前发现性能问题；可安装性，目前的ATS 安装是比较繁琐的，可了解用户的安装痛点并提出相应的改进意见；兼容性，可以从操作系统、硬件及与其他应用的兼容上面来考虑。

5 面向车车通信ATS的测试技术

如图6所示，ATS 的功能测试可结合MFQ，采用不同的测试方法来进行，测试人员需要明确的是，如何来判断该功能是可用的，即如何判断实现了该功能，同时也需要注意，不应该实现不该实现的功能；ATS 产品中比如列车早晚点调整功能中早晚点的定义与数据相关，可选择域测试，采用边界值（边界值、典型值、常用值、无效值）来进行测试；ATS 需要重点保证现场每天从早至晚按顺序进行的一系列工作，从凌晨自动建立计划、唤醒列车、自动匹配计划、出库、正线运行、回库、洗车、休眠，这便可采用流测试；情景（场景）测试对于ATS 这种面向用户的监控产品来说也非常重要，可结合既有ATS 产品以往发生过问题或多条件组合情况设计场景，确保面向车车通信的ATS 产品能够在这些场景下正常运行；获取到项目真实的用户数据，在真实用户数据情况下进行用户测试；使用HTSM 测试设计模型来进行梳理，本身就是一个基于风险测试的过程，识别了风险之后，测试人员需要做的就是提前规避该风险或设计用例/场景来确认该风险。

图6

6 结束语

HTSM 对于测试设计的意义，可通过James Bach 的培训教材Rapid Software Testing 中的一段话充分体现：

测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险，设计有针对性的测试策略。

在测试设计时，质量标准启发测试先知（Oracles），项目环境启发测试过程（Procedures），产品元素启发测试覆盖（Coverage），观察到的质量启发测试报告（Reporting）。

对于测试，HTSM 强调测试策略的多样性（Diversification），平衡代价和收益（Cost vs.Value），利用启发式方法（Heuristics）充分发挥测试人员的技能（Skill）。

需要注意的是，测试分析与设计不是一次性的工作。风险是不断变化的过程，风险的两个重要因素（可能性和影响力）也在不断发生变化，这就决定了测试分析与设计的工作是需要不断进行，是一个在测试过程中需要不断迭代和修改的过程。