大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
敏捷团队中测试人员和开发人员的合理比例？视情况而定。
作者 Chris Sims 译者 张晓庆 发布于 2009年1月6日
软件开发世界里有这样一个长期存在的问题是：测试人员和开发人员的比例多少才合理？Scrum开发列表中最近有一个帖子，询问敏捷对这个比例有什么影响。对第一个问题，答案应该“视情况而定”。对第二个问题，Elisabeth Hendrickson认为，敏捷团队能够用更少的测试人员，但是做更多的测试。
测试人员和开发人员的比例多少才合理？
许多年来，人们对研究测试人员和开发人员的“合理”比例充满了兴趣。《微软秘笈》书中指出，微软员工中测试人员和开发人员的比例是1比1。根据在某会议上非正式的调查，Randall Rice发现通常的比例是1个测试人员对3个开发人员。而Cem Kaner和Elisabeth Hendrickson发表的一篇论文认为，这样的比例毫无意义。不同的项目里这些角色被赋予的职责和任务相差甚远。举例来说，自动构建负责人应该算作开发人员还是测试人员？
除了计算问题，小组还发现，项目环境的差别使得不同项目的比较更缺乏意义。这些因素包括：
- 项目要求的可靠性
- 必须测试的可配置的范围
- 软件的易测试程度
- 工具的可用性
- 测试人员和开发人员的经验
- 必须坚持的质量标准
在这篇文章It Depends: Deciding on the Correct Ratio of Developers to Testers中，Johanna Rothman得到了类似的结论。Randall Rice在他的这篇文章The Elusive Tester to Developer Ratio中，对这个令人疑惑的比例给出了一些工业上使用的值：
需要清楚地认识到，我并不是完全怀疑在计划中使用这个比例，如果这个比例是你们自己的比例，并且基于你们的经验、技术和组织结构的话就没问题。但是如果一个组织把别人的比例拿来，不考虑到技术、流程成熟度、熟练程度的差别，直接用于自己的项目，那我就认为是一个风险。
敏捷对测试人员和开发人员的比例有什么影响呢？
在一个近期的网上直播中，Elisabeth Hendrickson和Lisa Crispin都 把敏捷环境描述成“测试的涅槃”。Elisabeth回忆了她在传统环境中的工作情况，开发小组给QA小组的软件经常是送到时就不能用（D.O.A.）， 不能安装，或者刚启动就崩溃了。而她在敏捷团队中工作时从未发生过这样的事儿。在敏捷团队里，测试人员能够创造更大的价值，他们做探索性测试、创建测试自 动化、与产品负责人紧密合作完善需求和验收条件。
Elisabeth曾见过这样的敏捷团队，运行效率很高，但测试人员对开发人员的 比例很低。这并不是说测试不重要。根据她的经验，敏捷团队需要的测试技能至少要和传统团队一样多。区别在于这些技能、以及保证质量的责任，并不仅仅取决于 称之为测试人员的少数人。整个敏捷团队都在努力提高产品的质量，与之形成对比的是，传统团队只依赖QA小组来给产品测试质量。
你的团队是怎样处理测试的职责的呢？欢迎留言分享你的经验。
查看英文原文 The Correct Ratio of Agile Testers to Developers? It Depends.
译者 张晓庆 有多年的软件开发经验，主要是J2EE项目、Web应用和分布式系统等等，在电信网管开发方面经验丰富。
reply:敏捷团队中测试人员和开发人员的合理比例？视情况而定。
发表人
Zongwang Huang
发表于
Re: reply:敏捷团队中测试人员和开发人员的合理比例？视情况而定。
发表人
张 晓庆
发表于
Re: reply:敏捷团队中测试人员和开发人员的合理比例？视情况而定。
发表人
zhang liang
发表于
Re: reply:敏捷团队中测试人员和开发人员的合理比例？视情况而定。
发表人
张 晓庆
发表于
Re: reply:敏捷团队中测试人员和开发人员的合理比例？视情况而定。
发表人
徐 毅
发表于
-
实际应用中，我们大多数project team应该是属于文中的“传统团队”，但又不太一样，往往开发需要先将unit testing脚本跑通过后才能提交给QA，所以测试的责任不仅仅在QA人员，需要项目组中产品，开发和测试成员共同承担！
-
说得没错。
对单元测试来说，首先有的传统团队没要求写；有的团队要求写，但是没有标准，基本上靠自觉；有的团队强制要求写，并且有测试覆盖率，这样测试写的多一些。
对功能测试和集成测试来说，更是很多团队都没有的。
在敏捷团队里，TDD保证了很高的测试覆盖率，而且单元测试、功能测试、甚至集成测试都可以自动化，开发人员就可以完成；持续集成能够减少集成、regression的bug。
所以我觉得敏捷团队对减少测试人员的比例还是比较有帮助 -
所以我觉得敏捷团队对减少测试人员的比例还是比较有帮助
对这个问题我现在比较迷惑。如果开发人员写出非常完备的测试用例，覆盖业务流程的每个分支，这样做，固然可以保证开发人员交付代码的质量，但是这种质量的提高以开发人员写测试用例、执行测试用例为代价，如何衡量这种代价是否值得？
而且测试人员经常有一个疑问，即测试人员撰写的测试用例，与开发人员的测试用例是什么关系，这个算不算重复劳动？
所以我觉得不能简单的说，单元测试减少了对测试人员的需求，因为单元测试只是把以前在项目后期执行的测试用例提前到开发阶段执行，降低了总测试成本（此处不考虑TDD对设计带来的促进作用）。 -
所以我觉得不能简单的说，单元测试减少了对测试人员的需求，因为单元测试只是把以前在项目后期执行的测试用例提前到开发阶段执行，降低了总测试成本（此处不考虑TDD对设计带来的促进作用）。
很好的想法。我所讲的是指传统意义上“测试对开发”与敏捷开发中“测试对开发”之间的对比。不过，确实有这样的问题，就是如何把测试与开发区分开来？其实开发人员编写单元测试、功能测试，甚至集成测试，本身就是测试的活。
所以我觉得敏捷可以降低测试人员比例可以先不考虑。
对你说的测试重复的问题，我的看法是，开发人员写的单元测试是白盒测试，可以在项目早期发现潜在的很多bug，能够大大减少测试人员的工作量（还包括撰写bug描述、重现步骤、开发人员重现、与QA验证等等很多工作），所以这种代价肯定是值得的。
开发人员写的功能测试和集成测试也是这样，而且测试都是自动化的，这样利于持续集成。以后新增功能、或者修改bug时，可以运行所有的测试，以尽力保证没有引起回归的bug，所以代价也是值得的。
测试人员的测试是黑盒测试，更多的是基于需求、验收条件写的。而且，很多项目QA的测试还是手工测试，所以与开发人员的测试虽然可以说有重复，但更多的是补充。想想，即使这样，产品发布之后还会有不少bug呢。 -
敏捷能否降低测试人员比例，是和BPUF这些方式进行对比。具体的团队要具体分析，如果团队本身的测试能力不足，那么即使转向使用敏捷方式进行开发，也或许还需要增加更多的人手才能保证质量呢。
而且需要注意到，测试人员数量减少的同时其他方面发生的变化，用于自动化测试的工具成熟且易用性高，测试人员的时间更多地花在价值更高的测试设计、需求分析、探索性测试等方面。如果实施敏捷期望达到的目标之一是减少测试人员，那么无疑这条道路也许不是你正确的方向。
5 条回复
关注此讨论 回复