问题7：缺陷解决流程没有形成规范，存在缺陷关注不足，缺陷不解决，解决后未验证、无法验证等情况。
　　解决：
　　制定缺陷解决流程，按规范严格执行。
　　配置人员权限
　　功能测试阶段：
　　项目测试类型我觉得可先大致可分为两类：周更新测试和系统测试（含性能测试、安全测试、稳定性测试等专项测试）。
　　周更新测试
　　周更新测试：主要是针对每周的各组件更新需求，进行测试。
　　组件更新是否提交测试可由组件负责人自行判断，不一定需要提交测试。
　　提交测试需保证更新的主要功能已完成并已自测，若发现因为主要功能有问题导致无法继续测试，则退回测试。
　　提交测试需由组件负责人说明清楚更新的内容和可能的影响功能。
　　测试人员主要针对更新的内容及可能影响的功能进行测试，并对系统的主要流程进行冒烟测试，其他功能不进行测试。（1.增加的新功能以及新修复的bug。2.系统中重要的功能，如果有将测试用例分优先级的话，优先级高的测试用例应该要被执行到。3.与开发人员交流，确定哪些功能是受新的改变而有可能发生问题的，开发人员认为有可能出问题的功能，应该重点测试。）
　　测试结束一般不出具测试报告，可大概整理下早会说明或者通过邮件、QQ向组件负责人、项目经理、产品经理说明下测试情况。
　　一般在测试完毕后才允许更新环境进行第二轮的验证测试。（尽量减少测试过程中更新测试环境的频率，除非因出现大问题影响测试不得不更新环境）
　　周更新测试发现的缺陷统一登记到jira上。
　　系统测试
　　系统测试：建议比较大版本的功能开发结束，提交一次比较完整的系统测试。（包含之前做的几次周更新测试）
　　系统测试可按循环进行，第一循环测试后，在开发人员修改完第一循环缺陷后再提交第二循环测试。如此进过2-3个循环，终使产品达到发布上线的标准。
　　系统测试结束后出具系统测试报告。
　　系统测试环境由测试人员搭建和更新。
　　提交测试时说明测试的内容（哪些要测试、哪些不测试）
　　系统测试准入条件
　　1. 需求文档已纳入SVN，功能需求明确，已通过评审。
　　2. 项目经理提交测试申请单(参考测试申请单模板)
　　3. 本迭代的测试用例已完成并通过评审。
　　由于版本周期问题，组内其他成员可能没时间看，测试人员可按优先级罗列测试点，测试计划。组内测试人员之间，也可以互评。若有时间产品经理和主要开发人员也可参与评审。
　　4. 版本开发结束，开发人员自测。
　　开发不宜提交太过频繁，不应提交无法构建，编译错误的代码。且应该在有较大改动，或进行较大更新时，有一定的可测性，才提交测试。若开发提交测试的产品，主流程主功能出现问题，较大影响测试开展，则测试人员可中止测试，待改善后重新进入。
　　相对独立的功能需求，可分别提交测试；但如果多个需求关联性紧密，应该开发完毕后一起提交测试，避免测试人员过多重复劳动。
　　对于没有完成的功能，不能提交测试，必须在代码中注释掉。
　　5. 代码已提交配置库，并提供安装说明文档。
　　注1：功能测试可以分测试循环进行，如第一循环测试完毕后，开发人员对缺陷进行修改，将大部分缺陷均已修改，然后提交第二循环测试。第二循环验证缺陷和进行针对性的测试。若缺陷还较多，再提交第三循环。如此反复直至满足测试退出准则结束功能测试。
　　注2：功能测试由于人力资源限制，提交太过频繁，建议有比较大改动或要进行较大更新才提交测试。其他类型采用周更新测试的方式，大体如现在我们进行的测试类型。
　　注3：若提交的产品，主要流程出现大问题，较大影响测试进行，向项目经理中止测试，待改善后再提交测试。
　　系统测试退出标准
　　1. 测试用例均已执行，用例通过率90%。
　　2. 功能需求都已经开发和测试完成，系统性能和功能已达到需求标准。
　　3. 严重缺陷均已修改（若有遗留由项目经理和产品经理审批）、总体缺陷修复率达到80%（暂定80%，后续根据产品要求可提高）