软件测试的思考与总结..docVIP

软件测试的思考与总结上一个项目总算是结束了,但是做的很不好,有很多的问题,在客户那边发现了很多的BUG.BUG多的原因有很多,也有设计和编码的问题.但是归根结底是测试没有做好.因为测试本身就是要找到程序中的bug,并修改它,当我们测试完之后,就说明程序在我们这边已经通过了,我们认为程序没有潜在的bug了.而我们在提交给客户之后,客户发现了很多的bug,这说明什么,说明我们的能力不行,我们编码编的不好?不是,是我们的测试没有做好.测试是软件质量的最后保证,测试做好了,我们的程序就能经的起考验,测试做的不好,那软件的质量无从谈起.我现在感觉,只要给予足够长的对应时间,和测试时间,开始是再烂的代码,通过严格的测试,我们都能把它变成精品. ???? 现在结合上一个项目,来分析我们上个项目测试做的失败的原因. ???? 1.对于测试的目的和重要性认识不足. ???????? 测试的目的是为了证明软件中存在bug,并把他找出来,以提高质量.它犹如数学中的反证法.我的目的是为了证明这软件有毛病有问题才做测试,但是经过严格的测试之后,发现他没有什么问题,这样就间接的证明了软件的质量.但是现状呢,在我们公司,没有专门的测试人员,一般都是自己测自己担当的那部分代码.而且项目做长了大家都有种厌倦的感觉,自己编好代码之后,根本就不想在改了.在测试的时候,也是报着证明软件没有问题的态度来去测试的.这样一来,在测试过程中极力的维护自己的代码和程序,这样下来,测试结果可想而知,根本达不到预定的测试效果. ??????? 要想保证软件质量,就需要进行好的软件测试,而严格的软件测试的最基础保证就是,要对软件测试的目的和重要性有个充分的认识.在下期的项目过程中,我们要向项目组的所有成员灌输软件测试的重要性,让他们对软件测试有个正确的认识. ????? 2. 测试用例写的不好 ???????? 现在来看,我们在做软件测试的时候,写的测试用例根本就比较白痴,也就是说我们写出的测试用例大都是不能发现问题的.在测试用例的制作过程中,我们有很多问题,而这些问题的类型是不一样的,现分别说明. ??????? a. 要说写测试用例的话,首先还是要谈,写测试用例的目的,知道目的之后,我们才能写出有效的测试用例.在这一年多的软件开发过程中,我发现大多数人,包括我自己在内,都没有真正的明确写测试用例的真正用意.或者说由于现实的所迫,加上我们自己的能力有限.曲解了写测试用例的目的.写测试用例的目的就是为了测试能严格的被执行,不会出现本来想到的测试点被遗忘.且让不同层次的人对同一产品进行测试,能出现同样的效果.而且有了测试用例之后,让我们的回归测试更方便和精确.但是可惜很多人都没有意识到这点,或者说做到这一点.一个经验丰富的人,写出的测试用例的命中率是很高的.也就是说,他写出的测试用例并不一定很多,但是个个一针见血,直指要害.现在呢,公司和客户对每千行代码的测试用例数有严格的规定,大家为了达到这个目的而写了很多无效的测试用例,而一针见血的测试用例却还很少.而且大家通过无效的或者重复的测试用例的堆积,使自己的测试用例数达到了公司的要求之后.就不再费心思考虑有效的测试用例了.大家在写测试用例的时候想的是我如何才能使自己的测试用例够数,而不是如何设计测试用例来测出更多的BUG.这样就不自觉的背离了写测试用例的初衷. ?????? 在下期的项目中,不仅要求测试用例的数量,更要要求测试用例的质量,而真正的要保证测试用例的质量,除了进行检查之外,更重要的是测试人员本身了.养成对测试用例的正确的看法,和测试的根本目的.还要测试人员有很强的责任心,在以前的项目中,我个人感觉,自己的责任心就不够. ?????? b. 测试用例写的不好,另一方面表现在,测试用例没有测到软件的所有的需求.也就是说在写测试用例的时候,没有能系统的考虑以前在设计阶段确定的需求.这里就要先讨论一下什么是bug,bug就是在软件中出现的不是我们以前在做需求的时候想要的结果.日方也经常叫做不具合.我们进行测试就是为了要找出bug,也就是找出不是我们预想得到的地方.而我们以什么为测试的凭判标准呢,当然是我们以前得到的软件需求,在写测试用例的时候,一定要保证测试用例体现了所有我们知道的软件需求.在我们现在的开发过程中,大多数需求是在基本设计书或者说是详细设计书里面记载的,但是要注意设计书里面并没有体现全部的需求.因为在开发过程中有需求的变更,正常的情况下他会体现在需求管理表中.还有一些是式样不明确的地方,我们需要通过QA List来给客户确认.以现在的情况来说,需求存在与式样书,需求管理表,和QA List中.我们只有在写测试用例的时候,把这些需求都写进去,这样测试用例才能有好的覆盖度. ????? c. 测试用例不好,还有一个方面是,