2. 测试用例写的不好
现在来看,我们在做软件测试的时候,写的测试用例根本就比较白痴,也就是说我们写出的测试用例大都是不能发现问题的.在测试用例的制作过程中,我们有很多问题,而这些问题的类型是不一样的,现分别说明.
A. 要说写测试用例的话,首先还是要谈,写测试用例的目的,知道目的之后,我们才能写出有效的测试用例.在这一年多的软件开发过程中,我发现大多数人,包括我自己在内,都没有真正的明确写测试用例的真正用意.或者说由于现实的所迫,加上我们自己的能力有限.曲解了写测试用例的目的.写测试用例的目的就是为了测试能严格的被执行,不会出现本来想到的测试点被遗忘.且让不同层次的人对同一产品进行测试,能出现同样的效果.而且有了测试用例之后,让我们的回归测试更方便和精确.但是可惜很多人都没有意识到这点,或者说做到这一点.一个经验丰富的人,写出的测试用例的命中率是很高的.也就是说,他写出的测试用例并不一定很多,但是个个一针见血,直指要害.现在呢,公司和客户对每千行代码的测试用例数有严格的规定,大家为了达到这个目的而写了很多无效的测试用例,而一针见血的测试用例却还很少.而且大家通过无效的或者重复的测试用例的堆积,使自己的测试用例数达到了公司的要求之后.就不再费心思考虑有效的测试用例了.大家在写测试用例的时候想的是我如何才能使自己的测试用例够数,而不是如何设计测试用例来测出更多的BUG.这样就不自觉的背离了写测试用例的初衷.
在下期的项目中,不仅要求测试用例的数量,更要要求测试用例的质量,而真正的要保证测试用例的质量,除了进行检查之外,更重要的是测试人员本身了.养成对测试用例的正确的看法,和测试的根本目的.还要测试人员有很强的责任心,在以前的项目中,我个人感觉,自己的责任心就不够.
B. 测试用例写的不好,另一方面表现在,测试用例没有测到软件的所有的需求.也就是说在写测试用例的时候,没有能系统的考虑以前在设计阶段确定的需求.这里就要先讨论一下什么是bug,bug就是在软件中出现的不是我们以前在做需求的时候想要的结果.日方也经常叫做不具合.我们进行测试就是为了要找出bug,也就是找出不是我们预想得到的地方.而我们以什么为测试的凭判标准呢,当然是我们以前得到的软件需求,在写测试用例的时候,一定要保证测试用例体现了所有我们知道的软件需求.在我们现在的开发过程中,大多数需求是在基本设计书或者说是详细设计书里面记载的,但是要注意设计书里面并没有体现全部的需求.因为在开发过程中有需求的变更,正常的情况下他会体现在需求管理表中.还有一些是式样不明确的地方,我们需要通过QA List来给客户确认.以现在的情况来说,需求存在与式样书,需求管理表,和QA List中.我们只有在写测试用例的时候,把这些需求都写进去,这样测试用例才能有好的覆盖度.
C. 测试用例不好,还有一个方面是,测试用例设计的简单,或者说,我们设计的测试用例中,操作非常简单.这样仅仅测试了系统最基本的功能.而在程序的健壮性上没有测到.这种情况一般会在各个操作之间的关联比较大的情况下更加明显.在上个项目中,有一些bug就是这样出来的.我们的测试用例相对简单,我们的测试也比较简单.我们测过之后,没有问题.发给客户之后,客户给我们返回了一大堆bug.为什么呢,因为客户在测试的时候,他们测试用例相对复杂,他们一个测试用例涉及的操作比较多.一般来说,单独的每个功能测试,都没有问题.但是没个功能重复多次的操作,或者先进行A操作,再进行B操作,再进行C操作,然后再进行A操作,这时候可能就会有问题,而这就是涉及到软件的健壮性了.记得以前在程序员杂志上看到过一篇文章,说是一个小伙在大学的时候,发现了微软的几个bug,毕业后就被微软亚洲研究院给录用了.他是对软件进行几乎破坏性的操作,同样一个操作,操作一遍没有问题,5遍10遍也没有问题,但是在15到20遍的时候就出问题了.我估计我们做出的东西很多地方用不到10遍就会出问题了.
D.测试用例中自己不确定或者不放心的地方,一定要多做一些测试用例.正如成功学上说的我是我认为的我一样.当你感觉程序的某个地方有问题的时候,一般来说它确实有问题.这些地方一定不要放过,因为这就是虫子的小窝,你只要对其进行测试,肯定有收获的.