Fuzz testing,中文可以翻译为模糊测试，简单的说来就是构造一些random或者unexpected的数据作为程序的输入，观察程序在这种情况下的工作状况。Fuzz testing是检查程序容错性的一个重要的测试手段。

虽然Fuzz testing的输入在正常情况下不大可能出现，但是hacker并不这么想，作为一个hacker，他可能千方百计的想要找到你程序的漏洞，或者使你的程序crash，用random的输入是hacker的一个很好的选择。因此，Fuzz testing也是security testing的重要组成部分。

关于Fuzz testing的最老网站是http://www.cs.wisc.edu/~bart/fuzz/fuzz.html，在这个网站中我们可以看到最早的paper/report是在1990年，可见Fuzz testing也不能算是一个新的东西。在这个网站的一个对于windowsNT的Fuzz test report中，我们看到一些很令人吃惊的数据。

• 在random键盘或者鼠标输入的情况下，NT4.0有21%的程序crash
• 在random键盘或者鼠标输入的情况下，NT4.0有另外24%的程序会hung掉
• 在完全random的键盘或者鼠标的输入情况，几乎100%的程序会crash或者hung

如果NT4.0表现的都如此之差，其它的程序应该也好不到哪里去。

Fuzz testing的strategy:

对于Fuzz testing来讲，也并非完全random的数据输入就是最好的选择，程序crash也并非是hacker们最期望的事情。因此Fuzz testing也需要有一些strategy。

我们以一个网站的测试作为例子来过一下，假定我们现在是一个http server的提供者，hacker想要对这个网站进行攻击。通常来讲，他有几个选择：

1. 用洪水攻击之类的方法使网站拒绝服务
2. http报文注入，获得该机器的权限
3. random的http报文，使http server(IIS/Apache/...)服务不可用

如果我是hacker，从获得的好处和攻击的难易程度上来考虑，选择的优先级会是2>3>1

因此，我们来看一下2如何做到。

一般来讲，http请求报文会像下面这样：

