在新公司负责的第一个项目，从杂乱总结一下，有些是自己的问题，有些是别人的问题：
- 需求分析：由于项目来源自原有项目的整合，所以从一开始，便只有一个大概的想法，要做成一个怎么样的东西，所以只有大致的需求，对于功能上的很多细节，都是边做边确定下来的，这个给测试用例的设计的带来了麻烦，很多东西事不确定的。需要很多时间去沟通
- Test Case Review：做是做了，但是自己感觉，用例设计的数量依然不够多，别人也未能给出更多的补充。Rview的时候，应该是要找个人专门记录的，忘记了。
- 测试验证：由于时间比较紧，测试验证的时候，并没有刻意去验证DB，更多的是从UI上去验证，下次要多关注后台包括DB,Log.
- Bug: 感觉基本上都找出来了。大部分也更新到Test Case中去了，但是由于数量较多，还有一些遗漏。
- 回归测试：到后期，时间比较紧的时候，果断不采取执行全部Case的策略，采取bug优先的测试的策略，并且让其它有经验的QA去做随即测试，效果不错。回归测试的策略果然很重要
- 项目后期：由于bug也发现了好多，开发过程中额外的改动也多，所以在项目的后期，其实是有必要再做一次Test Case Review的，但是由于时间问题并没有去做。如果加上这个过程，那么质量就绝对有保证了。
- 与Developer：感觉大部分的Developer心中想的始终是，尽早把事情做完，并且有一定的侥幸心理。基本上没有那种追求完美的想法。有时候碰到问题，都先会想，这个不是自己的问题，而是其它系统，或者是别人的问题。所以，以后跟他们相处，要求要严格一点，有时候要鞭策他们改bug，指引他们前进，不能依靠他们自己的自觉性。
- 测试数据：采用什么样的数据进行测试？我想首先要考虑的是以后程序真正被使用时，会有怎么样的数据输入，最好可以从将来的使用者手中拿到数据样本，这样测试的时候就能做到有针对性。比如说Email地址，用户的First Name， Last name, 拿些真正的数据来参考就可以了。很多其他需要测试的场景也是这样，光凭自己想象是没有用的，或者说是徒劳的