其他分享
首页 > 其他分享> > 测试质量保障-漏测原因和预防

测试质量保障-漏测原因和预防

作者:互联网

一、什么是漏测?

  漏测,是指软件产品在测试阶段未被发现,而是在产品发布上线之后,用户在使用过程中发现存在的缺陷。

 

二、为什么会漏测?

  谁也不能保证说经过我测试的东西完全没有问题,包括经验丰富、工作多年的资深测试工程师,或多或少的会出现自己没有考虑到的场景,谁也不能把软件所有的功能操作、使用场景想的十分周全,特别是功能复杂、业务关联性比较强的系统。

 

三、漏测产生原因

漏测大致有如下原因:

 

需求评审质量低、不规范、设计缺陷、遗漏、描述歧义等

需求变更频繁,PRD或用例未及时更新

 

技术实现设计缺陷,引入新组件、在未来某一时刻或数据存在问题

开发新功能或修复缺陷从而引入的新缺陷

 

上游系统不稳定、时好时坏

测试环境和生产环境出入

测试环境或测试数据受限,无法模拟覆盖真实场景

 

用例设计过于粗狂、覆盖不全

测试过程不规范、未按照测试用例执行

测试思维局限、业务理解不透彻、考虑不足

测试人力资源、时间不足,导致测试不充分,未完全覆盖所有场景

 

四、如何预防漏测

  我们知道,缺陷越早被发现,发现和解决缺陷所花费的成本就越小,如果在测试阶段就尽可能发现更多问题,那么所花的成本就小很多。测试是保障软件质量最重要的手段之一,因此,预防漏测、进行漏测分析、使缺陷尽可能在测试早期发现,是非常有意义的,有利于降低软件成本,提高软件产品质量。

 

需求评审质量提高:

需求评审过程规范、详细的PRD、开发和测试人员参与

需求评审需要有业务熟悉和测试经验丰富的人员参加

每次需求变更及时更新PRD和测试用例

 

项目流程改进:

测试用例评审(组内评审、开发产品评审)

技术方案评审&codereview

研发提测标注影响范围

研发自测通过

 

测试质量提升:

提升测试用例质量(颗粒度、需求覆盖度、冗余度等)

测试过程中遗漏和启发的用例及时补充

建立通用测试用例库和框架、建立优质测试用例

提测前充分准备测试数据尽量覆盖所有测试用例

测试数据足够丰富、多样化、特殊数据

业务覆盖、关联模块、相关功能验证

测试需覆盖需求未说明的(提高易用性、提示、校验、页面样式等)

站在用户角度测试(好不好用、符不符合用户习惯、是否易于理解等)

前后端都需要校验(尤其一些涉及用户信息、金额、数量等影响数据安全和资金安全的场景,前端校验同时也能减轻服务器和网络压力)

测试执行过程规范、严谨

必要时进行交叉测试

适当加入探索性测试或随机测试

测试完毕,思考是否测试充分,是否可能存在其他遗漏场景

有效回归测试(包括主流程测试、自动化测试)

 

专业度提升:

测试人员思维、专业能力提高

组织内部的相关技术培训

组织内部的业务知识培训

多学习、多交流、多总结

 

环境:

测试环境尽量贴近生产环境

保障测试和生产环境数据库、中间件、版本和配置一致

覆盖兼容性问题,如系统、版本、分辨率等

 

常用测试方法: 等价类、边界值、正交法、因果(场景)、错误推断(经验)

测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等

 

五、总结

 

出现漏测,必须分析原因,吸取教训,避免其他成员遇到类似情况发生,尽可能减少问题漏测;

版本上线后,及时总结测试过程中遇到的问题并改进

线上问题,定期组织复盘,了解问题根本原因,杜绝问题再次发生,包括流程改进、技术方案优化、测试过程改进等;

漏测是不可能避免的,我们能做的是尽量减少漏测,预防漏测、正确对待问题加以改进,漏测随着我们不断总结和经验的积累,而逐渐减少。

 

标签:场景,漏测,评审,测试用例,测试,缺陷,预防
来源: https://www.cnblogs.com/xiaoxitest/p/16197874.html