原文链接：https://blog.csdn.net/laoyang360/article/details/53729572
0、引言：
本文的项目验收指乙方完成甲方任务书中的所有任务，交付甲方运行验收。一般验收标准包括：功能达标、性能达标。本文的项目不具备通用性。
2个周（含周末）的项目验收，累、疲惫、心力憔悴自是不必说。临近收尾之际，想想15天的全程经历。 由于测试介入晚、没有充分测试、项目交付节点临近，等等……这样、那样的原因会导致项目功能或者性能达标。
验收阶段越发体会到：暴露问题是对项目验收最起码的尊重！不要遮遮掩掩，问题暴露的越早，解决问题的成本越低！
特将近期的思考总结如下：
1、程序员发现了问题，但是不第一时间说出来，是什么样的心境？
1.1 测试部估计测试不到吧。
程序员或许会说：反正是黑盒测试，逻辑复杂着呢，测试部不一定测出来。
正确的思维逻辑应该是：
（1）前期有相对充分的需求分析、设计阶段，形成模块设计文档。
（2）对应模块的测试人员在项目的开测的前期，与该模块的开发人员就设计文档进行对接，形成初步测试用例，并逐步完善。
（3）召集项目开发经理、测试经理、模块开发人员、模块测试人员评审测试用例。这样，基本能做到不漏掉用例。
（4）测试实施阶段，除了基础测试外，对于复杂的业务逻辑进行3处左右的发散测试。
1.2 不好重现或不能重现，挂起吧。
非必现Bug，没有环境重现、不知道如何重现。就放在那里吧。
我返回一句？Bug既然存在，肯定是可以重现的，只是我们不知道重现的方法而已。在没有充分的重现的情况下，你如何确保重现的概率？重现需要的场景考虑全了吗？万一交付的演示的时候，出现了Bug怎么解决？
正确的思维逻辑应该是：
（1）尽可能设想更多的方式进行重现；
（2）总结到已经做的重现环境、思路，在Bug处做好梳理；
（3）和技术经理、架构师讨论有没有好的重现、逆向分析方案；
（4）以上3步都试过后，再总结下重现的概率，备注下Bug。
1.3 事不关己，高高挂起。
和其他同事联调出了Bug，非常自信自身负责的模块没Bug。
正确的思维逻辑应该是：
（1）再次进行对接联调，确认是否是自身代码逻辑的Bug？
（2）排除一切和自己相关的障碍，做好充分排查。
1.4 多一事不如少一事。
他也不容易，别影响人家绩效。
正确的思维逻辑应该是：
（1） 发现了就第一时间暴露给相关开发人员、技术经理等。
（2）增强团队意识，不是仅从自己角度考虑问题，而是要有大局观。
（3）团队也应该给予一定的激励机制。
1.5 不着急，过会再告知项目经理或者技术负责人吧。
过会，过会，就这么拖到了验收。
正确的思维逻辑是：
（1）第一时间提交Bug库，如：TD，并指派给责任人。拖着很容易被其他事情分散精力。
（2）设定不同Bug级别，High、Mid、Low三级，High级别直接邮件抄收项目经理。
2、为什么不敢说出来？
2.1 怕受责备。
其实，完全没有必要。团队的绩效是每个人绩效来维护的。团队负责人对于用于发现关键问题、关键Bug的人往往都是正面激励的。
这点，新员工往往顾虑较多。我3年前刚入职时体会更深。没必要怕，Boss不吃人的。
2.2 害怕领导或自身性格原因，不喜欢说出来。
总感觉，差不多，应该没事吧？这些小心理作祟，更是耽搁了“治疗”的最佳时机。反而，一旦出了问题，团队负责人往往会因为你的不及时汇报而受到责备和责任追溯。
3、要勇于暴露问题。
3.1 暴露问题是对项目验收最起码的尊重！
要始终坚定的认为：
1）任何人都不喜欢有Bug的软件；
2）问题终究是要解决的。
3.2 不要遮遮掩掩，问题暴露的越早，解决问题的成本越低！
这点有过产品开发、项目实际供给销售的童鞋体会更深些。并且公司的市值越高、客户越多、产品销售的越多，一旦出了Bug，所有客户相同产品都会有相同的Bug。此时的抱怨率、投诉率、产品的忠诚度都会大打折扣。
试想下，如果前期暴露问题，仅是自身开发的阶段暴露问题，就会扼杀了Bug扩散的“摇篮”，扼杀在萌芽状态。何乐而不为呢？
4、程序员要学会直面Bug。
我始终认为：程序员要对自己的Bug负责，甚至终身负责都不会过。这样以后，自测才会充分，场景用例才会充分，而不是代码完了就丢给测试。这是自己对自己编码不负责任的表现。
并且程序员不要回避Bug。正如我去年所说“真正的程序员，敢于直面多变的需求，敢于正视疑难的Bug！”。
5、测试再充分也不为过。
验收阶段，听到甲方领导对其接受人员的要求是“往死里测！”。仔细想想也是很有道理的，这样真正到用户都是充分验收过，Bug率极低的高可用软件。