November 22, 2006

赶在GFW抽风恢复之前

这段日子过得昏昏噩噩,每天都在忙,可是细细想来,都忙些啥?唔,不知道,迷茫,失去了方向。

自打C出国培训,手里的活都转给我了(基本上)。这才体会到,那个烦呀,各类大小事务无不操心!这更加坚定了不愿从事管理工作的信念。跟朋友们抱怨,可是友Y的一句:“总不能一辈子做技术吧!” …… 我该如何回答他?是啊,国内不比国外,有多少能坚持技术路线?国内似乎看不出这样的氛围。年龄大了,个人有个人的打算,公司有公司的打算。虽说公司也说职业规划于个人,但是似乎总是按照它所希望的方向进行着,无论你满不满意(当然,辞职不算在内)。唉,真是为今后担心。一切都得时间考验,走一步看一步吧。好在手里没有什么紧急的事情,都安排妥当了。事情也按计划发展,比较顺利,也算是C照顾我,痛哭流涕啊~

前阵子又买了一本曼昆《经济学原理》,真是写的不错,通俗易懂,又以新闻稿来分析经济现象,正是我喜欢的。对经济的兴趣源自多年前凤凰卫视的世纪大讲堂做客教授、学者,他们总是用简短又易懂的方式讲述每个主题内容。所以看到此书,立刻决定买下。尚未读完,却从中学到不少“新知识”,值!

还有什么好说的呢?算了,看这个吧,或许有机会我也能去一一驻留这些点。

MapMark

MapMark2

November 01, 2006

ConferenceXP Research (2)

接 ConferenceXP Research(1)

ConferenceXP 包含了两大部分:ConferenceXP client和ConferenceXP services. 其中的细节本文就不再描述,可从这里获取细节描述。较On-Demand Meeting商业版本,如WebEx的Web Conferencing和Citrix的GotoMeeting,还显得有些稚嫩和不成熟,或者说其服务的目标对象不相同,毕竟这仅是个研究项目,不属于本文研究对象。真正感兴趣的地方在于其采用的多播(注意,不是广播)技术和Venue/Reflector Services.

1. Multicast 多播

由于ConferenceXP是P2P(点对点)应用程序,其数据在client之间发送,而非来自服务器端。为了支持多用户(并发用户)占用较少的网络流量,ConferenceXP采用多播来传送数据。利用多播技术,用户近发送一次数据,其他与其建立联系的用户都将受到这些数据。如此好处是显而易见的,用户间的数据通信量大大减少。但也有其缺点,易被利用进行DoS攻击,或因为大量发送数据而产生性能问题,以及在网络边缘由于路由器或者过滤器(防火墙)终止多播传输。

ConferenceXP是为高速网络而设计的,其要求网速在2Mbps或更快。尽管其最低要求是500Kbps,丢包率小于5%,但实际流量在2-3Mbps。若要最佳性能,则需要5-10Mbps。这也符合实测的结果:两台相邻的计算机和笔记本之间,无线路由,其视频图像刷新慢,图像质量不佳。

什么是多播?多播就是允许服务器同时传送多个内容给接收者。服务器提供单一内容源,由在多播网络中的路由器来处理复制和分发内容给接收者。

实现之一是,由服务器广播到整个网段,并由路由器来维护访问列表,来决定转发或阻止这些广播消息。只有特定设备对这些消息感兴趣,而其他设备则收到并丢弃这些广播消息。

实现之二是,有一套系统负责订阅消息,而只有对这些消息感兴趣的设备才可以接收到。即,有这么一个组,对应一个有效的IP地址。当信息被请求时,系统就被加入到一个组中。再明确些,一些设备对某些消息感兴趣(称之为订阅),就将其加入到这些消息所对应的多播组中,而这个组有一个多播地址。服务器则将消息发送到这个多播组对应的多播地址上,由路由器分发这些消息给订阅者。

多播IP地址范围 : 描述

224.0.0.0 – 224.0.0.255 : 保留的已知的多播地址

224.0.1.0 – 238.255.255.255 : 全球范围内的多播地址

239.0.0.0 – 239.255.255.255 : 有限范围内(如局域网)的多播地址

