提Bug，一个测试人员的日常事件，体现测试的价值。
但如果费尽心思所提的Bug，被开发、需求、设计人员、项目经理相继否定，必定是件很难过的事情。然而，有同行提出一个心理学方面的理论“框架效应”，引导我们从Bug的描述上下功夫，使所提的Bug得到认可，一击即中。
>>“框架效应”【定义】
**框架效应(Framing effects) **
框架效应是指一个问题两种在逻辑意义上相似的说法却导致了不同的决策判断。——百度百科
这个定义有一点晦涩难懂。总结相关资料，把“框架效应”理解为：提出问题的一方，通过设置一个框架，使回答问题的一方的观点和行为屈从于这个框架、随着框架的变化而变化。这样，设置框架的一方，就化被动为主动，不战而胜。翻译成现代语：套路。翻译成古语：请君入瓮。
>>“框架效应”【用法】
生活例子：同样的巧克力，A超市标价40元/盒，需要刷某银行的信用卡购买；B超市标价50元/盒，八折促销。结果，大部分顾客都会选择去B超市购买。
原因：B超市看起来省钱，A超市有附加条件才能买，麻烦。
可以看出：人们对于“损失”的重视要比同等的“收益”大得多。
行业应用：在测试工作中，Bug的受众是开发人员、项目经理。他们会不会认可一个Bug，首先看这个Bug的质量。如果这个Bug是严重级别，不用劝说，开发自然会去解决。
但如果这个是用户体验方面的Bug，不影响功能使用。要怎样去获取项目经理的认可、说服开发人员去修改呢？可以从这个解决这个Bug带来的正面影响去劝说，也可以从不解决这个Bug带来的负面影响去劝说。而避免负面影响，减少成本，正是人性之所向。
实例：在项目中，提了一个Bug，
【描述】在X省地图，用户处于A城市的a1区，想浏览A城市的a2区，操作的路径是：点击X省——点击A城市——点击a2区。
【预期】操作路径改为：返回A城市——点击a2区。
【理由1】用户浏览同一个城市的其他区域，不需要先返回省地图再下钻。有助于优化用户体验。
然而，项目经理评审时认为，为了少点击一次，得重新改UI，较麻烦。这个Bug不解决对用户影响不大。不需要优化程序。
学习了框架效应后，我认为，修改一下理由，有可能会获取到项目经理的认可。
【理由2】假设用户工作时，每个城市至少需要浏览10个地区，每次至少浏览3个城市，每换一个地区都要点击省地图，即要重复点击30次。对于每天高频率从事这份工作的用户来说，冗余的操作不利于用户体验。
可能要是这样描述的话，项目经理会觉得改了Bug之后用户是减少了大量操作从而赚了用户体验，是需要优化程序。
结论：在尊重既定事实的前提下，将Bug参数化，使得解决与不解决Bug的差异悬殊化。用这种框架去影响开发和项目经理实现对Bug的认可。
