项目中测试执行基本规范

类型,具体要求,备注

测试执行,"1、完整性：以模块为单位建立测试集(如双机模块-姓名-用例数量)，并确认模块用例已全部导入(如分阶段执行也需保证)

2、执行策略：按测试策略要求执行，建议执行顺序bvt、leve1、leve2、leve3或按照质量属性来；建议用例区域执行顺序：基本功能、高风险区域、复杂逻辑优先测试，测试完成率增加比较慢，但对被测对象质量的信心却增加很快

3、执行状态：按用例执行标记规范标记执行状态，测试执行结束时，只能存在N/A、pass、NotModify；NotComplete、N/A状态需找PM或责任人确认

4、用例优化：执行过程如用例存在问题，可直接提交评审记录，并让责任人处理或自己处理","用例执行标记规范：

NotComplete：用例无效、用例错误、无测试环境等过程状态，需处理；

Passed：执行通过

NoRun：默认状态，未执行

N/A：无须执行，需填写备注，需处理(某个发布测试项无须执行)

Failed：执行失败，需填写BUGID

Blocked：被其他问题阻塞

NotModify：由Failed状态而来，用例发现的bug不修改，bug为halt、Won'tFix

注意：需求变更删除、重复覆盖应该移走无效用例，测试集可删除无效用例，系统保留的是有效用例"

探索测试,"1、执行策略：需明确过程探索测试要求，有效保证用例执行，不能在执行过程中探索；执行过程中记录探索，经过分析后在验证，因为有可能探索测试点已被用例覆盖，或过度测试

2、探索方法：提前明确探索测试方法和形式(基于思维导图、基于质量分析等)

3、过程记录：所有探索测试记录都要在TP上记录",

bug提交,"1、提交规范：正确填写各字段的信息，“概要”部分要达到使人一看就基本明白是怎样一个bug，“描述”部分按规范填写，

2、提交要求：提交时需查看是否存在相同bug；禁止提交询问式bug，此类问题提交前先私下与相关人员确认；同一个页面的体验性问题、相同原因的同类体验性问题，可提交在一个bug里，其它情况都得独立提交

3、疑难问题：A、对于疑难问题，尽量找开发人员现场确认，并让开发尽量保留现场；B、对于应用层堆栈宕机bug，需提交数据流、堆栈信息、宕机信息、core文件、map文件、blackbox、日志等相关信息，也可以采用自动收集脚本进行收集；文件较小时直接放入TD，文件较大时放入服务器，TD中备注链接地址；C、对于非必现BUG，需明确操作过程，导出配置文件

4、字段填写：TD字段填写要保证正确性，以便于后续质量分析，否则会导致分析有偏差，如当时不能确定，在回归bug时修改TD字段(所属模块、bug案例分析、bug执行分析、严重性、发现版本及阶段、bug类型)

","bug描述规范：

【测试环境】

说明测试的软硬件和网络环境(哪个升级包、硬件平台，测试软件的客户端和服务端、访问了某个网页等与BUG直接相关的信息)

【测试步骤】

按照1、2…的方式列出重现该bug的步骤。好的情形是，描述清晰，别人按照此步骤也能把该bug重现出来。

非必现的bug要列出足够多的步骤信息。

不容易说清楚的，在附件中可加入截图信息。

【期望结果】

应该的预期结果，即正确的结果

【实际结果】

实际操作结果，即bug的现象

【备注】

其它需要说明的附加信息（如Log），或bug初步定位情况等，以方便开发人员及时修改bug"

bug跟踪,"1、严重问题：阻塞问题在缺陷标题中标注【阻塞】、严重问题在缺陷标题中标注【宕机】【严重】，并实时关注修复进展，

2、严重问题跟踪：优先关注【阻塞】【宕机】【严重】问题，如影响测试进度，需找项目经理协助，每天要有处理进展

3、例行跟踪：测试人员应每天例行查看bug解决进展和TD备注，以便及时配合开发修复缺陷，同时查看其它人员发现的问题，以便及时分析与验证",

bug重现,"1、重现前提：bug提交时已详细记录过程操作、日志、截图、监控等等

2、重现过程：A、首先明确重现思路、重现说明、如果重现是否可以定位出来、调试日志，并与开发人员讨论；B、重现过程重按照规范填写备注","bug重现规范：

【开发是否提供调试模块】

【测试重现跟踪】

问题出现次数：

原因可能分析：

计划重现方法：

实际重现结果：

尝试重现次数："

bug回归,"1、回归规范：A、bug回归备注部分按bug回归规范执行;B、bug回归不要进行阶段性回归，要在过程中及时回归或制定周计划(包括前期bug，同时督促开发及时修复bug)；C、bug回归时必须用新包进行回归，不能替换文件进行回归测试

2、回归过程：A、Closed和Closed_Dupbug回归备注必须覆盖开发的测试建议，提交bug的测试步骤，TD备注中需回归的点，讨论出的发散测试点，并备注说明升级包名称、验证的具体的测试点和验证结果，此类原因导致的漏测都视为执行漏测；B、对于开发备注的测试建议不具体可当时沟通；C、bug回归时需清楚开发改动和原理；C、回滚的bug需要验证回滚前的功能，确认开发是否真的已经回滚","bug回归规范：

【是否关联和优化案例】

【回归升级包名称或时间(开发只回归代码级测试的自提bug)】

【回归和关联测试点测试结果】"

BUG关联,"1、关联规范：

A、一级测试用例无覆盖的bug需补充用例(后续会使用模块用例)，其他可不做用例关联；

B、bug回归时需说明【是否关联和优化案例】；

C、对于非必现的问题可不做关联；

D、未覆盖的bug需正确填写“bug案例分析”字段","bug回归规范：

【是否关联和优化案例】

【回归升级包名称或时间(开发只回归代码级测试的自提bug)】

【回归和关联测试点测试结果】"

reopen,"1、reopen规范：

A、且“未回归通过”是指Bug本身描述的缺陷没有被解决，因修改而引起的其它缺陷不计入，当出现此问题时，要找相应开发人员进行确认，对于确实没改好的才能reopen；如发散发现的bug不能reopen，另提交bug

B、对于修改其他BUG所引发的，则不能reopen，等待另外的问题解决之后再进行回归；

C、如存在reopen，测试版本经理需要求开发版本经理分析问题、追溯与改进；","reopen规范：

表示开发认为改好了,但测试发现没有改好。

【何种情况下到此状态】回归测试不通过，或Closed状态的bug发现并没改好"

Rejected,"1、过程规范：

A、测试人员及时确认是否可以reject，并备注原因，测试版本经理填写“Reject已确认?”字段；如不认同，可与测试版本经理沟通；

B、没有确定原因的rej问题不能被reject；","Rejected规范：

1.表示开发和测试都认为这不是个问题,不需做任何改动；

2.或者开发和测试都认定这个bug和其它处于跟踪流程中的bug现象和原因完全相同

3.注意事项和不能重现的问题不能被reject，注意事项也要提交bug，凡是产品问题和注意事项都要在24小时内录入缺陷库

【何种情况下到此状态】任何状态下，认为不是问题；任何状态下，认为和其它bug相同"

duplicate,"表示开发和测试都认定，此bug和其它bug为不同现象、原因完全相同。（其中有一个bug要正常跟踪直至Closed，Duplicate状态的bug回归后改为Clo