巴别塔工人

【来源】CSDN

国外开发者博客中有一篇有趣的文章，将程序员按水平像软件版本号那样划分为不同的版本。相对于在招聘时分为初级，中级，高级程序员，直接表明需要某种语言N版本的程序员或许更方便直接。根据作者的观点，可将WEB开发者大致分为以下几个版本：

Alpha：阅读过一些专业书籍，大多数能用Dreamweaver或者FrontPage帮朋友制作一些Web页面。但在他们熟练掌握HTML代码以前，你大概不会雇佣他们成为职业的WEB制作人员。

Beta：已经比较擅长整合站点页面了，在HTML技巧方面也有一定造诣，但还是用Tables来制作页面，不了解CSS，在面对动态页面或数据库连接时还是底气不足。

Pre Version 1 (0.1)：比Beta版的开发者水平要高。熟悉HTML，开始了解CSS是如何运作的，懂一点JavaScript，但还是基于业余水准，逐步开始关心动态站点搭建和数据库连接的知识。这个版本的WEB开发人员还远不能成为雇主眼中的香饽饽。

1.0: 能够基本把控整个站点开发，针对每个问题尽可能的找到最直接的解决办法。但对可测性，可扩展性以及在不同(层)框架下如何选择最合适的WEB设计工具尚无概念。这个版本的WEB开发者有良好的技术基础，需要有进一步的帮助和指导。

2.0：懂面向对象的编程语言，理解分层开发的必要性，关注代码分离，对问题寻找更完美的解决方法，偶然也会考虑设计 模式的问题，但对此仍然概念不清。属于优秀的初级开发者，能完成较松散的代码开发(相对大型严谨的站点开发而言)，在面对较复杂问题寻找解决办法时需要周 边人的帮助。

3.0：开始较为深入的理解面向对象编程和设计模式，了解他们的用途，当看到好的设计模式时能看透其本质，逐步关注分 层的架构解决办法和可测试性。理解不同的开发语言并能说出他们的异同(例如各自的优势)。属于优秀的中级别开发者，雇主也确信他们最终能找到问题的解决办 法，这个版本的人可以给1.0和2.0的开发者以指导。但他们对架构的理解仍然不够清晰，值得一提的是，只要给予一些指导，他们能很快理解并熟记做出的决 定，以及选定方案的优势所在。

4.0：理解模式，重视用户的反馈。着手研究方法论，架构设计和软件开发的最佳入口。头脑中已经形成了超 越开发语言，技术架构的整体方案，可根据需求解构程序。能从理论的角度，不同模式如何融合成最佳形态，将多种X-驱动的模式应用到不同的方案中。是精通多 语言的高手，理解不同系统和方法论的细微差别，属于高级程序员。这个级别的人能够轻易的辅导2.0和3.0的程序员，将他们推向更高的级别。

5.0：从系统的角度考虑问题。对各种系统结构有深入研究，能对整个代码架构中的问题进行改进。在团队粘合性以及代码 安全性方面有杰出贡献。对1.0到4.0版本的开发人员出现的问题能及时察觉，让整个团队保持积极性且保持兴奋的状态创建软件解决办法。举例来说，他们总 是对新的技术和信息保持饥渴状态，试图用最简便的方案解决开发任务。在整个IT团队中获得信任，属于高级程序员和架构师。

那么，您属于哪个版本的程序员呢？

【作者】Leonid Mamchenkov
【来源】 CSDN

PHP 应用的复杂程度越来越高，而 PHP 却因为不够漂亮而吸引和保留不了优秀的程序员。结果呢？越来越多的应用是那些不够水平的开发者写的。于是，PHP 也越来越难找到合格的开发者。

在过去的六个月甚至更长的时间里，我至少在为三家公司寻找 PHP 开发者。我和一些程序员聊过，收到了一些反馈，甚至还面试了几个人，但是我却从来没有推荐过任何人。

在我解释之前，先别抨击我的要求太高。我并不是在寻找火箭科研人员，也不是找同样高端的开发者，我甚至都不打算找一个高级的 PHP 开发者。只要有足够的水平来维护 CakePHP 和 WordPress 这两个项目的人就够了，更何况，它们还是开源的。

