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

　　精彩回答：

　　陈甫?：

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

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

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

　　假定你打算写一个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的少步骤；可能的话，将重现步骤做自动化；