正如我之前在很多回复中说的，测试和开发是两个关注点不一样的工作。开发的目标是实现功能，测试的目标是确定功能是否能够正常运作。那么它的乐趣在哪里？简单地说是两个关键词：“发现”和“分析”。
一两句话很难说清楚，举一个例子吧。
假定你打算写一个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再说的做事风格是在耽误所有同事的工作。作为团队的一分子，测试在产品上多花一分时间，有时候能省下开发几天的工作量，因为测试是最熟悉这个bug的人，而开发则需要从头开始分析。
当然，反过来开发也应该尽量将测试带入开发过程，让大家都知道各种功能进度的细节。这种合作同样能大大减少测试在产品设计变更时重新设计用例的时间。
有人可能还要问：我的时间也很宝贵，为什么要替开发省时间？嗯，好问题。但我想谁都知道该怎么回答这种“问题”。

================================

-----  陈甫鸼编程话题优秀回答者

================================

和软件测试遭遇是个偶然，故事有点长，有空且看看作消遣吧。之前在一国企做金融类软件开发，开vi写C偶尔还客串VB，终于不堪一年200工作日以上的出差在外和出差期间彻夜加班且无双休待遇之折磨，一怒之下转而重回学校作个调整。大学同学所在公司招收实习生，本着赚点学费生活费的需要，抱着没做过的事情试试无妨的心态，邂逅了软件测试。研究生期间，学校先后开设了两门软件测试的课程，由于有实践在先，发现学习起来颇有心得。由于老师要求严格，第二学期选课人颇少，于是一门大课变成了给少数几个人开小灶，时间和资源瞬间变得充裕，让我受益匪浅。而自身的一些观察、分析、理解、想象能力上的优势逐渐在这个学习+实践的过程中体现出来。同时，在实习公司那边，我开始跟进一个至今说起来都让大家望而却步的新功能开发，遇到了开始做测试以来最大的一个挑战，那绝对是一段痛苦不堪的日子，但也正是这段时间让我飞速地成长起来，并获得了大家的认同。毕业后，自然也就留在了这家公司，正式加入了软件测试的大部队，似乎也不存在选择的问题。
软件测试的魅力嘛，其实在你这个问题之前，我也没有刻意地去想过，况且一百个人眼里一百个哈姆雷特，大家的痒处也未必在同一处。于是就临时想到的说上一说，个人色彩浓，可能不太切题了：
首先，我喜欢玩解谜类的益智游戏，而且发现我对这类的游戏通常上手较快。虽然我说不好这个跟测试具体有什么关联，不过有一些感觉是一样的，观察、推演、尝试、归纳、发现，一个妙趣横生的过程。测试本身也是对这方面能力的一个综合考验，拿到一个难题的时候那种又担心又手痒的感觉实在是和玩游戏很像。测试的过程又是一个学习和思维进一步发散的过程，一直引领人往前探索，很有吸引力。
其次，新鲜感。我做功能测试和可访问性测试，新功能的探索和发现，是我个人一直爱接新功能胜过做回归的主要原因。新工具新技术的发现和学习是个有趣的过程。测试其实是个目的驱动的事情，基于这一点，没人会要求你从头造轮子，能拿来用的现成都得学会捡，不然什么都要从main写起，黄花菜都凉了。囤新奇工具、学新鲜技术，都是有趣的事情。
再者，成就感吧。作为某应用的QA owner和一个dev团队长期合作，虽然大家也会有争论，时间紧张的时候也会互有抱怨，但合作非常顺畅。只有Dev和QA把发布一个健康的产品当做共同目标而密切合作的时候，才是一个良性的开发生态环境，一个成功发布的产品是大家共同努力的成果，既是dev team的骄傲，也是QA的骄傲，即使走向前台接受赞誉的更多是Dev，你也能因你所做出的贡献而自信满满，成就满满。想想，在参与设计讨论时指出可能存在的设计缺陷，在功能开发之前提供建议避免功能误读和错误风险评估，一个描述清晰、根源挖掘准确充分的defect送到dev处被干净利落地斩草除根，当supportteam来征询产品功能的相关问题时，当用户来寻求解决方案时，是不是都有一种叫成就感的东东在心里撒了欢地奔走呢。
最后，当跟你吵架吵得最凶的开发背着你对别人夸你是最好的QA的时候，那种感动，一辈子都不会忘记的。

================================

----- 朱杉 软件测试 豆瓣潜水员

================================

