2008-03-25 14:55:12
现在很多网站都用到Cookies，特别是用户的登陆以及购物网站的购物车。
Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies 访问了某一个应用系统时，Web
服务器将发送关于用户的信息，把该信息以Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果
Web 应用系统使用了Cookies ，就必须检查Cookies 是否能正常工
作。测
试的内容包括Cookies是否起作用，存储的内容是否正确，是否按预定的时间进行保存，刷新对Cookies
有什么影响等。
http://ccc.atmos.colostate.edu/~hail/howto/faq/coo...
如果到\Local Settings\Temporary Internet Files文件夹下查看每个Cookies文件是一件很麻烦的事情，这个时候就需要有工具来帮助我们。
1、Cookie Editor
http://www.proxoft.com/CookieEditor.asp
Cookie Editor is an application that helps you manage cookies set by Internet Explorer, Netscape or Mozilla Browsers.
Cookie Editor allows you to maintain the level of your privacy by allowing you to see, edit or delete any unwanted cookies. It searches your drives for all IE cookies then displays them is easy grid-like format. You can examine content of any cookie or delete it.
For advanced users, you can also edit the contents of cookies. So, for example, if you want to change your zip code for'movies.yahoo.com', or move up the expiration date of a given cookie, you could do so without even opening your browser!
比较大的特点是可以显示出IE，Netscape和Firefox的Cookie；因为Netscape和Firefox的 Cookie不是存储在Temporary Internet Files文件夹下的，而是在Application Data文件夹下的对应文件夹里。
2、IECookiesView
http://www.nirsoft.net/utils/iecookies.html
一 个可以帮你搜寻并显示出你计算机中所有的Cookies档案的数据，包括是哪一个网站写入Cookies的，内容有什么，写入的时间日期及此 Cookies的有效期限..等等资料。你是否常常怀疑一些网站写入Cookies内容到你的计算机中是否会对你造成隐私的侵犯！使用软件来看看这些 Cookies的内容都是些什么呢！如此你就不会再担心怀疑了。此软件只对IE浏览器的Cookies有效。
3、Cookies Manager
http://home.nordnet.fr/~pmdevigne/CookiesManager_e...
Cookies Manager helps you to select which cookies you want to keep and which cookies you want to delete.
4、My Cookie
My Cookie是一款可以实时查看、修改IE内 Cookied的软件。并且可以设 置 Cookie值的生命周期。
Cookie技术是一个非常有争议的技术，自经诞生它就成了广大网络用户和Web开发人员的
一个争论焦点。有一些网络用户，甚至包括一些资深的Web专家也对它的产生和推广感到不满，这倒不是因为
Cookie技术的功能太弱或别的技术性能上的原因，而仅仅是因为他们觉得Cookie 的使用，对网络用户的隐私
构成了危害。因为Cookie是由Web服务器保存在用户浏览器上的小文本文件，它包含有关用户的信息（如身份
识别号码、密码、用户在Web站点上购物的方式或用户访问该站点的次数）。
那么Cookie 技术究竟怎样呢？是否真的给网络用户带来了个人隐私的危害呢？还是让我们看了下面的内
容，再做回答吧。
（1）Cookie技术简介
在WEB技术发展史上，Cookie技术的出现是一个重大的变革。最先是Netscape在它的Netscape Navigator
浏览器中引入了Cookie技术，从那时起，World Wide Web 协会就开始支持Cookie标准。以后又经过微软的大
力推广（因为微软的IIS Web服务器所采用的ASP技术很大程度的使用了Cookie技术），即在微软的Internet
Explorer浏览器中完全支持Cookie技术。到现在，绝大多数的浏览器都支持Cookie技术，或者至少兼容Cookie
技术的使用。
1）什么是Cookie？
按照Netscape官方文档中的定义，Cookie是在HTTP协议下，服务器或脚本可以维护客户工作站上信息的
一种方式。Cookie 是由Web服务器保存在用户浏览器上的小文本文件，它可以包含有关用户的信息（如身份
识别号码、密码、用户在Web站点购物的方式或用户访问该站点的次数）。无论何时用户链接到服务器，Web
站点都可以访问Cookie信息。
通俗地讲，浏览器用一个或多个限定的文件来支持Cookie。这些文件在使用Windows操作系统的机器上叫
做Cookie 文件，在Macintosh机器上叫做magic Cookie 文件，这些文件被网站用来在上面存储Cookie数据。
网站可以在这些Cookie 文件中插入信息，这样对有些网络用户就有些副作用。有些用户认为这造成了对个人
隐私的侵犯，更糟的是，有些人认为Cookie是对个人空间的侵占，而且会对用户的计算机带来安全性的危害。
目前有些Cookie 是临时的，另一些则是持续的。临时的Cookie只在浏览器上保存一段规定的时间，一旦
超过规定的时间该Cookie就会被系统清除。例如在PHP中Cookie被用来跟踪用户进程直到用户离开网站。持续
的Cookie则保存在用户的Cookie文件中，下一次用户返回时，仍然可以对它进行调用。
在Cookie文件中保存Cookie，一些用户会过分地认为这将带来很大的问题。主要是有些用户担心Cookie
会跟踪用户网上冲浪的习惯，譬如用户喜爱到那些类型的站点、爱从事些什么活动等。害怕这种个人信息一
旦落入一些别有用心的家伙手中，那么个人也就可能成为一大堆广告垃圾的对象，甚至遭到意外的损害。不
过，这种担心压根儿不会发生，因为网站以外的用户是无法跨过网站来获得Cookie信息的。所以想以这种目
的来应用Cookie是不可能的。不过，由于一些用户错误的理解以及“以讹传讹”，一些浏览器开发商别无选
择，只好作出相识的响应（例如Netscape Navigator4.0和Internet Explorer3.0都提供了屏蔽Cookie 的选
项）。
对Cookie技术期待了这么久的结果是，迫使许多浏览器开发商在它们的浏览器中提供了对Cookie的灵活
性控制功能。例如，目前的两大主流浏览器Netscape Navigator 和 Internet Explorer是这样处理Cookie
的:Netscape Navigator4.0不但可以接受Cookie进行警告，而且还可以屏蔽掉Cookie；InternetExplorer3.0
也可以屏蔽Cookie，但在Internet Explorer4.0中就只能进行接受警告而没有提供屏蔽选项，不过在Internet
Explorer4.0之后的更新版本中又加入了屏蔽Cookie的功能选项。
此外，很多最新的技术甚至已经可以在不能屏蔽Cookie的浏览器上进行Cookie的屏蔽了。例如，可以通
过将Cookie文件设置成不同的类型来限制Cookie的使用。但是，非常不幸地是，要是你想完全屏蔽Cookie的
话，肯定会因此拒绝许多的站点页面。因为当今已经有许多Web站点开发人员爱上了Cookie技术的强大功能，
例如Session对象的使用就离不开Cookie的支持。
尽管今天仍有一些网络用户对于Cookie的争论乐此不倦，但是对于绝大多数的网络用户来说还是倾向于
接受Cookie的。因此，我们尽可以放心地使用Cookie技术来开发我们的WEB页面。
2）Cookie是怎样工作的？
要了解Cookie，必不可少地要知道它的工作原理。一般来说，Cookie通过HTTP Headers从服务器端返回
到浏览器上。首先，服务器端在响应中利用Set-Cookie header来创建一个Cookie ，然后，浏览器在它的请
求中通过Cookie header包含这个已经创建的Cookie，并且反它返回至服务器，从而完成浏览器的论证。
例如，我们创建了一个名字为login的Cookie来包含访问者的信息，创建Cookie时，服务器端的Header
如下面所示，这里假设访问者的注册名是“Michael Jordan”，同时还对所创建的Cookie的属性如path、
domain、expires等进行了指定。
Set-Cookie:login=Michael Jordan;path=/;domain=msn.com;
expires=Monday,01-Mar-99 00:00:01 GMT
上面这个Header会自动在浏览器端计算机的Cookie文件中添加一条记录。浏览器将变量名为“login”
的Cookie赋值为“Michael Jordon”。注意，在实际传递过程中这个Cookie的值是经过了URLEncode方法的
URL编码操作的。 这个含有Cookie值的HTTP Header被保存到浏览器的Cookie文件后，Header就通知浏览器
将Cookie通过请求以忽略路径的方式返回到服务器，完成浏览器的认证操作。
此外，我们使用了Cookie的一些属性来限定该Cookie的使用。例如Domain属性能够在浏览器端对Cookie
发送进行限定，具体到上面的例子，该Cookie只能传达室到指定的服务器上，而决不会跑到其他的如
www.hp.com的Web站点上去。Expires属性则指定了该Cookie保存的时间期限，例如上面的Cookie在浏览器上
只保存到1999年3月1日1秒。当然，如果浏览器上Cookie 太多，超过了系统所允许的范围，浏览器将自动对
它进行删除。至于属性Path，用来指定Cookie将被发送到服务器的哪一个目录路径下。
说明：浏览器创建了一个Cookie后，对于每一个针对该网站的请求，都会在Header中带着这个Cookie；
不过，对于其他网站的请求Cookie是绝对不会跟着发送的。而且浏览器会这样一直发送，直到Cookie过期为止。
上一部分讲了有关Cookie的技术背景，这部分来说说在PHP里如何设置、使用、删除Cookie，及Cookie
的一些限制。PHP对Cookie支持是透明的，用起来非常方便。
1、设置Cookie
PHP用SetCookie函数来设置Cookie。必须注意的一点是：Cookie是HTTP协议头的一部分，用于浏览器和
服务器之间传递信息，所以必须在任何属于HTML文件本身的内容输出之前调用Cookie函数。SetCookie 函数
定义了一个Cookie，并且把它附加在HTTP头的后面，SetCookie函数的原型如下：
int SetCookie(string name, string value, int expire, string path, string domain, int secure);
除了name之外所有的参数都是可选的。value,path,domain 三个参数可以用空字符串代换，表示没有设
置；expire和 secure两个参数是数值型的，可以用0表示。expire参数是一个标准的Unix时间标记，可以用
time()或mktime() 函数取得，以秒为单位。secure参数表示这个Cookie是否通过加密的HTTPS协议在网络上
传输。
当前设置的Cookie 不是立即生效的，而是要等到下一个页面时才能看到.这是由于在设置的这个页面里
Cookie由服务器传递给客户浏览器，在下一个页面浏览器才能把Cookie从客户的机器里取出传回服务器的原
因。在同一个页面设置Cookie，实际是从后往前，所以如果要在插入一个新的Cookie之前删掉一个，你必须
先写插入的语句，再写删除的语句，否则可能会出现不希望的结果。
来看几个例子：
简单的：
SetCookie("MyCookie", "Value of MyCookie");
带失效时间的：
SetCookie("WithExpire", "Expire in 1 hour", time()+3600);//3600秒=1小时
什么都有的：
SetCookie("FullCookie", "Full cookie value", time()+3600, "/forum", ".phpuser.com", 1);
这里还有一点要说明的，比如你的站点有几个不同的目录，那么如果只用不带路径的Cookie的话，在一
个目录下的页面里设的Cookie在另一个目录的页面里是看不到的，也就是说，Cookie是面向路径的。实际上，
即使没有指定路径，WEB 服务器会自动传递当前的路径给浏览器的，指定路径会强制服务器使用设置的路径。
解决这个问题的办法是在调用SetCookie时加上路径和域名，域名的格式可以是“www.phpuser.com”，也可
是“.phpuser.com”。
SetCookie函数里表示value的部分，在传递时会自动被encode，也就是说，如果value的值是“test
value”在传递时就变成了“test%20value”，跟URL的方法一样。当然，对于程序来说这是透明的，因为在
PHP接收Cookie的值时会自动将其decode。
如果要设置同名的多个Cookie，要用数组，方法是：
SetCookie("CookieArray[]", "Value 1");
SetCookie("CookieArray[]", "Value 2");
或
SetCookie("CookieArray[0]", "Value 1");
SetCookie("CookieArray[1]", "Value 2");
2、接收和处理Cookie
PHP对Cookie的接收和处理的支持非常好，是完全自动的，跟FORM变量的原则一样，特别简单。比如设
置一个名为MyCookier的Cookie，PHP会自动从WEB服务器接收的HTTP头里把它分析出来，并形成一个与普通
变量一样的变量，名为$myCookie，这个变量的值就是Cookie的值。数组同样适用。另外一个办法是引用PHP
的全局变量$HTTP_COOKIE_VARS数组。
分别举例如下：（假设这些都在以前的页面里设置过了，并且仍然有效）
echo $MyCookie;
echo $CookieArray[0];
echo count($CookieArray);
echo $HTTP_COOKIE_VARS["MyCookie"];
就这么简单。
3、删除Cookie
要删除一个已经存在的Cookie，有两个办法：
一是调用只带有name参数的SetCookie，那么名为这个name的Cookie 将被从关系户机上删掉；另一个办
法是设置Cookie的失效时间为time()或time()-1，那么这个Cookie在这个页面的浏览完之后就被删除了（其
实是失效了）。
要注意的是，当一个Cookie被删除时，它的值在当前页在仍然有效的。
4、使用Cookie的限制
首先是必须在HTML文件的内容输出之前设置；
其次不同的浏览器对Cookie的处理不一致，且有时会出现错误的结果。比如：MS IE+SERVICE PACK 1
不能正确处理带域名和路径的Cookie ，Netscape Communicator 4.05和MS IE 3.0不能正确处理不带路径和
时间的Cookie。至于MS IE 5 好象不能处理带域名、路径和时间的Cookie。这是我在设计本站的页面时发现
的。
第三个限制是在客户端的。一个浏览器能创建的Cookie数量最多为30个，并且每个不能超过4KB，每个WEB
站点能设置的Cookie总数不能超过20个。
关于Cookie的话题，就说到这儿了。
（由于Cookie最初由Netscape定义的，所以附上Netscape公司关于Cookie的官方原始定义的网址：
_spec.html"
target=_blank>http://www.netscape.com/newsref/std/cookie_spec.html）
Cookie技术是一个非常有争议的技术，自经诞生它就成了广大网络用户和Web开发人员的
一个争论焦点。有一些网络用户，甚至包括一些资深的Web专家也对它的产生和推广感到不满，这倒不是因为
Cookie技术的功能太弱或别的技术性能上的原因，而仅仅是因为他们觉得Cookie 的使用，对网络用户的隐私
构成了危害。因为Cookie是由Web服务器保存在用户浏览器上的小文本文件，它包含有关用户的信息（如身份
识别号码、密码、用户在Web站点上购物的方式或用户访问该站点的次数）。
那么Cookie 技术究竟怎样呢？是否真的给网络用户带来了个人隐私的危害呢？还是让我们看了下面的内
容，再做回答吧。
（1）Cookie技术简介
在WEB技术发展史上，Cookie技术的出现是一个重大的变革。最先是Netscape在它的Netscape Navigator
浏览器中引入了Cookie技术，从那时起，World Wide Web 协会就开始支持Cookie标准。以后又经过微软的大
力推广（因为微软的IIS Web服务器所采用的ASP技术很大程度的使用了Cookie技术），即在微软的Internet
Explorer浏览器中完全支持Cookie技术。到现在，绝大多数的浏览器都支持Cookie技术，或者至少兼容Cookie
技术的使用。
1）什么是Cookie？
按照Netscape官方文档中的定义，Cookie是在HTTP协议下，服务器或脚本可以维护客户工作站上信息的
一种方式。Cookie 是由Web服务器保存在用户浏览器上的小文本文件，它可以包含有关用户的信息（如身份
识别号码、密码、用户在Web站点购物的方式或用户访问该站点的次数）。无论何时用户链接到服务器，Web
站点都可以访问Cookie信息。
通俗地讲，浏览器用一个或多个限定的文件来支持Cookie。这些文件在使用Windows操作系统的机器上叫
做Cookie 文件，在Macintosh机器上叫做magic Cookie 文件，这些文件被网站用来在上面存储Cookie数据。
网站可以在这些Cookie 文件中插入信息，这样对有些网络用户就有些副作用。有些用户认为这造成了对个人
隐私的侵犯，更糟的是，有些人认为Cookie是对个人空间的侵占，而且会对用户的计算机带来安全性的危害。
目前有些Cookie 是临时的，另一些则是持续的。临时的Cookie只在浏览器上保存一段规定的时间，一旦
超过规定的时间该Cookie就会被系统清除。例如在PHP中Cookie被用来跟踪用户进程直到用户离开网站。持续
的Cookie则保存在用户的Cookie文件中，下一次用户返回时，仍然可以对它进行调用。
在Cookie文件中保存Cookie，一些用户会过分地认为这将带来很大的问题。主要是有些用户担心Cookie
会跟踪用户网上冲浪的习惯，譬如用户喜爱到那些类型的站点、爱从事些什么活动等。害怕这种个人信息一
旦落入一些别有用心的家伙手中，那么个人也就可能成为一大堆广告垃圾的对象，甚至遭到意外的损害。不
过，这种担心压根儿不会发生，因为网站以外的用户是无法跨过网站来获得Cookie信息的。所以想以这种目
的来应用Cookie是不可能的。不过，由于一些用户错误的理解以及“以讹传讹”，一些浏览器开发商别无选
择，只好作出相识的响应（例如Netscape Navigator4.0和Internet Explorer3.0都提供了屏蔽Cookie 的选
项）。
对Cookie技术期待了这么久的结果是，迫使许多浏览器开发商在它们的浏览器中提供了对Cookie的灵活
性控制功能。例如，目前的两大主流浏览器Netscape Navigator 和 Internet Explorer是这样处理Cookie
的:Netscape Navigator4.0不但可以接受Cookie进行警告，而且还可以屏蔽掉Cookie；InternetExplorer3.0
也可以屏蔽Cookie，但在Internet Explorer4.0中就只能进行接受警告而没有提供屏蔽选项，不过在Internet
Explorer4.0之后的更新版本中又加入了屏蔽Cookie的功能选项。
此外，很多最新的技术甚至已经可以在不能屏蔽Cookie的浏览器上进行Cookie的屏蔽了。例如，可以通
过将Cookie文件设置成不同的类型来限制Cookie的使用。但是，非常不幸地是，要是你想完全屏蔽Cookie的
话，肯定会因此拒绝许多的站点页面。因为当今已经有许多Web站点开发人员爱上了Cookie技术的强大功能，
例如Session对象的使用就离不开Cookie的支持。
尽管今天仍有一些网络用户对于Cookie的争论乐此不倦，但是对于绝大多数的网络用户来说还是倾向于
接受Cookie的。因此，我们尽可以放心地使用Cookie技术来开发我们的WEB页面。
2）Cookie是怎样工作的？
要了解Cookie，必不可少地要知道它的工作原理。一般来说，Cookie通过HTTP Headers从服务器端返回
到浏览器上。首先，服务器端在响应中利用Set-Cookie header来创建一个Cookie ，然后，浏览器在它的请
求中通过Cookie header包含这个已经创建的Cookie，并且反它返回至服务器，从而完成浏览器的论证。
例如，我们创建了一个名字为login的Cookie来包含访问者的信息，创建Cookie时，服务器端的Header
如下面所示，这里假设访问者的注册名是“Michael Jordan”，同时还对所创建的Cookie的属性如path、
domain、expires等进行了指定。
Set-Cookie:login=Michael Jordan;path=/;domain=msn.com;
expires=Monday,01-Mar-99 00:00:01 GMT
上面这个Header会自动在浏览器端计算机的Cookie文件中添加一条记录。浏览器将变量名为“login”
的Cookie赋值为“Michael Jordon”。注意，在实际传递过程中这个Cookie的值是经过了URLEncode方法的
URL编码操作的。 这个含有Cookie值的HTTP Header被保存到浏览器的Cookie文件后，Header就通知浏览器
将Cookie通过请求以忽略路径的方式返回到服务器，完成浏览器的认证操作。
此外，我们使用了Cookie的一些属性来限定该Cookie的使用。例如Domain属性能够在浏览器端对Cookie
发送进行限定，具体到上面的例子，该Cookie只能传达室到指定的服务器上，而决不会跑到其他的如
www.hp.com的Web站点上去。Expires属性则指定了该Cookie保存的时间期限，例如上面的Cookie在浏览器上
只保存到1999年3月1日1秒。当然，如果浏览器上Cookie 太多，超过了系统所允许的范围，浏览器将自动对
它进行删除。至于属性Path，用来指定Cookie将被发送到服务器的哪一个目录路径下。
说明：浏览器创建了一个Cookie后，对于每一个针对该网站的请求，都会在Header中带着这个Cookie；
不过，对于其他网站的请求Cookie是绝对不会跟着发送的。而且浏览器会这样一直发送，直到Cookie过期为止。
上一部分讲了有关Cookie的技术背景，这部分来说说在PHP里如何设置、使用、删除Cookie，及Cookie
的一些限制。PHP对Cookie支持是透明的，用起来非常方便。
1、设置Cookie
PHP用SetCookie函数来设置Cookie。必须注意的一点是：Cookie是HTTP协议头的一部分，用于浏览器和
服务器之间传递信息，所以必须在任何属于HTML文件本身的内容输出之前调用Cookie函数。SetCookie 函数
定义了一个Cookie，并且把它附加在HTTP头的后面，SetCookie函数的原型如下：
int SetCookie(string name, string value, int expire, string path, string domain, int secure);
除了name之外所有的参数都是可选的。value,path,domain 三个参数可以用空字符串代换，表示没有设
置；expire和 secure两个参数是数值型的，可以用0表示。expire参数是一个标准的Unix时间标记，可以用
time()或mktime() 函数取得，以秒为单位。secure参数表示这个Cookie是否通过加密的HTTPS协议在网络上
传输。
当前设置的Cookie 不是立即生效的，而是要等到下一个页面时才能看到.这是由于在设置的这个页面里
Cookie由服务器传递给客户浏览器，在下一个页面浏览器才能把Cookie从客户的机器里取出传回服务器的原
因。在同一个页面设置Cookie，实际是从后往前，所以如果要在插入一个新的Cookie之前删掉一个，你必须
先写插入的语句，再写删除的语句，否则可能会出现不希望的结果。
来看几个例子：
简单的：
SetCookie("MyCookie", "Value of MyCookie");
带失效时间的：
SetCookie("WithExpire", "Expire in 1 hour", time()+3600);//3600秒=1小时
什么都有的：
SetCookie("FullCookie", "Full cookie value", time()+3600, "/forum", ".phpuser.com", 1);
这里还有一点要说明的，比如你的站点有几个不同的目录，那么如果只用不带路径的Cookie的话，在一
个目录下的页面里设的Cookie在另一个目录的页面里是看不到的，也就是说，Cookie是面向路径的。实际上，
即使没有指定路径，WEB 服务器会自动传递当前的路径给浏览器的，指定路径会强制服务器使用设置的路径。
解决这个问题的办法是在调用SetCookie时加上路径和域名，域名的格式可以是“www.phpuser.com”，也可
是“.phpuser.com”。
SetCookie函数里表示value的部分，在传递时会自动被encode，也就是说，如果value的值是“test
value”在传递时就变成了“test%20value”，跟URL的方法一样。当然，对于程序来说这是透明的，因为在
PHP接收Cookie的值时会自动将其decode。
如果要设置同名的多个Cookie，要用数组，方法是：
SetCookie("CookieArray[]", "Value 1");
SetCookie("CookieArray[]", "Value 2");
或
SetCookie("CookieArray[0]", "Value 1");
SetCookie("CookieArray[1]", "Value 2");
2、接收和处理Cookie
PHP对Cookie的接收和处理的支持非常好，是完全自动的，跟FORM变量的原则一样，特别简单。比如设
置一个名为MyCookier的Cookie，PHP会自动从WEB服务器接收的HTTP头里把它分析出来，并形成一个与普通
变量一样的变量，名为$myCookie，这个变量的值就是Cookie的值。数组同样适用。另外一个办法是引用PHP
的全局变量$HTTP_COOKIE_VARS数组。
分别举例如下：（假设这些都在以前的页面里设置过了，并且仍然有效）
echo $MyCookie;
echo $CookieArray[0];
echo count($CookieArray);
echo $HTTP_COOKIE_VARS["MyCookie"];
就这么简单。
3、删除Cookie
要删除一个已经存在的Cookie，有两个办法：
一是调用只带有name参数的SetCookie，那么名为这个name的Cookie 将被从关系户机上删掉；另一个办
法是设置Cookie的失效时间为time()或time()-1，那么这个Cookie在这个页面的浏览完之后就被删除了（其
实是失效了）。
要注意的是，当一个Cookie被删除时，它的值在当前页在仍然有效的。
4、使用Cookie的限制
首先是必须在HTML文件的内容输出之前设置；
其次不同的浏览器对Cookie的处理不一致，且有时会出现错误的结果。比如：MS IE+SERVICE PACK 1
不能正确处理带域名和路径的Cookie ，Netscape Communicator 4.05和MS IE 3.0不能正确处理不带路径和
时间的Cookie。至于MS IE 5 好象不能处理带域名、路径和时间的Cookie。这是我在设计本站的页面时发现
的。
第三个限制是在客户端的。一个浏览器能创建的Cookie数量最多为30个，并且每个不能超过4KB，每个WEB
站点能设置的Cookie总数不能超过20个。
关于Cookie的话题，就说到这儿了。 thanks
2008-03-24 13:11:19
2008-01-11 16:09:30
GCC参数详解 [介绍]
gcc and g++分别是gnu的c & c++编译器
gcc/g++在执行编译工作的时候，总共需要4步
1.预处理,生成.i的文件
2.将预处理后的文件不转换成汇编语言,生成文件.s
3.有汇编变为目标代码(机器代码)生成.o的文件
4.连接目标代码,生成可执行程序
[参数详解]
-c
只激活预处理,编译,和汇编,也就是他只把程序做成obj文件
例子用法:
gcc -c hello.c
他将生成.o的obj文件
-S
只激活预处理和编译，就是指把文件编译成为汇编代码。
例子用法
gcc -S hello.c
他将生成.s的汇编代码，你可以用文本编辑器察看
-E
只激活预处理,这个不生成文件,你需要把它重定向到一个输出文件里
面.
例子用法:
gcc -E hello.c > pianoapan.txt
gcc -E hello.c | more
慢慢看吧,一个hello word 也要与处理成800行的代码
-o
制定目标名称,缺省的时候,gcc 编译出来的文件是a.out,很难听,如果
你和我有同感，改掉它,哈哈
例子用法
gcc -o hello.exe hello.c (哦,windows用习惯了)
gcc -o hello.asm -S hello.c
-ansi
关闭gnu c中与ansi c不兼容的特性,激活ansi c的专有特性(包括禁止一
些asm inline typeof关键字,以及UNIX,vax等预处理宏,
-wall
显示警告信息
-fno-asm
此选项实现ansi选项的功能的一部分，它禁止将asm,inline和typeof用作
关键字。
-fno-strict-prototype
只对g++起作用,使用这个选项,g++将对不带参数的函数,都认为是没有显式
的对参数的个数和类型说明,而不是没有参数.
而gcc无论是否使用这个参数,都将对没有带参数的函数,认为城没有显式说
明的类型
-fthis-is-varialble
就是向传统c++看齐,可以使用this当一般变量使用.
-fcond-mismatch
允许条件表达式的第二和第三参数类型不匹配,表达式的值将为void类型
-funsigned-char
-fno-signed-char
-fsigned-char
-fno-unsigned-char
这四个参数是对char类型进行设置,决定将char类型设置成unsigned char(前
两个参数)或者 signed char(后两个参数)
-include file
包含某个代码,简单来说,就是便以某个文件,需要另一个文件的时候,就可以
用它设定,功能就相当于在代码中使用#include
例子用法:
gcc hello.c -include /root/pianopan.h
-imacros file
将file文件的宏,扩展到gcc/g++的输入文件,宏定义本身并不出现在输入文件
中
-Dmacro
相当于C语言中的#define macro
-Dmacro=defn
相当于C语言中的#define macro=defn
-Umacro
相当于C语言中的#undef macro
-undef
取消对任何非标准宏的定义
-Idir
在你是用#include"file"的时候,gcc/g++会先在当前目录查找你所制定的头
文件,如果没有找到,他回到缺省的头文件目录找,如果使用-I制定了目录,他
回先在你所制定的目录查找,然后再按常规的顺序去找.
对于#include
统的缺省的头文件目录查找
-I-
就是取消前一个参数的功能,所以一般在-Idir之后使用
-idirafter dir
在-I的目录里面查找失败,讲到这个目录里面查找.
-iprefix prefix
-iwithprefix dir
一般一起使用,当-I的目录查找失败,会到prefix+dir下查找
-nostdinc
使编译器不再系统缺省的头文件目录里面找头文件,一般和-I联合使用,明确
限定头文件的位置
-nostdin C++
规定不在g++指定的标准路经中搜索,但仍在其他路径中搜索,.此选项在创建
libg++库使用
-C
在预处理的时候,不删除注释信息,一般和-E使用,有时候分析程序，用这个很
方便的
-M
生成文件关联的信息。包含目标文件所依赖的所有源代码
你可以用gcc -M hello.c来测试一下，很简单。
-MM
和上面的那个一样，但是它将忽略由#include
-MD
和-M相同，但是输出将导入到.d的文件里面
-MMD
和-MM相同，但是输出将导入到.d的文件里面
-Wa,option
此选项传递option给汇编程序;如果option中间有逗号,就将option分成多个选
项,然后传递给会汇编程序
-Wl.option
此选项传递option给连接程序;如果option中间有逗号,就将option分成多个选
项,然后传递给会连接程序.
-llibrary
制定编译的时候使用的库
例子用法
gcc -lcurses hello.c
使用ncurses库编译程序
-Ldir
制定编译的时候，搜索库的路径。比如你自己的库，可以用它制定目录，不然
编译器将只在标准库的目录找。这个dir就是目录的名称。
-O0
-O1
-O2
-O3
编译器的优化选项的4个级别，-O0表示没有优化,-O1为缺省值，-O3优化级别最
高
-g
只是编译器，在编译的时候，产生条是信息。
-gstabs
此选项以stabs格式声称调试信息,但是不包括gdb调试信息.
-gstabs+
此选项以stabs格式声称调试信息,并且包含仅供gdb使用的额外调试信息.
-ggdb
此选项将尽可能的生成gdb的可以使用的调试信息.
2008-01-11 16:08:14
2008-01-11 15:57:43
2008-01-10 17:40:01
2008-01-03 12:25:55
2008-01-02 15:59:26
互联网的发展历史也可以说是攻击与防护不断交织发展的过程。当前，Web 安全性已经提高一个空前的高度，然而针对网站的攻击却频频得手。如何最大化的保护 Web 应用呢，IBM Rational 提出了全面的解决方案。本文将针对 Web 安全的现状、根源、以及 Rational AppScan 产品的技术细节做全面的介绍，最后阐述IBM解决方案给企业带来的深层次价值。
1 当前 Web 安全现状
互联网的发展历史也可以说是攻击与防护不断交织发展的过程。目前，全球因特网用户已达 13.5 亿，用户利用网络进行购物、银行转账支付和各种软件下载，企业用户更是依赖于互联网构建他们的核心业务，对此，Web 安全性已经提高一个空前的高度。
然而，现实世界中，针对网站的攻击愈演愈烈，频频得手。CardSystems 是美国一家专门处理信用卡交易资料的厂商。该公司为万事达 (Master)、维萨 (Visa) 和美国运通卡等主要信用卡组织提供数据外包服务，负责审核商家传来的消费者信用卡号码、有效期等信息，审核后再传送给银行完成付款手续。这家公司为超过 10 万家企业处理信用卡信息，每年业务金额超过 150 亿美元。这家已有 15 年历史的公司怎么也没想到，居然有黑客恶意侵入了它的电脑系统，窃取了 4000 万张信用卡的资料。这些资料包括持卡人的姓名、账户号码等。这是美国有史以来最严重的信用卡资料泄密事件。此次攻击事件不仅仅对消费者，对公司造成了巨大的损失，甚至对美国的信用卡产业产生了严重的影响!
1.1 Web 安全的认识误区
然而什么才是 Web 安全呢，或者说什么样的网站才是安全的呢?用户往往有一些常见的误区。
“Web 网站使用了防火墙，所以很安全”
无论是应用级还是端口级的防火墙针对的都是网络层面的攻击，通过设置可访问的端口或者应用，把恶意访问排除在外，然而如何鉴别善意访问和恶意访问是一个问题。访问一旦被允许，后续的安全问题就不是防火墙能应对了。
“Web 网站使用了 IDS，所以很安全”
通过模式识别对网络层面的攻击做出防护措施。然而类似于防火墙，通过利用程序漏洞，通过正常连接进行攻击的访问无法被识别和处理。
“Web 网站使用了 SSL 加密，所以很安全”
SSL 对网站发送和接收的信息都进行加密处理，然而 SSL 无法保障存储在网站里的信息的安全和网站访问者的隐私信息。采用 64 位甚至 128 位 SSL 加密的网站被黑客攻陷的例子举不胜举。
“漏洞扫描工具没发现任何问题，所以很安全”
当前漏洞扫描工具已经被广泛使用去查找一些明显的网络安全漏洞。同理，扫描工具无法对网站应用程序进行检测，无法查找应用本身的漏洞。
“我们每季度都会聘用安全人员(Pen Tester)进行审计，所以很安全”
人为的检测考察不仅仅效率低，不可控因素也较多，同时对于代码变更频繁的今天，Pen Tester 也无法满足全面的安全需求
然而这些方法远远不能保障 Web 应用的安全，针对应用层面的攻击可以轻松的突破防火墙保护的网站。例如：最为常见的 sql 注入攻击表现层面完全是正常的数据交互查询。对于防火墙或者入侵检测系统而言，这是最为正常的访问连接，没有任何特征能够说明此种访问连接存在恶意攻击。所以，一些简单的 sql 注入语句就可以使得装备昂贵网络安全设备的网站被轻松攻破。
1.2 Web 安全现状
令人惊诧的是，几乎所有关注 Web 安全领域的人都会存在着上面我们阐述的误区，而当前 Web 的安全现状也同时证明了这些误区的普遍性。“防火墙、IDS 是主要安全手段，SSL 保证了安全性，…”与之相对的是：互联网发展到今天，75%的安全问题竟然是出现在应用程序本身。正如上面介绍的 sql 注入攻击一样，这是防火墙、SSL、入侵检测系统无法预防、解决、和应对的!
如下图所示，目前安全投资中，只有 10%花在了如何防护应用安全漏洞，而这却是 75%的攻击来源――10% Vs 75%，这是多么大的差距!这也是造成当前 Web 站点频频被攻陷的一个重要因素。
图 1. 当前安全现状统计分析图
那么，什么样的防护才是一个完整的解决方案呢?通过附图 2 我们可以看到，一个完整的 Web 防护不仅仅包含了常见的 IDS、Firewall 等防护手段，更需要针对应用本身做好安全防护，这也是解决 75%安全漏洞的手段。那么什么样的攻击是防火墙、IDS、或者 SSL 无法应对的呢，他们又是如何利用应用本身的漏洞进行攻击的呢?下面我们将做详细的阐述。
图 2. Web 应用的网络防护
常见针对 Web 应用攻击的十大手段
目前常用的针对应用漏洞的攻击已经多达几百种，最为常见的攻击为下表列出的十种。
| 应用威胁 | 负面影响 | 后果 |
|---|---|---|
| 跨网站脚本攻击 | 标识盗窃，敏感数据丢失… | 黑客可以模拟合法用户，控制其帐户。 |
| 注入攻击 | 通过构造查询对数据库、LDAP 和其他系统进行非法查询。 | 黑客可以访问后端数据库信息，修改、盗窃。 |
| 恶意文件执行 | 在服务器上执行 Shell 命令 Execute，获取控制权。 | 被修改的站点将所有交易传送给黑客 |
| 不安全对象引用 | 黑客访问敏感文件和资源 | Web 应用返回敏感文件内容 |
| 伪造跨站点请求 | 黑客调用 Blind 动作，模拟合法用户 | 黑客发起 Blind 请求，要求进行转帐 |
| 信息泻露和不正确的错误处理 | 黑客得到详细系统信息 | 恶意的系统检测可能有助于更深入的攻击 |
| 被破坏的认证和 Session 管理 | Session token 没有被很好的保护 | 在用户推出系统后，黑客能够盗窃 session。 |
| 不安全的木马存储 | 过于简单的加密技术导致黑客破解编密码 | 隐秘信息被黑客解密盗窃 |
| 不安全的通讯 | 敏感信息在不安全通道中以非加密方式传送 | 黑客可以通过嗅探器嗅探敏感信息，模拟合法用户。 |
| URL 访问限制失效 | 黑客可以访问非授权的资源连接 | 黑客可以强行访问一些登陆网页、历史网页。 |
在网站的应用中需要应用到大量的数据库查询检索等功能，例如最简单的例子是网站登陆，用户需要输入登陆名称和密码进行登陆认证。在早期的开发中通常使用最为简单的 select 语句实现此功能，即 select * from users where username = “XXXX” and password = “XXXX”( 假设数据库 user 表名称为 users，用户名和密码字段名称为 username 和 password)。通过截取用户在文本框中录入的字符串，再进行拼接，形成 select 语句，最终如果表 users 中有符合此条件的记录(即该用户名和密码)，系统将会返回有效记录，从而允许登陆系统中。
然而，此开发方法隐藏了一个巨大的漏洞，黑客可以通过 sql 注入攻击攻入网站。如下图所示，黑客在登陆界面录入的不是用户名，而是一串字符串 (’or 1=1 --)。黑客的目的是在原本应该录入用户的地方录入了一串字符串，导致整个 select 语句发生了变化：select * from users where username=’’or 1=1。熟知 Select 语句的人知道，在条件语句中，无论用户名称是否正确，由于 1=1 永远是正确的，所以 select 将会将所有 users 表中的数据返回。最终的结果是，黑客登陆到这个系统中。通过 sql 注入攻击，黑客可以轻松的敲入一些 sql 语句登陆进网站、对隐秘数据进行查询等等。
图 3. 攻击举例
通过上述原理描述我们可以看到，对于 sql 注入攻击无论是防火墙还是入侵检测系统都无法预防和阻止，唯一的办法是将应用本身的漏洞关闭。例如通过参数的传递配合存贮过程来实现数据库查询，这比动态的构建 sql 语句安全很多。比如在 ASP.net 中通过下面的程序将会避免攻击：
' Visual Basic example
Dim DS As DataSet
Dim MyConnection As SqlConnection
Dim MyCommand As SqlDataAdapter
Dim SelectCommand As String = "select * from users where username = @username"
...
MyCommand.SelectCommand.Parameters.Add(New SqlParameter("@username",
SqlDbType.NVarChar, 20))
MyCommand.SelectCommand.Parameters("@username").Value = UserNameField.Value
// C# example
String selectCmd = "select * from Authors where state = @username";
SqlConnection myConnection = new SqlConnection("server=...");
SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);
myCommand.SelectCommand.Parameters.Add(new SqlParameter("@username",
SqlDbType.NVarChar, 20));
myCommand.SelectCommand.Parameters["@username"].Value = UserNameField.Value;
除了注入缺陷攻击，常见的应用攻击还有跨网站脚本攻击、恶意文件执行攻击、不安全直接对象应用攻击、跨站点请求伪造攻击、信息泄漏以及利用错误处理机制展开攻击、等等。每种攻击都类似与 sql 注入攻击，根据应用程序本身的漏洞，对系统进行破坏工作，例如：获取系统权限、获取机密信息、模拟合法用户等等。
综上所述，这些利用 Web 应用漏洞的攻击是 Web 安全最主要的威胁来源，75%的攻击来源于此，只有对应用程序本身进行改造才能避免攻击。然而，如何发现这些应用漏洞是保证安全的第一前提，我们如何以最快最有效的方式发现 Web 应用本身的漏洞呢?没有高效检测手段，安全的 Web 应用将成为水中花镜中月。
3 通过 Rational AppScan 如何应对网站攻击
ibm Rational AppScan 正是应对这一挑战的利器。
如下图所示，Rational AppScan 工作方式比较简单，就像一个黑盒测试工具一样，测试人员不需要了解 Web 应用本身的结构。AppScan 拥有庞大完整的攻击特征库，通过在 http request 中插入测试用例的方法实现几百中应用攻击，再通过分析 http response 判断该应用是否存在相应的漏洞。整个过程简单易懂高效，测试人员可以快速的定位漏洞所在的位置，同时 AppScan 可以详细指出该漏洞的原理以及解决该漏洞的方法，帮助开发人员迅速修复程序安全隐患。对于攻击的特征以及测试用例用户不需要花费大量的精力，WatchFire 团队定期的对特征库进行更新，随着保证与业界的同步，最大化的提高用户的工作效率。
图 4. Rational AppScan 工作示意图
下面我们通过简单的实例介绍一下 Rational AppScan 的使用：
定义扫描
首先确定扫描站点的 URL，根据默认的模板配置向导，确定扫描的整个站点模型以及你想扫描的漏洞种类。例如，我想扫描企业应用 www.xxx.com，想根据默认值扫描是否有安全隐患，启动 AppScan，创建一个扫描，敲入 www.xxx.com; 根据配置向导直至完成。
图 5. 默认的模板配置向导
图 6. 创建一个扫描
扫描启动，进行测试
只需要点击执行。
扫描结果查看
如图所示，AppScan 以各种维度展现了扫描后的结果，不仅仅定位了问题发生的位置，也提出了问题的解决方案。
图 7. 扫描后的结果
4 Rational AppScan 深入介绍
Rational AppScan 同时提供了很多高级功能，帮助客户对复杂应用进行检测。支持的扫描配置有：
Starting URL：起始 URL，制定被测应用的起始地址
Custom Error Pages：制定错误网页提高测试效率
Session IDs：管理测试过程中的 session
Automatic server Detection：自动检测应用所在的应用服务器、web server、操作系统
Exclusion and Inclusion：制定哪些 Web 被扫描或者被排除，哪些文件类型不被扫描
Scan Limits：其他高级扫描限制，例如扫描次数限制等
Advanced：扫描的方式，是宽度扫描还是深度扫描
Communication Settings：对扫描中的延时、线程数量进行配置
Proxy Settings：代理设置vLogin/logout：对被测应用的登陆进行设置，可以采用录制回放的方式、也可以使用自动登陆的方式
configure a Test Policy: 配置测试测量，即想测试哪些漏洞。
……
如上所述，用户可以通过 AppScan 进行一系列高级配置，制定所要检测的 Web 模型，即哪些需要扫描、哪些不需要、扫描的方式等等;也可以定义需要扫描漏洞的列表，从而保证了用户关心的网站模型有无用户所关心的安全漏洞。在检测出安全漏洞之后，AppScan 又提供了全面的解决方案帮助客户快速解决这些问题，最大化的保证 Web 应用的安全。另外，对于 Web 服务 AppScan 同样可以支持。
AppScan 提供了完善的报表功能，可以支持用户对扫描的结果进行各种分析，包括对行业或者法规的支持程度;同时，AppScan 也提供了一系列的小工具，例如：Authentication Tester 通过暴力检测方法扫描被测网站的用户名称和密码;HTTP Request Editor 提供了编辑 Http request 的功能，等等。
5 Rational AppScan 的使用场景
在整个软件开发生命周期中的各个阶段，Rational AppScan 都可以被使用，全面的保障了软件的安全性。如下图所示，软件开发过程中，软件开发人员、软件测试人员、QA、审核人员等诸多角色都可以通过 AppScan 检测应用，将漏洞尽早挖掘出来。下面我们通过一些使用场景介绍一下 AppScan 给软件开发带来的利益。
图 8. AppScan 使用场景
5.1 开发人员使用 AppScan
开发人员在开发过程中可以使用 AppScan 或者专用插件，随时开发随时测试，最大化的保证个人开发程序的安全性。越早发现问题，解决问题的成本就越低，这为 Web 应用的安全提供了最为坚实的基础保障。
测试人员使用 AppScan
系统测试人员使用 AppScan 对应用做全面的测试，一旦发现问题，可以快速的生成 defect，通过与 ClearQuest 的集成可以实现 defect 电子化跟踪，再传递到开发人员手中，指导开发人员迅速解决问题。极大的提高了开发团队的开发效率，也提供了完整了沟通平台解决方案。
5.3 审核人员上线前使用 AppScan
这是系统上线前的安全质量关卡。任何系统上线都应该经过严格的上线测试，这也最大化的减少了上线后问题的出现，避免生产系统上线后给企业带来的巨额损失。
5.4 上线后审计、监控人员使用 AppScan
上线的系统应该定期检测，一旦出现问题更应该及时检测，越快速的定位发现问题，损失就会越小。
上面我们介绍的是比较通用的使用场景。当然，不同的企业可能不同的特点，AppScan 使用场景的原则是最大化的提高使用效率、尽早的把问题暴露出来，为应用安全打下坚实的基础。每个企业都可以根据自身的开发现状定义适合自己的使用模式。
6. 为企业带来的收益
通过上面的介绍，我们对 Web 安全现状、应用安全重要性、以及应用安全产品 Rational AppScan 的使用有了一定的认识。但是，工具带给客户的不仅仅是一些功能，更为重要的是给企业带来的深层次的收益，给企业在开发过程、安全策略等层面带来了深刻的变化 . 下面我们从几方面阐述 AppScan 给企业带来的价值：
AppScan 是 Web 应用安全的坚实保障
正如上面所论述的一样，当前 Web 安全 75%的漏洞出自于应用本身，快速全面的定位问题并提供完善的解决方案将会帮助开发团队构建一个健壮的应用。
AppScan 使得开发成本降低、开发效率提高
开发测试人员通过 Rational AppScan 可以迅速的定位安全隐患，早期发现问题不仅有助于解决问题，更降低了开发成本，避免问题过晚出现所造成的巨大损失。
AppScan 给企业提供了统计分析能力
Rational AppScan 提供了灵活报表功能，可以支持对扫描结果进行统计分析;支持对规范法规遵循的分析;更提供了 Delta 比较报告，可以比较两次检测的结果从而作为质量检验的基础数据 AppScan 帮助建立企业级的测试策略库
Rational AppScan
帮助企业根据不同的应用类型建立不同的测试策略，同时用户可以定义针对不同威胁的解决方法，持续的知识积累保证了企业拥有更完善的安全解决方案。
总结
综上所述，随着 Internet 的蓬勃发展，Web 的安全性已经被空前重视，薄弱的安全性也成为了很多企业发展的瓶颈。然而，即便安全性如此受重视的今天，很多人对如何保障 Web 的安去性都存在着巨大的误区。现实表明，只有加强 Web 应用的防护，才能有效的防范 75%的攻击，Web 应用的防护已经成为安全话题中最为不可获缺的部分。IBM Rational 提供了 Rational AppScan 解决方案，在 Web 开发、测试、维护、运营的整个生命周期中，帮助企业高效的发现、解决安全漏洞，最大限度的保证了应用的安全性，为企业发展提供了坚实的技术保障。
2007-12-27 13:26:01
2007-12-27 09:49:15
2007-12-07 09:47:34
2007-11-22 21:03:45
对于 PHP 来说，单元测试框架是 PHPUnit2。可以使用 PEAR 命令行作为一个 PEAR 模块来安装这个系统：% pear install PHPUnit2。
在安装这个框架之后，可以通过创建派生于 PHPUnit2_Framework_TestCase 的测试类来编写单元测试。
  |
