软件缺陷定义和跟踪流程

1、Bug状态说明状态说明权限版本发布时状态New表示测试人员新提交了一个bug【何种情况下到此状态】新建；测试人员无Open表示开发人员看到这个问题了,并着手修复中【何种情况下到此状态】New后开始修改；fixed后审核不通过；开发人员无Fixed表示开发人员认为修改好了这个问题【何种情况下到此状态】修改完成；审核不通过，审核人改为“Open”开发人员无Fixed_已审核表示开发人员交叉审核了代码，审核通过(个别产品线另加了一个Fixed_1，自行处理，不特别要求)【何种情况下到此状态】审核通过；开发人员无Rejected1.表示开发和测试都认为这不是个问题,不需做任何改动；2.或者开发和测试都认定这个bug和其它处于跟踪流程中的bug现象和原因完全相同3.注意事项和不能重现的问题不能被reject，注意事项也要提交bug，凡是产品问题和注意事项都要在24小时内录入缺陷库【何种情况下到此状态】任何状态下，认为不是问题；任何状态下，认为和其它bug相同开发人员有(注意事项)Duplicate表示开发和测试都认定，此bug和其它bug为不同现象、原因完全相同。（其中有一个bug要正常跟踪直至Closed，Duplicate状态的bug回归后改为Closed_Dup）【何种情况下到此状态】Fix或Open，认定为同于其它一个尚在fix或Open的bug开发人员Halt_1表示测试版本经理、测试产品经理认为是问题,但本版本不改,可以挂起以便审核。【何种情况下到此状态】任何状态下，认为暂不解决后特定人员改为此状态测试版本经理产品测试经理无Halt_2产品线主管操作,表示确认挂起,并为挂起负责!【何种情况下到此状态】Halt_1审核认为要挂起,放在后面版本去解决。产品线主管在转集成、转系统、发布前，要确认备注halt的bug，并将认为可以挂起的bug由halt_1转为halt_2，但RDM有权在评审时候否决产品线主管有(遗留问题)Reopen表示开发认为改好了,但测试发现没有改好。【何种情况下到此状态】回归测试不通过，或Closed状态的bug发现并没改好测试人员无重现中表示测试人员正在重现此bug.【何种情况下到此状态】任何状态下，认为需重现。最后不能重现的bug最终要halt起来吧，这部分BUG不扣版本时间。测试人员无Won'tFixWontFix意味着永久挂起，只能由Halt-2转换而来，需主管认可备注和操作，并为结果负责产品线主管有Closed_DupDuplicate的bug，最后也要关闭，关闭的时候就选这个，避免duplicate的bug在回归后没标记，分不清楚测试人员有(回归通过备注，并标注了和哪个已Close祇的bug重复)Closed表示测试认为修改好了这个问题【何种情况下到此状态】Fixed_已审核，回归认为问题解决(Low级别bug可从Fixed后回归关闭)测试人员(开发只回归代码级测试的自提bug)有产品线特别定制的状态说明SSL定制的状态Fixed_1,表示已解决可审核了，审核后改为Fixed_已审核，最后Fixed，表示可以回归；VT定制的状态Fixed_可回归,表示已经合入包可以回归。1）目前TD的bug有11个状态，见如下表格说明：2）测试过程中，rejected和halt的问题按照“halt/Rejectbug处理流程”去确认跟踪。3）测试过程中，避免出现reopen的bug，测试人员也尽可能少提交无效bug。4）不论任何bug，在提交下一个包前，除了已经评审的，状态不能出现new和open，如果出现，说明对应的开发人员没有去看这些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，永不解决的为Wontfix。7）Bug的处理时间、状态以TD为唯一标准；如有修改文件的记录而未录TD，则以文件修改时间为准，并对不提交bug的人酌情进行50元以上的罚款，测试中心另行追加处理，以下面的规定“3”为准。2、Bug等级说明3、提交bug说明前期发现的Bug，如各类评审、代码审查、安全体验、渗透测试、各类测试、验收测试发现的bug，开发人员和测试人员都要录入Bug库。功能、性能类问题，一个问题一个bug记录；Low级别非功能性体验问题，10个问题可提交在一个TD记录中，这10个问题，1条只能叙述1个问题，那怕是很小的问题，不能包含多个页面的问题等。[注]：同一个页面的体验性问题、相同原因的同类体验性问题，可提交在一个bug里，其它情况都得独立提交不能提交bug到已发布的版本里；提交bug后提交人要持续关注自己的bug，不能在版本发布后存在Bug没被处理的情况。如发现此类情况对发现人、指派解决人在Test、RDM范围内通报批评4、Bug描述说明正确填写各字段的信息，“概要”部分要达到使人一看就基本明白是怎样一个bug。“描述”部分由如下组成：【测试环境】说明测试的软硬件和网络环境【测试步骤】按照1、2…的方式列出重现该bug的步骤。好的情形是，描述清晰，别人按照此步骤也能把该bug重现出来。非必现的bug要列出足够多的步骤信息。不容易说清楚的，在附件中可加入截图信息。【期望结果】应该的预期结果，即正确的结果【实际结果】实际操作结果，即bug的现象【备注】其它需要说明的附加信息（如Log），或bug初步定位情况等，以方便开发人员及时修改bug【此部分的处罚措施】研发管理委员会将不定期针对某个产品线，进行bug的抽查，一经发现未按照上述规定或有明显错误的，一个bug罚款5元。5、修改Bug制度说明1）注释：开发人员对Bug的修复需做出注释。修复bug时，在代码中加入修改注释、版本号、BugID和修改人姓名(也可以在svn的注释上注明)。这样其他人在后续检视和查看该部分代码时，可以获取相关信息。2）研发备注：开发人员在fix该bug后填写，测试人员在回归完后填写，内容如下【问题原因(开发填)】【如何修改(开发填)】【可能影响的模块(开发填)】【测试建议(开发填)】【回归的关联测试(测试填)】3）修改bug的审核：所有Low以外的Bug修复，都至少让另外一个人来检查、审核所修改的代码。驱动等关键性代码的所有bug都要审。审核人检视完后，在Bug报告中标识审核信息和自己的名字。Low级的Bug由自己审核和测试。4）审核抽查：所有Fixed且审核过的Bug，部门主管、开发经理和研发管理委员会随时抽查，并进行结果通报。5）修改代码量大的bug：修改一个bug，如果改动代码超过100行或存在大的设计变动，需要向开发经理或者RDM技术委员长申请，包含必要性、必须性说明，审批通过后方可执行。违反规定，一个Bug罚款责任人200RMB，开发经理100RMB。6）属公共平台的bug：各部门开发人员在定位bug时，若确认该Bug属于公共平台，则由开发责任人将此Bug输入到“公共平台bug”库里，然后邮件通知公共平台主管和Bug提交人，并将本部门库里中的该Bug记录置于“Fixed”。

