1）Bug大都出现在程序员的编码过程中。测试人员工作之一就是找出Bug，面对那些难以被人发现的Bug，测试人员通常会采取哪些手段？以您的经验，对广大测试人员有什么好的建议？对于开发人员，您有什么建议让他们减少Bug的产生？

之所以难以发现，大多是测试案例不够完整，检查测试案例是否全面覆盖了需求，等价类划得是不是够细有助于发现更多的问题。

如果已经发现的问题大多是猜测法发现的，那么惨了，这是一个天马行空的测试，所有的BUG都将是难以发现的BUG，碰运气吧。如果你真的是在这个不幸的团队，别伤心，你有很多同伴都是这样不幸，继续用你学过的理论和可能不太多的编程经验，挖边界值，找亚边界，偷听开发人员聊天，看他们哪块儿是赶工的，哪块儿编得特艰难的，BUG往往在这里的，上升到理论就是20-80原则。

发现难以发现的BUG曾经是评价测试人员的一个重要指标，这要求测试人员细心，有耐心，分析能力强，知识面广，逆向思维能力强，有创造力。要想练耐心细心，可以玩拼图，练习在人民日报上找错别字。练思维方式可以玩密室逃生，玩找不同。可以看出，测试人员还是满讲天份的，女生往往细心耐心有余创造力不足，男生偏向于跳跃思维，但往往坐不住。

随着安全开发的概念的出现，软件的不可控性下降了，大家可以等着看微软Windows 7的补丁频率是不是还像2000/XP那么频繁。这个年代对测试人员的要求变成了开发能力强，要求结构化思维能力，简单的说，人治变法治了。

开发人员的随意性是很大的，据说中国的开发人员和印度的开发人员的差别就在于中国的开发人员喜欢小创新而印度的开发人员一般比较乖。对于控制BUG，人治不如法治，人治是指教育开发人员开发时要多做校验，严格按需求开发，不要玩小创造等等，法制是指有严格的开发规范并有技术手段去保障开发人员遵守这样的规范。别把开发人员累死也是减少BUG的重要方法，测试人员成长为项目经理时一定记着这一点。

（2）Bug除了出现在程序员编码阶段外，在测试过程中，会不会因为测试人员的操作失误，亦或是其他原因，导致软件出现Bug呢？

只要软件还在生命周期里，都可能导致BUG的产生。在测试阶段，测试人员没发现的BUG，就留在软件里了，测试人员理解错误，本来是毛毛虫的BUG，他给理解成甲壳虫的BUG，而开发人员也居然就给改成甲壳虫了，也就引入了新的BUG。如果测试管理到位，测试人员发现的BUG不是直接交给开发人员，而是有个对需求了解比较好的管理者审一下，确定是否真的是BUG，再交给开发人员，可以有效地避免大部分测试导致的BUG。

编码阶段的BUG其实只是BUG出现的一个小方面，最多的BUG，或说最严重的BUG，往往是在需求阶段，越早生成的BUG越难改，后果越严重。

（3）对于测试人员来讲，除了借助于一些测试工具外，还应具备什么样的个人能力？是否需要具备自己动手处理Bug能力？再则您认为软件开发人员是否需要具备自我测试的能力？

会用测试工具在应聘时超级管用，但要想当一个合格的测试人员，工具外的功夫还需要很多修炼。测试人员的技术能力很重要，作为开发测试，问题报告是给开发人员看的，需要用开发人员能看得懂的语言，因此懂开发，用开发人员的语言去描述问题就非常重要了，而如果是第三方测试，那么问题单不仅开发人员要看懂，业务人员，也就是用户也必需能看懂，这又要求测试人员要有被测软件所应用的领域的知识。

表达能力也很重要，就是要把你发现的问题说明白，让别人看得懂。好的程序员用注释让别人看得懂，好的测试人员不用注释就得让别人看得懂。特别是不容易重现的问题，需要描述很多问题出现的背景条件，绝对是一个挑战。

