最初我接触测试纯粹是出于偶然，微软到我们学校的面试只有做测试的肯要我啊。不过后来做了一阵子之后慢慢就喜欢上这个位置了。说说我过去的一些经验吧。

　　正如我之前在很多回复中说的，测试和开发是两个关注点不一样的工作。开发的目标是实现功能，测试的目标是确定功能是否能够正常运作。那么它的乐趣在哪里？简单地说是两个关键词：“发现”和“分析”。

　　一两句话很难说清楚，举一个例子吧。

　　假定你打算写一个VOIP程序，请问怎么测试它的效果？没有经验的测试可能会告诉你我连上两台机器确定电话可以打通就可以了，而有经验的测试可能会给你列出一大堆的组合：

　　你的场景支持笔记本和耳机么？你支持什么耳机？蓝牙还是3.5mm插口耳机？

　　你的场景支持使用笔记本麦克风么？还是只支持配麦克风的耳机？

　　你的场景支持使用手机设备么？Android还是iOS？

　　为什么要列出这么多东西？有人可能会对此嗤之以鼻：只是为了保证什么都能测到而已。但是其实这里每一个场景都是有意义的：

　　蓝牙耳机普遍都有硬件支持的回声消除模块（Acrostic Echo Cancellation)，而普通3.5mm耳机则通常由于结构简单而没有。对于没有回声消除的普通耳机，我们必须自己提供软件的回声消除避免影响接听效果。

　　我们不能使用完全相同的逻辑处理耳机和笔记本麦克风的语音输入。因为耳机麦克风的定向性比笔记本麦克风强很多，它只能取到声源凑得很近时发出的声音，而笔记本麦克风的设计则是用来在屏幕前相当大的范围内取声的。如果对笔记本麦克风使用耳机麦克风的声音检测算法则会由于灵敏度过高而将大量周边杂音收入，影响通话效果。而且有些场景是笔记本麦克风特有的，比如用户的打字音和风扇噪音。

　　Android和iOS都有内建的通话模块。iOS甚至提供了非常高效的回声消除和增益控制模块，但是没有静音检测模块。所以如果桌面程序移植到手机上时可以很好地利用这些功能简化自己的代码。而Android的回声消除模块则表现非常不稳定，需要很多调整才能得到较好的效果。

　　这就是所谓的“发现”，发现开发没注意的地方，发现项目经理没定义的场景，并提出相应的测试场景。这需要宽广的知识面才能做到。没有经验的测试更倾向于对所有测试的平台做全排列，但求不忽略任何一个场景。这在资源无限的情况下当然没问题，但真实项目中，测试的资源经常是最有限的，所以我们得学会怎么做最有效的测试，而不是闭着眼睛搞全面铺开。

　　那么什么是“分析”？举例来说：如果一个内测客户投诉你的VOIP程序实际使用中声音断断续续，你怎么分辨问题的原因？声音断断续续的情况有很多种，有由于网络延迟导致的，有由于操作系统处理过于繁忙导致程序执行时间被高优先级程序抢走而导致的处理中断产生的。我们怎么去分析哪些原因呢？没经验的测试可能会直接要求跑客户现场看看，但如果用户的环境不是每次都重现该怎么样？有经验的测试会提出：我们可以给客户一个调试用的版本，这个版本要求把数据包的收取时间点和每个数据段的开始处理时间点和CPU占用率纪录下来。通过前一个我们可以测量用户的网络情况，后一个数据段可以用来发现是否是操作系统换出导致的。反过来，对产品不熟悉的人，这些数据可能看不出什么用途。

　　有人说，这些都可以让开发来做，用不着测试。完全正确。可问题是：开发有时间做这些么？在微软这样级别的公司里，所有的项目都有严格的开发进度，开发部门忙于实现功能的时候，我想没几个产品经理会同意频频打断开发的进度要求停下来做bug分析。

