问题单管理规定

 

产 品 名 称

 

文 档 版 本

1.00 

                                                                                                                                 

xxxxx问题单管理规定

拟  制:

xxxxxx

日  期:

2014-2-9

审  核:

 

日  期:

 

签  发:

 

日  期:

 

XX技术有限公司

版权所有 侵权必究

修订记录

日期Date

修订版本Version

描述Description

作者Prepared by

2014-02-9

1.0

初稿

 

 

 

 

 

 

      

 

拟定声明

本标准拟制与解释部门：

本标准的相关系列标准或文件：本规范

文档目录

1      目的...4

2      问题单提单规范...4

2.1       提单基本原则...4

2.2       问题单填写规范...5

2.2.1        相关信息及ODC字段填写...5

2.2.2        问题的原始记录来源说明填写...6

2.2.3        简要描述填写...7

2.2.4        详细描述填写...8

3      问题单处理各环节管理规定...9

3.1       步骤1（问题提交人员填写问题单）...9

3.2       步骤2（测试（项目）经理审核）...9

3.3       步骤3（开发人员定位）...9

3.4       步骤4（项目经理审核定位）...10

3.5       步骤5（开发人员实施修改）...10

3.6       步骤6（审核人员审核修改）...11

3.7       步骤7（测试人员回归测试）...12

4      问题单处理管理规定...13

1     目的

为提高问题单处理质量，争取一次把事情做好，最大限度地发挥问题单的效力，规范问题单提单及各环节处理的操作，避免问题单修改引发新的问题，特制定本规定，指导ATAE版本的问题单缺陷电子流跟踪操作。适用所有提单人员。

2     问题单提单规范

2.1     提单基本原则

1）对于SDV、I&V、SIT阶段，且无论在公司内部还是在ODC场地工作的必须使用“标准流程”；ST阶段问题单管理方法可以采用三步提单法的“简化流程”

2）提单之前请基本定位，并和相关开发人员确认后再行提单。这里的“确认”是指开发人员确认看到测试人员描述的问题现象，而不是认可该现象是问题。原则上如此，意外情况区别对待，如：（1）如果和开发人员无法达成一致意见，也要提单，并在问题单的详细描述中说明：和开发人员xxx沟通，有争议等说明；（2）无人确认的情况下可以先提单，并在问题单的详细描述中说明：开发人员不在，先提单跟踪等说明。

3）针对版本所有不合理问题进行提单，不管问题大小，ST及以后阶段都必须及时走缺陷跟踪系统（DTS），（备注：ST阶段如果开发人员自验证发现的代码问题可以不提单）

4）有条件概率重现、无规律重现、很难重现的问题一样提单，但之前须确认问题存在，并将具体环境和操作步骤、相关配置项描述清楚，然后提单。

5）当天的问题必须当天提，不能拖延到下一个工作日。

6）建议当天发现问题单立即进行确认提单，避免将一天的问题汇总到当天结束时一起提交。

7）对出现问题的现场应及时保护，严重及以上的问题需及时通知相关开发人员来现场定位，测试配合定位，但是占用环境不能超过1小时。

8）对于日志、提示信息、界面文字、语法、英文翻译、SRS文档等问题提单，不必一个点提交一个问题单。可按照同一个需求项、同一个功能项等进行汇总提单，但在问题单中必须明确列出每个问题的确切所在，不能用笼统的词汇描述一类现象。

2.2     问题单填写规范

2.2.1       相关信息及ODC字段填写

1）采用继承已有问题单新增问题单的，一定要注意针对不同点修改相关信息。

2）按照版本提交时的规定，正确填写路标版本和基线版本－子版本选项，特别注意对于回归测试版本，一定要保证版本信息的正确。

3）根据测试组的特性树选择正确的特性，并选择相应的子系统(如果是定制数据问题，请选择Customized Version)。

4）发现问题的活动和问题发现阶段不是一一对应关系，该阶段以及之前阶段流程中的活动都是可能的发现问题的活动。。

5）问题发现阶段的填写：

       项目级系统测试（ST）：一体化测试，转SDV前的测试发现的问题

       系统设计验证(SDV)：一体化测试，转SDV后的测试发现的问题

       构件模块集成与测试（BBIT）：开发BBIT阶段发现的问题

       系统集成测试(SIT)：I&V测试阶段发现的问题

6）结果影响的填写，请选择不同的影响类型，以便区分出是那种类型的问题：

       业务功能

       业务性能

       可靠性

       产品安全性

       可测试性：如要求月结只能等到下个月或者修改系统时间才能测试