Get /mattmarg/ HTTP/1.0
User-Agent: Mozilla/2.0 (Macintosh; I; PPC)
Accept: text/html; */*
Cookie: name = value
Referer: http://www.webmonkey.com/html/96/47/index2a.html
Host: www.grippy.org

那我们如果要修改这样的报文（请参考http://sourceforge.net/projects/taof/）然后再转发，最合适的选择是1.Get后面的"/mattmarg/";2.Referer后面的那一长串网址。至于如何修改，那真的是需要一些背景知识，以及对于以往的网站安全漏洞研究的经验。

Fuzz的一些参考网站：

http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/

http://www.packetstormsecurity.org/fuzzer/

http://ivory.idyll.org/blog/nov-06/testing-is-hard.html

三个差不多了，慢慢研究。

对于一台榨汁机的需求阶段，需求还没有整理出来，测试人员先行介入，测试人员应该从哪些方面考虑测试用例？

我不知道是哪位仁兄出的这道题目，也不知道这位仁兄的原意如何。但是如果要我来回答，那我的答案是：“无可奉告”。

我们先来回顾一下软件测试的定义。现在一般分为两派，一派认为软件测试是为了证明软件“可以工作”，另外一派认为软件测试是为了证明软件“不能工作”。好，不管是那派，他们都需要有一个可以测试的东西作为基础，才能开始下面的证明工作。出题目的仁兄告诉我们，“需求还没整理出来”，测试人员就“先行介入”了。如果不是题目的陷阱，那只能认为这个项目的团队“有问题”。在需求还不明确的前提下，测试人员可以做的事情有两个：一是学习和项目有关的基础知识，剩下的就是等待。（需要指出的是，在需求不明确的前提下，开发人员是无法开始做high level design的，更加谈不上让测试人员参与design的讨论）

回到题目上来，我们假设题目有所改变，该榨汁机是一台普通的榨汁机，插电后放入水果或者蔬菜，按动开关，就可以榨汁。（和市面上能买到的差不多）那么需要如何考虑测试用例？虽然没实际用过榨汁机，但是靠想象应该也差不多。

1. 考虑90%以上用户的使用习惯，确保最基本的功能-榨汁能够正常运作。

• 通常的水果：西瓜、番茄、黄瓜、苹果、草莓、香蕉、李子、甘蔗等单独作为输入。
• 非常见：玉米
• 水果的混编作为输入。
• 在输入容器所能容纳的情况下，输出的量杯是否足够大能容纳榨出的液体。
• 在水果较硬的情况下，是否能正常工作。
• 水果较软的情况下，是否能正常工作。
• 如果有按钮或开关调节，测试按钮或开关的可用性和有效性。

2. 易用性测试

• 榨汁机的外观是否美观。这是用户选择的关键。
• 榨汁机的电源线长度是否足够。
• 量杯大小测试

3. Force Error测试

• 在空转情况（无输入）下做榨汁
• 在有异物（如蔬果的枝叶）的情况下做榨汁
• 在榨汁过程中停电，看是否能恢复
• 110v电源输入测试
• 在高温的情况是否能正常工作（40度以上）
• 在周围有磁场的情况下是否能正常工作
• 掉落测试

4. Security 测试

• 是否有儿童手指保护措施？
• 在榨汁有漏出的情况下，是否会有漏电？

5. 耐用性测试

• 刀片耐用度测试
• 平均无故障时间统计
• 按钮或开关耐用度测试
• 榨汁机使用寿命测试
• 榨汁机本体容器压强测试

基本上来讲，就是这些，对于一个只在电视上看过，从来没用过的人已经是一件不容易的事情了。

今天看到一个有关测试的故事：

====================================================================================
关于测试的故事
在产品周期中， 有三位测试人员根据要求开始测试软件。
测试员1：
立即开始手动测试，并发现一些细微的错误。开发团队高兴的修复了这些错误， 然后提供一个新的软件版本以供测试。测试的越多，发现的错误越多， 修复的错误也就越多。
测试员1 觉得很有成就感，也就会感到快乐――至少一段时间是这样的。
经过几轮这种发现、修复的循环，他开始由于一遍遍的手动重复运行实质上一样的测试而感到乏味和反应迟钝。当测试员1 最终丧失积极性― ― 同时也就意味着失去耐性― ― 就会宣称软件可以发布了。用户发现它有太多的错误， 于是购买了竞争者的产品。
测试员2：
从手动测试开始，但很快就判定创建自动执行按键的测试脚本更有意义。仔细找出那些会使用到软件有用部分的测试后，测试员2 将操作记录到脚本中。这些脚本很快达到几百个。按下一个按钮后，这些脚本就被激活并按照步骤运行软件。
测试员2 觉得自己很聪明，也就会感到快乐――至少一段时间是这样的。
当软件发生变化时，这些脚本需要大量的维护。他花费数个星期开发人员争论，要求停止修改软件，因为这破坏了自动化测试。最和后， 脚本需要太多的维护以致留下太少的时间来进行测试。
当软件发布后，用户发现太多脚本未覆盖的错误。他们停止购买该产品而决定等待版本2 的发布。
测试员3
不想维护数以百计的自动化测试脚本。他编写了一个测试程序来在应用程序中到处随机点击和按按钮。这种“随机”测试程序不需要一直查看， 且发现了很多致命的错误。
测试员3 很享受发现这些引人注目的缺陷，也就会感到快乐－－至少一段时间是这样。
由于随机测试程序只能发现那些毁坏应用程序的错误，因此测试员3 仍然不得不做大量手动测试，并很快在这个过程中感到乏味和反应迟钝。当软件发布后用户在软件中发现如此多的功能性错误而对公司丧失信任， 于是停止购买这种软件。

评注：
测试员1 是一个典型的手动测试者， 从键盘手动运行所有的测试。手动测试在当前的工业界很普遍――它能提供直接的好处，但长时间的运行会让测试人员感到单调乏味， 对公司来讲成本高。
“我看到的最悲哀的景象之一就是一个人在键盘上手动操作一些可以自动运行的东西。这是悲哀的但也是有趣的。”
黑盒测试： 软件和系统功能测试技术

测试员2 实践的是我称为静态测试自动化的测试。静态自动化脚本每次根据同样的次序执行同样的命令序列。当应用程序发生变化时这些脚本的维护成本很高。测试是不断重复的；但由于它们总是执行相同的命令， 因此它们很难发现新的错误。
“高度重复的测试实际上将发现所有重要问题的几率最小化了，这和沿着别人的足迹前行将发现自己的天地的几率最小化的原因是一样的” “骗人的测试自动化”

测试员3 的操作接近于自动化测试的边缘。这些类型的随机测试程序被称为蠢猴因为它们就是毫无目的的敲打键盘。它们生成非常规的测试执行序列并发现很多致命的错误，但是想控制它们到应用程序中你想测试的部分却是很困难的。因为它们不知道自己在做什么，所以它们会漏过应用程序中很多明显的错误。
“猴子式的测试不能是你测试的全部。猴子不明白你的应用程序，由于它们的无知它们漏掉了很多错误。”
“使用猴子式的测试工具,”
小结：
测试员1 的方法需要他的手不停的在键盘上工作。最后测试员1精疲力竭。
测试员2 的静态脚本重复他的手已经执行过的那些键盘操作。
测试员3 的猴子式测试本质上是无目的的在键盘上乱敲。
Now ：what we should do to test more science and more effective ？
;)
====================================================================================

最后，作者问了一个问题。What we should do to test more science and more effective?

我想先问一个问题：How perfect you want a software to be?

作为一个测试人员，首先需要意识到一点，你测试的软件不是完美的，而且，也不可能通过你的测试使它变得完美。假设你找到了90%以上的bug，为了准时release，可能有一些bug还是会决定不被fix。在这种情况下，找到所有的bug的意义何在？

作为一个软件，在大部分情况下，这个软件的功能不是100%被用户用到。有些功能可能永远都不会被用到。这同样适合于硬件。假设你有一个手机，你是否用到了手机的所有功能？我想大部分用户给我的答案都是no。
所以，我们不妨有一个假设，软件也好，硬件也好，常用功能和不常用功能符合28原则的比例。那测试人员的value就在于，如何保证那最常用的20%的功能的最稳定的被使用。

我们可能按照priority和serverity把bug分成p1,p2,p3...和SA,SB,SC...，同样，我们假设品p1/p2/sa/sb的bug占有总bug的20%，那么测试人员的目标就是，如何找到这些20%的bug并让它们被开发人员fix掉。

测试包含很多种，在前期介入时和开发一起做的design review甚至code review， 这些称为Early Defect Finding。前期的介入虽然没有bug可以体现，但是同样是测试人员表现其价值的地方。聪明的项目经理可以意识到这一点，同样，mature的测试经理或lead会主动要求参加这样的活动。

当产品design完成，测试人员开始准备测试用例。这个时候，需要做好测试用例的review。有经验的测试经理会邀请开发人员共同做测试用例的review。

当第一个正式的build出来以后，测试人员才正式开始测试。在前期，主要是保证主要的feature能够工作正常。这个期间手动测试是最多的。可以发现的P1/P2/Sa/Sb的bug也最多。

然后，在daily build正常运转后，测试人员开始做一些简单的automation工作，保证daily build的有效性。同时，有一下explore测试和系统测试开始involve进来。

如果这个项目有L10n需求，那么开发人员需要做各个语言版本的build，测试人员开始做针对各个语言版本的测试。

一般来讲，high volume测试都是需要保证的，考虑到如果软件需要成天的被run而不能crash。

对于coverage测试，个人觉得需要每个测试成员来保证，他自己的test case能够cover到所有的fuction。这个回在后面的日志进行讨论。

Resource leak和Stress状态下的测试也是需要做的。

扯远了， 但是如果有这么多的activity需要做，身为一个测试人员，大概不会为每天的regression test而感觉到boring。

回来，作为测试人员，重要的一点是，"Do what user may do during your test"， 这样才做到了一个测试人员的最本分。至于如何做的更好，那需要：

• 学而时习之
  
• 举一反三

Anyway, Go ahead, it is interesting to be a tester.

Automation Rate永远是软件测试经理或者Team Lead的痛。 每个在位的测试经理能想到的，和别人谈的最多的，就是怎么把Automation Rate提上去。 道理很简单，Automation Rate提高了，不但可以减小测试team在回归测试时的effort， 同时这也是一个Measurable的指标，是衡量一个team成熟度以及是否efficient的一个“重要”的标准。

然而Automation Rate永远不是那么容易提高的。一方面，国内的软件开发流程规范的很少，对于一些时间很紧的项目来讲，开发人员不愿意写设计文档。另外一方面，软件测试人员自身的素质有待提高，现在国内一般的情况是，员工通过面试，发现达不到开发的标准，还能被招进公司做测试人员。最后，在项目紧的情况下，如果有专门为Automation预留了时间，项目经理为了准时release，第一个砍掉的项目活动就是Automation.

在这种情况下，可谓是内忧外患。如果测试经理或者lead不够成熟，把Automation想成是用几个工具就可以达到的目标，那项目的automation测试基本上就是一项不可能完成的目标。

首先，测试经理或者lead要意识到，automation是为了提高测试团队的效率，保证回归测试的质量，提高项目release是整个项目组的信心，同时automation smoke test的case可以保证daily build的有效性。

其次，要做automation，需要有其他的基础。这个包括：

• 是否有专门的test case管理工具？测试的结果如何输入？测试经理或lead如何做monitor？
• 项目的test case是否完整？是否有效？如果有专门的测试开发人员，是否仅仅考查看case和看设计文档就能实现case的automation？
  
• 实现Automation的人员（可以是part time或者dedicate的人员）是否对需要automation的test case有足够的理解？如果没有，那说明还没有准备好开始做automation。
• 是否选择了有效的工具，很多人都用的工具不一定适合你，对于automation，轻量级的工具我个人更prefer，如果automation的人员有足够的知识，请专门花一点时间做programming。开始为了实现automation可以选择robot，QTP，Autoit等工具，但是做久了就会发现其实工具这个东西，运用之妙，存乎一心，测试人员永远不要为工具所限制，而是尽量把适合的工具用在适合的地方。
• 是否需要通用的automation框架。现在框架很多，STAF，RRAFS，关键是这个框架是否适合你的项目？

再次，是否能够让项目经理同意为automation预留resource和时间，这个对于测试经理来说相当关键。如果没有，那测试人员只能牺牲休息时间来做automation，对项目士气影响很大。

然后，如果决定开始做，automation绝对不是一个人的事情，做的人同样需要有design，需要team内部进行讨论这个方案的可行性。automation程序如何设计才能应对开发的设计变更？这些都需要考虑。

最后，automation的成果能否有效被保留？是否能有效的和daily build相集成？是否有使用说明书？是否有设计文档？测试team是否有自己的版本控制工具？是否有专人进行维护？这些都是automation程序开发人员需要考虑的事情。

如果不做automation，其实世界照样转。 如果你能用开发automation的时间发现更多有价值的bug，使release出去的软件quality更好，其实这样的QA/QC engineer更有价值。