数据库测试不可或缺_光环大数据培训

1、 光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/数据库测试不可或缺数据库测试不可或缺_ _光环大数据培训光环大数据培训光环大数据培训机构，有许多关于测试驱动开发（Test-Driven Development， 缩写为 TDD）的书籍。那些书通常关注的是将测试应用于工作单元（units of work）。对于工作单元的理解有许多种不同的方式，通常它表示一个类 （class）。正如那些书中所言：编写许多测试，以使那些测试都能通过的方式 创建代码。应模拟所有的外部资源，以便你可以只测试这个单元。这很酷，但不幸的是所有的测试在此刻停止了。因为通常会有些没被测到的查 询（手写的或者是由某些 ORM 工具生成的）。有些程序员使用集成测试来测试 那些查询连接到一个真实的数据库并执行真实的查询来进行测试。这种做 法通常意味着在测试快乐路径（happy path）我已经有了 ORM 工具，所以 它会搞定每件事，我无须费心。数据库通常是一家公司最有价值的资产。应用程序可以一遍一遍重写。旧的应 用程序扔出去，新的应用程序装进来。但是更换应用程序时

2、没人会丢弃满载数 据的数据库。而是将数据库小心翼翼地迁移过去。位于多个系统中的许多不同的应用程序会在同一时刻使用同一数据库。这就是为什么拥有充满约束的良好 数据库模型是如此重要、以及为什么应谨慎对待数据库的原因。你真的不想破 坏数据一致性（consistency），因为这会使你的公司付出高昂的代价。本文是关于经常被遗忘的数据库测试的。使用真实数据进行集成测试。实际上， 它与你所使用的数据库引擎的类型无关紧要。你可以使用 PostgreSQL、MySQL、Oracle，或者甚至使用那些有趣的 noSQL 数据库，例如 MongoDB。以下规则可适用于各种数据库和各类应用程序。也许不是全部，例如 noSQL 数据库就无法强制实施数据完整性（integrity）。光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/你的应用程序通常是由许多不同的部件组成的。其中有一些代码，一些配置文件，一些 SQL 查询，一些外部系统。测试一个应 用程序意味着分别测试每个部件（因为只有这样才更容易找出 bug）、以及测 试所有部件是如何协作的。数据库就是这

3、些部件的其中之一，而且你应该彻底 测试它。不测试数据库不测试数据库这是首要的、最可怕的错误。根本不测试数据库。你编写了一些使用数据库的 代码。你甚至使用一些模拟数据库连接为这些类创建了单元测试。集成测试怎么样？集成测试应在生产环境下对应用程序进行测试。集成测试背 后的唯一想法是，确保应用程序部署到生产环境后可以正常工作。如果你不在 生产数据库上测试应用程序，那么你实际上不并不知道应用程序能否工作。你 的模拟连接让你可以发送尚未检查以及没有检查的任何查询。模拟连接只返回 你所需的数据。不创建集成测试意味着你实际上没有测试你的应用程序。不测试数据库不测试数据库 SchemaSchema（模式（模式/ /架构）架构）光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/我所观察过的大多数团队拥有某种形式的集成测试。通常进行快乐路径测试：有某个 ORM 工具，我们持久化对象，ORM 工具会完成那些工作，真是太酷了， 我无须费心。我从未见过一支对数据库 schema（模式/架构）进行测试的团队。想象一下，由于某些针对产品的查询很慢，因此你必须在

4、该数据库中创建某个索引。当下 次在新的客户环境中部署此应用程序时，你希望拥有该索引并确认该索引真的 就在那里。为什么不编写一个简单的测试来检查该索引的存在呢？除了索引，还有许多要测试的内容：主键（primary keys）外键（foreign keys）一些检查以确保“price”（价格）列不会有负值某些列的唯一性（uniqueness）你实际上不想拥有两个具有相同登录名的用户。不在生产环境下测试不在生产环境下测试当你开发某个应用程序时，你可以从种类繁多的数据库中进行选择。通常你会 从中选择那个最好的、那个被团队所熟知的、或者是由管理层所选定的（有时 使用一些奇怪的理由）。有时同一应用程序的多个部署会在同一时间使用不同 的数据库引擎。有时应用程序会为了能使用不同的数据库引擎进行准备，因此 购买此应用程序的客户就可以选择他想要的数据库。光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/数据库引擎的选择真的与进行产品测试无关。由于程序员的懒惰，因此他们希望他们的测试可以运行得飞快。他们不想为测试结果等太久。这也就是为什么许多团队使用某

