|
|
现在结合上一个项目,来分析我们上个项目测试做的失败的原因.
1.对于测试的目的和重要性认识不足.
测试的目的是为了证明软件中存在bug,并把他找出来,以提高质量.它犹如数学中的反证法.我的目的是为了证明这软件有毛病有问题才做测试,但是经过严格的测试之后,发现他没有什么问题,这样就间接的证明了软件的质量.但是现状呢,在我们公司,没有专门的测试人员,一般都是自己测自己担当的那部分代码.而且项目做长了大家都有种厌倦的感觉,自己编好代码之后,根本就不想在改了.在测试的时候,也是报着证明软件没有问题的态度来去测试的.这样一来,在测试过程中极力的维护自己的代码和程序,这样下来,测试结果可想而知,根本达不到预定的测试效果.
要想保证软件质量,就需要进行好的软件测试,而严格的软件测试的最基础保证就是,要对软件测试的目的和重要性有个充分的认识.在下期的项目过程中,我们要向项目组的所有成员灌输软件测试的重要性,让他们对软件测试有个正确的认识.
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.测试用例中自己不确定或者不放心的地方,一定要多做一些测试用例.正如成功学上说的我是我认为的我一样.当你感觉程序的某个地方有问题的时候,一般来说它确实有问题.这些地方一定不要放过,因为这就是虫子的小窝,你只要对其进行测试,肯定有收获的.
3.再说一下测试执行的方面.
我个人感觉,如果测试用例制作的好坏,和担当人员的经验和能力有关系的话.执行测试时效果的好坏,主要决定于担当者的责任心和态度来说了.因为测试的时候,你只需要根据测试式样书上写的流程来测就好了.这个时候不需要再进行测试用力的设计了.在以前的项目中,可能有很多人,对测试不是很在乎,觉的测试就是走一个过场,我写出的测试用例和执行测试都是为了忽悠客户,而不真的是在提高产品质量.我以前就有这样的想法,以前觉得一个程序做的好坏,最主要的是在于代码的编写,后来又觉得设计非常的重要,而直到最近我才真正的意识到测试的重要性.其实对于在有限的时间中要做出一个好的产品,软件开发周期的各个阶段都是非常重要的.哪一环出了问题,都会对进度和软件的质量有挺大的影响.现在我甚至有这样的感觉,就是测试甚至比编码更重要,因为编码做的不好,还有测试来检查,而测试做的不好,那么就真的很难弥补他造成的恶劣影响了
其实,现在我们在测试过程中,做的不好,主要是态度不好.做任何事情都是态度决定一切.所以刘老大将软件是一种态度也是很有道理的.总结了这么多,希望在以后的项目中尽量的避免以上的各个问题.确实把测试做好,提高软件的质量,也提高我们自己的价值~
[ 本帖最后由 q260954617 于 2008-3-12 13:13 编辑 ] |
|
/1 
关于我们
发表于 2008-3-6 10:52:46
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主