发送数据包到一个IP多播组,每个IP多播组有一个唯一标示的D类IP地址。通常路由器使用IGMP协议处理多播业务。路由器和Hosts使用IGMP消息来开始、管理和停止多播服务。Host发送IGMP join-group消息来请求多播服务,路由器转发多播组数据包给这些已加入组的host。反之亦然。需要说明的是,多播服务并不一定实现在路由器中。路由器维护组的多播路由表和组的路由协议。

2. Venue Service

ConferenceXP架构没有实体服务器,而采用Venue/Reflector Services来实现多用户数据传递。

ConferenceXP Venue Service用以创建和管理venues(集合点)。集合点是用以同步用户参与的协作和学习的活动。Venue Service提供一个目录服务来确定在一个venue里所有用户的共同的多播地址。当参与者加入一个指定的venue,Venue Service将通知ConferenceXP用户程序连接指定的地址和端口。参与者加入一个venue之后,所有网络传输将使用有Venue Service提供的多播地址进行点对点传输。

3. Reflector Service

当多播不可用时,用户可以在单播(unicast)网络中使用Reflector Service来进行多播传输。例如,当您的网络中的路由器不支持多播时,或者网络阻止多播时,你可以使用Reflector Service。它允许指定一台在一个支持多播的网络中计算机来作为Reflector Service,它将负责进行多播传输并转发给您所在单播环境下的用户。

Diagram of connecting a multicast and unicast network by using a reflector server

ConferenceXP Research (1)

Keywords: Microsoft, videoconferencing, collaboration, conferencing, distributed applications, distance learning, conferencing, Tablet PC, multicast, wireless

ConferenceXP是一个由微软研究院主持的研究项目。ConferenceXP使得无线教室、协作和远程学习(教学)融为一体,其丰富的体验基于新兴的、开放的实用技术,如宽带网络、无线设备、Tablet PC(平板电脑)以及WindowsXP的高级特性。

ConferenceXP作为一个平台,能够让研究者和开发者利用ConferenceXP的高级特性技术(如平板电脑和无线网络)来创建分布式应用程序。也能够让他们开发协作工具和程序,而这些工具和程序不必依赖其它程序。作为合作者的研究机构和大学,ConferenceXP项目也包含了在知识科学具备微软技术专长的学院派的专家。ConferenceXP研究平台使大学能够建立丰富的协作应用,来增强在教室内或者外的学习体验。基于宽带连接的高质量传输、低延迟的音频视频,ConferenceXP支持开发实时协作和视频会议应用。由协作学习应用的设计和实现的公共框架,ConferenceXP也提供灵活的开放的研究平台。

ConferenceXP研究平台的设计目标:

  • 富体验 -- 将在教育、会议和协作方面的环境中集成高性能音频、视频和网络技术
  • 简单实用 -- 仅简单单击用户界面即可使参与者加入在线讨论、展示和会议。支持即插即用设备。
  • 灵活性 -- 支持无需基于服务器结构的单机单节点结构,能够在多点之间提供高质量音频和视频。同时也支持多播供应给需要高流量的大教室。
  • 扩展性 -- 提供能够供用户开发接口和应用程序的APIs。
  • 高级技术 -- 100%基于微软.Net框架的受控代码,支持无线网络和平板电脑。集成高级媒体和显示技术,如Microsoft DirectShow, Microsoft Windows Media, Microsoft DirectX.

ConferenceXP结构

由于ConferenceXP,开发者基由上层公共框架创建一套能共同使用的解决方案。公开的APIs和一套基类,使得开发者和研究者能够设计强大的新型会议和协作环境、自定义界面,将ConferencXP与现有会议和教室系统结合。

ConferenceXP使用点对点结构。由于没有服务器,这样的架构使得部署简单,防止网络瓶颈和单点失败。架构使用多播技术,为在宽带网络上的多点视频会议提供高效能和灵活性,为在802.11b无线网络上提供共享文档和墨水。如果没有多播环境,其也支持点对点的单播。

 

The architecture of the ConferenceXP research platform

续 ConferenceXP Research(2)

男孩的游戏,男人的事业

男孩的游戏,男人的事业。虽说有些夸张,对部分人来说却是事实。那会是什么呢?当然,就是参军入伍,成为军人,职业军人(特指特种部队)。

