努力工作,快乐生活

回归测试有感

上一篇 / 下一篇  2007-07-04 23:33:17

最近一直在进行回归测试,说到回归当然要先说一下定义,回归测试:回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。从上面可以看出来,回归测试应该涉及到两方面的内容.1.缺陷是已经进行修复.2.是否对别的功能的造成影响.我觉得其实应该还包括一种情况.就是有可能你修改的代码即解决了原来的问题.也对没有对其他功能造成影响.但是有可能修改出来的代码本身又存在问题.就是引入了新的问题.但不管怎么说,就是保证修改后模块应该是稳定和正确的.但是最近的回归测试产生了很多的想法,我工作了一年多了.也回归了不少问题.有时候经常是辛辛苦苦的花了好久搭起来的环境就为了回归一张问题,最后一般会发现回归是通过的.且也没有发现新的问题,如果以结果来看的话,这除了心理塌实了一点的话,对项目好象没有产生什么效益.所以,有时候在想,如果我们每一次花大量的时间回归都没有产出,那我们这种付出是否值得呢,是不是每一张问题都需要进行回归呢?而是我们可以选择性的性回归呢????还是我们回归的方式有问题呢?我们回归的时候是否可以不按照问题出现的步骤进行操作呢?我想答案应该是肯定的.,我想我们是可以选择性的回归.对于比较简单的修改,应该可以相信开发修改是没有问题的.一般出现问题相同的操作,开发也是验证过了。所以我们可以想想从另外的一些方面去进行验证.在某一种情况下,我们是否应该要相信开发呢..


TAG:

调皮精灵 引用 删除 调皮精灵   /   2007-07-09 21:58:48
谢谢winfood 的指导,非常感谢:)
答复testxxh ,我们的回归测试是完全手工的。所以我才觉得很浪费时间,又没有产出。。
紫雾心朦 引用 删除 testxxh   /   2007-07-08 14:26:38
问一下,你们的回归测试是纯手工测试?还是与自动化测试相接合的回归测试呢??
Victor's Testing Career 引用 删除 winfood   /   2007-07-06 11:47:36
既便如此,从测试角度也不应该完全依靠开发人员的测试结果。我倒觉得既然开发人员的工作质量很高,你可以以此为依据来调整回归测试时候的测试范围和优先级。
比如,产品或者系统中最重要的几个功能(事关产品成败,无论如何不能出错的那些),应该保证回归测到。而不是因为开发人员的工作质量而忽略测试;
至于其他的功能,就视情况而定了。回归测试的时间、重要程度以及开发人员的工作质量都可以作为是否测试的依据;

每个项目的实际情况不同(测试规模、回归测试时间)等等,作上面的决定时会不尽相同。
还有一点就是,如果要回归测试的对象功能简单。何不开发简单的测试工具来代劳呢,这样可以避免繁琐的操作,时间也容易控制。你们的测试重点就可以轻松转移了,反正回归测试产出比较低。
调皮精灵 引用 删除 调皮精灵   /   2007-07-06 00:51:47
呵呵,其实我也同意你所说的--尽量不要把测试建立在对开发团队的信任上.但是如果是回归的问题单且功能简单,开发人员如果回归不通过是要受重罚的(所以他们一般自己也是经过了测试的.)那在基于这种情况下,我们是否可以相信开发人员呢?反正我看到我们的回归产出几乎是没有的。。。
Victor's Testing Career 引用 删除 winfood   /   2007-07-05 23:52:34
回归测试的选择性应该体现为回归测试时使用的Test Case集合以及测试优先级。
而划分测试用例集合以及优先级的一个基础就是对代码改动影响范围的跟踪。理论上,如果Tracability作的足够好,代码改动对功能的影响是可以分析出来的。这样就可以判断出哪些功能受到的影响大,而这些受到较大影响的功能中最重要的功能是回归测试里面的优先级最高的。
尽量不要把测试建立在对开发团队的信任上,这样容易主观。
 

评分:0

我来说两句

Open Toolbar