今天查了一下开发与测试的工资水平，一些数据应该能说明一些问题。我们以硅谷的Mountain View为代表（Google总部所在地）。

开发：

Junior Software Engineer: $62K

Software Engineer: $98K

Senior Software Engineer: $110K

Principal Software Engineer: $110K

Lead Software Engineer: $113K

测试：

Junior QA Analyst: $53K

Junior QA Engineer: $61K

QA Test Engineer: $76K

Software QA Engineer: $86K

QA Team Lead: $88K

Senior Software QA Engineer: $93K

SQAE Manager: $100K

Junior SDET: $95K

Software Development Enginner in Test: $102K

Senior SDET: $108K

Lead SDET: $108K

可见，SDET是测试工资最高的职位了，比一般的Software Engineer还高一些。不过到了Senior就比开发低一些了，而且根本没有Principle的职位。即使SDET Lead工资也没有高出去。能够跟开发的工资水平相提并论的测试职位就是SDET了。

最近总是有一些网友问我一个问题“现在有机会转开发，应不应该转?”。我想我也需要单独发表一篇文章来表达一下自己的看法了。我会从一个新入行的测试人员一直往上发展大概会是一个怎样的情况入手，来表达我的观点“开发技术是测试人员发展的基础，也是测试人员发展的归宿”。当然了，我现在表达的是测试人员一直往上发展，如果你已经对自己的发展感到很满意了，则不在这里的讨论范畴。（相信会有不少这样的人来提出自己的疑义）

从你刚入行开始，你面前基本上是有两条路可以发展。一是技术，二是管理。先说管理，很多人做了很短的时间就走向了管理，team lead，甚至manager。他们的工作已经很少用到技术了，更多的是学习和运用管理的知识。这样的人不在少数，我当时做测试3个月一转正就是team lead了，老板也非常希望我专注在管理方面。可是下一步怎么办？一般出现这种情况的都是在中小公司，而不是大而正规的外企．下一步你的发展会由于技术不够扎实而出现了瓶颈．第一，你不可能回头去搞技术了，因为你管理的地位，工资都高于技术人员，而且还有年龄的问题，这些因素造成了你只能继续管理。第二，如果你想跳槽到大的外企搞管理，可能性几乎为零，因为你没有大外企的经验又没有出众的技术。第三，如果你想在本公司或类似公司往上爬，比如做director,很可惜，这些公司往往不配备test director的职位，并且其他director的职位也很难由一个做测试的人来承担。（可能会有特例，但是应该很少）。因此，刚入行不久，没有扎实的技术沉淀，就走向了管理，很快就会发展到头了。

再说技术，我们知道测试的最高title就是SDET和SET了。实际上都是一个东西，微软叫SDET,Google叫SET。说白了，这种职位本质上就是开发，只不过不是产品的开发，而是测试的开发。需要很强的开发背景。因此，一个普通测试人员想要得到这种工作机会，开发的经验是必不可少的。另外，微软，Google这种最top的公司，基本上已经没有STE, SQAE这种职位了。而我们大多数人做的测试工作恰好正是这种职位。顶尖大公司的这种职位都外包了。因此，你想通过普通的STE, SQAE这种职位进入顶尖公司，可能性基本为零。因此，如果从技术上来讲发展，无论从title上还是公司上往往上走，开发的功夫都是必须的。

因为我说的是一直往上发展，因此到了SDET后怎么发展？基本上三条路，第一管理，第二开发，第三继续测试。先说管理，你从技术上一路走过来再走向管理跟前面讲到的那种管理是天壤之别了。首先，你已经是在顶尖公司了，其次，你已经具备了高深的技术水准了。放眼望去，整个测试行业还能有几个适合你的位子呢？还能有多少人能跟你相提并论呢？这条路可以lead->manager->director->vp->senior vp往上发展。那么发展到了最后还怎么发展呢？这个时候，我估计应该年纪很大了吧？钱很多了吧？享受生活吧。

再说转开发，因为SDET具备了比较强的开发水平（比一般公司的开发人员的水平要高），因此可以比较容易的转向开发。转向开发之后就属于开发的发展之路了，就不多说了。

最后说继续测试，一直以来都有个疑惑，为什么我从来没见过senior SDET？本来SDET可以向senior, principle这条路走下去。我以前也想过自己发展成test architect。可是，为什么没见过？依我现在的感觉来说，测试的技术很快就学到头了，开发的技术由于一直是在做测试程序，而不是真正的产品，因此提高的程度也受到了很大的限制。因此，在技术上来讲，一直工作下去就会维持在一种不是很高技术水平的状态。这种状态达不到senior的要求。这也是为什么周围很多SDET不知道工作了多少年，还是SDET。目前来看，想发展的话，维持在SDET不算现实。必须走向管理，或者转向开发了。这也是为什么director在回答我的问题“我在测试方面应该怎么发展？”。回答竟然是“短期来看要学好Ｃ，长期来看还是Ｃ，转向开发”。根本就没有提到测试。