我理解并不是每个人都使用过 CakePHP 和 WordPress 来做开发。我也明白熟悉这些代码和通读相关文档都需要一些时间。更知道不是每个人都熟悉开源软件开发模型，不是每个人都在团队里工作过，所以，熟悉版本控 制软件，文档编辑工具和 bug 跟踪等等都不在要求范围之内。

但是我不明白的是，为什么那些自称使用 PHP 和 MySQL ，至少开发过两个 web 项目的人，却不能用纸笔写出最简单的代码？为什么有数年 PHP 开发和团队领导经验的“高级 web 工程师”，面对没有 Dreamweaver 的开发环境时却一无是处？那些至少拥有一个计算机科学学士学位的开发者，却还在崇尚冒泡排序法？为什么程序员不再回答技术问题，反而开始向潜在的雇主讲述 面试经历？为什么拥有数年团队合作经验的技术人员，在面试时哪怕是被问到最简单的技术问题，都会茫然不知所措？

如果你想知道上面这些问题的答案，这里正好有个例子。比如说，有个简单的问题：“stack (也称为 FILO ) 和 queue (也称为 pipe 或者 FIFO) 两者之间有什么不同？”答案就已经明显地隐藏在问题之中了，不是么？

这些自称有好几年开发工作和项目经验的应聘者，在面试时通常会遇到一些简单的程序问题。比如下面这个问题： “使用 PHP 创建一个存储人物信息的列表，人物信息包括姓名、年龄和性别，向其中添加三个样本。然后按列表中的男性名字的字母序排出一个列表，如果不使用数据库会有额 外加分。”每个应聘者只有一张纸，一支笔，和无限制的答题时间。但是在这六个月里，我还从没看过有人能手写代码解决这些问题。

我们通过所有的招聘网站、报纸、各地社区和职业介绍所来寻找应聘者，结果却是无一成功。现在我们只需要三个人，但是在不久的将来空缺将更多。

这就像塞浦路斯 (地中海东部一岛国，人口约82万) 上的人力资源状况一样，需求大于供给，但是仍然无济于事。所以我也希望你们了解我的感受。

想讨论塞浦路斯这个在科技领域里又小又不注目的国家，你们还是得等一等吧。去年我去了希腊博主露营会，今年 我又去了阿姆斯特丹的下一代网络大会。在这两个大会上，我和来自欧洲和美国的朋友们都聊过。我也访问过各地的社区和招聘网站。我的感受是，这不仅仅是和塞 浦路斯所面临的问题一样。当然，因为其地理原因和科技水平地位，塞浦路斯的情况确实是比其他地区要严重一些。

现在，我仍然在花费大量的时间来寻找 PHP 开发者，但是同时我也在思考这个问题的根源。PHP 看起来是种很流行的语言，但是为会在寻找一个好的 PHP 开发者时会遇到这样的问题呢？我得出这样一种理论，也许称其为一系列的假设和推测比较好。

PHP 是丑陋的语言

我本人认识一些优秀的开发者，我也读过更多优秀开发者的博客文章。尽管他们常常使用 PHP ，有些还把 PHP 作为日常开发基础语言，但是我却从来不记得他们其中有任何人说过喜欢 PHP 语言。如果在新项目时有开发语言的选择的可能，他们会选择 Java，C，Python，Perl，Ruby on Rails，Haskell等等，但就是不会选择 PHP 。PHP 有它的优势，但是却不是一种漂亮和方便的开发语言。

PHP 是面向新手的语言

PHP 之所以如此流行，原因之一就是它是面向新手的语言，人们可以不需要任何编程基础就开始编写 PHP 应用程序。 大多数应用提供商会提供 PHP 开发程序给你，而这些程序每个月的激活费不过是少之又少。你可以在任何文本编辑器里写 PHP 程序，所以你也不需要高性能的机器或是昂贵的 IDE 。HPH.net 开发网站上有所有你所需要的开发文档和实例，所以你也不必在学校苦学，更不必和开发者网站签订使用协议。对编程新手来说，所有这些都是让 PHP 吸引力十足的原因。

