кто написал 250k тестов для webkit? - PullRequest
22 голосов
/ 29 мая 2010

при условии доходности 3 в час, это 83000 часов. 8 часов в день составляют 10 500 дней, разделите на тридцать, чтобы получить 342 мифических человеко-месяца. Я называю их мифическими, потому что написание 125 тестов на человека в неделю нереально.

Может ли какая-нибудь мудрая душа там на ТАКОМ пролить свет на то, какие мифические люди пишут нереальные количества тестов для больших программных проектов? спасибо.

обновление Крис считает, что тестов всего 20k (см. Его объяснение ниже).
PS Мне бы очень хотелось услышать от людей, которые работали над проектами с большими тестовыми базами

Ответы [ 9 ]

12 голосов
/ 29 мая 2010

Исходный каталог содержал 240К файлов:

 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)

Сжатие «похожих» имен файлов (например, «стрелки-ключи-на-теле.html» и «стрелки-ключи-на-теле-ожидаемые.txt» - это два файла, которые определяют один тест) уменьшает общее количество с 87K до 43 тыс.

Единственными подкаталогами, которые содержат более 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 уникальных тестов: это все еще впечатляющее количество тестов, но меньше, чем 250K, которые вы оценили в своем OP.


Для сравнения я недавно обнаружил CSS2.1 Test Suite : это выглядит примерно как 9000 тестовых случаев для CSS.

7 голосов
/ 29 мая 2010

Я только что написал 4 модульных теста за 5 минут. Не все юнит-тесты занимают много времени. Некоторые очень просты;)

5 голосов
/ 29 мая 2010

Из рекомендаций по вкладу в webkit

"Для любой функции, которая влияет на механизм компоновки, должен быть создан новый регрессионный тест. Если вы предоставляете патч, исправляющий ошибку, этот патч должен также включать добавление регрессионного теста, который потерпит неудачу без патча и завершится успешно с патчем. Если регрессионный тест не предоставлен, рецензент попросит вас пересмотреть патч, чтобы вы могли сэкономить время, создав тест заранее и убедившись, что он прикреплен к ошибке. Если тест макета не может быть (или требует Чтобы исправить это, вы должны объяснить, почему новый тест не нужен рецензенту. "

В) Кто написал эти тесты? A) Почти все , кто внес свой вклад в веб-набор.

5 голосов
/ 29 мая 2010
  • Есть такие вещи, как автоматические генераторы тестов. Для сложной функции вам часто может потребоваться выполнить все перестановки возможных значений, скажем, 7 параметров. Если они булевы, вы получаете 2 7 = 128 тестов. Для определенных сценариев все эти 128 тестов генерируются с использованием 10 строк кода.

  • Многие модульные тесты на основе регрессии можно сгенерировать, взяв большой набор входных данных, запустив на них существующий код, записав соответствующие выходные данные, а затем выполнив тесты gazillion, в которых используется новый код, и запустить его вход и проверка того, что вывод соответствует старому выводу.

  • Написание юнит-тестов - довольно распространенное занятие. Армии интернов / волонтеров могут делать это параллельно.

3 голосов
/ 29 мая 2010

Это не модульные тесты: они больше похожи на системные / регрессионные тесты.

Это не дает прямого ответа на ваш вопрос, но я разработал собственный браузер, так что я мог бы немного разобраться в нем; см:

Может ли какая-нибудь мудрая душа там на ТАКОМ пролить свет на то, какие мифические люди пишут нереальные количества тестов для больших программных проектов?

Это просто и необходимо написать такой тест:

  • Легко: написать HTML-страницу (или аналогичный ввод в черный ящик), чтобы использовать функциональность / функции / поведение
  • Необходимо:
    1. Нужно проверить / отработать функциональность, когда написано
    2. Нужно демонстрировать / воспроизводить ошибки при регистрации любого сообщения об ошибке
    3. Необходимо сохранить все предыдущие тесты от 1. и 2., чтобы сделать регрессионное тестирование

Мой босс однажды сказал: «Вы получаете то, что осматриваете». (что означает, что все, что вы не тестируете, неизвестно / случайно).

1 голос
/ 29 мая 2010

Ваш анализ неполон, в лучшем случае. Или, наверное, предвзято.

Вы должны сосчитать количество тестеров, некоторые (или все) из них полностью посвящены тестированию и только тестированию, что делает их более продуктивными Кроме того, вы должны понимать, что очень мало тестов являются сложными во многих проектах, и большинство тестов могут быть повторяющимися, чтобы их можно было легко реализовать.

1 голос
/ 29 мая 2010

Это действительно зависит от того, как это было посчитано.

Но в любом случае, когда-то являясь хорошей основой для тестирования определенного класса / библиотеки / модуля / чего бы то ни было, добавление нового теста обычно занимает всего несколько строк. Если они писали тесты с целью обеспечения высокого процента охвата кода, то эти тесты, как правило, еще короче, потому что вы делаете много тестов, которые отличаются только значением одной переменной, чтобы получить другой путь кода.

0 голосов
/ 29 мая 2010

при условии доходности 3 в час, это 83000 часов

Учитывая, что существует только 18 тыс. Уникальных тестов и 200 рабочих дней на человека в год, тогда, если вы планируете целый день на разработку каждого теста, то команда из 9 штатных тестировщиков / людей может разработать 18 тыс. Тестов в 10 лет (проекты KDE KHTML и KJS начались в 1998 году). Эти цифры, вероятно, не имеют значения (может потребоваться не один день для разработки каждого нового тестового примера, и они могут не иметь полностью занятых / выделенных тестировщиков), но они действительно показывают, что 18К тестов в течение 10 лет выполнимо для «большого» ( или нетривиально), успешный проект.

Я использую аналогичную стратегию тестирования в своем проекте: не потому, что я скопировал Webkit, а потому, что это единственный способ, которым я думаю делать автоматизированные, но поддерживаемые регрессионные тесты GUI.

Следующий FYI - пример (один из самых коротких / простейших примеров) одного из моих тестовых случаев. Я генерирую его (и тому подобное) просто вручную используя пользовательский интерфейс моего браузера в рамках встроенной среды генерации тестовых наборов. Затем я могу запустить снова позже как автоматический регрессионный тест (фреймворк воспроизводит ввод и утверждает, что вывод не изменился).

Я считаю, что создание контрольных примеров - это не то, что занимает относительно много времени.

> 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.······
----------
0 голосов
/ 29 мая 2010

В комментариях вы спросили:

кто смотрит на наблюдателей? у кого-то должна быть кошмарная работа по выпасу всех этих утят

... и ...

верно, вы задаете тот же вопрос, что и я. сколько там было тестеров. кто они. они разработчики или сотрудники QA? добровольцы?

Возможно, на ваши вопросы ответят Политика коммиттеров и рецензентов WebKit .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...