话说不知道为何会被邀请回答，因为我之前是开发，之后是运维，并没有很多测试实践经验。前面各位前辈总结得非常好，提一些粗陋看法以作补充。
0. 责任感：
这恐怕是开发和测试之间最大的区别。就Bug在整个开发活动中造成的损失来看，在分析、设计处是最小的，而在测试时是最大的，依赖于具体使用的开发工程模型。每个环节引入的Bug都会在下一环节被放大，导致修正成本迅速扩大，到了测试这里再发现和修正Bug，返工成本相当高，拦截和修正的责任重大。
1. 成就感：
责任感越大，成就感也越大，相伴相生。在测试阶段能测出大Bug并修正，任何人都会感到自豪吧。
2. 实践经验密集型岗位：
相较于开发，测试需要更多更齐备的实践经验。从正向的系统知识、架构设计，到反向的破坏性思维，无所不包。开发人员通常在理想条件下编程，适时处理一些预想中的异常或错误;而测试则必须确保当这些异常或错误出现时处理代码能正确工作。这种检验工作远比开发工作困难得多。同样的业务代码，开发只需要面对少数“正常执行流”即可，而测试则需要面对大量的“异常执行流”。只有实践经验丰富者才能保持高测试效率。
3. 煎熬的协作关系：
开发向来难以认同测试的重要作用。还记得刚开始做开发时，SQA老是过来挑我的错，搞得我很恼火。但是Boss却说如果项目顺利收尾，我还必须请SQA吃顿饭，要不是他们的努力，说不定还得延期，严重的话甚至会导致用户体验指数下降，损失远远大过面子。幸而SQA组的同事都比较客观（天天看数据想不客观都难），他们是真正看结果不问过程的角色，一切就事论事。这一点，单向思维的开发人员很难企及。
写的代码越多，越认同测试的重要。曾经听过一个很贴切的比喻：写程序的人就像在造没有护栏的桥，自己去走那肯定安全无虞，那怕摸黑也不至于掉河里去;测试则像给桥修护栏的，让桥的普通使用者也能像开发那样来去自如。从这一点上说，测试远比开发重要。
我也想过是不是转任测试，但耐性不够，忍受不了测试那种枯燥，是以非常佩服能在测试上坚持五年十年的人。至于测试的魅力么，能说是“与人斗其乐无穷”吗？嘿嘿。

================================

----- 梁涛 愿做东风，处处解冻

================================

我第一次工作，服从领导的安排，于是进入了软件测试这个行业。
这个行业，呆的越久，就会发现，开发或者上级总认为测试不重要，然后，出现问题后，总会最先找到测试人员，而他们却有不给予测试人员相应的权利，以及对该项目的熟悉度，总是让测试人员慌手慌脚的开展工作。
作为一名测试人员，比开发更加考验自身的耐心。

================================

----- 杜凌峰 缺了运道，拿你来补！

===============================

如果软件测试真的有什么“魅力”的话，应该是下面几项：

1. 更早更频繁的去思考价值问题，包括艰难的人生

2. 享受少数派的乐趣

3. 享受Telling The Hard Truth的乐趣

4. 享受做幕后英雄的乐趣

我相信如果100个人有做选择的自由和能力，告诉他这些“魅力”，99.5个应该不会主动选择去做测试。还有半个有自虐倾向。而那些由于种种原因走上了软件测试道路，并且长期坚持做出成就的人，大多数应该是因为做一行，爱一行，而不是爱一行做一行。
那些告诉你软件测试人员需要什么不同的技能和思维方式，等等等等，都是不靠谱的。好的软件工程师在本质上没有什么不同，只是大家的偏好和选择不同。但是正是由于软件测试的这些“魅力”，导致大多数人更愿意选择其他角色。这就是人性。
-------------------------
做一些思考的尝试，不一定对，与大家切磋。
---------------------------
UP最多的答案有一些干货，但是我认为严重文不对题，也有很多误导，就不一一去驳了。
首先其实我推测题主其实想问的是软件测试区别于其他平行工种的特质。
还是得从问题入手，什么是“软件测试”，怎么定义“魅力”。
--------------魅力分割线-------------
先说“魅力”，简单可以理解成事物吸引人的内在品质。它应该是中性的和稳定的。这些品质之所以吸引人，是在特定的环境和文化背景下造成的。比如女人的魅力，据说唐代女人以丰满唯美，还有所谓“楚王好细腰，宫中多饿死”，魅力是审美的结果，审美是一个文化的东西，人，人类社会是不稳定的。
为什么要说这个。现实中选择做软件测试有多种原因：

1. 偶然 - 刚好有个测试的工作机会，面上了，各方面也不反感，没有更好的选择，或者不知道自己的倾向性

