博客园-关河的测试生活http://www.cnblogs.com/guanhe/生活不是测试，但测试确实是一种生活zh-cnSat, 04 Jul 2009 04:33:55 GMTSat, 04 Jul 2009 04:33:55 GMT60《Google API大全：编程·开发·实例》一书将在本周末的GDD（Google开发者大会）上首发http://www.cnblogs.com/guanhe/archive/2009/06/01/1493789.html关河关河Mon, 01 Jun 2009 07:46:00 GMThttp://www.cnblogs.com/guanhe/archive/2009/06/01/1493789.htmlhttp://www.cnblogs.com/guanhe/comments/1493789.htmlhttp://www.cnblogs.com/guanhe/archive/2009/06/01/1493789.html#Feedback4http://www.cnblogs.com/guanhe/comments/commentRss/1493789.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1493789.html我也是本书的作者之一，虽然只在其中占了两章的内容：）

《Google API大全：编程·开发·实例》这本书是国内的第一本较为完整的介绍Google API的书，内容囊括了所有主要的Google API，并用大量的实例展示了Google API的应用方法。在这本书的首页上，我选择了“Google是一种生活方式”作为我对这本书的推荐语。

“Google是一种生活方式”，此言不虚，现在的网名，或多或少的被搜索引擎影响着使用Internet的方式，Google在其中的贡献不言而喻。当然，对我而言，“Google是一种生活方式”更有所指，Google的产品一向以良好的编程接口著称，对于以技术工作为主的工程师们，基于Google的产品构建自己的产品，更是一件值得一试的事情。

《Google API大全：编程·开发·实例》作者序：

10年前，使用Email邮箱收发邮件，只是很少一部分技术人员才能享受到的便利；5年前，出行时如果没有随身携带地图，只好在路人的指点下摸索找寻。而今天，无处不在的互联网和丰富多彩的互联网应用，已然嵌入了我们的生活。GMail带给我们免费、好用且容量不断增加的邮件服务，Google Maps成了我们出行前必不可少的参阅工具，甚至通过移动终端将地图随时带在身边。所有这些，都悄无声息成为我们生活的一部分。

互联网技术每天都在更新和发展，促成这一切发生的，正是背后极具创造性的程序员，和那些通过产品为用户带来价值的新技术公司。在这些公司中，Google毫无疑问是在帮助用户改变互联网使用方式上做得最为出色的。

Google以其独具特色的互联网应用，一直引领着互联网产品开发的方向。同时，Google为其绝大部分产品提供了面向开发者的API调用接口。这些设计良好的API，帮助开发者通过Mashup调用将Google产品所提供的内容集成在第三方应用中。

Google 多达几十种的开放API无法一一列举，但我们在日常使用互联网时一定在不经意间享受过它所带来的便利。提供地图服务的Maps API，实现互联网社区化联系的OpenSocial API，开发定制个性化首页的iGoogle Themes API，简化广告营销管理活动的AdWords API，提供网络应用程序平台的App Engine，等等。这些API的出现，不仅仅为开发者带来更具灵性的开发创意，为用户带来更为丰富多彩的互联网产品，更重要的是，它们说明了 Google的产品不是封闭的，而是属于整个互联网开放平台的，任何人都可以在Google的产品之上进行拓展，并享用Google产品为互联网带来的便利。


完整的作者序请移步至Google Doc上阅读。 或者，你可以查看豆瓣和China-pub上的本书信息。

 


 



--------------------------
新闻：19岁天才黑客发布首个iPhone 3GS破解软件
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>4月份到上海出差http://www.cnblogs.com/guanhe/archive/2009/03/11/1408595.html关河关河Wed, 11 Mar 2009 03:39:00 GMThttp://www.cnblogs.com/guanhe/archive/2009/03/11/1408595.htmlhttp://www.cnblogs.com/guanhe/comments/1408595.htmlhttp://www.cnblogs.com/guanhe/archive/2009/03/11/1408595.html#Feedback2http://www.cnblogs.com/guanhe/comments/commentRss/1408595.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1408595.html4月份到上海出差，有机会的话希望能够和上海的测试同行们见见面：）


