Scrap | 双陳兩曲 —— 书键录恩仇

原来Bill Gates也可以很可爱

称这个视频是2008年的第一个年度视频一点都不为过。（比之很黄很暴力，我更喜欢这个）
在这里你可以看到一个不一样的Bill Gates,他一扫在我心目中木讷的Nerd形象,开始变得鲜活起来。

Technorati Tags: Bill Gates, Microsoft, video, CES2008

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 【8】

注：这一个系列是我在看原版的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-Chapter9 Testing Internet Applications) 【7】

9.3.2.2 数据验证

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

9.3.2.3 业务处理测试

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

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

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

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

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

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 【6】

9.3.2.1性能测试

糟糕的互联网程序使你的用户怀疑你网站的强壮能力，而且会让顾客离开。冗长的页面和缓慢的下载速度就是这中差体验的典型。为了帮助达成足够的性能水平。你需要保证，操作仕样已经在需求收集的阶段就已经写好了。如果没有写好仕样或者目标，你没办法知道你的程序到底运行的怎么样。操作手顺经常一条一条地列出相应时间或者吞吐率。举例来说，一个页面载入了x秒，或者程序服务器一分钟完成y张信用卡支付。

通常的捷径是，你可以用压力测试来当做性能测试。通常来说，对系统的需求变得过载的时候，系统的性能表现将会下降到一个不能使用的点。这可能是导致时间敏感型处理程序失败的原因。当然程序的错误将会导致你的顾客浪费金钱。压力测试的概念我们在第六章中就提到过了，可以用到测试商务层的性能上。

我们来做一个快速的回顾，压力测试包含了用过多个登录和模拟处理来使得程序出错，你可以以此来判断你的程序有没有达到一个性能的目标。当然，你也需要一个典型的用户访问模型来验证结果。只是载入主页不等于传输购物信息和处理交易。你应该使系统承受重压来暴露过程上的错误。

压力测试也允许你调查你网络构造的坚固和轻装。你可能会觉得你的程序每秒钟只处理x个交易是一个瓶颈。但是进一步的调查显示配置不正确的路由，服务器，或者防火墙的浪费了带宽。因此，你应该保证之前用来进行压力测试的的网络结构是支持的。而不是做了很多之后得到一个错误的结果。

Technorati Tags: artofsoftwaretesting, internet application, performance

怎么在WordPress MU中开启注册这个链接?

昨天还在问我爱水煮鱼，怎么在WP MU中打开“注册”这个链接。今天就在WP MU的文档中找到了答案。

要打开“注册”这个链接，需要在管理员后台打开“anyone can register”这个功能。应该是任何人都可以注册用户的功能，而不是任何人都可以注册用户并开启Blog这个功能吧。

然后，编辑header.php

<body>
<div id=”rap”>
<div id=”header”>
        <ul id=”topnav”>
                <li><a href=”http://blogs.sitename.com/”>blogs.sitename.com</a> | </li>
                <li><?php wp_register(‘ ‘ , ‘ ‘); ?> | </li>
                <li><?php wp_loginout(); ?> | </li>

OK，这样应该就可以了。但是具体的还没有时间试验，等到回家之后或许可以试验一下。当然，我觉得这个链接也不一定需要出现在header中，如果你设置了单独的首页入口的话，也是一样的。

Technorati Tags: wordpress mu, code, project azz

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 【5】

9.3.2 商务层的测试

商务层测试主要关注找到你网络程序的商业逻辑的错误。你会发现其实测试这个和测试其他的独立程序是一样的，你可以使用白盒和黑盒手段来进行。你要建立测试计划和步骤来检测程序在性能要求和数据收集还有交易进程的过程中的错误。

你要通过白盒测试来接近内部开发的组件，因为你可以知道程序的内部逻辑。然而，黑盒测试才是你在这一层测试的时候主要的技术手段。你要从开发测试驱动来组合测试独立的组件。(You will start by developing test drivers to unit-test the individual components.) 接下来你可以进行系统测试来检测你的组件在一起是不是可以很好的工作。当在这一层来领导一个系统测试时，你需要模仿用户购买产品或服务的步骤。比如，作为一个电子商务站点你可能需要建立一个测试驱动来查找清单，添加东西到购物车，还有支付。实事求是地为这些步骤来做模型是很有挑战的。( Pragmatically modeling these steps can prove challenging.)

你用来建立商业逻辑的技术指导你如何来建立和领导你的测试。有很多技术和手段你可以在这层的测试中用到，这使得没法建议你挑选一种唯一的测试方法。( There are numerous technologies and techniques you man use to build this layer, which makes it impossible to suggest a cookie-cutter testing method.)举例来说,你可能用一个向JBoss一样的专门的程序服务器建造你自己的解决方案。或者你可以用C或者Perl写一些标准的CGI模块。

