背景
任何产品在研发阶段总有那么一些让人掉坑的缺陷，然而这些缺陷又是怎么去定义的呢？其实各种书籍和网上都有很好说法和定义，在这里就不再细详说。写这文章只是个人对bug理解和看法而已
例：测试web一个页面时，加载完成的时间达到了5s以上，如果是你在操作，你会怎么去定义这个问题？有以下场景：
1、提出的bug，如何证明它不是bug
测试：这是个bug，页面加载的时间都有5s以上了，测试了多次都是这样的，很慢啊
开发：5s的加载时间很正常啊，你可以查查我代码
需求：5s加载时间至少不会影响使用，客户没要求要求页面响应要多快
项目经理：整体功能为主，这个不响影流程的暂不考虑
领导：能满足客户的要求即可
客户：基本上能达到我们要求的功能和要求
路人甲：不好好测试，浪费时间来研究5s（无语）
路人乙：叫你来测试的，不是叫你来找茬的
路人丙：所有人都没问题，就你说这个有意义吗（鄙视的眼神）
……
你所认为的bug，被各种理由无奈的抹杀掉
2、提出的bug，如何证明它是bug
测试：这是个bug，页面响应和加载时的io过高，经多次测试结果，HTTP 请求的连接、发送请求、等待回应的总时间达5000ms以上了，这样影响了整体的性能和体验
开发：有这么高了，我查查代码
需求：5000ms加载时间太长了，客户体验肯定不行
项目经理：那么长的时长，代码优化一下，控制在200ms～1000ms
领导：用户体验很重要，必须把时间缩短下来
客户：这么长的加载时间，那样不是很差吗？我的客户都不想用了
路人甲：打开页面要花这么长时间，看来做的不怎么样
路人乙：这个时间都能测出来，看来是拿着手机在计算时间（这么慢）
路人丙：这是谁开发的（那鄙视的眼神）
……
总结
同样一个bug，看以什么样的方式去证明它是什么。提出的问题，不能仅仅是以个人的想法去说服其他人，而是提出有价值且带专业性的问题，能引起其他人来帮助自己一起去评估这问题，甚至于还帮助去解决问题，这就是共鸣效应。有时候不能以主观的认知和经验去判别一件事情的对错，因为那样对事件的本身是不公平的。
要善于从不同角度去分析事件的本身的价值和影响程度，是否能真正满足整体的需求，还有是否是以负责任的态度在做事同样很重要，对人对事负责任，反过来同样会回报于己身。
框架理论和框架效应，这两个理论很好的说明了。同样是指同一件事情，有两种逻辑思维和意义上相似的说法导致了不同的结果。
End
如果你对测试方面有更好的技术、想法和看法，我们可以一起聊聊。如何改善自己，提升做事效率，个人责任感……
欢迎来撩，但别撩我 ^ _ ^ --by 王子
网友评论