2.2 用户问题反馈
用户反馈的问题，属于软件质量范围内的问题，统一提交到测试组中。对用户反馈的问题，必须执行如下规定：
1. 对确认的缺陷，必须按需求变更、完善系统方式进行分类， OA 问题、业务问题（可细分到子模块中），并记录到 XX 项目缺陷 .xls 的表“最新 BUG 报告”中，并上传到 VSS 上；
2. 测试组通知项目经理，项目经理从 VSS 上取“最新 BUG 报告”（强制要求行为），确认哪些内容是需要修改的，并在“最新 BUG 报告”上填写修改人，解决时间；对属 OA 问题，由项目经理整理到“ OA 缺陷提交报告”中，并与电子政务协调修改；
2.3 修改人员管理
为了避免同一个问题反复出现，源代码在经过多人修改后，无人相信 VSS 的局面，修改过程中必须如下规定：
1. 从 VSS 上获取用户最新的运行环境；
2. 对修改内容必须从 VSS 上 check out ；
3. 对不执行 check out 而造成的对他人修改的影响，罚款 100 元作为项目活动经费；
4. 缺陷修改完，必须将所修改的内容 check in 到 VSS 上，制定修改清单，清单中必须说明经编译后的类文件的路径；
5. 从新从 VSS 上获取最新的运行环境，根据修改清单对开发环境进行升级；
6. 将修改清单提交到测试组中；
2.4 测试组测试
1. 在修改内容的文件夹下，建立以修改日期命名的文件夹；在修改结果的文件夹下，建立以修改日期命名的文件夹；
2. 根据清单，从 VSS 上取得相应的文件 ，并将写上当日修改日志，总的修改日志；
3. 利用 Ant 将 *.java 编译成 *.class 文件；
4. 将 *.class ，将文件复制到 jar 包及 classess 的目录下，将其他文件复制到相应目录下，在修改的修改日期文件下夹应该只有一个 public.war 文件夹， jar 包， * 。 sql 文件，并将写上当日修改日志，总的修改日志；
5. 从新从 VSS 上获取最新的运行环境；
6. 根据修改结果步骤，在对内服务器对应的应用上进行升级；
7. 还原数据库，测试，如有问题，返回修改人员进一步修改，重复上述步骤 ；如开发人员提供的修改清单名称错误超过两次，罚款 100 元作为项目活动经费；
8. 如无问题，则将修改结果整理到用户升级文件中，提交给项目经理；
9. 测试组将“最新 BUG 报告”中修改确认正确的缺陷转到已修改 BUG 报告，并将内容上传到 VSS 上；
2.5 升级及备份
1. 项目经理收到测试组提交的用户升级文件后，根据项目作进一步检查；
2. 项目经理联系用户负责人进行升级，填写升级记录，并将与用户交流的电子邮件等上传到 VSS 上；
3. 升级后，应将用户环境、数据库进行备份，如情况不允许，应将对内服务器的对应的环境尽心备份，将部分内容上传到 VSS 上；用户环境应是不包括附件外的所有环境；
4. 过一段时间后，与用户联系，确认缺陷是否解决；
文章来源于领测软件测试网 https://www.ltesting.net/