不管你怎么接近,你程序中总有一个部分是你必须要测试的。比如下面列出来的那些：

.性能。测试看看你的程序是否达到了文档上所标称的性能（通常是响应速度和传送率）
.数据校验。测试看看从客户处收集的数据是否包含了错误。
.执行。测试是否覆盖到了整个交易的全部过程，这个过程应该包括了信用卡，电子邮件验证，和计算消费税等等。

Technorati Tags: art of software testing, Internet application test, business

中国移动，你是优秀的服务还是糟糕的骚扰

一早上,短短的10分中之内被中国移动骚扰了3次。先是10086的电话,一直不停的响,我开的是震动还是受不了接了起来。告诉我余额不足20元了，要快点交钱了。接完电话还没几分钟,短信又来了,一看又是中国移动。还是那句，您的余额不足20元了，为了保证您的…blah blah 心想这次总该让我好好工作了吧,等我下班再去买卡充值。第二条短信又来了… 囧一模一样的短信发两次。强忍着没把手里的手机扔出去，要不然就变成办公室3C掷远了。

我明白,移动是怕我忘记交电话费,可是我不是还有20元的余额么 -___- 虽然全球通比较费钱，可是20元撑一下还是可以的吧。这么热情的提醒我缴费…我有欠过你移动钱么 -____-

确保用户能及时准确地收到消息是对的。但是密集的消息轰炸就有些过了，难道我不用干活每天都是等着移动的消息，然后屁颠屁颠地跑去充值么。

现在很多网站也是这样.经常一条通知发送n次。一般来讲这种服务我基本上都不会再去用它了。

Technorati Tags: china mobile, service

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 【4】

9.3.1 展示层的测试

对展示层的测试由寻找图形界面上的错误和前台的错误所组成。这个关键的一层提供了减少对你站点投诉，所以发现和改正这一层上发现的问题对展示一个有质量，有活力的站点来说是至关重要的。( This important layer provides the curb appeal of your site, so detecting and correcting errors in this layer are critical to presenting a quality, robust website.) 如果你的顾客在这个层面遇到问题，他们可能不再回来了。他们会可能因为你网站上的拼写错误而离开，一个连拼写都没法保证正确的公司怎么能把信用卡信息交给他们呢？

简而言之，展示层的测试是劳动密集型的工作。如果你可以把你的互联网程序分割成分开的实体的话，你在测试展示层的时候也可以怎么做。下面的列表定义了展示层三个主要的区域：
1. 内容测试。整体的美观，字体，颜色，拼写，内容的正确性，默认值的正确性。
2. 网站的结构。有没有死链接和不能显示的图片。
3. 用户环境。浏览器的版本和操作系统设置会不会对网站正常显示造成影响？

内容测试需要检查网站的人机接口元素。你需要查找字体的类型和屏幕输出，颜色，图片的分辨率以及其他直接作用到最终用户的特性。另外，你需要检查你网站提供信息的准确性。防止出现语法正确，但是信息不准确，信息可以和其他图形界面的问题一样危害到你公司的可信度。不准确的信息还可能给你的公司造成法律上的问题。

测试网站的结构，是需要找到导航和构造上的问题。你需要查找坏掉的链接，不存在的页面和错误的文件或者其他一切将用户带往网站错误区域的东西。这些错误非常容易发生，特别是在动态的网站在开发或者升级的过程时候。只要有一个项目成员修改了一个文件的名字，那么指向它的那个超级链接就没用了。如果图片元素被重命名或者移除了，那么在你网页上因为找不到文件会留下一个“大洞”。你可以用一个检查每个页面的结构问题的组合测试来验证你网站的结构问题。最好的练习是，你把结构测试也同样迁移到回归测试中。很多工具都可以自动进行坏链和丢失文件的检查。

白盒测试的手段当测试网站结构的时候是非常有用的。就像程序组会有决定点和执行路径一样，网页也有。（Just as program units have decision points and execution path, so do Web pages.) 用户可能用任何顺序来点击那些可以引导用户从一个页面到另一个页面的链接和按钮。对大型站点来说，他们有很多导航事件的组合会发生。复习我们在第四章提到的白盒测试和逻辑覆盖理论能了解更多。

就像早先提到的那样，测试最终用户的环境，也就是说浏览器兼容性测试，是测试基于互联网程序的非常具有挑战性的方面。浏览器和操作系统的组合有很多很多。不只是你需要测试每种浏览器的设置，你还要测试同一浏览器的不同版本。浏览器的供应商经常会在版本升级的时候对一些特性进行改进，也就是说这些改进很有可能会对就的浏览器兼容性造成影响。