PHP 回避了某些问题

大多数我认识的优秀程序都有一定的 PHP 水平，而那些差劲的程序也学习过一些 PHP。但是对于优秀程序员来说，PHP 既不是他们的所在领域的第一位语言，也不是他们的发展方向。而我所知道的大部分差劲程序员，却只了解 PHP 这一种语言，而且他们并不精通 PHP。所以，对于优秀程序员来说，学习和使用 PHP 不过是一时需求；而对于那些差劲者来说，使用 PHP 却是永久的习惯。

因为次要原因流行的 PHP

有很原因促成了 PHP 的流行：免费，开源，易于上手，等等。大多数应用提供商都提供可用的 PHP 开发包，而很多程序里就已经预置了 PHP 。而 PHP 本身最大的特点，比如执行速率，资源要求，开发速度等等，却和其他很多语言没有多大差别。PHP 不过是因为一些次要原因而流行起来罢了。

PHP 已经过时

PHP 起源于 Perl 中过时的 web 开发库，它已经发展和扩展成熟甚至过时，那些用 PHP 编写的项目也是如此。如果说以前大部分 PHP 项目做的是的最简单的事情，比如连接注册表单，访问者计算和一些模板，那么，现在这些 PHP 项目的处理能力已经在用户管理，金融操作，高实用性和平衡配置等需求上到达了瓶颈。

冲突

现在来说说 PHP 所面临的两难境地。PHP 应用的复杂程度越来越高，而 PHP 却因为不够漂亮而吸引和保留不了优秀的程序员。结果呢？越来越多的应用是那些不够水平的开发者写的。于是，PHP 也越来越难找到合格的开发者。(你自己的 PHP 项目也变得越来越复杂。)

问题？

我们怎样才能吸引优秀的开发者来做 PHP 开发？最大的原因就是不能找到合格的开发者，这个问题也困扰其他一些开发语言。其他的开发语言能解决这个问题吗？这个问题真的有解决之道吗？

出路

和别人一样，我也没有解决方法。但是，我却看好服务应用提供商，比如 Amazon 和 Google 。他们可能会在几个月甚至几年后才过时，但是到时又会有更多的服务商加入进来 (Yahoo，微软，或 IBM ？) 。

我认为提供应用服务的方式应该是这样的。首先，他们应该把程序员类为两类。第一类是新手程序员，他们既不知 道也没有多少资源可以调配，他们要通过服务商的提供来使用服务，数据库，函数库和编程界面。(当然，优秀程序员也可以使用这些，但是他们另有选择，而不像 新手一样。) 提供的应用服务应该会方便地解决他们所不了解的东西，并且可以随时随时帮助他们。特别是像 PHP ，已经这样做了数年了。而优秀程序员大多数都会参与到核心项目和专项开发中，他们则会需要更多的知识和经验。

【原文】Angelo’s Blog

1990年，万维网之父蒂姆•伯纳斯-李（Tim Berners-Lee）开发出了第一个网页浏览器ViolaWWW，随即很多出色的程序员加入了网页浏览器开发的行列。

终于在1993年1月，NCSA（National Center for Supercomputing Applications，美国国家超级电脑应用中心）完成革命性的创新，在Unix平台上开发出了第一个图形化的网页浏览器Mosaic（Alpha 版），同年九月发布的1.0正式版实现了在Apple Macintosh和Microsoft Windows平台上的运行，一时间Mosaic俨然成为 Web浏览器的标准。随后NCSA将Mosaic的商业运营权转售给了Spyglass公司，该公司又向包括微软公司在内的多家公司技术授权，允许其在 Mosaic的基础上开发自己的产品。

1994年Mosaic研发的核心成员马克•安德森（Marc Andreessen）和几何图形发生器的发明人吉姆•克拉克（Jim.H.Clark）共同创立了Mosaic Communication Corporation。同年11月为了避免与NCSA的法律纠葛，公司更名为Netscape Communication Corporation即网景公司，并一直沿用。其中后者还先后创立了Silicon Graphics（视算）公司和Healtheon（永健）公司。

