51Testing软件测试论坛

标题: 驳--虚假繁荣 [打印本页]

作者: luckflying 时间: 2009-6-3 11:16
标题: 驳--虚假繁荣
偏颇了zee老兄，你的高度决定了你的眼界。。

国人总是关注在具体技术上，技术算什么？连你都说，毕业生一把把的，那点技术你能指望用到白头？所以不要总把自己定位到苦力一级。

国外优等生学文科经济管理等，二流的才跑到理工科深造，你考虑过为什么吗？举一个例子，每个开发工具的发布都是全球统一的，所以国内软件人才与外国的技术上站在同一起跑线，但为什么MS,IBM,Oracal,SAP...全部是国外的，国内像样的产品有吗？
你不奇怪吗？同样的平台，同样聪明的群体，那么几乎颗粒无收的我们究竟缺在那里？

你要是来面试，我会很快把你定位的资深的测试执行人员，经验多的话可以带个小测试团队，，当然这样的话也不有高工资了。

[ 本帖最后由 luckflying 于 2009-6-3 14:40 编辑 ]

作者: lotuis 时间: 2009-6-3 13:01
偏颇了luckflying同学，你的高度决定了你的眼界。。

技术不行的人总是忽略技术，认为技术算什么？对于他们来说，技术不过是毕业生才关注的东西，所以总把自己定位到管理一级。

国外优等生学文科经济管理等，不入流的才跑到理工科深造，你从哪得到这个结论的？一个例子，因为每个开发工具的发布都不是全球统一的，国内软件人才与外国的技术上根本不站在同一起跑线，所谓中国没有MS，IBM，Oracle，SAP这样的企业。语言差异是鸿沟，教育落后是洪水。

你不奇怪吗？什么时候有同样的平台，同样聪明的群体了？除了参加所谓的竞赛？其他几乎颗粒无收。

你要是来我这里应聘，你的简历直接就被自动过滤了，连苦力都干不了，更谈不上高工资了。

作者: tnt277 时间: 2009-6-3 13:06
这个楼主明显毕业没多久，属于顺风顺水的牛B人士啊

作者: Zee 时间: 2009-6-3 14:05
唉。众口难调。

这是在那个帖子回的，也放到这儿来吧。

本来不想回这个帖子。但在群里刚有人觉得我应该回一下这个帖子。所以我还是回一下吧。

褒贬，我都不想反驳。因为人都有自己的角度。就像楼上说的一样：你的眼界决定了你的高度（小改一下，群里人的建议）。
这个文章，我想了大概有一周的时间才开始写的。因为我知道它会引起一些人正面或者负面的看法。不过这些，我都不关注。
其实刚开始的时候，我还写了一句话就是：对本文正面和负面的评价，我都不接受。后来删掉了。
楼上的思维，如果再转一个圈，我想也许可能明白我想表达的到底是什么意思。
并且这个文章写的是给谁看的，谁看了会受益。谁看了会反感。谁看了会反驳，谁看了会赞同。我都有考虑过。
我从文章一开始就说明了我要表达的观点和角度。而这些观点和我所写本文写站的角度直接影响了，我本人对此文的定位。
如果楼上看明白我这句话，也许能明白一些。

曾有人告诉我这个文章不要发，我还是要发出来表达自己的观点。

PS: 最后一句话，有点人身攻击的味道。不过我并不想反驳，我现在值多少钱，只要我的manager知道即可。

作者: shanxi 时间: 2009-6-3 14:18
标题: 回复 1# 的帖子
现实确实是测试在国内许多公司仍然不受重视。

即使在MS IBM GOOGLE这样的大公司，测试架构师的职位基本上不会从资深测试人员中应聘，而是资深开发人员中寻找！

面对现实好好接受，楼主不会代表着培训机构的利益吧？

作者: luckflying 时间: 2009-6-3 14:28
标题: 回复 2# 的帖子
难道技术的反面就是管理？在你眼中管理就是管几个人头？

就拿测试来说，会几种语言和测试工具，只能是对低水平测试执行人员的要求。随便问你几个“管理类”的小问题：
test case/plan/scenario的开发策略？
如何组织上面的三者连同test result/test script的关系？
在频繁变更下如何维护之间关系？
多次测试跌代情况下呢？
如何通过配置管理来控制并行测试，以及怎样通过多流优化bug分析？
你组织过DP吗，以及如果通过之预防bug？
....

