软件测试管理知识.pptVIP

软件测试管理知识 徐登峰 2011/02/26 目录 一.熟读bug三百条，bug怎找很明了 二.软件测试过程中进行Bug描述 三.软件测试缺陷密度的计算方法 四.需求测试怎么做？ 五.巧破软件测试缺陷管理之痛 六.怎么看待缺陷漏测 一.熟读bug三百条，bug怎找很明了 古人说：熟读唐诗三百首不会作诗也会吟。很多小孩子，从小就要求背诵唐诗宋词，熟练之后自然而然就会把握住诗词歌赋的韵律。 　　在我们测试行业，很多新人在刚踏进这个门槛的时候，最迷茫的就是怎么找bug啊，有些bug提上去，被退回来，被人说不是bug，有些bug，自己认为不是bug，别人却说你怎么不提啊，结果造成遗漏，三来二去，刚进来时候的豪情万丈，被打击成垂头气丧了。 那么，作为测试工程师，如何积累对bug的敏感度，以及把握的准确度呢，这个话题，可能不只是新人，很多在这个行业做了很多年的工程师也觉得这是个老大难，在这里，我提一个建议，熟读bug三百条，bug怎找很明了。 　　今天看了雅虎的QA典型百大missbug总结，才有此感触，的确我们应该形成经验积累的机制，尤其是bug，今年大量新同学加入我们团队，如果他们能在上岗前的培训中都过一遍我们常见典型的bug总结结果，将对他们的质量意识和bug敏感度有很好的提升，如果以后工作中再培训的话，效果就差很多了，和我们bug的发现时机是一个道理，越早发现bug，越早解决，我们所付出的代价就越小。 　与其临渊羡鱼，不如退而结网，相关负责人应该落实这种机制，积累一些我们这几年的典型bug，用文档或某种形式形成共享，在新同学们上岗前培训一下，我期望的是每一个新人在正式工作前，至少要熟读百个以上的典型bug，并且最好可以亲自重现或者分析其中的一些。 　　一句话： 　　没吃过猪肉，也应该大概见过猪跑; 　　没提过bug，也应该大概知道bug怎么找。 二.软件测试过程中进行Bug描述 1、术语解释 　　测试程序：提供给测试组测试的程序； 　　测试计划：对测试程序（构件、应用程序、系统等）及其目标进行简要说明； 　　测试bug：不符合测试需求的错误，也就是缺陷； 　　错误跟踪系统：是某个程序或应用系统，使得项目组可以报告、管理以及分析错误报告和错误趋势，如RationalClearQuest就是一个错误跟踪系统 2、为什么要提交bug 　　在得到一个详尽的测试程序后，剩下的工作就是执行测试计划了。但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也就是bug。因此需要一个方法来跟踪、分析和展示那些测试活动，避免偏离最小。这种方法称之为错误跟踪系统。它主要是有效的管理缺陷，实现以下作用： 　　1)减少由于缺陷报告不明确而被开发组驳回的情况； 　　2)加快缺陷的处理速度； 　　3)提高测试的可信度； 　　4)加强测试组与开发组在整个项目过程中的团队合作 　　3、如何才能提交好的测试bug 在有些组织里，程序员几乎会把一半的测试bug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间；会影响程序员和测试人员之间的团队凝聚力；最糟糕的是失去改进产品质量的机会。 　　有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。有时候，当真正的问题在于糟糕的测试过程、测试数据或不正确的测试用例时，测试人员可能错误解释测试测试结果和报告错误。 为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下八个步骤： 　　1) 结构：无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的测试； 　　2)再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率；例如，每3次出现一次，每3次出现2次等； 　　3) 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。 　　4)总结：简要描述客户或用户的质量体验和观察到的一些特征 　5)压缩：精简任何不必要的信息，特别是冗余的测试步骤。 　　6)去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。 　　7)中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。 　　8)评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在你提交测试报告或测试评估报告之前先自己读一遍。 　　好的测试bug描述是