如果你的程序严重依靠于客户端的脚本运行，你的用户环境测试将会变得非常复杂。每个浏览器都回有不同的脚本引擎，或者虚拟机来运行脚本，而且代码是在客户的电脑上。如果你使用了下列技术，那么你在测试浏览器兼容性测试的时候请特别注意：

. Active X 控制
. JavaScript
. VBScript
. Java控件

你使用一份定义的很好的功能需求书，可以很好的克服大部分和浏览器兼容性测试关联的挑战。比如，在要求收集的阶段，你的市场部可能会决定程序需要确认在某个特定的浏览器下可以运行。这个要求消除了很多测试因为你定义了你需要测试的平台。

Technorati Tags: art of software testing, internet application test, browser compatbility

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 【3】

9.3 测试的战略

开发一个测试基于互联网的程序的战略要求踏实地了解组成这个程序的每个硬件和软件。因为这是是否能成功地测试程序的重要标准，需要一份描述你的网站期望的功能和性能的测试需求文档。如果没有文档，你没法设计合适的测试用例。

你需要测试内部开发的组件以及向外部购买的第三方组件。对自己开发的组件，你可以使用之前几章我们介绍的那些手段。包括了设计组合/模块化的测试用例以及代码审查。只有在你检查过这些组件达到了你的文档中提到的设计标准和功能需求之后，你才能把他们集成到整个系统中去。

如果你购买了第三方的组件，那么你要设计一系列的系统测试来检验这个组件是否可以正常地独立地运行于你的程序中。不要用你供应商的质量控制程序在这个组件中来发现的错误在作为测试的结果。比较完美的是你需要自己独立地完成你对程序的测试。只有当你决定他们表现出了可以接受水平之后，你才能把他们集成到程序中去。对于你程序结构中的非功能性的第三方组件，很难用测试结果来解释和定义出错误的源头。通常，你需要用到黑盒测试来检验第三方的组件，因为你几乎不知道这个组件内部是怎么实现的。

测试基于互联网的程序，最方便的方法是用分而治之的方法来达到效果。幸运的是，基于互联网的应用程序的结构可以允许你来定义描述区域来运用测试用例（Fortunately, the architecture of Internet applications allows you to identify discrete areas to target testing.) 图标9.1已经表达了一些互联网程序的基本结构。那么图标9.2将会为每一层提供更多更仔细的视角。

就像我们在本章的早些时候提到的那样，基于互联网的程序可以被看做是三层的C/S结构。在图标9.2中对每一层是怎么定义的：
.展示层这一层互联网程序提供了图形界面。
.商业逻辑层这一层为你提供了用户认证和交易处理等的商业模式
.数据层这一层容纳了你的程序需要使用的或者是从用户那里收集来的数据

每一层都有它自己的特性，他们促进了测试的细化。如果你每个层分开独立测试，那么你将会在系统测试开始之前更容易地定义问题和错误。如果你只是依赖于系统测试，那么你可能会将时间浪费在定位一个造成问题的特定组件上。

图表9.2列出了你在每一个层面必须测试的项目。这个列表并不完整，但是为你设计自己的测试标准提供了一个出发点。在这一章的接下来部分我们会为怎么测试每一个层面提供更详细的指导。

Technorati Tags: art of test, internet application test, stratage

测试的艺术第九章测试基于互联网的程序（The Art of Software Testing-Chapter9 Testing Internet Applications) 【2】

9.2 测试的挑战

在设计和测试基于互联网的程序是因为大量的你无法控制的元素和许多互相依存的组建，所以你将面对许多挑战。适当的测试你的程序需要你来制作一些你的客户如何使用你网站的环境假定。

一个基于互联网的程序有许多容易失败的地方，在你需要在设计测试用例的时候需要考虑好的。( An Internet-based application has many failure points that you should consider when designing a testing approach.) 下面的这个列表提供了一些测试基于互联网的程序相关联挑战的例子：

.有一个很大而且各式各样不同的用户群。你网站的用户技术的水平是不相同的，他们所使用的浏览器也是各式各样的，当然使用的操作系统和设备也不相同。你也应当考虑到，用户访问你网站的网络速度也是不一样的。不是每个人都有一条T1线路或者拥有宽带连接的。

.商业环境如果你正在运营一个电子商务网站，那么你必须考虑到一些比如计算税收的问题，还要决定运费，完成交易财务处理和追踪客户的资料。

