我说的是中国微软工程院的情况，是做EXCHANGE2007的项目组
当然EXCHANGE相对MS其他的产品要简单一些，所以自动化测试可以达到99.9%
我不认为WINDOWS也可以这样搞 但是OFFICE也是可以的
微软工程院，测试是开发工资的两倍？ 原帖由 shanxi 于 2007-7-18 10:40 发表 http://bbs.51testing.com/images/common/back.gif
微软的PM中中国人也相当多，特别是Redmond的中国人不少
多看怎么说了？不可否认中国的PM是有的，从某种角度也可以说不少。可是，占总数的百分比是多少呢？核心项目里的PM又是多少呢？大陆来的有占多少呢？很多是香港，台湾，美国长大的呀。
Redmond中国人是不少，可是PM的比例并不大。Office是否能完全覆盖我不敢说。不过我比较强烈的怀疑。即使zgslhyh讲的北京研究院的例子也不是100%。不过我认识一些office工作的人，我可以打听一下。我想这个完全覆盖也是要看从那个角度去说吧？如果真的完全覆盖了，是不是就代表Office没有bug了？如果还有bug，怎么能证明是完全覆盖呢？我想我们大家都装过office的patch吧？
Windows的Sub Team是什么意思呢？Windows我还是比较熟悉的，绝对没有达到100%覆盖。这个我很自信的说。只是不知道你讲的sub team是什么team。 其实,不管是什么的软件,不管你如何测试,BUG总会有的,你是测试不完全的,世界没有十全十美的东西. 原帖由 mojinde 于 2007-7-18 14:13 发表 http://bbs.51testing.com/images/common/back.gif
其实,不管是什么的软件,不管你如何测试,BUG总会有的,你是测试不完全的,世界没有十全十美的东西.
这个我同意。一般只要东西一绝对就变成错的了，物极必反。比如，100%自动化，完全避免bug等等。 我也并没说Windows是100%覆盖了，只是说从sub的角度讲已经能够达到这个比例。
美国公司核心的都是美国主流人种的人，相比中国人来说印度人总体来说比较高。
另外，原帖的那个人留言了。Explosive Test是微软比较推崇的做法。
[ 本帖最后由 shanxi 于 2007-7-18 14:26 编辑 ] 你说过“Windows的Sub Team也应该实现了完全的覆盖。”，给我的理解就是100%覆盖呀。完全还不等于100%吗？不是100%还算是完全？
还有就是sub的角度到底是什么意思呢，这个我也有点疑惑？
我看了他的留言，那个人也说了，他不代表微软。
我等一会儿回他。
这是作者的回帖
写了这篇文章，惹得有些人很生气，后果很严重。所以再写一些，阐明我的一些观点。首先要说的就是欢迎大家的争论，其次我当然不代表微软的观点J 其实我想微软对我讨论的问题也没有什么官方观点。学术问题本来就是应该各抒己见。我只是想谈谈我个人对自动化的感觉，至于感觉是否科学，大家可以批评。但测试本身就是Art，还不是科学（这话不是我发明的，是书上说的。）有人质疑我的能力和Credibility，首先我做SDET有六年了，之所以写这篇文章就是想总结一下有效测试的经验。反思一下为什么近三年自动化做得少了，反而工作成效大了。另外，我的工作涉及网络安全认证与授权，是公认相当复杂的项目。为什么我们可以较少的人力比较出色地完成项目。所谓出色，我认为我们做到了PM和Dev的双满意。
测试人员和PM, Dev的关系。
测试人员最直接的打交道的人是PM和Dev。相对而言，测试人员较少和客户直接打交道。当然，PM满意应该和客户满意是一致的。PM和Dev关心测试自动化吗。No！PM 最关心是进度，其次是质量。Dev有几类，有一类最高兴的就是测试的人别找他们麻烦，当然测试人员的工作就是找他们的麻烦。还有一类比较通情理，知道测试人员是在帮助他们把工作做好。当然，bug找得少，产品在用户出问题，Dev会觉得测试人员的工作不够。所以Dev首先讨厌测试人员做无用功，效率不高。其次，Dev最讨厌的就是测试人员乱挑毛病。就像针灸一样，如果扎得不是地方，只会惹人烦。如果一针扎到病灶，Dev会很满意。所以Dev关心的并不是测试人员否是搞了自动化，只要能找到问题。黑猫白猫，抓到耗子就是好猫。
什么是自动化
我定义的自动化是指较大的框架。举例说，如果你要测一个API，这个API的其中一个参数是C# String，如果有必要测很多不同的Unicode值，当然写个程序测最快，最可靠。另外Stree/Performance测试都要写程序。我觉得这个不叫自动化，这是SDET的基本功。我也反对没有必要的自动化。比如，有些测试要检验Event Log的内容，有些人把.NET中读Event Log的库函数再打包写个自动化库，认为这样把原来需要五行完成的动作一行完成很酷。其实，你想想自动化库带来的维护问题比解决的问题还多。本来，.NET的文档很清楚，你的自动化库文档又不全，出了问题还得找源程序，还得有人改自动化库。麻烦不知道是少了还是多了。另外，我所说的手工测试包括写测试程序，但测试程序侧重的不是自动化，而是探索测试Exploratory Test.
自动化在测试中的地位下降
另外我观察自动化在测试中的地位下降。测试人员的大忌就是在测试开始把自动化作为首要目标。一般来讲，过去我们把测试自动化作为目标之一，总是想完成手工测试后，在有时间要做自动化。可是实际情况是，项目进度太快，根本没有时间做自动化。一般手工测试完成后，产品就发布了。
测什么不测什么
和PM讨价还价不是偷工减料。一般讲，在项目开始阶段，测试人员的发言权最低。很多东西测试人员是没法控制的。PM总想多加功能，即使现在没用，想着将来会有用。有的项目，Dev有很大的支配权，Dev可以加入很多他喜欢的东西。（很吃惊吗，现实就是这样）。测试人员只有在测试阶段讨价还价的份儿。
有人认为我说“软件的特点是如果一次做对了，以后永远不会出错。”很荒谬。我承认有点极端。我的意思是，你在测试时肯定要假设有些东西是对的，不用测的。比如.NET的库。测试完成了投入使用了一段时间后，就可以假定当前的软件基本符合要求，不需要进一步测试了。必须学会画一条测与不测的线，否则测试会无休无止。我们大多数人接受的项目肯定是前人基础之上的项目，新的版本出来了，我们肯定要假定没有变动的，没有涉及程序不会出错，重点测试变动的部分，分析可能会涉及的部分。具体讲可以用Beyond Compare比较程序的变化。
当然，这个假定在一定程度上是错的。前人做得程序可能会出错，.NET库函数也有错，如果不在当前测试人员的工作范围，这种错误是可以接受的。如果你能找出前人的错误，发现.NET库函数的错，说明你确实出色。但从往往时间上讲，你能做到这步的机会有限。当然，我发现的最得意的bug就是在产品中隐藏了五年之久，我讲出来都替微软丢人的安全漏洞。我发现这个bug就是读程序偶然读出来的。读的时候，脑子里多打了几个问号，然后动手一测，果然如我所料。
WhiteBox Test + Exploratory Test
我的测试哲学是WhiteBox + Exploratory Test。测试开始阶段要读懂要求，理解设计。然后是读懂程序，在程序中找问题。这就是WhiteBox Test。然后动手写一些测试程序，测试程序的原则一定要简单灵活但自动化程度不高。测试程序的主要目的是探索，手工探索，目测探索软件那里会出错。之所以要做探索测试，就是因为自动化要求对输入输出都要很准确的定义。输入好控制，可是没有探索测试，很难准确知道输出是否正确。自动化必须建立在探索测试的基础之上。就像用一只单发的步枪，一发一发精确打击敌人防御的弱点，不是用机关枪盲目扫射。单发的好处是，每打一枪你都要目测效果，然后调整子弹大小，射击的远近。如果像机关枪打出一百多发子弹，你会视觉疲劳，无所适从。自动化就像一只机关枪。
我的观点只是一家经验之谈，不是理论，大家可以借鉴，不要照搬。
关于，美国软件业大公司的人工成本是公开的，新闻里可以查到，平均大概是十一到十五万，当然包括各种福利，和管理成本。
这是我的回复
我也并没有什么生气，最近根据一些微软的员工写出的文章，感觉到对普通的测试人员产生了比较大的误导作用。因为是微软的员工，使得大家看文章的时候误认为代表了微软的测试观点，从而把一些个人的经验当成了微软的真理来看待。这种误导作用我个人认为不是很妥当的，因此我也想说点什么，提醒大家不要全盘吸收。我想如果我们把范
围缩小到只是个人的观点，我可能不会花时间来讨论这些问题。因此，你的这篇文章我认为跟以前的相比有了很大的改善，可能以前由于没有表达全面产生的误解，这里也作
出了很详细的解释。而且，我也很欣赏你对于技术讨论的态度。因此，这里还是有些问题想向你请教或探讨。
1。因为您在微软已经做了六年的SDET，能不能介绍一下你这六年在微软的发展轨迹呢？还有就是今后计划如何的发展，SDET在微软发展到最后又会是什么样子呢？
2。关于测试人员和PM，Dev的关系部分：我想你说的不错。可是，测试人员最直接打交道的难道仅仅是PM和Dev吗？我不知道你有没有team lead，有没有manager？team
lead, manager关心什么呢？难道你的team lead，manager不关心自动化测试吗？我不清楚你到底是在做什么项目，难道你不了解自动化在Windows，Office都非常重要吗？
Windows每天都要出一个，甚至几个build，没有自动化，怎么能完成测试任务呢？
3。关于什么是自动化部分：首先你自己定义了自动化的含义，那就是较大框架的自动化。这和大家普遍理解的自动化就有了一定的歧异。当然我们这里可以姑且就按照你的
定义来讨论。你说的自动化在测试中的地位下降有没有什么具体的根据呢？比如在微软，是不是Office，Windows越来越少的进行自动化了？据我所知，他们对自动化的要求
是越来越高。这里，我感觉好像是自动化只是在你的心中地位下降了。你说的测试人员的大忌，我同意。可是，不把自动化作为首要目标就推出来不要自动化，是不是就太牵
强了？难道我不可以把自动化作为次要目标，第三目标，甚至不作为目标，只是作为实现目标的一个方式？还有就是，有没有时间做自动化还是要看测试人员水平的。比如说
，不久前，有人说要3个月实现的自动化，我花了一个月就实现了。再比如说，windows的周期一般至少两年，后来的维护工作至少五年，难道我们没有时间做自动化？还有就
是一般手工测试完成以后，产品就发布了。这个观点从何而来？难道Windows，office发布的时候没有做自动化？
4。关于测什么不测什么。你说设计阶段测试人员没有发言权，可能符合大多数的情况。可是对于技术背景非常强的测试人员是有足够的能力在这个阶段监督PM的工作的。不
知道你是否知道PM的spec需要测试人员review和sign off的。也就是说测试人员在产品的流程中，这个阶段是有权利监督的，并且判定spec是否合格。这个阶段当然可以讨价
还价了。你甚至可以指出某个feature,由于不能进行很好的测试，把它cut掉。spec中有什么没有什么，不是PM一个人说了算的。是要经过大家的review的，不合理的东西肯
定不应该存在进去。而且，他的老板在这方面也会进行监督的。我知道大多数测试人员没有水平在这个阶段去跟PM协商，可是资深测试人员是需要有这个能力的。
5。关于WhiteBox Test+Explorator Test: 请问没有自动化，你怎么实现在各种不同操作系统，不同cpu上，不同的Windows版本上,不同的SP进行测试呢？比如，操作系统，
Windows2000， XP，2003，Vista，2008， CPU，x86, amd64, IA64, 版本，Ultimate, Home Premium, Home Basic, Enterprise, Business, Starter, SP, XP SP1, SP2,
2003 SP1, SP2, 等等。难道你要每种组合都手工跑一遍？还有就是不知道你的产品多长时间出一个build，如果一天一个，你每天都要在不同的环境下跑一遍？
以上疑惑，还望得到你的解答。 这个作者很黑呀。在CSDN上删除了我的留言。
算了，这种人我也不跟他讨论什么了。
大家别受误导就可以了。 代码覆盖率没有100%
EXCHANGE 自动化测试用例的代码覆盖率每个模块都在85%以上，有的比较好的可以达到98%，整体大约90%
至于功能覆盖率。。。这个数据好象没什么用吧。。。猜想MS应该是100%的
据我所知SETUPUNINSTALL配置域 都能自动化 还有什么不能呢。。。
99.9%我是指 自动化用例占总用例数99.9%
[ 本帖最后由 zgslhyh 于 2007-7-19 09:33 编辑 ] 原帖由 zgslhyh 于 2007-7-19 09:28 发表 http://bbs.51testing.com/images/common/back.gif
代码覆盖率没有100%
EXCHANGE 自动化测试用例的代码覆盖率每个模块都在85%以上，有的比较好的可以达到98%，整体大约90%
至于功能覆盖率。。。这个数据好象没什么用吧。。。猜想MS应该是100%的
据我所知 ...
UI软件的代码覆盖率整体达到90%并不是很困难的一件事情。代码覆盖最容易的就是测试UI程序了。你说的数据是可信，也是合理的。
理论上来讲，可能任何东西都可以自动化。能自动化不代表一定要自动化。正像这个文章的作者极力反对自动化一样，你是极力的夸大自动化。我个人认为你们都走了极端。我们应该理性地看待自动化。自动化不是万能的，自动化也不是bullshit,什么应该自动化，什么不应该自动化，应该如何自动化，里边都是有学问的。你所追求的90%的代码覆盖率，99.9%的自动化，正好是典型的文章作者所阐述的“迷信自动化”。我认为，作者的这篇文章正好适合你对自动化的这种看法。不知道你有没有仔细看作者的文章？ 手工的优势在哪呢？省钱省事嘛
自动化都能了 想手工测测我还不能了吗？ 工具也是人手写的
追求是追求实际是实际何为迷信 虽然我写了长篇来反对文章的作者。其实我主要反对的是作者拿自动化当作bullshit。
关于你提到的几个问题，好好看看这个作者的原文，里面都有很好的解释。
我不知道你自动化经验有多少，我可以稍微给你解释一下。
手工测试和自动化测试各有优缺点。根据不同的情况，我们应该合理的选择测试的方法。有些bug一眼就可以看出来，你要是非得编程序自动化那可麻烦大了。比如，你要是验证一个软件的所有text是否正确，所有帮助文件是否正确。你手工一会儿就测完了，自动化你要开发多长时间呢？
自动化都能了，想手工我还不能吗？这个思想也大错而特错了。比如，你要在word里面输入几十万的字符，如果编个程序，很快就实现了。如果你手工，不得把你累死？
总而言之，做测试一定不要教条。灵活掌握和运用才能成为资深。
看到了一些高手对这篇文章的回答，感觉比较长见识，大家有兴趣也看看。
13 楼：omomo看起来这个帖子里,楼主是微软的
peking2torento是前微软的, 目前在Google. 呵呵.
楼主,你公布内部网站的内容,请小心!这是Standard business contact不允许做的. 我觉得你应该删掉那部分引用和内部链接. 以避免给你自己带来麻烦
我读了peking2torento的反驳,觉得多数是在理的,可能语言有些激烈. 在楼主的后一篇回复中,于是变得讨论的理性些. 这个标题之下其实可以做很多理性的讨论,只是楼主的第一帖,为了证明这个标题,说的有些言过其实了.
楼主上面又说了.有个新来的,写了个自动化测试,但是没有找到那个bug. 还是回到我之前的看法,我认为测试人员的素质,我把深刻理解产品和产品的目标用户为第一,自动化为第二. 那个新人是因为没有做好第一条,所以自然工作做不好. 但这不能抹杀自动化的意思. 如果要我来说,那是test lead培养新人的失败. 我认为正确的ramp up策略是 让新人先手工测试,读spec,读dev design和尽可能的玩他要测得产品. 这样搞几个月以后,再叫他开始做自动化测试,如果按照这个顺序,我想新人的成长就会不错了. 这不是自动化测试的错. 不要把项目中的失误总是归结到自动化测试浪费了你们的时间. 说到底那是你们自己分析的问题. 不经过分析就执行的自动化策略,我也反对.
发表时间：2007-07-20 16:40:17 14 楼：omomo
我希望当测试人员来试图说服大家做一个自动化测试方案都要明确地告诉我收益/付出的比例有多大. (ROI)
能力不同的测试人员,分析出来的ROI基本上就可以看出他的水平了.有些人我听听他的分析,就知道这事情有没有谱.也可以看出他的技术水平到底怎么样.当然这也要求我们自己与时俱进,不断地追求技术进步.
做自动化测试计划,我们无非就是在quality/schedule/ROI中间平衡.
发表时间：2007-07-20 18:13:32 15 楼：papercrane
抄抄底，挑挑刺，原文就不贴了，说说个人见解而已：
有些做测试的人因为不正确的动因去做自动化，不能推断出做自动化的测试人员都有不正确的动因，哪怕这个比例是1-1.0e-100。很多人献血是为了卖钱，但不能说献血者都是不崇高的。这个立论会导致以偏概全。
后来接手项目的人喜欢重来，不管在测试还是开发领域都是普遍存在的“坏”现象，如果因此否定测试自动化的作用，估计大量的development framework也都难逃一劫了。
找bug只是测试工作的其中一个任务，哪怕再重要（当然是很重要），也不是唯一的令产品开发失败的风险。请注意“唯一”和“风险”：风险就是，搞不定就完蛋，不管其它方面做得多好，所以就是要做好！唯一就是，只弄好就行，其他别管。好了，解决了找bug的风险，其他的风险呢？如果有项目因为过于着重其他风险而没有处理好找bug的风险，似乎是时间管理或者风险管理没有搞好的原因居多喔。
分析变动影响（impact factor）也是需要代价的，从纯粹代码分析到纯粹回归测试之间，显然是有机可乘的。代码分析随代码覆盖量增长区分效果急剧下降；回归测试随代码覆盖量增长执行时间延长。那么作初步代码分析，定出范围后自动化回归测试，结果如何？
开发过程和工具都针对Agile Development做了大量改进和适应，自动化测试的实践跟不上是自动化测试的错呢？还是不思进取的错？从管理、设计到工具，开发人员不断降低行为粒度；自动化测试是天生就不能这么做还是没想到可以这样做呢？
找到很多的bug和找到难以重现的bug，使用的方法是不一样的。重负荷下处理特定序列的bug，race condition，dead lock，很多时只有依赖自动化才能容易重现。产品发布以后暴露的问题，很多也属于这一类。自动化测试除了发现这些bug，还能高效的确认修复是否成功。否则想象一下，修复之前折腾一次，修复之后又折腾一次，每次regression折腾两次......
功能设计freeze了才说有些功能不测？计划阶段和设计阶段复核的时候测试人员不参加的吗？早就应该跳起来啦。Test is the guard of the product！
发表时间：2007-07-20 19:52:11 16 楼：goldcattle
我觉得楼主的观点有点以偏概全。
自动化测试的目的一般有几个：
1、防止regression.
2、替代简单而重复的手工测试。
3、手工测试无法做到的测试。
如果你的项目有这样的需求，那么自动化测试是必要的。当然到底才用不采用自动化测试，自动化到什么程度和项目的预算和时间相关。
楼主主要在的测试是在“涉及网络安全认证与授权，是公认相当复杂的项目”
我想如果楼主接触的是嵌入式底层开发或者直接和电路打交道的话，那么楼主可能大声说，自动化测试根本是不必要的。
对于微软来说，很多组是提供一些二次开发的平台。这些平台往往会提供一堆API。这些API肯能会内部使用也可能会外部使用。有的team最后的产品就是一堆API和binary。这些东西根本没办法手工测试。这些项目组的测试压力是相当大的。他们必须要理解每个API究竟是干什么的，才能设计出好的case。然后还有设计一些黑盒的例子去测这些case.
对于有UI的产品来说，楼主很大程度上忽略了回归测试。
从接触到大的项目而言，很多人成百上千个人在开发一个产品。每个team可能会依赖好多个team。如果某个team新加的代码影响到你依赖的一个模块。如过没有回归测试来保证，我想测试team 根本没有时间来做ADhoc testing。
你用Adhoc 发现了一堆错误，不能把功劳完全归功于Adhoc testing。你应该看到，是因为有自动化测试在保证着产品的区ality让测试人员在防止regression bug的战斗的解放出来。
不能吃到第九个馒头饱了，就说前面8个馒头是没有用的。
本回复于：
2007-07-20 19:53:20 被【goldcattle】修改
发表时间：2007-07-20 23:22:57 17 楼：Skyfire1201
看了这篇文章以及回复之后深有感触，觉得真是不能用片面的例子否决全部。读过离散数学的人都知道，如果A是B的子集，而A是错误的，这并不能表明B全部是错误的。楼主根据自己对一种自动化测试失败的经历就否认了所有的自动化测试，而推理出“自动化测试无用”的理论，正是犯了基于一点否定全部的错误。其实自动化测试分很多种，有为了防止regression做的功能性自动化测试，有压力自动化测试，有为本地化做的自动化测试，更有exploratory自动化测试。就算automated regression在某些产品上作用不大（比方说生命周期只有1-2年甚至几个月的游戏），不能因此就否定所有的自动化测试。
发表时间：2007-07-22 18:00:04 18 楼：papercrane
关于API测试:
上次去总部出差遇到一老员工在庆祝二十年微软生涯。问及其经历，答曰基本上是测试两个Windows API；再问test case数量，答曰三千左右；最后问执行耗时，答曰全部平台的组合约需两天，幸好win98已不支持，否则无法按时完成。翻看其blog，原来是timer相关的API。归来后对三千之数不得要领，苦思冥想之下释然，此事牵涉甚广：
- 内核重入
- 与Windows Message Pump交互
- 与debugger交互
- 与Windows Time service交互
- 时间/时区变动
- 以往版本的regression 楼上有人说从开发转到测试的人员很少，能力差的除外。我对这点很不赞同，一个良好的测试人员可以没有做过开发，那他要的是敏锐的直觉。如果他做过开发，则更有利于他对整个系统的把握。再着，测试往往看全局，而开发可能专注于一点。所以从职业的发展来看，也是先开发，后测试的，再管理，然后咨询的。 原帖由 yt1985cncn 于 2007-7-23 21:46 发表 http://bbs.51testing.com/images/common/back.gif
楼上有人说从开发转到测试的人员很少，能力差的除外。我对这点很不赞同，一个良好的测试人员可以没有做过开发，那他要的是敏锐的直觉。如果他做过开发，则更有利于他对整个系统的把握。再着，测试往往看全局，而 ...
你去大公司看一下，大部分做测试的是因为面试开发没有成功才去做的。包括这篇文章的作者。
很多人本来是应该做开发的，要放到测试锻炼一两年，再转回去。做了测试再去开发更能保证coding的质量。
开发的路可以发展很久，测试则不同，很快就发展到头了，发展到头还是得转开发，或者管理。可是，管理毕竟是少数人才能做的。因此大部分如果想往上发展还是要转开发。
当然我说的是测试发展到头，很多人还不是很明白测试怎样算发展到头，也有很多人根本就发展不到头。
还有就是我说的是目前的情况，不代表以后也这样，而且我说的是大公司的情况，国外的情况，不代表国内，国外小公司的情况。
个人来讲，我觉得测试发展两年多就到头了，不能说完全到头吧，但是工作基本上就是重复了，不能学到什么新东西了。不只我自己，连我的几个老板都让我在开发上下功夫。（对我在测试上已经没什么要求了） 对了，我自己也是无奈才开始做测试的。要不是年纪大，我早就转开发去了。
另外，我做测试将近两年的时间都十分的郁闷。一直想要脱离这种状态。现在其实已经不是纯测试了，可以说一半测试，一半开发。而且我的工作跟纯的开发是非常接近的。可以这样说，我们这里的测试要懂很多开发知识，比一般公司的开发人员水平还高。现在自己觉得转去开发还没有ready，各种原因吧。如果以后学习了很多开发知识以后，现在的工作用不到多少，那也很有可能去搞开发了。幸好这里的测试可做的东西很多，要是一般的公司，非得把我郁闷坏了。还有就是要是跳槽的话，很可能就直接申请开发职位了，因为其他公司很少有这种测试职位的。 我想cleverman的意思不是说测试做到多少岁就做不下去了，而是指你能力达到一定程度，测试这个行业已经没有和你能力非常match的职位了，再想往上提升只能去开发这个范围找合适的位置，绝大多数测试工程师不要担心这个问题，因为很多人能力可能也达不到这个程度， cleverman都在google美国总部当上了team leader， 年薪10W美元＋，还要再过一段时间再转开发，咱们还没到担心这个的时候，而且即使真的能达到cleverman那个位置，有了哪种能力 转开发也是非常简单的事情！
从开发转测试，并不都是应为能力差！
cleverman，你好！你的高见：“可是总的来说，测试的地位还是比不上开发。这也是为什么有人从测试转到开发（而且是很多人），没人从开发转到测试（能力差者除外）。”
难道从开发转到测试，就是因为能力差么？我认为有点偏颇，呵呵~
从开发转测试，和个人的兴趣也是有关系的！
[ 本帖最后由 dypku 于 2008-4-24 11:50 编辑 ] 我这句话是指的在微软吧?
如果要是从整个情况来说,不是某个公司的话,当然不是这么绝对.
关于兴趣,这个可值得讨论,我感觉很多人从开发转到测试是拿兴趣作为一个借口,或者说作为自己安慰自己的一个理由.
当然我不排除有些人是真的不喜欢开发而喜欢测试.可是一般能力强的人还是觉得在开发上更能体现自己的价值.我觉得真的能力很强的人是很罕见去转测试的.当然有些因为钱,或者晋升的因素,我指得是纯技术.至少我是没见过.