以上是我自己的分析与理解。

大概几个发展路径

1.QA->management

2.QA->SDET->management

3.QA->SDET->Dev

当然还有其他的可能，比如

4.Dev->QA......

5.QA->Dev......

6.QA->Dev->SDET......

7.Dev->SDET......

8.SDET......

我想大家可以分析一下自己以前的发展之路，看看以后应该如何发展？当然了，如果自己已经满意了就算了。我的发展之路是这样的

Dev->QA->Management->SDET->(Lead/Dev/Senior if possible)

总而言之，在整个的发展路径中，如果你缺少Dev,都会限制你更好的往上发展。还有就是发展的高低，一要看title,二要看公司。很多小公司的manager可能根本都进不了大公司。很多大公司的普通员工一旦跳槽到小公司很容易就能升职。比如一个朋友在国内做了６年的外包经理，面试大公司总是失败，因为技术不行。还有朋友在顶尖公司只是SDET,跳到盛大就是director.

这里我想破除很多测试人员的一个幻想，我强调的一点是“不懂开发的测试没有太大的前途”。

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 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

发表时间：2007-07-23 13:44:18 19 楼：waterine

计算机科学的根本目的就是从简单到复杂，从具体到抽象地将事务处理过程自动化。软件测试涉及大量类似/重复劳动，正是自动化需求最大的行业之一。楼主所说的种种缺点，其根本原因还是技术所限。如果技术进步，这一切都能够很好的实现，没有人会拒绝自动化测试。而技术的进步正是靠SDET写自动化测试的过程中一点一点推动的。这也是SDET的工作职责之一。

写了这篇文章，惹得有些人很生气，后果很严重。所以再写一些，阐明我的一些观点。首先要说的就是欢迎大家的争论，其次我当然不代表微软的观点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，如果一天一个，你每天都要在不同的环境下跑一遍？

以上疑惑，还望得到你的解答。

第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug.  懂程序的人每个test case都可能发现一个或多个bug.  我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解，即使release后出了问题，也能很快理解问题出在什么地方，是否是bug.

[comments]读程序也算是测试人员的一个基本技能了．可是没有任何理由说读程序就能代替自动化测试呀．我承认读程序是一个非常好的测试方法，可是我们更需要其他好的方法来对软件进行全面的测试．自动化测试难道不是其中一种吗？通过一种测试方法来贬低另外一种，不是很客观和有意义．

第二，测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序，20%写测试程序，50%写Test Cases和运行Test Cases. 好的测试员的工作重点应该放在理解要求，理解客户需要，思考在什么条件下程序会出错，而不是思考如何去自动化。如果时间都放在设计自动化上了，必然会影响测试，分散测试资源。测试人员应该边读程序边测试，读程序帮助找到好的Test Case，测试帮助验证理解和猜测。

[comments]我们今天的主题本来是在讨论自动化测试方面,你现在却跳到了白盒测试方面。我想白盒测试可以单独作为一个ｔｏｐｉｃ来讨论。还是那句话，用一种测试方法来贬低另外一种，没有意义，也没有说服性。毕竟大家搞自动化大多数都是从黑盒测试的角度出发的。

第三，测试人员要学会讨价还价。很多时候项目经理，开发人员搞得东西不是客户马上需要的，或许是永远用不到的。测试人员可以和项目经理研究先测什么，后测什么，那些不测。比如，我做的一个项目，我发现30%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。

[comments]这不是偷工减料吗？用户不用为什么还要设计呢，还要实现呢？你应该在设计阶段就进行质疑。对用户的需求方面是项目经理的责任。你的目的是监督项目经理的工作。如果你认为这些东西没用，应该在设计阶段就ｃｕｔ掉。而不是等到测试阶段才发现，并且不进行测试。你现在没有节约成本，你浪费了很多ｐｍ和ｄｅｖ的时间，加大了他们的成本开销。你现在是拿ＰＭ的错误来跟他们讨价还价，他们也没办法。但是，作为一个优秀得测试人员，最好的办法还是应该在设计阶段发现这些问题。还有就是，既然已经实现了，如果你不进行测试，里边的风险是很大的，是绝对的不应该的。这里我不想多讲，因为道理还是很简单的。如果有人不明白我再解释？

第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。
总之，少做自动化，多写小工具，读懂程序，是高效省钱的测试方法，除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架，告诉他"That is bullshit".

