紧张的测试和质量强化终于过去了,新一期的开发马上又要开始了.及时的总结才能不断的进步!
测试总结:
1.“过程总结”:
整个的FT测试过程走的不是很充分,因为对系统的关联和对细节的操作都不是很熟悉,所以FT1,FT2基本上是在验证用例,而不是验证程序.效果可能不好,但对熟悉系统却有巨大(之所以巨大是因为这段时间我开始了正确的交流和思考)的作用.
之后的几轮测试有些掉以轻心,其中有几个用例都没有弄明白怎么回事,或者只是根据其他测试推断出不会有问题,也就是说没有做到实事求是.另外,有些测试的工作量有些大(如SAMPLE的DB连携和PDF转换的某些),导致我不能每个都测到,确实是一个问题.
最后在自由测试中自认为表现不错.我发现了4个BUG(其中一个影响十分大),还有其他的一些”怪现象”(要么是原系统的,要么是特殊操作引起).我觉得直到这时才放开了包袱,才真正有了工作的激情.我开始研究一些测试策略,看CHECKLIST,向其他测试人员了解相应模块的功能,操作,以及以往的BUG或隐患等.我觉得这时的学习才是真正主动的学习,不为任务,不为责任,完全以自己的探索愿望推进,不仅效率高而且效果也好.
2.”技术总结”:
管理:
测试任务的明确分工,有一次我就因为没有注意TastArrange而漏掉了上百个用例,因此一位同事提出的个人负责制很好,根本上克服了人的惰性,杜绝了问题出现混乱的可能;
服务器的专人维护/使用,看看桌面的混乱程度就知道我们的管理工作多不完善,权限的管理也很混乱,根本就没有发挥WIN2000以上版本OS的安全性能;
代码的修改和BUG的回归,后来提出代码修改(方案及实施细节)要征求相关人及PSM的同意并详细的体现在文档中(亡羊补牢为时未晚),BUG修正的确认和回归(集中体现在DR票的填写上)都要仔细;
技术:
CHECKLIST,应该加强(不管是开发还是测试人员)对CHECKLIST的了解和使用,并及时总结,更新它,它是一种财富的积累而决不是简单的制度化的东西;
测试策略,了解测试策略和相关的方法,技巧,强调边界检查的重要性;
自由测试,虽然自由测试是必不可少的环节(?),但要明确一个观点:”自由测试能够发现的BUG数应默认为0”,也即所有的BUG都该在UT,FT,ST等制度性测试中指摘出来,自由测试只能作为有益的补充而不是发现BUG的主要手段.它只是质量强化阶段采取的一种灵活方法之一(?)(这样说并没有否认自由测试由于其调动人的积极性而在测试阶段产生的巨大作用).
复用,这个问题我一直没有处理好.用例在本机的不同OS及不同的SERVER上怎样有效的复用:如果再增加测试环境(的组合),我的工作量会不会几何级数的增加?别人是怎样处理的?
跳跃思维(BT),不能光照用例跑完就草草了事,要思考,用例组合是否覆盖得全面?现象之间有没有隐含什么?极端的情况(这才考验BT呀)都考虑了吗?结合开发的细节,那些地方会暴露问题?BT和思维方式有关,要尝试去把握灵感.
还有一点建议:可以尝试在开发时就写测试用例,也就是”测试驱动”的模式.也许会有代价,但是相比目前的状况,风险会小一些,改进的工作量也会小一些(?)(参考其他项目组的经验).
本文地址：http://com.8s8s.com/it/it35423.htm