组网能力：不支持某种类型的组网，或者某种类型的组网下能力有限制（比如短信直连DCC，不支持对短信漫游权限的控制）

可安装性：没有安装的磁盘、内存空间的规划，安装后不知道怎么检查是否安装成功等。

       可维护性：比如根据日志不能定位问题，日志不符合规范。

       可操作性/易用性：比如升级步骤复杂，界面布局不合理等。

7）若发现问题的活动为“功能测试”，需要注意触发因素的选择；是通过单运行覆盖即能发现该问题还是通过单运行的边界、非法输入才能发现该问题；必须通过多运行执行才能发现的问题，要注意是否与多运行执行的顺序相关。

8）正确填写问题的严重等级，问题级别判定就重不就轻，当问题现象可能符合多个问题级别定义的描述时，应该选择级别最严重的作为最终的问题级别，问题单的严重级别定义简单如下：

    致命：造成系统死机、程序崩溃、死循环、造成系统主要功能无法实现的异常等

包括但不限于:

Ø  版本安装（包括报表、GFEP和实例化等）失败

Ø  基础业务流程（开户激活、充值缴费、Voice、SMS、MMS、GPRS等基础流程）不通

Ø  FRS需求没有实现，而且影响范围很大的

Ø  接口实现错误，导致大范围对接联调Block的

    严重：导致系统主要功能无法实现或者实现错误的问题；

        包括但不限于：

Ø  涉及到钱的问题（计费、提醒、话单中的金额）都是严重及以上的问题

Ø  FRS需求没有实现，但是影响范围比较小

Ø  规划在Backlog列表需要实现，但是版本没有开发，又没有提前知会

Ø  版本实现与规格描述不一致

Ø  配置功能没有提供，阻塞后续业务流程测试

Ø  接口描述不一致，导致小范围功能对接联调失败

    一般：对系统运行和功能实现影响不大的所有问题/对于其他对主要功能来说属于附属功

        能的部分的问题如状态条、进度条、按钮点击等等问题；

        包括但不限于：

Ø  普通的资料问题

Ø  界面显示错误，影响客户使用感受但不影响业务功能使用

Ø  短信提醒内容错误，但不影响业务功能

Ø  归档的参数与局点需求不符合，又没有提供界面配置

    提示：操作不方便、视图不友好、颜色搭配、窗口布局等

        包括但不限于：

Ø  界面或者资料中的单词拼写错误

Ø  前后章节顺序错误，但不影响使用和业务功能的

        如对级别有异议请提出，可提出后讨论解决。

9）问题的紧急程度，一般来讲，严重及以上问题为紧急。

10）对于问题是否重现，必须认真如实填写，不得随意扩大或缩小。对于随机重现问题和不可重现问题界定如下：

很难重现：测试过程中仅出现一次，且在一个月内未重现的问题认定为很难重现问题；

    无规律重现：在测试过程中出现两次的问题认定为无规律重现问题；

    有条件概率重现：在测试过程中出现三次（包括三次）以上的认定为有条件概率重现问题。

11）问题根源深入定位和问题原因分析总结流程上不是必填项，建议提单时根据开发部的子系统、模块树选择正确的子系统、模块，以及责任项目组。不清楚子系统、模块的可不填子系统、模块及责任项目组信息。

2.2.2       问题的原始记录来源说明填写

1）若发现的问题是手工执行且有用例对应的，需要选择“测试手工执行用例发现”，并在初始问题单出处和编号中填写用例名称。

2）若发现的问题是自动化执行且有用例对应的，需要选择“测试自动化执行用例发现”，并在初始问题单出处和编号中填写用例名称。

3）若发现的问题是没有用例对应的，且该问题是测试执行人员测试自己负责特性的问题，需要选择“测试非用例发现（本特性）”，初始问题单出处和编号可不填写，也可填写“无用例”，此类问题单提交时抄送本特性的测试负责人。

4）若发现的问题是没有用例对应的，且该问题是测试执行人员测试出非自己负责特性的问题，需要选择“测试非用例发现（其它特性）”，初始问题单出处和编号可不填写，也可填写“无用例”，此类问题单提交时抄送对应特性的测试负责人及测试执行人员。

5）若是回归版本、补丁版本中新增需求，需要提单跟踪的，需要选择“新需求”，初始问题单出处和编号可不填写。(若新需求要求提单跟踪的建议将对应的单号给出)