[comments]不想多说了，自己自动化不行，别说脏话。你要是参与了设计，怎么还出现了第三里面的问题呢？

最后想说的是，这个作者的观点绝对不代表着微软的观点。作为前辈传授经验是好事，不过千万不要误导。作为晚辈学习前辈的经验也不要全盘接受，要学会思考，有自己的理解和ｉｄｅａ。

第一，不要指望自动化能帮你找bug. 软件bug和生物的bug很像，测试的规律是bug少的地方bug越少，bug多地方越找越多。做测试自动化，往往在开发自动化的时候，该发现的bug就发现了。自动化开发完成，再想发现更多bug就很难了。这是无论你怎样跑你的自动化，也不会发现新的bug.

[comments]我承认大部分的ｂｕｇ都是通过手工测试来找到的，我也相信很少会有人把找ｂｕｇ完全依赖于自动化。可是，你也提到了，在开发自动化的过程中，该发现的ｂｕｇ就发现了。这也就是说，如果没有开发自动化，这些ｂｕｇ还未必能被发现。这里边的意思就是，自动化开发完了，可能找不到什么ｂｕｇ，可是在开发过程中还是对找ｂｕｇ做出了贡献。我们总是说要注重过程，因此从过程来说，自动化对找ｂｕｇ还是有它的必要性．对于作者后面的问题，我得先说说什么是自动化测试的目的了（在找ｂｕｇ方面）．我们知道，很多模块是要跟其他模块来合作工作的，即使你自己的模块没有任何变动，也有可能因为其他模块的变动被ｆａｉｌ掉。比如最近的Ｎｏｒｔｏｎ的问题。Ｗｉｎｄｏｗｓ的ｕｐｄａｔｅ引致了Ｎｏｒｔｏｎ的误报。因此，自动化测试的非常重要的一个目的就是保证没有ｒｅｇｒｅｓｓｉｏｎ的问题。也就是说，我们不指望ａｕｔｏｍａｔｉｏｎ找到新的ｂｕｇ，可是以前能够ｗｏｒｋ的一定要保证继续ｗｏｒｋ。我工作过不少公司，很多产品都是一天一个ｂｕｉｌｄ，请问没有ａｕｔｏｍａｔｉｏｎ的话，你怎么能够手工的运行一遍你的ｃａｓｅ呢？而且，每天运行一遍的话，你烦不烦呢？

还有就是，作者说的不会发现新的ｂｕｇ还是太绝对了。我的自动化可是发现了不少新ｂｕｇ呢。有的是因为开发人员改动代码造成的，有的是因为其他ｔｅａｍ的模块发生变动造成的。有的是测试工具本身的ｂｕｇ造成的。总之这种各样，并且每种问题，我都是要报ｂｕｇ的。最后，无论对自己的ｔｅａｍ还是其他的ｔｅａｍ都做出了自动化测试的贡献。

第二，不要指望自动化对Regression Test的测试的贡献。软件的特点是如果一次做对了，以后永远不会出错。当程序出现变动时，只要针对变动的部分测试就可以了，以前测过的东西，如果和变动没有关联就不会出错。相反如果，程序出现很大变化，自动化可能完全不能用了。

[comments]我想这种观点也不需要我反驳了吧？任何有个有一定测试经验的人很难说出这种话来。这里边每一句话都是错的，如果有人提出不明白，我再来解释。这里我假设大家都清楚怎么回事。

第三，自动化不如测试工具加手工测试。我不建议测试人员作全面自动化，相反我建议测试人员多做小巧灵活的测试工具。自动化往往需要自动判Pass或Fail.  想想你如果测试用于生成www.microsoft.com的页面的产品，你如何判断页面框架生成的正确？很多东西是动态产生的，你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面，用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug.

[comments]又一次以一个例子引申到整体自动化。可能你的这个例子没有什么问题，可是根据这个例子，我实在不能得出自动化不如测试工具加手工测试的结论。还有就是多做小巧灵活的测试工具？这个最好能具体谈谈。什么是多做？什么是小巧？什么是灵活？作者从一个自动化工程师发展到现在用肉眼来测网页，还拿着１２万美金的年薪，我实在是怀疑作者的测试发展轨迹了。这个工资应该是很ｓｅｎｉｏｒ的了，怎么还在肉眼测网页呢？这种工作在ｇｏｏｇｌｅ是最低级的。都是合同工来做，根本不可能那么高人工。

第四，软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短，一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易，成本越来越低。可是当一个项目死掉了，自动化还有什么用。而且最新的敏捷开发，软件的要求，程序，接口，界面在不断变化，自动化怎么可能跟得上变化。与其去搞自动化，不如多理解变化，直接测试变化的东西。

