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