软件测试 测试核心：如何减少线上故障？_软件测试减少线上问题(1)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

产品故障的广泛定义

从广义上来说，故障同时包括了：硬性质量引发的问题、软性质量引发的问题、需求定义引发的问题。

硬性质量引发的问题

指上线/配置修改等直接引发的线上不可用问题(用户直接不可用)

软性质量的引发的问题

指新功能上线/改版等引发的不好用问题(用户直接产生不好用的感受，当然，这部分实际项目中往往不被直接当成线上故障通过回滚版本的方式来处理。)

需求定义引发的问题

指新功能上线/改版后立即重新上线推翻修改。比如推翻之前的实现；走回头路；由于大 Boss 推翻 3 周的实现等。

故障发生有种种可能的情况，这里更多的是从狭义角度来定义故障的，即：给用户带来不可用的问题，并常常通过回滚版本的方式进行处理，对应硬性质量引发的问题。

如何减少线上故障？

减少故障需要考虑的研发阶段

由于故障可能在需求、技术设计、开发、漏测、上线不规范等过程产生，因而，故障的控制必须从各个阶段分别入手。

针对已有的故障，在复盘时找到最根本的原因

线上的故障，最多的呈现形式往往是某个边缘功能的漏测，上线新功能问题等等，但这些问题的出现需要更深层次的深挖。例如，某个功能的漏测，可能是QA/开发人员对影响点评估不足，但也可能是频繁快速的超负荷迭代，导致无暇东顾；上线新功能问题，可能是因为开发人员/QA人员对上线checklist 评估不到位，也可能是项目管理混乱导致，或是线上线下环境gap导致。

根据业务成熟度、团队成员特点有针对性应对

不同阶段的业务需要不同程度的质量侧重，例如，在产品的野蛮增长期，为了实现产品原型的快速上线，允许不影响使用的问题存在。

不同团队成员(产品、研发)有略微不同的合作模式，例如，有的团队人员都特别有经验，本身需求、提测质量都很高，这时不妨和团队成员一起制定更加成熟的产品质量数据；相反，则需要从最基础的需求变动、提测等流程开始一点一滴的实践起来了。

具体评估整个项目迭代成熟度

1. 整个迭代周期是否合适，保证反复迭代时不会对质量产生风险。

具体来说就是，需求变动方面、开发周期、测试后期、上线周期等是否存在时间过紧的情况。或许偶尔几次的赶上线，对质量没有太大问题，但长期如此，出问题可能就是必然了。

2. 测试人力的效率。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

这份系统化的资料的朋友，可以戳这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**