战争游戏对于男孩,如同玩偶对于女孩,其意义不必言语。男孩们无不在游戏中体验着“战争”的快乐,在“战争”中体验成为英雄的快感。那时年少无知,甚至幼稚,可这并不是罪过,仅不过是遥远的梦想中的虚拟的游戏。

然而,当梦想成为现实,当男孩成为男人,当游戏变成了事业的时候,这一切却发生了根本的改变。“游戏”不再是快乐的,刺激的,而是现实的,残酷的。原本对这个职业的模糊认识逐渐清晰起来。生死较量之下,没有重新再来的机会,没有暂停休息,只有责任,荣誉。承受着如此重压,却又不能丝毫懈怠,敌人们时刻寻找着任何可能的机会。

《The Unit》,2006年CBS推出的军事题材电视剧,目前正在热播第二季。The Unit(这里)讲述的是一支没有名字的部队, 一支不存在的部队。他们被派往全球各地,执行美国政府的秘密使命。对于这一群特殊的军人,他们的荣誉和战绩,甚至他们所执行的任务,都将封存在机密档案里。在基地里, 他们的妻子互相安慰,互相支持。除了承受士兵家属所必需承受的一切,她们还要学会保守秘密——丈夫的秘密,自己的秘密...

《The Unit》与《战火兄弟连》都是我喜爱看的片子。它们绝不仅仅是部战争片,尽管看了多遍,但每次总有些新的发现和体会。我会在以后的篇幅中结合工作谈谈自己的感想和想法。

October 19, 2006

如何招聘软件测试人员(2)

谜题测试

面试时,有些经理人常常习惯于用逻辑或者算法迷题进行智能测试,我并不反对这种做法,但我不相信这样的测试会像他们所想象的那样有意义。首先,世界上存在着大量的逻辑和算法谜题。在速度、非语言和能力测试方面,实践强化的效果更持久、更明确(见Jepson, A.R. 著、1980年出版的Bias in Mental Testing一书)。其次,速度测试的典型范例就是龟兔赛跑的故事,它足以证明速度超不过思想。或许速度很慢的“乌龟”们有时会设计出更适合的产品或产品测试方案。

一个简单的测试题目

速度测试的一个古老而备受喜爱的谜题应当首推G.J. Myers的self-as-sessment(见1979年由John Wiley & Sons出版的The Art of Software Testing一书)。测试时,给被测者一个特别简单的程序,要求生成有意义的测试案例列表。这个特定的程序包含一个集合抽象物(三角形)。我很喜欢这个谜题,原因是它检测了被测人员的实际能力:分一个程序,找出测试该程序的方法,虽然这个题目已经流传了很久,但它始终具有一定的实际意义。首先,解答过Myers这道谜题的人,一般而言,都回避从未见过该题的优秀测试员做出更好的答案。其次,即便是同等熟练的测试人员,文化上的差异也会产生不同的成绩等级。对于抽象有研究的人(例如几何抽象或者数字之间的逻辑关系),要比那些对用户界面或者产品与设备兼容性测试的人更有优势。

另一例简单测试

在画板上绘出一个打开文件的对话框,对面试者进行如下说明:“这是一个打开文件的对话框,你可以直接输入文件名,也可以点击打开按钮来打开”。然后把画板交给面试者,问问她将怎样测试该对话框。同时向她补充不限制答题时间。而且,她还可以在纸上或画板上记下自己的想法。有些应聘者只要思考几分钟就会开始回答。但是,注意不要批评或质问。

当应聘者停顿时,允许她保持沉默。在她准备完全的时候,她会继续回答。

这是一个典型测试,它允许应聘者在某种程度上可以有种多种答案。有些应聘者也许会停留在设计的表面,指出对话框设计的每一点瑕疵。例如: 没有取消按钮或者对话框标题、没有目录间切换的明显方式,等等。而另外的应聘者可能会忽略用户界面问题,将重点放在测试大文件、小文件、受损文件、扩展名不符合的文件或者远程文件(根据她在文件名栏内键入路径)的打开上。