就像你无法描述开发人员应当需要什么能力一样，测试人员也各不相同，不管是技术强的，管理强的，沟通强的，脑子活的，细心的，耐心的，都会有发挥优势的地方。

如果说一定要找一个最关键的能力，那就是责任心了。这是针对不太规范的测试而言，对于理想状态的测试，如果测试案例都定好了，测试人员按部就班执行就好。但一般来说，测试方案都是粗线条的，那么做一个案例还是做两上，猜测还是不猜测，都是测试人员主观需要确定的，这时，有责任心的测试的价值就体现出现了。

我不建议测试人员自己动手处理BUG，开发人员和测试人员形成的相互制约在一定程度上保证了软件的质量。测试人员如果自己处理BUG，引入新的BUG的概率会大增，而且发现这样的BUG要比发现开发人员制造的BUG难得多。

同样的道理，开发人员测试也会造成相互制约机制的破坏，因此，有条件的软件公司最好不要让软件开发人员测试自己的软件。但这也有一点例外，就是开发人员用白盒测试工具自己检查自己代码的质量，这样的测试还是建议开发人员自己做的。

（4）我们经常看到一款软件在正式发布后，仍存在很多Bug。在产品发布后，是否还需要人员去进行测试Bug？对一款产品的测试工作，Bug率达到一个怎样的状态才算作合格产品？

即使软件再也不打算升级了，只有还在使用，测试就还有意义。测试可以为下次升级做准备，即使不再升级，测试也能给使用者以信心，对于存在的问题，给出解决或预防的办法。更主要的是，用户一定会发现问题，开发人员要么根据测试人员的复测情况进行修改，要么就只能教育用户怎么避免问题了，比如：“那个地方千万别输入负数，否则系统会崩掉了”，多丢脸呀。

而如果一个软件行将就木了，不仅不会再改，甚至不会再用了，那就别测了。

Bug率多高跟软件给谁用有关，飞机火箭的BUG率要求肯定要比办公软件苛刻得多。套用一句据说是某快餐店销售人员的话：“给冰激淋的量应该是客户不投诉的最少量。”那么BUG率就应该是客户还愿意选用你的软件的最高BUG率就好了。对于一般软件来说，这完全是个市场行为，客户能接受，项目经理一定不会再投入测试人员了。而如果你的对手重重，或你有一个很有追求的上司，那么BUG率就会要求得比较严格。而对于飞机火箭来说，由于硬件投入大，政治影响大，事关人事等原因，BUG率的要求会非常苛刻，测试投入也应该大得多。

（5）您认为测试人员有没有必要与开发人员在同一个项目组工作，能将Bug扼杀在萌芽状态吗？如果采用这样的工作方法，责任应该如何界定，避免互相推诿？

将BUG扼杀在摇篮里是我们的终极追求。上面的问题谈到开发人员可以利用白盒工具检查自己的代码，这样就可以在代码还没有离开开发人员的手里的时候就杀掉它。在一个大型开发项目中，测试可能有很多的角色，如开发测试，为开发人员贴身服务，独立于测试，跟开发人员背对背，跟踪每一个研发版本，在发版前还有一个测试组，这个测试组发现的问题就要打开发和测试组的板子了。软件发版后，再有一个测试组，专门针对用户的反馈进行测试，将认为必要的改动记入下一个版本的需求中。

不管测试和开发是在一个项目组中还是完全独立，出现推诿的原因一般是因为测试和开发上面共同的领导工作缺位，没有一个老大说了算。测试人员发现开发人员的问题天经地义，似乎开发人员没有反驳的余地，但测试人员也会有“水平有限，错漏之处，敬请谅解”的地方，这要是让开发人员揪住，当然会出现界定责任的问题。这就需要有一个站得更高的人，充分了解软件的需求和设计，由他来充当裁判，一方面保证开发人员按要求修改问题，一方面把测试人员提得不合理的问题驳回，主持公道，解决争端。

来源