近阶段测试工作小结：

近一个月左右的时间里，我参加了某项目的测试工作。具体有：编写测试用例，实施单体测试（其实是功能性测试），实施强化测试。

测试结束后，出现了若干个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/