不知道有没有感兴趣的朋友？我到上海会住在南京路附近。 



--------------------------
新闻：新浪邮箱大本营粉墨登场！Sina.cn开放注册
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>拿到了TD的3G测试手机http://www.cnblogs.com/guanhe/archive/2008/09/11/1289078.html关河关河Thu, 11 Sep 2008 05:59:00 GMThttp://www.cnblogs.com/guanhe/archive/2008/09/11/1289078.htmlhttp://www.cnblogs.com/guanhe/comments/1289078.htmlhttp://www.cnblogs.com/guanhe/archive/2008/09/11/1289078.html#Feedback6http://www.cnblogs.com/guanhe/comments/commentRss/1289078.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1289078.html从小到大，除非是人人都有奖的那种，否则我就和抽奖无缘。一直以为这就是我的命，没想到，居然有例外——几个月前申请TD的3G社会化测试，居然中彩被抽中了，太难得了。

我拿到的是新邮通的 N269 这一款手机，样子倒是中规中矩的长方形，不过不知道怎么回事，看到这个手机的第一眼就觉得有典型的山寨机风格。到今天为止大约使用了一周左右的该手机，接听和打了几个电话，和另一个测试用例视频了一次，用手机浏览器上网浏览了一些网站，用笔记本连接手机上网，总体感觉是，除了连接笔记本上网感觉上比GPRS和CDMA 1X明显快之外，别的3G的优势就没有明显的体会了。

不过话说回来，从3G的技术上来说，3G提供的特色也就是一个“更宽的网络带宽”，至于具体的业务么，那是运营商操心的事情，对我这样的用户来说，与其用手机浏览网页、打游戏、弄一些花里胡哨的业务，不如用我更熟练使用的notebook去干这些事情好了。

对这个3G手机还有一个比较大的抱怨就是说明书，看上去挺精美的说明书，一到关键地方就...了。在拿3G手机尝试通过笔记本连接Internet的时候，在光盘上一共发现了两个安装包，怎么找都找不着手机的驱动，折腾了两天才弄清楚，原来要先安装那两个包，然后在系统提示安装新硬件的驱动时，找到Sync安装后生成的那个目录，驱动在该目录下的driver目录中——晕，就这点东西也不说清楚，折腾人。具体过程我就不写了，这里有一篇更详细的说明：新邮通N269连接笔记本电脑上网操作指南。




--------------------------
新闻：IE市场份额首次跌破60%
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>天佑中华http://www.cnblogs.com/guanhe/archive/2008/05/16/1200041.html关河关河Fri, 16 May 2008 02:29:00 GMThttp://www.cnblogs.com/guanhe/archive/2008/05/16/1200041.htmlhttp://www.cnblogs.com/guanhe/comments/1200041.htmlhttp://www.cnblogs.com/guanhe/archive/2008/05/16/1200041.html#Feedback2http://www.cnblogs.com/guanhe/comments/commentRss/1200041.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1200041.html这些天来，没有什么比得上对四川地震的关注，心里一直被塞得满满的，同情，难过，悲伤。

恨不能和那些可爱的救援者一样，在现场亲手挽救同胞的生命，可是理智却告诉我，对他们最大的帮助是做我能够做的。

看着新闻中的英雄们，在网站上读着感人至深的故事，看着那些放弃了自己的休息时间忙碌着筹集捐款，组织献血，人肉搜索，尽自己能力帮助他人的同事们，感动到无语。

逝者已矣，祝他们在天堂安好。我们能做的，是为那些需要帮助的人提供尽可能的帮助。看到网上很多和自己亲人失散的朋友焦急地打听自己亲人的消息，或许可以尝试这个：

http://www.google.cn/intl/zh-CN/qinren/cse.html

我在blog的右侧也加上了这个搜索框，即使这样只能帮到一个朋友，我也会发自内心的感到高兴。

太沉重，不能再说些什么了，我们经历了灾难，受难的人们正在经历苦难，但只要希望在，就能期待光明。

