1、 易于测试
使用大量的自动化测试可以帮助稳定应用的发展。这样的测试在敏捷方法里是常用的方法。为了使这些测试有效进行，很理智的方法是在一个有样本测试数据的基础上工作，这样所有的测试可以在程序正式进行之前完成。
2、测试数据库的迁移
除了测试代码之外，样本测试数据允许我们测试数据库的迁移，当改变了数据库的计划后，我们还必须保证所有的计划变更也能够处理样本数据。
在大多数项目中这些样本数据是虚构的。然而在某些项目中人们使用实际数据作为例子。在这些情况下，数据从先前由自动化数据迁移代码的系统中提取出来。很明显不能马上迁移所有的数据，因为在早期迭代中数据库只有小部分建立起来。但是我们希望当应用和数据库发展时，改变迁移代码。这样不仅能够尽早解决迁移问题，也使行业专家易于处理这个正在开发的系统。因为有他们熟悉的数据，所以他们会指出可能给数据库和应用设计带来问题的地方。因此我们建议在项目的早期迭代中引入实际数据。
3.5所有的变化应该数据库重构
重构技术就是应用所有可控技术来改变现有的代码基础。与此类似我们定义了数据库重构也给数据库的改变提供了类似的控制。
数据库重构的不同之处在于它必须将三种不同的变化同时完成：
* 改变数据库计划
* 进行数据迁移
* 改变数据库存取代码
于是当描述数据库重构时，我们必须描述变化的三个方面，并确保在应用另一个重构之前完成了这三种变化。
我们必须文档化不同的数据库重构，因此我们还不能详细描述他们。然而这里有几点需要指出：像代码重构一样，数据库重构非常微小。概念链一系列微小的变化，数据库和代码很相似。变化的三个属性使保持小的变化更加重要。
许多数据库重构，如增加一个字段，可以不必更新所有存取系统的代码来完成。但是如果在使用新计划之前并不了解它，该字段将会无用，因为新计划不知道其变化之处。许多变化，没有考虑整个系统计划，我们称之为破坏性变化，如将一个已经存在的空值列设置为非空。破坏性变化需要多加留心，留心的程度依赖于包含破坏性的程度。一个小破坏性的例子是将一个已经存在的空值列设置为非空，在这种情况下你可以蒙着头做。
而重构将考虑数据库中空值数据。开发人员将更新数据库映射代码，因此更新不会破坏其它人的代码；如果偶然会破坏，开发人员将在建立和使用测试时发现问题。
将一个经常使用的表分成两个是一种更复杂的破坏。在这种情况中提前让所有人知道变化到来很重要，这样他们可以有所准备。此外应该在一个更安全的时刻来实施变化。
这里面很重要的一点是选择适用于你做出的变化的过程。
3.6自动重构
在代码世界中许多语言能够实现自动重构。在计划变化和数据迁移过程中，这种自动化对于数据库也非常重要。因此每个数据库重构都可以通过编写SQL DDL（对于计划变化）和DML（对于数据迁移）来完成。这些变化不是通过手工实现，而是通过一些SQL语句来自动实现变化。
一旦完成代码，我们保存这些代码文件来产生数据库变化的完整的变化记录，作为数据库重构的结果。我们于是可以更新任何实例到最新的主数据库，通过运行在我们拷贝主数据库来产生更早的数据库实例的变化记录。
自动化变化的序列化是对于持续集成和迁移产品数据库的一个基本功能。
为了最后产品数据库我们并不在常规迭代周期中实施变化。我们在每一个发布之间建立完整的数据库重构变化日志。毫无疑问，这是一个巨大的变化，我们必须离线实施该变化。在实际应用之前先测试迁移计划绝对是明智之举。迄今为止，这项技术相当管用。通过将大变化分解为小的简单的变化，我们可以对产品数据进行大的变化，同时又不会给我们太多的麻烦。套用兵法中的一句话，就是“化整为零”。
除了自动化向前的变化，我们也要考虑重构时向后的变化。如果能够做到这样就可以回到以前的数据库状态。在我们的项目中并没有这样做，因为没有这个需求，但这同样是很重要的基本原则。
3.7自动地更新所有开发人员的数据库
人们变化和更新主数据库，但是如何发现主数据库已经发生变化？在传统的持续集成有源代码的环境中，开发人员在提交变化之前先更新主数据库。这样他们就可以在提交变化给共享主数据库之前，解决他们自己的机器上的问题。
每次主数据库发生改变时，我们都要更新开发人员的数据库。当主数据库发生变化时，我们自动化更新所有项目成员的数据库。相同的重构代码更新主数据库上的同时，自动更新成员数据库。也许有人认为在开发人员不知情的情况下，更新开发人员数据库会产生很多问题，但在实践中我们没发现什么问题。当然，这只在人们联网时管用。所以当开发人员离线时，必须尽快与主数据库重新保持同步。
3.8清晰地分离所有的数据库获取代码
为了理解数据库重构的结果，了解应用程序如何使用数据库也非常重要。如果SQL语句分布在代码基础周围，则很难这样去做。因此一个清晰的数据库获取层很重要，它用来显示数据库如何被使用，在哪里被使用。
清晰的数据库层有很多好处。它减少了开发人员操纵数据库时需要使用SQL知识的地方，这样使对SQL语句不太熟悉的开发人员更易开发。对于DBA来说，给他提供了清晰的代码，可以清楚地了解数据库将如何使用。这也帮助准备索引、数据库优化，优化SQL语句，使DBA更好地理解数据库如何被使用。
4 变化法则
如同任何实践一样，这些原则必须根据你特殊的环境变化。没有一成不变的项目，我们必须要应对变化。
4.1保持多个数据库在一个系统中
简单项目也许只需要一个主数据库。但是复杂项目需要有多个数据库，即数据库系。如果在投入生产之前数据库必须分支，那么我们可以创建新的数据库系。数据库系类似于代码的分支，需要不同测试数据集来进行测试。
当开发人员从主数据库中获取了一份拷贝，必须注册他们在修改哪个数据库系。当DBA更新主数据库某个数据库系时，同时更新了所有注册这个数据库系的开发人员的数据库。
4.2不需要专职的DBA
所有这些听上去好像需要大量的工作，但它并不需要大量的人力资源。在最大的项目中，我们有30个开发人员，项目组规模100人（包括质量评价、分析人员和管理人员），我们大概有100多个不同系列的产品分布在各工作站上。但所有这些工作只需要一个专职DBA，只有两个编程人员业余帮忙。
在小项目中甚至不需要专职DBA。当我们将这些技巧用于更小的项目--12人左右的小项目时，发现该项目不需要一个专职的DBA。与此相反，我们依靠两个对数据库感兴趣的开发人员业余处理DBA任务。
这是自动化的功劳。如果对每项任务进行自动化处理，就可以用更少的人来完成更多的工作。
5辅助工具
文章来源于领测软件测试网 https://www.ltesting.net/
