注：这一个系列是我在看原版的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

注：这一个系列是我在看原版的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.2.2 数据验证

商务层的一个非常重要的功能就是要确保你从用户那里收集的数据是正确的。如果你的系统运作在像错误的信用卡号码或者错误的地址这样的不正确的信息上的话，就会发生含义错误（歧义？）。如果你运气不好，那么这些错误将会导致你和你的客户发生财务上的问题。你测试数据收集的错误就应该像你测试独立的程序时的用户输入或者参数错误那样测试。请参考第5章来取得设计这些测试用例的信息。

9.3.2.3 业务处理测试

你的电子商务网站必须一直100%地正确处理交易业务。不能有例外。客户是不会容忍失败的交易业务的。另外，名声上的污点也会导致顾客的流失，你还可能因为失败的业务招来法律责任上相关的麻烦。

你可以在测试商务层的时候，考虑像测试系统测试一样测试业务流程测试。换句话说，你从头到尾地来测试商务层，试着揭露问题。再说一次，你应该有一份制定整个业务交易的详细流程文档。它到底是用户怎么在站内查询，填充购物车，或者还是只是由购买的流程所组成？

从一个典型的互联网应用来讲，交易业务的组成远远比财务上的业务交易要复杂的多（比如处理信用卡）。客户在整个业务交易中产生的事件主要包括以下一些：
.查询存货清单。
.收集客户想要购买的物品。
.购买物品，当然这中间除了进行财务的交易处理以外，还包括了交易税和运输费用的计算。
.通知顾客这个交易已经完成，这通常是用E-mail来完成的。

除了测试内部的交易流程，你还必须要测试外部的服务，比如信用卡的验证，银行还有地址的认证。你基本上使用第三方的组件和财务机构在指导财务交易时定义好的交流界面。不要认为这些项目已经很好地工作着了。你必须测试和验证你可以和外部的服务沟通还有你从他们哪里收到正确的反馈。

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