软件测试的魅力何在？

问题： 软件测试的魅力何在？您为什么选择测试一行而不做开发？

　　精彩回答：

　　陈甫鸼：

　　虽然我现在换到开发去了，不过毕竟也在这一行做了六年，貌似还是有机会在这里发言的吧。最初我接触测试纯粹是出于偶然，微软到我们学校的面试只有做测试的肯要我啊。不过后来做了一阵子之后慢慢就喜欢上这个位置了。说说我过去的一些经验吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　1、开一个bug；

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

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

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

　　5、尝试给出一个fix；

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

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

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

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

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

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

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

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

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

朱杉：

　　和软件测试遭遇是个偶然，故事有点长，有空且看看作消遣吧。之前在一国企做金融类软件开发，开vi写C偶尔还客串VB，终于不堪一年200工作日以上的出差在外和出差期间彻夜加班且无双休待遇之折磨，一怒之下转而重回学校作个调整。大学同学所在公司招收实习生，本着赚点学费生活费的需要，抱着没做过的事情试试无妨的心态，邂逅了软件测试。研究生期间，学校先后开设了两门软件测试的课程，由于有实践在先，发现学习起来颇有心得。由于老师要求严格，第二学期选课人颇少，于是一门大课变成了给少数几个人开小灶，时间和资源瞬间变得充裕，让我受益匪浅。而自身的一些观察、分析、理解、想象能力上的优势逐渐在这个学习+实践的过程中体现出来。同时，在实习公司那边，我开始跟进一个至今说起来都让大家望而却步的新功能开发，遇到了开始做测试以来最大的一个挑战，那绝对是一段痛苦不堪的日子，但也正是这段时间让我飞速地成长起来，并获得了大家的认同。毕业后，自然也就留在了这家公司，正式加入了软件测试的大部队，似乎也不存在选择的问题。

　　软件测试的魅力嘛，其实在你这个问题之前，我也没有刻意地去想过，况且一百个人眼里一百个哈姆雷特，大家的痒处也未必在同一处。于是就临时想到的说上一说，个人色彩浓，可能不太切题了：

　　首先，我喜欢玩解谜类的益智游戏，而且发现我对这类的游戏通常上手较快。虽然我说不好这个跟测试具体有什么关联，不过有一些感觉是一样的，观察、推演、尝试、归纳、发现，一个妙趣横生的过程。测试本身也是对这方面能力的一个综合考验，拿到一个难题的时候那种又担心又手痒的感觉实在是和玩游戏很像。测试的过程又是一个学习和思维进一步发散的过程，一直引领人往前探索，很有吸引力。

　　其次，新鲜感。我做功能测试和可访问性测试，新功能的探索和发现，是我个人一直爱接新功能胜过做回归的主要原因。新工具新技术的发现和学习是个有趣的过程。测试其实是个目的驱动的事情，基于这一点，没人会要求你从头造轮子，能拿来用的现成都得学会捡，不然什么都要从main写起，黄花菜都凉了。囤新奇工具、学新鲜技术，都是有趣的事情。

　　再者，成就感吧。作为某应用的QA owner和一个dev团队长期合作，虽然大家也会有争论，时间紧张的时候也会互有抱怨，但合作非常顺畅。只有Dev和QA把发布一个健康的产品当做共同目标而密切合作的时候，才是一个良性的开发生态环境，一个成功发布的产品是大家共同努力的成果，既是dev team的骄傲，也是QA的骄傲，即使走向前台接受赞誉的更多是Dev，你也能因你所做出的贡献而自信满满，成就满满。想想，在参与设计讨论时指出可能存在的设计缺陷，在功能开发之前提供建议避免功能误读和错误风险评估，一个描述清晰、根源挖掘准确充分的defect送到dev处被干净利落地斩草除根，当support team来征询产品功能的相关问题时，当用户来寻求解决方案时，是不是都有一种叫成就感的东东在心里撒了欢地奔走呢。

　　最后，当跟你吵架吵得最凶的开发背着你对别人夸你是最好的QA的时候，那种感动，一辈子都不会忘记的。