在测试中我遇到过各种各样不同的回答,随着时间的推移,我已经对这种测试方式进行了改进。现在,我还会像以前那样给出对话框,同样不限制答题时间。在对方完成回答后,我会对她的分析表示赞许,而不在乎她的实际成绩。然后,我会向她列举她所遗漏的测试部分。同时,我还会补充说,从来没有人能够发现所有的测试疑点。有时人们会遗漏问题,只是因为过于紧张或者太匆忙。我花费大量时间列举和讨论各种不同类型的测试方法以及他们可以找出的种种bug。最终,我擦干净画板,重新画一个保存对话框,当然也是错漏百出的,然后让应聘者再试一次。

由于经过了前面的练习测试和指导,两次测验的效果差别被减小到了最少,所以真正的测试是第二次。应聘者收到考官的反馈信息,不再担心自己会当作傻瓜。实际上,大部分的应聘者在第二次的测试中都完全放松,不再那么紧张不安。

通过第二次的测试,我会明白应聘者是否对我的训练方式作出反应、应聘者是否完全理解了我的指导,并在第二次的尝试中更好更完善的加以发挥?如果答案是肯定的,我就找到了合适的应聘者(正是由这项试验测定的)。如果应聘者第二次的分析和第一次相差无几,那她或许就不是合适的人选了。也许她也很聪明、谦虚和风趣,但是,她没有能够学到我所讲述的内容,她也就不太合适于我们这个团体。

有时,我也会免去第二次测试,那一般都是因为应聘者在第一次测试中太差,或者在我的降解过程中过于固执的为自己分辨或争论不休。取消第二次测试,通常就意味着我和这位应聘者的面试实际已经结束,即使我会花一点时间来礼貌地结束这次面试,但是,我肯定不会聘任他的。

Bug报告

编写bug报告是测试人员工作中最基本的,但也是最重要的一部分。其中,有许多的因素都会影响到bug报告的质量,即便是那些有多年经验的熟练测试人员编写的报告也概莫能外。

为了测试这种能力,让面试者从你提供的软件中找出bug并写出报告。如果你所提供的软件bug太难或者太简单,那都不适合于测试,不过你可以从www.bugnet.com站点里再找一个合适的程序。评测一份bug报告很简单,不过,让你的员工试答一份答案也可以提供相对参考,帮助你判断测试者答题的质量。实际上,目前正在使用的还有不少很不错的试题和方法,但这些试题必须根据一个共同的前提: 努力去寻找一个最合适的方式,让面试者处理未来实际工作中需要面对的部分工作。这样你就能了解应聘者真正面临实际问题时的表现。所以,必须认真设计测试题目,以使面试者在不熟悉你的产品情况下,也能客观地找出软件的瑕疵。这实现起来虽然麻烦,但如果能制作这样一份公正、实用、合理的测试题目,对于你的正确选拔无疑是十分有益的。

如上所示,综合考查应聘者对各方面问题的答复,并且面试完所有的应聘者后,只要运用你手中占据的大量资料,就可以公正、准确地选择出你的最佳人选了。

--------------------

本文源自:《程序员》2001.4期,撰文Cem Kaner,编译孟迎霞

October 15, 2006

如何招聘软件测试人员(1)

公司的招聘活动是否成功,很大程度上取决于面试官所采用的面试方式和考试题目。

每个经理最头疼的一项工作就是如何招聘优秀的员工。一个看似简单的招聘决定,也许会关系到一个小组或团队的命运,而从长远来说,项目或小组的命运也直接影响到公司的成败。

在招聘软件测试人员时,一些基本的要素。当最终的人员缺口确定后,主管经理必须列出符合该职位人选的必备条件,以此来考核那些希望进入软件测试领域的应聘者的资格和等级,并同时收集相关候选人资料。

从根本上说,聘任决定通常是一整套严格的面试程序运作之后的结果,但面试人员是如何进入测试领域的?他在此领域的学识有多深?是否具备项目管理的经验?他是如何谈论他的同事、主管和职员的?他提交的报告是全面且具洞察力,还是简单又不合语法?他是怎样完成专为面试人员所设计的测试题或谜题的?这些问题往往也很重要,它是从众多面试人员中选择最具资格的优秀人才的关键要素。

测试体系

