这也是测试的一个发展方向吧，从底层开始测试才是最好的测试
测试需要走向“开发”
在整个软件生产过程中，测试和开发分工是不同的，但是从个人来讲，测试和开发不管工作目标，学习方向基本上是相似的。工作目标：
测试是保证软件质量 开发是开发优秀的软件
学习方向：
工作决定我们的学习方向，测试不能一直都停留在研究理论方面，测试理论是很重要，但个人三年半来一直觉得coding也是必须的。平心而论开发转测试是很容易的，并且要比一般目前普通的测试人员测试更有效率。这也是目前测试人员能力上升的瓶颈所在，测试人员和开发人员的不同从个人能力来看，在于他们会coding，而测试人员不会或者不精更或者也许可以叫做不重视coding。那么coding真是那么重要吗？我个人觉得，是的。测试人员可以不会写，但一定会看，其实coding只是一个方法，是让我们更加了解系统更加了解系统底层的一种最直接最有效的方法。可能有人问，为什么要了解底层？我只要找出bug来就可以啦。很简单，从bug严重级别来说，界面的错误和底层的错误谁更重要呢，我想大部分做过测试的人都会有体会吧。
做测试的同志们，咱们扪心自问一下，测试中的测试技术和测试思想，真是那么艰难的让开发学不会，了解的loadrunner,QTP,或者更强一些的同志会用脚本写工具，这些开发不能够自己来做这些吗？其实都是人，测试能学会，开发想学也能学会去做，并且这些东西真的不难甚至可以说非常简单，尤其是使用qtp,loadrunner等测试工具来测试，都有详细的帮助。反方观点里面所提到的技术和思想，也许只是思想是我们唯一可以拿出来炫耀的文字了。
做为一个从事测试3年多快4年的测试人员，经历了从终端测试到服务器测试，从单一手工测试到现在从事的自动化测试，从功能测试到性能测试后，我真诚的希望喜欢测试同志或者想要在测试这行发展的同志，不要再心存幻想不学习开发方面的知识(不仅仅是coding)，如果抱着反方这种心态在从事测试工作，这是非常不可取的。
所以，我在这里真诚的投了正方一票，如果开发转测试那么在公司的立场，会比较两人能力强弱，所以如果你只有测试思想或者思维做为武器，可以想像是多么无力，还存在另一种威胁，测试人员本身在进化的过程中成为了“开发”人员，从而取代一直自认为自己为“测试”的人员，这种肯定是趋势。最终测试“开发”人员会将完全取代测试人员。
[ 本帖最后由 coffeg 于 2008-12-4 11:54 编辑 ] 我觉得就个人来说，一个开发人员如果拥有系统的测试方面的知识是可以做测试的，
但是就一个公司，一个团体来说是测试人员是不能缺少的的。
就像医生和护士的关系，我们不能是说医生不会做护士的那些事情，
只是大家各有侧重点，是不能简单的被替代的。 太帅了说了这么多了
我也来说说从个人情绪上讲 如果自己做的东西自己都不满意那就太郁闷了
开发人员不会取代测试人员
开发人员的“铁路警察”思维决定了他们永远不会取消测试人员。对于开发人员来说，因为开发的思维局限，他们永远只关注于跟他们手头模块相关的一些重要的问题的发掘和解决。对于即使很严重的但是不是他们视线范围的东西，他们是不会去理会的。也就是说，他们的不具备测试人员的基本道德素养--在最短的时间内发现问题，并且进行汇报和分析以及解决。
同样一个功能，测试人员的实现方法有很多，他们因为自己了解编写规则，所以对于根需求不符合的或者跟习惯不符合的实现不会去关注，因为他们觉得，实现了就OK了。
对于测试人员来说，他们会去研究的是业务，是客户的需要，习惯而不是代码，他们一切以客户的需要为出发点，想尽办法去找出所有的问题而不是仅仅满足于某个功能的实现。
对于大多数开发人员来说，如果做测试，只是适合做单元测试或者pass-to-pass测试。没有测试思维的开发人员，永远替代不了测试人员。 我就是做开发现转学测试的，谁写的正方观点呀，丫都看不懂，没意思，开发压力大，但是轻松，测试压力小点，但是累和烦
开发人员和测试人员从不同的方向保证软件质量
我认为开发人员主要是从某个功能是否实现的角度去进行开发设计的，而测试人员主要是从某个功能实现的是否正确，该功能的实现是否影响到其他功能实现来进行测试，个各的优势。1.开发人员了解程序代码，逻辑架构，但往往负责某个功能的模块开发，只是比较熟悉其负责的模块及其相关模块，而非对整个系统非常熟悉（也有高手对整个系统非常熟悉的，这样的高手列外），如果想从测试方面发展，还需要花很多时间去学习整个系统的架构，看整个系统的代码实现方式等等，还需要花时间去学习测试理论知识和测试实践，积累丰富的测试经验，行业内也有很多开发转测试的列子
2.测试人员（以系统测试为例），站在整个系统的功能实现上考虑，进行测试，不但保证某个模块功能实现正确，也有保证与此相关模块的功能不受到影响而且实现正确，比较熟悉测试理论和测试方法，也又丰富的测试经验，如果想从程序开发方面发展，也有花很多时间去学习程序设计，行业内也有很多测试转开发的列子
如果开发人员想做好测试，仅仅凭开发的知识是不够的，没有经一定时间的积累，很难成为一名优秀的测试工程师，测试的领域越来越广，测试的方法也越来越多，不是一下就学会的，测试经验不是一下就有的
看帖
!!!!!!!开发和测试，共同的合作者
开发和测试是一个项目中共同的合作者，为了一个共同的目标：高效、高质量的完成产品／项目，而走到了一起。开发和测试的关系不应当是排挤、对立，而应该是合作、共赢。
怕被开发挤掉的测试，只能说是技不如人，要加强修炼。
开发知道测试的方法和目的，能够更有效的避免错误，提高代码质量；
测试知道开发的理论和技巧，能够更有效的了解实质，提高测试效率；
欢迎开发做测试，但不是为了减压，而是为了更好的提高质量；
欢迎开发做测试，这样也能让开发更深入的了解测试，其实真正的测试压力并不比开发小；
测试也要向开发多学习，能把测试做深做好，毕竟深入的测试是需要一定的代码功力的。 我是反方...
理由:知由不具...
闻道有先后，术业有专攻，如是而已
闻道有先后，术业有专攻，如是而已不做测试不知道测试的苦
我以前做开发，转测试有一年多了，
真是不做开发不知开发的苦，
不做测试更不知道测试的苦。 不做那一行，永远不会了解这一行的苦！
应该没有谁替代谁，相辅相成才能事半功倍！！ 1，开发掌握的编成经验是在测试的时候会有很大帮助，尤其对于系统内部架构和code运行机制上，不过这样的开发去做测试优势最多只能发挥到ut这块，到了it，st之后的则需要懂测试的，了解业务的测试人员去做更加合适。
2，如果一个开发人员做了很久的测试，那这时他已经是测试人员，不再是开发了，呵呵！！！
3，可在开发初转测试的时候有很多东西是需要扭转的：看问题的角度--从代码角度到业务角度；从程序角度到需求角度；从测试角度到与开发沟通，和需求人员确认，这一系列的过程是开发到测试的一个转变，通过了则可以，通不过则就没希望了。
4，开发需要喜欢code，但测试不光是喜欢的问题，还要有灵活性，好的交流沟通，喜欢一个东西可不是那么容易的。
5，开发喜欢想当然的去考虑问题，而测试认为一切皆有可能。
所以说开发取代测试是不可能的，因为惯性思维是每个人很容易形成了，而更改则很难，试想如果一个团队的测试工作都由开发去做了，那质量和使用还能否那么让人放心呢。再从历史角度来看，正是因为测试不是开发就可以解决的，所以近年才高度提倡测试的重要性。
综上所述，开发取代测试是不可能的，各尽其责，则能发挥最大优势。 不可以！ 分析这个话题的背景描述： 开发人员有意转做测试，是否会挤掉原测试人员？
感觉首先要考虑下：
1.开发人员是否会经过系统的培训；
2.原测试人员是否有着丰富的测试经验；
说下他不可能取代原测试人员的情况：
1. 若开发是兼职测试的话；
2. 若开发人员无培训；
3. 原测试人员有丰富经验； 开发的做白盒测试还可以~但要开发人员取代测试人员我想那是不可能的~在开发人员眼里程序可以正常运行，功能可以实现就行~但测试人员追求的是完美~开发人员总是有理由说这不是BUG，开发人员最不愿意看到的就是自己做的程序中存在BUG～同理，让开发人员做测试从他们内心里就理解做开发的不易，所以不会追求完美，他们只是从开发的角度来做测试，而不是从用户的角度来做测试~两者之间做测试的目的是不尽相同的~
ww
不做那一行，永远不会了解这一行的苦！这句话说的很好~~有些人怎么把事情想的那么简单 毕竟在中国这片土地上，大部分的IT公司的还是更多的关注开发，测试对整个项目的重要程度对于管理者来说，转变思维不是几十年能够转变的，他们会根据用工成本来衡量，可就这么一衡量，那么测试这个岗位就危险了，我就是被公司人力成本衡量陷害的，取消测试部，开发和测试任务全部由开发人员替代。
我不会说大道理，只会认清现实，所以测试这个职位在中国的IT企业真正被重视，估计还得在需500年。 呵呵 我只能说开发人员可以取代测试人员，但是开发人员又要开发，又要测试，你真的当开发人员是神？在现在项目时间普遍不够的情况下，叫开发人员去做测试是不可想象的，真的有这种情况发生的话，这个项目肯定要毁掉的，开发开发不好，测试也测试不好。所以术业有专攻，让开发人员做开发，测试人员做测试吧。这个问题没啥要pk的。不论从成本，进度，风险角度来说，都不能让专职开发人员去做兼职的测试。