作test，眼界看开点，上面问题不过九牛一毛了，纯是技术上，相信吧，成熟的测试人员待遇一点不会差。。。

作者: luckflying 时间: 2009-6-3 14:31
标题: 回复 4# 的帖子
如果有人身攻击之嫌，那么抱歉了。。

作者: shanxi 时间: 2009-6-3 14:39
标题: 回复 6# 的帖子
luckflying 确定仅仅凭借你自己的管理经验（这里假如技术能力不太好）能应聘到MS IBM GOOGLE的管理职位吗？
我的经验是如果你以前的工作背景不过硬，你连面试的机会都不会有。

如果你的眼界只局限于二流的企业，那就当我白说了吧。

作者: luckflying 时间: 2009-6-3 14:42
标题: 回复 8# 的帖子
你认为6#提到的都是管理经验吗？我不这么认为。

作者: tnt277 时间: 2009-6-3 14:56
正文：

有几个文章大概的题目如：
软件测试行业缺口多少多少万、
软件测试人员比博士还值钱、
软件测试越老越吃香、
软件测试是金饭碗、
等等等等。

如果你认同上面几个问题的话，那你来错地方呢，

作者: lotuis 时间: 2009-6-3 14:57

原帖由 luckflying 于 2009-6-3 14:28 发表
难道技术的反面就是管理？在你眼中管理就是管几个人头？

就拿测试来说，会几种语言和测试工具，只能是对低水平测试执行人员的要求。随便问你几个“管理类”的小问题：
test case/plan/scenario的开发策略？
如何 ...

除了技术和管理，你倒是给个发展路径看看？

你所列的问题早在若干年前面试EMC的QA职位的时候就见识过，我不认为这算什么技术方面的题，纯属理论问题。我也问你一个，你知道如何利用马尔科夫决策模型优化测试用例分布吗？

最后那句，你是摆资历吗？别的我不肯定，但是我肯定一个成熟的Tester不会如你这样偏激。

作者: luckflying 时间: 2009-6-3 15:24

原帖由 lotuis 于 2009-6-3 14:57 发表

除了技术和管理，你倒是给个发展路径看看？

你所列的问题早在若干年前面试EMC的QA职位的时候就见识过，我不认为这算什么技术方面的题，纯属理论问题。我也问你一个，你知道如何利用马尔科夫决策模型优化测试用例 ...

“纯理论问题”？？你干没干过测试？搞笑！

一个真实的例子：某个项目测试用例在5000左右，测试迭代15次，有n多的测试脚本。每次执行都会有对应测试result，并且可能会有defect。这是一个实际存在的复杂的网！
现实的问题：每当有新的CR，或者enhancemant来了后，如何去调整这个复杂的大网？如果回朔到某个指定迭代的环节？如何对开发人员提供bug分析的支持？

难道这都是理论？？

作者: lotuis 时间: 2009-6-3 15:36

原帖由 luckflying 于 2009-6-3 15:24 发表

“纯理论问题”？？你干没干过测试？搞笑！

一个真实的例子：某个项目测试用例在5000左右，测试迭代15次，有n多的测试脚本。每次执行都会有对应测试result，并且可能会有defect。这是一个实际存在的复杂的网！
...

嗯哼，你的问题正好是马尔科夫决策模型，defect的不确定性你怎么衡量？这还不算理论问题啊？

[ 本帖最后由 lotuis 于 2009-6-3 15:39 编辑 ]

作者: luckflying 时间: 2009-6-3 15:45
谈叉了，我谈的问题不是在趋势分析上，而是复杂环境下的变更控制。

作者: claude 时间: 2009-6-3 15:47
开眼界了，我只知道马尔代夫.

开个玩笑，各位牛人你们继续，我这儿拿个小本正学习呢......

作者: lotuis 时间: 2009-6-3 15:53

原帖由 luckflying 于 2009-6-3 15:45 发表
谈叉了，我谈的问题不是在趋势分析上，而是复杂环境下的变更控制。

