从小到大，除非是人人都有奖的那种，否则我就和抽奖无缘。一直以为这就是我的命，没想到，居然有例外——几个月前申请TD的3G社会化测试，居然中彩被抽中了，太难得了。

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

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

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

这些天来，没有什么比得上对四川地震的关注，心里一直被塞得满满的，同情，难过，悲伤。

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

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

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

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

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

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

天佑中华！

网站名称是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，即可看到下一关的问题页面。

     摘要: 本来打算写一篇JMeter和LoadRunner的简单比较的文章，Google了一下，发现类似的文章已经有不少了，中文的英文的都有。大致阅读了几篇，发现其中一篇文章的总结和比较还是比较中肯的，因此直接把这篇文章的Link贴在这里，供大家参考（请注意，这篇文章是2006年的文章，有些内容有点过时了）。

文章标题：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进行比较，然  阅读全文

     摘要:

在4月26号下午的讲座中，我提到了“将Script放到HTML文件中尽量靠近尾部”的方法来提高用户感觉上的响应时间，有朋友对这个问题提出了疑问，因此在这里更详细的对该方法进行说明。

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

  阅读全文

     摘要: 是火龙果组织的一次公益活动，大约有100来人参加，感谢火龙果为大家提供场地。

如果希望下载到本地，请从这里下载（PDF文件，3.53兆大小） ：

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

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

今天收到一个读者的来信，对于我在书中提到的“响应时间”有一些疑问，以下是他的邮件中提到的问题：

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

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

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

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

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

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

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

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

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

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

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

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

追求问题的定义往往是一件非常好玩的事情。比如，这篇文章的标题：“什么是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.

    《软件性能测试过程详解与案例剖析》一书自去年8月份由清华出版社出版以来，已经经过两次重印，目前出版社希望能够根据读者的反馈，出本书的第二版。 
    《软件性能测试过程详解与案例剖析》的第一版侧重描述了性能测试过程组织、性能测试方法和技术、使用LoadRunner作为书中的主要性能测试工具。有不少读者都对本书的内容等提出了宝贵建议，基于大家的建议，我把第二版的方向定在以下几个方向的扩展：

1. 增加对本书中PTGM模型的解释和描述。包括在给出一些更有针对性的各阶段的方法（例如，QPS的估算方法，并发用户数的估算方法等）；
2. 扩大本书中描述的软件性能测试范围。除了针对Web和Socket的应用，增加对于Web Service、中间件服务器和使用自定义协议的C/S应用的性能测试的描述；
3. 增加对于性能优化的描述，包括描述如何使用Profile工具找出代码级别的性能瓶颈；
4. 【非常重大的改变】不再仅仅基于LoadRunner进行性能测试的描述，采用开源性能测试工具JMeter作为讲述性能测试的主要工具，为了便于LoadRunner的使用者能够快速切换到本工具，第二版会附加一个“LoadRunner用户的JMeter使用手册”，将LR中的相应概念一一对应到JMeter中。

    为了能够通过《软件性能测试过程详解与案例剖析》第二版和大家更好的分享我在性能测试方面的经验和教训，我非常热切的希望各位朋友能够告诉我你的期望，和你希望在书中看到什么。

    我将从所有给我反馈的朋友中选择最终被采纳建议的朋友，赠送《软件性能测试过程详解与案例剖析》第二版一书，以表谢意。

   

     摘要: 不少使用IIS或是windows域的环境中，在访问某个页面时，系统会弹出一个对话框要求用户输入域用户名称和口令，输入正确的与用户名称和口令才能继续。在使用LoadRunner对这种类型的网站进行测试时，录制下来的脚本在回放时通常都会在访问特定页面时给出一个401 Authorized require的错误信息。

其实，在LoadRunner中，有一个专门的函数 web_set_user 可以实现输入windows认证信息。  阅读全文