操作系统测试缺陷处理流程和缺陷接受方案研究

操作系统测试缺陷处理流程和缺陷接受方案研究

ID:34029069

大小:55.91 KB

页数:5页

时间:2019-03-03

操作系统测试缺陷处理流程和缺陷接受方案研究_第1页
操作系统测试缺陷处理流程和缺陷接受方案研究_第2页
操作系统测试缺陷处理流程和缺陷接受方案研究_第3页
操作系统测试缺陷处理流程和缺陷接受方案研究_第4页
操作系统测试缺陷处理流程和缺陷接受方案研究_第5页
资源描述:

《操作系统测试缺陷处理流程和缺陷接受方案研究》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、操作系统测试缺陷处理流程和缺陷接受方案研究摘要:本文论述了操作系统测试项目中,缺陷的生命周期和处理流程。对不同操作系统研发项目的背景进行分析,研讨在不同情况下接受缺陷所应采取的方案,并提出具体建议。关键词:操作系统测试;缺陷处理流程;缺陷接受方案一、序论:缺陷的生命周期操作系统测试是操作系统开发项目中的重要组成部分,是通过人工或自动的方法,来确认一个操作系统的质量或性能是否符合开发之前所提出的要求。在操作系统开发项目中,测试属于项目质量管理的角色。而无论在操作系统测试还是其他普通软件测试项目中,缺陷(bug)管理都是测试项目的重中之重。本文将简要介绍操作系统测试项目中的bug生命周期、bu

2、g处理的一般流程、bug等级划分,以及在不同情况(是否需要兼容多家厂商的硬件平台及板卡)下,bug的接受方案的选择及处理的建议。首先,我们需要简要介绍一下bug的生命周期。bug的产生到消失,存在一个生命周期。每个操作系统厂商或者测试项目小组对bug的生命周期划分不尽相同。但在业界一般会把bug的生命周期大致分为以下几个状态:1.提交当测试工程师发现新bug,并提交到bug管理系统中时,该bug的状态标记为newo提交时应注明其详细信息,并根据规定对此bug标记严重程度。此时,该bug的生命周期正式开始。2.接受项目经理接收到这个bug后,首先要判断这个问题是否是bugo如果是bug,则接

3、受该bug,此时,其状态应由项目经理标记为open。在这个阶段,项目经理应协调开发人员,分配软硬件及时间资源,并由开发人员来修复这个bugo直到开发工程师完成修复(fixed)或拒绝修复(rejected)为止。3.拒绝处理(Rejected)开发人员认为该问题不是Bug、现象描述不清、与现有bug重复、不能复现,或可忽略不计,从而拒绝处理该问题。则将这个bug标记为rejected,并通知测试工程师,之后由项目经理关闭(closed)o4.修复(Fixed)开发工程师在修复完该bug后,该bug即进入fixed状态(由开发工程师标记,后转入retest阶段。5.重新测试(Retest)在

4、开发工程师修复该问题后,测试工程师需要重新测试。确认是否完成修复,并检查是否有新问题出现。测试成功,则转入新版本测试阶段(newbuildretest);否则,转入重新开启(reopen)阶段。1.新版本测试(Newbuildretest)该操作系统产品在新的内部版本发布时,重新测试该bugo检查问题是否重现。该状态应由测试工程师标记。若未重现,则转入关闭(closed)状态;否则转入(reopen)状态。2.重新开启(Reopen)测试工程师对修复后的问题进行验证,若不通过,或者又因此重新出现新的错误,则bug的状态应该由测试工程师标记为reopeno并交由开发工程师重新修复。3.关闭(

5、Closed)所有测试流程通过,则应由项目经理将bug状态标记为closed,并对此操作负责。根据项目及bug的实际情况不同,测试项目经理对本公司的产品的bug生命周期划分可能略有不同。在上面介绍的生命周期中,newbu订dretest状态就有很多公司没有采用。但笔者仍认为该步骤是必要的。因为在新的内部版本发布后,重新检测已知bug会对产品的稳定性提供相应保障。二、缺陷处理流程分析根据bug生命周期,我们可以采用以下流程来提交、接收、处理、关闭bug:(1)测试工程师发现新bug,并提交到相应的bug管理系统中。(2)项目经理确认。并指派相应的研发工程师进行修复。(3)研发工程师判断是否需

6、要修复该bug。若需修复,则修复后将修复结果转交给测试工程师重新测试;若拒绝修复,则说明理由,并请项目经理关闭该bug。(4)测试工程师核实该修复结果。若通过核实,则在操作系统的新版本发布后,再次测试;若不通过,则将该bug回退给开发工程师重新修复。(5)在操作系统的新版本中测试该bug后,若测试成功,则关闭该bugo若失败,仍然回退给开发工程师重新修复。在上述的流程中,我们可以看到,被bug接受(open)后,项目经理会指定相应的工程师来完成修复。这是在操作系统只运行在本公司所生产的硬件平台上的情况下,通常所采取的bug处理流程。此时,项目的复杂程度较低,各方面资源的协调相对容易。项目经

7、理可以独自分析并定位该问题出现的原因,同时协调相应的部门及工程师来对bug进行修复。即使bug现象模糊,不能准确判断,也能比较方便地通过协调各研发部门的资源来共同定位。而如果该操作系统需要与其他厂商的硬件平台兼容,则需要判断该bug究竟是操作系统本身的问题,还是与合作厂商的硬件平台的兼容性问题,或者只是硬件平台本身的问题。此时,测试项目组作为第三方质量管理角色,对bug的处理流程就需要相对复杂一些。可以通过增加部分流程,

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。