俺理论很差，俺只知道，有CR之后，在有改动的地方修改case，其他地方保持不变即可。。。你给个高级点的方法？俺觉得你说了半天的问题，都是废话。。。

作者: lotuis 时间: 2009-6-3 15:54

原帖由 claude 于 2009-6-3 15:47 发表
开眼界了，我只知道马尔代夫.

开个玩笑，各位牛人你们继续，我这儿拿个小本正学习呢......

测试相关的论文里多得是所谓的理论型文章，一堆公式，就是公式的左边有很多根本就没法衡量的变量。。。

作者: 板砖 时间: 2009-6-3 15:58
看了三遍还不知道楼上的都在讨论啥

好象是在非常牛B的公司做非常牛B的软件,然后用装B的方法讨论牛B的理论.
观看者继续用仰视的目光,看着据说牛B的人物!

作者: luffy2095 时间: 2009-6-3 16:01
我是属于看热闹不怕事大的，老实说支持Zee的同学确实没看懂楼主的意思，所谓的《驳--虚假繁荣》并非是说明支持测试繁荣；而且，确实是你的高度决定你的眼界，呵呵。
Zee的文章写的很平实，面面俱到，但确实也没说出啥，n个不痛不痒的观点，连回复都那么四平八稳；
luckflying的言论很犀利，我喜欢旗帜鲜明。

作者: lotuis 时间: 2009-6-3 16:05

原帖由板砖于 2009-6-3 15:58 发表
看了三遍还不知道楼上的都在讨论啥
好象是在非常牛B的公司做非常牛B的软件,然后用装B的方法讨论牛B的理论.
观看者继续用仰视的目光,看着据说牛B的人物!

俺也不知道LZ在说啥。。。俺们本来觉得测试行业不咋的，人家非要觉得测试行业很牛B。。。

作者: luckflying 时间: 2009-6-3 16:06
标题: 回复 16# 的帖子
“俺只知道，有CR之后，在有改动的地方修改case”
---说眼界决定高度，没委屈你。

反问你：
例如第5次迭代前引入CR，在该迭代测试发现第二次迭代的defect又出现了（怎么发现的你自己想），难道你不需要知道每次迭代引入的变化（变化包括需求，script，case,result,defect and relationship of them）？如果需要再现迭代2的测试用例条件，你怎么实现呢？

因为你就记录个改动的CR，剩下的一切凭脑子或者牛人吧，是吗？

作者: lotuis 时间: 2009-6-3 16:09

原帖由 luffy2095 于 2009-6-3 16:01 发表
我是属于看热闹不怕事大的，老实说支持Zee的同学确实没看懂楼主的意思，所谓的《驳--虚假繁荣》并非是说明支持测试繁荣；而且，确实是你的高度决定你的眼界，呵呵。
Zee的文章写的很平实，面面俱到，但确实也没说出 ...

我太佩服你的理解能力了。。。
LZ的帖子有意思吗？在天朝以外生活多长时间了？居然就得出洋人不是好学生才学理工科这个结论的？国内与国外技术同步吗？

标题挺大，说了半天，什么也没反驳。

我倒是觉得你是因为反对Zee的观点，所以选择支持LZ。

作者: lotuis 时间: 2009-6-3 16:18

原帖由 luckflying 于 2009-6-3 16:06 发表
“俺只知道，有CR之后，在有改动的地方修改case”
---说眼界决定高度，没委屈你。

反问你：
例如第5次迭代前引入CR，在该迭代测试发现第二次迭代的defect又出现了（怎么发现的你自己想），难道你不需要知道每次 ...

本人所经历的公司一概用CR来表示新的feature或者修改已有的feature，不知你的CR是否与我理解的是一回事。

你的反问我看来就是先前的bug在产品变化之后又Repro了，这不就是典型的Regression Bug吗？这还有什么好说的？既然你都说了是之前的bug又重现了（你确定是之前bug的重现，而不是新bug），这还要回退到bug先前出现的环境下进行测试有什么意义？你多半不知道测试也有debug一说吧？

[ 本帖最后由 lotuis 于 2009-6-3 16:37 编辑 ]

