51Testing软件测试论坛

标题: 测试人员驱动开发人员，可否？（2010-3-3）（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2010-3-3 10:27
标题: 测试人员驱动开发人员，可否？（2010-3-3）（获奖名单已公布）
测试人员驱动开发人员，可否？
就是说开发一个软件产品应该以测试人员的判断和期望为依据，因为测试人员更了解用户需要什么，而不是像以前大家所认为的测试人员是给开发人员“擦屁股”的。欢迎大家畅所欲言！


如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！





获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
rolei
50元手机话费充值卡
二等奖
carina2010
300论坛积分
三等奖
huxb_dowant
100论坛积分
作者: willingchenlp    时间: 2010-3-3 11:41
拿个床来占SF。

占坑待编辑。
作者: 寻根问底    时间: 2010-3-3 11:58
现在在我们公司，测试人员，还是在给开发人员“擦屁股”。

要改为像楼主说的那样子，个人觉得不行。

首先：测试人员，在公司的地位，普遍比开发人员低。
其次：开发一个软件，本应该按照策划文本或用户需求方案决定，而不是测试人员说了算。现在我们公司的情况是，就算是遇到用户体验方面的问题，我们测试人员，也必须经过策划人员或上级确认，才能告诉开发人员如何做。
最后：“以测试人员的判断和期望为依据，因为测试人员更了解用户需要什么”。我觉得每个测试人员，都会有自己的想法。假如真的能够做到代表用户，那么这个测试人员是非常成功的。我想，这时，其职位就不是测试人员了吧

一家之言，欢迎指正
作者: 厍仕杰    时间: 2010-3-3 12:29
要满足三点条件才可能实施：
1.高层支持
2.测试人员有一定的技术水平
3.所做项目要具备作为试验品的条件

即便实施开始，也要符合以下三点：
1.清晰工作处理流程
2.完毕的文档支持
3.清晰明确的角色定义

一点拙见、谢谢。
作者: rolei    时间: 2010-3-3 13:02
标题: 测试驱动开发不如用目标驱动整体
先计论一下题设（提的太有意思，忍不住要说两句）
１、"一个软件产品应该以测试人员的判断和期望为依据，因为测试人员更了解用户需要什么"
如果测试人员更了解用户需要什么，要需求分析人员做什么？
如果以测试人员的判断和期望为依据，那么用户的需要是什么？
测试人员用自已“制定”出来的标准验证自己的想要的产品，这与开发人员自己测试自己的程序有什么区别？
测试的价值到底是什么？

２、不是像以前大家所认为的测试人员是给开发人员“擦屁股”
测试能擦得了这个“屁股”？如果可以，建议这样的测试做到项目管理或是咨询去。
你就不怕你把“标准的制定权”拿到后，所有的问题都会一股脑的冲向测试，测试人员成为“被扣屎盆子”的了。
开发的质量不高不假，测试发现了大量问题不假，但决不是“擦屁股”
不要忘了测试工作：发现问题，提出问题，验证问题，不断改进。

回归正题：测试驱动开发，可否？
１、测试和开发什么关系？
独立？依赖？
合作，才是正道。
软件过程发展了这么多年，每一个岗位的职责定义已经很详尽，如何何作也有详细描述。
为什么执行的不好？为什么让测试做的如此痛苦？
不是谁驱动谁能解决的，只是岗位职责下的奖惩措施不明确，缺少必要的约束。

２、你想管理开发吗？
也许你会说，测试只是督促，只是希望开发的质量更高一些。
如果你没有管理权，能否驱动的了开发。
从合作到管理，这种关系的变化，测试自己是否能接受。