通常,在常规性的面试问答(例如有关简历、教育及工作经历的基本问题)完成之后,我会着重考察他的测试知识和测试体系。对于管理层或其他高级职位,我还会提出下列问题:

  • 什么是软件质量保证
  • 测试组的价值在哪里?你是如何证明你的工作价值并且安排预算的?
  • 和文档、技术支持等相比,测试组充当的是怎样的角色?
  • 测试人员和用户之间应当具有怎样的交互性?为什么?
  • 如何从本领域已发现的问题中学到教训?应当从中学些什么?
  • 白盒和黑盒测试工具充当的是什么角色?
  • 自动测试中会出现什么问题?如何处理这些问题?
  • 测试程序员和测试组应当使用什么开发模块?
  • 怎样使程序员对他们的代码建立易测性支持?
  • 错误追踪系统有什么用?

对于如何进行测试,我并不希望得到唯一正确的答案。我只想知道这些面试者是否仔细考虑过这些问题,而且他的见解是否合公司的观点大体一致。

例如,上述问题就是专为那些将着眼点放在测试上、而非实施标准上的公司设计的。因此,通过上述问题的考核,成功面试者的答案应当让我确信,他将会非常适合于我们这个团队,决不只是抱着一些ISO 9000-3或者CMM之类的操作标准不放的人。

知识面的宽度

在考察完体系知识之后,还需要测评出面试者的知识面广度。尽管这些实践问题在一定程度上取决于应聘者所工作过的公司环境和应用领域,但下列问题仍然可以反映出面试者在某些方面的经验程度:

  • 测试中最关键的问题是什么?
  • 你是否完整地对某一个产品的某一部分作过测试?如何测试的?
  • 进行过探索性的测试还是沿袭规范进行测试?
  • 是否每个公司都应当用同一种方式来测试软件产品?
  • 谈谈测试中自动操作的实用性以及规范的作用。
  • 描述一个典型测试计划的各个部分,例如用于互动产品、数据库产品的工具,以及因果图表和数据流程图等等。
  • 什么时候你应当将着重点放在数据的完整性上?
  • 在过去的任务中,你遇到过有代表性的程序错误吗?

对于“是否每个公司都应当用同一种方式来测试软件产品”这一问题的回答,可以考察出面试者是否具有开明的态度,乐于接受新观点、新思维和其他人的不同意见,同时也能判断出他本人对此领域知识所了解的深度和广度。我个人认为,正确的答案应当是非常鲜明的——“不”,并且我希望能听到这样的声音:最关键的应用程序应该使用更严格的评测和流程管理,而不是像眼下盛行的那样,只满足于今天,明天再考虑升级的得过且过式应用程序。

此外,面试者也应该认识到,对待不同的应用程序问题,应当提倡使用不同的处理方法。例如,评测一个用COBOL编写、工作中需要用到大量数据库的财务软件时,就应该用一些不同的技巧。这些技巧绝对不会和测试字处理程序交互性大小的方法一样。同样,与众不同的面试者还应当谈论一些软件测试的不同范例,或者还可以谈谈业内人士对这些关键问题的不同观点。

例如,在黑盒问题上,James Bach定义了范围测试、重点测试、流程测试、用户测试、回归测试、基于风险的测试等7种不同的方法(Tripos: A Model to Support Heuristic Software Testing)。可是,根据我的测试经验,从帮助评测人员确定不同标准,以便查创建更有效的测试方法或方案为着眼点,在此目的下,我划分为下列9种方法: 范围测试、重点测试、基于风险的测试、随机测试、功能测试、用户测试以及安全测试。面试者不应当非常肯定回答说只有一个正确的分类法;而且应该表示认同: 殊途同归。测试中的不同的方法、不同的类别都是正确的。

在面试几位资深人士时,我非常希望听听他们对常见测试问题的看法,并且还想知道他们对自己说使用过的工具的看法和评价。我并不要寻求特别一致的意见,相反,我想确定这些面试者是否真正具有资深的、综合性的见解。例如,在测试数据库和说使用的测试工具时,面向数据的问题就非常适合于测试面试者的深浅程度。当然,还要根据面试者的技能类型和应用程序的类型,对测试题目做出适当的变动。比如,向非常专业的测试人员或测试经理,询问一些交互性的应用程序,例如与数据库和测试工具相关的游戏或字处理之类,是没有意义的。

项目管理