[comments]又一次从网络应用的生命周期短，引申到了整个的软件项目。ｗｉｎｄｏｗｓ存活多少年了？Ｏｆｆｉｃｅ多少年了？有没有死掉？就算是网络应用，Ｇｏｏｇｌｅ　Ｓｅａｒｃｈ多少年了？有没有死掉？Ｇｏｏｇｌｅ的界面这么多年变化也不大吧？可能你做了一些项目很快死掉，但是不能代表整个的软件行业。软件的要求，程序，接口，界面在不断变化？我真怀疑当初是怎么设计的？如果这样的话，你手工也没法测。这个问题好像不是自动化测试的问题，而是产品设计的问题吧？ 

[comments]在进行第二部分的时候，我想简单说一个问题。以我个人的看法，功能测试根据被测试对象主要可以分三种类型：UI测试，Command line测试和API测试。我认为后两部分是非常适合用自动化来作为主要方法进行测试的。作者只是提到了UI自动化，然后就推广到整个的自动化。我认为这不是很reasonable的。如果谁要是认为API和command line的测试不适合自动化，我们可以单独讨论。不过这里，我们就要把topic nail down了。我们只谈UI的自动化。如果我们要谈整个的自动化，作者的观点一下子就错了，没必要继续谈下去了。

我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。

[comments] 作者在自动化过程中发现的问题，和犯下的错误是初学自动化的人很容易出现的。刚开始的时候，很多人都想把自己的自动化做的多么fancy,想100%的automation.把目标定得很高，结果又相差很大。因此，就动摇了自动化的信心。我做自动化总是强调的一点是，“怎样合理的进行自动化？”。什么应该自动化，什么不应该自动化，怎样进行自动化，这都是有一定学问的，也是一个senior测试人员应该具备的基本能力。因为作者的能力问题，使得后来的测试人员不愿意用他们的代码，宁可另起炉灶。这完全不能说明自动化有什么不好的。你想想看，如果你设计，实现了一套非常好的，非常灵活的自动化系统，后来的人很轻松的能够上手，他为什么还要自己重新来过呢？以我个人的经验来看，想另起炉灶的最根本的原因是因为以前人留下的代码太滥了。这个不光测试有这个问题，开发中同样普遍。我设计的自动化框架，到我辞职后一年还没有替代品的出现，大家都是在我的基础上进行新的开发和利用，以及扩展。这又说明了什么？我从来没有试图去说服别人一定要用我的。好的东西，别人一定会看到的。

下面分几点讲讲为什么要放弃对测试自动化的幻想，和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法，可以去这个微软员工的Blog http://minimsft.blogspot.com/2006/08/dev-vs-test-vs-pm.html 去看看为什么Windows测试组用的WTT测试框架被称作“Waste of Tester Time". 我最基本的观点不是说测试自动化不能测出bug，而是想问: 一个比较复杂的测试自动化框架所造成的人力浪费，值不值得最终的结果？如果不做测试自动化，能不能达到同样的效果。以我的亲身经历，去年我的测试组两个人对应开发组五个人，项目经理三个人的工作量，去年做了好几个Release，Hotfix只有两三个。我们旁边的测试组七八个人对应五六个Dev. 他们又是自动化，又是搞程序覆盖率，好不热闹，Hotfix 也不少。按一个人的人工成本12万美元，我们组省至少三个人的成本36万美元。

[comments] 作者自己在自动化中出现了很多问题之后，并不是积极地想办法去解决这些问题，而是消极地放弃了自动化测试，实在是令人感到可惜。要知道，发现问题是最能提高人的能力的时候，你把这些问题解决了，你的水平，能力，经验就相应的得到了提高。并且，作者从一个极端走到另一个极端以后，就想方设法找一些证据来支持自己的观点。比如，通过微软员工的blog。一个员工blog里的观点能证明什么呢？你有没有去问过windows 测试组对WTT的观点呢？别人一说，你就相信？可以看出作者不是一个严谨的人，吸收东西总是从自己的思想角度出发，而没有经过验证。作者在自动化过程受到挫折后，竟然与当今测试的发展背道而驰，实在是令人费解。