作者: luckflying 时间: 2009-6-3 16:36
标题: 回复 23# 的帖子
我们不在一个体系上，谈不到一起。谈完后，就此结贴不在回复该CR问题。

简单说一下现有方案：
首先就是对测试点的控制，通过某些工具，以及项目police，把测试相关的需求/计划/用例/结果/defect等等编织起来。而不会仅记录个测试用例。
在此基础上进行基线化管理（怎么控制基线，恢复基线，权限以及流程控制在此不谈了）。

对于每次迭代的测试对象实行多分支控制，并映射到上述基线。

当CR来了，要做影响分析并升级基线，新的迭代中控制变更范围，控制源代码版本，并适时引入基线对比；

稳定后，提升基线，对新的测试对象进行测试
。。。

谈了我们的测试流程，这样的好处：
可以对测试每个环节做到精确控制；
领导拿到准确量化的报告；
开发人员更容易的作bug分析
对个人绩效的控制以数字为标准
。。。。

另开贴讨论之：
http://bbs.51testing.com/viewthr ... &extra=page%3D1

[ 本帖最后由 luckflying 于 2009-6-5 15:24 编辑 ]

作者: shanxi 时间: 2009-6-3 16:45
标题: 回复 24# 的帖子
你通篇说的都是管理流程
可以看出你们所做的测试工作对技术能力的要求不高所以技术在你眼里就是0

如果有一天你想去的一家对测试的技术能力要求高而这家公司又是全球顶尖的公司那你就完蛋了希望我说的情况你永远别碰到阿门

作者: luckflying 时间: 2009-6-3 16:47
不要断章取义，前面是为了驳斥“仅记录个测试用例”才谈到如何组织测试。。

作者: shanxi 时间: 2009-6-3 16:52

原帖由 luckflying 于 2009-6-3 16:47 发表
不要断章取义，前面是为了驳斥“仅记录个测试用例”才谈到如何组织测试。。

那前面那人问除了技术和管理你这里通篇说的又是哪块呢？

跟你这种人说话简直是浪费口舌。

作者: lotuis 时间: 2009-6-3 16:54

原帖由 luckflying 于 2009-6-3 16:47 发表
不要断章取义，前面是为了驳斥“仅记录个测试用例”才谈到如何组织测试。。

这需要断章取义吗？你谈到什么技术细节了？除了管理理论之外，你还谈了什么？你自己翻页回去看看。

Regression Bug居然需要回退到原始环境去确认，这是什么先进方法？你不知道debug吗？或者你们根本就是纯黑盒测试？

还组织测试呢，哪里改动，自然修改哪里的case，你扯到文档之类纯属找茬，文档先行你不知道吗？你听说过Regression Testing吗？

作者: 我是别人的马甲 时间: 2009-6-3 17:06
我喜欢看吵架。哈哈

作者: radsofia 时间: 2009-6-4 07:50
这个lz挺有想法的，但是觉得有点涉世未深的样子，貌似工作没有几年。。。
测试现在在国内的发展是个什么情况，相信大家都心知肚明，面对现实吧。

作者: xiaoyaoke 时间: 2009-6-4 09:54
非常佩服luckflying的见地

作者: 欧阳 时间: 2009-6-4 10:12

我是小辈，现在还是不清楚状况，

作者: 欧阳 时间: 2009-6-4 10:13
国内测试缺口是有，不过估计都是初级测试缺口，高级的还没重视起来。估计国内一般企业还养不起，也没几家国内企业有这个需求。

作者: luckflying 时间: 2009-6-4 10:46

原帖由 radsofia 于 2009-6-4 07:50 发表
这个lz挺有想法的，但是觉得有点涉世未深的样子，貌似工作没有几年。。。
测试现在在国内的发展是个什么情况，相信大家都心知肚明，面对现实吧。

不止一个人说我没工作几年，呵呵，你们怎么得出的结论？

作者: xiaoyaoke 时间: 2009-6-4 11:59
标题: 回复 34# 的帖子
相反，我觉得你工作很久了，能有你这种体会绝不会是刚开始工作的人能体会到的，顶你