2. 理性 - （注意理性并不代表正确），试举几例

   1. 测试工作比开发对代码能力要求低，对沟通要求高。我代码能力一般，沟通还可以

   2. 现实中测试工作女生多，我是女生，我做测试理所当然

   3. 最近测试职位比较多，竞争不是很激烈

   4. 测试的面试要求低，可以先进自己心仪的公司，然后转开发，曲线救国

上面能不能稍微总结几条软件测试的固有特质呢？我们试试：

1. 测试工作比开发对代码能力要求低 ------ 否。行业的现实情况是测试从业人员的整体代码能力是比开发要低，但是这个是事实而不是理想情况。再者有很多公司对测试人员和开发人员的开发能力要求是一样高的。

2. 测试工作中女生多 ----- 同样是部分公司的事实，但是也有不少例外

3. 测试职位比较多 ----- 这个显然是感觉而已

4. 测试面试要求低 ----- 这个也有很多例外，而且这个理解本身也是错误的

这些所谓属性都不稳定。
再来看看有朋友提出的-------------发现”和“分析”
那么其他的兄弟工种，比如产品，开发，运维，又有那一个不需要发现与分析呢？
那么究竟什么是软件测试工作的相对稳定的内在特质？
首先，我觉得还得从专职软件测试的产生说起。首先，软件行业最初是没有专职的测试人员和测试团队的，这个分工是后来形成的。其次，现在很多互联网创业公司，最初也没有专职测试人员和测试团队。科学管理的先驱者查尔斯·巴贝奇（Charles Babbage，1792—1871）发展了亚当·斯密关于劳动分工的利益的思想，分析了分工能提高劳动生产率的原因。他指出，这些原因是：

1. 节省了学习所需要的时间。生产中包含的工序愈多，则所需要的学习时间愈长。例如一个工人无需从事全部工序而只做其中少数工序或一道工序，就只需要少量的学习时间。

2. 节省了学习中所耗费的材料。因为在学习中都要耗费一定的材料。实行劳动分工后，需要学习的内容减少了，所耗费的材料也相应地减少。

3. 节省了从一道工序转变到另一道工序的耗费的时间。而且，由于分工后经常作某一项作业，肌肉得到了锻炼，就更不易疲劳。

4. 节省了改变工具所耗费的时间。在许多手艺中，工具常常是很精细的，需要作精密的调节。调节这些工具所占的时间相当多，分工后就可以大大节省这些时间。

5. 由于经常重复同一操作，技术熟练，工作速度可以加快。

6. 分工后注意力集中于比较单纯的作业，能改进工具和机器，设计出更精致合用的工具和机器，从而提高劳动生产率。

这个显然是针对体力劳动的，巴贝奇还指出，脑力劳动也同体力劳动一样地可以进行分工。（来自百度百科）类比软件行业的分工，我觉得可以大概总结出类似几点：

1. 节省了学习所需要的时间 - 依然成立

2. 节省了学习中所耗费的材料 - 依然成立

3. 节省了从一道工序转变到另一道工序的耗费的时间 - 减少Context Switch，可以更专注，成立

4. 由于经常重复同一操作，技术熟练，工作速度可以加快 - 成立

5. 分工后注意力集中于比较单纯的作业，能改进工具和机器 - 能改进测试工具和流程

那么在软件测试的专业分工形成以后，究竟什么工作被分了出来？这个回答很简单，就是软件测试的活动？那么软件测试的活动包含哪些？这个就有可能不那么容易形成一致了，在现实场景中每个行业和每个公司可能有差距。我认为软件测试的最终目的和产品、开发、运维等等应该是一致的，就是保证软件产品符合用户的预期，给用户和企业创造价值和利润。在这个工程中，以传统瀑布模型为例，试着比较一下各个工种的分工：

1. 需求提出阶段

   1. 大家都会关注需求的合理性

   2. 开发人员更关注需求的实现方式和代价等

   3. 测试人员关注需求的可测性（不展开可测性，有需要自己查）

   4. ------------------这个阶段我认为对测试人员和开发人员只有技能要求不同，没有本质区别

2. 技术设计阶段

   1. 大家都关注设计本身的正确性，完整性等

   2. 开发人员更关注设计的实现方式、工具、代价

   3. 测试人员还需要关注可测性

   4. ------------------这个阶段我认为对测试人员和开发人员只有技能要求不同，没有本质区别

3. 开发测试阶段

   1. 开发人员构建产品，修改bug

   2. 测试人员构建测试工具，测试用例等素材，执行测试，暴露bug

   3. -------------------这个阶段我认为对测试人员和开发人员只有技能要求不同，没有本质区别

   ================================

   -----Andy Chen 牢裏只有一隻羊

   ================================

关注公众号 (softtest_way) 软测之道