在新公司负责的第一个项目,从杂乱总结一下,有些是自己的问题,有些是别人的问题:
- 需求分析:由于项目来源自原有项目的整合,所以从一开始,便只有一个大概的想法,要做成一个怎么样的东西,所以只有大致的需求,对于功能上的很多细节,都是边做边确定下来的,这个给测试用例的设计的带来了麻烦,很多东西事不确定的。需要很多时间去沟通
- 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, 拿些真正的数据来参考就可以了。很多其他需要测试的场景也是这样,光凭自己想象是没有用的,或者说是徒劳的