“BUG”的由来

　　Bug一词的原意是“臭虫”或“虫子”。但是现在，在电脑系统或程序中，如果隐藏着的一些未被发现的缺陷或问题，人们也叫它“bug”，这是怎么回事呢？

　　原来，第一代的计算机是由许多庞大且昂贵的真空管组成，并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热，引得一只小虫子（Bug）钻进了一支真空管内，导致整个计算机无法正常工作。研究人员费了半天时间，总算发现原因所在，把这只小虫子从真空管中取出后，计算机又恢复正常。后来，Bug这个名词就沿用下来，用来表示电脑系统或程序中隐藏的错误、缺陷、漏洞等问题。

　　1945年，计算机还是由机械式继电器和真空管驱动的，机器有房间那么大。体现当时技术水平的MarkⅡ，是由哈佛大学制造的一个庞然大物。当技术人员正在进行不整机运行时，它突然停止了工作。他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。

　　与Bug相对应，人们将发现Bug并加以纠正的过程叫做“Debug”（中文称作“调试”），意即“捉虫子”或“杀虫子”。

　　后来就直接用bug 在现在很多的软件测试中 都用Bug来说明那些问题。

　　“Bug”的创始人格蕾丝·赫柏（Grace Murray Hopper），是一位为美国海军工作的电脑专家，也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字，正是由赫柏所取的。1945年的一天，赫柏对Harvard Mark II设置好17000个继电器进行编程后，她的工作却毁于一只飞进电脑造成短路的飞蛾。在报告中，赫柏用胶条贴上飞蛾，并把“bug”来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。

 

专题入口：http://www.51testing.com/zhuanti/bug/bug.htm

测试人员如何说服他人认可你提交的缺陷是需要修改的？

 

　　软件测试每周一问：作为一个软件测试人员经常会遇到程序员或者设计人员拒绝修改你提交缺陷的情况，但是往往到最后这个缺陷会被用户提出，不得已再进行修改，给个人和公司带来一定的负面效果，那么如何说服他人认可你提交的缺陷是需要修改的？欢迎大家各抒己见！

　　会员cityyard的精彩回答：

　　这个问题其实非常不好回答，实际情况往往很复杂……

　　就我个人经验写一点感受吧~~当然了，诸如要写清楚现象，尽量详细报告等是QA人员应有素质，这里篇幅原因暂且搁置不谈。

　　首先，开发方必须提供完整详细的式样书和制限事项。式样书是测试人员测试的基础，测试人员如果按照式样书测试得到了不一样的或者奇怪的结果，那么必然是bug无疑，没有任何可以争论的余地；如果测试人员执行了式样书上没有写的动作，得到了一个奇怪的结果，那么首先去制限事项里面找，如果制限事项写了，那么意味着开发者知道这个问题并且还在开发中，那么OK暂时放过（注意是暂时），如果制限事项也没写，那么再看这个动作是不是用户可能做出来的动作，举个例子如果一个软件的某个命令完全封装在内部，调用时一定会以普通用户身份执行，那么测试人员使用root测试出来的问题就是无效的（注意，当然封装的命令可能因为封装错误用root执行了，但那是另一个bug）；如果测试人员的动作虽然式样书没有，但是却是用户可以做出来的，那么抱歉，这个问题必须修改，而且还要围绕这个被式样书遗漏的问题进行拓展。

　　其次，测试开始前由开发方review测试方的测试计划，并针对测试方对式样书的疑问答疑。这一点有两个好处，一个是开发方可以尽早指出哪里测试不合理，哪里测试薄弱，另外也可以减少以后因为双方理解上的差异带来的时间浪费。虽然这会占用一点开发人员的时间，但是磨刀不误砍柴工。

　　第三，建立完备的版本管理系统，这个系统如何建立前面的每周一问已经详细讨论过了，目前要补充的就是，版本管理中必须把式样书和制限事项一起加进去，开发者发布了0_0_1版，其中制限事项是文件数目不能超过1M个，0_0_2版开发者取消了这个制限，那么必须在发布作这个版本的同时写明这一点，测试人员才能据此测试。严格的版本管理可以有效减少纠纷，如果测试人员使用0_0_1版测试1M+1个文件失败，那么是无效测试，如果使用的0_0_2版，那么就是bug必须修复，无可争论。

