与测试人员的约定：
一、测试过程资产部分
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.存在缺陷是否更改的争议时，先跟测试沟通，若无法达成一致，再由指定的项目负责人或产品人员决定。
