FDD开发模式强调的就是测试，只能说更加强和规范化测试了，要 ...
tiandijiaolong 发表于 2010-9-26 14:17 http://bbs.51testing.com/images/common/back.gif
测试是由开发来做还是测试来做呢？我最近和Google的开发也聊了一下，他说他做过两个项目，第一个项目是5：1的开发测试比例，第二个项目也是目前正在进行的没有测试人员。他们的Unit Test搞定。 我最近也跟Google的测试打了一下交道。我问他Google测试的工作是怎么进行的，和开发的关系是什么。他说Google的测试其实还是software engineer, 是write code to test code。（我心里一乐，这话忽悠不了我，写test code和product code可不是一回事）。我说你们测试需要进行product code的code review 和debugging吗？他犹豫的回答，你可以这样做，可是你也可以直接报bug了。（我一听就知道他们对测试的要求明显要低了，写test automation也不过是entry level的要求呀，有什么吹的？） 问亚马逊的时候，他们不敢回答开发和测试的比例问题。然后说开发人员需要进行大量的Unit Test, 测试人员主要是integration test。我一听，完了，测试的技术含量也高不了哪去了。
微软Bing对测试还是比较重视，比例基本是2：1，还给我解释这个比例比较低。我说不低了，跟其他互联网公司比起来。然后我问，你们这个比例能测完所有的工作吗？他们说肯定不可能，所以他们要决定什么需要测试，什么不需要测试，什么要让开发人员来测，比如code coverage就让开发来做，他们不管。我一听，这么大工作量，哪来的时间去研究和改善自己的测试技术呢？
所以呀，真正重视测试的还是传统软件的开发流程。以后传统软件越来越少了，测试的地位也不容乐观。（在很多传统的软件项目中，测试和开发的人员属于平等的地位和1：1的比例） 测试行业前途确实每况愈下！
只有测试培训机构还在大肆鼓吹，以谋求最后的利润！ 其实最终是对测试的理解不一样…… 其实最终是对测试的理解不一样……
愚人 发表于 2010-9-27 11:20 http://bbs.51testing.com/images/common/back.gif
嗯。所以需要交流。 是不是可以从更高的角度来考虑，从而能挖掘出测试尽可能大的价值。
1、软件企业不管是传统的还是互联的，归根到底都是要实现商业上的价值，我的理解有三个方面很重要：成本、质量、速度，这三者需要根据实际情况来进行平衡。
2、质量则与三个要素相关：组织、流程、技术，这三者之间也需要相互协调。
3、通过组织、流程和技术的合理选用，来实现成本、质量、速度的平衡，从而实现企业的商业目标。这才是我所理解的不同公司开发、测试现状背后的东西。为什么不用专门的测试，因为我的产品质量要求不高（以成本取胜）或者产品生命周期短（互联网上好些应用就是这样的，玩一段时间就好，速度才是关键）。
下面是我们作为专职测试人员可以思考的方向：
1、如何通过测试来降低成本，包括人力成本、维护成本等等？
2、如何通过测试加快产品的上市时间？
3、如何通过测试及时反馈出产品质量的信息（软件质量度量），帮助管理层更好的进行商业上的判断？
。。。
而要想解决以上的这些问题，都可以从组织、流程、技术上找到突破口。
不管IT行业如何发展，很多本质的东西都还是在的，我们测试人员能做的就是迎合这些发展，让我们测试工作的价值最大化，不能仅仅满足于设计测试用例、找bug、自动化，我们可以把我们的工作往需求方向延伸、往客户方向延伸。不管怎么变，一个人的价值是由他/她创造的价值来衡量的，这样就不怕没未来了。 如果只是简单的功能测试我觉得开发人员是可以完全替代测试人员的，但是开发和测试人员本身在思维上都不太一样的，大家关注点不同；另外测试人员也需要找到自己的核心价值，做到不可替代，有危机感还是很有必要的 回复 27# skinapi
管理员的分析很到位，如果单是从技术角度去分析的确是不够的，企业考虑更多的是利润。投入与产出 白盒测试本来就应该开发人员来做，和测试一点关系都没有，测试本来就不需要很强的编码技术含量，但测试同样要懂相对简单的脚本，数据库，以及网络相关知识和行业知识，如果让开发人员也来做ui测试，或者压力性能测试，那工作量将会是非常大的，工作量这个东西不是说写代码工作量就一定比简单的手工测试来的大了，正相反的是有时候同样功能手工测试的工作量要远远大于编码的工作量，所以让开发既做开发又做测试，这是根本不可能的事情，除非你这个项目的工期是别人的两倍，那你可以去做，不然必然导致混乱，看了lz很多帖子，无非一个观点，看不起手工测试，片面的强调编码和开发的重要性，其实我觉得你的这个思路是很有问题的，就算是简单的手工测试也是不可替代的，你这种说法会误导很多人，其实是在专牛角尖，一定要让测试人员的编码能力去和开发比，是根本没有必要的 学习下 我觉得这里不少朋友没有理解楼主的意思。
测试人员需要客观的认识到自己的问题，你的价值在哪里？需要改进那些方面？不能总是抱着自己的一些认识不放。前面一位朋友提到的通才发展，我很认同，我认为以后开发工程师和测试工程师之间的界限，会越来越模糊。所谓不再招聘测试工程师，不是这个组织不需要进行测试工作，而是不再需要传统中的那种测试工程师。大家应该考虑这个问题，你独特的优势是什么？你能为一个组织带来什么独特价值？ 一起创景下未来软件的发展 挺有意思
刚查了下敏捷开发的定义，其中提到将整个系统分为几个小项目，分别完成，在此过程中软件一直处于可使用状态。我觉得这样就给公司领导层一个假象：新功能被1-2个高级测试人员测试后，与主产品对接，让适用用户来测试，如果不理想也不会对整个产品产生很坏的影响。
说白了，还是资本家对剩余价值的追逐导致将国外一些好的研发方法变了味道。。。。。。 回复 18# 千里
‘当需要才会存在，这种存在自然合理’，说的太好了！最近也看了些相关内容，我觉得敏捷开发项目中，可以根据具体情况来决定是否要敏捷测试人员，但一旦需要，就必然有其合理性。而且我觉得大多数项目只有开发和测试并驾齐驱才能做出比较好的东西，因为毕竟开发和测试的思维方式和专攻方向是不同的。但有一点，敏捷测试对测试人员的要求提高了，甚至需要分担开发人员的部分工作，所以不是单单手工测试就可以胜任的 回复 18# 千里
‘当需要才会存在，这种存在自然合理’，说的太好了！最近也看了些相关内容，我觉得敏捷开发项目中，可以根据具体情况来决定是否要敏捷测试人员，但一旦需要，就必然有其合理性。而且我觉得大多数项目只有开发和测试并驾齐驱才能做出比较好的东西，因为毕竟开发和测试的思维方式和专攻方向是不同的。但有一点，敏捷测试对测试人员的要求提高了，甚至需要分担开发人员的部分工作，所以不是单单手工测试就可以胜任的 我所在地的 一些欧美企业 （敏捷开发模式）都正在招聘测试者。。。 cleverman 的问题总是能让人思考 敏捷对黑盒测试的需求会相对较少吧！ 回复 4# cleverman
面对个人用户的软件产品是一方便，简洁，时尚为重， 比不需要太重视错误率， 比如google, 即使偶尔出现一些错误， 比如排名错误， 对终端用户影响并不大。 但是对企业， 银行，保险，ERP, 医疗领域，电信， 交通这些领域， 小的错误带来的就是实实在在的金钱损失。所以做测试最好选定一个行业
页:
1
[2]