5、些更快的内存数据库（例如 HSQLDB）的原因。由于那些内存数据库仅存储在 RAM（Random Access Memory，随机存取存储器）内存中，而且在操作时不接触任何硬盘驱动器，因 此它们的运行速度要快得多。还有一条常常被人遗忘的规则：测试应该使用与生产环境相同的数据库引擎。许多程序员会使用某个其他引擎。常见的解释很简单：“我们的数据库太慢了， 我们应该使用某个内存数据库引擎。”。这并不是个好主意。这样你测试的是 该其他引擎，而非你的生产环境中的那个，所以实际上你并没对你的应用程序 进行测试。我曾经遇到过这个问题。我们必须在成功连接数据库后通过设置 session 变量 来优化查询。那个应用程序在生产环境中只使用 Oracle 数据库。当设置此变量 以后，测试失败了。而且是所有的测试都失败了。原来是我不能在 HSQLDB 内存 数据库中设置此变量，因为它根本不存在。因此，我必须编写一段糟糕的代码： 在连接后，检查数据库引擎，并由此决定是否设置此变量。即使你没有任何与混合引擎有关的问题，请记住，当你测试其他非生产环境的 数据库引擎时，你恰恰根本没对你的应用程序进行测试。光环大数据光

6、环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/不准备好数据库就进行测试不准备好数据库就进行测试测试有一个通用的、明确定义的流程。 它非常简单：准备环境运行一个测试检查测试结果返回至第一点若尝试背道而驰，则你会被它所伤。你察觉在测试之后是没有整理（tidying）的么？这点非常重要：必须在测试前准备环境，而非测试之后。你无法确保测试将能 够清理一切。应用程序可能因为某个错误、网络连接失败而退出，或者应用程 序可能崩溃（例如，由于内存不足异常）。该测试如何终止并不重要，真正重 要的是该测试运行在为每个测试所准备的相同环境中。我曾犯过这个错误：有大量的集成测试，它们会在每次测试后清理所有更改。 许多程序员正使用调试器来运行这些测试，并且当发现 bug 后会在中间停止测 试。任何在该测试之后运行的测试会得到不可预知的且随机的结果。因为它正 运行在已被前一测试所改变的环境中，而且没有为其清理整个环境。光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/准备了数据库却不对其检查就进行测试准备了数据

7、库却不对其检查就进行测试在前面的部分中我提到许多有关准备数据库的内容。我还想补充一点。准备数据库是不够的。当你通过清理某些表、加载配件等等准备好数据库时还剩 下一件事情要做。在准备完毕后，要检查数据库状态。你真正需要确保的是你已将一切准备妥当。当出现由于 bug 所导致的某些数据 留下来且未能清理时，这些工作就可以节省你的时间。这应该是测试前数据库准备的一部分。不测试创建脚本不测试创建脚本每个应用程序都需要某种形式的安装过程。而对于你部署数据库而言，永远是 第一次。程序员往往会通过手工执行某些临时的数据定义语言（DDL，data definition language）查询来改变数据库。他们稍后并没有把那些语句写下来，或是忘记 了所做的改动。他们没有更新安装脚本。大多数团队不使用有版本控制的脚本 （例如，Ruby on Rails 中的 Migrations、或者是 Java 世界中的 Liquibase）。光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/对测试而言最好的方式是，在运行测试套件前重新创建数据库。你不必在每个测试开

8、始前都那么做。只在运行所有测试前运行一次就行了。是的，宁可事先谨慎有余，不要事后追悔莫及。不测试外键不测试外键外键是提供数据库一致性的基本途径之一。在良好的关系数据库 schema 中，你 应该拥有各种键。如果你没有的话，那么这可能表明你有一个真正的大问题。 然而，这取决于数据模型，但是通常缺乏外键是种非常糟糕设计的味道。测试外键很简单。只需在事先没有在引用表中添加适当的行的情况下，为某个 表添加一些行。你应该得到一个错误。然后，你应该从引用表中删除行，你可 能得到错误，或没有错误（这取决于该键的定义）。无论如何，你都应该检查一下预期行为。不测试默认值不测试默认值在良好的数据库设计中，你应该定义一些合理的默认值。通常这些默认值可能 是空（null）。即便这些空也应该进行测试。你不能假设，只有你的应用程序 将改变此数据库中的数据。/ 两个问题：光环大数据光环大数据-大数据培训知名品牌大数据培训知名品牌http:/ 光环大数据光环大数据 http:/如果某人想创建一个快速修复并使用临时 SQL 查询更新某些数据，该怎么办？ 如果有一天某人启动另一应用程序，它可以改变这些数据，而且新的应用程序将不使用你的 ORM 映射或你的 DAO（数据访问对象）类，又该怎么办？如果你拥有愚蠢的默认值、或是错误的默认值，那么你可能会破会数据，而且那可能比一个简单的应用程序 bug 更糟糕。不测试约束不测试约束在数据库中还有更多约束，不仅只有主键和外键约束。你可能拥有一些唯一的 （unique）或不为空的列。你可能约束某列只有很少的值集。你可能想确保价 格永远不会低于 0。良好的数据库 schema 应拥有许多约束。你也应该测试它们。如果你希望你的价 格列只能拥有正值，当你尝试向其中插入-1 美元时会发生些什么？为什么不测 试一下呢？你不能假设只有你的经过良好测试的应用程序将使用那些数据，而且这些检查 是为你防御这些 bug 的最后一道防线。为什么不测试它是否正常工作？多个测试可以更改同一数据库多个测试可以更改同一数据库光环大数据光环大数

《数据库测试不可或缺_光环大数据培训》由会员gua****an分享，可在线阅读，更多相关《数据库测试不可或缺_光环大数据培训》请在金锄头文库上搜索。