6）若是和下游的产品进行集成测试发现的问题、下游产品单独测试时发现的问题，需要选择“解决方案发现的部件产品问题”，初始问题单出处和编号填写下游产品缺陷库中相同问题的问题单号。

7）若是已上网版本，网上发现的问题，无论该问题是否走网上问题处理电子流，都选择“从网上问题处理电子流中转接”。走网上问题处理电子流的，初始问题单出处和编号填写网上问题处理电子流问题单号，否则可不填写。

8）若是未上网版本，但已在现场进行调测的版本，现场反馈的问题需要跟踪的，选择“其他问题来源”。初始问题单出处和编号可不填写。

2.2.3       简要描述填写

1）问题单简要描述分五段，每段之间用中文的【】分隔

格式为：【问题单分类字母】【测试类型】【特性】【国家局点】简要描述。。

样例：【N】【功能】【虚拟化】【UVP】rest接口查询UVP镜像列表失败查询条件生效时间和失效时间计算有误。

针对每段的填写说明如下：

问题单分类字母(必选)

N（NEW BUG）：属于本版本新增需求引入的问题，有事先设计的用例（正常问题单，无需分析）；

O（OLD BUG）：基础版本特性但是前边没有测试出的问题（C版本间漏测，需要分析）；

A（Add）：为上个版本缺陷修改不完整或者修改引入的问题（需要开发人员分析）；

F（File）：属于转测试相关文档的问题；

T（oTher）：不在上属范围内的问题，字段保留，暂不启动

【新需求】：需求跟踪ID：版本规划新需求，需要提单跟踪的；需求跟踪ID为可选，有ID的一定要填写，没有ID的则可以不写。

测试类型（必选）

功能、安装、性能、可靠性、可服务性、安全性、资料、兼容、ATP

特性（必选）

特性填写依据基础版本的测试特性建模结果，到测试特性级别即可，不必细化到大类、小类。发现的日志类问题，需要在特性后加“：Log”。Story发现的问题，需要在特性后加“：StoryID”（StoryID需要实例化）

国家局点（可选）

国家和局点名称（如果是ST和SDV阶段的问题单可以不填写此项，这项增加是考虑到I&V阶段和版本维护阶段，如果是针对某个国家局点的定制化，实例化问题或者现场反馈回来的问题，则此项必填）

简要描述（必选）

简要描述部分要概要描述问题出现的地方以及错误是什么。

 

2.2.4       详细描述填写

详细描述信息要包含环境信息、版本信息、重现步骤、预期结果、测试结果、附件六部分内容：

环境信息

相关的硬件、配套操作系统、软件等信息。功能测试发现的问题，硬件信息到机器型号即可。性能测试发现的问题，必须把硬件的详细配置信息列出。

版本信息

配套版本的版本信息，被测软件的版本信息

重现步骤

有条件必现、概率重现的问题：需要描述出重现问题的详细操作步骤，有对应用例的，可以将用例的步骤信息贴上，但需要注意删简，突出重现步骤的重点。

很难重现、无规律重现的问题：需要描述出现问题前所做的操作步骤。

预期结果

根据规格、需求的显式或隐式要求，被测软件、特性在功能、性能、可服务性、可靠性等方面应该表现出的结果、特征。

测试结果

被测软件、特性实际表现出的结果、特征。与预期结果不同的地方请标红色

相关日志

有相关截图、日志文件、core文件的，以附件方式提供。若截图、日志内容较少，不影响阅读，可以在测试结果中直接贴出。

1）SRS问题提单时忌讳笼统说需求不清晰之类，而是把不清晰的地方具体描述出来；如果很多地方有同样的问题要把所有的都列出来。

标准流程问题单处理各环节管理规定

目录(?)[-]

1. 标准流程问题单处理各环节管理规定
   1. 步骤1问题提交人员填写问题单
   2. 步骤2测试项目经理审核
   3. 步骤3开发人员定位
   4. 步骤4项目经理审核定位
   5. 步骤5开发人员实施修改
   6. 步骤6审核人员审核修改
   7. 步骤7测试人员回归测试
2. 简化流程问题单处理各环节管理规定
   1. 步骤1问题提交人员填写问题单
   2. 步骤2测试项目经理审核
   3. 步骤3测试人员回归测试
3. 问题单处理管理规定

1      标准流程问题单处理各环节管理规定

1.1      步骤1（问题提交人员填写问题单）

1）问题单提交给测试经理时提交人员要确保问题单基本信息的正确性；

2）如果项目组成员众多，可以提单时选择测试经理和TC

