假设每小时收益率为3,那就是83000小时。每天8小时制作10,500天,除以30来获得342个神话般的人月。我称之为神话故事,因为每人每周写125次测试是不真实的。
是否有任何明智的灵魂可以在那里阐明什么样的神话人为大型软件项目编写不真实的测试数量?谢谢。更新 chrisw认为只有20k测试(请查看下面的解释) PS 我真的很想听听那些参与大型测试基地项目的人们
答案 0 :(得分:12)
原始目录包含240K文件:
Total Files Listed:
243541 File(s) 1,062,470,729 bytes
64718 Dir(s)
其中许多是svn文件。如果我删除所有名为“.svn”的子目录,那么文件数量将降至90K:
Total Files Listed:
90615 File(s) 537,457,618 bytes
7190 Dir(s)
某些目录有一个名为“resources”和/或“script-tests”的子目录。我认为这些子目录包含辅助文件,这些文件由超级目录中的测试用例使用。如果我删除这些子目录(因为它们没有添加到测试总数),那么文件数量将降至87K:
Total Files Listed:
87672 File(s) 534,598,610 bytes
6305 Dir(s)
冷凝“类似”文件名(例如“arrow-keys-on-body.html”和“arrow-keys-on-body-expected.txt”是定义单个测试的两个文件)将总数从87K减少到43K。
包含超过1500个这些测试用例(如上所述计算)的唯一子目录是:
2761 LayoutTests\dom
10330 LayoutTests\fast (of which 5934 are in LayoutTests\fast\js)
22575 LayoutTests\platform (with various O/S-specific subdirectories).
在平台子目录中,平台之间似乎存在一些复制和粘贴。例如,css3-modsel-37-expected.txt
文件存在:
LayoutTests\platform\mac\css3
子目录LayoutTests\platform\chromium-win\css3
子目录LayoutTests\platform\qt\css3
子目录中。如果我丢弃复制到多个平台子目录中的文件名,那么只有5716个(而不是22575个)独特的平台测试。
总之,我认为大约有18K的独特测试:这仍然是一个令人印象深刻的测试数量,但是少于您在OP中估计的250K。
作为比较,我最近发现CSS2.1 Test Suite:看起来像CSS的9000个测试用例。
答案 1 :(得分:7)
我刚在5分钟内完成了4次单元测试。并非所有单元测试都需要很长时间。有些很简单;)
答案 2 :(得分:5)
有自动单元测试生成器之类的东西。对于复杂函数,您可能经常需要运行7个参数的可能值的所有排列。如果它们是布尔值,则得到2 7 = 128次测试。对于某些情况,这128个测试都是使用10行代码生成的。
许多基于回归的单元测试可以通过获取大量输入,运行现有代码,记录相应输出,然后进行大量测试(采用新代码,在同一运行中运行)来生成输入和测试输出匹配旧输出。
编写单元测试是一项相当分散的工作。实习生/志愿者的军队可以同时进行。
答案 3 :(得分:5)
来自webkit contribution guidelines
“对于影响布局引擎的任何功能,必须构建一个新的回归测试。如果你提供修复bug的补丁,该补丁还应该包括一个回归测试,如果没有补丁就会失败并成功如果没有提供回归测试,审核人员会要求您修改补丁,这样您就可以通过预先构建测试并确保它附加到错误来节省时间。如果没有布局测试可以(或需要)要为修复而构建,你必须解释为什么审阅者不需要新的测试。“
问:谁写了那些测试? A)几乎所有人谁为webkit做出了贡献。答案 4 :(得分:3)
这些似乎不是单元测试:它们看起来更像是系统/回归测试。
这并没有直接回答你的问题,但是我开发了一个自己的浏览器,所以我可能对它有一些了解;见:
那么,任何有智慧的灵魂都能解释出什么样的神话人物为大型软件项目编写了不真实的测试数量?
编写此类测试非常简单,有必要:
我的老板曾经说过,“你得到了你所检查的东西。” (这意味着无论你不测试什么都是未知/随机的)。
答案 5 :(得分:1)
这实际上取决于这是如何计算的。
但无论如何,一旦测试特定类/库/单元/任何设置的好框架,添加新测试通常只有几行。如果他们编写的测试目标是高代码覆盖百分比,那么这些测试通常会更短,因为你做了很多测试,这些测试只能通过单个变量的值来改变,以获得不同的代码路径。
答案 6 :(得分:1)
你的分析充其量是不完整的。或者有偏见,我想。
您应该计算测试人员的数量,他们中的一些(或全部)完全致力于测试和测试,是什么使他们更有效率。此外,您应该意识到在很多项目中很少有测试很复杂,而且大多数测试都是重复的,因此可以很容易地实现。
答案 7 :(得分:0)
在评论中,你问:
观看观察者的是谁?有人必须完成放牧所有这些小鸭子的噩梦般的工作
......和......
好吧,你问我同样的问题。有多少测试人员在那里。他们是谁。他们是开发人员还是QA员工?志愿者?
也许您的问题已在WebKit Committers and Reviewer Policy得到解答。
答案 8 :(得分:0)
假设每小时收益率为3,即83000小时
鉴于只有18K的独特测试,每人每年200个工作日,那么如果你预算一整天开发每个测试,那么一个由9名全职测试人员组成的团队可以在10年内开发18K测试年(KDE的KHTML和KJS项目始于1998年)。这些数字可能是无关紧要的(开发每个新的测试案例可能不需要一天,他们可能没有全职/专职测试人员),但IMO表明,10年的18K测试对于“大”是可行的(成功的项目。
我在我的项目中使用了类似的测试策略:不是因为我复制了Webkit,而是因为这是我想要对GUI进行自动但可维护的回归测试的唯一方法。
以下FYI是我的一个测试用例的示例(最短/最简单的示例之一)。我只是通过在内置的测试用例生成框架中手动运行浏览器的UI来生成它(以及其他类似的东西)。然后我可以再次运行作为自动回归测试(框架重放输入并断言输出没有改变)。
我发现创建测试用例并不需要相当长的时间。
> clientSize 20 10
+ screenDisplays lines 0
----------
----------
> loadDocument lines 5
----------
<div>
<h1>Easy title</h1>
<p>Hello world. Lorem ipsum.</p>
<p>Embedded <a>anchor</a> tag.</p>
</div>
----------
< invalidateAll
> paint 0 0 20 10
+ screenDisplays lines 10
----------
····················
····················
··»«Easy title········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> mouse down 9 2
< ensureVisible 9 2 1 13
+ screenDisplays lines 10
----------
····················
····················
··Easy ti»«tle········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> mouse up 9 2
< ensureVisible 9 2 1 13
+ screenDisplays lines 10
----------
····················
····················
··Easy ti»«tle········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> keyDown Enter
< invalidate 2 2 16 1
< invalidateAll
< invalidate 2 4 16 3
< ensureVisible 2 5 1 16
+ currentDocument lines 6
----------
<div id="ModelText_id_contents">
<h1>Easy ti</h1>
<h1>tle</h1>
<p>Hello world. Lorem ipsum.</p>
<p>Embedded <a>anchor</a> tag.</p>
</div>
----------
+ debugDumpDom lines 15
----------
1 div
2 h1
3 Easy ti
4 h1
5 tle
6 p
7 Hello world. Lorem ipsum.
8 p
9 Embedded
10 a
11 anchor
12 tag.
Selected start={parentId=4,parent={tle},offset=0}, end={parentId=4,parent={tle},offset=0}
----------
> paint 0 0 20 10
+ screenDisplays lines 10
----------
····················
····················
··Easy ti···········
····················
····················
··»«tle···············
····················
····················
··Hello world. ·····
··Lorem ipsum.······
----------