软件测试之数据库设计中的敏捷方法[2]

关键字：数据库设计 敏捷方法

　　3.4数据库包含计划和测试数据

　　当提到数据库的时候，我们并不仅仅指数据库计划，而且还包括相当规模的数据。这些数据包括应用所需的标准数据，如全国所有的省份名，以及一些样本客户的样本数据。

　　数据的作用：

　　1、 易于测试

　　使用大量的自动化测试可以帮助稳定应用的发展。这样的测试在敏捷方法里是常用的方法。为了使这些测试有效进行，很理智的方法是在一个有样本测试数据的基础上工作，这样所有的测试可以在程序正式进行之前完成。

　　2、测试数据库的迁移

　　除了测试代码之外，样本测试数据允许我们测试数据库的迁移，当改变了数据库的计划后，我们还必须保证所有的计划变更也能够处理样本数据。

　　在大多数项目中这些样本数据是虚构的。然而在某些项目中人们使用实际数据作为例子。在这些情况下，数据从先前由自动化数据迁移代码的系统中提取出来。很明显不能马上迁移所有的数据，因为在早期迭代中数据库只有小部分建立起来。但是我们希望当应用和数据库发展时，改变迁移代码。这样不仅能够尽早解决迁移问题，也使行业专家易于处理这个正在开发的系统。因为有他们熟悉的数据，所以他们会指出可能给数据库和应用设计带来问题的地方。因此我们建议在项目的早期迭代中引入实际数据。

　　3.5所有的变化应该数据库重构

　　重构技术就是应用所有可控技术来改变现有的代码基础。与此类似我们定义了数据库重构也给数据库的改变提供了类似的控制。

　　数据库重构的不同之处在于它必须将三种不同的变化同时完成：

　　*** 改变数据库计划

　　*** 进行数据迁移

　　*** 改变数据库存取代码

　　于是当描述数据库重构时，我们必须描述变化的三个方面，并确保在应用另一个重构之前完成了这三种变化。

　　我们必须文档化不同的数据库重构，因此我们还不能详细描述他们。然而这里有几点需要指出：像代码重构一样，数据库重构非常微小。概念链一系列微小的变化，数据库和代码很相似。变化的三个属性使保持小的变化更加重要。

　　许多数据库重构，如增加一个字段，可以不必更新所有存取系统的代码来完成。但是如果在使用新计划之前并不了解它，该字段将会无用，因为新计划不知道其变化之处。许多变化，没有考虑整个系统计划，我们称之为破坏性变化，如将一个已经存在的空值列设置为非空。破坏性变化需要多加留心，留心的程度依赖于包含破坏性的程度。一个小破坏性的例子是将一个已经存在的空值列设置为非空，在这种情况下你可以蒙着头做。

　　而重构将考虑数据库中空值数据。开发人员将更新数据库映射代码，因此更新不会破坏其它人的代码;如果偶然会破坏，开发人员将在建立和使用测试时发现问题。

　　将一个经常使用的表分成两个是一种更复杂的破坏。在这种情况中提前让所有人知道变化到来很重要，这样他们可以有所准备。此外应该在一个更安全的时刻来实施变化。

　　这里面很重要的一点是选择适用于你做出的变化的过程。

　　3.6自动重构

　　在代码世界中许多语言能够实现自动重构。在计划变化和数据迁移过程中，这种自动化对于数据库也非常重要。因此每个数据库重构都可以通过编写SQL DDL(对于计划变化)和DML(对于数据迁移)来完成。这些变化不是通过手工实现，而是通过一些SQL语句来自动实现变化。

　　一旦完成代码，我们保存这些代码文件来产生数据库变化的完整的变化记录，作为数据库重构的结果。我们于是可以更新任何实例到最新的主数据库，通过运行在我们拷贝主数据库来产生更早的数据库实例的变化记录。

　　自动化变化的序列化是对于持续集成和迁移产品数据库的一个基本功能。

　　为了最后产品数据库我们并不在常规迭代周期中实施变化。我们在每一个发布之间建立完整的数据库重构变化日志。毫无疑问，这是一个巨大的变化，我们必须离线实施该变化。在实际应用之前先测试迁移计划绝对是明智之举。迄今为止，这项技术相当管用。通过将大变化分解为小的简单的变化，我们可以对产品数据进行大的变化，同时又不会给我们太多的麻烦。套用兵法中的一句话，就是“化整为零”。

　　除了自动化向前的变化，我们也要考虑重构时向后的变化。如果能够做到这样就可以回到以前的数据库状态。在我们的项目中并没有这样做，因为没有这个需求，但这同样是很重要的基本原则。

原文转自：http://www.ltesting.net