如何改善没完没了的软件测试版本?

上一篇 / 下一篇  2012-07-09 19:16:28

     开发人员3天出1个新的软件版本?1天1个新的版本?甚至1天3个版本?测试人员不得不每天不停地更换软件版本,而这种情况会导致一些不利的后果:

  (1)过于频繁的软件测试版本发布,导致其中的管理和干扰时间太多,测试效率降低。测试人员无法集中精力开展有实际效果的测试活动,浪费测试人员大量的测试时间和精力;

  (2)由于测试版本间隔时间短,因此每个版本的测试周期很短,这样会导致测试覆盖率低下。开发人员在研究缺陷的时候,有时候就会很难确定该问题是在什么版本中引入的,是原来没有被发现的问题还是在修复其他缺陷的过程中新引入的?

  测试团队很难处理过于频繁的软件测试版本,检查和安装每个测试版本需要花费每个测试人员的测试时间。因此,处理过于频繁的测试版本应该得到每个测试团队的重视,本文将从下面几个策略来改善这样的境况:

  1)协商测试版本发布

  针对软件测试版本过于频繁的问题,一个有效的策略是制定版本进度计划,该计划中包括开发团队提交不同版本的计划时间、每个版本中新增功能模块列表、提交版本的要求、版本中解决的缺陷列表等。在版本进度计划中,除了提交版本的计划时间是相对固定之外,其他的内容需要根据实际的情况进行不断的更新,例如其中解决的缺陷列表。

  有了版本进度计划之后,测试人员可以更好的了解什么时候会出新的软件版本,测试的主要内容是什么,需要验证的缺陷有哪些?需要开展哪些相应的回归测试等,有利于测试效率的提升。

  2)开展冒烟测试

  冒烟测试的目标是检查软件版本的基本功能,假如该版本没有通过冒烟测试,则可以认为该版本不太稳定,不值得继续测试。

  通常情况下,当某个新版本提交测试时,要有一名测试人员运行冒烟测试。冒烟测试既可以是自动化的方式,也可以是手工方式,或者两者的结合。其他测试人员需要等到冒烟测试通过之后在投入该版本的测试。

  冒烟测试的测试用例通常覆盖了该软件版本的基本功能和核心功能,以及少量对这个版本特别重要的缺陷或者特别功能的临时测试。通常来说,冒烟测试的测试用例需要项目相关者的评审,例如:开发人员。

  冒烟测试既可以是开发团队执行,也可以由测试团队负责。由于冒烟测试的执行频度比较高,所以其中的测试用例最好是能够自动化,以提高测试的效率。

  3)制定测试准则

  假如既没有制定版本进度,也没有开展冒烟测试的规则,那么定义一些基本的测试准则也是避免没完没了软件测试版本的策略:

  (1)测试执行入口准则:假如测试团队可以制定测试执行入口准则,那么在软件团队提交测试版本之前必须满足某些条件,其中冒烟测试常常就是入口准则的重要组成部分;

  (2)测试挂起准则:可能导致测试执行挂起的状态或者事件,如测试中发现严重问题或者大量问题,以至于继续测试没有什么意义;

  (3)测试恢复准则:可以继续或者重新进行测试的状态或者事件,如严重问题已经解决,并且满足了入口准则(假如定义了);


TAG:

xuning556的个人空间 引用 删除 xuning556   /   2012-07-10 15:39:38
我所在的团队也是敏捷开发,确实经常遇到这种情况,很让测试人员头疼。这种状况下,由于测试时间太短,测试人员往往只能根据经验进行冒烟测试。在我们团队中,导致这种情况出现的主要原因有三:1)开发人员完成代码后,自己不但没有UT,甚至连随机的测试都不进行,就交给测试人员;2)需求频繁变更,尤其是在快要交版本前还在变;3)开发整体延误,占用了测试的时间。
 

评分:0

我来说两句

Open Toolbar