　　有了上面三条，大部分问题差不多能解决了，但是还是不行，差在哪里？主要还有两个问题，一个是测试方可能指出一些跟个人喜好相关的地方，比如测试方可能指出GUI一个警告信息窗的字体太暗而且不显眼，不容易被注意到，这类问题无法用上面三条来解决，因为是否容易被看到本身就不好界定；另一个问题就是（尤其是到了测试后期），测试人员连续跑了好几天测试忽然程序死了，再来一次又没事了，告诉开发人员这个现象，开发人员也解决不了，因为很难再现，如果是测试环境问题还好，如果真的是软件缺陷那被用户遇上就很严重，但是这种问题无论是让QA无休止的尝试再现还是让开发者没头没脑的调查都很难说得过去。

　　......

 

专题入口：http://www.51testing.com/zhuanti/bug/bug.htm

测试如何更有效说服研发去修改bug？

　　问题描述：测试过程中一些bug会被研发认为是无效bug，但从用户角度出发，测试认为该bug需要更改，此时测试如何更有效的说服研发去修改bug？

　　精彩回答：

　　1. 扭转研发领导的思想，提高研发人员的响应速度：

　　a). 让研发团队的领导重视缺陷：

　　很多研发团队的领导都是销售出生，懂技术的很少，他们和搞技术的想法明显不一样。我在的第一家公司，发布版本时很多时候，都是没有测试结束，功能开发的差不多就把产品卖掉了，后面再对版本不断升级，结果这个公司没多久大概3年不到就散伙了。后面一家公司的领导是做质量管理出生的，明显对测试的质量要求就不一样，每次要求都特严，对以前测试结束标准都做了进一步的修改。如果领导对缺陷都视而不见，你说研发人员还愿意花大量的力气去修改Bug吗？所以说，团队的领导的想法或意识，对缺陷是否修改起到非常重要的作用。我记得以前测试高手zhuzx也在每周一问中提到过，大家也可以借鉴一下。

　　b). 采用常用的缺陷管理工具（QC9.0），提高缺陷的透明度：

　　我们公司使用缺陷管理工具（QC9.0）,测试经理任管理员，给公司高层领导、项目经理、开发经理都分配了权限，自己可以登录系统查询相关信息。在测试后期，特别是要发布版本前后，领导们一有空，也随时上去浏览一把，无意识给开发人员施加了较大的压力。如果这个时候还有很多Open的缺陷，开发人员自然不敢怠慢。

　　c). 把开发人员的修改缺陷的响应速度，记入绩效考核内容：

　　由于公司总监特别关注产品质量，我们公司对缺陷修改这一点做得比较好，每次都是递交缺陷以后，开发人员响应特别快。如果有疑问，就马上和测试人员一对一交流，尽快修复或解决该缺陷。我们公司的口号是：“宁愿花出100倍的代价，也不让发现的缺陷留给客户”。还有一点就是开发人员绩效考核的时候，我们测试人员要给开发人员打分，很重要的一点就是：开发人员对测试缺陷的响应速度，如果这一项很低的话，老大要找你谈话的，问具体原因是什么？呵呵。所以，我们公司很少有测试人员追着开发修改缺陷的情况，把修改缺陷的响应速度纳入个人绩效考核，我个人觉的是一种比较好的方式，值得借鉴或推广。

　　2. 组建一个合理的研发团队，规范测试规范：

　　a). 关键是建立一个完善的研发机制：

　　在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关制度或相关部门去约束。毕竟在国内软件的软件企业缺少这样的部门，所以说把修改缺陷相关的重任推到了测试人员的头上，其实对测试人员实在是太不公平了。要解决这个问题，最关键就是建立一个完善的研发机制，让QA等相关部门督促解决这类问题，比较好。

　　b). 分清团队成员的具体责任：

　　对于研发团队中的每个成员，必须责任明确，否则像督促缺陷修改这样的事情本来不是测试人员的责任，现在都推到测试人员头上了。很郁闷！！

　　c). 完善测试规范，明确Bug管理制度：

　　大部分的公司，都没有单独的部门来单独管理督促缺陷是否修改，都默认为是测试部门的事情。个人觉的最好是赋予项目组中相关人员一定的资质，让他们去处理这些琐事。经常碰到这样的情况，很多争议的缺陷都一直放到后面一个版本，一段时间下来，几个版本争议的缺陷就多于100个，弄得后面版本也不好发布。我们的做法是，发布前几天，对每个争议的缺陷用邮件先发给项目组成员先看，后面在召开缺陷评审会议，如果通过，毫无疑问修改，否则关闭或保留到下一个版本。

　　本文出自51Testing软件测试网，感谢会员sun_0910在每周一问（08-10-27）中的精彩回答。

　　http://bbs.51testing.com/forum-157-1.html

　　3. 从源头上杜绝无效缺陷的递交：

　　a). 测试前细化测试需求,避免递交歧义缺陷：

