51Testing软件测试论坛

标题: 静态案例设计与动态案例设计 [打印本页]

作者: hobli    时间: 2007-5-17 21:44
标题: 静态案例设计与动态案例设计
在传统的软件开发周期中,测试员反馈软件的bug,再用已经完成的测试案例,针对修复的软件进行验证。在这种测试流程中,测试案例的设计是固定的,在软件验证过程中,我们期望error counter 逐渐减少,甚至为零。但是,这种案例设计的弱点,就是这些固定的案例,只能验证发现的具体问题是否改正,, 一般来说,我们在某个功能发现了问题,这个功能就有可能有更多的问题。使用固定的案例,在regression test 过程中,测试的涵盖范围已经缩小了(如果开发员为了项目进度,只针对发现问题的特定案例,来修改程序,那么,我们用同样的案例来检验这个错误,其实已经是无效的了。)

这个问题,我们可以用“动态案例”设计来解决:当测试发现软件的错误后,我们应该针对发现的问题,设计更多的案例,用既有的案例,加上新设计的案例,针对开发员的修复版本,在进行验证,就不会出现如上所说的问题了。当然,这个方法,也有它的弱点,测试的工作量会变大,在一定程度上,也会增加测试成本和测试周期。由于增加测试案例是基于既有案例的,这种工作量一般不会太大,相较减小测试覆盖率而增加的风险,我们这么做还是值得的。
作者: hapliu    时间: 2007-5-19 09:46
标题: 您说的是系统测试吧
如果是系统测试的话,发现问题后由开发人员进行修改,如果依然有此错误继续修改,如果此错误解决的话,要从新全面的测试,因为这个功能的缺陷使很多相关的错误隐藏,当把此错误修改后这些错误就会显露出来,要进行重新的详细的测试,而您说的正是功能的错误,正好符合这种情况/
      只测试错误的地方,。发现问题解决就提交PASS,是严重得不负责的做法,很可能影响到软件的质量和用户的投诉,软件的性能,及公司的形象
作者: hobli    时间: 2007-5-20 21:24
首先,谢谢您的关注!

我所说的问题,并不局限于系统测试。还有一个问题我要澄清一下,就是说我强调的是“动态的案例设计”,也就是说,如果发现了问题,提交后得到修复的新版本,测试员应该不仅用所有执行过的已有的案例来测试(也就是说,不仅测试发现错误的地方,而是这是您所说的全面测试),而且应该针对所犯错误相应的增加新的案例。即所谓“动态”设计。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2