BUG平台应该是一个知识库

被风遗忘
 被风遗忘
发布于 2012年02月27日
收藏 41

我很喜欢看各个产品的Bug追踪系统,比如jQuery的Bug Tracker,因为在Bug系统中总能发现一些非常细节的问题,补充自己的知识,慢慢地自己的代码的兼容性会有很大的提高。

但是,在各个Bug系统之中,包括现在公司使用的Trace系统,无一例外地存在一些让我不满意之处,其中最大的原因就是很多Bug系统仅仅是作为Bug的记录系统存在,而没有试图去让一个Bug成为一个知识的积累,让整个Bug系统变成一个丰富充实的知识库。这样的Bug系统,永远都只是提供一个简单的业务流程,不会变成干完人员、产品、甚至是整个团队的进步的天梯。

在我看来,一个Bug系统应该更加全面,管理Bug的生命周期的同时,也用于管理一个产品、团队的知识,更可以与周边系统合作,形成一个真正的集成式管理平台。

Bug的分类

现在的Bug系统,对Bug系统的分类通常有这么几种:

  • 根据性质:Bug、Feature、Enhancement等。
  • 根据危险程度:Trival、Minor、Normal、Major、Critical等。
  • 根据模块、系统、可重现性等与项目紧密相关的分类。

但是这些Bug系统往往忽略了一个很重要的分类方式,那就是“按Bug影响面分类”,在这种分类模式下,一个Bug可以根据其影响的范围来进行区分:

项目型Bug

与当前项目的业务流程、逻辑等有紧密关系的Bug,此类Bug只可能在当前项目中出现,离开了项目的大环境就没有任何存在的意义。

针对此类的Bug,只需要在当前的环境下修复即可,不需要考虑太多的问题。

复发型Bug

此类Bug通常也与项目有紧密的关系,但是此类Bug在项目的整个演化过程中一而再再而三的出现,也许每一次出现的原因有些许差异,但表现上极其相似。比如某系统每天下午17:00左右会出现无法提供服务的情况,在第一轮修复的情况下,几周后继续出现此类情况。

在这样的前提下,该问题就应该被评定为复发型Bug。对于复发型Bug,项目管理层及开发人员都应该给予绝对的重视,投入足够的人力和时间来对问题进行彻底的跟踪和追查,以期从根本上进行解决。

同时,在问题被定位并修复后,可以进行一次case study,以杜绝此类问题的再次发生。

通用型Bug

此类Bug是我认为当前的Bug系统最没有关注到的一个问题,而且相比前面两类Bug往往可以在项目层面通过制度和流程来进行规范,通用型Bug是一个最需要自动化处理的问题。这往往涉及到不同团队之间的合作,也是Bug平台成为一个知识库的最为基础的条件。

顾名思义,通用型Bug即与项目本身的业务没有任何关系的,仅仅是技术上存在的问题。比如我最近发现的一个Bug,其可以用以下的代码来表现:

<!DOCTYPE html> <head> <base target="_blank" /> <body> <script> var iframe = document.createElement('iframe'); document.body.appendChild(iframe); iframe.contentWindow.location = 'javascript:;'; // 以上代码会在IE9下弹出一个窗口 </script>

这个Bug很明显,是不属于任何项目的,即所有项目在特定的情况下都可能使用类似的代码,产生相同的Bug。

在这样的情况下,如果将这个Bug继续划定在某个项目之下,那么他最多只能为一个项目提供帮助,防止该项目再次出现类似的问题。因此我们各项目组间可能经常能看到这样的对话:

A:Hi,我们这边发现一个问题,具体是…………这样的,你们有相关经验吗?

B:哈哈,这个我们前段时间才遇上过,解决方法是…………那样的。

A:谢谢,谢谢!!

确实,这样的场景很多,甚至能贯以“项目之间善于交流”的美名,但是如果认真地去思考,这样的场景真的有必要吗?如果有一个自动化的平台,会将这些通用的Bug都公布出来,每个人各取所需进行关注、记录,又怎么会出现这样的对话呢?