作者: heqingbluesky 时间: 2009-6-4 13:08
就这句话“国外优等生学文科经济管理等，二流的才跑到理工科深造，你考虑过为什么吗？举一个例子，每个开发工具的发布都是全球统一的，所以国内软件人才与外国的技术上站在同一起跑线，但为什么MS,IBM,Oracal,SAP...全部是国外的，国内像样的产品有吗？
你不奇怪吗？同样的平台，同样聪明的群体，那么几乎颗粒无收的我们究竟缺在那里？
”

我发表一下个人看法，我们目前缺乏顶尖的公司，顶尖的人才，最主要的问题是－整个社会都是急功近利，有多少个人能够静下心来学东西，静下心来思考。
个个都想做销售，来钱快，人脉广。

作者: luckflying 时间: 2009-6-4 13:36
标题: 回复 36# 的帖子
很喜欢你的参与，这是我帖子的初衷。从文化上谈谈吧：
从文化上讲，我们始终没有建立一个制度性的社会，如今看看邓玉娇案，就知道法律的脆弱，，如果连法律都做不到制度化，怎么能摒弃人治了呢？

我们可以在小范围的把工作做好，但如果让1000人，同时做一件事情/产品开发，我们的软件企业能行吗？2000人呢？而这些在很多外企中都很平常，我们缺少什么呢？

其实西方人非常重视制度，他们花了大量的精力去研究和完善之。拿我们公司来讲，它有甚比CMM5严格的一套体系，当然都是最精英的人研究这些了。而公司的上上下下都非常“自觉地”在该体系中完成自己的工作。
自觉来自哪里？
1）文化上的，大家把这些规范当作了圣经，如果谁违反，他在各个角度都很被动（怎么听着像前规则了），，这个或许就是我们常说的企业文化吧。
2）聪明人设计的制度，总不会忘记监督和制约，你偏要当个软件英雄或者瞎指挥，就会发现有各种制衡你的地方。

老马说过生产关系决定生产力，内因来讲，在公司里创建了良好的制度架构，该制度并保证文化的实施，那么就可以获得高的生产力。

作者: lotuis 时间: 2009-6-4 14:09

原帖由 luckflying 于 2009-6-4 13:36 发表
很喜欢你的参与，这是我帖子的初衷。从文化上谈谈吧：
从文化上讲，我们始终没有建立一个制度性的社会，如今看看邓玉娇案，就知道法律的脆弱，，如果连法律都做不到制度化，怎么能摒弃人治了呢？

我们可以在小范 ...

邓玉娇案不是法律问题，而是法治问题。

请你找个一个项目有超过1000人一起做的例子来看看，不要自己想当然，即便是MSFT和Google，也没有一个项目千人共同研发的。

马克思从来没有说过“生产关系决定生产力”，即便是天朝的教材也明确写着“生产力决定生产关系，生产关系反作用于生产力”。

我现在算明白你为什么要反驳了，你这样的思维居然都能在外企混得开，还是测试的管理岗位，还有什么理由怀疑测试行业不繁荣啊？！

作者: 夭夭旭 时间: 2009-6-6 13:01
恩。。。看着大家的讨论，真的很困惑。之前的《虚假繁荣》偶也看过。是不是不管什么工作只要做久了，都会有腻烦心里啊？是不是了解的越深就越愤恨，越想脱离啊？像我这种即将毕业，还没工作的测试菜鸟现在还理解不了大虾们的想法。

作者: 愚人 时间: 2009-6-7 00:10
现在有两个个事实，一是管理岗位远远少于技术岗位，二是管理岗位由于技术岗位是中国特有的现象，
现在都成了恶性循环了

作者: chech28 时间: 2009-6-8 00:08

原帖由 shanxi 于 2009-6-3 14:39 发表
luckflying 确定仅仅凭借你自己的管理经验（这里假如技术能力不太好）能应聘到MS IBM GOOGLE的管理职位吗？
我的经验是如果你以前的工作背景不过硬，你连面试的机会都不会有。

如果你的眼界只局限于二流的企业 ...

路过插一句，这个倒不要说的那么绝对哈，我认识两个人，一个是MS的Lead SDE,一个是CA的QA Director.

作者: shanxi 时间: 2009-6-8 11:17

原帖由 chech28 于 2009-6-8 00:08 发表

