摘要：话说自从我厂的商务部门搬到旁边的商务楼之后，工程师发现漂亮的前台MM也搬走了，某区只留下冷冷清清的鱼缸。然后，工程师们发现开门成了个问题。鉴于进门需要刷卡，所以没有带卡的工程师就不得不摁下门铃，等待其他人从座位上起身为自己开门。经历过多次不得不让别人来开门以及不得不为别人开门之后，终于有工程师不能忍受了（我就是其中一个），于是，决定自己动手解决问题。要知道，地球上没有能难住工程师的问题！
研究与选择方案：
我厂的电子门锁的开门设备是通过一个带弹簧的开关（门内，类似墙面上开灯的开关）控制的，按下开关就能打开门，按下开关的时候能够听到明显的继电器闭合的声音，因此，趁着没人的时候我把开关拆开看了一下，证实的确是通过触电控制的一个继电器。按下开关时，两个金属触电接触，继电器动作，门打开。继电器在动作后延时4秒左右恢复。这样看来，硬件层面的开门实现就非常简单了：跨接一个数字继电器，要开门时，通过电平信号控制继电器闭合并保持2秒即可。
阅读全文
摘要：作为一个已经有多年工程师面试经验，并在国内的大企业，小企业，国外的大企业，小企业混迹过的面试官（注意，我是技术人员，不是HR），我在微博上的吐槽的确有戏虐的成分。每年的校园招聘季，阅读和筛选简历都是我重要的工作之一。在一上午时间内怀着生怕错误优秀人才的心态伏案阅读了接近40份简历的我来说，在简历中看到让自己“情何以堪”的内容吐个槽，似乎也合情合理。不过，简历中是否应该包含“精通”并非是我吐槽的重点，目前完全由于应届毕业生在简历中写了过多精通而被直接挂掉的事情在我身上还未发生过，过多的“精通”表述最多只是我看不惯的一个点而已。
看到回复中有不少怀着热切心情找工作的应届毕业生（或是将要面临找工作压力的非应届毕业生），我觉得也许我可以从一个面试官和用人公司的角度描述一下我的体会。
找到“好的”工作必然会给初涉职场的各位应届毕业生一个良好的起步基础，加上走出校园面临的各种不确定性和在一个城市生存下来的压力，找工作基本是各位希望走出学校的应届毕业生自己的头等大事。我不能像大师们一样给各位斩钉截铁的“可行建议”，只是希望能让大家了解从我这样一个面试官的角度如何看待应届毕业生招聘这件事情
阅读全文
摘要：本文的标题借用了安东尼.韦斯顿（Anthony Weston）的《论证是一门学问》一书的标题，向安东尼老爷子致敬的同时，也希望更多人能够真正了解“什么是论证”。
争论与论证从来都不是新鲜事物，作为软件行业的科技工作者，理应对各种论证的手段了如指掌才是。然而，从各种我参与的有争论的场合来看，事实并非如此。许多论证最终都停在口号式的结论，或是由于自说自话无法进行下去。科学对人类的贡献之一在于科学的方法，而“合理”的论证方式才是科学真理得以彰显的手段。
《论证是一门学问》一书（http://book.douban.com/subject/5399343/）中提到了论证的基本规则，以及各种论证的方式：类比论证、因果论证、演绎论证。这些方法都不是什么难度很高的方法，但在实际的争论过程中，尤其是在微博上进行的论证中（字数的限制也是导致误解的原因之一），却并不经常被论证的双方所遵守。
一个观点包含“前提”和“结论”。前提是为你的结论提供理由的表述。前提一般基于具体的事实或是已经被事实证实的结论，通过前提，借助各种论证的方法就能推导出结论。这个过程看似简单，在很多情况下却并非显而易
阅读全文
摘要：左耳朵耗子发表了《我们需要全职的QA吗？》后，一石激起千重浪，赞成者有之，激烈反对者有之；有人说文中对QA的定义不对，还有人说以偏概全…… 的确，在需不需要专职的QA角色这个问题上，很难用一个简单的“需要”或“不需要”来回答。前两天我写了一篇对该文的回应文章，但由于文章写就得比较仓促，很多观点来不及完整表述，因此，在“真理越辩越明”的原则下，在这边文章中，我准备就“我们需要什么样的测试”这个问题说说我自己的看法。
首先要说明的是，这篇文章完全不是讨论“我们是否需要专职QA”这个问题的，也不是讨论“各种情况下QA或测试工程需要做什么”，而是从我自身对测试的认知和个人经验出发，说一说我对不同特点的产品需要的测试的看法。
阅读全文
摘要：说实话，在我看来，左耳朵耗子的《我们需要专职的QA吗？》这篇文章的观点并不算过激。最多就是一篇从开发工程师的角度来商讨是否需要设立“专门做测试的岗位”，让“不熟悉或是不懂开发的人”来做测试工作。如果这个问题摆在我的面前，在大多数情况下，我的答案可能和左耳朵耗子一样：“不需要”。
作为一个在测试行业工作了10多年的“老人”，在这里赞同左耳朵耗子的观点似乎是对自己过去这么多年工作的否定，但实际上，正是因为有这么多年的经验，我才真正能够深刻的体会专职测试工程师在工作中的局限和不足。
阅读全文
摘要：在第四届软件质量年会上的演讲，标题是”让测试敏捷起来“。
下面的链接是InfoQ上的视频和PPT：
http://www.infoq.com/cn/presentations/duannian-agile-test
阅读全文
摘要：在本系列的第一部分中，我们简要回顾了敏捷开发，以及敏捷测试与传统测试的不同。在第一部分中，我们特别提到，敏捷测试的要点之一就是，不依据于角色而是依据于任务来考虑整个开发过程中的测试。
但是，对一个开发组织来说，组织中一定存在开发工程师和测试工程师的角色划分，作为一个敏捷团队中的测试工程师，他的主要工作职责是什么呢？或者说，他可以在哪些工作上发挥自己的作用呢？
阅读全文
摘要：Agile testing（敏捷测试）基本上是伴随着敏捷开发的概念成长起来的，但在受关注程度上，远远不及敏捷开发本身。自然，开发队伍从数量和活跃度上来讲大于测试队伍，是其中的一个原因；除了这个原因之外，“敏捷测试究竟如何在项目中发挥作用”这个问题可能也是导致敏捷测试概念的流行度远远不如敏捷开发的原因之一。
在敏捷环境中工作了几年之后，对敏捷测试有了一些感悟，希望和大家分享。
阅读全文
摘要：本来打算写一篇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文件中尽量靠近尾部”到底能起到多大的作用，需要注意哪些事项，我希望在这篇文章中进一步的进行讨论。
阅读全文
摘要：追求问题的定义往往是一件非常好玩的事情。比如，这篇文章的标题：“什么是Test Automation（测试自动化）？”
许多人都在谈论测试自动化，但是要谈论测试自动化的人对测试自动化进行一个明确的定义，却不是一件容易的事情。不信，我们来看看：
阅读全文
摘要：《软件性能测试过程详解与案例剖析》一书自去年8月份由清华出版社出版以来，已经经过两次重印，目前出版社希望能够根据读者的反馈，出本书的第二版。
为了能够通过《软件性能测试过程详解与案例剖析》第二版和大家更好的分享我在性能测试方面的经验和教训，我非常热切的希望各位朋友能够告诉我你的期望，和你希望在书中看到什么。
本书预计的扩展方向：
1，增加对本书中PTGM模型的解释和描述。包括在给出一些更有针对性的各阶段的方法（例如，QPS的估算方法，并发用户数的估算方法等）；
2，扩大本书中描述的软件性能测试范围。除了针对Web和Socket的应用，增加对于Web Service、中间件服务器和使用自定义协议的C/S应用的性能测试的描述；
3，增加对于性能优化的描述，包括描述如何使用Profile工具找出代码级别的性能瓶颈；
4，【非常重大的改变】不再仅仅基于LoadRunner进行性能测试的描述，采用开源性能测试工具JMeter作为讲述性能测试的主要工具，为了便于LoadRunner的使用者能够快速切换到本工具，第二版会附加一个“
阅读全文
摘要：昨天一个测试工程师发邮件给我，询问软件评测师考试的一个题目的答案。题目是关于估算系统中存在缺陷数量的，原题如下：
“两个小组独立地测试同一个程序，第一组发现25个错误，第二组发现30个错误，在两个小组发现的错误中有15个是共同的，那么可以估计程序中的错误总数是 ___个。
A．25 B．30 C．50 D．60”
当然，任何一个了解估算方法的朋友都可以根据公式计算出最终的结果是50个，这没有什么问题。——但是，我在这里引用这个题目，是希望我们可以把学习这件事情通过类比变得“更加有趣”一点。
其实，如何估算一个系统中存在的缺陷数，我们的老祖宗早就有现成的方法了。不信，请看我在我们老祖宗的数学专著中找到的一个实践问题：“有一口鱼塘，不知道其中有多少条鱼，如何才能估算出池塘中鱼的数量？”（当然，原文不是这样，请原谅我一下子找不到出处，只好凭记忆用我的语言描述一下了）。我们老祖宗给出的答案是这样的：
………………
阅读全文
摘要：在Zee的论坛里面和大家讨论了一下关于如果学习编程的问题，觉得挺有意思的，干脆贴在BLOG上了，呵呵。
阅读全文
摘要： 从内心来说，我非常非常同意Raymond的话：你要自己去“挣”回一个答案。在我看来，简单的说，关于提出问题，大致是3点：
1. 没有人有义务回答你的问题，所以请不要动辄大叫“为什么没有人回答我的问题？高手在哪里？”——越是高手，越是时间宝贵，也许根本原因是，你的问题不值得他们浪费时间；
2. 不要把提问变成一个简单的索取，你的问题只有在给其他人带去同样的价值和收获的时候，才会引起他人的关注，所以请不要在论坛上大叫“这段话我看不懂，谁能给我讲一下？”
3. 请只有在确认自己无法解决这个问题的时候，才向他人提问——“确认”的意思是说，你无法从其他任何来源获得关于此问题的信息，不想看，不愿看，看不明白不在此列。
阅读全文
摘要： 很多测试工程师强调测试的方法和思想，到底什么是测试的方法和思想？
测试的思路是一种立体的思路，物理学在说到多维空间的时候，往往会用“生活在球面上的动物”来形象地说明二维空间和三维空间的不同，在这里我也想借用多维空间的概念说一说测试。
阅读全文
摘要：上周让几个来应聘的应届毕业生参加了我们的笔试，我答应他们在明天给他们是否能参加下轮面试的答复，结果今天突然接到了前台转来的电话，正是其中一个应聘的毕业生打过来的。说实话，接到电话的时候，我有些不那么高兴，毕竟，答应的是明天答复，今天就询问具体结果，在我看来，和不请自来一样的唐突。可是接下来，电话那头的声音让我改变了不高兴的态度。
我欣赏的是她的勇气和热诚，我相信，一个有勇气和热诚为了自己目标而行动的人，总能获得他/她想要的成功。因此，我决定给她一个下轮面试的机会，不管她最终能否进入我们公司，迈出她的第一步，我宁愿相信，因为勇气和热诚，在今后的工作和生活中，她都能够在自己人生的道路上快乐和幸福的前进。
阅读全文
摘要：建立高效的测试团队是每个测试经理的希望，但究竟该如何才能建立一个高效的测试团队呢？
建立高效的测试团队首先要从“人”的问题抓起，只有在了解测试工程师这个群体后，才能针对各种不同类型的测试工程师进行具体的安排和管理。本文结合作者本人的测试管理经验和思考，首先分析了测试工程师的不同类型，并从系统的角度出发，给出了一些可行的建议和方法。
阅读全文
