这是我在新公司第一次负责这种跨组进行测试工作的，先来说说这个项目的情况，这项目是移动基地要考核的，领导也会比较关注，如果出了问题，或者延期了，都要会被扣分的，所以各个方面要求都比较严格。

　　这项目主要是进行页面交互的优化，一些冗余按钮信息的去掉，页面样式的修改，工作量也不是很小，但是开发人员在评估时间的时候，估算工作量失误，导致提交基线版本的时候，就比原计划延迟了4天多，结果另外安排测试时间，把周末也算成了工作时间，这是很不好的项目管理，就算这样压缩开发和测试时间，还是会延迟一个星期才能上灰度环境。

　　下面从我自身做的不好方面进行阐述。

　　在第一轮测试开始之前我的准备工作是要导入测试用例，当时导入的时候，忘了建立一个这个版本的目录，导致导入的用例都和以前的用例一起了，很不好管理，最后只有删除了之前的目录重新建立这个版本的目录，重新导入所有的用例，这样我自己也就浪费了一上午的时间，终于可以进行第一轮测试了，但是当时只顾着测试，没有把大概的功能都过一遍，进行冒烟测试。结果在测试的时候，有很多问题，如果这样把所有的问题都提上去，工作量很大，开发修改这些问题，再来基线时间也就会更大，后来在组长和成员之间讨论之后，就把今天做为冒烟测试，不算测试时间，把所有的功能都过一遍，发现的问题记录下来，然后给开发晚上修改，第二天更新一个补丁，更新完补丁之后，我们继续第一轮测试，周末加了一天班，加上工作日一共测试了4天，有些测试的比较快的同学只测试了3天，我每次测试的时间要多于别的同学，我的速度要提高，第一轮测试在我们加班中结束了，第一轮结束之后，总共发现问题175个，问题还是比较多，比较严重的情况就是有些开发人员不看需求，自己想怎么开发就怎么开发出来的，因为这个是优化，开发人员老说现网就是这样的，其实需求已经变了，更让人生气的是，产品经理最后妥协了，就按照开发说的那样实现了，有些需求也不实现了。结束之后，还要写轮次测试报告，这次我写的时候，居然没有把其它成员的测试时间一起写进来，导致后来要出上线报告的时候，时间就不好写了。

　　结束了第一轮测试，过了几天迎来了第二轮测试，时间只有3天，而工作量不会亚于第一轮测试，第二轮测试主要是问题回归，浏览器兼容性测试，手机兼容性测试，主要功能流程测试，只有临时加人力，又加了两个同事，主要帮我们进行手机兼容性测试，两位同事用手机测试了两天，发现了很多手机上兼容性不是很好的问题，也有性能方面的问题，我主要第一天进行回归测试，加了两天班主要进行pc上面的浏览器兼容性测试，最后我还是用了4天才完成第二轮测试，当第一轮问题太多的情况下，第二轮测试时间不会少于第一轮测试，我们总共发现了178个问题，这里我用出现了一个错误，当时有同事提问题单的时候，提到项目名称不一样的下面去了，导致统计的数目出错，我当时应该用项目版本号再统计 一次据不会错了。

　　这么多问题在开发同事的夜以继日的工作中，修改的差不多了，就进行了第三轮基线，这个时候产品经理就急着要上线了，因为已经到基地要上线的时间了，而问题还是很多的，这个时候QA也催着要上线报告，想想我们都还没有测试完成，就要测试报告，这个报告要怎么出，我们迷茫了，就算出，我们也只能出一个结论，问题很多，测试不通过，建议不上线，而QA不要这样的报告，要出测试通过的报告。上面的领导也开始出了两个方案：第一：按时上线，这样的风险还是比较大的，如果被基地发现了问题，是要扣分的;第二：申请延期，那么这样错过了考核时间，也是要扣分的，很难有两全其美的，最后还是开发人员过了一下bug，觉得影响不大的就固定了，下一个版本优化，影响比较大的就马上修改了，就这样决定晚上10点多的时候，上灰度验证，如果问题不是很大，就第二天走紧急上线，灰度验证完了，还是存在12个问题，这时已经是凌晨1点多了，大家都不想再测试下去了，然后就回家了，第二天下午继续上班，开发修改了几个比较严重的问题，又打了一个补丁包，更新到了灰度环境，等我验证完之后，还是有11个问题存在，最后这11个问题都放到下一几个版本解决。出了灰度验收报告，上线申请之后，这项目也就这样上生产线了。

　　总结几点：

　　一、在测试准备之前，没有做好很好的准备

　　二、在测试过程和结束之后，没有很好的全局观，总是落下其它同事的一些数据，没有整合到一起。

　　三、没有统计好要的数据，犯下很低级的错误

　　四、主动，积极方面还有所欠缺。

　　五、当和产品经理或开发沟通的一些结果，没有很红的传达给其它组员，导致信息流失。

　　六、讨论的一些问题，没有及时记录下来

　　本文出自 “走在测试的道路上” 博客，请务必保留此出处http://testing2012.blog.51cto.com/4887161/1076015