近一个月左右的时间里,我参加了某项目的测试工作。具体有:编写测试用例,实施单体测试(其实是功能性测试),实施强化测试。
测试结束后,出现了若干个Bug,分类一下,有如下几个原因:
对源代码没有很好的进行管理:2个。由于信息沟通不畅,该提交的css文件没有提交,导致画面表现和测试时不一致,被客户指责。
对本项目特有的作法不熟悉:1个。 客户方提供画面Demo为主页文件,约定俗成的规矩是:我们在他们的Demo文件基础上改动。而不遵守此点,被客户发现,被指责。
对式样理解不正确: 2个。
1个是因为没有理解客户需要在输出的Excel文件中,NUll为空白显示,如果为其他则用=''来表达。对此说明理解有误。导致没有用'xxx'来输出,而无论开发人员还是测试人员,都没有认识到这一点。
1个是对某模块的三种状态理解不正确。以为只有两种状态。事后仔细阅读详细设计文档也发现了这一点。
但是由于项目的历史积累很庞大,在很短的时间里阅读完毕详细设计文档存在困难。 如果有一个可以参考的地方,提供出完整的画面迁移图,也可以了解到该模块有几种状态。
测试人员不细心导致:N个。
比如:用例写明要求某项目的值大于零的时候,需要用红字显示。但测试者没有验证等于零的情况,结果等于零也是红色。当然被指责。不过,话说回来,也可以把Case写的细致一些,列出值等于零的情况。使得测试者无法躲避。
还有,测试用例中明明写着画面的Layout要和用户提供的Demo一致,但是测试人员根本没有进行比对。直接把画面拷贝贴上了事。这是很不好的习惯。
测试用例不够细致清晰:N个
比如:客户的设计文档中提到的 时间日期格式:yyyymmddhhmmss,其实他们想要的是24小时格式。而这一点在写Case之前,我们必须和客户确认好。而且要分别对0x点(比如5点) 和1x点(比如15点)的类型分别测试。又因为编码人员错误的采用的simpledateformat ,导致把12点若干分表示成了00点若干分。导致事后,我们把从0点到24点的各个时段全都测试了一遍。
从这一点上,也看出,等待最后测试把门的方式,实际上很容易造成遗漏,而且测试的代价也很大。从0点到24点的各个时段全都测试,这种方式如果在编码的时候,由编码人员自己实施的话,要轻松很多。当然jsp页面自动化测试很困难。
不过,做一个测试用的页面,把24小时的时间段在画面上都表示一下,恐怕早就会发现自己的问题。
用户的设计文档不完整:N个
客户的要求里面,有全称改略称的要求。虽然在页面初始化的时候,按下检索按钮的时候都正确。
但是在画面上进行各种编辑活动的时候, 却会再次变成全称,结果也导致客户指责。而实际上,这一点在客户的设计文档上完全没有。
此外,还有客户中途变更设计书,导致已经进行的测试用例没有了用处,还得重新进行测试之类。
而且,在强化阶段,还无意中发现了,
为了鼠标移动的时候,显示提示信息。在本该采取左连接的地方,错误地采取的等值连结。这是个非常严重的问题,
会导致客户的数据很多都无法抽取出来。而这本该在代码Review的时候就发现出来。
我想,是否对从数据库抽取数据这样的操作,在输出到页面之前,就要在DAO层次上进行严格测试。
综合来看:
从客户方角度,维护一个最新状态的,与源代码一致的设计文档十分重要。若非如此,很容易造成开发,测试实施的遗漏。
而另外,很多的问题,都可以早期发现,早期防止。比如:对维护项目而言,当客户对系统提出维护性开发需求的时候,
应当进行风险分析,详细记录分析过程:那些地方需要修改,会影响到那些地方等等。如果可能,具体到代码的原文件级别更为理想。
这样,当修改代码完毕后,方便项目经理或者Leader进行检查,探讨。事情推到测试级别后,代价就比较高昂。
当然,客户给定的工期较紧张,也导致我们无法很好的进行代码Review,对设计文档的QA等。
[@more@]
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/37160/viewspace-1033325/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/37160/viewspace-1033325/