做为测试人，开发BUG频出，我该最怎样避免线上事故……

前言

测试的目的不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。

测试的原则
基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量。

一个产品的研发过程中，bug是不可避免的。bug很难彻底消除，只能避免，尤其避免那些线上影响范围大的，涉及关键功能点的高级事故。今天说几点我们日常工作中能有效避免线上事故的拙见。

1、上线流程规划
不完整的发布和迭代是隐患出现的一大原因。成熟而完整的产品线应该严格按照需求->开发->测试->运维发布的持续集成过程，除此之外，还应该附带有标准的hotfix流程&灰度流程，最大程度从根源预防风险。

很多时候，临时需求加塞，慌忙上线，线上直接修代码等一些过火操作是导致重大事故的直接原因，一定要避免。

除此之外，一些常用的事件追踪管理工具比jira/mantis，建立的相关sprint版本，hotfix版本，临时上线版本，正式版本号等，这些发布要走的必要流程，看起来比较偏行政化的工作，却是必须要有人来管理和维护的；记录清楚事件的流转，这样即使线上出现了事故也能快速回滚或及时止损。

2、前后端分离的重要性
公司一般都有明确的前端开发人员，后端开发人员；但测试可能没有前端测试人员和后端测试人员，这就要求测试同学在工作的时候分清楚前后端需求，对于出现的问题,能够通过抓包等方式迅速定位到。

怎么做到前后端分离呢？
一般认为：
API自动化(first 后端自动化)
UI自动化(second 前端自动化)

对于前端bug，比如一些控件，元素，特效等，js报错等相对比较容易定位。

对于后端，尤其是service相关的bug，定位可从以下几方面入手：
关键日志抓取/请求抓包
API情况，关键error code&message
数据库数据情况

前后端分离是清晰化测试任务的有效方法，也是及时响应bug/处理bug/分类bug的有效方法。

3、做好单元测试和集成测试
单元测试一般在工程代码里同时存在，由开发同学来完诚。做好底层单元测试，提升分支覆盖情况，提升代码质量，最大限度避免一些低级却致命的错误。单元测试-大指标可以说是覆盖率，有些人认为覆盖率太片面，但覆盖率却是最直观，最容易做，收益比较高的一个工程。

不过，如果不做覆盖率的话，现在SonarQube比较火，它是一个代码质量管理的平台，通过插件机制，Sonar 可以集成不同的测试工具，进行代码质量分析工具和报告，像类似这种工具也可以联系起来。

那集成测试呢，就是系统级别的测试。这种测试可以发现，联调时候的问题，前后端不一致，接口返回数据等系统性的问题，集成测试有时候和回归测试一起做，目的是保障之前的功能正常运行。

4、做好bug管控
有些公司内部，bug还是比较乱的。遗留的新建的去年的今年的，各种bug越积越多，没有推进，会直接导致一系列的连锁反应，所以测试同学联合开发同学最好有对bug的把控或认知，分清重要级紧急级优先级，哪些应该优先解决，哪些需要配合解决，哪些需要重构，哪些需要改表，都要十分清楚，把控把控，怎么把控呢，就是一不要事故牵着鼻子走。

5、认真对待每一次需求
每个产品及产品线，只要正常运转，都会不可避免的面临持续迭代和发版。每次的需求，都需要正规走需求评审，用例设计，开发自测等环节，认真对待每次需求，再小的需求也要做到五脏俱全，指不定哪里就会爆雷。

有的时候说开发紧张或者排期紧张，只能说前期规划并没做好，导致整个团队跟着一起紧张，这样的事情尽量避免。但如果实在不行，那就要临时更换上线方案，走一些hotfix等等。

我们测试人员，是为了质量保障而存在。线上事故的数量直接衡量了这个产品的稳定性。QA做的每个措施，下的每个决定，都可能在这个产品线起到影响。所以，认真对待上线，认真对待产品本身，Deadline is deadline，认真对待排期，才能做到持续且长久的质量保证。

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

成人的世界，天黑可以矫情，天亮就要拼命，岁月不会安逸，无论你当下经历了什么，天亮以后依然踏着荆棘前行！

生活中，应对困境，咱们常常会有走投无路的感觉。不好气馁，坚持下去，要坚信年轻的人生没有绝路，困境在前方，期望在拐角。只要咱们有了正确的思路，就必须能少走弯路，找到出路！

成功不是属于跑得最快的人，而是属于一直在跑的人。