交流,哪怕是使用最好的方式进行最有效的沟通,始终是有一定的成本的。同时,交流通常是1v1的关系,即便频繁的接触、沟通,一个知识也很难以广播的形式让尽可能多地需要他的人接收到。

正因如此,我才认为一个Bug系统的职责远不止记录、处理、关闭Bug,而应该作为一个知识的集散地,在团队的发展中起更大的作用。

通用性Bug处理平台

前面也提到,对于通用型Bug,平台应该有能力对其进行分发、通告,在这里再详细地总结一下,一个较为完善的Bug平台,在处理通用型Bug方面应该至少有以下的特色:

Bug的tag
无论系统内置使用怎么样的方式来对Bug进行分类,其分类的维度总会有照顾不周之处。因此在Bug平台中应该引入tag的概念,让每一个Bug都能够有一个或多个tag,使用tag这种通用的方式来标识一个Bug的属性,也进一步方便了灵活的分类。
Bug的订阅
在Bug有了tag之后,所有拥有相应权限的人都可以订阅其指定的tag的通用型Bug。当一个Bug被提升为通用型Bug时,Bug平台会找到所有订阅了这个Bug拥有的tag的用户,并通过邮件等形式向其发送该Bug报告。而随后Bug的每一个处理环节都会有邮件等形式的广播。
Bug的共享
在Bug可以被订阅和广播的同时,通用型Bug应该允许每一个有权限(并且此类权限应该放得很宽松)的用户来参与讨论、修补,每一个人都可以提交解决方案,再由相应的QA进行验证后给予实行。这样的效率远大于一个项目的开发人员独自苦苦挣扎,因为很可能有某个人曾经遇上过这个问题,对他来说提供解决方案仅仅是举手之劳。

Bug的生命周期

当前多数的Bug平台将Bug的状态分为几个阶段,一般是Open -> Resolved -> Closed这样的过程,但这其实远远没有涵盖一个Bug处理过程中应该有的环节。

当然作为一个简单、现实为上的Bug系统,其主要环节有以上三者足矣,但是如果需要将Bug平台扩展成一个知识库,就不得不添加更多的环节,以期得到更多的信息:

  1. Open,Bug的发现阶段,此时创建一个Bug,通常这个动作由QA进行。任何可重现、不可重现、小频率重现的问题都可以进入到这个阶段。
  2. Reproduce Step Confirmed,Bug的重现步骤被确定,通常由QA提交。在这个阶段的Bug通常是稳定的,至少通过QA提供的重现步骤能大概率地被重现出来。
  3. Reproduce Environment Confirmed,Bug的重现环境被确定,通常由开发人员提交。在这个阶段,在正常的重现步骤之外,开发人员已经可以提供一个最简的环境来复现问题,可能是一段非常精简的代码,也可能是一个很简单的步骤,其特点是这个重现的环境远比QA的按步操作来得简单,甚至可能得以自动化的重现。如果问题可以自动化重现和确定,则可以考虑将自动化脚本作为单元测试保存。
  4. Reason Found,问题的根本原因被确定,通常由开发人员提交。在这个阶段,开发人员需要描述问题产生的原因,可能是某个业务逻辑的理解有分歧、或者某个第三方产品确实存在Bug、或者某段代码存在着函数使用的错误等。
  5. Resolution Submitted,解决方案已提交,通常由开发人员进行。在这个阶段,开发人员提交一个完整的解决方案,根据开发人员的思路,这个解决方案确实得以修复该问题。随后同项目级的人员、QA可以对该解决方案进行评估,确定对其他模块不会有影响等。
  6. Resolution Applied,已经应用了解决方案,通常由开发人员提交。此时开发人员指定一个新的源码版本号,该版本号中的相应代码段应用了第5步中提交的解决方案,问题应当已经修复。
  7. Resolution Confirmed,问题已经确定修复,由QA人员提交。此阶段QA确定问题已经被修复,并且经过了一定范围的回归测试,确保问题不会对其他模块产生严重影响。在这个阶段,Bug依旧是开放状态,各成员可以对Bug进行参与,作一些总结性的讨论。
  8. Close,Bug关闭,此时Bug已经锁定,可以作为一个固定的知识项来查看,但不再有修改和讨论的可能性。