实践中,在面试管理层人员时,人们肯定会提出一些人员和项目管理方面的问题。同样,那些有可能录用的中高级测试人员,我也会使用同样的方法。因为随着工作资历的增长,测试人员会非常善于自我管理。分派了大型项目后,他们能够独立地规划出项目的规模、类型以及项目内多个任务的合理序列。有位名人曾经定义说:在某种程度上,任何知识工人都是主管,因为他们必须管理好自己的时间和资源。对于这一点,我深有体会。

下面是有关管理或者自我管理方面的问题:

  • 在项目内部,你如何优化测试任务?
  • 如何制订测试计划和日程安排?介绍几种自下而上、组织管理严密的方法。
  • 应当在什么时候启动测试计划?
  • 应当在什么时候开始测试?
  • 对于能帮助你评估测试工作量大小的方法,你知道的有哪些?
  • 如何粗略地估算出测试工作量的大小?
  • 每位测试人员每周的工作量应当是多少小时?
  • 如何管理你的员工?对加班,你有什么看法?
  • 如何评估人员需求?
  • 进度失败时,怎么办(如何处理项目任务)?
  • 如何处理程序员之间的冲突?
  • 如何判断产品测试到什么时候就算足够了?

人事管理

同样,下面这一部分主要内容也是针对管理层人员的。无论如何,我还要对测试组经理提出以下问题。我想,有意于管理层的面试者,或许能够从中得到些启示:

  • 你希望的测试组经理应当具有什么样的性格?
  • 你认为测试组经理应当扮演什么角色?和高层管理部门打交道时扮演什么角色?和公司其他技术组?和你的员工相处时?
  • 同你刚才描述过的理想中的经理形象相比,你如何看待自己?
  • 同你刚才描述过的理想中的测试组经理所应扮演的角色相比,你的工作风格怎样?你工作所采用的方式和你说描述的角色之间有什么不同?
  • 你应当为测试组招聘哪些人?为什么?
  • 在人力资源管理方面,考核和比较人员业绩的准绳是什么?
  • 如何评定测试人员所应当具备的素质?
  • 进度失败时,怎么办(如何处理相关项目人员)?
  • 描述几例你曾处理过的人员冲突。

如果应聘者对理想中经理人的描述,和他本人或者他对自己的介绍所给我的印象差异太大,那就需要核实一下,这种差异究竟是一个危险的信号还是由于过于谦卑的原因。反之,如果两者没有什么差别,那么也不能立即判断说该人一向就很自负。因为面试过程中,应聘者肯定想竭力将自己放在显著的位置上,这不但是可能的,也很符合常理,只要他不是夸大其辞或者撒谎。最后要说的是,如果应聘者对于理想中经理人的描述根本不同于公司的期望,那我肯定怀疑他本人是否同本公司的企业文化相匹配,这样的人注定也很难入围。

October 05, 2006

托斯卡纳艳阳下

托斯卡纳,Toscana(意大利语),是意大利的一个大区,拉齐奥位于其南,翁布里亚位于其东,艾米利亚-罗马涅和利古里亚在其北,西濒第勒尼安海。它经常被评价为意大利的最美丽的部分。其首府为佛罗伦萨。

《托斯卡纳艳阳下》,女主人公—弗朗西斯·梅尔斯在婚姻失败之后的一次旅途中,买下了托斯卡纳小城的一座古老别墅,以此重新找回爱情……

托斯卡尼艳阳下,美丽的异域风情,让我羡慕不已,如此美景,令人心驰神往。

October 02, 2006

架构设计之学习(1)

当访问www.google.com的时候,您是否注意到url却重定向成为这样:www.google.com/intl/zh-CN/ 为何会这样?为何不是uk,不是fr,而是cn呢?

其实这些都已经在Google集群架构设计中作了说明。对于Google集群架构,这可就说来话长了。暂不细说。我们先从简单却重要的技术说起——DNS.

DNS, Domain name System. RFC1034对DNS做了详细的阐述,当然现在的版本都是基于此之上的扩展。DNS采用分布式数据库,分层授权控制多区段域名。当前全球12个root names servers,分别是:

