测试工程师怎样提供一份优秀的缺陷陈诉

分享
开发者 2024-9-3 09:07:18 87 0 来自 中国
        在测试工作中,有个标题是全部阶段的测试工程师都可能遇到的:提交的BUG被开发开发拒绝修复,据理力图轻易产生矛盾。作为测试工程师,我们既不能陵暴开发举行修复,也不能随意放任BUG上线,那么怎么做才气体现职业素养呢?
1、清楚地分析每一个缺陷对用户的危害。
第一,缺陷陈诉要重点分析该缺陷对用户代价的损害。许多软件项目都进度告急、资源有限,项目团队修复一个严峻的缺陷,可能必要思量多个因素。比方:修复该缺陷可能必要2天,而实现一个用户建议的新功能也必要2天,是修复缺陷还是增加功能对用户更有代价?如今,软件即将发布,修复该缺陷会不会引入新的标题?为了修复该缺陷而推迟发布是否值得?这些标题标焦点因素是该缺陷是否显着地低沉了软件对用户的代价,以至于开发职员与测试职员乐意占用开发运动的时间、冒着引入更多缺陷的风险来修复它。假如缺陷陈诉没有写清楚缺陷的影响,有可能会错误地以为这是一个不告急的标题,并将它标记为“不予修复”。
2、提供尽可能多的技能信息,方便程序员调试
第二,缺陷陈诉应该提供尽可能多的信息,以便程序员修复缺陷。缺陷不被修复或没有被实时修复的常见缘故起因是程序员没能重现该缺陷。对于难以重现的标题,测试职员应该网络并陈诉尽可能多的信息,比方有可能重现缺陷的操纵步调、屏幕截图等。软件测试是技能观察,缺陷陈诉作为观察效果,应该包罗技能层面的信息,资助程序员更快地修复标题。以web测试为例,我们不光必要提供操纵步调,还应该提供举行该操纵时欣赏器发送的关键哀求,以及哀求中所包罗的参数,方面程序员重现标题。
3、尽早提交缺陷陈诉。
第三,缺陷越早被陈诉,越有可能被修复。当项目邻近发布时,项目团队会对代码变动接纳谨慎的态度,由于最后时候的代码修改可能会引入一些新的缺陷,而短时间的测试不能发现这些缺陷。因此,缺陷评审集会常常由于风险较高而拒绝修复一些缺陷。如许的环境我遇到过多次,假如能早一些提交该缺陷,哪怕是早一个星期,它就能得到修复。这给我两个启示:一是要第一时间提交发现的缺陷,而不是同一提交(即:一个缺陷一个缺陷陈诉,而非团体提交);二是在订定测试策略时,要以优先发现严峻缺陷为目标(即:优先主流程,暂时忽略细枝末节。而并非根据模块一条条实验测试用例)。偶尔,软件的体现出乎我们的预料,但是并不能确定这肯定是个缺陷。这分析测试职员对软件的筹划和实现尚有不相识的地方,我们应该将此迷惑视为一个学习的时机,通过阅读文档、咨询同事等方法来得到解答。然而,在测试时间告急的环境下,深入观察是不相宜的。假如不能立刻得到解答,应该提交缺陷陈诉,让产物司理或缺陷评审集会来答复。
4、陈诉发现的全部缺陷,即便有些缺陷难以重现。
第四,为了提供完备的信息,我们应当陈诉发现的全部标题。这并不意味着提交重复的信息。在提交缺陷陈诉之前,可以查询一下缺陷管理体系,相识被测功能有哪些生动的缺陷。假如其他测试职员已经提交了这个缺陷,那么测试职员可以跳过陈诉,继续测试。我建议测试职员在查询相似缺陷上不必耗费太多的时间,只要避免显着的重复提交即可,由于重复提交的开销远小于遗漏陈诉的代价。而且,程序员通常可以大概快速地链接根源类似的两份缺陷陈诉,将它们“并案”处置惩罚。
对于程序员来说,时间不充裕的环境下被告之必要修复BUG的心情是烦躁的。当看到GET不到重点的缺陷陈诉时会加重这种感情,甚至会对测试职员的专业性提出质疑。因此作为测试职员,我们不光必要尽可能早的提交缺陷陈诉,还必要将标题尽可能清楚的形貌出来。
您需要登录后才可以回帖 登录 | 立即注册

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-12-23 00:20, Processed in 0.156307 second(s), 32 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表