1.2      步骤2（测试（项目）经理审核）

1）测试经理要审核问题单基本信息的正确性。如果测试人员在提单的时候填写错误，必须通过纠正或返回问题单的形式确保正确性。

2）对于需要复制到其他项目组的问题单，由测试经理复制给其他项目组。抄送给本组的项目经理。

1.3      步骤3（开发人员定位）

1）该阶段问题定位人可以多重转发，当问题单转给其他开发人员定位时，必须在流程中提供书面的充足的理由并征得被转入人员同意，否则被转入人有权返回；如果转给其他项目组定位，必须抄送双方PL；产品CMO及QA定期随机抽查，对于无故来回倒手的情况进行通报并处罚。

2）问题单定位时，需要和测试人员充分沟通；可以请测试人员复现问题，但不允许把问题单转给测试人员定位。

3）定位完成后，需要正确填写ODC的各个选项，比如：版本、模块、问题类型、问题引入阶段等等，如果测试人员在提单的时候填写错误，开发人员必须在该阶段纠正过来。

4）开发人员经过定位，确认该问题单在其他产品上同样存在的，需要在问题单上明确说明存在该问题的产品和版本。

6）开发人员经过定位，如果问题单不只涉及代码的修改，而同时需要修改文档（比如：FRS/SRS，这里的文档是指研发内部文档，资料组的内容不包括在内），修改项中应该填写CODE/DOC，而修改实施步骤需同时给出代码修改说明和文档的CR单。

7）对于开发人员认为重复的问题单，不能直接返回测试人员关闭，要走版本归档流程经回归测试后关闭。开发人员在新的重复问题单上必须注明旧重复问题单号并且附上相关链接，提交项目经理。

8）此环节的正常滞留时间是2个工作日，除了挂起的问题单，每2个工作日必须给出解决进展报告。

9）对于开发人员认为是非问题的问题单，必须要和提单人沟通达成一致意见，并在定位信息中说明定位原因以及测试人员确认人后才能走返回流程。对于有异议的问题单要走CCB流程不能直接关闭问题单。

1.4      步骤4（项目经理审核定位）

1）项目经理审核问题定位是否正确。

2）TR5之前的问题单，项目经理决定该问题单在哪个版本合入，对于过了TR5之后的问题单，必须由项目经理将问题提交CCB决策是否修改，以及合入哪个版本，CCB决策的纪要要进行归档。

3）对于容易修改的问题单（项目经理自己控制），直接提交CMO授权修改，并指定问题修改人和审核人。

4）对于不容易修改的问题单（项目经理自己控制），项目经理提交CCB讨论解决，在没有CCB结论之前，问题单停留在项目经理处。

5）对于需要复制的问题单，由项目经理复制给其他项目组，本问题单停留在项目经理处，等待复制的问题单修改并提交回归后，该问题单同步走到相应版本的回归测试阶段。

6）对于需要和其他项目组配合修改问题单（包括资料组），项目经理与相关项目组共同协调在哪个版本进行修改，并授权开发人员在相应版本进行修改，开发人员在上库的时候，需要确认同步的问题单是否已经走到CMO授权阶段（不包括资料的修改），如果没有，则该问题单暂不上库。

7）对于在其他产品上同样存在的问题单，项目经理负责复制给相应产品版本的责任人。

1.5      步骤5（开发人员实施修改）

开发人员在修改缺陷后，可以进行PC-LINT检查（C++）或FindBugs检查（Java），必须要进行单元测试和系统测试，并输出缺陷修改测试报告单，将该报告作为附件，填入电子流中，具体格式，参照《缺陷修改测试报告单模板》，如下：

待开发补充缺陷修改测试报告模板

1）问题单修改时，修改代码时能添加注释的地方必须添加注释，不能添加注释的地方（eg：部分js文件不能添加注释）由各项目组统一给出标准，说明修改原因，解决思路等。按

照公司规定，代码注释率在30％左右。

●如果连续两处修改在20行之内，可以用一套注释语句；

●  禁止删除原有代码，对于无效代码应该通过注释掉的方式屏蔽，并在注释中说明原因

●  对于涉及研发内部的文档修改，以修订的方式进行修改，在审核人进行审核阶段进行确认。

注意：任何人不能删除和修改正式版本中的注释语句，无论是自己的还是他人的。

2）修改人从配置库中获取最新版本，在本机中进行修改并完成测试和验证工作。在代码上主干并附上报告后提交审核。

● 问题单提交审核人员审核时一般及以上问题必须提供缺陷修改测试报告单。