作者的问题是，一个复杂自动化框架值不值得去做？如果不做自动化，能不能达到同样效果。从这里我们又一次看到了作者走了极端。复杂的自动化不值得做，就要抛弃自动化。首先，我不想辩论到底什么是复杂的自动化，是它本身复杂，还是你自己给搞复杂了。这里我假设，它不值得做。可是，这样就抛弃自动化吗？我的问题是，如果复杂的自动化不值得做，那么相对简单的自动化值不值得做？合理的自动化值不值得做？是不是一定就要抛弃自动化？接下来，作者用自己的经历来说明，自动化没有必要，并且和其他的team进行了比较。从数据上看，好像自动化测试真的不如他的手工测试。我想这种比较意义不大，因为我可以给你举出更多的例子，自动化比手工测试效果好。并且，你hotfix少也不能说明什么，说不定你要用合理的自动化，都没有hotfix呢。别人如果不用自动化，hotfix更多呢。产品不一样，都很难进行公平比较。另外，既然公司给他们配备了更多的测试，本身就说明了其他组的项目复杂度比较高。你们少的测试，说明了复杂度比较低。最后质疑一下工资成本，12万美金的年薪？你真有那么多吗？如果是的话，也不代表普遍的测试人员的工资。不知道你这个数字从何而来？如果你拿着这么高的年薪而不能搞定自动化的一些基本问题，那么我还有点为你担心了。

今天七月四号美国国庆节，有时间坐下来总结一下过去几年在微软的测试经验，谈谈对测试自动化的看法。

[comments]今天看到这篇关于自动化测试的文章，有很大的误导作用，我也谈一下对自动化测试的看法。首先，作者是一个在微软工作了几年的一个测试人员，总结的是在微软的测试经验。可是他总结的并不是典型的微软公司的测试观点，而是自己个人的测试观点。因此，他的观点实际上是与微软公司没有太大关系的。这点，大家还是不要被误导。众所周知，微软在几年前对测试有一个大的改变。以前微软有两种职位，STE和SDET，前者是手工测试，后者是自动化测试。微软把STE基本cut掉了，因此STE要不走人，要不转SDET。转过来的，因为以前主要是手工测试，因此就对自动化测试产生很大的抵抗情绪。这种情绪是team lead很不愿意看到的。因此，STE的困境是比较大的。还有就是在微软里做几年如一日的测试人员大有人在，因为能力问题，级别得不到提升。因此，几年还是junior。所以，在微软做几年测试，也不代表就是一个级别很高的人。

另外要说明一点，从文章的title里可以看到，这篇文章是说给迷信自动化测试人员的。作者以前本身就是一个迷信自动化测试的人，可是后来从迷信变得不相信自动化测试了。可见作者是一个很容易走极端的人，从头到尾都没有用一个公平理性的态度去面对自动化测试。还有就是，这个文章如果给迷信自动化测试的人看，还是有一定意义的。可是，我们当中有几个人像作者以前那样迷信自动化呢？大部分看了可能会觉得是针对整个自动化来讲的，而且作者确实也偏离了他的title，因此我也需要澄清一下。

先说说为什么做测试的人喜欢搞自动化。
第一，自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己，可是测试工作很多时间不需要编程，于是做测试的人想方设法写些程序，以显示自己也会编程。结果往往是欲罢不能，测试自动化程序越写越多，越写越复杂。后面我会谈谈测试自动化框架复杂的代价。
第二，为了出成绩。很多测试组为了向管理层展示成绩，往往要拿出例如测试自动化达到80%，程序覆盖率达到90%。要我说，这些都是Bull Shit. 就象小平同志说的“实践是检验真理的唯一标准”，我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多，用户出了问题，也是白搭。另外，一个人就可以做的测试，自动化往往需要两个，三个。倒是解决就业的好方法。

 [comments]我想作者漏掉了一个最重要的方面，那就是自动化可以解决我们的测试问题。两个方面，一是自动化可以完成手工不能完成的任务，二是自动化可以替代手工重复的劳动。这才是我们搞自动化最重要的原因。关于自尊心的问题是有的。可是作者解释的好像都不在理。计算机科班出身的人都喜欢做开发？这个观点从何而来？计算机出身的人可以做开发，测试，dba，support，销售，市场，自己创业。各种工作都有可能，怎么能说都喜欢做开发呢？以我的个人经验来看，喜欢做开发的是少数。做测试经常是身不由己？我认为做开发也很多是身不由己。测试工作很多时间不需要编程？开发人员很多时间也不需要编程。后边的就不说了。总之，给人的感觉都是作者的心理。好像作者自己喜欢做开发，身不由己作了测试，发现不需要什么编程，然后就想方设法写程序，以显示自己也会编程，结果出了大问题了。这里可以提供两点信息，一是作者想做开发没有做成。可见作者的开发能力有限，老板不给提供这个机会，因为老板是要给产品负责的。还有就是，做了几年的程序，而且一直想转开发而转不过去的话，我真的不能suppose他水平有多高了。另外就是，把自己的心理，心态，引申到整体，不是很有道理。