在二人领导下，公司合力进行超越以往浏览器的新一代浏览器的研发，试图打破Mosaic的垄断并取得业界的领导地位。所以对新浏览器名为 Netscape Navigator，即“导航者”。对内其1.0版本的研发代号则为Mozilla！Mozilla一词是由“Mosaic Killa”（Mosaic杀手/终结者，Killa是俚语中Killer的拼法）和“Godzilla eat the Mosaic”（Godzilla,即“哥斯拉”，日本遭受核打击和“第五福龙丸”事件后创造的经典虚拟生物）合成而来。即Mosaic＋ Godzilla＋Killa＝Mozilla！读作[mәu’zilʌ]。网景公司员工也常将其称作Moz或Mozzie。

起初，网景公司尝试了很多图标。最后考虑到哥斯拉是一只由遭到核辐射的蜥蜴演化而成的怪兽，最终决定采用一只会喷火的绿色蜥蜴造型。并由其员工戴夫 •泰特 斯（Dave Titus）于1994年设计完成。在1995年网景浏览器1.1版中，网景公司开发人员首先在浏览器内加入了启示文学《Mozilla之书》（《The Book of Mozilla》）！这并不是一本真的书，只要你在地址栏中键入about:mozilla便可以看到书中的“节录”（至今依旧如此，随版本不同内容亦不 同）。在这个首次出现被称为“12:10”（12:10这个章节编号实际上是指日期，即12月10日）的章节中，出现了一只野兽（“beast”，这也是 全书的主体），显然此时Mozilla已经被定位为一只野兽了。

在当时的环境下，网景浏览器的推出无疑是革命性的。如果说Mosaic是互联网热潮的燃点，那么NN（Netscape Navigator的官方简称）无疑是当时以至导致后来.COM热潮的最大的催化剂。自1.0的发行版推出，NN便迅速的占领了市场，并且成功取代 Mosaic成为新的Web标准。曾一度达到了超过90％的统治级市场占有率，并且一直保持这个占有率到1996年初，是其有力证据。

1995年，微软在取得NCSA授权后开发出了自己的第一代浏览器Internet Explorer 1.0（官方简称IE），并于同年8月开始在其新版32位操作系统Windows 95中搭售。目前普遍把这一时间看作是第一次浏览器大战的起点。

但是随后NN依旧保持着绝对垄断的市场占有率，故而“Mozilla”成为了几乎所有浏览器向Web浏览器发送的标识验证字符串。在网景公司的竞争 者中最 先采用这一办法的是微软公司，其IE验证字符串为Mozilla/<Mozilla版本号>(compatible;MSIE< MSIE版本号>)。直到1997年10月微软推出IE4.0版本的时候NN依然拥有72％的市场份额！

伴随着Windows 98系统的发售以及微软与ISP以及主机厂商的合作；可以加入IE专属标签的FrontPage软件的普及；对CSS的抢先支持；以及网景公司的错误决策。NN逐渐败下阵来。

为了扭转颓势，1998年2月23日。网景公司内部成立Mozilla组织（Mozilla.org），该组织独立运作来负责Mozilla Application Suite的研发。Mozilla Application Suite（简称Mozilla Suite）是一套自由的、跨平台的因特网应用套装软件，它的组件包括Navigator（网页浏览器）、Mail & Newsgroups（电子邮件客户端）和Composer（HTML编辑器）。3月31日，网景决定依托NPL（Netscape Public License，网景公共许可证）开放NN的源代码，意图在于吸引来大量的开发者完善软件。这一时期网景放弃了绿色蜥蜴的造型，开始使用一只凶猛的、线条 粗犷的、红色的、类似霸王龙的形象。在后来看到的《Mozilla之书》“3:31”章节中明显可以看出反攻的意图。并且使用了“玛门（Mammon）” 这一闪米特族语汇，用其贪婪和财富的内涵来隐喻微软。10月网景决定将Mozilla的源代码全部改写。

