问题严重程度定义

3.3.5 致命问题：

1、 系统异常复位、重启；

2、 系统死机；

3、 系统启动失败；

4、 板间通讯瘫痪；

5、 模块功能失效，必须要通过复位操作才能恢复的问题；

6、 内存持续丢失，最终导致系统不能正常运行；

7、 系统严重丢内存；

8、 控制台瘫痪；

9、 配置恢复失败；

3.3.6 严重问题：

1、 系统重要功能异常但能恢复；

2、 板间通讯间断断链；

3、 基本功能执行错误；

4、 与主流厂商设备不能互通；

5、 性能指标没有达到基本要求；

6、 配置恢复丢数据；

 3.3.7 一般问题
1、 系统功能执行效率较低；
2、 实现细节与规格不符，但不影响功能；
3、 进行了额外的操作处理，但不影响正常功能；
4、 未对可选项进行处理，但不影响正常功能；
5、 未对异常参数进行处理，但不影响正常功能；
6、 兼容性问题，但不影响正常功能；
7、 命令行错误；
8、 提示信息语句存在歧义或错误；

3.3.8 提示性问题：
1、 命令使用不方便；
2、 命令不便于理解；
3、 命令功能正常，但操作顺序不合理；
4、 提示信息风格不合适；
5、 命令、参数、提示或返回信息不符合系统风格；
6、 其它建议性问题；

3.3.9  测试人员在提交问题单的时候需要的注意事项：
1、 对于严重、致命和对接失败的问题要抄送测试组所有成员；
2、 对于严重、致命、不可重现以及无规律重现的问题一定要联系开发现场定位，需要开发确认。在问题单中注明定位开发人员名单和定位信息，测试人员需要提供的信息；

3、 对于大数据量或满配置数据引起的问题，把配置文件附上，便于开发定位和回归测试；
4、 对于命令行或者方案性的问题，给出修改建议，开发人员在定位修改时需要和问题提交人确认；
5、 命令行提示问题可以多个问题合为一个问题单，但要求该问题属于同一个特性，不同特性的命令行提示问题一定要分开提单；
6、 硬件问题一定要注明问题单板的条码信息和相关硬件版本信息，如果可能需要收集硬件PCB版本；
7、 提交问题态度要严肃，描述要清晰，描述不清晰的问题单打回

3.4.1 问题单审核人注意事项：
1、 严格要求问题级别，不符合的返回提交人修改后重新提交；
2、 硬件问题在提交开发项目经理的时候，请各个问题审核人将问题单抄送给硬件测试经理；
3、 问题审核人每天要将审核的问题单处理完，不能滞留；
 
3.4.2 回归测试时间
在版本通过初验之后才可以启动回归测试，此时测试负责人应通过邮件方式通知。回归测试责任人在收到回归测试通知或版本转测试通过电子

流后开始进行回归。

--------------------------------------------------------------------------回归测试报告模板----------------------------

【回归测试结果】
通过、不通过、部分通过。

【回归测试版本】
MA5600T(su)%%display compiling time active

【回归测试环境】
组网、配置等信息

【功能验证记录】
按照问题出现的步骤一步一步进行操作，并对于关键部位像提问题单时一样给出标识说明；
【是否引入新问题】
如果引入新问题，请注明新问题单号(由于问题提交开始没有单号，这里就需要定期清理一下需要回归和确认的问题单，来确保，能够记录下来，只是建议)。

【相关模块分析】
此问题修改，将影响其它特性的功能。在将备注下，并知会到相关特性责任人。

【是否刷新测试用例】
注意事项：
1、回归测试结果严格按照以上模板给报告；
2、若多次回归，不能将以前的回测试记录删除，在每次回归记录前加上以下内容标明回归测试时间。格式如下：

第XX次回归测试时间：YYYY-MM-DD(YYYYMMDD为8位数字的年月日)

3.4.4 回归测试不通过确认处理流程

1. 回归测试不通过的定义：
1、 问题单要求要修改的、但实际在指定版本中没有修改；
2、 问题单中说明要修改的、但开发人员在问题单中没有明确说明不用修改，实际在指定版本中没有修改或者与问题定位、修改实施不符的；
3、 如果问题单中列了有多个问题，但存在某个问题没有解决，该问题单作为回归测试不通过；
4、 对于开发修改中引入的新问题，如果问题单本身的问题已经解决，则不认为是回归测试不通过，新问题重新提交问题单跟踪，原来问题单中说明情况；