|
我发现开始单元测试最好的地方是在应用程序的业务逻辑模块中。我使用了一个简单的例子：这是一个对两个数字进行求和的函数。为了开始测试，我们首先编写测试用例，如下所示。
<?php |
这个 TestAdd 类有两个方法，都使用了 test 前缀。每个方法都定义了一个测试，这个测试可以与清单 1
一样简单，也可以十分复杂。在本例中，我们在第一个测试中只是简单地断定 1 加 2 等于 3，在第二个测试中是 1 加 1 等于 2。
PHPUnit2 系统定义了 assertTrue()
方法，它用来测试参数中包含的条件值是否为真。然后，我们又编写了 Add.php 模块，最初让它产生错误的结果。
<?php |
现在运行单元测试时，这两个测试都会失败。
% phpunit TestAdd.php |
现在我知道这两个测试都可以正常工作了。因此，可以修改 add()
函数来真正地做实际的事情了。
<?php |
现在这两个测试都可以通过了。
尽管这个TDD的例子非常简单，但是我们可以从中体会到它的思想。我们首先创建了测试用例，并且有足够多的代码让这个测试运行起来，不过结果是错误的。然后我们验证测试的确是失败的，接着实现了实际的代码使这个测试能够通过。
我发现在实现代码时我会一直不断地添加代码，直到拥有一个覆盖所有代码路径的完整测试为止。在本文的最后，您会看到有关编写什么测试和如何编写这些测试的一些建议。
|
|
在进行模块测试之后，就可以进行数据库访问测试了。数据库访问测试 带来了两个有趣的问题。首先，我们必须在每次测试之前将数据库恢复到某个已知点。其次，要注意这种恢复可能会对现有数据库造成破坏，因此我们必须对非生产数据库进行测试，或者在编写测试用例时注意不能影响现有数据库的内容。
数据库的单元测试是从数据库开始的。为了阐述这个问题，我们需要使用下面的简单模式。
DROP TABLE IF EXISTS authors; |
清单 5 是一个 authors 表，每条记录都有一个相关的 ID。
接下来，就可以编写测试用例了。
<?php |
这组测试覆盖了从表中删除作者、向表中插入作者以及在验证作者是否存在的同时插入作者等功能。这是一个累加的测试，我发现对于寻找错误来说这非常有用。观察一下哪些测试可以正常工作，而哪些测试不能正常工作，就可以快速地找出哪些地方出错了，然后就可以进一步理解它们之间的区别。
最初产生失败的 dblib.php PHP 数据库访问代码版本如下所示。
对清单 8 中的代码执行单元测试会显示这 3 个测试全部失败了：
% phpunit TestAuthors.php |
现在我们可以开始添加正确访问数据库的代码 —— 一个方法一个方法地添加 —— 直到所有这 3 个测试都可以通过。最终版本的 dblib.php 代码如下所示。
<?php |
在对这段代码运行测试时，所有的测试都可以没有问题地运行，这样我们就可以知道自己的代码可以正确工作了。
|
|
对整个 PHP 应用程序进行测试的下一个步骤是对前端的超文本标记语言（HTML）界面进行测试。要进行这种测试，我们需要一个如下所示的 Web 页面。
这个页面对两个数字进行求和。为了对这个页面进行测试，我们首先从单元测试代码开始入手。
<?php |
这个测试使用了 PEAR 提供的 HTTP Client 模块。我发现它比内嵌的 PHP Client URL Library（CURL）更简单一点儿，不过也可以使用后者。
有一个测试会检查所返回的页面，并判断这个页面是否包含 HTML。第二个测试会通过将值放到请求的 URL 中来请求计算 10 和 20 的和，然后检查返回的页面中的结果。
这个页面的代码如下所示。
这个页面相当简单。两个输入域显示了请求中提供的当前值。结果 span 显示了这两个值的和。<span>
标记标出了所有区别：它对于用户来说是不可见的，但是对于单元测试来说却是可见的。因此单元测试并不需要复杂的逻辑来找到这个值。相反，它会检索一个特定
<span> 标记的值。这样当界面发生变化时，只要 span
存在，测试就可以通过。
与前面一样，首先编写测试用例，然后创建一个失败版本的页面。我们对失败情况进行测试，然后修改页面的内容使其可以工作。结果如下：
这两个测试都可以通过，这就意味着测试代码可以正常工作。
不过对 HTML 前端的测试有一个缺陷：JavaScript。超文本传输协议（HTTP）客户机代码对页面进行检索，但是却没有执行 JavaScript。因此如果我们在 JavaScript. 中有很多代码，就必须创建用户代理级的单元测试。我发现实现这种功能的最佳方法是使用 Microsoft® Internet Explorer® 内嵌的自动化层功能。通过使用 PHP 编写的 Microsoft Windows® 脚本，可以使用组件对象模型（COM）接口来控制 Internet Explorer，让它在页面之间进行导航，然后使用文档对象模型（DOM）方法在执行特定用户操作之后查找页面中的元素。
这是我了解的对前端 JavaScript. 代码进行单元测试的惟一一种方法。我承认它并不容易编写和维护，这些测试即使在对页面稍微进行改动时也很容易遭到破坏。
|
|
在编写测试时，我喜欢覆盖以下情况：
这是有关单元测试的几点想法。有关如何编写单元测试，我也有几点建议：
|
|
单元测试对于工程师来说意义重大。它们是现在热门话题敏捷开发过程（这个过程非常强调编码的作用，因为文档需要一些证据证明代码是按照规范进行工作的）的一个基础。单元测试就提供了这种证据。这个过程从单元测试开始入手，这定义了代码应该实现但目前尚未实现的功能。因此，所有的测试最初都会失败。然后当代码接近完成时，测试就通过了。当所有测试全部通过时，代码也就变得非常完善了。
我从来没有在不使用单元测试的情况下编写大型代码或修改大型或复杂的代码块。我通常都是在修改代码之前就为现有代码编写了单元测试，这样可以确保自己清楚在修改代码时破坏了什么（或者没有破坏什么）。这是为了开发交付的代码提供了很大的信心，相信它们正在正确运行。
2007-10-18 18:15:25
2007-08-16 15:30:27
2007-08-07 18:15:16
2007-08-07 18:14:19
2007-08-07 18:11:49
2007-08-07 18:10:19
2007-08-07 18:09:41
2007-08-07 18:09:00
