怎样才能做到测试用例没有缺陷

etheltim

最近公司版本上线后，出现的网上问题客户强烈要求我们测试组去反省，提出改进措施。原因现在客户考核我们的测试质量很严，出一个网上问题就要扣除质量分，所以公司不得不重视起来。
分析了一下网上问题，发现新需求的提出并没有考虑旧功能的业务。而且系统的业务功能多而复杂，功能之间的关联约束也很多。单从测试用例上去编写也无法确定这些影响范围，难免会有一两个旧功能被影响了，大部分功能是正常。
这样的话，从测试用例出发，如何去避免这种功能影响范围大小的问题。总会是写多或写少的。
大家来讨论一下，从测试的角度如何避免这种问题产生，有没好的建议或意见，多谢！

etheltim

没人顶一下啊,郁闷!

尘封的记忆

关注中。。。

[ 本帖最后由 尘封的记忆 于 2010-1-27 16:12 编辑 ]

欺负人

这个不叫测试用例缺陷.....确切的说,是你Design的Test Case没有把所有的测试点和需求都Cover到.

常规的办法,一般是需要Review Test case的,可以有一个Senior Test, 相关的Dev,还有PM等参加Review meeting.

欺负人

补充一下.你们那项目有Automation Test吗?

从你的描述,我冒似感觉到,在最新的Build出来之后,那些之前测试过的功能,你们自己认为之前测试过了,然后觉得在新的版本上肯定没问题,所以放弃测试那些旧功能...但是到客户那边使用的时候,却突然发现那些旧功能有问题,其实这个就是你们自己本身的责任了

也可以说,Automation的好处就是在这个地方,可以代替很多手工,繁琐,需要在多个版本进多次测试,从而避免手工测试产生的问题~~

etheltim

赞同楼上的说法，现在具体的做法；

1、将网上问题发起测试回溯，召集开发、PM一起分析原因，及讨论改进措施。具体措施就是发起自动化。这个自动化其实一直有做过，问题是对于自动化测试脚本的覆盖面如何做到覆盖全面一些，这个方法仍是模糊中。现在是全员发起整理认为关键的业务集成测试脚本，慢慢积累。。感觉对于业务功能得一个个梳理清楚才行，不能一下就来搞自动化那脚本根本就是治标不治本，白干。还有就是对系统方面的了解大家是各有差参。。。。

2、用例评审，这块只有说法，形式，但没有实际的做法，如果我是评审人员就对着需求文档，和测试用例，一个个地审核。重要的需求就开个会评审。有点费神，而且写用例的人思路会不太一样，如果是开会的大家还会发散思维的讨论一番……
---哪位有评审用例方面的经验，多多发表啊，多谢！

zcblinux

不好意思，做不到。

msnshow

没有缺陷是不可能的，只能把控风险

bestgo

楼主这种问题要从白盒的角度考虑，即路径覆盖上来衡量测试的覆盖范围。软件质量的好坏并不由测试人员单方面负责，编码，设计，需求这些方面的配合也是很重要的。所以，测试前让开发，需求等部门评审你们的测试用例，如果交付时出现遗漏，那么他们也得有一定责任。
至于自动化，就得看你们的项目及公司的财力，人力了，可以考虑部分自动化，一般刚开始做自动化不要考虑所有都用。

zhangting85

自动化测试见效是很慢的，
首先是编写自动化测试用例的脚本需要时间，
然后，编写好的测试脚本还需要经常维护，
此外，还需要考虑你们的自动化测试是只从UI角度来做呢，还是从代码阶段就开始做。

我觉得可以从两个角度来解决你们的这个问题：
第一是从系统测试的角度来看，那么，
首先规定新的需求提出来的时候，规定开发人员必须列出会影响到哪些老功能，这样就可以针对有影响的这些功能来编写测试用例了。假如开发人员也不知道会影响哪些老功能，那就需要全部回归所有主要功能。首先对你们所有的测试用例划分优先级，重要的功能，经常使用的功能，复杂的功能都需要每次都仔细地进行回归测试，影响不大的功能则简单地回归测试。这里进一步就可以把一些简单而稳定的功能的测试用例进行自动化。

另一个方面，我建议你们进行单元测试，并且对单元测试进行完全的自动化。这样，可以让在新功能的编码完成后，立即检测是否对老功能产生影响。如果有bug也可以在第一时间消灭掉，其对你们系统的质量提升地帮助程度，远远大于UI层次上的功能自动化。