天佑中华！



--------------------------
新闻：Google App Engine宕机6小时——云的安全在哪里？
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>一个好玩的网站http://www.cnblogs.com/guanhe/archive/2008/05/05/1183759.html关河关河Mon, 05 May 2008 09:17:00 GMThttp://www.cnblogs.com/guanhe/archive/2008/05/05/1183759.htmlhttp://www.cnblogs.com/guanhe/comments/1183759.htmlhttp://www.cnblogs.com/guanhe/archive/2008/05/05/1183759.html#Feedback1http://www.cnblogs.com/guanhe/comments/commentRss/1183759.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1183759.html网站名称是PythonChallenge，提供了一系列的Python puzzle需要你去解决。需要你根据给出的页面提供的信息，猜测（计算）出下一关的URL是什么。

刚开始看到的时候觉得满头雾水，尝试着解决了几关之后发现，还是蛮好玩的。所有的puzzle都建议使用Python编程语言来解决，当然也可以用其他的语言来解决。如果你正在学习Python，或是对用编程解决问题有兴趣，可以去试试，看看你能到哪一关。

http://www.pythonchallenge.com

一点小提示：
1，解决一个问题后，得到下一关的html文件名，只需要把本关的URL的xxxx.html改成[newstring].html即可；
2，注意页面上的提示信息，请仔细阅读；
3，很多时候需要查看页面的源代码，源代码中通常会隐藏一些信息。

我第一次看到最初那一关的时候，想了半天也没弄明白怎么回事，为了方便大家可以尽快开始玩，把第0关的解决过程描述一下：
1，你首先看到的应该是一个类似电视机的图片；
2，查看页面源代码的话，没有任何提示信息；
3，注意页面上的数字，一个大的2和一个小的38
4，这提示你是2的38次方

因此，解决方法是计算出2的38次方（当然不是让你手算啦……），例如，用python写：
print pow(2, 38)

得出的结果是274877906944，原来的URL是：http://www.pythonchallenge.com/pc/def/0.html，将其更改成http://www.pythonchallenge.com/pc/def/274877906944.html，即可看到下一关的问题页面。

--------------------------
新闻：微软新推社交网站Windows Live Planet
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>JMeter与LoadRunner的比较http://www.cnblogs.com/guanhe/archive/2008/04/28/1174583.html关河关河Mon, 28 Apr 2008 06:13:00 GMThttp://www.cnblogs.com/guanhe/archive/2008/04/28/1174583.htmlhttp://www.cnblogs.com/guanhe/comments/1174583.htmlhttp://www.cnblogs.com/guanhe/archive/2008/04/28/1174583.html#Feedback10http://www.cnblogs.com/guanhe/comments/commentRss/1174583.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1174583.html
文章标题：Shootout: Load Runner vs The Grinder vs Apache JMeter
http://blackanvil.blogspot.com/2006/06/shootout-load-runner-vs-grinder-vs.html

随着对JMeter使用的深入，我越来越倾向于在自己的工作中使用JMeter工具，并且也不遗余力的向我认识的测试工程师推荐这个工具，但很多工程师在初步使用过这个工具后，会向我抱怨JMeter有太多不能做的事情，但在我看来，JMeter确实有不能做的事情，不过，对于Web应用的测试，JMeter是足够强大了。很多人会把JMeter和自己正在使用的LoadRunner进行比较，然  阅读全文

--------------------------
新闻：火狐3.5版被指推出太匆忙：存在50多个漏洞
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>浏览器对Script下载的非并行处理再说明http://www.cnblogs.com/guanhe/archive/2008/04/27/1173609.html关河关河Sun, 27 Apr 2008 14:08:00 GMThttp://www.cnblogs.com/guanhe/archive/2008/04/27/1173609.htmlhttp://www.cnblogs.com/guanhe/comments/1173609.htmlhttp://www.cnblogs.com/guanhe/archive/2008/04/27/1173609.html#Feedback5http://www.cnblogs.com/guanhe/comments/commentRss/1173609.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1173609.html
在4月26号下午的讲座中，我提到了“将Script放到HTML文件中尽量靠近尾部”的方法来提高用户感觉上的响应时间，有朋友对这个问题提出了疑问，因此在这里更详细的对该方法进行说明。