● 提示级别问题单可不提供，但在问题单中需要填写下面几项，具体要求如下：

实现说明（意见）：

修改文件清单：详细修改说明一栏必须列出该问题单涉及的每一处修改

测试建议：

1.6      步骤6（审核人员审核修改）

审核一般为项目组内该领域资深员工承担。审核人员审核时必须以clearcase/SVN上的代码为准。

1）审核人员需要检查开发人员提交的报告内容是否齐全，若有PC-LINT报告要检查是否满足要求。否则退回问题单，审核人员必须对问题单修改或者新增的代码进行检视，如果修改存在问题需退回问题单，对于涉及研发内部文档修改的，审核人还需对修改的文档进行审核，确认前面的修订内容。审核人员必须对问题单测试通过的日志进行审核，如果修改存在问题需退回问题单。

2）如果代码修改量较大或者比较复杂，审核人员可以向项目经理申请组织专门的人员进行检视，由参加检视的人员共同对本问题单负责。

 

1.7      步骤7（测试人员回归测试）

1）在进行问题单回归时，测试人员应认真阅读开发人员的给出的定位和修改信息，从而使回归测试全面、彻底。

2）对于回归测试不通过的问题，需要与开发人员沟通之后，以回归测试不通过的方式，打回问题单。严禁对回归测试不通过的问题单，先关闭，再提单。

3）回归不通过的问题单，回归测试人员必须通知到相关问题修改人，尽量达成一致意见，给出不通过的原因描述。如无法达成一致意见，应及时将问题反馈给测试经理或相关测试负责人，由测试负责人与开发负责人讨论确定处理方式。

4）问题单的回归必须与所标识的版本信息一致，如不一致，测试人员有权拒绝回归。假如测试人员是在后续版本回归的，则需要写明回归的版本。

5）现网问题在回归测试时需要提供问题重现的步骤、测试数据、日志等相关信息。现网问题需要补充问题重现场景、开发修改方案和测试建议。不能重现的问题要在问题单中说明测试的方法和结论。

6）在版本测试结束时，所有回归问题单必须处理完成，不得有遗漏。

7）测试人员在回归问题单时，需要把测试的用例、关键的日志附带进去，不能只写“OK”或“问题回归通过”等简单结果。如果问题单回归多次，不能将以前的版本回归记录删除。

8）回归测试报告样式：

A、回归测试通过的情况

回归人：姓名＋工号 回归时间：YYYY-MM-DD  回归版本：RxCxxBxx 回归结论：回归通过

【问题重现场景】（现网问题必填）

【开发修改方案】（现网问题必填）

【问题重现报告】（包含重现环境、重现步骤、重现数据、重现日志等）

【回归测试用例】（补充的测试用例需要给出用例所在特性路径）

【回归测试环境】

【回归测试步骤】

【回归测试结果】

【附件】

B、回归测试不通过的情况

回归人：姓名＋工号 回归时间：YYYY-MM-DD  回归版本：RxCxxBxx 回归结论：回归不通过

【问题重现场景】（现网问题必填）

【开发修改方案】（现网问题必填）

【问题重现报告】（包含重现环境、重现步骤、重现数据、重现日志等）

【回归测试用例】（补充的测试用例需要给出用例所在特性路径）

【回归测试环境】

【回归测试步骤】

【回归测试结果】

【回归确认结果】

和开发人员xxx确认：xx原因，该问题单回归测试不通过。

【附件】

2      简化流程问题单处理各环节管理规定

2.1      步骤1（问题提交人员填写问题单）

1）问题单提交给测试经理时提交人员要确保问题单基本信息的正确性；

2）如果项目组成员众多，可以提单时选择测试经理和TC

2.2      步骤2（测试（项目）经理审核）

1）测试经理要审核问题单基本信息的正确性。如果测试人员在提单的时候填写错误，必须通过纠正或返回问题单的形式确保正确性。

2）对于需要复制到其他项目组的问题单，由测试经理复制给其他项目组。抄送给本组的项目经理。

2.3      步骤3（测试人员回归测试）

1）在进行问题单回归时，测试人员应认真阅读开发人员的给出的定位和修改信息，从而使回归测试全面、彻底。

2）对于回归测试不通过的问题，需要与开发人员沟通之后，以回归测试不通过的方式，打回问题单。严禁对回归测试不通过的问题单，先关闭，再提单。

