在一次和开发同学交流中，他说道 “我常称测试的手为神手，没有测不出的 bug”。很多人对测试的第一印象是不是都是这样呢？
如果测试人自己也这么认为，那你很危险！
\
BUG 一定会存在
我想表达一个观点：bug 是一定会存在的。测试的本质是降低风险。测试的目标不是发现错误，而是通过主动发现并消除可能对使用软件的客户造成最大影响的问题来降低风险。这是因为我们永远找不出一个软件的所有 bug，也无法测试所有可能的输入条件。
这个世界上没有哪个软件是完美的。就像我们人类一样，谁都有优缺点。不要下意识的觉得缺陷出现是不好的，让这个缺陷的出现，给你带来正向的好处。比如是不是我们有漏测，总结后是不是可以运用到下次的任务中，处理的过程如何更快的定位等等。
突然联想到「反弹力」这个概念，遇到问题，我们就像跌到了谷底，不是爬到平地就好了。想想，我们还可以弹的更高，下次碰到坑甚至可以跳过去，做更好的自己。（我希望我分享的内容不光是针对测试工作，也可以运用到生活中~）
\
如何处理缺陷
区分优缺点的唯一方法是你如何处理缺陷。接下来聊聊怎么爬起来或者避免自己不掉到谷底，也就是想办法避免 bug，或许它出现了我们怎么尽快恢复。
\
如何避免
测试应该全方位参与整个软件开发过程，而不只是关注测试阶段。避免 bug 的话，我们从职能角色的三个层面来看：
1.产品层面：
PRD 文档是否贴近用户的真实需求，从源头避免
2.开发层面：
理解要实现的需求，增加设计评审、自测环节
3.测试层面：
测试点、测试场景贴近用户的真实需求，测试用例覆盖度高等等
\
事后如何解决
像 Devops 里面就提倡事故事后处理文化，软件有 bug 是很难避免的。我们应该优化我们的测试手段和策略，加快事故响应速度，尽可能缩短由于事故带来的影响时间。
1.即时响应， 评估影响
响应，很重要！让客户知道有人在处理。如果一直不去跟进，客户情绪上来了，小问题也会变成大问题。问题不是都需要立刻处理的，需要评估一下影响面；如果对用户影响面很小，可以记录下来之后跟进。如果需要立刻解决，需要去找 "问题" 的原因。
2.找原因
不同业务形态，可能处理方式有一些不同。以我所在的 2B 医疗系统举例，日常线上反馈有问题的时候，开发如果没有问清楚就去查，反而会耗费大量时间。因为业务流程复杂，涉及多条链路以及不同的配置参数。
那经过多次教训，我的思路变成了先破题，向提出问题的同学或用户，了解清楚操作步骤。而不是看到报错页面就默认有问题。了解清楚了之后，根据自己对功能模块的熟悉程度，进行判断。
没问题，就告诉用户正确的操作；是问题，就找原因。对问题有一个初判断：前端监控，后端监控，缺陷定义，再重点分析。当然，这依赖监控体系和我们对模块的熟悉程度，可以尝试复现、查看日志、埋点报错等等。
3.快速解决
- 回滚：特别严重的问题，可以立即进行版本回滚；
- 修复：可以直接修复的找到 bug 所属模块的负责人，确定解决方案，并及时发布对应的补丁包或者给出解决措施即可。事后也要进行复盘，总结。这些都是经验，经验就是成长。
\
绝大多数时候，你永远都无法解决某些问题，你要么想办法避免问题的发生，要么学会与问题共存。
希望今天这篇文章，给你一些不一样的，看待 “问题” 的思路! 期待和你交流，我们下次见！