测试不需要驱动开发，只能驱动自己。
痛苦不可怕，找到原因改正。
不要抱怨，不要等待。
期待和争取更多支持的同时，还要自己不断前行。
质量不是测试一个人或几个人的事，质量是团队共同努力的目标。
作者: chengning    时间: 2010-3-3 13:09
作者: chengning    时间: 2010-3-3 13:12
顶5楼
作者: huilin.gao    时间: 2010-3-3 14:21
楼主的观念非常正确
但是在国内的大环境下，就目前而言，根本无法达到那个高度
我工作了几家公司，都是测试在给开发擦pp
“开发一个软件产品应该以测试人员的判断和期望为依据”这句话有点问题，应该是用户，因为测试人员对需求的理解也会因为种种原因出现偏差
作者: xunmi    时间: 2010-3-3 17:15
如果测试人员在公司里的角色就是给开发人员擦屁股的话，那说明这个公司的测试部门工作是相当被动的。测试人员的职责应该去思考如何提高公司产品的质量，而不仅仅只是限于去发现产品中的BUG。
部门管理人员应该从测试管理流程上对这种现象进行改善：（1）公司在需求和设计评审时，测试人员需要参与，并积极提出建议；（2）测试人员编写完测试用例后，需要发阅给产品经理和开发人员，进行评审，并提取出BVT测试用例供开发人员版本提交时用，多增加测试与开发之间的交互；（3）测试人员不能仅仅只做功能测试，还需要做性能和自动化方面的测试，使得部门测试人员的技术水平提高，这样才能发现产品更多的缺陷。
作者: zhang1987yuan    时间: 2010-3-3 18:07
我现在还在擦PP呢。哎。。。什么时候才能出头啊？还是自己的能力不行。说话没有分量。
作者: happylongnv    时间: 2010-3-3 22:13
测试完全驱动开发是不可能的，但测试对开发起相当重要的作用却是有可能的，而不简单的只是擦屁股或者说做开发人员的秘书。原因：
1。测试人员本身认识的局限性，测试人员不是用户，只能尽量从用户的角度来看问题。。。有些事情还需要和开发人员讨论，甚至碰到测试人员和开发人员无法达到意见一致的情形（当然这种情况一般要项目经理或者最终用户定夺）。
2。测试人员地位的问题，很多公司测试人员的地位普遍低，根本没有说话的份。
3。但是测试人员能做到尽量将开发人员交代的事情做好，并且适当的和开发人员争辩，坚持自己的意见，如果你的意见大多数情况下是对的，并对项目的质量起了帮助，我想开发人员会对你另眼相看的。
不才，期待更新的看法。。。
作者: oac    时间: 2010-3-3 22:57
说到底，就是目前测试人员不太能参与进软件需求分析及设计阶段，做到尽早测试。目前国内很多公司的领导层对测试的定位也就在给开发人员“擦屁股”阶段。国内软件开发的普遍意识是尽量民工花，工厂模式化，跟做山寨机一样。很多的开发也就是不断垒代码的民工，处于产业链的底层，而测试就是更底层了。
作者: 开着拖拉机上班    时间: 2010-3-4 09:38
如果单独回答楼主的问题：可以
但是大家在讨论的时候最好弄清开发和测试的最终目的是什么，引用5楼的一句话：质量是团队共同努力的目标
嘎嘎嘎
作者: kiss0710    时间: 2010-3-4 12:34
开发和测试应该是合作关系，相互独立又相互监督。
用户的需求需求文档不都定义好了么?
个人认为测试存在的最大目的是监督开发成果的正确性，规范性，健壮性。
测试驱动开发，在某个具体的功能点上是可能的，在测试比开发更有经验的前提下，可以在符合规范的前提下引导开发向自己期望的方向修改代码及处理异常。
从整个项目来看，测试不可能驱动开发如何开发。
不过测试可以影响开发进度。
作者: dumb_dora    时间: 2010-3-4 12:54
能者多劳
假如测试提的意见能够真正代表客户，能够说服大家，那我想，这个时候测试确实能够驱动开发去做一些修改的
那假如测试提的意见有时候连自己都说服不了，那这样的意见又有什么参考价值呢?
相对于需求，开发，测试而言，谁的意见被采纳了，那才有真正的驱动价值。
所以，测试人员也勿需想太多，先做好自己的本职工作：发现问题，提出问题，验证问题，改进质量。
被大家认可之后再发表些有意义的言论吧
作者: 投缘    时间: 2010-3-4 13:17
按照理想化，应该测试驱动开发。因为测试是站在客户的角度，在软件投入运行前，对软件需求、设计等进行最终复审的活动，暴露软件中隐藏的错误和缺陷。测试的结论和判断代表了用户。当质量真正达到标准后，才能上线，而不是开发无限期的压缩测试的时间，等上线后出现问题，再让测试人员负责。
作者: 卿如野菊花    时间: 2010-3-4 14:38
好问题
作者: carina2010    时间: 2010-3-4 15:24
测试能不能代不代表用户，其实有很大的局限性。
如果是网站 ，大家还可以站在普通用户的角度测试一把，
要不然一些专业一点的软件，都有一定的行业特征，拿功能测试来说
例如电信方面的软件，你必须知道电信人员是怎么工作的，
如果是财务软件，你就要知道财务人员是怎么回事情，你才是真正的站在用户的角度，
但是现在大多数的测试并不知道自己的用户是做什么，甚至不知道用户怎么用软件去工作，
站在这个角度驱动开发其实没有多大的驱动力。
至于性能测试等等，就更别提了。自然更加复杂。
然后很多测试不懂开发，所以提不出有关性能或其它的建设性意见，
只能是开发怎么做，测试怎么测，顶多就是提点界面的问题啊什么修改（有时候这个，开发有可能也会不理睬），SO,不受领导重视，地位低下的评论就出来了。



