测试建模:启发式测试策略模型(Heuristic Test Strategy Model)
2012-02-23 15:14 liangshi 阅读(13336) 评论(0) 编辑 收藏 举报启发式测试策略模型(Heuristic Test Strategy Model,简称HTSM)是测试专家James Bach提出的一组帮助测试设计的指南(guideline)。本文将介绍HTSM的内容与应用。
为什么需要HTSM
根据产品的风险(risk)设计测试是一种常见的测试设计思路。在复杂的现实世界,产品面临的风险多种多样,只有全面考虑、周密测试才能避免风险暴露导致的严重后果。因此,测试人员需要一个相对完整、可以定制、容易扩展的风险列表或参考模型,来帮助他们发现产品风险。HTSM就是一个结构化的、可定制的参考模型,从测试技术、产品元素、项目过程、质量标准等多个角度启发测试设计。
HTSM能够在测试全程提供有益的提示。在制定测试计划初稿时,它可以帮助测试人员完整地思考产品的方方面面,从而产生系统性的(systematic)测试计划。在测试过程中,它可以帮助测试人员组合测试想法、深入探索产品,以开发出强有力的测试策略。在回归测试中,它可以帮助测试人员确定测试范围,制定测试方案。
HTSM的内容
上图是HTSM的概要描述,测试人员利用质量标准(Quality Criteria)、项目环境(Project Environment)、产品元素(Product Element),指导测试技术(Test Techniques)的选择与应用,并产生观察到的质量(Perceived Quality)。
HTSM是层次结构,其顶层元素(质量标准、项目环境、产品元素、测试技术)可以分解为次层元素,而次层元素可进一步分解为第三层元素。本文只概要介绍次层元素,更多的细节请参考James Bach的文档。
测试技术:生成测试的策略。有效地选择和实施测试技术,需要综合分析项目环境、产品元素和质量标准。
- 功能测试(Function Testing)
- 域测试(Domain Testing)
- 压力测试(Stress Testing)
- 流测试(Flow Testing)
- 情景测试(Scenario Testing)
- 声明测试(Claims Testing)
- 用户测试(User Testing)
- 风险测试(Risk Testing)
- 自动测试(Automatic Testing)
项目环境:资源、约束和其他影响测试的项目元素。测试总是受到项目环境的约束。在某个团队运转良好的策略不一定适合另一个相似的团队,以往富有成效的方法未必适应当前的项目。有经验的测试人员会根据当前语境(Context),在约束条件下充分运用资源,以高效地测试。
- 用户(Customers):理解产品的用户
- 信息(Information):发现测试所需的信息
- 开发者关系(Developer Relations):与开发者协作加速开发
- 测试团队(Test Team):利用团队的力量支持测试
- 设备与工具(Equipment & Tools):可利用的硬件、软件、文档等
- 进度(Schedule):项目实施的流程
- 测试条目(Test Items):测试范围和重点
- 交付品(Deliverables):测试的产出
产品元素:需要测试的对象
- 结构(Structure):产品的物理(physical)元素(如代码、接口、配置文件、可执行文件等)
- 功能(Functions):产品的功能
- 数据(Data):产品所操作的数据
- 平台(Platform):产品所依赖的外部元素
- 操作(Operations):产品将被如何使用
- 时序(Time):影响产品的时间因素
质量标准之操作性标准(Operational Criteria):面向用户和运营团队
- 能力(Capability)
- 可靠性(Reliability)
- 可用性(Usability)
- 安全性(Security)
- 可伸缩性(Scalability)
- 性能(Performance)
- 可安装性(Installability)
- 兼容性(Compatibility)
质量标准之开发标准(Development Criteria):面向开发团队
- 可支持性(Supportability)
- 可测试性(Testability)
- 可维护性(Maintainability)
- 可移植性(Portability)
- 本地化(Localizability)
由以上介绍可知,HTSM由一组指导性词语(guide word)组成,它们构成一个层次结构,让测试人员从高层抽象到底层细节对产品和测试进行思考。这些指导性词汇是测试的指南,其作用不是教导如何具体地测试,而是启发测试人员的思维,发掘测试对象和测试策略。
下图摘录自James Bach的培训教材Rapid Software Testing,体现了HTSM对于测试设计的意义。
- 测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险,设计有针对性的测试策略。
- 在测试设计时,质量标准启发测试先知(Oracles),项目环境启发测试过程(Procedures),产品元素启发测试覆盖(Coverage),观察到的质量启发测试报告(Reporting)。
- 对于测试,HTSM强调测试策略的多样性(Diversification),平衡代价和收益(Cost vs. Value),利用启发式方法(Heuristics)充分发挥测试人员的技能(Skill)。
定制HTSM
在定制化之前,HTSM对测试人员的帮助很小,因为此时的HTSM是“James Bach的模型”,而不是符合当前语境的模型。HTSM是通用的模型,虽然能够普遍使用,但是不能快速、高效地指导具体的测试工作。测试人员需要将其“本地化”,才能发挥其威力。
Cem Kaner教授在教程Blank Box Software Testing 中提出利用思维导图(Mind Map)定制HTSM。他将HTSM作为图的为中心,将Quality Criteria、Project Environment、Product Elements和Test Techniques作为主干。
在分支上,Cem Kaner添加了他觉得重要的节点。例如,他在Product Elements下增加了Benefits节点和Time节点,使HTSM符合他的工作需要。
恰如Cem Kaner所说:“大多数严肃对待此模型的人会定制它以符合自己的需要”(Most people who work seriously with this model customize it t meet their needs),测试人员可以也应该修改HTSM,以获得符合项目语境的模型。
- 增加节点:增加与当前项目相关的测试技术、测试想法、测试对象和任何测试人员认为有价值的元素。
- 删减节点:忽略一些与项目或任务无关的元素。
- 增加标记、注释、链接等图元:标记可以突显重要的元素,注释可以增加更多的细节,链接可以指向更详细的信息源。
定制HTSM是理解并掌握HTSM的过程。与大多数方法一样,测试人员需要修改它,加入自己的风格和元素,才能正真掌握它。
测试专家Michael Larsen在XMind.net提供了他制作的HTSM思维导图,为测试人员制作自己的HTSM提供了很好的基础。
应用HTSM
定制HTSM就是应用HTSM的过程。测试人员遵循HTSM的结构化指南,深入地思考产品、项目与测试,添加自己的想法、评论、标记和启发式问题。这本身就是极好的测试学习过程。作为学习的结果,定制化的HTSM为进一步地测试设计提供了坚实的基础。在测试过程中,测试人员会接触新信息,学习新知识。他应该持续地将新知补充到HTSM中,以迭代地优化测试略模型。从这个角度,HTSM既是测试想法的源头,也是测试过程的产出。
在测试设计时,测试人员可以逐个检查HTSM中的每个元素(指导性词语),阅读相关标记、注释和链接,以启发测试思路。他可以自问:
- 该元素与当前测试任务相关吗?
- 针对该元素,产品有什么风险?可能会有什么缺陷?
- 通过什么测试可以发现这些缺陷?
- 依据当前的进度和资源,如何实施这些测试?
另一种更有威力的方法是综合HTSM中的多个元素,开发测试策略。当开发人员用单元测试检查了组件,测试人员需要在系统层面检查产品。此时,产品的缺陷往往存在于组件的交互和复杂的流程。综合产品的多个方面,开发多样化的测试,以更深入地测试产品,才能够更好地体现测试人员的价值。一些有帮助的启发式问题包括:
- 该元素与哪些元素相关?
- 元素的组合有没有揭示出新的风险?
- 如何设计测试,以同时测试这些元素?
- 能否让来自元素A的信息帮助元素B的测试?
参考资料
- James Bach:Heuristic Test Strategy Model
- James Bach: Rapid software Testing
- 该教程按HTSM组织,系统性地讲解了探索式测试的思维和方法
- Michael Larsen:HTSM in XMind
- Cem Kaner: Black Box Software Testing
- HTSM for risk-based testing:第199~204页
- 用思维导图定制HTSM:第262~273页