软件缺陷定义和跟踪流程

《软件缺陷定义和跟踪流程》由会员分享，可在线阅读，更多相关《软件缺陷定义和跟踪流程（7页珍藏版）》请在金锄头文库上搜索。

1、1、 Bug状态说明状态说明权限版本发布时状态New表示测试人员新提交了一个bug【何种情况下到此状态】新建；测试人员无Open表示开发人员看到这个问题了,并着手修复中【何种情况下到此状态】New后开始修改；fixed后审核不通过；开发人员无Fixed表示开发人员认为修改好了这个问题【何种情况下到此状态】修改完成；审核不通过，审核人改为“Open”开发人员无Fixed_已审核表示开发人员交叉审核了代码，审核通过(个别产品线另加了一个Fixed_1，自行处理，不特别要求)【何种情况下到此状态】审核通过；开发人员无Rejected1.表示开发和测试都认为这不是个问题,不需做任何改动； 2.或者开发

2、和测试都认定这个bug和其它处于跟踪流程中的bug现象和原因完全相同3.注意事项和不能重现的问题不能被reject，注意事项也要提交bug，凡是产品问题和注意事项都要在24小时内录入缺陷库【何种情况下到此状态】任何状态下，认为不是问题；任何状态下，认为和其它bug相同开发人员有(注意事项)Duplicate表示开发和测试都认定，此bug和其它bug为不同现象、原因完全相同。（其中有一个bug要正常跟踪直至Closed，Duplicate状态的bug回归后改为Closed_Dup）【何种情况下到此状态】Fix或Open，认定为同于其它一个尚在fix或Open的bug开发人员Halt_1表示测试版

3、本经理、测试产品经理认为是问题,但本版本不改,可以挂起以便审核。【何种情况下到此状态】任何状态下，认为暂不解决后特定人员改为此状态测试版本经理产品测试经理无Halt_2产品线主管操作,表示确认挂起,并为挂起负责!【何种情况下到此状态】Halt_1审核认为要挂起,放在后面版本去解决。产品线主管在转集成、转系统、发布前，要确认备注halt的bug，并将认为可以挂起的bug由halt_1转为halt_2，但RDM有权在评审时候否决产品线主管有(遗留问题)Reopen表示开发认为改好了,但测试发现没有改好。【何种情况下到此状态】回归测试不通过，或Closed状态的bug发现并没改好测试人员无重现中表示

4、测试人员正在重现此bug.【何种情况下到此状态】任何状态下，认为需重现。最后不能重现的bug最终要halt起来吧，这部分BUG不扣版本时间。测试人员无Wont FixWontFix意味着永久挂起，只能由Halt-2转换而来，需主管认可备注和操作，并为结果负责产品线主管有Closed_DupDuplicate的bug，最后也要关闭，关闭的时候就选这个，避免duplicate的bug在回归后没标记，分不清楚测试人员有(回归通过备注，并标注了和哪个已Close祇的bug重复)Closed 表示测试认为修改好了这个问题【何种情况下到此状态】Fixed_已审核，回归认为问题解决(Low级别bug可从Fi

5、xed后回归关闭)测试人员(开发只回归代码级测试的自提bug)有产品线特别定制的状态说明SSL定制的状态Fixed_1,表示已解决可审核了，审核后改为Fixed_已审核，最后Fixed，表示可以回归；VT定制的状态Fixed_可回归,表示已经合入包可以回归。1）目前TD的bug有11个状态，见如下表格说明：2）测试过程中， rejected和halt的问题按照“halt/Reject bug处理流程”去确认跟踪。3）测试过程中，避免出现reopen的bug，测试人员也尽可能少提交无效bug。4）不论任何bug，在提交下一个包前，除了已经评审的，状态不能出现new和open，如果出现，说明对应的

6、开发人员没有去看这些bug或则看了没改好。也不能出现fixed的状态，如果出现，说明对应测试人员没有去看这些bug。5）为了规范上面的过程，研发人员只有fixed、open 、rejected、halt-1、halt-2、duplicate、Fixed_已审核的权限，测试人员只有reopen、closed、new、closed_dup的权限。 如有冲突，以bug跟踪系统中的设置为准6）到版本发布时候，所有bug只允许存在5种状态。遗留问题为halt-2状态的所有问题, rejected的所有问题，所有解决的问题为closed，同于其它Bug的所有已解决重复性问题为Closed_Dup，永不解决

7、的为Wontfix。7）Bug的处理时间、状态以TD为唯一标准；如有修改文件的记录而未录TD，则以文件修改时间为准，并对不提交bug的人酌情进行50元以上的罚款，测试中心另行追加处理，以下面的规定“3”为准。 2、 Bug等级说明 3、 提交bug说明前期发现的Bug，如各类评审、代码审查、安全体验、渗透测试、各类测试、验收测试发现的bug，开发人员和测试人员都要录入Bug库。功能、性能类问题，一个问题一个bug记录；Low级别非功能性体验问题，10个问题可提交在一个TD记录中，这10个问题，1条只能叙述1个问题，那怕是很小的问题，不能包含多个页面的问题等。注：同一个页面的体验性问题、相同原因

8、的同类体验性问题，可提交在一个bug里，其它情况都得独立提交不能提交bug到已发布的版本里；提交bug后提交人要持续关注自己的bug，不能在版本发布后存在Bug没被处理的情况。 如发现此类情况对发现人、指派解决人在Test、RDM范围内通报批评4、Bug描述说明正确填写各字段的信息，“概要”部分要达到使人一看就基本明白是怎样一个bug。“描述”部分由如下组成：【测试环境】说明测试的软硬件和网络环境【测试步骤】按照1、2的方式列出重现该bug的步骤。好的情形是，描述清晰，别人按照此步骤也能把该bug重现出来。非必现的bug要列出足够多的步骤信息。不容易说清楚的，在附件中可加入截图信息。【期望结果