测试就是一个怪圈，在中国来说都是属于不含多少技术量的职位，
其实测试真应该多一些代码，架构以及需求方面的特长或知识，这样才能真正挖掘软件的BUG，但是有这个技能的，都不会去做测试吧，哈哈。

所以说，要测试驱动开发人员，有几个条件
一，测试懂你要测的软件的功能实现的目的，这样才能了解软件功能的实用性和写测试用例的完整性
二，测试要能全程参与需求，这样才能评估开发的功能是否满足客户所需。减少返工次数和提升客户感知度
三，测试懂一些代码，不懂代码也要懂逻辑。这样才知道业务是怎么通过软件实现的，然后可以挖掘出更深层的BUG。

等真正实现这个的时候，估计你在公司也是大牛一只了，驱动开发人员，那是当然的啦
作者: z_kh    时间: 2010-3-4 17:19
先问个问题：
不知道现在有几家公司的需求做的真的有用例细致的？

不用说什么理论，直接说案例
我所负责的组里，测试和开发同时获取需求，需求确认完后，开发负责自己的codeing，我们开始用例设计，用例设计完成后，评审，审完后发给程序，他们单元测试完后还会根据我们的用例自测，并根据他们自己的测试结果进行修改。
而程序给我们的评价是，用例比需求更好用。
不知道这是否属于变相的驱动开发了？

[ 本帖最后由 z_kh 于 2010-3-4 17:21 编辑 ]
作者: swinfans    时间: 2010-3-5 03:58
现在不是有测试驱动开发吗？
作者: cangmang    时间: 2010-3-5 14:17
这个命题比较有意思哈~
    首先，从目前国内行业的发展和地位来讲，开发是占据主导地位的。
    其次，测试的目的是 检验产品是否满足规定的需求或弄清预期结果与实际结果之间的差别。如此目的来讲，如何驱动？
所以我认为测试驱动开发是不可能的。

但是我想说的是，质量驱动开发
    质量其实就是产品或工作的优劣程度，也可以看作是满足顾客需求的能力。这就大大超脱了测试的范畴。
我们都知道QA、QC，这两个的区别不用细说，相信大家都了解。
    从QA的角度讲，要规范流程和各个里程碑、检查点，这些完全就是为了质量的目的服务的。而这些恰恰是约束开发、提高开发质量的工具。
以规范的流程、制度去约束开发必然会降低开发过程中的质量损耗。同样，质量也可以驱动产品。
    最后，借用质量管理大师菲利普.克劳斯比的一句话：质量的盈利模式就是第一次把事情做对。