路过插一句，这个倒不要说的那么绝对哈，我认识两个人，一个是MS的Lead SDE,一个是CA的QA Director.

不知道你指我说的哪块：
是技术能力不行
还是工作背景不丰富？

CA这公司就不说了，这公司招人很不规范。有个case，在CA做leader的跳去微软做的普通员工。
微软是有些以Vendor身份进入了FTE的行列，一般这种情况的面试，对技术方面面的轮数和要求都比较低。

[ 本帖最后由 shanxi 于 2009-6-8 11:22 编辑 ]

作者: luckflying 时间: 2009-6-8 12:03

原帖由 shanxi 于 2009-6-8 11:17 发表

不知道你指我说的哪块：
是技术能力不行
还是工作背景不丰富？

CA这公司就不说了，这公司招人很不规范。有个case，在CA做leader的跳去微软做的普通员工。
微软是有些以Vendor身份进入了FTE的行列，一般这种 ...

这位老兄观点是不是必须有技术背景，才能做好管理？
为方便讨论，管理分成两类，一个是技术上的，比如前面我提到数千的case，复杂的对象关系网络，怎么组织和控制。
此兄好像对管理的理解偏重于当“领导”。可以这样说，做这类的人，没有技术背景完全可以！对他们的要求是PMP的认证，CMMI的知识。。等等。我见到过很多成功的项目，他们的经理没有什么相关项目背景！（比如一个带过java的经理，去带一个SAP的项目，他一样做的非常好）

作者: bonniey 时间: 2009-6-8 12:03
顶Lotuis
lz做咨询挺好的，理论一套套的，忽悠人很行
但没必要因为自己会讲点管理理论就bs做技术的，这里不是你待的地儿，哪来回哪去吧

作者: shanxi 时间: 2009-6-8 12:04

原帖由 luckflying 于 2009-6-8 12:03 发表

这位老兄观点是不是必须有技术背景，才能做好管理？
为方便讨论，管理分成两类，一个是技术上的，比如前面我提到数千的case，复杂的对象关系网络，怎么组织和控制。
此兄好像对管理的理解偏重于当“领导”。可 ...

我没有问你。我说过不会再跟你就这问题对话说任何问题。

作者: bonniey 时间: 2009-6-8 12:07
另外还有一个

就这句话“国外优等生学文科经济管理等，二流的才跑到理工科深造，你考虑过为什么吗？举一个例子，每个开发工具的发布都是全球统一的，所以国内软件人才与外国的技术上站在同一起跑线，但为什么MS,IBM,Oracal,SAP...全部是国外的，国内像样的产品有吗？
你不奇怪吗？同样的平台，同样聪明的群体，那么几乎颗粒无收的我们究竟缺在那里？
”
我觉得很奇怪哎，lz既然觉得二流的去理工科深造，哎哟，这些二流的竟然还能做出什么ms啊ibm啊等等牛的东西
为什么国内的没有呢，哎哟，看来国内的牛人还不如人家国外的二流呢
lz是这个意思吧

作者: kuangquanshui 时间: 2009-6-8 12:19
说的都没有用大家还是努力工作吧做出来证明自己的理论求同存异

作者: 鹭岛 时间: 2009-6-8 12:29
搞技术的就是民工
不搞技术的才有可能是吃香喝辣的~~~
测试在我看来也是极其没前途的行业。。。明年打算转行（我已经做了4年测试了）

作者: 欺负人 时间: 2009-6-8 12:49
萝卜白菜，各有所爱！！

作者: kakamissyou 时间: 2009-6-8 12:54
标题: 回复 39# 的帖子
这正是楼主在这里据理力争的原因。

为了不把一些刚入门的同学造成影响啊，哈！

看来事实上，楼主还是占下风。

作者: 南拳王 时间: 2009-6-8 12:59
来了解下情况！！！

作者: hawkhao 时间: 2009-6-8 16:22
技术也好，理论也好，都应该是为了实际的项目来服务的，而实际上在绝大数的项目中，所谓的测试模型其实根本上就用不着。那些个技术基本上只有在大型项目的而且是以迭代模式开发的项目中才可能有这种需求。在绝大数的公司所处理的项目基本上都是出于中小型的，只要坚持公司所预设的流程，问题基本上都能解决掉的。脱离了实际项目去讨论理论是没有太多的实际意义，除非我们是做理论方面的研究，期待着咱们中国也能出先在软件测试理论方面的牛人。哈哈！

