软件测试管理知识ppt课件.ppt

软件测试管理知识
徐登峰
2011/02/26
目录
,bug怎找很明了


?


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