A.ROOT-SERVERS.NET. 588402 IN A 198.41.0.4
B.ROOT-SERVERS.NET. 415610 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 503628 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 507504 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 415610 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 507271 IN A 192.5.5.241
G.ROOT-SERVERS.NET. 415610 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 415610 IN A 128.63.2.53
I.ROOT-SERVERS.NET. 503414 IN A 192.36.148.17
K.ROOT-SERVERS.NET. 503414 IN A 193.0.14.129
L.ROOT-SERVERS.NET. 509660 IN A 198.32.64.12
M.ROOT-SERVERS.NET. 504758 IN A 202.12.27.33

而我,现在adsl分配给我的ip是61.174.146.232,是属于哪儿的name server?

232.146.174.61.in-addr.arpa. 78000 IN PTR 232.146.174.61.broad.hz.zj.dynamic.cndata.com.

174.61.in-addr.arpa. 43518 IN NS dns-noc.zjhzptt.net.cn.
174.61.in-addr.arpa. 43518 IN NS ns.zjnbptt.net.cn.

当client向local dns server查询一个域名,若此域名所属的class属于这个local dns server,则将此域名所对应的ip返回给client;若不属于此class,则会从root ns一路查下来:

;; local name server: 202.96.209.133

;; global options: printcmd
. 325286 IN NS C.ROOT-SERVERS.NET.
. 325286 IN NS D.ROOT-SERVERS.NET.
. 325286 IN NS E.ROOT-SERVERS.NET.
. 325286 IN NS F.ROOT-SERVERS.NET.
. 325286 IN NS G.ROOT-SERVERS.NET.
. 325286 IN NS H.ROOT-SERVERS.NET.
. 325286 IN NS I.ROOT-SERVERS.NET.
. 325286 IN NS J.ROOT-SERVERS.NET.
. 325286 IN NS K.ROOT-SERVERS.NET.
. 325286 IN NS L.ROOT-SERVERS.NET.
. 325286 IN NS M.ROOT-SERVERS.NET.
. 325286 IN NS A.ROOT-SERVERS.NET.
. 325286 IN NS B.ROOT-SERVERS.NET.
;; Received 436 bytes from 202.96.209.133#53(202.96.209.133) in 30 ms

com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
;; Received 492 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 580 ms

google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; Received 168 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 1251 ms

www.google.com. 604800 IN CNAME www.l.google.com.
l.google.com. 86400 IN NS a.l.google.com.
l.google.com. 86400 IN NS b.l.google.com.
l.google.com. 86400 IN NS c.l.google.com.
l.google.com. 86400 IN NS d.l.google.com.
l.google.com. 86400 IN NS e.l.google.com.
l.google.com. 86400 IN NS g.l.google.com.
;; Received 244 bytes from 216.239.32.10#53(ns1.google.com) in 260 ms

在ns1.google.com这个所属的name server里,我们在来看看:

;; ANSWER SECTION:
www.google.com. 411943 IN CNAME www.l.google.com.
www.l.google.com. 405 IN CNAME www-china2.l.google.com.
www-china2.l.google.com. 309 IN A 64.233.189.165

;; AUTHORITY SECTION:
l.google.com. 66362 IN NS c.l.google.com.
l.google.com. 66362 IN NS d.l.google.com.
l.google.com. 66362 IN NS e.l.google.com.
l.google.com. 66362 IN NS g.l.google.com.
l.google.com. 66362 IN NS a.l.google.com.
l.google.com. 66362 IN NS b.l.google.com.

;; ADDITIONAL SECTION:
a.l.google.com. 73562 IN A 216.239.53.9
b.l.google.com. 68442 IN A 64.233.179.9
c.l.google.com. 68438 IN A 64.233.161.9
d.l.google.com. 68391 IN A 64.233.183.9
e.l.google.com. 68172 IN A 66.102.11.9
g.l.google.com. 68442 IN A 64.233.167.9

;; Query time: 30 msec
;; SERVER: 202.96.209.133#53(202.96.209.133)
;; WHEN: Mon Oct 02 15:00:28 2006
;; MSG SIZE rcvd: 285

因此,当我查询google.com的时候,name server告诉我这个域名对于的ip是:64.233.189.165.

September 29, 2006

Testing 1-2-3... is this thing on?

1.1 What are These Strange Creatures?

I have to say that tests are such a straight-forward concept that it’s actually harder to describe what they are than it is to show you how to do them.

So what are tests?

The Official Answer

Tests are collections of questions and scenarios that provide us (developers) with consistent results which prove that our application is doing what we expect it to do.

