小李的漏测分析
清晨刚到工位,小李就接到了领导安排的现场缺陷漏测分析任务。他打开缺陷单,映入眼帘的标题让他眉头微皱 ——“债券指令交易双击资产支持证券的协商成交指令,下达委托时提示‘暂不支持该业务’”。带着疑惑,小李点开开发团队的分析报告,逐渐摸清了问题的脉络:资产支持证券在匹配成交时不支持买卖,系统需给出相应提示,然而程序处理逻辑出现错误,在协商成交时错误地执行了匹配成交的处理分支,导致了误判。
为了探寻漏测根源,小李翻出了当初债券统一入口任务的测试文档。测试计划里明确列出了覆盖所有债券类型的用例,资产支持证券赫然在列。他回忆起当时的情形,由于测试时间十分紧迫,且债券统一页面是从其他菜单迁移而来的功能,他最终只执行了国债、企业债和可转债的测试,将资产支持证券等类型暂时搁置。那时他想着,都是页面迁移的功能,验证几个交易频率高的债券类型应该就能发现主要问题,可没想到,正是这一 “想当然”,让问题钻了空子。经过深入分析,这次漏测的根本原因逐渐明晰 —— 在测试时间不足的压力下,测试人员依据经验对原计划执行的用例进行了裁剪,最终酿成了这次漏测。
回忆往事
想起七八年前测试交易系统交付的情形。我们在异常用例设计时,规划对机器重启、程序退出、网络断开等场景进行测试。但在内部测试阶段,由于使用虚拟机环境,测试团队担心断网后无法重新连接,且部分成员认为断网和程序退出的测试效果相似,加上测试时间紧张,最终只执行了程序退出场景的测试,未对网络断开场景进行验证。
系统交付后,客户开展 UAT 测试。负责执行测试的外包人员虽然不熟悉系统架构和业务逻辑,但严格按照提供的测试用例操作。当执行到网络断开场景时,系统运行结果与预期不符,这个在内部测试中被跳过的测试项,成为交付后发现的关键缺陷。
发现问题后,客户测试负责人组织复盘会议。会上,客户提出疑问,指出测试环境单一,仅测试异常场景存在不足。作为系统开发方,团队在测试专业性和系统熟悉度上本优于外包测试人员,却因测试执行不到位,被客户指出问题。客户还多次询问内部测试工作是否落实到位,这也让团队认识到,测试过程中的任何疏忽,都可能影响系统交付质量。
历史漏测回顾
小李负责分析的这个缺陷,已是近一年多来我参与复盘的第三个严重漏测案例。这些缺陷都导致正常功能无法使用,极易引发客户对供应商测试能力的质疑。
最早的一次,某功能从主版本同步到补丁时,测试用例明确要求同时进行页面查询和数据库查询,但测试人员仅执行了页面查询,跳过数据库验证,最终功能在客户侧无法使用。当时因客户集中反馈多个现场缺陷,意见强烈,这个低级错误更是雪上加霜。涉事测试人员被列入业务总部质量黑榜并通报批评,还因此连续两次错失晋级机会。
另一起案例中,新开发的报盘网关功能需支持同时连接 20 个交易所网关。测试执行人员因不熟悉测试工具,无法达成连接 20 个的条件,在询问开发人员 “连接 1 个与 20 个效果是否相同” 并得到肯定答复后,仅测试了连接 1 个的场景。系统发布后,客户在周末测试时发现,连接到 10 个网关程序就崩溃了。正值公司降本增效阶段,该员工最终被开除。
尽管两次漏测事件对相关人员的处理都十分严厉,但测试用例执行不到位的问题依然存在,成为困扰测试质量提升的顽疾。到底是什么原因导致用例无法按要求执行呢?
为什么不严格按照用例执行呢?
测试用例已经写好,并且计划要执行,什么原因导致用例未按要求执行呢?虽然存在极个别员工缺乏责任心、上班摸鱼、工作偷工减料,但绝大部分员工是有责任心的,用例未按要求执行会存在如下主观或客观的原因
1、主观经验判断:测试人员凭借过往经验,主观认为某些用例不必要或效果相似,自行调整测试范围。
2、时间压力:项目工期紧张,留给测试的时间不足,测试人员为追赶进度,被迫裁剪或跳过部分用例。
3、资源限制:硬件、软件资源不足,如缺乏测试设备、测试环境搭建不完整,导致部分用例无法执行。
4、工具不匹配:使用的测试工具无法支持部分用例的执行,或工具存在缺陷,导致执行受阻。
5、理解偏差:当测试设计人员与执行人员不一致时,执行人员对测试用例设计意图、需求或业务逻辑理解不到位,导致执行过程无法完全实现用例设计目标;此外,用例编写不清晰、缺乏详细说明,也会造成执行人员误解,影响用例执行准确性。
实际工作中,用例未严格执行的原因可能是上述多个原因导致的。
如何确保用例按要求执行?
1、测试用例原子化设计:将复杂测试场景拆解为单一功能验证的原子化用例,确保每个用例仅覆盖一个测试目标,避免因步骤冗余导致部分场景漏测。同时,细化用例执行结果记录,明确区分各步骤执行状态,防止风险隐藏。
2、严格用例裁剪审批流程:禁止测试人员私自裁剪用例、测试步骤或场景。若因特殊情况需调整,必须提交书面说明,经测试经理评估确认后,方可修改执行计划,杜绝主观随意性操作。
3、实施重点功能交叉测试:针对核心业务功能,安排不同测试人员独立执行测试用例,通过交叉验证发现潜在问题,降低因个人理解偏差或疏漏导致的测试盲区。
4、建立用例优先级动态评审机制:测试管理人员联合开发、产品人员,基于业务影响度、用户使用频率等因素,在每个迭代周期重新评估用例优先级,确保时间紧张时优先执行核心用例,合理分配测试资源。
5、推行 “双人交叉验证” 机制:测试人员两两结对,互相审核对方对测试用例的理解,尤其针对复杂场景,通过沟通消除理解偏差。测试管理人员随机抽查验证效果,提升用例执行准确性。
6、制定工具能力适配清单:系统梳理现有测试工具支持的功能,与测试用例需求一一匹配标注。遇到工具不支持的场景,提前评估手动执行或临时开发插件的可行性,减少因工具适配问题导致的执行障碍。
7、推行 “最小可行性测试包” 方案:针对紧急项目,测试团队提前定义覆盖核心功能和高风险点的最小测试用例集,确保在时间不足时仍能保障基础质量,避免因赶工造成大面积漏测。
总结
面对资源永远不足、时间始终紧迫的现实,我们的态度应是:拒绝 “差不多” 思维。真正的质量保障,始于承认资源有限,却以规范流程守住测试底线 —— 那些 “以为不会出问题” 的疏漏,终将用客户的投诉敲响警钟。