用户不出问题是唯一标准？你可以认为它是一个标准，可是你怎么衡量？用户，半年不出问题，一年不出问题，还是五年不出问题，永远不出问题？还有就是，难道只能在用户的使用上才能衡量一个软件的质量吗？我们做测试的首要目的就是在用户拿到产品之前就要保证好产品的质量。难道，自动化测试，程序覆盖率不是实现这个目标的解决方法吗？一个人做的测试，自动化需要两，三个。这又是从何而来？以我的经验，三四个人的测试，我一个人做自动化就可以完成了。我前不久的工作成绩就是，本来需要3个星期手工测试的，经过我的自动化，变成1个星期完成了。也就是说，本来需要三个手工测试人员，现在只需要一个自动化测试人员了。还有就是，我们的软件需要在不同平台下，不同环境下测试，没有自动化怎么行？比如，我们要在2000，XP，XP+sp1,XP+sp2, 2003, 2003+sp1，2003+sp2,vista。这还不包括，这种cpu，windows的不同版本呢。手工测试得需要多少人呢？

一直都在注意Oracle的招聘信息，毕竟是世界第二大软件公司呀。可是，奇怪的是观察了很长的时间都没有发现任何招聘广告。并且，从我对它的初步了解来看，与微软，Google中国研发中心比起来，它显得那样的无声无息。终于有一天的早上，打开zhaopin.com，第一次发现了Oracle的招聘信息。高兴的是，里边包括若干个测试的职位。马上把简历投了过去。下午接到了电话，一听果然就是Oracle的，要跟我安排面试。Oracle的招聘比较奇怪，没有recruiter,都是hiring manager跟你联系。

面试当天，早了几分钟来到公司，被前台领到一间会议室里面，给了一套试题来做。同屋已经有好几个人在做题了，心理顿感不爽。本来以为是要单独给我面试的，没想到竟然会跟大家一起做题。更没想到的是，当我打开试题的时候，我好像基本都不会做。实话实说，我并没有什么Oracle的技术背景，可是我觉得做测试也不需要懂这么多试题上的知识吧？硬着头皮做了两道，实在做不下去了，起身就走。到了前台，告诉他们我感觉这个面试不对劲。他们才反应过来给搞错了。忙着给我的hiring manager打电话，让我去了她那里。

Hiring manager是个中年女士，看起来人就很nice。面试也是在一间会议室进行的，做了一屋子的人。看来对一个测试人员的面试也搞得挺隆重。Hiring manager并没有提问，第一个提问的是个技术大拿。他面试的场面我还从来没经历过。简单的说就是，他看着你简历问你问题，问得肯定是你做过的东西，但是，问得深度是特别的深，一般你还回答不上来。这种知识面，深度的人，到任何地方都是大拿。我是挺佩服的。第二个面试的可能是一个香港人，他主要是考察我的英文水平，用英文跟我聊了很长时间。第三个人主要是考察我的Linux的技术，很抱歉好久没有用Linux了，问我的很多简单的命令，本来我以前是会的，可是忘记了。不过，这个时候那个manager讲话了，说我的背景学Linux应该是很快的事情。然后我主要跟他们聊了自动化测试的东西，他们竟然还没有什么自动化的测试，基本还是靠手工测试。他们也希望我能够在自动化测试方面能够给公司带来些新鲜的东西。

第二天，manager给我打电话，说美国的老板想跟我聊聊。与此同时，我也接受到美国的一封email,要跟我电话面试，搞得我有点迷惑。最后才知道，是两个不同的老板要跟我面试。定了周末两天的上午，因为对方是在加州，我们合适的时间只有每天的上午。第一天面试是一个中国人，不过我们全是用英文交谈的。看得出他对我很满意，多次给我说这个职位不是在他的team，如果对方的不要我，我可以来他的team。他是做日本方面的项目，另一个team是做open source的项目。一直谈的都很愉快，直到谈到待遇的问题。说实话，我当时的目标是每月2万，不过由于微软，Google的情况还不明朗，不想再错过这次机会，因此就要了每月1.5万。没想到他却明确回答不能满足，并跟我说他们有很多福利等等。最后问我要多少钱，我就回答算上福利全年20万。实际上当时有点傻，因为月薪1.5万和加上福利年薪20万应该是差不多的。对方就没有再说什么，我们结束了谈话。第二天是个老外，主要谈一些技术的问题吧，我也没感觉是好是坏，因为昨天的人已经说过不行就去他的team了。