以上为一个非常周全的Bug生命周期管理,但确实不需要对其进行一个强制的要求。一个Bug平台可以提供这些生命周期,也许只是简单地在“Bug状态”中添加相应的项,而进一步如何引导用户对这些环节进行充分的利用,则可以通过团队的规章、Bug平台本身的界面等方面来进行,强硬地规定只会让Bug追踪过程事倍功半。

其他方面的增强

上文提的是个人认为Bug平台向知识库整合过程中最重要的一环,即通用型Bug的分类、分享、订阅工作,以此为其他来散布众多点状知识,以期通过所有人员共同参与交流、沟通,再将点状的知识整合成线状甚至是面状的知识体系,补充团队的经验和能力。

但是在此之外,其实Bug平台还可以做很多事情,来提高这个“伪知识平台”的使用体验,证知识更加有条理、有结构:

  • 与源码平台关联

    一个Bug平台应该与源码平台有着非常紧密的关系,包括一个Bug在哪个版本(A)发现,在哪个版本(B)修复,并可以通过平台找到源码平台中两个版本的diff,比如scm.xxx.com/diff?file=abc&rev=A:B。这要求Bug平台与源码平台都提供相应的接口,可以在两个第三方系统间进行交互合作,现时也要求Bug平台有一个严格的规范,在Bug的open和close操作中提供相关的版本号。

  • 与知识平台关联

    Bug是知识的来源,那么Bug提供的知识自然要进入到知识管理平台。这一点需要系统的智能化识别,当一个Bug其信息足够完善,包括了前面提到的Bug生命周期的各个环节应有的信息的时候,Bug平台应该主动与知识平台连接,将这个Bug整理成一份真正的知识文档进入到知识管理平台。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:BUG平台应该是一个知识库
加载中