然而这些努力还是没有能够扭转颓势，终于在1998年11月24日，AOL（American On Line，美国在线）以42亿美元免税换股的方式收购了网景。其后Mozilla组织在AOL的资助下继续进行研发，期间IE夺取了浏览器市场的统治地 位，并于2002年达到96%的峰值。而Mozilla组织则接手了网景过去的很多事务，但是很多Mozilla的核心成员对成果并不很满意，他们把这归 结为受到投资方（AOL）的需求所累。

2002年6月5日，Mozilla推出了Mozilla Suite的1.0版本。由于Mozilla Suite主要是针对软件开发者而不是消费者，所以他们将每次的发行版本定名为milestone release（里程碑版），在每个版本为期4个月的研发周期里，第一个5周释放Alpha版（不稳定版，内测）；第二个5周释放Beta版（较稳定版， 公测）；最后几周发布正式版，期间还有可能发布RC版（release candidate，候选版）。在最后的几周中，程序的主体将用于下一版本的研发，分支将继续作稳定性适应改写。最后发行版的完成度和稳定性完全由这4个 月以及其中开发周期中程序员的完成度来决定。

2003年5月，著名的AOL诉微软垄断案达成和解。作为让步，AOL同意解散网景并中止其下业务。同年7月15日（AOL关停网景全部业务当 日）， Mozilla组织在得到了来自AOL的200万美元和米切•卡普尔（Mitch Kapor，Lotus创始人）30万美元资助后，正式注册成为了非牟利机构。并正式更名为Mozilla基金会（Mozilla Foundation，简称MF或MoFo），并注册Mozilla为期商标。标识为恐龙形态的Mozilla头部（右）半面相。该基金会主体拥有免税资 格。其成立目的在于保证Mozilla计划在没有网景之后可以继续下去。早在同年3月Mozilla组织就决定放弃冗杂的业务，把精力投入到其旗下的两个 旗舰产品Firefox和Thunderbird中。在9月释出的《Mozilla之书》“7:15”章节中，描述了巨鸟用火（Fire）与雷 （Thunder）驱散玛门信徒，令野兽重生的场景。此时Firefox还在使用其第二个名字“Firebird”，所以章节中只出现了巨鸟（great bird）这一个意象。

Mozilla组织在释出Mozilla Suite1.1版本之后，便放弃了NPL（Netscape Public License，网景公共许可证）转而采用MPL（Mozilla Public License，Mozilla公共许可证）其二者都类似于GPL（GNU General Public License，GNU通用公共许可证），但是都保留了部分不可更改的权利。当自由软件基金会（Free Software Foundation，FSF，GNU计划和GPL协议的官方机构）发现了GPL与NPL以及MPL的不兼容的事实之后便像会员建议不要采用 Mozilla系产品。故而Mozilla组织/基金会在2003年逐步对下属全部产品源代码进行了向GPL的过渡。

2004年，Mozilla基金会专注于Firefox和Thunder的开发。使其逐步成为一种界面友好的消费软件。4月Mozilla基金会协 同 Opera Software（Opera是其旗下浏览器品牌）以及Apple 公司（Safari是其旗下浏览器品牌）共同成立WHATWG（Web Hypertext Application Technology Working Group）工作组，致力于开发和制定新的Web标准。并且提交W3C（World Wide Web Consortium，万维网联盟，又称W3C理事会）审核。

2005年8月3日Mozilla基金成立了完全所有的应税牟利子公司Mozilla公司。其公司初始运营资金来自Mozilla基金，其成立目的 在于推 广Firefox和Thunderbird。11月29日，在三个RC版之后Mozilla终于发布了后来广受好评的Firefox1.5正式版。由于安 全问题等多方面原因导致IE的市场占有率再次下跌至85%左右，这一时间的回落主要源于Firefox的攻击。

