用户接受测试

公司的一个网上支付项目的第一阶段连着进行了2次用户接受测试都没用通过，用户把他们的测试报告发个来给我们看。他们的测试用例比我们的详尽多了。考虑的情况也多好多。看到他们的用例都有点自愧不如的感觉。
为了通过第三次用户接受测试。必须要修改用户发现的问题。时间很紧，没办法只得连接着加班测试和修改缺陷。
一天加班到了临晨4点，准备回宿舍的时候，外面居然下起了大雨，等雨停了才能走。
测试的过程中都会有一些意想不到的问题。一些特定的操作连在一起都会产生一些很严重的问题。程序员在修改缺陷的时候同时会产生其它的问题。大大的加长了测试的时间和难度。
项目本身也有很多问题，导致了用户接受测试接着两次都失败。
1）用户需求的不可控
由于是香港的一个项目，所以需要香港的同事获取需求然后再传到广州。由广州team进行开发测试，这样就增加了沟通的成本和降低了沟通的效率。由于项目schedule的安排不一致，没有提前安排和通知，降低了广州和香港team的工作协调性，导致项目时间安排上的冲突。并且由于SA接连换了2个，导致客户需求获取的不完善，并且新的SA需要时间了解项目情况，这样就延长了项目时间，增加沟通成本。并且相应的需求用例没有及时更新和与客户确认。从而导致客户在第一阶段开发的过程中不断的提出新的需求。导致工作量增加而又处于十分被动的地位。
甚至在用户接受测试的报告中还有建议改进项，而程序员试图完成这些需求。
2）多浏览器测试引发的技术风险
接到用户的测试报告，他们用不同的版本不同浏览器进行了测试:IE6,IE7,firefox2.0, firefox3.0,结果是由于浏览器的版本和类型不一样，导致了很多界面问题，出现了一些客户不愿意接受的差别问题。由于支付网关对浏览器的支持问题，导致一些浏览器下，支付活动遇到障碍。甚至还有一些问题暂时无法完全解决。这样就给项目带来很大的技术风险。
现在正在进行第3次用户接受测试呢！希望能够顺利通过吧！