2. 回归测试不通过处理流程
1、 出现回归测试不通过的现象，测试人员需要在第一时间联系相关开发人员电话沟通测试结果，尽量不要使用邮件沟通方式；
2、 如果没有达成一致，严禁测试和开发争吵，联系特性负责人或者测试经理解决；
3、 回归测试不通过的问题单测试人员返回问题审核人，问题审核人提交给配置管理员修改授权。
4、 版本回归测试期间回归测试不通过的问题单每个特性负责人要收集后统一报给测试经理汇总。

3.4.5 对硬件问题的回归
如果最后明确定位问题是由于个别单板硬件故障（如器件失效、虚焊）引发的问题：
1、如果该硬件可以更换，在更换后回归，回归测试通过关闭问题单；联系硬件测试人员；
2、如果无法更换硬件，则需要硬件人员给出分析报告，并由相关PM和硬件测试经理审核确认。

3.4.6 回归测试结果确认
1、 对于回归测试人员和问题提交人是同一人，可以不用再进行确认流程；
2、 如果回归测试人员和问题提交人不是同一人，一定要让问题提交人确认关闭。

3.4.7 回归新引发问题的处理
问题单的回归针对原有问题进行测试。有的问题单修改后，原有问题已经解决，但修改时又有新的问题引发，此时可以关闭原问题单，对新产

生的问题重新提单，但注意要在原问题单的回归测试过程中注明新问题所提交的问题单号及链接，便于日后查验。

3.4.8 测试人员关注开发修改的正确性
回归测试时应该关注“开发人员进行修改实施”阶段问题单的流程：
1、 开发定位与修改实施应完全一致，不允许出现修改实施阶段多修改、少修改问题的情况，更不应该出现开发定位为A、修改实施为B的现象；

2、 要检查“实现说明”部分的版本号是否正确；
3、 要检查测试报告是否和实际回归测试时的结果保持一致，如果不一致则需要和开发人员确认。有可能出现开发人员修改完问题后发现不妥

后面再次修改而没有修改记录的情况，这样对问题的修改过程就难以追溯。

3.5 问题单关闭、转CCB、当前版本不解决问题单处理原则

3.5.1 问题单关闭条件
问题单关闭只能有三类情况：
1、 问题解决正常关闭：经过回归测试确认在新版本彻底解决；
2、 非问题关闭：测试人员对问题理解错误；
3、 重复问题关闭：处理方式见3.6.1

3.5.2 转CCB评审条件
1、 暂时无法重现：经3个月不能重现转CCB评审；
2、 近期B版本无法解决：近期B版本（当前B版本的回归版本）无法解决的问题，可以先转CCB评审挂起，等新的B版本发布以后再激活解决；
3、 当前R版本决定不解决：在当前R版本中无法解决，或解决成本较高，但对产品质量影响不大（用户可以接受）的，可以转CCB评审；
4、 方案解决有争议的问题；

3.5.3 对当前版本不解决的问题
1、 当前R版本决定不解决的问题，无论问题在新R版本中能否解决，其在低R版本中的问题单都不能以在下一版本解决的理由进行删除或正常关闭。

2、 对于未发行到网上运行的B版本无法解决的问题，需要在后续B版本中解决的，只有在新发布B版本中验证解决以后，才能关闭原问题单。

3.6 其他问题单处理
3.6.1 重复问题单处理
1、 对于重复问题，如果表面现象完全相同，该类问题返回删除问题单；
2、 对于重复问题单如果现象不相同，得到测试人员认同，该类问题单不能删除，请审核人关注只能走问题确认关闭流程。
3、 对于重复问题单现象不同，而且无法得到测试人员认同，则问题单走正常修改、回归测试流程。

3.6.2 问题单同步处理
需要同步到其他版本的问题单处理如下：
1、 当前版本的问题不能直接转到后面的R版本或B版本，必须采取复制的方式；
2、 当前版本的问题单上必须附上复制问题单号以及链接；
3、 当前版本的问题单不能被删除，请问题审核人关注；
4、 当前版本的问题单必须在问题解决后才能关闭，不能因为复制就关闭问题单；