The Unofficial Answer

We write tests to interrogate, taunt, bully, punish, and otherwise kick the crap out of our application code until it consistently gives us the correct answer. Think of it as “tough love”. ;)

Need some examples?

* ensure user names have at least 4 characters
* ensure that when we save this record, the administrator is e-mailed
* ensure all replies are deleted when we delete the parent message
* ensure that Canadians have GST of 7% applied to their purchases

The idea of tests is that you write them at the same time as you write your application. In essence, you’re writing two application. As your application grows and becomes more complex, you create many tests. Re-running these tests at any point will help you discover if you’ve “broke” anything along the way.

Some developers actually take this a step further and create the tests before they create the application. This is called Test Driven Development (TDD), and although I personally don’t subscribe to it, it’s a totally legit way of coding.

There’s volumes written about Test Driven Development and testing in general. For more information, talk to Mr. Google.

1.2 So Why Test?

As mentioned before, tests offer proof that you’ve done a good job. Your tests become your own personal QA assistant. If you code your tests correctly, at any point in development, you will know:

* what processes work
* what processes fail
* the effect of adding new pieces onto your application

With your tests as your safety net, you can do wild refactoring of your code and be able to tell what needs to be addressed simply by seeing which tests fail.

In addition to normal “did it pass?” testing, you can go the opposite route. You can explicitly try to break your application such as feeding it unexpected and crazy input, shutting down critical resources like a database to see what happens, and tampering with things such as session values just to see what happens. By testing your application where the weak points are, you can fix it before it ever becomes an issue.

A strong suite of tests ensures your application has a high level of quality. It’s worth the extra effort.

Another positive side-effect of writing tests is that you have basic usage documentation of how things work. Simply by looking at your testing code, you can see how you need to work with an object to make it do it’s thing.

But enough about theory.

FROM: Ruby on Rails

The Benefits of Automation and Tools

Think back to what you've learned about how software is created. In most software development models, the code-test-fix loop can repeat several times before the software is released. If you're testing a particular feature, that means you may need to run your tests not once, but potentially dozens of times. You'll check that the bugs you found in previous test runs were indeed fixed and that no new bugs were introduced. This process of rerunning your tests is known as regression testing.

If a small software project had several thousand test cases to run, there might be barely enough time to execute them just once. Running them numerous times might be impossible, let alone monotonous. Software test tools and automation can help solve this problem by providing a more efficient means to run your tests than by manual testing.

The principal attributes of tools and automation are:
* Speed. Think about how long it would take you to manually try a few thousand test cases for the Windows Calculator. You might average a test case every five seconds or so. Automation might be able to run 10, 100, even 1000 times that fast.
* Efficiency. While you're busy running test cases, you can't be doing anything else. If you have a test tool that reduces the time it takes for you to run your tests, you have more time for test planning and thinking up new tests.
* Accuracy and Precision. After trying a few hundred cases, your attention span will wane and you'll start to make mistakes. A test tool will perform the same test and check the results perfectly, each and every time.
* Resource Reduction. Sometimes it can be physically impossible to perform a certain test case. The number of people or the amount of equipment required to create the test condition could be prohibitive. A test tool can be used to simulate the real world and greatly reduce the physical resources necessary to perform the testing.
* Simulation and Emulation. Test tools are often used to replace hardware or software that would normally interface to your product. This "fake" device or application can then be used to drive or respond to your software in ways that you chooseand ways that might otherwise be difficult to achieve.
* Relentlessness. Test tools and automation never tire or give up. They're like that battery-operated bunny of the TV commercialsthey can keep going and going and…

All this probably sounds like great news. You could have test tools do all the work for youturn them loose and wait for the results. Unfortunately, it's not that easy. Houses aren't built automatically, even though carpenters have power saws and nail guns. The tools just make it easier for them to do their work and for the resulting work to be of higher quality. Software test tools operate the same way.

NOTE:
Software test tools aren't a substitute for software testersthey just help software testers perform their jobs better.

It's important to note that using test tools isn't always the right answer. Sometimes there's no substitute for manual testing. For now, take in the information about what tests tools can do and how they work. Think about how you might use them to complement your testing tasks.

September 25, 2006

Sample post

Woo, do you like this page?

-rogerw.hai