目录：导读
前言
当产品上线的或者开售时候，如果没有严重的上线事故或售后问题，那自然是皆大欢喜。
一旦有严重的问题反馈，产品、开发首先想到的就是测试部门有漏测。问题已经发生了，紧接着的是应该首先搞清问题，然后制定复现策略，抓取有效的Log给开发人员分析。
不管是测试漏测，还是开发修改引起而测试回归时没有覆盖到（由于不知道修改点导致没有回归），出现线上或售后严重问题，测试部门、开发部门写回溯报告是在所难免了，需要向上面的老大汇报。
虽说产品的最终质量不是由测试决定的，但谁叫测试是产品开发的最后一环把关者呢，这个时候，项目、产品、开发都会把矛头指向测试部门。如果是你刚好负责这个项目的测试，那你运气不好，当季度绩效可能没了。
谁也不想产品发布之后出现任何严重问题或事故，但是在负责项目过程中，你自己负责的模块执行测试过程中，是否有做到尽职尽责，不把任何风险压在自己身上而及时抛出求助。
测试整体负责人，是否有做到以下方面：
版本太烂没法管控你是否有邮件向项目相干人员反馈；
版本发布前有拿到修改点和研发针对修改点的测试建议；
项目的整体测试策略、测试计划是否有拉产品、开发人员一起评估，安排的测试内容是否评审达成一致；
各模块测测执行的测试人员技术能力是否能足够支撑该项目；
项目测试过程中出现的任何风险自己解决不了，是否有及时Highlight给项目组人员求助；
重点模块是否安排的是资深测试人员测试；
资源、人力不够是否有找领导协调；
当版本发布不按照计划执行时，测试计划是否有调整以有预留足够的测试执行时间。
如果这些你都做了，那问题就不在于你，该做的你都做了，项目出现发布后严重的问题概率会很低，也不大是因为测试环节出现的问题。
模块执行人员，那是否有做到以下方面：
对测试模块的需求是否都有了解清楚；
测试用例疑问是否都有确定过；
测试执行过程中偶现的问题是否非常重视，有向上反馈经过压力测试；
测试过程中上报的Block、Critical问题是否有跟踪开发人员及时修复；
模块以前的经典问题列表是否有验证过。
如果在测试执行过程中，所有的点你都做到了，那你负责的模块部分出现漏测的情况基本不会出现。
在平时的工作中尽可能避免口头的沟通，而使用邮件、公司的沟通工具来沟通，当最后出现扯皮的时候就能派上用场了，否则出现问题的时候就比较尴尬了，例如需求的沟通确认。
但是也不能仅仅是发邮件了事，而是要持续跟踪，所有的问题都需要闭环结论，不管是最终结果如何，不然发不发邮件又有什么意义呢，最终的问题还是没处理而继续遗留到下一个阶段。
产品的最终质量不是由测试人员决定的，而是由产品相关的所有人员、完善的流程共同决定的。但是作为测试人员，我们要对我们的测试的质量负责，对我们交付的测试报告质量负责。
我们首先要把我们自己的事情做好，然后在完善其它流程，共同推广到其他部门，建立完整的质量控制流程。
下面是我整理的2022年最全的软件测试工程师学习知识架构体系图
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
不管昨夜经历了怎样的泣不成声，早晨醒来这个城市依然车水马龙。人生，总会有不期而遇的温暖，和生生不息的希望。
努力做一个积极的人。不埋怨谁，不嘲笑谁，也不羡慕谁，阳光下灿烂，风雨中奔跑，做自己的梦，走自己的路。
摔跤了不要哭，爬起来站直一笑，拍拍身上的尘灰，继续奔跑。正视人生的每一个挫折，适应人生的每一回起伏，吸取人生的每一场失败，利用人生的每一个坎坷。
版权归原作者 百度测试开发 所有， 如有侵权，请联系我们删除。