+二次开发业务+外包开发业务
3. 日后所有的开发内容(技术平台补丁、标准产品补丁、外包开发团队的功能内容)必须以标准补丁的形式更新测试环境，进行测试。不允许在测试服务器上进行手工操作，包括脚本的执行。
4. 原则上每日更新补丁测试，开发人员对于bug的修改每日构建，第二天更新补丁进行测试。如有紧急需求，张小静可以增加补丁更新的频度，但不允许替换jar的形式更新。
5. 测试环境保持唯一性和准确性，所有的内容都以补丁形式进行验证
6. 每条项目任务的通过以项目管理工具中项目任务通过为标准，项目进度以及项目质量全部以项目管理工具数据为准。在开发机上测试结果不能作为任务通过标准。
质量保障缺陷处理机制：
1. 测试中发现的所有问题都必须以bug的形式在项目管理工具中更新，无论是环境问题、标准产品问题、技术平台问题、二次开发内容还是外包开发内容
2. 所有的任务和缺陷修复开发人员必须做好单元测试，单元测试必须执行测试用例的1级用例或执行30%的核心用例，减少中断等影响测试开展的重大错误。测试人员保障业务流程的有效测试。
3. 项目问题分析和处理机制：首先标准产品研发人员进行分析，标准产品确认无误后，二次开发人员对二次开发内容进行分析，确认无误后外包团队开展问题分析，只至分析出问题的所属团队，由对应团队成员第一时间处理。
4. 几种BUG处理机制
1) 除重复bug外，其余bug一律不允许打回
2) 测试人员提交bug给开发人员A，如该bug不属于开发人员A处理，不得打回，应将bug转交给对应的开发人员，如不清楚该bug对应的开发人员，将bug转发给项目经理，由项目经理转交给对应的开发处理人。
3) 测试人员提交bug给外包团队开发人员A，开发人员A发现该bug属于技术平台或标准产品或二次开发影响导致，不得将bug打回，将bug转发给项目经理，由项目经理协调相关人员进行修改，待bug处理解决以后，标记已改提交给测试人员验证
4) 测试人员提交bug给开发人员，开发人员发现该bug属于测试环境问题，不得将bug打回，而是需要分析测试环境为什么会存在问题，并告知环境解决的方法，如果有问题，可以申请相关人员协助，如果无法发现问题，将bug提交给项目经理，由协调资源处理，待问题解决，将bug标记已改提交测试验证
5) 对于技术上存在难度或认为bug无需处理，可将bug标记暂不处理，且必须注明暂不处理的原因，并提交项目经理。由项目经理和我共同决策该bug是否可以不处理。原则上只有人机交互和产品建议可以不处理，其他bug不允许不处理。
6) 开发人员和测试人员遇到争议问题要进行充分沟通，保证对于产品缺陷的一致性，提升bug修改的效率和质量
7) 所有的bug逐条关联项目任务，直接反应项目任务的开发质量
8) 对于bug，开发和测试人员必须及时处理，原则上提交的bug开发必须在3天内处理完毕，重大中断、数据等缺陷必须在1天内处理完毕，测试人员必须在2天内保证bug的验证通过。
进度和质量的衡量标准
1. 项目任务的完成进度以项目管理工具数据作为唯一标准，以项目任务的通过率作为项目任务进度数据
2. 功能质量以项目管理工具完成情况为依据。测试通过的任务视为有质量保证的任务，测试未通过的项目任务一律认为存在质量问题，不纳入进度数据。