所以我认为，质量驱动开发是行业发展的一个趋势。
作者: 8596991    时间: 2010-3-5 17:01
其实测试是否驱动开发，需要关注两个问题：一是公司对测试的定位，二是这个“驱动”的真正含义
有些公司对测试定位，确实如大家所说的那种功能测试，系统测试，界面测试，很简单，所以大家都认为没有得到重视，也就是所谓的给开发“擦屁股”。这基本是整个中国测试行业的现状。
但有些公司，对测试的要求还是蛮高的，需要测试能够做功能测试，也能够有做性能测试，更有些需要做白盒测试。如果是这种情况，测试在整个的产品生命周期中，是起着关键性作用的。
在第二种情况的背景下，说说我个人对“驱动”的看法。这个驱动，当然是测试人员更多的去考虑产品的适用对象，在保证产品符合相关文档要求的情况下，去思考他们的使用方式以及他们的使用习惯。这种“驱动”，要求测试人员在产品需求阶段就参与进来，在以后的产品生命周期中一直跟进。在了解整个产品需求以及定位的情况下，多方面的去了解相关的行业的知识以及同行软件。这就与需求分析人员有了很大的区别，在一般的公司，需求分析人员都是市场部门的人，由他们去定位市场的需求，并提交产品部，在多个部门的配合下决定整个产品的框架以及产品的最终方案。
公司的目的是挣钱，测试人员保证的是质量。这样又有人问“QA”是干嘛的？QA负责规范流程以及里程碑，并对产品的结果做验收。测试人员保证的质量，不仅仅是功能正确，更重要的是功能好用。所以，个人理解的测试“驱动”开发，不是驱动开发去开发代码，而是提出BUG，驱动开发去完善代码与重构代码。开发人员，他们眼中只有二进制，你要他们过多的去考虑客户，那是不可能的；测试人员不仅仅按照功能流程做测试，检验功能性的BUG，也在不停的测试中，使用的常人的操作习惯，也能发现软件的易用性BUG；更有甚者，在多次测试中，发现软件的性能或者内存泄露的问题等等。诸多BUG的合成，就能促使开发人员重新考虑代码的可用性，他们会寻求更好的方式，去完善与重构自己的代码。难道这种不叫测试“驱动”开发吗？
另外说些题外话，与其说测试“驱动”开发，还不如我们怎么达到测试“驱动”开发这个层次。虽然现在中国的测试非常的不成熟，定位也低，但我们不能这么低的定位我们自己。在平时的工作中，我们需要接触更多的产品，因为有些行业，是你不曾涉及的，所以在需要的时候，了解相关行业的规则，多看同行的类似产品，就非常关键。
祝愿大家跟随测试行业的不断成熟，都有更好的发展
作者: huxb_dowant    时间: 2010-3-5 17:28
标题: 理论上是可以的，前提是测试真的很强。
测试驱动开发的首要条件是测试人员对业务和软件设计模型都很精通，同时要对要使用的编程语言比较熟悉，还要有公司高层领导的绝对支持。
测试驱动开发说透了就像测试部门内部开发自己需要的测试工具一样；对需求及软件的目标有清楚和透彻的了解，在做事情以前，所有的东西都了然
在胸。
    做到测试驱动开发软件质量就能上去？没这么简单的事情。我认为测试驱动开发或开发驱动测试，都无所谓，真正提高软件质量才是真正的目标。
其实像国外的大软件公司微软，谷歌他们的软件开发流程就是很成熟的，但国内的软件公司如果把人家那一套搬过来，却不一定能达到好的结果，弄
不好甚至会倒闭。因为投入和产出是不成正比的，一切好的流程必须有好的经济基础和优秀的管理团队来作支撑。没有适用所有脚的鞋，所以每个公
司应该根据自己的实际情况找出一套适合自己的测试流程。   
    我们中国99%的公司说透了不重视测试，而造成这一结果的主要原因是90%的测试人员做的工作技术性确实没有开发强。如果一个测试人员干的活
真的很NB,那他绝对可以NB的炒掉任何一个老板，那他的地位怎么可能不高。经济社会是以创造的价值来说话的，你够强，你就有地位；否则，不要
怨天尤人。
    作为一个测试人员，我们应该要有很强的主动性、学习能力和发现问题根源的能力。有能力必然会有地位；成就是自己给的，不要奢望天上掉金子。
    本人的一点拙见，各位高手多多指教 。
作者: shanxi    时间: 2010-3-5 18:14
被骗进来了

还以为测试 驱动的开发呢
作者: huogongyanchang    时间: 2010-3-5 23:19
我感觉还是有可能，等到中国的软件正的发展的很好，还是有可能的，
如果软件测试人员水平真的很高，这是完全有可能的，
要知道其他的行业很多都是以检验员的标准生产产品
作者: snbc    时间: 2010-3-6 11:34
不存在谁驱动谁的问题；

测试和开发是一个团队伙伴的关系；

项目前期的方案和需求阶段，测试人员需要介入，未产品的方案设计提供评审和参考意见，此时可能重点是一些易用性、易维护性、从客户角度出发的一些功能需求等；避免到了后期测试时提出问题，导致产品有较大更改的风险；

