摘要：
模糊测试（fuzz testing）是一类安全性测试的方法。说起安全性测试，大部分人头脑中浮现出的可能是一个标准的“黑客”场景：某个不修边幅、脸色苍白的年轻人，坐在黑暗的房间中，正在熟练地使用各种工具尝试进入某个系统。这种由安全人员“模拟黑客进入系统”的测试方法的确是安全性测试中的一种有效测试手段，名叫“渗透测试”。渗透测试方法完全依靠测试执行者的能力，能力强的“白客”能够发现有价值的安全性漏洞，而不具备很强的攻击能力的测试者就无法有效发现系统中的安全性漏洞。必须承认，渗透测试是一种有效的安全性测试手段，当然，前提是你要能够找到足够好的测试执行者。
渗透测试是一种有效的测试方法，但由于它对执行者的能力要求太高，因此很难被大规模应用。站在测试的角度，我们是否能够用“自动化测试”这个强有力的武器帮助降低安全性测试的门槛呢？一个容易想到的“录制/回放”方法是：将渗透测试的执行者们的操作录制下来，形成脚本，期望这些脚本可以在不加修改或是稍加修改时应用在对其他应用的安全性测试中。但由于渗透测试的过程并不具有可重复的特点（测试执行主要依赖执行者的经验，类似调试），这种想法在真实的安全性测试环 阅读全文
2013年12月20日
2012年12月25日
摘要：
话说自从我厂的商务部门搬到旁边的商务楼之后，工程师发现漂亮的前台MM也搬走了，某区只留下冷冷清清的鱼缸。然后，工程师们发现开门成了个问题。鉴于进门需要刷卡，所以没有带卡的工程师就不得不摁下门铃，等待其他人从座位上起身为自己开门。经历过多次不得不让别人来开门以及不得不为别人开门之后，终于有工程师不能忍受了（我就是其中一个），于是，决定自己动手解决问题。要知道，地球上没有能难住工程师的问题！
研究与选择方案：
我厂的电子门锁的开门设备是通过一个带弹簧的开关（门内，类似墙面上开灯的开关）控制的，按下开关就能打开门，按下开关的时候能够听到明显的继电器闭合的声音，因此，趁着没人的时候我把开关拆开看了一下，证实的确是通过触电控制的一个继电器。按下开关时，两个金属触电接触，继电器动作，门打开。继电器在动作后延时4秒左右恢复。这样看来，硬件层面的开门实现就非常简单了：跨接一个数字继电器，要开门时，通过电平信号控制继电器闭合并保持2秒即可。 阅读全文
2012年10月17日
摘要：
作为一个已经有多年工程师面试经验，并在国内的大企业，小企业，国外的大企业，小企业混迹过的面试官（注意，我是技术人员，不是HR），我在微博上的吐槽的确有戏虐的成分。每年的校园招聘季，阅读和筛选简历都是我重要的工作之一。在一上午时间内怀着生怕错误优秀人才的心态伏案阅读了接近40份简历的我来说，在简历中看到让自己“情何以堪”的内容吐个槽，似乎也合情合理。不过，简历中是否应该包含“精通”并非是我吐槽的重点，目前完全由于应届毕业生在简历中写了过多精通而被直接挂掉的事情在我身上还未发生过，过多的“精通”表述最多只是我看不惯的一个点而已。
看到回复中有不少怀着热切心情找工作的应届毕业生（或是将要面临找工作压力的非应届毕业生），我觉得也许我可以从一个面试官和用人公司的角度描述一下我的体会。
找到“好的”工作必然会给初涉职场的各位应届毕业生一个良好的起步基础，加上走出校园面临的各种不确定性和在一个城市生存下来的压力，找工作基本是各位希望走出学校的应届毕业生自己的头等大事。我不能像大师们一样给各位斩钉截铁的“可行建议”，只是希望能让大家了解从我这样一个面试官的角度如何看待应届毕业生招聘这件事情 阅读全文
2012年8月21日
摘要：
本文的标题借用了安东尼.韦斯顿（Anthony Weston）的《论证是一门学问》一书的标题，向安东尼老爷子致敬的同时，也希望更多人能够真正了解“什么是论证”。
争论与论证从来都不是新鲜事物，作为软件行业的科技工作者，理应对各种论证的手段了如指掌才是。然而，从各种我参与的有争论的场合来看，事实并非如此。许多论证最终都停在口号式的结论，或是由于自说自话无法进行下去。科学对人类的贡献之一在于科学的方法，而“合理”的论证方式才是科学真理得以彰显的手段。
《论证是一门学问》一书（http://book.douban.com/subject/5399343/）中提到了论证的基本规则，以及各种论证的方式：类比论证、因果论证、演绎论证。这些方法都不是什么难度很高的方法，但在实际的争论过程中，尤其是在微博上进行的论证中（字数的限制也是导致误解的原因之一），却并不经常被论证的双方所遵守。
一个观点包含“前提”和“结论”。前提是为你的结论提供理由的表述。前提一般基于具体的事实或是已经被事实证实的结论，通过前提，借助各种论证的方法就能推导出结论。这个过程看似简单，在很多情况下却并非显而易 阅读全文
2012年6月6日
摘要：
该书的第一版是在2006年出版了，算起来，第二版离第一版都已经6年了。
《性能测试过程详解与案例剖析》这本书的写作目的简单且纯粹：在计划写作本书之前，市面上还没有一本原创的性能测试的中文书籍，而我因为做了几年的性能测试，有一些积累，希望能够和大家分享自己在性能测试方面的体会。因为这个原因，2006年我完成了这本书第一版的写作。写作过程消耗的时间和精力远超我的想象，所幸2006年第一版出版后，获得了大家的认可，给一些需要了解和提高性能测试知识和技能的朋友提供了帮助。
本书第二版的写作意向开始于2009年。不少读者给我来信，询问这本书可以在哪里买到，或是指出书中覆盖不够全面的地方，让我萌发了写作本书第二版的念头。但由于工作太忙，同事需要照顾家庭，该书的第二版工作一直进行得断断续续，期间几次准备中途放弃了。所幸在出版社和家人的支持下，在3年的时间里，终于还是完成了这本第二版。与第一版相比，第二版 阅读全文
2012年4月15日
摘要：
左耳朵耗子发表了《我们需要全职的QA吗？》后，一石激起千重浪，赞成者有之，激烈反对者有之；有人说文中对QA的定义不对，还有人说以偏概全…… 的确，在需不需要专职的QA角色这个问题上，很难用一个简单的“需要”或“不需要”来回答。前两天我写了一篇对该文的回应文章，但由于文章写就得比较仓促，很多观点来不及完整表述，因此，在“真理越辩越明”的原则下，在这边文章中，我准备就“我们需要什么样的测试”这个问题说说我自己的看法。
首先要说明的是，这篇文章完全不是讨论“我们是否需要专职QA”这个问题的，也不是讨论“各种情况下QA或测试工程需要做什么”，而是从我自身对测试的认知和个人经验出发，说一说我对不同特点的产品需要的测试的看法。 阅读全文
2012年4月12日
摘要：
说实话，在我看来，左耳朵耗子的《我们需要专职的QA吗？》这篇文章的观点并不算过激。最多就是一篇从开发工程师的角度来商讨是否需要设立“专门做测试的岗位”，让“不熟悉或是不懂开发的人”来做测试工作。如果这个问题摆在我的面前，在大多数情况下，我的答案可能和左耳朵耗子一样：“不需要”。
作为一个在测试行业工作了10多年的“老人”，在这里赞同左耳朵耗子的观点似乎是对自己过去这么多年工作的否定，但实际上，正是因为有这么多年的经验，我才真正能够深刻的体会专职测试工程师在工作中的局限和不足。 阅读全文
2010年12月15日
摘要：
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。
确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量，或是敏捷开发实践中的“测试驱动开发”，“行为驱动开发”，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中 阅读全文
2010年11月15日
摘要：
上周六在杭州的《互联网软件测试大会》上做演讲的时候提到可测试性的话题，顺手举了一个例子：“B类存在对A类的依赖，A类是一个Singleton类，B类使用到了A类中的一个需要被mock的函数，这种情况下如何处理？” 本来，这是《修改代码的艺术》上曾经提到的一个典型模式，该书中有非常详细的描述。但今天收到某位听众的邮件，问这个问题应该怎么回答。
正好好久没有写过blog了，于是顺手写了一段简单的代码来说明这个问题。 阅读全文
2010年5月20日
摘要：
为什么要使用开源测试工具？
作为一个开源测试工具的推崇者，我经常被问到这个问题。许多测试工程师对商业测试工具情有独钟，总觉得商业测试工具既好用又强大，而开源测试工具功能弱，缺陷多，而且不好用。对开源测试工具的偏见一方面来自于商业测试工具的宣传，另一方面，也来自部分测试工程师在使用开源测试工具过程中的心态。
在本人所在的组织中，公司内使用的绝大多数测试工具或多或少都有开源测试工具的影子，从开源测试工具在本组织的应用中看来，使用开 源测试工具带来的优势非常明显… 阅读全文