不过，后来他们就再也没跟我联系过。我估计是我的要价太高了，而且我最近知道我一个朋友有多年的Oracle经验，刚刚进入他们那里，也不过是20万年薪。这样解释了我的一个疑惑。我当时就奇怪，堂堂一个Oracle怎么把研发中心放到上地。看来他们本身就不想投入太多。后来又听人说，这个中心的老板不地道，总之有一些rumor,不知道是真是假。

我想当时如果我真想进的话，开口小点应该是没什么问题的。这里给大家介绍一个面试的经验，对方的技术你不熟悉可能不是一个大问题。面试的时候，一定要有自信，让对方知道你有能力，有激情，有头脑。并且，一定要大胆跟他们讨论一些你擅长的技术问题。让他们更细致的了解你的能力，留下与其他人不一样的印象，就更容易打动他们。还有一个经验就是，谈待遇的时候，如果你真的想进这个公司，你就不要说具体数目了，就说我很珍惜这个工作进会，我一直都期望能进入你们的公司，你们可以按照标准给我工资就可以了，我没什么特殊的要求。我后来的面试在待遇上都是如此回答的，并且都得到了offer。

下次有时间，讲讲我去微软，北电面试的经验教训。

作者: cleverman    时间: 2007-7-8 10:49     标题: 到底什么是白盒测试？
白盒测试，黑盒测试是刚学测试时候的基本概念。我们大部分人可能做的都是黑盒测试，也就是看不到代码，对产品进行功能测试。
可是什么才算是白盒测试呢？
Code coverage算不算白盒测试？
自己和别人一样做黑盒测试，可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？
如果不算的话，因为测试的过程中也分析了代码，明显不算是黑盒测试。如果算得话，自己跟同事做同样的工作，只是自己没事看看代码就可以说别人做黑盒，自己做白盒？
要不算灰盒测试？
我们公司并没有白盒，黑盒测试的概念。可是这又是测试最基本的概念。我有点confused.大家讨论一下好吗？

QUOTE:

原帖由 wyzwise 于 2007-7-8 11:43 发表
White box 就是在全部理解系统的基础上去go through source code和architecture documents。
Code coverage（当然是拉） 是White box 的一个重要的优势和black box比较。。
首先做white box 的时候要有计划 ...

那我说的第二种情况,算不算白盒?
还有就是能不能举个灰盒的例子.

QUOTE:

原帖由 shanxi 于 2007-7-8 11:52 发表
白盒、黑盒
自动化、手工
回归等等
具体做事的时候没有区分的那么细致，很少是只做其中一种，基本是交叉着本着解决测试问题的效率来采用。

我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.

QUOTE:

原帖由 cleverman 于 2007-7-8 12:05 发表
我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.

这个一部分是对得，我以前得公司，计划，管理不是很好，所以每次经常什么东西都混在一起，不是很明确。。。
其实如果管理好，这些测试的理论是很有用得。。。我现在得team就是按照成型得MVC得testing phase一步一步走，每一步每个在team里面得人都很清楚，都知道什么时候在什么事情。。。 测试还是要根据不同阶段做不同得事情得。。。

QUOTE:

