问题1：用需、软需文档不够完整，需求不够明确，功能细节描述不足。

　　解决：

　　需求维护：Jira上的产品建议、运维反馈的产品建议。

　　需求文档维护。(系统的主要功能、流程在文档中都需描述，功能实现细节可在需求评审补充或用例设计时加入)

　　需求评审(召开版本迭代会讨论明确需求)

　　版本迭代会：项目经理规划版本之时，召开版本迭代会，对需求进行说明，开发和测试人员有问题可共同探讨，避免需求理解歧义。(其他组的经验)

　　问题2：完善需求OR完善用例?

　　讨论：

　　严格意义测试应该从需求开始抓起，参与需求的评审，对详细设计也要测试，如果可以做到这样，那么无需求测试的状况就不会出现了;但目前我们并没有做这么多，或者说做得不完全。所以测试人员都会或多或少的遇到这种无完善需求文档的测试状况，这时候我们需要谨记的则是我们必须保证我们的测试用例包含了你所要测试对象的所有功能点。Openqs目前来看完善需求文档和完善用例都是比较痛苦的。因此建议是两头同时开展，一方面，系统的主要功能流程在需求文档(用需)补充。另一方面提高测试用例覆盖需求度，补充异常的验证流程等。

　　问题3：jira上的缺陷描述不规范。

　　解决：

　　全员规范缺陷描述，注意事项：

　　1. 对于无法重现或不好重现的问题，备注说明测试地址、账号、密码等，供开发人员排查。

　　2. 针对兼容性类的缺陷，说明缺陷使用的浏览器、分辨率、操作系统等情况。

　　3. 1个缺陷尽量只描述1个问题，不要描述多个问题。避免开发人员对缺陷没有修改全，或者只修改一部分，一部分后面才修改。

　　4. 一些缺陷若文字描述无法准确表达的话，最好都能带上附件截图说明。比如一些提示信息啊、样式显示啊、另外一些显示代码类的错误都必须截图说明。

　　5. 开发人员解决完缺陷，若可能的话最好备注说明修改的情况及可能影响的功能。

　　6. 测试人员验证缺陷，若缺陷重新打开，增加备注说明验证的情况。

　　问题4：系统环境搭建较为复杂，测试环境更新未走标准化流程，系统安装更新手册说明不足。

　　解决：

　　自动构建、减少人工的配置操作、简化环境搭建和更新步骤

　　完善系统安装手册、系统维护手册、系统更新手册。

　　问题5：测试过程中，采用边测边改的方式，更新测试环境频繁，导致功能重复测试较多，测试效率不高，同时遗留缺陷的风险较大。

　　解决：

　　引入周更新测试，规范测试。

　　问题6：提交的缺陷，没有安排解决时间表，不断遗留和累积，感觉测试的工作成果得不到重视。

　　解决：

　　建议制定迭代计划时，将缺陷安排到迭代任务中解决，在迭代的系统测试进行验证。

　　问题7：缺陷解决流程没有形成规范，存在缺陷关注不足，缺陷不解决，解决后未验证、无法验证等情况。

　　解决：

　　制定缺陷解决流程，按规范严格执行。

　　配置人员权限

　　功能测试阶段：

　　项目测试类型我觉得可先大致可分为两类：周更新测试和系统测试(含性能测试、安全测试、稳定性测试等专项测试)。

　　周更新测试

　　周更新测试：主要是针对每周的各组件更新需求，进行测试。

　　组件更新是否提交测试可由组件负责人自行判断，不一定需要提交测试。

　　提交测试需保证更新的主要功能已完成并已自测，若发现因为主要功能有问题导致无法继续测试，则退回测试。

　　提交测试需由组件负责人说明清楚更新的内容和可能的影响功能。

　　测试人员主要针对更新的内容及可能影响的功能进行测试，并对系统的主要流程进行冒烟测试，其他功能不进行测试。(1.增加的新功能以及新修复的bug。2.系统中重要的功能，如果有将测试用例分优先级的话，优先级高的测试用例应该要被执行到。3.与开发人员交流，确定哪些功能是受最新的改变而有可能发生问题的，开发人员认为最有可能出问题的功能，应该重点测试。)

　　测试结束一般不出具测试报告，可大概整理下早会说明或者通过邮件、QQ向组件负责人、项目经理、产品经理说明下测试情况。

　　一般在测试完毕后才允许更新环境进行第二轮的验证测试。(尽量减少测试过程中更新测试环境的频率，除非因出现大问题影响测试不得不更新环境)

　　周更新测试发现的缺陷统一登记到jira上。

　　系统测试

　　系统测试：建议比较大版本的功能开发结束，提交一次比较完整的系统测试。(包含之前做的几次周更新测试)

　　系统测试可按循环进行，第一循环测试后，在开发人员修改完第一循环缺陷后再提交第二循环测试。如此进过2-3个循环，最终使产品达到发布上线的标准。

　　系统测试结束后出具系统测试报告。

　　系统测试环境由测试人员搭建和更新。

　　提交测试时说明测试的内容(哪些要测试、哪些不测试)

　　系统测试准入条件

　　1. 需求文档已纳入SVN，功能需求明确，已通过评审。

　　2. 项目经理提交测试申请单(参考测试申请单模板)

　　3. 本迭代的测试用例已完成并通过评审。

　　由于版本周期问题，组内其他成员可能没时间看，测试人员可按优先级罗列测试点，测试计划。组内测试人员之间，也可以互评。若有时间产品经理和主要开发人员也可参与评审。

　　4. 版本开发结束，开发人员自测。

　　开发不宜提交太过频繁，不应提交无法构建，编译错误的代码。且应该在有较大改动，或进行较大更新时，有一定的可测性，才提交测试。若开发提交测试的产品，主流程主功能出现问题，较大影响测试开展，则测试人员可中止测试，待改善后重新进入。

　　相对独立的功能需求，可分别提交测试;但如果多个需求关联性紧密，应该开发完毕后一起提交测试，避免测试人员过多重复劳动。

　　对于没有完成的功能，不能提交测试，必须在代码中注释掉。

　　5. 代码已提交配置库，并提供安装说明文档。

　　注1：功能测试可以分测试循环进行，如第一循环测试完毕后，开发人员对缺陷进行修改，将大部分缺陷均已修改，然后提交第二循环测试。第二循环验证缺陷和进行针对性的测试。若缺陷还较多，再提交第三循环。如此反复直至满足测试退出准则结束功能测试。

　　注2：功能测试由于人力资源限制，提交太过频繁，建议有比较大改动或要进行较大更新才提交测试。其他类型采用周更新测试的方式，大体如现在我们进行的测试类型。

　　注3：若提交的产品，主要流程出现大问题，较大影响测试进行，向项目经理中止测试，待改善后再提交测试。

　　系统测试退出标准

　　1. 测试用例均已执行，用例通过率90%。

　　2. 功能需求都已经开发和测试完成，系统性能和功能已达到需求标准。

　　3. 严重缺陷均已修改(若有遗留由项目经理和产品经理审批)、总体缺陷修复率达到80%(暂定80%，后续根据产品要求可提高)