原文地址： 

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率极低的高可用软件。

小结：

似乎忽视了由于利益关系不能暴露的问题部分，但这种小技俩，程序员就不必学了吧。

20161218 20:34 思于家中床前