原帖由 seifer1754 于 2007-7-8 13:40 发表
既然白盒，黑盒 的概念你都知道了，那么举个例子来说明一下好了。
void test(x)
{
   if (x

我明白你的例子，不过你认为我说的第二种情况算白盒测试吗？也就是说跟黑盒测试没有任何区别。可是，遇到bug自己可以去代码里找到root cause.

QUOTE:

原帖由 wyzwise 于 2007-7-8 14:32 发表
"可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？"
这个不是testing...是bug fixing:)

不对。真正好的测试人员report bug的时候，是要写明白代码的root cause的。这只是发现bug，怎么能算fix呢？
真正的fix是要开发人员来做的，测试人员没有这个权力。
你找到代码里的问题，不代表就解决了这个问题。明白吗？

QUOTE:

原帖由 cleverman 于 2007-7-8 14:35 发表
不对。真正好的测试人员report bug的时候，是要写明白代码的root cause的。这只是发现bug，怎么能算fix呢？
真正的fix是要开发人员来做的，测试人员没有这个权力。
你找到代码里的问题，不代表就解决了这 ...

也许你们公司的特殊要求吧。。。我对我的team的要求是，tester不需要去找到原因，找到哪里出了问题。。如果每一个tester都花时间去看code，找root cause，这个涉及到成本问题，毕竟人工是一个人每小时上百人民币。。。呵，cost and timeframe 是一个trade off...
最省事省力的做法是，找到问题，report to manager,assign to the function owner...fix bug...new build version...regression.......这个是常规做法。。。
还有一个就是white box 和black box  。。简单说是，white box is to test the design(defect),black box is to test the system without going through the code inside...

QUOTE:

原帖由 scorix 于 2007-7-8 18:25 发表
楼主应该自问一下：“在发现错误之前的测试过程中，我是否只关心软件的内部构造？”
答案如果是肯定的，那么就是白盒测试。
至于定位错误，我想大部分的情况都要翻看代码才能确定哪里出了问题，但这不代表就是 ...

不对呀。我们在functional spec的时候就involve进去了，很关心软件的内部构造呀。我们对Windows Internal Knowledge的实现都要精通，更不要说自己的软件了。好像这不能说明是白盒测试呀。

QUOTE:

原帖由 wyzwise 于 2007-7-8 17:28 发表

也许你们公司的特殊要求吧。。。我对我的team的要求是，tester不需要去找到原因，找到哪里出了问题。。如果每一个tester都花时间去看code，找root cause，这个涉及到成本问题，毕竟人工是一个人每 ...

不是我们公司有特殊要求，最top的公司很多都这样要求的。对于一个strong的测试人员来说，他还需要跟开发人员讨论solution options，在fix之前就发现可能引起的其他问题。别说测试人员了，就是pm很多都很精通coding。他们都会code review去报bug。这里的人工比你们贵多了。还有就是，
white box is to test the design. What design? internal design or funcationality design, or code design?
Backbox is to test the syste without going through the code inside. If so, my second example is a not a black box at all. right?
[ 本帖最后由 cleverman 于 2007-7-9 01:24 编辑 ]

QUOTE:

原帖由 DERYCK 于 2007-7-8 21:14 发表
看了以上几位的看法，我觉得还是在测试过程中你是根据外部功能设计的用例进行测试，还根据内部代码的结构设计的用例进行测试。
只要分清楚这两种区别就明白什么是黑盒测试和白盒测试了。
我个人认为定位错误不 ...

不只是定位错误，是要找到错误的root case。 不然的话，你不能定bug的优先级别和严重程度。
比如我不久前发现了一个bug，会导致windows重启。你怎么定优先级呢和严重程度呢？windows重启也够常见了吧？
因此一定要找到root cause，最后我们发现是一个安全漏洞，可能被黑客利用进行攻击。因此就给了最高的优先级和严重程度。开发人员当天就fix了。
这就是我们为什么要求测试人员有这个能力。大公司里，老板不可能管任何事情，很多都需要测试人员来drive。但是，你必需要有个好的判断，不能出错。
[ 本帖最后由 cleverman 于 2007-7-9 06:45 编辑 ]

早就知道加拿大的滑铁卢城市有美国一个著名安全公司的研发中心，也曾经梦想过有朝一日能在那里工作。因此，一直关注他们是否在招聘测试人员。

机会终于来了，一天突然在招聘网站上看到他们招聘两个测试工程师，马上投了简历上去。

第二天，接到了recruiter的email，问我是否能去加拿大参加面试（我当时在北京工作）。因为恰巧要拜访加拿大的一朋友，朋友家在滑铁卢旁边的一个城市，就答应了。看来他们挺着急，给我约到了我到达加拿大的第二天上午10：00。

终于等到这一天了，头天大概晚上12点才到达加拿大，赶紧休息，为了有精神第二天面试。第二天早上驱车赶赴这家公司。

公司在著名的滑铁卢大学的北面，是独立的一个大房子，只有一层，大概几百名员工。环境来说，在加拿大还是很不错的了。没想到recruiter竟然是个男士，让我在会议室等待。

不一会儿，来了两人，一男一女，年纪都不算小了。后来才知，男的是team lead，女的是test manager。

面试大概是半个小时，其中前15分钟是他们问我问题，后15分钟是我问他们问题。没有问到具体的技术细节问题。他们主要是了解我做过什么项目，问了我对安全领域的看法，还有就是他们对这个职位的技术需求，并且告诉我不是team lead的置位，我是否愿意。我主要是问了他们自动化测试的情况，能不能看开发代码，有没有白盒测试等等。面试之后并没有什么结果，但是自我感觉还好。

然后驱车回去，刚到家门，朋友就说有人给我打电话了。一看号码，正是这家公司，赶紧打了回去。recruter上来就跟我说，准备给我offer，想讨论一下工资的问题，问我期望多少。说实话，我对工资并没有特别高的期望，我更重视有海外的工作机会，因此回答你们看我的水平来给就可以了。他们回答是X万加币，我回答it's reasonable,实际上已经超出了加拿大平均IT的工资不少了，我也很满足了。

后来的offer竟然又给我在这个基础上加了2000加币，感觉心里很舒畅。不像国内的企业，看你满足了，可能还要给你减点。大公司还是很大气，你满足了还多给你点，公司没多付出多少，可是员工的感激之情就不一样了。