3）回归不通过的问题单，回归测试人员必须通知到相关问题修改人，尽量达成一致意见，给出不通过的原因描述。如无法达成一致意见，应及时将问题反馈给测试经理或相关测试负责人，由测试负责人与开发负责人讨论确定处理方式。

4）问题单的回归必须与所标识的版本信息一致，如不一致，测试人员有权拒绝回归。假如测试人员是在后续版本回归的，则需要写明回归的版本。

5）现网问题在回归测试时需要提供问题重现的步骤、测试数据、日志等相关信息。现网问题需要补充问题重现场景、开发修改方案和测试建议。不能重现的问题要在问题单中说明测试的方法和结论。

6）在版本测试结束时，所有回归问题单必须处理完成，不得有遗漏。

7）测试人员在回归问题单时，需要把测试的用例、关键的日志附带进去，不能只写“OK”或“问题回归通过”等简单结果。如果问题单回归多次，不能将以前的版本回归记录删除。

8）回归测试报告样式：

A、回归测试通过的情况

回归人：姓名＋工号 回归时间：YYYY-MM-DD  回归版本：RxCxxBxx 回归结论：回归通过

【问题重现场景】（现网问题必填）

【开发修改方案】（现网问题必填）

【问题重现报告】（包含重现环境、重现步骤、重现数据、重现日志等）

【回归测试用例】（补充的测试用例需要给出用例所在特性路径）

【回归测试环境】

【回归测试步骤】

【回归测试结果】

【附件】

B、回归测试不通过的情况

回归人：姓名＋工号 回归时间：YYYY-MM-DD  回归版本：RxCxxBxx 回归结论：回归不通过

【问题重现场景】（现网问题必填）

【开发修改方案】（现网问题必填）

【问题重现报告】（包含重现环境、重现步骤、重现数据、重现日志等）

【回归测试用例】（补充的测试用例需要给出用例所在特性路径）

【回归测试环境】

【回归测试步骤】

【回归测试结果】

【回归确认结果】

和开发人员xxx确认：xx原因，该问题单回归测试不通过。

【附件】

3      问题单处理管理规定

1）C版本的第一个B版本转测试后，所有发现的缺陷，必须提交问题单，没有提交问题单，不得将代码Check In到代码配置库。

2）所有测试提交的缺陷单都必须按照正常的流程处理，任何人不得以任何理由异常关闭问题单。这里的异常关闭是指没有经过回归测试直接进行问题确认后关闭。

3）对于测试提交的所有缺陷问题单，相关人员不得随意挂起。如需要挂起，必须经过CCB讨论和测试经理的确认。

4）对于测试提交的很难重现、无规律重现、有条件概率重现问题单，开发人员不得以无法重现为理由打回问题单；开发人员定位后，缺少相关信息影响继续定位的，可以提交测试人员重现问题，但开发人员需要提出明确的问题重现后要获取的相关信息。

5）CCB由开发PL定期组织，主要是对有争议的问题单进行决策，必须是开发，SE，测试（测试PL或TSE）三方共同参加；

6）对于有争议的问题（例如：需求理解问题；开发觉得不是问题，而测试认为是问题），开发人员不得直接将缺陷单返回测试经理，必须要先与测试沟通，取得一致意见后才可以返回，如果不能达成一致，则可以将问题单提交CCB进行讨论处理。

7）回归问题单的执行必须等版本基本功能验证通过之后再统一进行，任何人不得在版本尚未正式提交时对问题单进行回归。

8）为保证自身测试工作的质量和进度，问题的重现定位原则上由开发人员自己完成，测试人员只协助进行定位，但在问题第一次出现所进行的定位确认时，必须给予开发人员足够的帮助，但开发人员在测试人员环境定位超过1小时（不重现/随机重现问题2小时），则由开发人员自行解决，测试人员不再提供环境。

9）缺陷问题单处于问题确认状态不得超过三个工作日。

10）由于提交错误、重复或其他原因被打回的问题单，问题提交人必须及时处理，问题单处于初始化状态不得超过五个工作日。

11）对因为填写不规范、不全面的缺陷问题单，问题提交人应尽快根据审核人意见进行修改后重新提交，任何人不得随意将问题单删除。

12）提交CCB决议的问题单，CCB决议后认为不需要在本版本修改的，测试认为是问题、需要跟踪的，问题单退回测试经理审核环节后，测试经理选择作为非问题提交给问题提交人确认关闭。

13）提交CCB决议的问题单，经确认是测试人员理解错误或配置、操作错误的，问题单退回测试经理审核环节后，测试经理退回给问题单提交人确认，提交待删除。