注：这一个系列是我在看原版的The Art of Software Testing时的一些翻译，因为没有得到作者和出版社的同意，这只是我自己的练习。请不要把本文中的内容用于商业用途。

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 2nd Edition
作者：GLENFORD J. MYERS
Revised and updated by Tom Badgett and Todd M. Thomas with Corey Sandler

9.3.3.2 数据完整性
数据完整性测试是在你的数据库表中查找错误数据的过程。这个测试和你在测试商务层的时候进行的数据验证不同。数据验证主要是要找到在数据收集的时候有什么错误发生。数据完整性的检查是努力找到你存储数据过程中的错误。

很多因素会影响到你如何去存储数据。数据的类型和长度可能使得数据被截断或者损失精度。比如在日期和时间区域中，时区的问题就会发生。比方说，你存储时间基于客户端的本地时间，还是Web服务器，程序服务器还是RDBMS的本地时间？国际化和字符集可能也会影响到数据的完整性。比如，多字节的字符可能占去两倍的存储空间，另外他们也会导致查询时得到一些填充的无用数据。

你还应该调查一下你程序所使用到的查询/参考表格的数据准确性，比如消费税，邮编，还有时区信息。不只是你必须确保这些信息是对的，你还要保证他们能得到及时的更新。

9.3.3.3 容错和可恢复

如果你的电子商务站点依赖于RDBMS，那么这个系统必须一直开着保持运行。在这个方案中几乎没有可以停下来的时间。因此你必须测试你数据库系统的容错和可恢复性。

数据库操作的一个目标，通常来说就是把MTBF最大化和MTTR最小化。你应该在你电子商务站点的需求文档中找到标明的这些数值。你测试数据库系统的强壮程度的时候你的目标上就是要超过这些数值。

MTBF的最大化是依赖于你数据库的容错等级。你可能有一个可以让你在主系统发生问题时把主数据转移到一个新的数据库的容错转移结构。如果这样的话，你的顾客只是感觉到一个很短暂的服务停顿，但是系统还是可以用的。另外的方案就是你在你的程序中建立一个容错转移系统，当你的数据库当机的时候对系统的影响会很小。你的测试将会依赖于这个结构。

你还需要考虑数据库的恢复，这也相当重要。数据的恢复性测试的目的在于创造一个你无法恢复数据库系统的方案。在某些时候，你的数据库可能会崩溃，所以你必须有一个快速恢复它的步骤。恢复的计划，在开始需要包括一个对备份的验证。如果你不能在可恢复性测试时恢复数据库，他们你需要改变你的备份方案了。

-EOF-

Technorati Tags: Art of software testing, internet application test

注：这一个系列是我在看原版的The Art of Software Testing时的一些翻译，因为没有得到作者和出版社的同意，这只是我自己的练习。请不要把本文中的内容用于商业用途。

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 2nd Edition
作者：GLENFORD J. MYERS
Revised and updated by Tom Badgett and Todd M. Thomas with Corey Sandler

9.3.3 数据层的测试

一旦你的站点开始运行，你收集到的数据将会变得非常有价值。信用卡号码，支付信息，和用户资料是你开设你的电子商务站点时将会从用户哪里收集到的信息的一些例子。如果你丢失了这些数据，损失是非常惨重的，而且可能使你的业务变成残废。因此，你必须开发一个程序来保护你的数据存储系统。

测试你的数据层主要由测试你程序用来存储和检索信息的数据库管理系统所组成。小型的站点可能在文本文件中存储信息，但是大型的复杂的站点使用的是企业级的全面的数据库。根据你自己的需求，你可能这两者都会用到。

和测试这个层面相关的最大的挑战是重现产品的环境。你必须使用和现实一样的硬件和软件来验证测试。另外，一旦你得到了财务和人力的资源，你必须开发一个保持你的测试环境和产品环境相互同步的方法。

就像其他层一样，你必须在测试数据层的时候找到哪个特定的区域有错误。这些错误包括了下列的：
.相应时间。DML（SQL INSERTs,UPDATEs,和 DELETEs）的定量完成时间，查询（SELECTs）和执行。
.数据完整性。验证数据正确的存储着。
.容错和可恢复性。MTBF的最大值和MTTR的最小值。

9.3.3.1 响应时间
慢速的电子商务程序会使得客户不愉快。因此，你应该想办法保证你的站点在用户需求和动作之后的相应时间。在这一层上测试的相应时间不包含页面的载入时间，但是主要专注于定义数据库操作是不是达到了性能标准。当测试数据层的相应时间时，你必须保证个体的数据库可以很快的操作，不会成为其他操作的瓶颈。

不管怎么说，你开始衡量数据库操作之前，你必须明白数据库由什么组成。就这个讨论来讲，数据库的操作包含了在RDBMS中对数据的插入，删除或者查询操作。衡量相应时间简单的是包括决定每个操作占用多长的时间。你不需要对衡量执行次数太过关心，因为他们可能包含在多数据库操作中。在测试商务层的时候外观的执行速度测试已经做过了。

因为你想要定位数据库的错误，你不想测试数据层的响应速度是衡量完成交易的速度。在整个执行的过程中，太多的因素会影响到测试的结果。比方说，如果用户试着取回自己资料的时候耽误了很长时间。你应该决定那个是操作中存在的瓶颈。是在SQL 声明中还是Web服务器还是防火墙中？如果单独测试数据库操作，使得你可以确认问题。在这个例子中，如果SQL声明写的很差，在你测试响应时间的时候它会自己显示出来。

数据层的响应时间测试是充满挑战的折磨。你必须有和你产品一样的测试环境。否则，你可能得到不正确的测试结果。同样，你必须对你数据库系统有一个直观的了解来确保它是正确地设置和高效地运行。你可以找到数据库运行低效的原因是因为RDBMS被不正确地配置。

通常来说，你对响应时间的测试大多数时候是用的黑盒方式进行测试。你所关心的是数据库执行所花去的时间。有很多工具可以做这个事情，或者你可以自己写一个。

Technorati Tags: Art of software testing, internet application test, data