4 测试过程各种规范
4.1 版本刷新规范
1、 加载程序出现问题需要刷新，必须走刷新流程和进行刷新公告,附上问题单号；
2、 补丁和升级工具刷新，也必须走刷新流程和进行刷新公告，附上问题单号；
3、 版本、补丁和升级工具刷新一定要同步刷新相应的转测试文档。

4.2 对无规律、不可重现问题的处理：
4.2.1 测试人员必须做到的：
1、 出现无规律重现和不可重现问题在第一时间通知相关开发人员现场定位，要求直接电话联系；
2、 测试人员要将相关的信息和所有执行过的操作知会到开发人员，而且一定要在问题单中详细描述；
3、 如果没有找到负责该模块的开发人员，继续找相关人员，实在找不着一定要知会主管，由主管协调，测试人员不能在没有知会的情况下随意破坏现场；

4、 在开发结束定位后，测试人员一定要清楚最后的结论，在问题单中注明最后定位结论以及曾经定位过的开发人员名单，特别注明得出结论的开发人员；
5、 严禁测试人员和开发人员私下协调认为无法重现、无法定位就放弃提交问题单；
6、 在资源允许情况下，测试人员由责任协助开发重现问题，但要明确重现的主体仍然是开发人员，测试人员协助。

4.3 测试报告
1、 版本测试按照原定日期停止测试，停止问题单的提交；
2、 按照测试报告模板在版本结束日期提供测试报告；
3、 报告中要加强用例执行情况、测试充分性、测试建议分析；
4、 测试报告需要审核人严格审核，不符合要求的要返回修改；
5、 停止测试期间发现严重、致命以及不可重现问题需要开发及时定位；

以下是过去问题单处理中常见的问题：
--发现问题后注意保留第一现场，尝试重现最好另找环境操作，因为可能遇到的是非必现问题，现场不保留，会让开发定位很头疼的。
--注意保留操作日志等关键物证，比如调用栈信息，LASTWORD,消息包过载记录，抓包记录，系统加载的补丁（补丁文件应提醒开发保留源代码）

--提单之前做一些必要的发散操作，因为可能关联有其他异常现象存在。
--开发尚未定位出来的问题，切勿延迟，应该尽早提单（最多延迟1小时）。
--开发定位如需占用工作PC，请换用备用PC处理工作内容（缺少PC可以找主管人员协助解决），物料资源紧张的时候，原则上现场保留时间不超过2小时。

--问题单填写请遵照模板，语言准确简练，提供信息关键而不冗长，如果提上去的单让人看不懂或难以按照描述重现问题，是非常糟糕的体验。

--以客户为中心，严重级别分析的时候请考虑对客户的影响，对用户体验有影响的也是问题。
--同源问题的不同表现，按不同问题单提交。
--包含多个现象的问题，以严重程度最高的现象确定严重级别。
--坚持标准和原则，问题单的严重级别判定不要随开发的思路走。
--资料问题单的处理流程稍有不同，需要使用专门的提单工具，由资料测试接口人统一提单
（相关内容请咨询资料测试接口人，比如谢远征同学，以前负责过资料测试工作，有疑问可以找他）。

--问题单中描述的所有现象均得到了解决，问题单才有关闭的可能。
--问题单回归请注意查看开发的问题分析和测试建议，回归时做适度的发散，谨防问题修改又引入新的问题。如有新现象，及时和开发沟通，

引入新问题就提新问题单。
--回归不通过的问题单，请先和测试经理以及开发沟通后再确认处理方法。
--问题回归时关注下测试设计的覆盖，与特性OWNER/TSE沟通，缺少用例覆盖就及时补充用例覆盖。
--问题单关闭时，一定要注意关闭类型，尤其是同步问题单，返回到自己手里确认关闭的时候，确认是问题（不论是否是本部门的）的就不能按非问题关闭，关闭前请知会测试经理。

--其他注意点以提单规范为准则，不能定夺的处理，请咨询老员工们或向测试经理反馈。