首先，浏览器对于script的下载是避免并行进行的。HTTP/1.1协议中规定浏览器和同一host之间只建立最多两个连接，也就是说允许的最大并行度为2（当然，对IE和Firefox来说，你都可以通过修改浏览器的设置来扩大这个并行度）。但对于Script的下载来说，浏览器在开始下载Script之后，是不会并行的下载其他element的。不会并行下载script这一点是一个事实，但浏览器为什么要采用这种策略，以及浏览器我们提到的“将Script放到HTML文件中尽量靠近尾部”到底能起到多大的作用，需要注意哪些事项，我希望在这篇文章中进一步的进行讨论。

  阅读全文

--------------------------
新闻：Google对手机搜索进行优化升级
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>今天下午做的一个关于web前端性能/性能测试的Talkhttp://www.cnblogs.com/guanhe/archive/2008/04/26/1172491.html关河关河Sat, 26 Apr 2008 12:48:00 GMThttp://www.cnblogs.com/guanhe/archive/2008/04/26/1172491.htmlhttp://www.cnblogs.com/guanhe/comments/1172491.htmlhttp://www.cnblogs.com/guanhe/archive/2008/04/26/1172491.html#Feedback7http://www.cnblogs.com/guanhe/comments/commentRss/1172491.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1172491.html
如果希望下载到本地，请从这里下载（PDF文件，3.53兆大小） ：

下载链接：http://www.guanhe.cn/mydownload/Web_Frontend_Performance_200804_by_DuanNian.pdf

在线浏览请访问：http://docs.google.com/EmbedSlideshow?docid=dhdkc7jb_836ct6wgwhd
  阅读全文

--------------------------
新闻：风声又起 Windows 7 RTM版7月13日完成
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>论“响应时间”http://www.cnblogs.com/guanhe/archive/2008/04/23/1167828.html关河关河Wed, 23 Apr 2008 09:16:00 GMThttp://www.cnblogs.com/guanhe/archive/2008/04/23/1167828.htmlhttp://www.cnblogs.com/guanhe/comments/1167828.htmlhttp://www.cnblogs.com/guanhe/archive/2008/04/23/1167828.html#Feedback4http://www.cnblogs.com/guanhe/comments/commentRss/1167828.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1167828.html今天收到一个读者的来信，对于我在书中提到的“响应时间”有一些疑问，以下是他的邮件中提到的问题：

1，“系统响应时间”如何定义？是指“客户端接收到响应所消耗的时间”还是“接收到最后一个字节数据所消耗的时间。。。。”？

2，书中提到“可以使用技巧在数据尚未接收完成时进行呈现来减少用户感受到的响应时间”，这一句话是什么意思？

先回答第一个问题，我在书中找到了原文：

而“系统响应时间”指应用系统从请求发出开始到客户端接收到数据所消耗的时间。

这里确实有不明确的地方，更确切的说法应该是：而“系统响应时间”指应用系统从请求发出开始到客户端接收到所有数据所消耗的时间。

这样，“系统响应时间”加上“呈现时间”，才是完整的用户感受到的响应时间。

对于第二个问题，倒是有些可以讨论的内容：

我们在定义响应时间的时候，是从应用的使用者/客户的角度出发的。从这个角度出发，响应时间被定义成“对请求做出响应所需要的时间”。我们以一个web应用为例，假设web应用有一个“提交用户留言”的功能，考察这个功能的响应时间，就应该是“从用户填写完留言，点击提交按钮开始，到页面刷新完成，用户看到完整的返回页面为止”所消耗的所有时间——这个定义非常完整，但若从用户的实际感受来看的话，这里还是有一点模糊的地方。

我们可以把上文提到的交互过程细化一下：

