测试约定

与测试人员的约定：

一、测试过程资产部分

1.产出测试输出物：

测试用例：新需求测试用例设计、流程测试用例（老用例库）补充。

问题清单checklist：版本上线前发现的问题清单。

2.完成版本上线报告测试部分的填写：

验收结果：说明当前已解决问题及仍存在的问题。

二、Bug开立及追踪部分

1.测试过程发现的所有问题都要记录在wiki之中，以便于Bug统计及其他工作的进行。

2.Bug开立需遵循wiki问题单提交规范。

标题标注具体是哪一端（Android、IOS、后台）的问题以及问题发生的版本号。

选择具体模块，指定经办人。

描述中提供问题重现步骤，

提供测试数据来源：用户信息以及具体哪一天哪一模块的数据。

附件中添加问题截图或报错日志，

3.测试人员需跟踪Bug处理状态，特别是优先级较高的问题，可催促开发人员尽快解决以免影响项目进度。

4.及时回归已修复的Bug。

可创建"我报告的未回归的问题"筛选器用来查询未自己回归的Bug。

帮其他测试人员回归问题时需在备注中标明：回归测试已通过、回归测试未通过（标明具体问题）@报告人、@解决者

三、 测试与开发配合

1.测试配合开发说明Bug产生场景辅助开发人员分析问题。

2.测试完毕后，必须通知相关的负责人。

3.遇到某个bug修改不完整的情况，做到不急于驳回，与开发沟通后再将问题指回（不符合预期/重新打开的问题不会在开发人员未解决的问题中显示，需要单独通知）。

与开发人员的约定：

一.、版本发布部分

1.确保版本能按计划交付

遵守产品迭代计划，按期交付测试

2.与测试的交付物需先经过自测：

开发完成新需求以及修复bug后，自身进行测试以确保新需求得以实现,bug问题已经修复、保持版本稳定。

开发人员自测后方可将产出物交于测试人员测试。

3.提供版本问题修复清单：

开发人员每次打版之前需提供本版本已修复问题的清单，测试人员可根据此清单进行回归。

清单需明确当前版本的送测内容：修复问题列表、具体功能修改等，避免出现模糊描述。

二、Bug处理部分（wiki）

1.Bug修复后开发人员必须修改Bug状态。

2.拒绝或者延期处理的Bug必须修改Bug状态

3.严重影响测试进行的Bug，开发人员应积极配合修复，在第一时间处理Bug以保证项目的总体进度。

4.开发人员如对测试人员所填写的Bug不理解或不能重现，可请求测试人员解释或重现，而不能直接拒绝修改。

5.存在缺陷是否更改的争议时，先跟测试沟通，若无法达成一致，再由指定的项目负责人或产品人员决定。