后期测试过程中，测试发现问题，可以利用自己的经验进行缺陷定位或提供缺陷解决的建议措施等；共同提高产品开发质量；
作者: ch2fjc    时间: 2010-3-6 23:17
我们公司很大程度上是测试驱动开发的，很多开发工程师只了解该项目的一部分，或者说有时候不晓得具体要设计成什么样子，这就需要测试工程师去判断了
作者: swordredlin    时间: 2010-3-8 08:43
标题: 撇开开发人员讲测试
1、首先明确，测试人员职责是发现问题。
2、不管是系统本身的问题，还是用户体验问题，作为测试人员可以不经过开发人员甚至主管可以直接提到缺陷系统中去。
3、不管缺陷类型，测试人员发现的任何一个问题，甚至是建议性的问题都工作中的成果
4、测试人员除了跟踪Bug进度之外，对于上级不予修改的Bug，一定需要负责人尽可能的给出备注。
这样，测试人员首先完成了自己的职责，对于有些不在职责范围内的事情也可大胆的放下。
作者: dennyqiang    时间: 2010-3-8 10:36
感觉大家对这个主题都有很多想法，我觉得这是好事，起码我们在考虑这个问题了，起码我们引入了这样一种理念：一个软件产品的开发，有一部分是可以由测试人员来驱动的。

其次呢，感觉大家对题目的本意还是理解得不够到位，始终把测试和开发作为一个对立面来理解这句话，基于这样一种观念的话不管谁驱动谁都无从谈起，都只会变成抱怨和无奈。

其实，测试驱动开发为什么一定要把需求人员拉出来呢，为什么一定要想到那以后岂不是测试说了算呢，也不用担心以后前一阶段人的屁股没人擦，如果有这种假设，讨论该话题肯定跑偏。

谈谈个人的一些看法吧：
1) 需求人员是必需的，这毫无疑问，哪怕测试团队有一天驱动了整个项目，需求人员也是必不可少的。
2) 有需求人员就够了吗？测试人员只需要按照SRS文档和其它文档上的功能来测就行了吗？恐怕不完全是。
3) 测试驱动开发就意味着开发从此以后一定要听测试的吗？也不见得，但至少，测试人员应该更主动才对。
4) 我不得不承认，对软件测试行业的从业人员，技术水平与相应的开发人员是有差距的，道理很简单：很多人是因为做不了开发才做测试的，也有真正喜欢测试的，但不太多。
5) 但是大家可不要忽略一点：对一个软件产品的认知能力，测试人员可不一定比开发人员差，这个跟技术水平没有任何关系。
6) 在团队中应该形成这样一种文化，测试人员说了可以不算，但是你必须重视我说的。

以前我们使用ClearQuest系统跟踪缺陷，CQ对于一个软件产品的Enhancement有单独的管理，测试人员想往产品中新加一些功能时便会将建议提交于此，但是开发人员根本没有时间顾得上这些Enhancement，连基本的功能都没时间做，哪有时间Enhance呢，也对。但是这个归要结底还是由于老板没有把这一块做起来，缺乏管理层的支持的确是一个比较头疼的问题，我们也只能在此默默的呼吁一把了。

若干年前，XP这种开发模式就被大家所熟知，其核心就是“测试驱动开发”，只不过它叫Test-Driven Developement，既然大家能接受这种方法论，为何不应该认真考虑考虑真正意义上的测试驱动开发呢，它的英文应该是：

Tester Drives Development   (主 -- 谓 -- 宾)    或者Tester Drives Developer 也行，不过这个显得比较狭义。

[ 本帖最后由 dennyqiang 于 2010-3-8 10:50 编辑 ]
作者: 绯苍信    时间: 2010-3-8 16:52
测试工作从需求开始的话就可以....如果只是做单元或系统测试，永远是擦PP的工作
作者: wepheloo    时间: 2010-3-8 18:05
首先大家应该明白测试部门不是质量管理部门，从根本上讲测试人员不需要对项目的质量负责任，他们紧紧是软件问题的发现者，是

尽量减少软件发布后由于软件缺陷而带来的损失而存在的；而质量管理人员需要对项目的质量负责任，他们是为了需求做得更好，为

了让开发写更好质量的代码，为了让测试发现更多的Bug而存在的。测试本身并没有对开发产生什么影响，他们两都从根本上是两权

分立。但测试与开发矛盾为什么会发生？本来当问题发生的时候，如，开发人员总是找测试人员帮忙重现Bug，一次两次大家都觉得

没有什么，但长期如下，矛盾始终会激发。那么这是谁的责任呢？我觉得从根本上讲是由于大家没有明确各自的责任，一方面认为测

试人员就是质量管理人员，软件有问题就不分是非地把矛头指向测试人员；另一方面质量管理人员都是公司的高层人员，他们可能由

于各方面的原因不可能会因为为那种不明不白的事而把责任扛上。于是就不声不响地让测试与开发去吵。而测试与开发即使知道真正