　　另一点是我们不需要把开发和测试的界限分得那么清楚。事实上大部分如今的跨国IT公司都很少分开发和测试这两个职位（大约只有微软还严格地分两个职位吧，即使是这样，搜索那边也开始探索改变了），但是要做的工作还是那么多，只是顶着的头衔换了换，所以没必要纠结。

　　=== 我是转换话题的分割线 ===

　　另一个问题是关于测试的工作方式的。就像开发一样，有经验和没有经验的测试在团队起到的作用是很不一样的。从测试中遇到问题采取的行动来看，我观察到的测试人员能达到的层次大概有这么几个级别：

　　开一个bug；

　　查找一些额外的资料如设计文档和历史，确定这是一个问题，然后给出详细的bug重现步骤；

　　对重现步骤做一些精炼，确定能够重现bug的最少步骤；可能的话，将重现步骤做自动化；

　　尝试通过研究代码确认问题所在；

　　尝试给出一个fix；

　　对错误的原因进行分析，提出一些标准化的方法来检测出类似的问题，比如stress，fuzzing等等；

　　能够对标准化的测试流程定义对应的数据分析方法，可以保证开发和项目主管都能从中得到需要的信息来掌控质量状况。

　　那么作为一个测试人员，我们的目标是什么？我对自己的目标是能对我控管的所有的bug从1做到4，在至少两个例子中我甚至能做到级别6。我在微软六年多，在很多部门都见到过可以见到可以总是做到级别7的测试，能做到这个状态的测试，没有人敢说他们技术不行。对于开发人员来说，如果你身边有一位能对大部分bug做到级别4的测试，我相信开发的工作也会轻松很多。

　　即使是抓bug也分很多种。抓一群猴子来随便在键盘上胡点两下算是测试，认认真真地一步步通过各种技术手段（代码覆盖、压力测试、安全分析等等）来步步推进也是测试。作为技术人员，你信任哪一种？我想多数人都会选择后者，但我要说的是在实践中很多测试团队都会不知不觉地变成前一种。为什么？因为测试对产品的设计不了解，所以本能地会选择最容易做的，可问起他们：你们测了多少？信心多高？他们就都傻掉了。我不是说猴子测试没意义：恰恰相反，它可以抓到我们思维上的许多盲点。但如果你的整个团队完全靠猴子测试过日子，那绝对不可能给你一个可信任的结果。

　　那么看官们必然会问，这种大牛测试和大牛团队有多少？很不幸，就我个人的经验来说，事实是在我遇到的测试人员中，最多只能做到级别1的测试人员并不罕见，能做到3的测试人员就被很多人认为相当不错了，至于团队中存在多个大牛测试的队伍则真的很少见（微软总部的比例高很多）。是的，别惊讶，这就是我工作中遇到的情况。但是请注意，这不是说公司在花钱养废物，而是说在没有专业测试教育的情况下在入行初期必然会导致的现状。我们所有人都是从这个状态开始的，也都需要时间来让自己进步。

　　也许还会有人问：这不是跟开发抢活儿干么？是的，没错。但为什么不能抢呢？我们的目的是什么？是开bug还是做更好的产品？如果你的全部目的只是多开bug，那真的很简单。真实的例子，我曾经见过有同事将测试自动化代码的bug开成产品bug的，他的理论就是不管bug是什么，先开出来再说，至于它是产品问题还是测试代码的问题甚至是环境的故障都可以缓一缓，反正他不负责指出原因。我知道要求一个同事干这个干那个很不礼貌，但这种什么都不做就先开了bug再说的做事风格是在耽误所有同事的工作。作为团队的一分子，测试在产品上多花一分时间，有时候能省下开发几天的工作量，因为测试是最熟悉这个bug的人，而开发则需要从头开始分析。

　　——当然，反过来开发也应该尽量将测试带入开发过程，让大家都知道各种功能进度的细节。这种合作同样能大大减少测试在产品设计变更时重新设计用例的时间。

　　有人可能还要问：我的时间也很宝贵，为什么要替开发省时间？嗯，好问题。但我想谁都知道该怎么回答这种“问题”。

　　现在知道我为什么要做六年测试了么？