待公共平台将问题解决后，由测试中心bug提交人，将本产品线和“公共平台bug”库里的两个Bug记录一起回归验证；回归验证由bug提交人主导，公共平台测试组在确定必要时给予配合。7)开发人员前期(转集成前)发现的bug：寻求SQA提供帮助，(模板点这里)导入TD的时候Fixed状态，由开发当事人填写剩余字段后直接关闭，审核与否自己决定【附：Bug反复不能解决的处罚标准】bugReopen达2次罚50，钱给产品线使用，BUG审核人只点名不罚款，reopen1次产品线内部自己出措施。如4次以上回归未通过，则加大罚款额度。（此处提及的Bug都应为必现的，且“未回归通过”是指Bug本身描述的缺陷没有被解决，因修改而引起的其它缺陷不计入该数据。）6、案例质量分析标记案例无覆盖:1）、前置条件，执行步骤，后置条件，预期结果无覆盖都算案例无覆盖；2）、功能实现或需求中途有变更的，优化案例后在本轮次发现的bug不算案例无覆盖；（比如：测试阶段加了硬件平台支持，实现原理变更，界面限制变更等）；3）、功能实现或需求在轮次中变更后，未及时同步更新案例，导致下一轮漏测的算案例无覆盖；4）、案例中带附件补充说明的无覆盖都算案例无覆盖；5）、由于第三方测试资源在测试阶段变更，导致用例需要优化的，比如：软件版本更新，不算案例无覆盖；案例有覆盖:1）、建议性、LOW级别bug统一标记为案例有覆盖；2）、案例有覆盖必须符合案例规范标准，存在二义性不算；补充说明:1）、集成测试阶段用例无覆盖纳入绩效考核统计；2）、定制版本不纳入考核版本，其余大小版本都算；3）、所有级别的bug都纳入统计范围；4）、全面测试后的所有bug都为案例无覆盖，测试策略覆盖除外，需在TD备注中说明为什么是案例已覆盖；7、bug执行分析标记正常（凡是标记为正常的必须有备注说明为何是正常）：1）、上一轮测试策略确定不用测试该模块或部分用例级别；2）、上一轮安排执行的用例覆盖不到该问题，如：上一轮只要求覆盖一种硬件平台；3）、上一轮功能实现或需求有变更未测试的模块；4）、个别测试项上一轮没有测试条件满足的，如：上一轮本来要获取的测试资源结果没有协调到位；改动引发：本包测试有问题，但前一次测时没问题；合入引发：前一次测到时没问题，合入后有问题；漏测：不属于以上情况的都属于漏测，包括历史版本遗留问题；经过全面测试后bug默认为漏测；8、执行漏测标准1）、根据测试用例执行没有达到测试目的导致的问题，属执行漏测，如是案例设计问题，案例设计人负联带责任；2）、问题能够根据测试用例执行发现，包括系统例行检查点，属执行漏测；3）、由于第三方测试资源有变更，必须进行用例优化的，不属执行漏测；9、TD上的版本字段规定，以及开发发现的bug标记注：1.开发人员发现的bug，该哪个阶段发现的就填那个阶段。并用“发现人角色”“发现方式”两个字段来标记，“发现人角色”写开发人员，“发现方式”填代码审查、代码走读等等2.版本字段的基本框架：当前未发布的正式版本，R版本显示在最前面，其他版本都归纳到相应的文件夹下。也可由产品线在此基础上经测试中心主管同意后定制。举例如AD产品线10、Bug回归说明1)、bug回归标准：Closed和Closed_Dupbug回归备注必须覆盖开发的测试建议，提交bug的测试步骤，TD备注中需回归的点，讨论出的发散测试点，并备注说明升级包名称、验证的具体的测试点和验证结果，此类原因导致的漏测都视为执行漏测。2)、bug回归备注部分由如下组成：【是否关联和优化案例】【回归升级包名称或时间(开发只回归代码级测试的自提bug)】【回归和关联测试点测试结果】11、处罚措施1）检查和抽查发现bug描述、备注、字段填写有问题，或者填写有误