原因但即不敢向上头说什么。所以能驱动开发的不是测试人员，而质量管理
作者: baobao72931    时间: 2010-3-10 17:05
标题: 回复 14# 的帖子
你姓张啊？
作者: zhenni    时间: 2010-3-11 10:10
标题: 交流哈子
软件测试群号：3611124  
欢迎进入交流！
作者: NapoleonWang    时间: 2010-3-11 12:54
基本不可行。
首先声明，我是测试人员，免得有人误会我。。。

这个观点应该是从“测试驱动开发”来的。 声明一下，测试驱动开发中的测试是“单元测试”，不是我们所讲的测试，区别有：

测试驱动开发可以看做是帮助敏捷开发的一种手段。

现在来说测试人员驱动开发人员：这个工作模型是完全错误的，其实驱动开发过程的既不是开发人员，更不可能是测试人员，而是项目经理或者产品经理，其实驱动开发过程就是要控制和平衡三个维度：

这中间还包括和客户沟通，构思和实现公司的产品战略等等。这个工作是高风险、高模糊性的工作，而且很繁重，不可能交给测试人员的。
作者: alice29funny    时间: 2010-3-11 15:08
当然不行。如果这样也可以，那么项目组长做什么，不如直接叫测试人员做项目组长了。
作者: wynpere    时间: 2010-3-12 10:01
个人觉得测试只能在一定程度上驱动开发即可，比如测试过程中遇到争议的BUG，在测试人员确实了解系统业务及客户需求的情况下驱动开发执行问题修改
完全意义上的驱动似乎与需求人员、系统分析人员的工作相混，意义不大。
作者: znhwj    时间: 2010-3-13 20:25
发现有好多牛人,先向牛牛们致敬!我以前做过开发,后转为测试,我觉得测试和开发是合作关系,测试一定程度上驱动开发,同时,开会也会驱动测试,互相驱动的经果就是使得产品质量得到提升,最终满足客户要求.
作者: zhenni    时间: 2010-3-16 11:22
作者: dsy851009    时间: 2010-3-16 15:34
我怎么感觉你们把测试驱动开发的意思给理解错了呢？
测试驱动开发，并不是测试人员去驱动开发人员，而是开发人员在开始一个项目之前要先测试是否可行等。
跟测试人员似乎是没有必然联系的吧？
作者: mx113040    时间: 2010-3-18 09:35
个人认为：‘测试人员驱动开发人员这句话没问题’，
但解释好像不是说的这个意思呀
‘开发一个软件产品应该以测试人员的判断和期望为依据’这句话的意思好像在说开发一个产品的时候要根据测试人员对需求的判断和理解，如果测试人员理解有偏差怎么办？
另外，开发人员是这个产品的生产角色，测试人员则是这个产品的质检角色，两者是一种对立合作的关系，目标是一致的，所以测试人员和开发人员是互相驱动才对~~
作者: darking    时间: 2010-3-18 17:03
大家可以看看《敏捷开发的艺术》

测试驱动开发，好像不是各位说的那个意思

敏捷开发中
要求测试的水平比较高
作者: wangzihaoipp    时间: 2010-3-25 15:48
感觉我这个刚进入测试的菜鸟逃离这个行业比逃脱菜鸟这个名号还好点~~~~
呵呵。。
作者: 郁闷的芝麻    时间: 2010-3-30 15:37
谈谈我的看法，我是一个测试行业的从业者，之前做过3年开发，然后转测试，大概做了2年测试，然后做测试管理，都是同一个行业。
最开始我做开发的时候，也认为公司的测试人员没什么价值，水平低，能力差，等我真正做测试后情况发生了变化，新公司测试方面投入很大，测试不再是可有可无的角色了。

回到楼主的话题，个人认为测试驱动开发是可能的，但是要注意如何理解“驱动”二字。这个驱动不是所有的都驱动，在软件设计方面开发的优势是不可替代的，测试更多的是从流程/质量/控制方面来驱动，当然还包括需求的把握。测试人员不可能替代用户说话，但是可以做到尽可能站在用户立场说话。要达到测试驱动开发对测试人员要求很高，不但要有很好的沟通理解能力，精通专业业务知识，还要具备足够的开发设计经验。

其实就国内的情况看，绝大部分公司都陷入一种恶性循环，测试人员不能给予高薪和很好的发展机会，从而导致很多人员不愿意进入测试领域(因为没有发展)



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2