技术开发 频道

DM数据库版本驱动测试

  【IT168 文档】有一句谚语说:世界上唯一永恒的东西就是改变。对于一个大型软件项目的开发,其开发周期通常相当的长,在软件项目基本成型之后,大规模的测试工作也随之展开,在发现了一堆缺陷之后,伴随而来的就是缺陷的修正和版本的不断变更,面对着版本的不断变更,也给测试人员带来了很多令人头疼的烦恼。因为每个改变都可能产生新的缺陷,找到新缺陷的唯一的方法就是使用回归测试,回归测试可以完整的重复先前的测试过程并与得到的结论进行比较,以便找到不同的地方。

  但是日常版本的发布是一件经常性的工作,修改了一定数量的缺陷后可能就会发布一个测试版本,增加了某一个新功能也可能会发布一个测试版本,那么面对频繁发布的版本,测试部门如何来应对呢?

  首先,我们必须接受一个事实,那就是我们不可能花费大把的人力来对每个版本都进行回归测试,因为也许你还没对这个版本完成回归测试,下一个版本就过来了。这就意味着我们必须在有限的时间内对新发布的测试版本进行快速而有效的测试。

  当一个软件开发基本完成以后,新版本的发布通常只是一些bug的修改或者子功能的增加,这个时候测试用例也应该是比较充分了,那么我们可以选取一个版本作为基准版本,在基准版本上进行全面的测试,记录下测试结果。下一个版本发布的时候,则可以根据代码修改记录,对修改的代码进行审查,评审修改代码的影响范围,其影响的测试用例,然后只需针对其影响的范围来进行测试,那么我们就可以认为这是在基准版的基础上对新版本进行的一次有效的测试。

  在达梦数据库日常版本的测试过程中,我们正是采用了上面这样一种测试方法,我们暂时称之为版本驱动测试,也就是通过对新版本同老版本的代码变更,分析其影响范围,对影响的测试用例进行测试的一种方法。具体执行流程如图1.1所示。白箱测试部从开发部取得最新版本的源代码,由专人分析新版本和上一版本代码的异同点,统计出修改的函数有哪些,并评估这些影响的功能有哪些。接下来,由黑箱测试部和白箱测试部,根据影响的功能,制定新版本测试计划,确定涉及到哪些测试用例,是否需要新增或修改现有测试用例,并将这些测试任务分配给相应人员,明确测试任务开始和结束时间以及形成的产物。测试完成之后,根据测试报告总结新版本测试是否充分,是否引入了新的缺陷以及有哪些遗留缺陷未解决。

  为了防止版本驱动测试中可能存在的测试不充分的问题,定期对新发布的版本进行一次全面的测试,一般定位对季度版进行测试。

  通过使用版本驱动测试的方法,极大的提高了测试部门的工作效率,面对不断更新的版本,测试部门能够有效的应对这种变更,有针对性的制定相应测试计划,同时为了防止可能存在的测试不充分问题,通过对季度版进行全面测试来进行保证,从而保证了对外发布版本的质量,并将缺陷保证在可控的范围内

0
相关文章