摘要：本文的标题借用了安东尼.韦斯顿（Anthony Weston）的《论证是一门学问》一书的标题，向安东尼老爷子致敬的同时，也希望更多人能够真正了解“什么是论证”。
争论与论证从来都不是新鲜事物，作为软件行业的科技工作者，理应对各种论证的手段了如指掌才是。然而，从各种我参与的有争论的场合来看，事实并非如此。许多论证最终都停在口号式的结论，或是由于自说自话无法进行下去。科学对人类的贡献之一在于科学的方法，而“合理”的论证方式才是科学真理得以彰显的手段。
《论证是一门学问》一书（http://book.douban.com/subject/5399343/）中提到了论证的基本规则，以及各种论证的方式：类比论证、因果论证、演绎论证。这些方法都不是什么难度很高的方法，但在实际的争论过程中，尤其是在微博上进行的论证中（字数的限制也是导致误解的原因之一），却并不经常被论证的双方所遵守。
一个观点包含“前提”和“结论”。前提是为你的结论提供理由的表述。前提一般基于具体的事实或是已经被事实证实的结论，通过前提，借助各种论证的方法就能推导出结论。这个过程看似简单，在很多情况下却并非显而易
阅读全文
摘要：上周六在杭州的《互联网软件测试大会》上做演讲的时候提到可测试性的话题，顺手举了一个例子：“B类存在对A类的依赖，A类是一个Singleton类，B类使用到了A类中的一个需要被mock的函数，这种情况下如何处理？” 本来，这是《修改代码的艺术》上曾经提到的一个典型模式，该书中有非常详细的描述。但今天收到某位听众的邮件，问这个问题应该怎么回答。
正好好久没有写过blog了，于是顺手写了一段简单的代码来说明这个问题。
阅读全文
摘要：Agile testing（敏捷测试）基本上是伴随着敏捷开发的概念成长起来的，但在受关注程度上，远远不及敏捷开发本身。自然，开发队伍从数量和活跃度上来讲大于测试队伍，是其中的一个原因；除了这个原因之外，“敏捷测试究竟如何在项目中发挥作用”这个问题可能也是导致敏捷测试概念的流行度远远不如敏捷开发的原因之一。
在敏捷环境中工作了几年之后，对敏捷测试有了一些感悟，希望和大家分享。
阅读全文
摘要：从小到大，除非是人人都有奖的那种，否则我就和抽奖无缘。一直以为这就是我的命，没想到，居然有例外——几个月前申请TD的3G社会化测试，居然中彩被抽中了，太难得了。
我拿到的是新邮通的 N269 这一款手机，样子倒是中规中矩的长方形，不过不知道怎么回事，看到这个手机的第一眼就觉得有典型的山寨机风格。到今天为止大约使用了一周左右的该手机，接听和打了几个电话，和另一个测试用例视频了一次，用手机浏览器上网浏览了一些网站，用笔记本连接手机上网，总体感觉是，除了连接笔记本上网感觉上比GPRS和CDMA 1X明显快之外，别的3G的优势就没有明显的体会了。
阅读全文
摘要：网站名称是PythonChallenge，提供了一系列的Python puzzle需要你去解决。需要你根据给出的页面提供的信息，猜测（计算）出下一关的URL是什么。
刚开始看到的时候觉得满头雾水，尝试着解决了几关之后发现，还是蛮好玩的。所有的puzzle都建议使用Python编程语言来解决，当然也可以用其他的语言来解决。如果你正在学习Python，或是对用编程解决问题有兴趣，可以去试试，看看你能到哪一关。
http://www.pythonchallenge.com
一点小提示：
1，解决一个问题后，得到下一关的html文件名，只需要把本关的URL的xxxx.html改成[newstring].html即可；
2，注意页面上的提示信息，请仔细阅读；
3，很多时候需要查看页面的源代码，源代码中通常会隐藏一些信息。
阅读全文
摘要：本来打算写一篇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进行比较，然
阅读全文
摘要：存在了两年多的BLOG终于要关闭了，以后我就只在cnblog上维护这个BLOG了。
===============在sitwithwhom.51.net上的告别词=====================
重要声明：本BLOG从即日起不再更新，请访问我的新BLOG:
http://guanhe.cnblogs.com
从2004年12月16日到现在，这个BLOG已经存在了2年半了。我不是一个勤奋的blogger，但今天浏览了以下，居然也还有142篇日志。
当然，让我惭愧的是那385条评论，感谢朋友们的支持，特别感谢这些一直以来坚持查看我的Blog，关心我的朋友们。
两年半不是一个特别长的时间，但对我来说，在这段时间里我收获了幸福——和自己最爱的人结婚，收获了甜蜜——有了一个可爱的baby，收获了一些新的体验——尝试了创业，当然，还是很多的其他。。。
阅读全文
摘要：昨天一个测试工程师发邮件给我，询问软件评测师考试的一个题目的答案。题目是关于估算系统中存在缺陷数量的，原题如下：
“两个小组独立地测试同一个程序，第一组发现25个错误，第二组发现30个错误，在两个小组发现的错误中有15个是共同的，那么可以估计程序中的错误总数是 ___个。
A．25 B．30 C．50 D．60”
当然，任何一个了解估算方法的朋友都可以根据公式计算出最终的结果是50个，这没有什么问题。——但是，我在这里引用这个题目，是希望我们可以把学习这件事情通过类比变得“更加有趣”一点。
其实，如何估算一个系统中存在的缺陷数，我们的老祖宗早就有现成的方法了。不信，请看我在我们老祖宗的数学专著中找到的一个实践问题：“有一口鱼塘，不知道其中有多少条鱼，如何才能估算出池塘中鱼的数量？”（当然，原文不是这样，请原谅我一下子找不到出处，只好凭记忆用我的语言描述一下了）。我们老祖宗给出的答案是这样的：
………………
阅读全文
摘要：在Zee的论坛里面和大家讨论了一下关于如果学习编程的问题，觉得挺有意思的，干脆贴在BLOG上了，呵呵。
阅读全文
摘要： 从内心来说，我非常非常同意Raymond的话：你要自己去“挣”回一个答案。在我看来，简单的说，关于提出问题，大致是3点：
1. 没有人有义务回答你的问题，所以请不要动辄大叫“为什么没有人回答我的问题？高手在哪里？”——越是高手，越是时间宝贵，也许根本原因是，你的问题不值得他们浪费时间；
2. 不要把提问变成一个简单的索取，你的问题只有在给其他人带去同样的价值和收获的时候，才会引起他人的关注，所以请不要在论坛上大叫“这段话我看不懂，谁能给我讲一下？”
3. 请只有在确认自己无法解决这个问题的时候，才向他人提问——“确认”的意思是说，你无法从其他任何来源获得关于此问题的信息，不想看，不愿看，看不明白不在此列。
阅读全文
摘要：我也不知道时间过了多久，也不知道我到底是在梦中还是在现实，对面不知道是一个什么奇怪的装置，每秒钟发出一声“咔”的声音，不停的“咔咔”声如同对我的嘲笑，让我一瞬间有扑过去狠狠捣毁它的冲动。
……等等，让我想想，我为什么会在这么一个奇怪的地方？……对了，我想起来了，很久以前，我曾经是一个……呃，……小有名气的物理学家……那我为什么会在这里？……对了，该死的量子自杀试验。时间过去得太久了，我都几乎忘了我还承担着如此重要的任务。
阅读全文
摘要：最近一直在学习和使用Ruby，对rubyforge的一个开源项目 foxGUIb （ http://fox-tool.rubyforge.org ）很有兴趣，该项目是 FXRuby （Ruby GUI 库）的 GUI Builder 前端工具，能生成 FXRuby 图形界面布局文件。之所以对这个项目感兴趣，是觉得如果这个工具足够稳定和好用的话，是可以作为一些辅助工具的快速开发工具来...
阅读全文
摘要：经常收到测试工程师的Email，有相识的，有不相识的。今天看了下邮箱，又有几封邮件静静地躺在那里，等着我回复。
总觉得自己还算是热心的人，无论工作是不是忙，在看到这些求助的邮件的事情，就仿佛看到了那些焦急等待的脸，无论如何，我是一定会回复邮件的。
回复这些求助的邮件，有时候是件快乐的事情——看到一些充满求知欲的新入行的测试工程师，感到由衷的高兴；有时候却是件痛苦的事情，甚至还会断送我一天的好心情——那一定是语焉不详的要求我给他找一份这样或那样的文档，或是直接要求我告诉他应该怎样对付掉老板交代的工作的邮件。说真的，有时候我很难理解为什么会有人对一个素不相识的人发出这样的邮件，或者说，觉得其他人有帮助自己的义务。
阅读全文
