回复 16# 的帖子
“俺只知道，有CR之后，在有改动的地方修改case”---说眼界决定高度，没委屈你。
反问你：
例如第5次迭代前引入CR，在该迭代测试发现第二次迭代的defect又出现了（怎么发现的你自己想），难道你不需要知道每次迭代引入的变化（变化包括需求，script，case,result,defect and relationship of them）？如果需要再现迭代2的测试用例条件，你怎么实现呢？
因为你就记录个改动的CR，剩下的一切凭脑子或者牛人吧，是吗？ 原帖由 luffy2095 于 2009-6-3 16:01 发表 http://bbs.51testing.com/images/common/back.gif
我是属于看热闹不怕事大的，老实说支持Zee的同学确实没看懂楼主的意思，所谓的《驳--虚假繁荣》并非是说明支持测试繁荣；而且，确实是你的高度决定你的眼界，呵呵。
Zee的文章写的很平实，面面俱到，但确实也没说出 ...
我太佩服你的理解能力了。。。
LZ的帖子有意思吗？在天朝以外生活多长时间了？居然就得出洋人不是好学生才学理工科这个结论的？国内与国外技术同步吗？
标题挺大，说了半天，什么也没反驳。
我倒是觉得你是因为反对Zee的观点，所以选择支持LZ。 原帖由 luckflying 于 2009-6-3 16:06 发表 http://bbs.51testing.com/images/common/back.gif
“俺只知道，有CR之后，在有改动的地方修改case”
---说眼界决定高度，没委屈你。
反问你：
例如第5次迭代前引入CR，在该迭代测试发现第二次迭代的defect又出现了（怎么发现的你自己想），难道你不需要知道每次 ...
本人所经历的公司一概用CR来表示新的feature或者修改已有的feature，不知你的CR是否与我理解的是一回事。
你的反问我看来就是先前的bug在产品变化之后又Repro了，这不就是典型的Regression Bug吗？这还有什么好说的？既然你都说了是之前的bug又重现了（你确定是之前bug的重现，而不是新bug），这还要回退到bug先前出现的环境下进行测试有什么意义？你多半不知道测试也有debug一说吧？
[ 本帖最后由 lotuis 于 2009-6-3 16:37 编辑 ]
回复 23# 的帖子
我们不在一个体系上，谈不到一起。谈完后，就此结贴不在回复该CR问题。简单说一下现有方案：
首先就是对测试点的控制，通过某些工具，以及项目police，把测试相关的需求/计划/用例/结果/defect等等编织起来。而不会仅记录个测试用例。
在此基础上进行基线化管理（怎么控制基线，恢复基线，权限以及流程控制在此不谈了）。
对于每次迭代的测试对象实行多分支控制，并映射到上述基线。
当CR来了，要做影响分析并升级基线，新的迭代中控制变更范围，控制源代码版本，并适时引入基线对比；
稳定后，提升基线，对新的测试对象进行测试
。。。
谈了我们的测试流程，这样的好处：
可以对测试每个环节做到精确控制；
领导拿到准确量化的报告；
开发人员更容易的作bug分析
对个人绩效的控制以数字为标准
。。。。
另开贴讨论之：
http://bbs.51testing.com/viewthread.php?tid=151441&pid=1244130&page=1&extra=page%3D1
[ 本帖最后由 luckflying 于 2009-6-5 15:24 编辑 ]
回复 24# 的帖子
你通篇说的 都是管理流程可以看出你们所做的测试工作对技术能力的要求不高 所以技术在你眼里就是0
如果有一天 你想去的一家对测试的技术能力要求高 而这家公司又是全球顶尖的公司 那你就完蛋了 希望我说的情况你永远别碰到 阿门 不要断章取义，前面是为了驳斥“仅记录个测试用例”才谈到如何组织测试。。 原帖由 luckflying 于 2009-6-3 16:47 发表 http://bbs.51testing.com/images/common/back.gif
不要断章取义，前面是为了驳斥“仅记录个测试用例”才谈到如何组织测试。。
那前面那人问除了技术和管理 你这里通篇说的又是哪块呢？
跟你这种人说话简直是浪费口舌。 原帖由 luckflying 于 2009-6-3 16:47 发表 http://bbs.51testing.com/images/common/back.gif
不要断章取义，前面是为了驳斥“仅记录个测试用例”才谈到如何组织测试。。
这需要断章取义吗？你谈到什么技术细节了？除了管理理论之外，你还谈了什么？你自己翻页回去看看。
Regression Bug居然需要回退到原始环境去确认，这是什么先进方法？你不知道debug吗？或者你们根本就是纯黑盒测试？
还组织测试呢，哪里改动，自然修改哪里的case，你扯到文档之类纯属找茬，文档先行你不知道吗？你听说过Regression Testing吗？ 我喜欢看吵架。哈哈 这个lz挺有想法的，但是觉得有点涉世未深的样子，貌似工作没有几年。。。
测试现在在国内的发展是个什么情况，相信大家都心知肚明，面对现实吧。 非常佩服luckflying的见地 :lol 我是小辈，现在还是不清楚状况， 国内测试缺口是有，不过估计都是初级测试缺口，高级的还没重视起来。估计国内一般企业还养不起，也没几家国内企业有这个需求。 原帖由 radsofia 于 2009-6-4 07:50 发表 http://bbs.51testing.com/images/common/back.gif
这个lz挺有想法的，但是觉得有点涉世未深的样子，貌似工作没有几年。。。
测试现在在国内的发展是个什么情况，相信大家都心知肚明，面对现实吧。
不止一个人说我没工作几年，呵呵，你们怎么得出的结论？
回复 34# 的帖子
相反，我觉得你工作很久了，能有你这种体会绝不会是刚开始工作的人能体会到的，顶你 就这句话“国外优等生学文科经济管理等，二流的才跑到理工科深造，你考虑过为什么吗？举一个例子，每个开发工具的发布都是全球统一的，所以国内软件人才与外国的技术上站在同一起跑线，但为什么MS,IBM,Oracal,SAP...全部是国外的，国内像样的产品有吗？你不奇怪吗？同样的平台，同样聪明的群体，那么几乎颗粒无收的我们究竟缺在那里？
”
我发表一下个人看法，我们目前缺乏顶尖的公司，顶尖的人才，最主要的问题是－整个社会都是急功近利，有多少个人能够静下心来学东西，静下心来思考。
个个都想做销售，来钱快，人脉广。
回复 36# 的帖子
很喜欢你的参与，这是我帖子的初衷。从文化上谈谈吧：从文化上讲，我们始终没有建立一个制度性的社会，如今看看邓玉娇案，就知道法律的脆弱，，如果连法律都做不到制度化，怎么能摒弃人治了呢？
我们可以在小范围的把工作做好，但如果让1000人，同时做一件事情/产品开发，我们的软件企业能行吗？2000人呢？而这些在很多外企中都很平常，我们缺少什么呢？
其实西方人非常重视制度，他们花了大量的精力去研究和完善之。拿我们公司来讲，它有甚比CMM5严格的一套体系，当然都是最精英的人研究这些了。而公司的上上下下都非常“自觉地”在该体系中完成自己的工作。
自觉来自哪里？
1）文化上的，大家把这些规范当作了圣经，如果谁违反，他在各个角度都很被动（怎么听着像前规则了），，这个或许就是我们常说的企业文化吧。
2）聪明人设计的制度，总不会忘记监督和制约，你偏要当个软件英雄或者瞎指挥，就会发现有各种制衡你的地方。
老马说过生产关系决定生产力，内因来讲，在公司里创建了良好的制度架构，该制度并保证文化的实施，那么就可以获得高的生产力。 原帖由 luckflying 于 2009-6-4 13:36 发表 http://bbs.51testing.com/images/common/back.gif
很喜欢你的参与，这是我帖子的初衷。从文化上谈谈吧：
从文化上讲，我们始终没有建立一个制度性的社会，如今看看邓玉娇案，就知道法律的脆弱，，如果连法律都做不到制度化，怎么能摒弃人治了呢？
我们可以在小范 ...
邓玉娇案不是法律问题，而是法治问题。
请你找个一个项目有超过1000人一起做的例子来看看，不要自己想当然，即便是MSFT和Google，也没有一个项目千人共同研发的。
马克思从来没有说过“生产关系决定生产力”，即便是天朝的教材也明确写着“生产力决定生产关系，生产关系反作用于生产力”。
我现在算明白你为什么要反驳了，你这样的思维居然都能在外企混得开，还是测试的管理岗位，还有什么理由怀疑测试行业不繁荣啊？！ 恩。。。看着大家的讨论，真的很困惑。之前的《虚假繁荣》偶也看过。是不是不管什么工作只要做久了，都会有腻烦心里啊？是不是了解的越深就越愤恨，越想脱离啊？像我这种即将毕业，还没工作的测试菜鸟现在还理解不了大虾们的想法。:L 现在有两个个事实，一是管理岗位远远少于技术岗位，二是管理岗位由于技术岗位是中国特有的现象，
现在都成了恶性循环了
