项目中测试执行基本规范.xlsVIP

项目测试执行基本规范 类型 具体要求 备注 测试执行 1、完整性：以模块为单位建立测试集(如双机模块-姓名-用例数量)，并确认模块用例已全部导入(如分阶段执行也需保证) 2、执行策略：按测试策略要求执行，建议执行顺序bvt、leve1、leve2、leve3或按照质量属性来；建议用例区域执行顺序：基本功能、高风险区域、复杂逻辑优先测试，测试完成率增加比较慢，但对被测对象质量的信心却增加很快 3、执行状态：按用例执行标记规范标记执行状态，测试执行结束时，只能存在N/A、pass、Not Modify；Not Complete、N/A状态需找PM或责任人确认 4、用例优化：执行过程如用例存在问题，可直接提交评审记录，并让责任人处理或自己处理 用例执行标记规范： Not Complete：用例无效、用例错误、无测试环境等过程状态，需处理； Passed：执行通过 No Run：默认状态，未执行 N/A：无须执行，需填写备注，需处理(某个发布测试项无须执行) Failed：执行失败，需填写BUGID Blocked：被其他问题阻塞 Not Modify：由Failed状态而来，用例发现的bug不修改，bug为halt、Wont Fix 注意：需求变更删除、重复覆盖应该移走无效用例，测试集可删除无效用例，系统保留的是有效用例 探索测试 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_Dup bug回归备注必须覆盖开发的测试建议，提交bug的测试步骤，TD备注中需回归的点，讨论出的发散测试点，并备注说明升级包名称、验证