.发生的场地用户可能定居在不同的国家，所以你需要处理一些国际化的问题，比如语言的翻译，时区的考虑和货币的换算等问题。

.测试环境为了恰当地测试你的程序，你需要重现产品的环境。这表示你需要使用和正式上线的产品环境一样的web服务器，程序服务器和数据库服务器。为了得到最准确的测试结果，我们同样需要重现网络的基础设施，包括路由器，交换机和防火墙。

.安全因为你的站点是面向全世界的，你必须保护自己的站点防止黑客的攻击。他们会用DoS攻击给你的站点带来令人难以忍受的停顿或者窃取你用户的信用卡资料。

即使在这个列表之外，当我们从一个非常多样化的开发和商务的角度来看待这个测试时，我们也需要添加许多考虑角度。( Even from this list, which could be expended considerably as we include viewpoints from a wide variety of developers and businesses) 你可以看到配置一个测试环境是电子商务开发的最富有挑战性的地方。测试财务交易的过程需要最大的精力和花费。你必须复制包括软件和硬件在内的所有组件，利用这个环境来测试程序得到符合要求的结果。配置如此一个测试环境是一个昂贵的努力。不仅设备会给你带来不菲的成本，同样人力成本也同样高昂。许多公司在制作预算的时候没有把这些成本计算进去。导致这个的原因通常包括过分低估时间和货币的需求。再说一点，测试环境还需要一个维护计划，用来保证程序的升级对它产生的影响。

另外一个在测试中有意义的挑战是当你面对浏览器的兼容性测试的时候。在市场上有许多种浏览器，而且他们的行为都不相同。虽然在浏览器的操作上具有一个标准，但是大多数的浏览器提供者为了吸引忠实用户而对浏览器做了很多增强的工作。很不幸的是，就是这些增强导致了浏览器变得不那么符合标准。我们会在本章的接下来环节在仔细阐述这个问题。

虽然在测试基于互联网的程序的时候将会面对那么多的挑战，你还是应该把你的测试精力集中到一些特定的环节。图表9.1定义了一些在测试中非常重要的部分，这个可以保证你的用户可以在你的网站上得到积极的体验。

因为第一印象是最重要的印象，你的一部分测试精力将会集中在测试可用性和面向人类的影响。（Because the first impression is the most important impression, some of your testing will focus on usability and human-factor concerns.) 这个区域主要专注在外观和对你程序的感觉上。在用户是不是会接受你的程序这个问题上，字体，颜色和图片将会在测试项目中扮演一个主要的角色。

系统的性能当然也会印象到用户的第一印象。就像我们在前面提到的那样，互联网的用户希望得到即时的满足。他们不希望为了等待页面载入或者完成处理而浪费很多时间。毫不夸张地说，几秒钟的延时就可能导致你的顾客去访问其他的网站了。低下的性能可能导致顾客怀疑你网站的可靠性。因此，你应该设定你希望的性能目标，而且设计一些可以暴露你的网站没法达到目标这样问题的测试用例。

当顾客在你的站点购买产品或者服务的时候，他们需要快速和正确地处理交易。他们绝对不会容许付费和运输上发生什么错误 (They do not, and should not, tolerate inaccurate billings or shipping errors.) 如果你的程序没办法进行正常的财务交易，发现你应该对更多的交易数量负责，比损失一个顾客要来的好些。（Probably worse than losing a customer is finding yourself liable for more that the transaction amount if your application does not process financial transactions correctly)

你的程序在完成交易或者电子邮件注册的时候都会收集一些信息。所以，你应该保证你收集的这些信息是有效的。比如说，保证电话号码，身份证号码，货币种类，电子邮件地址和信用卡号码这些号码的长度和格式都是正确的。再说一点，你应该检查你的数据的完整性。本土化的过程很容易导致数据因为字符集的不同而被截断，使得这些数据不能使用。

在互联网环境中，保证用户可以使用网站的服务是非常重要的。这需要你为了所以的支持程序和服务器开发和设计一份指导方针。比如Web服务器和RDBMS需要高等级的管理。你必须监控日志文件，系统资源和备份数据用以保证这些重要项不会出错。就像我们在第六章中说的那样，你希望用最小的覆盖达到最大的错误发现。

最后，你测试精力还要注意到其他地方网络的连接水平。也就是说，你要注意网络连接性能下降。( At some point, you can count on network connectivity going down) 失败的源头可能是因为网络本身——你的服务提供商或者你的内部网络造成的。所以，当损耗发生时，你需要为你的程序建立一些备选方案和基础设施来有条不紊地回应它。保证你测试的主题，那就是你需要制定一个测试用例来打破你的备选方案。

Technorati Tags: Art of test, internet application test, challenge