最新评论(32

Monkey
Monkey

引用来自“被风遗忘”的评论

引用来自“victorhuang”的评论

引用来自“Monkey”的评论

引用来自“victorhuang”的评论

引用来自“Monkey”的评论

引用来自“被风遗忘”的评论

引用来自“Monkey”的评论

引用来自“桔子”的评论

引用来自“Monkey”的评论

我只说一个BUg,我刚开始那会和鬼子干事,鬼子的测试人员测出一个bug,是undo和redo的bug,操作20步,然后往回undo到头,redo到头,发现状态没有回到最初那个时候。这bug用文字都没办法描述,因为详细的操作步骤是在太多,最后直接录制视频发过来。而且这群人并非是软件测试人员都是软件销售人员,后来转到国内公司了对比一下我们的测试,顿时感觉差距不是一般大,基本上我这个开发换一个公司就能挑出不少bug,每到一家公司总有测试问我,你是怎么测试的啊,怎么发现了那些他们好几年都没有测试出来的bug啊。

en 鬼子做软件的都是非常敬业,而且分工非常明确,每个人只精通某方面。而天朝就是样样行,样样耸

两年过去了,到现在为止我还没看到一个国内公司做到他那种水平。而且更意外的是鬼子是用swing做了一个复杂的设计程序。我们这边人恐怕一听说swing做应用就会说傻子才会。但是鬼子就能用这玩意做一个相对有水平的东西出来。

Monkey.我看你是在对日外包干傻了吧.这么钦佩鬼子.难道国人就不行吗?还是不是出了那么多的技术牛人哦.

我早就没在哪里干了。不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平。一个最简单的打开文件可以提示四五种错误信息出来。加上这几年的经历我可以确定的说中国软件水平离日本差的很远,这一点不是你谩骂就可以改变的,那一家公司是目前我做的最小的公司,但是对于产品的态度也是最高的,代码注释要求就是所有的方法都要有注释,一个都不能少,否则都是纳入bug范围的。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”
你说的这句话口气真大啊,试问你在国内哪几个公司干过?或是你都用过哪几个国产收费软件?你崇拜鬼子可以,但是你这样诋毁国人就是一SB

爱国愤青伤不起啊。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”

就是这句话,让你暴露了你是一个SB的实质。

OK,大家的想法都是好的.别伤了和气.

我只是说了实话而已,我个人承认差距。而且这种差距不是技术上造成。
被风遗忘
被风遗忘

引用来自“victorhuang”的评论

引用来自“Monkey”的评论

引用来自“victorhuang”的评论

引用来自“Monkey”的评论

引用来自“被风遗忘”的评论

引用来自“Monkey”的评论

引用来自“桔子”的评论

引用来自“Monkey”的评论

我只说一个BUg,我刚开始那会和鬼子干事,鬼子的测试人员测出一个bug,是undo和redo的bug,操作20步,然后往回undo到头,redo到头,发现状态没有回到最初那个时候。这bug用文字都没办法描述,因为详细的操作步骤是在太多,最后直接录制视频发过来。而且这群人并非是软件测试人员都是软件销售人员,后来转到国内公司了对比一下我们的测试,顿时感觉差距不是一般大,基本上我这个开发换一个公司就能挑出不少bug,每到一家公司总有测试问我,你是怎么测试的啊,怎么发现了那些他们好几年都没有测试出来的bug啊。

en 鬼子做软件的都是非常敬业,而且分工非常明确,每个人只精通某方面。而天朝就是样样行,样样耸

两年过去了,到现在为止我还没看到一个国内公司做到他那种水平。而且更意外的是鬼子是用swing做了一个复杂的设计程序。我们这边人恐怕一听说swing做应用就会说傻子才会。但是鬼子就能用这玩意做一个相对有水平的东西出来。

Monkey.我看你是在对日外包干傻了吧.这么钦佩鬼子.难道国人就不行吗?还是不是出了那么多的技术牛人哦.

我早就没在哪里干了。不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平。一个最简单的打开文件可以提示四五种错误信息出来。加上这几年的经历我可以确定的说中国软件水平离日本差的很远,这一点不是你谩骂就可以改变的,那一家公司是目前我做的最小的公司,但是对于产品的态度也是最高的,代码注释要求就是所有的方法都要有注释,一个都不能少,否则都是纳入bug范围的。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”
你说的这句话口气真大啊,试问你在国内哪几个公司干过?或是你都用过哪几个国产收费软件?你崇拜鬼子可以,但是你这样诋毁国人就是一SB

爱国愤青伤不起啊。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”

就是这句话,让你暴露了你是一个SB的实质。

OK,大家的想法都是好的.别伤了和气.
IT好男人
IT好男人

引用来自“Monkey”的评论

引用来自“victorhuang”的评论

引用来自“Monkey”的评论

引用来自“被风遗忘”的评论

引用来自“Monkey”的评论

引用来自“桔子”的评论

引用来自“Monkey”的评论

我只说一个BUg,我刚开始那会和鬼子干事,鬼子的测试人员测出一个bug,是undo和redo的bug,操作20步,然后往回undo到头,redo到头,发现状态没有回到最初那个时候。这bug用文字都没办法描述,因为详细的操作步骤是在太多,最后直接录制视频发过来。而且这群人并非是软件测试人员都是软件销售人员,后来转到国内公司了对比一下我们的测试,顿时感觉差距不是一般大,基本上我这个开发换一个公司就能挑出不少bug,每到一家公司总有测试问我,你是怎么测试的啊,怎么发现了那些他们好几年都没有测试出来的bug啊。

en 鬼子做软件的都是非常敬业,而且分工非常明确,每个人只精通某方面。而天朝就是样样行,样样耸

两年过去了,到现在为止我还没看到一个国内公司做到他那种水平。而且更意外的是鬼子是用swing做了一个复杂的设计程序。我们这边人恐怕一听说swing做应用就会说傻子才会。但是鬼子就能用这玩意做一个相对有水平的东西出来。

Monkey.我看你是在对日外包干傻了吧.这么钦佩鬼子.难道国人就不行吗?还是不是出了那么多的技术牛人哦.

我早就没在哪里干了。不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平。一个最简单的打开文件可以提示四五种错误信息出来。加上这几年的经历我可以确定的说中国软件水平离日本差的很远,这一点不是你谩骂就可以改变的,那一家公司是目前我做的最小的公司,但是对于产品的态度也是最高的,代码注释要求就是所有的方法都要有注释,一个都不能少,否则都是纳入bug范围的。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”
你说的这句话口气真大啊,试问你在国内哪几个公司干过?或是你都用过哪几个国产收费软件?你崇拜鬼子可以,但是你这样诋毁国人就是一SB

爱国愤青伤不起啊。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”

就是这句话,让你暴露了你是一个SB的实质。
Monkey
Monkey

引用来自“victorhuang”的评论

引用来自“Monkey”的评论

引用来自“被风遗忘”的评论

引用来自“Monkey”的评论

引用来自“桔子”的评论

引用来自“Monkey”的评论

我只说一个BUg,我刚开始那会和鬼子干事,鬼子的测试人员测出一个bug,是undo和redo的bug,操作20步,然后往回undo到头,redo到头,发现状态没有回到最初那个时候。这bug用文字都没办法描述,因为详细的操作步骤是在太多,最后直接录制视频发过来。而且这群人并非是软件测试人员都是软件销售人员,后来转到国内公司了对比一下我们的测试,顿时感觉差距不是一般大,基本上我这个开发换一个公司就能挑出不少bug,每到一家公司总有测试问我,你是怎么测试的啊,怎么发现了那些他们好几年都没有测试出来的bug啊。

en 鬼子做软件的都是非常敬业,而且分工非常明确,每个人只精通某方面。而天朝就是样样行,样样耸

两年过去了,到现在为止我还没看到一个国内公司做到他那种水平。而且更意外的是鬼子是用swing做了一个复杂的设计程序。我们这边人恐怕一听说swing做应用就会说傻子才会。但是鬼子就能用这玩意做一个相对有水平的东西出来。

Monkey.我看你是在对日外包干傻了吧.这么钦佩鬼子.难道国人就不行吗?还是不是出了那么多的技术牛人哦.

我早就没在哪里干了。不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平。一个最简单的打开文件可以提示四五种错误信息出来。加上这几年的经历我可以确定的说中国软件水平离日本差的很远,这一点不是你谩骂就可以改变的,那一家公司是目前我做的最小的公司,但是对于产品的态度也是最高的,代码注释要求就是所有的方法都要有注释,一个都不能少,否则都是纳入bug范围的。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”
你说的这句话口气真大啊,试问你在国内哪几个公司干过?或是你都用过哪几个国产收费软件?你崇拜鬼子可以,但是你这样诋毁国人就是一SB

爱国愤青伤不起啊。
IT好男人
IT好男人

引用来自“Monkey”的评论

引用来自“被风遗忘”的评论

引用来自“Monkey”的评论

引用来自“桔子”的评论

引用来自“Monkey”的评论

我只说一个BUg,我刚开始那会和鬼子干事,鬼子的测试人员测出一个bug,是undo和redo的bug,操作20步,然后往回undo到头,redo到头,发现状态没有回到最初那个时候。这bug用文字都没办法描述,因为详细的操作步骤是在太多,最后直接录制视频发过来。而且这群人并非是软件测试人员都是软件销售人员,后来转到国内公司了对比一下我们的测试,顿时感觉差距不是一般大,基本上我这个开发换一个公司就能挑出不少bug,每到一家公司总有测试问我,你是怎么测试的啊,怎么发现了那些他们好几年都没有测试出来的bug啊。

en 鬼子做软件的都是非常敬业,而且分工非常明确,每个人只精通某方面。而天朝就是样样行,样样耸

两年过去了,到现在为止我还没看到一个国内公司做到他那种水平。而且更意外的是鬼子是用swing做了一个复杂的设计程序。我们这边人恐怕一听说swing做应用就会说傻子才会。但是鬼子就能用这玩意做一个相对有水平的东西出来。

Monkey.我看你是在对日外包干傻了吧.这么钦佩鬼子.难道国人就不行吗?还是不是出了那么多的技术牛人哦.

我早就没在哪里干了。不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平。一个最简单的打开文件可以提示四五种错误信息出来。加上这几年的经历我可以确定的说中国软件水平离日本差的很远,这一点不是你谩骂就可以改变的,那一家公司是目前我做的最小的公司,但是对于产品的态度也是最高的,代码注释要求就是所有的方法都要有注释,一个都不能少,否则都是纳入bug范围的。

“不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平”
你说的这句话口气真大啊,试问你在国内哪几个公司干过?或是你都用过哪几个国产收费软件?你崇拜鬼子可以,但是你这样诋毁国人就是一SB
被风遗忘
被风遗忘

引用来自“川泽人”的评论

引用来自“Monkey”的评论

引用来自“川泽人”的评论

引用来自“Monkey”的评论

引用来自“川泽人”的评论

引用来自“Monkey”的评论

引用来自“川泽人”的评论

引用来自“Monkey”的评论

引用来自“被风遗忘”的评论

引用来自“Monkey”的评论

引用来自“桔子”的评论

引用来自“Monkey”的评论

我只说一个BUg,我刚开始那会和鬼子干事,鬼子的测试人员测出一个bug,是undo和redo的bug,操作20步,然后往回undo到头,redo到头,发现状态没有回到最初那个时候。这bug用文字都没办法描述,因为详细的操作步骤是在太多,最后直接录制视频发过来。而且这群人并非是软件测试人员都是软件销售人员,后来转到国内公司了对比一下我们的测试,顿时感觉差距不是一般大,基本上我这个开发换一个公司就能挑出不少bug,每到一家公司总有测试问我,你是怎么测试的啊,怎么发现了那些他们好几年都没有测试出来的bug啊。

en 鬼子做软件的都是非常敬业,而且分工非常明确,每个人只精通某方面。而天朝就是样样行,样样耸

两年过去了,到现在为止我还没看到一个国内公司做到他那种水平。而且更意外的是鬼子是用swing做了一个复杂的设计程序。我们这边人恐怕一听说swing做应用就会说傻子才会。但是鬼子就能用这玩意做一个相对有水平的东西出来。

Monkey.我看你是在对日外包干傻了吧.这么钦佩鬼子.难道国人就不行吗?还是不是出了那么多的技术牛人哦.

我早就没在哪里干了。不过我可以实实在在的说,这些年来我还没有见到任何一个国产软件商到达这种水平。一个最简单的打开文件可以提示四五种错误信息出来。加上这几年的经历我可以确定的说中国软件水平离日本差的很远,这一点不是你谩骂就可以改变的,那一家公司是目前我做的最小的公司,但是对于产品的态度也是最高的,代码注释要求就是所有的方法都要有注释,一个都不能少,否则都是纳入bug范围的。

日本人的敬业精神完全是可敬的,很多测试的精细程度的确比较的细,想对来说这也是好事,也肯能不是好事,相对于项目来做测试是很必要的,不是一个内部系统也要搞个几个月的精细测试。

我觉得很多时候中国软件水平低是一个怪圈,因为用户就是那种水平,因为国人真正愿意全心于自己工作的人就少,所以对于自己使用的软件工具自然就不会有那么高的标准。再加上很多甚至就是之求快速完成,所以整个就是陷入赶进度了,没时间精力去想做好,而且做好了用户可能觉得反而没啥用,因为细节考虑太周全就变成太复杂。

中国软件水平也不一定就水平低,再说用户的水平也不能决定软件质量和软件的水平。主要是什么样的项目做什么样的测试,没有必要什么东西都花费大量的时间去跑测试用例,例如对于一个即将淘汰的东西还花费大量的精力去做测试显然是不划算的,从公司的角度上出,应该把资源都放在必要的地方,这些都是人力成本。

我现在有一个感觉,只要一个测试人员嘴里开口就是测试用类,那么可以肯定的是他出来的软件一定有bug,就这么简单。另外如果你觉得你可以用种种理由和借口来说明你的软件可以有bug,那么我可以肯定的是你所有的软件都会有bug。就像夫妻出轨一样,有人就觉得出轨一两次没问题,只要不把女人独自搞大就行。实际上这种男人往往是出轨不断。 当你全心于自己事情的时候你就不会有应付过去的想法,你会努力尽善尽美。据我所知中国软件用户大多是为政府或者是事业单位服务,这里的工作人员对待工作的态度我相信大家自己清楚,另外就是私企,而且也是管理人员,中国这个奇葩的社会里企业的管理人员大多都是精于人际交往根本不在意业务,所以对于使用的软件产品也不会太过于重视。还有法律的确实,csdn这种事情在欧美国家恐怕政府都会出来干预,在这种局面下作为软件公司必须要用心做好产品。我们这个奇葩的环境不可能有好的软件产品。

首先没有软件没有bug,再次软件的发布或是遗留bug都是允许在可控范围之内的,什么东西都有相关标准,我们需要的是按照标准来,追求完美固然是对的,但是无止尽的追求完美不一定就是好事,众所周知,这个世界上就没有真正所谓的完美。作为一个QA人员,就是要保证产品的质量,同时也要关心项目的进度,不符合发布标准的产品肯定是不能通过的,但是遗留的问题是在可控范围内或是已经符合发布标准,当然是可以通过发布的。这个就像食品中的含菌量是多少是符合标准,就可以销售到市场,不能说你生产的食品完全不含细菌,如果非要这样的话,我想你也不要吃东西好了。

标准都是人定的,所以中国就能定出三聚氰胺的牛奶,和细菌超标的汤圆。人家就是水平比咱们低太多,所以就定不出这种标准,人家英国连地沟油炼航空油都不同意,咱们都炼出来吃了,也是标准不同吗。没有那种心态你就只能定出畸形的标准。

大哥息怒,人人都是想追求完美的,这点稍微敬业点的人都是明白的,但是标准这个事情是做事情的准则,我们现在国标一次比一次低,这个不是标准的问题,而是制定标准人的问题。你要做的事情想精益求精,跟德国人一样,那么肯定是要超过标准,而日本人一次一次的做精细测试,也是根据日本标准来的,你不能说按照标准做事情就是不好的心态,标准只是做事情的基准,想怎么去做就要根据你自己来做了。我的想法是如果项目时间有富余,那么可以进行高标准的测试,如果时间比较紧迫,加班来解决问题都比较紧,我们测试结果已经达到了发布标准,如果还要继续进行,势必会影响项目的交付,付出这种代价是否合适,那就要需要全方面的权衡利弊了。另外,软件质量这个事情并不都是测试人员的问题,开发人员也有很大的问题,如果开发人员提交过来的代码都是严格遵照设计编码,通过自测,通过单元测试用例,那么测试效果也会提高很多。同时对待bug的态度肯定都是重视的,不能说发现了都不解决,另外貌似现在的软件好像没有一款软件发布后没有bug的吧?

@红薯 像这种无限制下去会怎么样呢?
阿昭
阿昭
你们可以引用一千个你们的对话,看看红薯的系统会不会出现BUG,还是浏览器先出现BUG
返回顶部
顶部