作者: shamoyizhihu 时间: 2009-10-19 11:24
标题: 支持zee
呵呵来评论的都是太阳啊，传说中的牛人，我工作时间不长，越来越感觉zee说的是对的，也感觉相见这篇文章恨晚的感觉，楼上各位的资历已经看不到现在毕业生的处境，爬上去的人也不会关心一直处于低谷的同志，这都是正常的，以zee三年的经验，写出很多好文章不是什么人都能做到的，这份精神也不是各位能够评头论足的。
我在经常7dtest里逛，也在zee的群里问问题，公共的平台，很受欢迎。
不要以各位的成功来看如今的所有，我想更多的人还是在学习中努力中。

作者: zhangting85 时间: 2009-10-19 22:25
看了半天了没看明白，我看不明白充分说明了一个问题，就是楼主在装B啊。楼主你到底想说什么就直接开个贴说清楚，连我都看不明白，我相信根本没人看得明白。皇帝的新衣不要拿出来现了，搞点人民大众都看得懂的东西！

你们到底在争什么？？？

作者: yabest 时间: 2009-10-21 18:42

原帖由 zhangting85 于 2009-10-19 22:25 发表
看了半天了没看明白，我看不明白充分说明了一个问题，就是楼主在装B啊。楼主你到底想说什么就直接开个贴说清楚，连我都看不明白，我相信根本没人看得明白。皇帝的新衣不要拿出来现了，搞点人民大众都看得懂的东西！
...

我来给你翻译一下吧！

Zee说：没有多年的技术积累，是做不好测试的。
LZ说：没有严格复杂的测试流程，是做不好测试的。

本来各说各话，都有道理，可以相安无事的。这些道理其实大家都懂。

可LZ话里夹了些不该有的话：
“技术算个P，流程才是最重要的”
“Zee的眼界高度太低了，只懂技术不懂流程。这样的人到他那有牛B流程的牛B公司，只能做个低层次的测试执行人员”

然后就吵起来了！

[ 本帖最后由 yabest 于 2009-10-21 18:51 编辑 ]

作者: black_tulip 时间: 2009-10-21 19:42

原帖由 lotuis 于 2009-6-4 14:09 发表
邓玉娇案不是法律问题，而是法治问题。

请你找个一个项目有超过1000人一起做的例子来看看，不要自己想当然，即便是MSFT和Google，也没有一个项目千人共同研发的。

马克思从来没有说过“生产关系决定生产力”，即便是天朝的教材也明确写着“生产力决定生产关系，生产关系反作用于生产力”。

我现在算明白你为什么要反驳了，你这样的思维居然都能在外企混得开，还是测试的管理岗位，还有什么理由怀疑测试行业不繁荣啊？！

顶这个。

楼主说：“国外优等生学文科经济管理等，二流的才跑到理工科深造，你考虑过为什么吗？”

我不知道为什么，我也不相信这个结论，因为我不相信一流的人弄出了那么大的危机，破产倒闭，失业自杀，而二流的继续在科技领域为人类造福。

从我不认同这句话开始，看到6楼楼主向2楼开炮，问出6、7个问题，我只能觉得，楼主像个小孩，哪怕他有点年纪，工作很多年，可是脾气性格还是像个小孩。或者，就是个小孩。

2楼很老实，楼主问了，就回答了，于是楼主大有机会冒出一堆一堆的名词动词。阵势很大，其实呢，有几个回帖好像也说了，楼主啥都没讲。

2楼的这个（在38楼）反驳很精彩，精彩得楼主选择性跳过不看。

最后，55楼翻译得也很好。看完到55楼，对楼主的印象很差，希望以后的帖子能改变印象。

作者: zhangting85 时间: 2009-10-25 11:51
标题: 回复 55# 的帖子
Thanks！

作者: freedom_me 时间: 2010-1-4 16:40

起码增进了认识,辩、驳带来了很多思想哦！求同存异..

[ 本帖最后由 freedom_me 于 2010-7-1 17:06 编辑 ]

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)