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

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

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

注:这一个系列是我在看原版的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.1性能测试

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

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

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

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

Technorati Tags: , ,

怎么在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: , ,

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

注:这一个系列是我在看原版的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 商务层的测试

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

你要通过白盒测试来接近内部开发的组件,因为你可以知道程序的内部逻辑。然而,黑盒测试才是你在这一层测试的时候主要的技术手段。你要从开发测试驱动来组合测试独立的组件。(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: , ,

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

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

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

注:这一个系列是我在看原版的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 测试的战略

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

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

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

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

Photo sharing and image hosting

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

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

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

Technorati Tags: , ,

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

注:这一个系列是我在看原版的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.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定义了一些在测试中非常重要的部分,这个可以保证你的用户可以在你的网站上得到积极的体验。

Photo sharing and image hosting

因为第一印象是最重要的印象,你的一部分测试精力将会集中在测试可用性和面向人类的影响。(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: , ,

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

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

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

9.1 基本的电子商务网站结构

在一头扎进测试基于网络的程序之前,我们先来看看在典型的基于网络电子商务的C/S的三层结构吧。从概念上来讲,每一层都可以作为一个很好地定义了接口的黑盒。这样的模型的好处是,你可以改变每层的内部不用担心这种改变会影响到其他的层。

虽然不是一个非常正式的结构,但是客户端和它的关联是非常值得讨论的。尽管从设计上来说比如手机,冰箱,传呼机还有汽车都开始可以连接到互联网,但是大多数和你的程序的联系都是存在与一台运行着浏览器的电脑上。浏览器戏剧性地呈现他们从网站上得到的内容。就像我们稍后会提到的,测试浏览器的兼容性是一项和互联网测试相关的挑战。内容提供者轻松地跟随已经发布的标准来帮助浏览器表现的一致,但是他们的独家增加的内容可能会导致一些不一致的行为。通常客户端使用的自定义程序就像管道一样通向一个特定的站点。在这个情况下,程序模仿一个你可能会在公司本地网路中看到的标准的C/S程序。

Web服务器是三层结构的第一层,而且也是网站所存放的地方。一个互联网程序的外观和感觉都是来自这个第一层。因此,也有的说法称呼这一层为展示层,它有这个称呼的原因是因为它向最终客户提供了可视化的内容。Web服务器可以使用HTML页面文件来提供静态的内容,也可以使用CGI脚本来提供动态的HTML内容,但是有很大的可能是提供了静态和动态。

第二层,又被称为商务层,程序服务器就是这一层。你在这里可以运行你那些展示你商业进程的软件。(?)一下的列表包含了一些和商务层相关的功能:
. 处理过程
. 用户认证
. 数据校验
. 程序的日志

第三层关注的是从数据源中存储和读取数据,其中有代表性的是RDBMS(关联数据库管理系统),第三层又被称为数据层。这一层是由数据库的最底层结构组成用来和第二层通讯的。数据层的接口是由数据模型定义的,它描述了你希望怎样了存储数据。有时候这一层有好多个数据库服务器组成。你通过典型的调整这层中的数据库系统来处理电子商务网站遇到的高交易量问题。(You typically tune database systems in this layer to handle the high transaction rates encountered in an e-commerce site.)关于数据库服务器,一些电子商务网站也可能在这层增加一个认证服务器。最有可能的是,你使用一个LDAP服务器来实现这个功能。

Technorati Tags: ,

囧,这个字你认识么?

在和Carol聊天聊两岸的流行语。感谢Carol教会了一个我想认识很久的字“囧”。
这个字你认识么?这个字念“Jiong”第三声,同窘。意思也和窘差不多,所以可以说“很囧”原因是什么呢?因为它实在长得相张人脸…

Technorati Tags: ,

活到老学到老,ATOM和RSS的区别

Fenng对他的MT RSS做了一些修改,使得输出的时候除了显示全文,还可以显示评论。这个方法似乎在我订阅的Blogger中间很少有人采用,所以觉得很新鲜。不过这个做法有一个不完美的地方是如果我阅读完一篇文章之后,在我的Google Reader上是不再显示了的。那么有新的评论似乎我也看不到了?

在看评论的时候看到POPOEVER说:

@Nasone: 在RSS里做全文输出?那还要ATOM干嘛?每种协议或规范完成自己的任务就可以了。

我所期待的是能解决相对路径的问题。

这个说法很新鲜,我原先光知道ATOM和RSS都是FEED的输出形式,似乎Google采用的是ATOM形式,其他的采用RSS的多些。至于他们两者具体的区别我就不清楚了。他们真的是区别在ATOM输出全文,RSS输出摘要么。

我上网查了一下,找到了这篇文章:Rss20AndAtom10Compared中文版的在这里。这篇文章比较的非常全面,通过对实施状况和性质等18个方面对RSS和ATOM进行了比较。

在完整的与部分的内容的比较上,文章是这么说的:

RSS 2.0 has a <description> element which is commonly used to contain either the full text of an entry or just a synopsis (sometimes in the same feed), and which sometimes is absent. There is no built-in way to signal whether the contents are complete.

Atom has separate <summary> and <content> elements. The summary is encouraged for accessibility reasons if the content is non-textual (e.g. audio) or non-local (i.e. identified by pointer).

RSS 2.0的元素常被用来存放entry的全部文字内容或大纲(有时是在同一个feed中),有时没有该元素出现。没有内建的方法鉴别其内容是否完整。

Atom有独立的和元素。为了可用性的原因,鼓励在内容为非文本(比如:音频)或非本地(比如:以pointer标示)的情况下使用summary。

按照这段解释来看RSS2.0协议是可以输出全文的,因为它被用来存放entry的全部文字内容或大纲, 但是它没有一种内建的方法来判定是否输出了完整的全文内容。而ATOM则不同,因为有<summary>和<content>两个不同的元素,摘要在<summary>中输出,正文内容就在<content>中输出。

所以就这么看来RSS和ATOM的区别不在于是否能输出全文,而在于能否受控制地输出全文或摘要…

而且,再进一步说:

The RSS 2.0 specification is copyrighted by Harvard University and is frozen. No significant changes can be made (although the specification is under a Creative Commons licence) and it is intended that future work be done under a different name; Atom is one example of such work.

Atom 1.0 is specified inRFC 4287 (HTML Version); it represents the consensus of the Atompub Working Group within the IETF, as reviewed and approved by the IETF community and the Internet Engineering Steering Group. The specification is structured in such a way that the IETF could conceivably issue further versions or revisions of this specification without breaking existing deployments, although there is no commitment, nor currently expressed interest, in doing so.

RSS 2.0规范已经冻结,Harvard University拥有其版权。不能做大的修改(虽然该规范处于Creative Commons 协议) 且计划未来的工作在一个不同的名称下进行;Atom是这类工作的一个例子。

Atom 1.0的规范 RFC 4287 ( HTML Version ); 体现了 IETF 内的 Atompub Working Group 大多数人的意见,并由IETF和 Internet Engineering Steering Group 讨论并通过。该规范在架构设计上使得IETF能有预期的发布新的版本或修正版本而不会破坏当前的实施。虽然这样做并没有约定,当前也没有明确的需要。

所以ATOM和RSS2.0其实在本质上是一个东西? ATOM是对RSS2.0的进一步改进,他们或许不是那么完全截然不同的两个规范。

好了,翻字典的事情就不做了,如果需要了解进一步信息的。可以去看我给出的两个链接或许更多知识。

Technorati Tags: , , , ,