问题1：用需、软需文档不够完整，需求不够明确，功能细节描述不足。
　　解决：
　　需求维护：Jira上的产品建议、运维反馈的产品建议。
　　需求文档维护。（系统的主要功能、流程在文档中都需描述，功能实现细节可在需求评审补充或用例设计时加入）
　　需求评审（召开版本迭代会讨论明确需求）
　　版本迭代会：项目经理规划版本之时，召开版本迭代会，对需求进行说明，开发和测试人员有问题可共同探讨，避免需求理解歧义。（其他组的经验）
　　问题2：完善需求OR完善用例？
　　讨论：
　　严格意义测试应该从需求开始抓起，参与需求的评审，对详细设计也要测试，如果可以做到这样，那么无需求测试的状况不会出现了；但目前我们并没有做这么多，或者说做得不完全。所以测试人员都会或多或少的遇到这种无完善需求文档的测试状况，这时候我们需要谨记的则是我们必须保证我们的测试用例包含了你所要测试对象的所有功能点。Openqs目前来看完善需求文档和完善用例都是比较痛苦的。因此建议是两头同时开展，一方面，系统的主要功能流程在需求文档（用需）补充。另一方面提高测试用例覆盖需求度，补充异常的验证流程等。
　　问题3：jira上的缺陷描述不规范。
　　解决：
　　全员规范缺陷描述，注意事项：
　　1. 对于无法重现或不好重现的问题，备注说明测试地址、账号、密码等，供开发人员排查。
　　2. 针对兼容性类的缺陷，说明缺陷使用的浏览器、分辨率、操作系统等情况。
　　3. 1个缺陷尽量只描述1个问题，不要描述多个问题。避免开发人员对缺陷没有修改全，或者只修改一部分，一部分后面才修改。
　　4. 一些缺陷若文字描述无法准确表达的话，好都能带上附件截图说明。比如一些提示信息啊、样式显示啊、另外一些显示代码类的错误都必须截图说明。
　　5. 开发人员解决完缺陷，若可能的话好备注说明修改的情况及可能影响的功能。
　　6. 测试人员验证缺陷，若缺陷重新打开，增加备注说明验证的情况。
　　问题4：系统环境搭建较为复杂，测试环境更新未走标准化流程，系统安装更新手册说明不足。
　　解决：
　　自动构建、减少人工的配置操作、简化环境搭建和更新步骤
　　完善系统安装手册、系统维护手册、系统更新手册。
　　问题5：测试过程中，采用边测边改的方式，更新测试环境频繁，导致功能重复测试较多，测试效率不高，同时遗留缺陷的风险较大。
　　解决：
　　引入周更新测试，规范测试。
　　问题6：提交的缺陷，没有安排解决时间表，不断遗留和累积，感觉测试的工作成果得不到重视。
　　解决：
　　建议制定迭代计划时，将缺陷安排到迭代任务中解决，在迭代的系统测试进行验证。