用户点击“提交”按钮-》请求被发送到服务器-》服务器处理-》服务器返回页面-》浏览器接收服务器的返回并render页面

模糊之处在于最后一个环节：“浏览器接收服务器的返回并render页面”，如果我们坚定的认为“只有当页面完整的显示完成，才是响应时间的结束”，这不会是一个问题。但实际上，对大多数用户来说，看到页面上开始显示数据或是图片，用户就会认为“我已经得到了响应”，从这个角度来说，用户感受到的响应时间实际上是“从请求发出开始，到用户看到页面开始呈现出的内容结束”所需要的时间。

那为什么我们不采用“从请求发出开始，到用户看到页面开始呈现出的内容结束”这样一个定义方式呢？关键在于这里涉及到用户的认知行为，带有主观色彩，不完全是客观的标准，因此不适合作为一个需要被度量的性能指标。另一方面，不同的浏览器有不同的行为（例如parse的方式和render的方式），如果需要把这些浏览器本身的行为都考虑到性能测试中的话，我们很难为所有的系统建立统一的测试模型——实际上，现在的主流性能测试工具（例如JMeter，LoadRunner，Webload等）都完全不考虑客户端的呈现过程。



--------------------------
新闻：乔布斯和埃利森
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>什么是Test Automationhttp://www.cnblogs.com/guanhe/archive/2007/12/23/1011424.html关河关河Sun, 23 Dec 2007 04:59:00 GMThttp://www.cnblogs.com/guanhe/archive/2007/12/23/1011424.htmlhttp://www.cnblogs.com/guanhe/comments/1011424.htmlhttp://www.cnblogs.com/guanhe/archive/2007/12/23/1011424.html#Feedback0http://www.cnblogs.com/guanhe/comments/commentRss/1011424.htmlhttp://www.cnblogs.com/guanhe/services/trackbacks/1011424.html追求问题的定义往往是一件非常好玩的事情。比如，这篇文章的标题：“什么是Test Automation（测试自动化）？”

许多人都在谈论测试自动化，但是要谈论测试自动化的人对测试自动化进行一个明确的定义，却不是一件容易的事情。不信，我们来看看：

1，一种字面上的解释，“自动化测试”可以被定义为“以自动化的方式完成测试”，表面上看上去，这个定义完美无缺——从自动化测试的发展来看，目前的自动化测试在大多数情况下是将手工测试的过程变成了自动化测试的过程，因此，“以自动化的方式完成测试”应该是自动化测试的发展趋势。但是，让我们设想一个场景：在某些难以完全采用自动化测试的方式下，测试工程师写一段代码，然后通过人工观察代码执行的结果来判断测试通过与否，这是否应该被归在自动化测试的领域呢？——我们这里描述的场景显然不是完全以自动化方式完成测试的一个例子。

2，如果我们将自动化测试的定义扩展一下，应该怎么来描述呢？一时间还真的很难找到一个合适的定义。或者，“尝试通过代码或是其他手段摆脱完全的人工测试的方式”就应该被归入自动化测试？不过这个定义实在拗口：）

其实，在目前的测试环境下，自动化测试和手工测试之间往往并没有明确的界限。很多测试往往并不能完全通过自动化测试完成，自动化到不需要人工参与的程度是不现实的。而且，自动化测试并不是测试的最高境界——实际上，手工测试在发现缺陷，设计用例方面显然比自动化测试有更大的优势。因此，我们在谈论自动化测试的时候，不是要把手工测试从测试过程中驱赶出去，也不是要用自动化测试替代掉所有的手工测试。

套用一句俗套的话，“在可预见的将来，自动化测试和手工测试将会和平共存一段相当长的时间”。

TestReflections上有两篇针锋相对的关于自动化测试的观点，很有意思，有兴趣的朋友可以去看看：

What Is Test Automation?

Submitted by SteveRowe on Wed, 19/12/2007 - 20:45.

What is Test Automation?

Submitted by james on Wed, 19/12/2007 - 23:55.



--------------------------
新闻：Xbox Live将投放Silverlight广告
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>