9、】应该的预期结果，即正确的结果【实际结果】实际操作结果，即bug的现象【备注】其它需要说明的附加信息（如Log），或bug初步定位情况等，以方便开发人员及时修改bug 【此部分的处罚措施】 研发管理委员会将不定期针对某个产品线，进行bug的抽查，一经发现未按照上述规定或有明显错误的，一个bug罚款5元。 5、 修改Bug制度说明1） 注释：开发人员对Bug的修复需做出注释。修复bug时，在代码中加入修改注释、版本号、Bug ID和修改人姓名(也可以在svn的注释上注明)。这样其他人在后续检视和查看该部分代码时，可以获取相关信息。2） 研发备注：开发人员在fix该bug后填写，测试人员在回归完后

10、填写，内容如下 【问题原因(开发填)】 【如何修改(开发填)】 【可能影响的模块(开发填)】 【测试建议(开发填)】 【回归的关联测试(测试填)】3） 修改bug的审核：所有Low以外的Bug修复，都至少让另外一个人来检查、审核所修改的代码。驱动等关键性代码的所有bug都要审。审核人检视完后，在Bug报告中标识审核信息和自己的名字。Low级的Bug由自己审核和测试。4） 审核抽查：所有Fixed且审核过的Bug，部门主管、开发经理和研发管理委员会随时抽查，并进行结果通报。5） 修改代码量大的bug：修改一个bug，如果改动代码超过100行或存在大的设计变动，需要向开发经理或者RDM技术委员长申

11、请，包含必要性、必须性说明，审批通过后方可执行。 违反规定，一个Bug罚款责任人 200 RMB，开发经理100RMB。6） 属公共平台的bug： 各部门开发人员在定位bug时，若确认该Bug属于公共平台，则由开发责任人将此Bug输入到“公共平台bug”库里，然后邮件通知公共平台主管和Bug提交人，并将本部门库里中的该Bug记录置于“Fixed”。 待公共平台将问题解决后，由测试中心bug提交人，将本产品线和“公共平台bug”库里的两个Bug记录一起回归验证； 回归验证由bug提交人主导，公共平台测试组在确定必要时给予配合。 7) 开发人员前期(转集成前)发现的bug：寻求SQA提供帮助，(模

12、板点这里)导入TD的时候Fixed状态，由开发当事人填写剩余字段后直接关闭，审核与否自己决定【附：Bug反复不能解决的处罚标准】bug Reopen达2次罚50，钱给产品线使用，BUG审核人只点名不罚款，reopen 1次产品线内部自己出措施。如4次以上回归未通过，则加大罚款额度。 （此处提及的Bug都应为必现的，且“未回归通过”是指Bug本身描述的缺陷没有被解决，因修改而引起的其它缺陷不计入该数据。）6、案例质量分析标记案例无覆盖:1）、前置条件，执行步骤，后置条件，预期结果无覆盖都算案例无覆盖；2）、功能实现或需求中途有变更的，优化案例后在本轮次发现的bug不算案例无覆盖；（比如：测试阶段

13、加了硬件平台支持，实现原理变更，界面限制变更等）；3）、功能实现或需求在轮次中变更后，未及时同步更新案例，导致下一轮漏测的算案例无覆盖；4）、案例中带附件补充说明的无覆盖都算案例无覆盖；5）、由于第三方测试资源在测试阶段变更，导致用例需要优化的，比如：软件版本更新，不算案例无覆盖；案例有覆盖:1）、建议性、LOW级别bug统一标记为案例有覆盖；2）、案例有覆盖必须符合案例规范标准，存在二义性不算；补充说明:1）、集成测试阶段用例无覆盖纳入绩效考核统计；2）、定制版本不纳入考核版本，其余大小版本都算；3）、所有级别的bug都纳入统计范围；4）、全面测试后的所有bug都为案例无覆盖，测试策略覆盖除

14、外，需在TD备注中说明为什么是案例已覆盖； 7、bug执行分析标记正常（凡是标记为正常的必须有备注说明为何是正常）：1）、上一轮测试策略确定不用测试该模块或部分用例级别；2）、上一轮安排执行的用例覆盖不到该问题，如：上一轮只要求覆盖一种硬件平台；3）、上一轮功能实现或需求有变更未测试的模块；4）、个别测试项上一轮没有测试条件满足的，如：上一轮本来要获取的测试资源结果没有协调到位；改动引发：本包测试有问题，但前一次测时没问题；合入引发：前一次测到时没问题，合入后有问题；漏测：不属于以上情况的都属于漏测，包括历史版本遗留问题；经过全面测试后bug默认为漏测； 8、执行漏测标准1）、根据测试用例执行

15、没有达到测试目的导致的问题，属执行漏测，如是案例设计问题，案例设计人负联带责任；2）、问题能够根据测试用例执行发现，包括系统例行检查点，属执行漏测；3）、由于第三方测试资源有变更，必须进行用例优化的，不属执行漏测； 9、TD上的版本字段规定，以及开发发现的bug标记 注：1. 开发人员发现的bug，该哪个阶段发现的就填那个阶段。 并用“发现人角色”“发现方式”两个字段来标记，“发现人角色”写开发人员，“发现方式”填代码审查、代码走读等等2. 版本字段的基本框架：当前未发布的正式版本，R版本显示在最前面，其他版本都归纳到相应的文件夹下。也可由产品线在此基础上经测试中心主管同意后定制。 举例如AD产品线 10、Bug回归说明1)、bug回归标准：Closed和Closed_Dup bug回归备注必须覆盖开发的测试建议，提交bu