在2006年Mozilla基金会加强了与非本土的爱好者以及那些对Mozilla文化的认同者的联系以扩大市场。研发周期不断缩短，基本每月都有 新版本 释出。2006年10月底微软和Mozilla同时释放出IE7以及Mozilla Firefox2.0的正式版本。虽然在短时间之内IE7的下载量就突破了百万，但是却不能挽救其市场占有率持续下降的势头。Mozilla Firefox和Opera成为其主要竞争对手，另外Safari也保有了一定的市场份额，在这一时期Firefox的市场份额一直稳定的保持在10%以 上。Firefox2.0和IE7的同时释出被很多人看作是浏览器第二次大战的开端。Mozilla公司在2005年底开始的与Google合作计划也顺 利的进行着，06年上半年正式推出了带有Google工具条的Firefox正式版本，伴随Google推广攻势的展开取得了显著的效果。但是 Mozilla公司一直没有公开06年的收益，年初计划启动的时候曾有媒体报道这一做法为Mozilla带来了7200万美元的收入。Mozilla的首 席执行官米切尔•贝克（Mitchell Baker）则表示说这数字不确切，但是相差不多。

进入2007年，Mozilla似乎已经安定了下来。不想过去那么复杂多变，而是基本以一个商标或者品牌的形象出现（虽然大家还是习惯说只用 Mozilla描述基金会和公司）。5月30日，Mozilla放出了Firefox1.5的最后一版（1.5.0.12），并且公布在07年的第三季度 放出3.0的正式版。前两个季度Mozilla旗下的Firefox和Thunderbird都在保持持续的增长，不仅在欧洲市场发展稳定而且在亚洲市场 也开始被认同。6月下旬Mozilla基金会决定在中国大陆投资成立子公司谋智网络公司（谋智，Mozilla的音译），由前微软Windows Live中国区总经理宫力出任董事长兼CEO。并于7月正式挂牌营业。

至此，Mozilla的历史还在延续……

【原文】IT168
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

本文将 web 测试分为 6 个部分：
1. 功能测试
2. 性能测试（包括负载/压力测试）
3. 用户界面测试
4. 兼容性测试
5. 安全测试
6. 接口测试

本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。

一、功能测试

1.1 链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
采取措施：采用自动检测网站链接的软件来进行。
推荐软件：
Xenu Link Sleuth 免费 绿色免安装软件
HTML Link Validator 共享（30天试用）

1.2 表单测试
当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

1.3 数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。

1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。

1.4 cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。
采取措施：
1 采用黑盒测试：采用上面提到的方法进行测试
2 采用查看cookies的软件进行（初步的想法）
可以选择采用的软件
IECookiesView v1.50
Cookies Manager v1.1

1.5 数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
采取措施：暂时没有更好的测试方法
考虑结合到1.2和1.3的测试中

1.6 应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
采取措施：深刻理解需求说明文档

1.7 设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、javascript、 ActiveX、VBScript或Perl等也要进行验证。
暂时没有方法测试，可以多参考一点讨论组内的更新信息

二、性能测试

2.1 连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2.2 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

2.3 压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
•负载/压力测试应该关注什么？
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
•瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。
•每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?
•长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。
但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
采取措施：采用测试工具WAS、ACT协助进行测试

三、用户界面测试

3.1 导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

3.2 图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到 30k 以下
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

3.3 内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。
在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。

3.4 表格测试
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?

3.5 整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
采取措施：手动测试，参与人员最好有外部人员

四、兼容性测试

4.1 平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

4.2 浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、javascript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

4.3 分辨率测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

4.4 Modem/连接速率
是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。

4.5 打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

4.6 组合测试
最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。
采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵

五、安全测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。

5.1 目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

5.2 SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

5.3 登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

5.4 日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

六、接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。

6.1 服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中

6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到

6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。

七、结论
无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。

腾讯科技讯(http://tech.qq.com/a/20080523/000270.htm)
5月23日上午，中国移动通信集团公司发言人通报：中国铁通集团有限公司并入中国移动通信集团公司，成为其全资子企业，目前仍将保持相对独立运营。

此外，中国移动通信集团公司领导班子也进行相应调整。王建宙继续担任中国移动通信集团公司总经理，并担任党组副书记；张春江任中国移动通信集团公司党组书记、副总经理；中国移动通信集团公司原有副总经理继续留任；同时新增赵吉斌、张晓铁、李正茂为中国移动通信集团公司副总经理，党组成员。

据悉，上述调整不涉及中国移动有限公司（0941. HK）。

我国电信业重组拉开帷幕。截止到23日上午11：30，中国联通、中国电信、中国网通等运营商尚未公布重组消息。