　　很多研发不愿意修改的缺陷，大部分都是由于需求不明确或者理解歧义引起的。所以，最好的做法是在测试以前，开个项目会议，细化一下测试需求，让研发去确认或项目组成员集体Review，达成一致观点。尽量减少理解上的歧义，力争尽早消除无效或争议的软件缺陷，避免递交的缺陷成争议的缺陷。测试人员无法说服研发，让研发去修复缺陷，长期这样，测试部的威信就大大降低了。

　　b). 把握不准的缺陷，递交以前最好讨论一下：

　　特别是在测试初期，由于测试介入项目时间较短，有时候测试人员对业务或需求了解不深，递交错Bug也是常有的事情。这个时候，往往测试认为自己递交正确了，开发人员认为自己开发软件是对的，互不相让，如果处理不好，很容易弄僵关系，弄得大家都不是很愉快。要是项目中出现这样的Bug，是很难说服研发去修改的，还有可能成为研发抓你的“小辫子”的有力证据，要是这样以后就更难做了。个人的一些做法：所有的测试缺陷相互审核后，才递交到缺陷系统上公开，是最为保险的方法。

　　c). 清楚无歧义的描述Bug，减少随机测试，带来不可重现的Bug：

　　很多时候，测试人员把缺陷描述不清楚或者缺陷有歧义，开发人员看不懂，不明白具体的意思，加上开发人员任务重时间紧，很容易产生逆反心里，这就让开发人员对测试人员有看法，以后递交的缺陷认可度就大大降低了。还有就是要减少随机测试，一定要保证递交的缺陷能够重复出现，最好要有截图、图片或者用数码相机照下来，让开发人员认识到这个问题确实存在，并且更具说服力。

　　d). 做好版本配置管理工作，保证测试环境的准确性：

　　很多同事发现的缺陷，只有在测试环境下重现，而在开发环境下不能够重现。这样的缺陷开发人员往往是看不到的，他们很容易得出结论，说测试人员递交无效的缺陷而被拒绝，大部分情况发现是版本弄错啦！！我们唯一能做的就是做好源代码的配置管理工作，保证测试环境版本的正确性和独立性，自己编译自己部署测试环境。只有这样，才会减少无效缺陷的递交，避免“费劲周折”说服开发人员修改缺陷。

　　4. 正确分析测试中的软件缺陷：

　　a). 为递交的每个缺陷准备几条充足的理由：

　　一般情况下，我们提到一个Bug时，开发人员都会说出很多可以不修改缺陷的理由，尽量搪塞住我们的口，要求我们关掉缺陷或者置为无效或者延期到下一个版本。如果你很牛，你可以为自己递交的每个缺陷准备很充足的理由去说服开发人员；如果你不是太强，那就可以求 助部门同事，集中测试部门团队的力量，想一些好的、站得住脚理由，详细介绍给研发人员听，只要我们递交的Bug，每个都具说服力的话，我想他们也会尽快修改的。这种方法还真是不错，大家不妨试一试。

　　b). 详细分析缺陷给项目带来的各种可能影响或缺陷风险：

　　比如说，我们递交一个缺陷，如果研发的觉的这个缺陷可以修改或可以不修改时。我们一定要给研发分析修改这个缺陷的必要性，不修改，对客户带来哪种可能影响或存在哪些风险。要在修改缺陷的代价与修复成本的关系上去衡量。相信，当我们对缺陷分析的很详细时，研发人员一定会修改Bug的。

　　5. 做一个聪明的测试工程师：

　　a). 注意和研发人员的沟通技巧：

　　如果测试人员没有做过开发工作，理解也许就比较片面。有的测试人员，对待问题没有耐心，性情比较急，也是常有的事。如果没有较好的沟通技巧，也许就是几句话的功夫，就和同事争吵了起来，弄得大家都比较尴尬。个人建议：谈话时，要注意沟通技巧，要有换位思维的方式，做事情对事不对人，处理事情一定要有一颗宽容的心。只有这样，才能够很好的说服研发去修改Bug。

　　b). 和研发人员搞好私人关系，做研发的听众：

　　比较明智的测试人员，一定要学会倾听研发人员的心生。很多时候，开发人员碰到工作困难的时候，很希望和人倾述，如果测试人员是他的听众，那么你们的关系一定会不错。搞好了私人关系，工作中你递交的缺陷，他们就不会那么斤斤计较了，毕竟关系是基础，关系好了好说话呀，在中国就是如此。如果私人关系好了，说服研发修改Bug就是很容易的事情。不过得提醒一句：不能因为关系好就把Open的缺陷给关了。

　　......

 

专题入口：http://www.51testing.com/zhuanti/bug/bug.htm