Здравствуйте, Sinclair, Вы писали:

S>Если повезёт, и новых утечек не будет добавлено, то да — удастся. А если нет — то упс, наше расписание безнадёжно испорчено и продолжает портиться. Вместо 2х релизов в месяц мы имеем примерно 2 за три месяца, плюс расходы на тройную инфраструктуру и нервы разработчиков.
Всё так... Но это очень грустная история. А может быть ведь можно исследовать источник падения теста и попробовать бороться с причиной, понижая вероятность будущих падений. Т.е. такой подход вполне работает, если soak tests падают редко.
Если вероятность падения низка — то это надо быть очень неудачливым, чтобы появились несколько багов подряд.
Поэтому, RC1 нужно исправить, прогнать ещё 30 дней и зарелизить R1. А текущие RC2... выкинуть и начать создавать следующие RC из результата мержа R1 в trunk.
Т.е. тогда максимальная пауза между релизами будет 59+x дней, где x — количество дней на исследование причины падения и исправление (при условии RC мы исправляем с первой попытки).

В общем... варианты возможны.

Здравствуйте, Ikemefula, Вы писали:

I>>>Мануально не надо ничего сравнивать. Человек видит картинку и все нестыковки, косяки, корявости видит сразу при минимальной подготовке.
I>·>Видит где? На каждой из 1000 форм одновременно?
I>Нужно помнить ,что условия естественные, а значит у юзера не может быть открыто одновременно 1000 форм
Почему ты от авто-тестов ожидаешь падения всего (т.е. модификация кода повлекла изменение всего — всё менять!!111) и считаешь это чем-то ужасным, а в той же ситуации ты не требуешь, чтобы юзер открыл всё и проверил то же вручную?

I>>>Ты статью то перечитай — косяк был именно в либе. Они сменили одну версию на другую и "понадеялись".
I>·>Перечитал, оказывается вообще 3rd party никакого не было. "У Яндекса есть собственная технология распознавания SpeechKit". Линковали _вручную_ свою либу к своему приложению.
I>Не к своему, а взяли либу которую пилила другая команда. Практически тоже самое что и 3rd party.
Совсем не тоже самое. Это значит у них такая организация классная, что команды между собой взаимодействуют как чужие.

I>·>Мне и не особо интересно наличие этого курсора, вообще UI не интересно. Меня больше всего интересует вопрос — какое всё это отношение имеет к сабжу?
I>А ты ответы на вопросы читаешь ? Внимательно — "никакого". И уже давно, потому что перешли на UI
А тут тоже всё просто — если UI библиотека плохо поддаётся автотестам, то её лучше выкинуть.

I>·>В твоей начальной задаче курсор рендерился, но не там. А потом ты начал говорить, что он вообще не рендерится.
I>Баг то сразу указал — тестер видит что курсор смещен. Его так и обнаружили.
А какие авто-тесты присутствовали?

I>·>Не знаю. А ты правда считаешь, что в мире не существует проектов, где выгодно используется или будет выгодным использование попиксельного сравнения рендеринга?
I>Теоретически — можно. Нужно только соблюсти все условия, что я привел. Скажем, я использовал такое дело когда надо было выяснять, как работает свой собтсвенный рендерер.
Собственно я так и понял изначальную задачу — кастомный контрол, проблемы с рендером — значит надо тестировать рендерер. А проблема оказывается в том, что рендерер завязан на систему и 3rd party, т.е. код не ваш, глюки в 3rd party.

I>·>Только одно я не понимаю — раскрой секрет. Как вы, десять человек, вручную тестируете 8 тысяч только устройств?
I>Я ж говорил — всего пару десятков. На самом деле у нас нет задачи все 8000 тыщ покрывать. Кастомер такой задачи не ставит.
А почему ты это требуешь от авто-тестов? Вроде задачи такой нет, а как появляются авто-тесты, так сразу вдруг надо все 8000.

I>>>Для примера. Я ж не в курсе, что ты начнешь кирпичами срать и сочинять, что эвентов не бывает.
I>·>Ещё раз. В языке Java эвентов нет. Найди евенты в JLS, если сможешь.
I>Есть, поддерживаются на уровне библиотеки. Синтаксической поддержки — нет.
Да пусть поддерживаются. Но mockito работает на уровне языка, а не библиотеки. mockito никак с swing не связан. Зачем это всё мешать в кучу?

I>·>Мы проверяем, что делает реализация компонента.
I>·>Что сказать-то хотел?
I>Я хотел сказать что вы тестируете именно то, что делает реализация. Поскольку вы делаете это сознательно, то это уже преступление
Почему? Собственно юнит-тесты — тесты реализации.

I>>>Юзеру надо работать с софтиной, решать свои задачи. Потому он работает с софтиной плотнее любого тестера.
I>·>И что?
I>Баги при такой работе вылазят постоянно, ибо практически всегда это новые кейсы
Зависит от того, насколько качественно покрыта тестами функциональность.

I>>>Именно. Это и есть ручной привод. Как теперь планировать, что фиксить сейчас, что попозже, где фиксировать эстимейты ? Тоже заводить всякие аннотации для этого ?
I>·>Не понял. История уже спланирована, сэстимирована, это фаза имплементации. Если в процессе работы над историей возникнут неожиданные сложности — решаем по ходу.
I>Что значит уже спланирована ? как мне посмотреть, скажем, баги связанные с компонентом XXX, проверить, сколько вреени на них ушло, какие девелоперы их фиксили, какие компоненты патчились в тех же коммитах ?
Ещё раз, баги идут в трекер. В коде — разработка, имплементация истории. История — не баг, а новая фича.
Звонит клиент, говорит: "баг". Заводим тикет в баг-трекере. Смотрим, решаем, баг ли. Если вдруг действительно баг, то тестер рисует красный тест его воспроизводящий, коммитит, дев делает тест зелёным. Т.е. тестеры баги не создают, баги создаются клиентами.
Подавляющее большинство тикетов в трекере не требуют бакфиксов, обычно проблемы на стороне клиента, настроек, проблемы с железом|инфраструктурой, проблемы с latency (самый жуткий ужас) или просто фич-реквесты.

I>>>3 после отрисовки система вернется к тому, кто сильнее жрет проц
I>·>Какое-то странное представление о том как работает операционная система. В конце концов... можно крутить приоритеты тредов|процессов, если это такая проблема, то, внезапно, в мире существуют многопроцессорные системы. И, если это так важно (а у нас, например, это очень важно), то есть affinity, isolcpus, cset, cgroups.
I>Для UI это ни о чем. Максимум, ты можешь высвободить одно ядро, что бы ни один из процессов его не юзал и пускануть апликачку именно в этом ядре.
I>При этом из за косвенного влияния ФПС падает, а следовательно количество ресурсов затраченых на работу самой апликачки.
Какого такого косвенного влияния? Нет никакого магического косвенного влияния. В конце концов, если ваша тестовая система настолько тяжелая, её можно на другом хосте запускать и по оптике...

I>>>Соотсвенно если в твоей софтине упал ФПС, это значит, внимание, что ты затратил ресурсов МЕНЬШЕ.
I>·>Я не понимаю что вы там такое делаете. Система тестирования забирает не сильно больше ресурсов, чем драйвер мыши и клавиатуры.
I>Ты же хотел аналог нагрузочного влупить.
Я говорил о soak tests, а не о load tests. Они не о предельной нагрузке, а о долговременной.
Но да, совершенно ожидаемо — сделать тесты качественные, чтобы они показывали не погоду на марсе, а реальное положение дел — это наука.

I>>>Максимум, чего ты добьешься — будешь генерить кадры вхолостую.
I>·>Это правда, что винда может давать cpu два раза в секунду? Что у вас за такая система тестирования, которая жрёт больше 5% одного ядра??
I>Правда. Если ты запустишь нагрузочный тест, сам же просил, то именно так и будет.
Для UI? слабо верится. Для high-perf сервера — понятно, он должен обслуживать тучи клиентов. Поэтому обычно эти тучи пускают на кластере, чтобы они все бомбили один сервер.

I>Потому нагружать надо принципиально иначе. Не количество действий в секунду, не внешняя система которая может убить UI, а объемы данных, сложные функции, время работы, большие разрешения.
I>Вот есть у тебя рисовалка — берём раскрываем на весь экран, разрешение чем больше тем лучше, вгружаем конские данные, что бы на одном экране было как можно больше объектов и наблюдаем результат. Можно увеличить частоту некоторых таймеров, частоту опроса мыши поднять и тд и тд.
Только не надо говорить, что это можно сделать только вручную. Скорее наоборот — только автоматически. Даже выбора больше — можно сделать виртуальный экран размером 20000*10000 и проверять нужный fps, а вот человек это сделать не сможет.

I>>>Синтетика от реалных кейсов отличается всего лишь частотой встречаемости. Беременность от небеременности отличается не частотой, а наличием однозначных изменений в организме женщины.
I>·>Разве? Вот авто-тесты тестируют всё что встречается, без всяких частот, т.е. они полностью реальны. Но я думал реальность, это когда ты делаешь перевод денег в программе и деньги и вправду переводятся, а не тыкается стаб платёжной системы.
I>Тестируют всё, но в реальной жизни кейсы встречаются с разной частотой. С автотестами получается так, что тесты получаются в основном вырожденные.
Пусть, жалко что-ли? Компьютер железный, будет и редкие случаи перетестировать постоянно.

I>·>У нас простой случай — WUI, и для финансов. Где модность|красявость|дизайнерские изыски|accessability не важны, главное функциональность, которая идеально тестируется автоматически.
I>У вас главная функция это не UI. А вот есть целый класс приложений, который держится исключительно на UI. Что характерно, в таких приложениях никто даже не заикается, что бы выкинуть мануальщиков. Скорее автоматизаторов повыкидывают, если вдруг бюджет тоньше станет.
I>·>Есть приложения, игры-казуалки, например, где главное выпендёж, а функциональности особо нет...
I>И это нормально.
Об автоматизации именно функциональности я и говорил всё время. Я сразу поделил UI на функциональность и UX. И да, второе хрен протестируешь. Поэтому да, если в проекте 95% UX и 5% функциональности, то работы автотестам мало.

I>>>Хочешь, можно оба блекбокс, хочешь вайтбокс, хочешь выясним, какой метод больше пользы приносит.
I>·>Я не понимаю за счёт чего ты надеешься выиграть. Единственное что может помочь — это то что ты тестер, а у меня опыта тестера нет, я дев.
I>Я не тестировщик Но опыт тестирования есть.
У меня почти нет.

I>·>Если ты считаешь, что тесты можно запускать только после коммита, только во время полного билда — ты ошибаешься.

I>Всё проще — мне не надо ничего записывать, билдить и тд и тд. 100% времени я потрачу на эксперименты с UI и тупо прокликаю бОльше тестов.
I>Ты сможешь обогнать меня, только если, скажем, найдёшь какой то новое семейство багов или похожие баги в разных местах и тд.
I>Мне на новый кейс надо времени парус секунд. А тебе еще и написать, отладить, собрать, проверить, не врут ли тесты и тд и тд.
Так опять от приложения зависит. CD Ejector да, пара кнопок и всё. А если тебе для воспроизведения ситуации нужно создать админа, компанию задав куча параметров, в компании юзера, для юзера создать инструмент, задать роли, и т.п., т.д. Да, можешь мышой, но это будет занимать 100 кликов и 500 нажатий клавиш. А авто-тесты имеют это всё готовым, берёшь начальный сценарий и продолжаешь вариации.

I>·>Может быть... но, мне почему-то кажется, что обычные тестеры в целом менее эффективны, чем хорошо поставленный процесс с более высококвалифицированными тестерами.
I>Смотря для каких масштабов. Затраты на хорошо поставленый процесс и подготовку хотя бы одного тестера, энвайрмент и тд, уже больше по бюджету многих проектов.
Вот и говорю — жадность или бедность.

I>·>Если у вас проект кастомных контролов, то и эксперт будет по контролам, а не по графикам. Зачем отдельный ручной тестер?
I>Затем, что надо тестировать приложение в целом. Контрол это обычно в плане пару строчек.
Так там уже функциональность, а значит не просто UX, а значит нужно знание предметной области, т.е. эксперт, а не тестер.

I>>>Для UI — проще, ненадёжно и дорого. Одна инфраструктура стоит столько, что перекроет бюджеты многих приложений мобильных.
I>·>Вы вроде о Яндексе тут, вроде это уже не стартап...
I>Яндекс это кучка разных направлений, приложений, проектов, все это практически ничем от стартапа не отличатся. Если на каждую мелочевку подключать всю мощ Яндекса, то наверх всплывет столько уродцев, что вспотеешь фильтровать. Потому и надо в больших конторах ограничивать бюджеты, а то спокойно какой нибудь landing page продукта сожрёт чуть не весь профит.
Что-то как-то кустарно звучит. Вон гугл хвалится своим 2-миллиардным единым репозиторием кода и всех тулзов вокруг. И начать очередной CD Ejector проще в готовой инфраструктуре, чем с нуля.

I>>>Ну да, пусть файлы у юзера удаляет. Как юзер заметит, так и пофиксим, ага.
I>·>Это "мешает другим".
I>Тестер находит такие вещи гораздо лучше.
Не верю. Сетевой трафик? Место на диске? Память? Проц? Ошибки вычислений? Тестер хорош только для UX.

Я помню много-много лет назад участвовал в одном проекте, тестеры упустили интересный баг — был диалог выбора дней недели. Все тестеры (три человека!) когда тыкали "случайно" дни недели — никогда не выбирали вторник...

Здравствуйте, Sinclair, Вы писали:

L>>В результате — есть фикс, есть юнит-тесты, верифицирующие фикс. Есть лучший код. Все щасливы, кроме тестеров.
S>На самом деле — кроме юзеров.
S>Потому, что всё, что мы имеем — это +1 тест, который теперь не падает, и +1 if в коде.
S>Цитирую:
S>

S>вариации этого бага были обнаружены… семь раз. Каждый особый случай в коде соответствовал конкретному багу, который был «исправлен», если можно так сказать в этом случае.
S>Многие из этих «исправлений» на самом деле внесли новые баги, ухудшая существующее корректное поведение, что, в свою очередь, «исправлялось» добавлением особой обработки поверх особых обработок,

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

Наш процесс включал в себя код ревью, во время которого проводился разбор полетов. Выяснялся, откуда взялся этот баг — неполные (некорректные) требования, косяки вендора, некорректная реализация (багус вульгариус) или архитектурный косяк. Обязательно — воспроизведение бага, с анализом ситуаций, которые к нему могут привести, и верификация фикса. С регрессией сверху. Код ревью больше походили на защиту диссертации.
Соответственно, фикс в виде тупо "одного if" имел весьма призрачные шансы попасть в транк.

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

Здравствуйте, Sinclair, Вы писали:

S>То есть у пацанов было, скажем, три теста. Все — зелёненькие на момент релиза.

У пацанов никаких тестов не было. От слова "вообще"

S>Как вы думаете — почему "вполне нормальный цикл разработки" приводил к последовательному ухудшению качества кода, а не наоборот?

И культуры разработки — тоже.

Здравствуйте, landerhigh, Вы писали:
L>У пацанов никаких тестов не было. От слова "вообще"
Вот как раз были.

Здравствуйте, ·, Вы писали:
·>Т.е. тогда максимальная пауза между релизами будет 59+x дней, где x — количество дней на исследование причины падения и исправление (при условии RC мы исправляем с первой попытки).
Воот. Видите, вы начинаете понимать, что soak test длиной в X не даёт нам возможности уверенно релизиться чаще, чем раз в 2X, независимо от вложений в инфраструктуру.

Поэтому там, где утечки считаются критическими, релизят редко, отводя себе время на soak tests. А ещё проектируют софт с учётом ограничений, например, выделяя компонентам бюджеты на мусор. Если у нас ограничение 100мб на месяц, и в первые три дня мы жрали по 4mb, то ждать ещё 22 дня, чтобы убедиться в нарушении ограничения нет никакого смысла. А если у нас есть компонент, ответственный за log rotation, то мы тестируем его юнит-тестом, и полагаем, что он работает.
В итоге soak test имеет крайне низкие шансы завалиться, поэтому 2X нам хватает с достаточной вероятностью.

А там, где утечки считаются несущественным неудобством, результаты soak test на релиз не влияют — "мы починим это в одном из следующих релизов". В итоге, например, Office 2013 с распоследними апдейтами беспрерывно срёт на диск .etl файлы, а Microsoft support включает дурака и делает вид, что ни сном про это ни духом.

Здравствуйте, landerhigh, Вы писали:

L>иными словами, делая имеющиеся зеленые тесты красными.
Иными словами — нет. "Красными" становились тесты, которых не было на момент релиза. Они появлялись по итогам фидбека от пользователей.

L>В общем, вы только что прослушали басню Крылова в современной интерпретации.
Нет, мы просмотрели впечатляющую демонстрацию неспособности читать с пониманием прочитанного.

Здравствуйте, Ikemefula, Вы писали:

I>Я хотел сказать что вы тестируете именно то, что делает реализация. Поскольку вы делаете это сознательно, то это уже преступление
Ага. Я тоже не могу понять, где граница между осмысленным юнит-тестом и тупо сравнением нового кода с оригиналом путём команды fc (это если мы не хотим полагаться на встроенные иструменты VCS). Раз уж единственная роль теста — отловить изменение реализации, на основе white-box тестирования.

I>Тестируют всё, но в реальной жизни кейсы встречаются с разной частотой. С автотестами получается так, что тесты получаются в основном вырожденные.
Ага. Меня тоже всегда интересует статистика вроде "вот мы написали в 2005 году юнит-тест. Он был выполнен с тех пор более миллиона раз, и ни разу не был красным". Имело ли смысл тогда писать этот тест?

Здравствуйте, ·, Вы писали:

>Я помню что ты отвечал. Ты просто попутал load tests и soak tests, а Синклер описывал совсем другую ситуацию.
Антон просто привел еще один пример, показывающий, что soak тесты далеко не везде применимы, как минимум, в предлагаемом вами виде.

>А обосновать? Почему soak tests не подходят для коробок?
Ровно по тем же причинам — UI и окружение. А для устройств это еще забавниее, так как поведение на реальной железке запросто может отличаться от эмулятора.

>Конечно, но это всё к сабжу не имеет никакого отношения.
Ну конечно, если факты не лезут в теорию, то тем хуже для фактов?
Отношение самое прямое — если утечка будет не в основном сценарии, то ваш подход его не отловит, с чего и начался наш разговор.

>Я дождусь ровно тогда, когда ты начнёшь свой рассказ. Ты не можешь предполагать свои действия?
boring.. Даже стрелки красиво перевести уже не можете.

>Я представляю с кем ты работаешь... найди другую работу что-ли, чтобы правильно написанный тривиальный код у тебя не вызывал изумление.
Ну откуда это желание до меня-то докопаться? Не переживайте за меня, у меня все прекрасно. Вокруг лучшие разработчики, которые делают совершенно волшебные продукты и технологии.
Не обо мне речь.

>Может быть, но для нас — достаточно. Факапы — ловит, внимания не требует. Простое решение, как говорится, дёшево и сердито.
как я уже говорил — ктож вам доктор?

IB>>Мне надо объяснять, что малого числа пользователей тоже достаточно для большего "факапа"?
IB>>Или надо объяснять, что число пользователей может быть даже большим из-за того, что проблема вылезет не сразу?
>Не надо это объяснять, ибо это оффтоп.
Ну какой же это оффтоп? Это же и есть тема нашего разговора — пропускает ваш подход серьезные ошибки или нет. Если упомянутые выше ошибки попадают под категорию серезных, значит ваш подход не работает, что, собственно и требовалось доказать.

>>>Где что я подменил?
IB>>Какой у вас однако стек короткий... Например, вы заменили "организацию процесса тестирования" на "тест".
>Так ведь это не важно.
То есть подмена понятий была, но это не важно? Забавно, и как после этого с вами вообще конструктивно разговаривать?

>"тест" тоже существует, который ты заставил меня написать.
Ранее вы утверждали, что теста нет, так как вы целиком доверяете конфигурации. Так есть тест или нет? Или вы показания на лету меняете?

>Правда огранизация процесса — лучше.
Она не может быть лучше или хуже, это не взаимозаменяемые вещи.

Здравствуйте, ·, Вы писали:

I>>Нужно помнить ,что условия естественные, а значит у юзера не может быть открыто одновременно 1000 форм
·>Почему ты от авто-тестов ожидаешь падения всего (т.е. модификация кода повлекла изменение всего — всё менять!!111) и считаешь это чем-то ужасным, а в той же ситуации ты не требуешь, чтобы юзер открыл всё и проверил то же вручную?

Это ж элементарно. Вот твоя вики, раз уж тебе она так нравится

Integration testing typically still relies heavily on humans testing manually; high-level or global-scope testing can be difficult to automate, such that manual testing often appears faster and cheaper.

Вот взять скажем, форму составленную из контролов на html.css. Внезапно, что бы дать хоть какие то гарантии, нужен эталонный css процессор. Такого в природе нет и никогда не будет. Все что можно — выдумывать эвристики, эффективность и результативность каждой из которых нужно проверять экспериментально.

I>>Не к своему, а взяли либу которую пилила другая команда. Практически тоже самое что и 3rd party.
·>Совсем не тоже самое. Это значит у них такая организация классная, что команды между собой взаимодействуют как чужие.

Если в конторе больше чем пара сотен человек, то сорганизовать команды что бы все чотко было, не выйдет.
Одним нужно релизиться раз в неделю. Другим — раз в месяц. Третьим — раз в год. Библиотеку пилит четвертая команда. Всё — конфликт интересов. Или уравниловка, или 3rd-party-like.

I>>А ты ответы на вопросы читаешь ? Внимательно — "никакого". И уже давно, потому что перешли на UI
·>А тут тоже всё просто — если UI библиотека плохо поддаётся автотестам, то её лучше выкинуть.

Это практически про любой UI. Хорошо покрываются только точечные кейсы для проверки регрессии.

I>>Баг то сразу указал — тестер видит что курсор смещен. Его так и обнаружили.
·>А какие авто-тесты присутствовали?

Я уже не могу вспомнить

I>>Я ж говорил — всего пару десятков. На самом деле у нас нет задачи все 8000 тыщ покрывать. Кастомер такой задачи не ставит.
·>А почему ты это требуешь от авто-тестов? Вроде задачи такой нет, а как появляются авто-тесты, так сразу вдруг надо все 8000.

ты уже третий раз задаёшь вопрос. Посмотри предыдущие ответы.

I>>Есть, поддерживаются на уровне библиотеки. Синтаксической поддержки — нет.
·>Да пусть поддерживаются. Но mockito работает на уровне языка, а не библиотеки. mockito никак с swing не связан. Зачем это всё мешать в кучу?

И это вполне достаточно. Ты не волнуйся — свинг никакой не особенный, эвенты есть во всех либах.

I>>Я хотел сказать что вы тестируете именно то, что делает реализация. Поскольку вы делаете это сознательно, то это уже преступление
·>Почему? Собственно юнит-тесты — тесты реализации.

Вот-вот.

I>>Баги при такой работе вылазят постоянно, ибо практически всегда это новые кейсы
·>Зависит от того, насколько качественно покрыта тестами функциональность.

Я снова покажу тебе вики, поскольку ты веришь только ей

"code for a unit test is likely to be at least as buggy as the code it is testing"
"As a result, for every line of code written, programmers often need 3 to 5 lines of test code"
"Testing will not catch every error in the program, since it cannot evaluate every execution path in any but the most trivial programs"
"In order to guarantee correct behavior for every execution path and every possible input, and ensure the absence of errors, other techniques are required, namely the application of formal methods to proving that a software component has no unexpected behavior."
"Another challenge related to writing the unit tests is the difficulty of setting up realistic and useful tests"

I>>Что значит уже спланирована ? как мне посмотреть, скажем, баги связанные с компонентом XXX, проверить, сколько вреени на них ушло, какие девелоперы их фиксили, какие компоненты патчились в тех же коммитах ?
·>Ещё раз, баги идут в трекер.

Меня интересует аналитика. Как по вашей истории коммитов получить аналитику ? Вот есть компонент XXX. Как узнать затраты, структуру затрат и тд и тд ?

I>>При этом из за косвенного влияния ФПС падает, а следовательно количество ресурсов затраченых на работу самой апликачки.
·>Какого такого косвенного влияния? Нет никакого магического косвенного влияния. В конце концов, если ваша тестовая система настолько тяжелая, её можно на другом хосте запускать и по оптике...

Все софтварные компоненты влияют друг на друга. Косвенно — через кеш, адресное пространство, виртуальную память, Garbage Collection и тд и тд и тд.
Более того — сторонние процесс, если активны, влияют точно так же. а иногда даже сильнее.

I>>Правда. Если ты запустишь нагрузочный тест, сам же просил, то именно так и будет.
·>Для UI? слабо верится.

Именно. UI он очень особый. Даже профайлер очень часто маскирует кучу проблем и выдаёт зачастую нереальные.
Логирование тоже имеет влияние. Казалось бы — всего лишь UI, да ?

I>>Вот есть у тебя рисовалка — берём раскрываем на весь экран, разрешение чем больше тем лучше, вгружаем конские данные, что бы на одном экране было как можно больше объектов и наблюдаем результат. Можно увеличить частоту некоторых таймеров, частоту опроса мыши поднять и тд и тд.
·>Только не надо говорить, что это можно сделать только вручную. Скорее наоборот — только автоматически. Даже выбора больше — можно сделать виртуальный экран размером 20000*10000 и проверять нужный fps, а вот человек это сделать не сможет.

Это делается очень легко Пишешь в углу экрана цифры и всё. Можно фпс, можно время отрисовки фрейма.

I>>Тестируют всё, но в реальной жизни кейсы встречаются с разной частотой. С автотестами получается так, что тесты получаются в основном вырожденные.
·>Пусть, жалко что-ли? Компьютер железный, будет и редкие случаи перетестировать постоянно.

"перетестировать" == проверки регрессии.

·>Об автоматизации именно функциональности я и говорил всё время. Я сразу поделил UI на функциональность и UX. И да, второе хрен протестируешь. Поэтому да, если в проекте 95% UX и 5% функциональности, то работы автотестам мало.

UX это "юзер ошибается, потому что кнопки не в том порядке"
Функциональность начинается с "кнопка недоступна или имеет чужой тайтл"

I>>Я не тестировщик Но опыт тестирования есть.
·>У меня почти нет.



·>Так опять от приложения зависит. CD Ejector да, пара кнопок и всё. А если тебе для воспроизведения ситуации нужно создать админа, компанию задав куча параметров, в компании юзера, для юзера создать инструмент, задать роли, и т.п., т.д. Да, можешь мышой, но это будет занимать 100 кликов и 500 нажатий клавиш. А авто-тесты имеют это всё готовым, берёшь начальный сценарий и продолжаешь вариации.

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

I>>Смотря для каких масштабов. Затраты на хорошо поставленый процесс и подготовку хотя бы одного тестера, энвайрмент и тд, уже больше по бюджету многих проектов.
·>Вот и говорю — жадность или бедность.

Это здоровый прагматизм. Перфекционизм окупается крайне редко, исключительно там, где цена ошибки крайне высока.

I>>Затем, что надо тестировать приложение в целом. Контрол это обычно в плане пару строчек.
·>Так там уже функциональность, а значит не просто UX, а значит нужно знание предметной области, т.е. эксперт, а не тестер.

Теоретически. А если приложение сорта "productivity" то вместо эксперта можно нанять целую бригаду QA.

I>>·>Вы вроде о Яндексе тут, вроде это уже не стартап...
I>>Яндекс это кучка разных направлений, приложений, проектов, все это практически ничем от стартапа не отличатся. Если на каждую мелочевку подключать всю мощ Яндекса, то наверх всплывет столько уродцев, что вспотеешь фильтровать. Потому и надо в больших конторах ограничивать бюджеты, а то спокойно какой нибудь landing page продукта сожрёт чуть не весь профит.
·>Что-то как-то кустарно звучит. Вон гугл хвалится своим 2-миллиардным единым репозиторием кода и всех тулзов вокруг. И начать очередной CD Ejector проще в готовой инфраструктуре, чем с нуля.

И мы знаем из истории, что у Гугла уже всплыло столько уродцев, что хватит на целую индустрию.
Всех их пришлось закопать, а бабла они сожрали столько, что не передать словами.

Ты в курсе, что гугл теперь режут на части ? https://en.wikipedia.org/wiki/Alphabet_Inc.

I>>Тестер находит такие вещи гораздо лучше.
·>Не верю. Сетевой трафик? Место на диске? Память? Проц? Ошибки вычислений? Тестер хорош только для UX.

Сетевой трафик, если это не HFT, то запросто. Вот нам тестеры часто приносят баги "если в иос кликнуть здесь, в андроиде — там, то новый клиент при синхронизации от сервера получает невалидный json".

Место на диске — легко. Для этого есть счетчики. Память, проц — счетчики. Ошибки вычислений, смотря каких. Если простое, то запросто. А если сопромат или тяжелые финансы — то и автотесты ничего не дадут, надо садить эксперта.

·>Я помню много-много лет назад участвовал в одном проекте, тестеры упустили интересный баг — был диалог выбора дней недели. Все тестеры (три человека!) когда тыкали "случайно" дни недели — никогда не выбирали вторник...

Пудозреваю или разгильдяи или неопытные. В таких формах №1-обязательных-кейсов == прокликать все варианты.

Здравствуйте, Sinclair, Вы писали:

I>>Тестируют всё, но в реальной жизни кейсы встречаются с разной частотой. С автотестами получается так, что тесты получаются в основном вырожденные.
S>Ага. Меня тоже всегда интересует статистика вроде "вот мы написали в 2005 году юнит-тест. Он был выполнен с тех пор более миллиона раз, и ни разу не был красным". Имело ли смысл тогда писать этот тест?

Что касается таких вещей, то действительно, есть проблема
Если код не затрагивается, то от тестов смысла мало.
Если затрагивается, то необязательно тест будет срабатывать в билде. Тест в билде просто страховка от хитрых кейсов, скажем с джуниорами или некоторыми организационными моментами. Юнит-тесты запускают девелоперы и здесь есть всякое
1 как должно быть, документация фактически
2 рефакторинг-оптимизация и поправить пока не станет зеленым
3 гарантии, т.е. на всякий случай

п.3 используется в связке с формальными методами. Например, нам нужна гарантия, что getBitAt и setBitAt ведут себя корректно.

Теоретически, для п.3 есть более мощные средства, навроде поддержки контрактов, инвариантов прямо в коде, чтото навроде как в Эйфеле. За неимением таких вещей в мейнстриме приходится жить с тем, что есть

Здравствуйте, Sinclair, Вы писали:

S>·>Т.е. тогда максимальная пауза между релизами будет 59+x дней, где x — количество дней на исследование причины падения и исправление (при условии RC мы исправляем с первой попытки).
S>Воот. Видите, вы начинаете понимать, что soak test длиной в X не даёт нам возможности уверенно релизиться чаще, чем раз в 2X, независимо от вложений в инфраструктуру.
Так это очевидно. Ключевое слово тут "уверенно", можно не "уверенно", а "осторожно". Я говорю о более гибкой модели, что если всё хорошо, то релизимся часто. Если что-то поломалось — отменяем релизы до тех пор пока не починится.

S>Поэтому там, где утечки считаются критическими, релизят редко, отводя себе время на soak tests. А ещё проектируют софт с учётом ограничений, например, выделяя компонентам бюджеты на мусор.
Это просто можно рассматирвать как soak tests независимых компонент. Но это если система хорошо делится на компоненты и бюджеты аддитивны.

S> Если у нас ограничение 100мб на месяц, и в первые три дня мы жрали по 4mb, то ждать ещё 22 дня, чтобы убедиться в нарушении ограничения нет никакого смысла. А если у нас есть компонент, ответственный за log rotation, то мы тестируем его юнит-тестом, и полагаем, что он работает.
S>В итоге soak test имеет крайне низкие шансы завалиться, поэтому 2X нам хватает с достаточной вероятностью.
Если мы сожрали много места по началу, это не значит что оно не может уменьшится, скажем, благодаря перестройке индексов, компрессией или gc, как, например, git делает.

S>А там, где утечки считаются несущественным неудобством, результаты soak test на релиз не влияют — "мы починим это в одном из следующих релизов". В итоге, например, Office 2013 с распоследними апдейтами беспрерывно срёт на диск .etl файлы, а Microsoft support включает дурака и делает вид, что ни сном про это ни духом.
Так они и SLA не обещают, ни релизов частых не делают, да и вообще похоже просто игнорируют. На винчестеры нонче дешевые цены, однако.

Здравствуйте, IB, Вы писали:

>>Я помню что ты отвечал. Ты просто попутал load tests и soak tests, а Синклер описывал совсем другую ситуацию.
IB>Антон просто привел еще один пример, показывающий, что soak тесты далеко не везде применимы, как минимум, в предлагаемом вами виде.
А я и не говорил, что soak tests везде применимы.
А Антон, как я понимаю, писал что тесты могут влиять на план релизов. Что в общем-то понятно. И автоматизация тут не причём.

>>А обосновать? Почему soak tests не подходят для коробок?
IB>Ровно по тем же причинам — UI и окружение. А для устройств это еще забавниее, так как поведение на реальной железке запросто может отличаться от эмулятора.
И что UI? И что окружение? Подробнее давай.
soak tests можно и на реальной железке запускать. Я не вижу в этом проблемы.

>>Конечно, но это всё к сабжу не имеет никакого отношения.
IB>Ну конечно, если факты не лезут в теорию, то тем хуже для фактов?
IB>Отношение самое прямое — если утечка будет не в основном сценарии, то ваш подход его не отловит, с чего и начался наш разговор.
Soak tests должны покрывать ровно те сценарии, которые оговорены в спеке, или о чём подписаны SLA. "Основной", "не основной" это какое-то кустарное деление. Мы сами принимаем решение — что основной, а что нет. И исходя из этого проектируем тесты. Поэтому, чисто по построению подход отлавливает всё.

>>Я дождусь ровно тогда, когда ты начнёшь свой рассказ. Ты не можешь предполагать свои действия?
IB> boring.. Даже стрелки красиво перевести уже не можете.
Так развлекай давай своими рассказами. А красивости я и не обещал.

>>Я представляю с кем ты работаешь... найди другую работу что-ли, чтобы правильно написанный тривиальный код у тебя не вызывал изумление.
IB>Ну откуда это желание до меня-то докопаться? Не переживайте за меня, у меня все прекрасно. Вокруг лучшие разработчики, которые делают совершенно волшебные продукты и технологии.
IB>Не обо мне речь.
Неужели обо мне? Чем моя персона тебя так впечатлила и заинтересовала? В чём для тебя ценность моего изумительного кода?

>>Может быть, но для нас — достаточно. Факапы — ловит, внимания не требует. Простое решение, как говорится, дёшево и сердито.
IB> как я уже говорил — ктож вам доктор?
Ты тут вроде диагнозы расставляешь.

IB>>>Или надо объяснять, что число пользователей может быть даже большим из-за того, что проблема вылезет не сразу?
>>Не надо это объяснять, ибо это оффтоп.
IB>Ну какой же это оффтоп? Это же и есть тема нашего разговора — пропускает ваш подход серьезные ошибки или нет. Если упомянутые выше ошибки попадают под категорию серезных, значит ваш подход не работает, что, собственно и требовалось доказать.
У нас — пока не пропустил. Это, конечно, не 100% гарантия, но сама структура тестов позволяет на них полагаться.

IB>>>Какой у вас однако стек короткий... Например, вы заменили "организацию процесса тестирования" на "тест".
>>Так ведь это не важно.
IB>То есть подмена понятий была, но это не важно? Забавно, и как после этого с вами вообще конструктивно разговаривать?
Это не было подменой понятий, а уточнением. Тест без процесса — дохлый код.

>>"тест" тоже существует, который ты заставил меня написать.
IB>Ранее вы утверждали, что теста нет, так как вы целиком доверяете конфигурации. Так есть тест или нет? Или вы показания на лету меняете?
У нас теста нет в требуемом тобой виде, то что ты хочешь называть тестом. А по факту — есть.

>>Правда огранизация процесса — лучше.
IB>Она не может быть лучше или хуже, это не взаимозаменяемые вещи.
В общем случае да, но иногда хорошо поставленный процесс может заменить тесты. В нашем случае процесс проще в реализации и поддержке, а результат такой же.

Здравствуйте, Ikemefula, Вы писали:

I>>>Нужно помнить ,что условия естественные, а значит у юзера не может быть открыто одновременно 1000 форм
I>·>Почему ты от авто-тестов ожидаешь падения всего (т.е. модификация кода повлекла изменение всего — всё менять!!111) и считаешь это чем-то ужасным, а в той же ситуации ты не требуешь, чтобы юзер открыл всё и проверил то же вручную?
I>Это ж элементарно. Вот твоя вики, раз уж тебе она так нравится
I>

I>Integration testing typically still relies heavily on humans testing manually; high-level or global-scope testing can be difficult to automate, such that manual testing often appears faster and cheaper.

I>Вот взять скажем, форму составленную из контролов на html.css. Внезапно, что бы дать хоть какие то гарантии, нужен эталонный css процессор. Такого в природе нет и никогда не будет. Все что можно — выдумывать эвристики, эффективность и результативность каждой из которых нужно проверять экспериментально.
Опять непонятно о чём ты говоришь. Если UX — то да, только человеки, я и не спорил никогда. Если функциональность — selenium в зубы, и вперёд, на баррикады.

I>·>Совсем не тоже самое. Это значит у них такая организация классная, что команды между собой взаимодействуют как чужие.
I>Если в конторе больше чем пара сотен человек, то сорганизовать команды что бы все чотко было, не выйдет.
I>Одним нужно релизиться раз в неделю. Другим — раз в месяц. Третьим — раз в год. Библиотеку пилит четвертая команда. Всё — конфликт интересов. Или уравниловка, или 3rd-party-like.
Можно всегда пойти к овнерам библиотеки и поговорить — и оценить риски|"непредвиденные артефакты" из первых уст. А не сидеть в своём silo.

I>>>А ты ответы на вопросы читаешь ? Внимательно — "никакого". И уже давно, потому что перешли на UI
I>·>А тут тоже всё просто — если UI библиотека плохо поддаётся автотестам, то её лучше выкинуть.
I>Это практически про любой UI. Хорошо покрываются только точечные кейсы для проверки регрессии.
А так же функциональные тесты: в поле записать значение, поставить тикбокс, нажать кнопку, проверить, что другое поле имеет ожидаемое значение и в БД появилась правильная запись аудита.

I>·>А какие авто-тесты присутствовали?
I>Я уже не могу вспомнить
А присутствовали ли вообще? А то выяснится сейчас, что авто-тестов никаких не было, или были но на них давно забили, поэтому они и не помогли, нашли только вручную.

I>>>Я ж говорил — всего пару десятков. На самом деле у нас нет задачи все 8000 тыщ покрывать. Кастомер такой задачи не ставит.
I>·>А почему ты это требуешь от авто-тестов? Вроде задачи такой нет, а как появляются авто-тесты, так сразу вдруг надо все 8000.
I>ты уже третий раз задаёшь вопрос. Посмотри предыдущие ответы.
Извини, я их не очень понял. Сформулируй чётко ещё раз, плз.

I>>>Есть, поддерживаются на уровне библиотеки. Синтаксической поддержки — нет.
I>·>Да пусть поддерживаются. Но mockito работает на уровне языка, а не библиотеки. mockito никак с swing не связан. Зачем это всё мешать в кучу?
I>И это вполне достаточно. Ты не волнуйся — свинг никакой не особенный, эвенты есть во всех либах.
Смелое заявление, но очевидно ошибочное.

I>>>Я хотел сказать что вы тестируете именно то, что делает реализация. Поскольку вы делаете это сознательно, то это уже преступление
I>·>Почему? Собственно юнит-тесты — тесты реализации.
I>Вот-вот.
Так почему преступление-то?

I>>>Баги при такой работе вылазят постоянно, ибо практически всегда это новые кейсы
I>·>Зависит от того, насколько качественно покрыта тестами функциональность.
I>Я снова покажу тебе вики, поскольку ты веришь только ей
Ты даёшь количественные оценки, "постоянно", "всегда", а вики пишет о принципиальных ограничениях. Хорошо покрыто — баги вылазят изредка, кейсы иногда новые. Плохо покрыто — вылазят постоянно, ибо практически всегда это новые кейсы.

I>"code for a unit test is likely to be at least as buggy as the code it is testing"
I>"As a result, for every line of code written, programmers often need 3 to 5 lines of test code"
I>"Testing will not catch every error in the program, since it cannot evaluate every execution path in any but the most trivial programs"
Логично. Но если юнит-тестирование не ловит все ошибки, это не значит что оно не ловит ошибки.

I>"In order to guarantee correct behavior for every execution path and every possible input, and ensure the absence of errors, other techniques are required, namely the application of formal methods to proving that a software component has no unexpected behavior."
Это редко требуется. Только для Ядерных Реакторов™. Эти методы сильно дороже юнит-тестирования.

I>"Another challenge related to writing the unit tests is the difficulty of setting up realistic and useful tests"
difficulty — да. А кто обещал что будет легко? Писать любой хороший код — difficult.

В общем я не понимаю к чему всё это. Мне это давно всё известно, но мне не важно, что unit-testing это не панацея. Мне достаточно, что оно даёт очень много полезностей.

I>>>Что значит уже спланирована ? как мне посмотреть, скажем, баги связанные с компонентом XXX, проверить, сколько вреени на них ушло, какие девелоперы их фиксили, какие компоненты патчились в тех же коммитах ?
I>·>Ещё раз, баги идут в трекер.
I>Меня интересует аналитика. Как по вашей истории коммитов получить аналитику ? Вот есть компонент XXX. Как узнать затраты, структуру затрат и тд и тд ?
Какого типа аналитику? Для чего эта аналитика будет использоваться? Обозначь цель.

I>>>При этом из за косвенного влияния ФПС падает, а следовательно количество ресурсов затраченых на работу самой апликачки.
I>·>Какого такого косвенного влияния? Нет никакого магического косвенного влияния. В конце концов, если ваша тестовая система настолько тяжелая, её можно на другом хосте запускать и по оптике...
I>Все софтварные компоненты влияют друг на друга. Косвенно — через кеш, адресное пространство, виртуальную память, Garbage Collection и тд и тд и тд.
I>Более того — сторонние процесс, если активны, влияют точно так же. а иногда даже сильнее.
А как именно? Ты вырази это в виде цифр и метрик, и вдруг выяснится что ничего особо такого магического в этом нет, простая арифметика. Тем более для UI (не путай с CGI), который по компьютерым меркам — жутко медленный и совершенно нетребовательный.

I>>>Правда. Если ты запустишь нагрузочный тест, сам же просил, то именно так и будет.
I>·>Для UI? слабо верится.
I>Именно. UI он очень особый. Даже профайлер очень часто маскирует кучу проблем и выдаёт зачастую нереальные.
I>Логирование тоже имеет влияние. Казалось бы — всего лишь UI, да ?
Логгирование/статистику надо уметь делать, особенно если важен микросекундный уровень (не верю что такое нужно в UI). У нас, скажем, логгирование работает в других тредах (ядрах CPU) и шлёт UDP-пакеты. Поэтому влияние минимально.
В общем да, проблемы есть, и нетривиальные. Но всё решаемо.

I>>>Вот есть у тебя рисовалка — берём раскрываем на весь экран, разрешение чем больше тем лучше, вгружаем конские данные, что бы на одном экране было как можно больше объектов и наблюдаем результат. Можно увеличить частоту некоторых таймеров, частоту опроса мыши поднять и тд и тд.
I>·>Только не надо говорить, что это можно сделать только вручную. Скорее наоборот — только автоматически. Даже выбора больше — можно сделать виртуальный экран размером 20000*10000 и проверять нужный fps, а вот человек это сделать не сможет.
I>Это делается очень легко Пишешь в углу экрана цифры и всё. Можно фпс, можно время отрисовки фрейма.
И как юзер будет смотреть на экран 20000*10000? Мониторов вроде таких ещё не изобрели, либо стоят дохрена.

I>>>Тестируют всё, но в реальной жизни кейсы встречаются с разной частотой. С автотестами получается так, что тесты получаются в основном вырожденные.
I>·>Пусть, жалко что-ли? Компьютер железный, будет и редкие случаи перетестировать постоянно.
I>"перетестировать" == проверки регрессии.
Сабж — типичная регрессия.

I>·>Об автоматизации именно функциональности я и говорил всё время. Я сразу поделил UI на функциональность и UX. И да, второе хрен протестируешь. Поэтому да, если в проекте 95% UX и 5% функциональности, то работы автотестам мало.
I>UX это "юзер ошибается, потому что кнопки не в том порядке"
Или если кнопка для человека выглядит как недоступной, но нажать можно.

I>Функциональность начинается с "кнопка недоступна или имеет чужой тайтл"
Это элементарно автоматизируется. "Нажать кнопку с тайтлом Save." — "упс, у нас нет такой кнопки!".

I>·>Так опять от приложения зависит. CD Ejector да, пара кнопок и всё. А если тебе для воспроизведения ситуации нужно создать админа, компанию задав куча параметров, в компании юзера, для юзера создать инструмент, задать роли, и т.п., т.д. Да, можешь мышой, но это будет занимать 100 кликов и 500 нажатий клавиш. А авто-тесты имеют это всё готовым, берёшь начальный сценарий и продолжаешь вариации.
I> Я просто начну с поиска багов при создании админов и прочих начальных параметров. Уже на этапе создания админа независимо от количества тестов можно сходу влупить десяток другой кейсов. Не факт что найдется чтото, но шансы неплохие.
I>Вообще, компоненты которые спрятаны от массового юзера и покрытые авто-тестами имеют обыкновение содержать целую пропасть багов.
А для создания админа может и не быть UI, может быть в prod используется LDAP, а для отладки локально нужно выполнить SQL или послать REST-запрос. Удачи, товарищ кнопкодав...

I>>>Смотря для каких масштабов. Затраты на хорошо поставленый процесс и подготовку хотя бы одного тестера, энвайрмент и тд, уже больше по бюджету многих проектов.
I>·>Вот и говорю — жадность или бедность.
I>Это здоровый прагматизм. Перфекционизм окупается крайне редко, исключительно там, где цена ошибки крайне высока.
А ещё есть технический долг. Начать проект без оглядки на авто-тестирование — сразу минус в карму. Сейчас ты сделаешь всё побыстрее, подешевле, а потом хоть потоп.

I>>>Яндекс это кучка разных направлений, приложений, проектов, все это практически ничем от стартапа не отличатся. Если на каждую мелочевку подключать всю мощ Яндекса, то наверх всплывет столько уродцев, что вспотеешь фильтровать. Потому и надо в больших конторах ограничивать бюджеты, а то спокойно какой нибудь landing page продукта сожрёт чуть не весь профит.
I>·>Что-то как-то кустарно звучит. Вон гугл хвалится своим 2-миллиардным единым репозиторием кода и всех тулзов вокруг. И начать очередной CD Ejector проще в готовой инфраструктуре, чем с нуля.
I>И мы знаем из истории, что у Гугла уже всплыло столько уродцев, что хватит на целую индустрию.
I>Всех их пришлось закопать, а бабла они сожрали столько, что не передать словами.
Не поверю, что инфраструктура тут сыграла хоть какую-то значительную роль в провале. Скорее наоборот, с silo инфраструктурой денег бы сожралось гораздо больше. А так, делая уродцев часть сожранных денег уходило и на развитие инфры, уродцы может и сдохли, а технологии остались.

I>Ты в курсе, что гугл теперь режут на части ? https://en.wikipedia.org/wiki/Alphabet_Inc.
Юридически, но технически вроде всё остаётся на месте.

I>>>Тестер находит такие вещи гораздо лучше.
I>·>Не верю. Сетевой трафик? Место на диске? Память? Проц? Ошибки вычислений? Тестер хорош только для UX.
I>Сетевой трафик, если это не HFT, то запросто. Вот нам тестеры часто приносят баги "если в иос кликнуть здесь, в андроиде — там, то новый клиент при синхронизации от сервера получает невалидный json".
Невалидный json от сервера? Это пипец. И причём тут UI?
Это не совсем сетевой трафик.

I>Место на диске — легко. Для этого есть счетчики. Память, проц — счетчики. Ошибки вычислений, смотря каких. Если простое, то запросто. А если сопромат или тяжелые финансы — то и автотесты ничего не дадут, надо садить эксперта.
Я понимаю, что всё можно сделать вручную. Толпа людей вполне может быть эквивалентна Машине Тьюринга... Но это, мягко говоря, не совсем хороший подход. Если можно автоматизировать — нужно автоматизировать, если нельзя автоматизировать — что можно сделать чтобы стало можно?

I>·>Я помню много-много лет назад участвовал в одном проекте, тестеры упустили интересный баг — был диалог выбора дней недели. Все тестеры (три человека!) когда тыкали "случайно" дни недели — никогда не выбирали вторник...
I>Пудозреваю или разгильдяи или неопытные. В таких формах №1-обязательных-кейсов == прокликать все варианты.
Кликаться-то оно кликлалось, но неправильно устаравливался планировщик.. А чтобы тестировать планировщик надо было играться с виндовым системным временем. Короче такой тест был жутко хитрый, с огромным количеством кликов мыши, аккуратно проверять для каждого дня недели (и их разных комбинаций) было жутко сложно и долго, легко запутаться.

У нас, кстати, есть, как мы называем, Машина Времени, специальный способ из тестов рулить временем (а система выполняется на 100+ хостах сразу).

Здравствуйте, ·, Вы писали:

I>>Это ж элементарно. Вот твоя вики, раз уж тебе она так нравится
I>>

I>>Integration testing typically still relies heavily on humans testing manually; high-level or global-scope testing can be difficult to automate, such that manual testing often appears faster and cheaper.

·>Опять непонятно о чём ты говоришь. Если UX — то да, только человеки, я и не спорил никогда. Если функциональность — selenium в зубы, и вперёд, на баррикады.

Все понятно, селениум это приложение целиком или почти целиком. Собтсвенно про эти случаи и сказано.

I>>Одним нужно релизиться раз в неделю. Другим — раз в месяц. Третьим — раз в год. Библиотеку пилит четвертая команда. Всё — конфликт интересов. Или уравниловка, или 3rd-party-like.
·>Можно всегда пойти к овнерам библиотеки и поговорить — и оценить риски|"непредвиденные артефакты" из первых уст.

Это только так кажется. Овнер библиотеки это менеджер и совершенно точно будет сильно вряд ли в курсе всех деталей разработки. Все детали есть только в одном месте — в коде.
Какие именно для тебя детали критичны — никто не знает.

I>>Это практически про любой UI. Хорошо покрываются только точечные кейсы для проверки регрессии.
·>А так же функциональные тесты: в поле записать значение, поставить тикбокс, нажать кнопку, проверить, что другое поле имеет ожидаемое значение и в БД появилась правильная запись аудита.

Про это сказано в цитате выше. Здесь на самом деле бесконечное количество кейсов, особенно в браузере.

·>А присутствовали ли вообще? А то выяснится сейчас, что авто-тестов никаких не было, или были но на них давно забили, поэтому они и не помогли, нашли только вручную.

Да, один ты умный.

I>>·>А почему ты это требуешь от авто-тестов? Вроде задачи такой нет, а как появляются авто-тесты, так сразу вдруг надо все 8000.
I>>ты уже третий раз задаёшь вопрос. Посмотри предыдущие ответы.
·>Извини, я их не очень понял. Сформулируй чётко ещё раз, плз.

Уже сказал — в обоих случаях два десятка. А 8000 это что бы ты масштабы непротестированой области понимал.

I>>И это вполне достаточно. Ты не волнуйся — свинг никакой не особенный, эвенты есть во всех либах.
·>Смелое заявление, но очевидно ошибочное.

Очевидно — нет. Вместо эвентов кое где вводятся кастомные схемы навроде

private void finish() {
    component1.refresh(true);
    component2.update();
    component3.invalidate(Invalidate.Full);
    component4.setDirty(true);
}

I>>·>Почему? Собственно юнит-тесты — тесты реализации.
I>>Вот-вот.
·>Так почему преступление-то?

Синклер ответил рядом. Тесты никогда не тестируют реализацию. Они тестируют исключительно ожидания клиентской части. Это называется абстракция, т.е. изоляция клиента от знания ненужных деталей реализации.
Тесты сами по себе фиксируют внешний АПИ. Ты дополнительно к этому жостко фиксируешь еще и реализацию.

Такие вещи проще, надежнее и эффективнее реализовывать не на тестах, а на внятных формальных моделях, которые поддаются анализу.
Отсюда есть такое взгляд на моки — моки в своем собтсвенном коде есть гарантия говнодизайна.

·>Логично. Но если юнит-тестирование не ловит все ошибки, это не значит что оно не ловит ошибки.

1 Оно ловит узкий класс ошибок. В основном это простейшие случаи.
2 оно четко отделено от интеграционного, а у тебя чуть не всё подряд есть юнит-тест.

I>>"In order to guarantee correct behavior for every execution path and every possible input, and ensure the absence of errors, other techniques are required, namely the application of formal methods to proving that a software component has no unexpected behavior."
·>Это редко требуется. Только для Ядерных Реакторов™. Эти методы сильно дороже юнит-тестирования.

Наоборот. Если тебе нужн протокол, то нужно брать внятную формальную модель на каком нибудь автомате.
Вместо лапши из if-else нужно брать pattern matching. Обработка строк это большей частью внятные грамматики и реализация их с помощью тех же регэкспов.

Кроме того, вещи навроде контрактов, инвариантов, пред-, пост-условий дают сами по себе гораздо больше пользы. А _вместе_ с юнит-тестами это вообще чудеса.

I>>Меня интересует аналитика. Как по вашей истории коммитов получить аналитику ? Вот есть компонент XXX. Как узнать затраты, структуру затрат и тд и тд ?
·>Какого типа аналитику? Для чего эта аналитика будет использоваться? Обозначь цель.

Цель — обнаружение проблем в разработке, оптимизация процесса в долговременном масштабе — год-два-пять. Например я хочу знать наиболее проблемные компоненты. Или девелоперов, у которых много реопенов, или девелоперов, у которых крайне мало багов вообще.

I>>Более того — сторонние процесс, если активны, влияют точно так же. а иногда даже сильнее.
·>А как именно? Ты вырази это в виде цифр и метрик, и вдруг выяснится что ничего особо такого магического в этом нет, простая арифметика. Тем более для UI (не путай с CGI), который по компьютерым меркам — жутко медленный и совершенно нетребовательный.

Это так кажется. "жутко медленный" это было примерно 15 лет назад.
Для UI надо 50-60 фпс в динамике и 0.3-0.5 секунды отклик в статике.

I>>Логирование тоже имеет влияние. Казалось бы — всего лишь UI, да ?
·>Логгирование/статистику надо уметь делать, особенно если важен микросекундный уровень (не верю что такое нужно в UI). У нас, скажем, логгирование работает в других тредах (ядрах CPU) и шлёт UDP-пакеты. Поэтому влияние минимально.
·>В общем да, проблемы есть, и нетривиальные. Но всё решаемо.

Одна песчинка ничего не весит. И 10 — ничего. И даже 100 — ничего. И 1000 — тоже ничего.
Следует ли из этого, что и самосвал песчинок ничего не весит ?

I>>Это делается очень легко Пишешь в углу экрана цифры и всё. Можно фпс, можно время отрисовки фрейма.
·>И как юзер будет смотреть на экран 20000*10000? Мониторов вроде таких ещё не изобрели, либо стоят дохрена.

20000*10000*32 бита = 6.4Gbit пропускная способность. Т.е. на три порядка выше DDR4, удачи в оптимизациях !
Глядишь, через 5-6 поколений архитектур приблизишься к успеху

I>>"перетестировать" == проверки регрессии.
·>Сабж — типичная регрессия.

Когда ты берёшь либу в хрен знает каком качестве, то вообще не знаешь, ни что в самой либе, ни что в твоем приложения. Поэтому нужно искать не только старые баги, но и новые, к чему авто-тесты принципиально непригодны.

I>>UX это "юзер ошибается, потому что кнопки не в том порядке"
·>Или если кнопка для человека выглядит как недоступной, но нажать можно.

Ну да, кнока может быть даже доступной для клика мышом но юзер не узнает, ибо не видит. Скажем, такое бывает, когда из за конского DOM в некоторых либах, берут хитрую обработку эвентов с привязкой к координатам.

I>>Функциональность начинается с "кнопка недоступна или имеет чужой тайтл"
·>Это элементарно автоматизируется. "Нажать кнопку с тайтлом Save." — "упс, у нас нет такой кнопки!".

Проверяем твою уверенность. По ссылке ниже в хроме найди "read" поиском. Должно быть 3 вхождения
http://www.w3schools.com/cssref/tryit.asp?filename=trycss_content_string
Попробуй скопировать каждый из этих трёх в клипборд и проверь что же скопировалось.
Идею понял ?

I>>Вообще, компоненты которые спрятаны от массового юзера и покрытые авто-тестами имеют обыкновение содержать целую пропасть багов.
·>А для создания админа может и не быть UI, может быть в prod используется LDAP, а для отладки локально нужно выполнить SQL или послать REST-запрос. Удачи, товарищ кнопкодав...

Если нет UI то мануальщику там делать нечего.

I>>Это здоровый прагматизм. Перфекционизм окупается крайне редко, исключительно там, где цена ошибки крайне высока.
·>А ещё есть технический долг. Начать проект без оглядки на авто-тестирование — сразу минус в карму. Сейчас ты сделаешь всё побыстрее, подешевле, а потом хоть потоп.

1. технический долг страшен исключительно в долгосрочной перспективе. Далеко не все проекты такие.
2. часть проектов принципиально одноразовые, прототипы, пруфы, пилотные и тд и тд. Цель — узнать, что будет дальше.
3. Ты снова забыл про разную цену ошибок

I>>И мы знаем из истории, что у Гугла уже всплыло столько уродцев, что хватит на целую индустрию.
I>>Всех их пришлось закопать, а бабла они сожрали столько, что не передать словами.
·>Не поверю, что инфраструктура тут сыграла хоть какую-то значительную роль в провале. Скорее наоборот, с silo инфраструктурой денег бы сожралось гораздо больше. А так, делая уродцев часть сожранных денег уходило и на развитие инфры, уродцы может и сдохли, а технологии остались.

Это теоретически, если предположить что гугл не глядя ни на что будет доводить до юзеров всех уродцев. На практике, если куча денег вложена а результата все ещ нет, проект нещадно режется.

"технологии остались" —
1 технологии для реализации уродцев в основном пригодны для изготовления уродцев.
2 технологии сильно второстепенны, их стоимость около нуля.

I>>Ты в курсе, что гугл теперь режут на части ? https://en.wikipedia.org/wiki/Alphabet_Inc.
·>Юридически, но технически вроде всё остаётся на месте.

Технически у подразделений в разных конторах появляется целый стек менеджеров которые не в курсе дел у соседей.

I>>·>Не верю. Сетевой трафик? Место на диске? Память? Проц? Ошибки вычислений? Тестер хорош только для UX.
I>>Сетевой трафик, если это не HFT, то запросто. Вот нам тестеры часто приносят баги "если в иос кликнуть здесь, в андроиде — там, то новый клиент при синхронизации от сервера получает невалидный json".
·>Невалидный json от сервера? Это пипец. И причём тут UI?

А сетевой трафик это UI ? А место на диске ? А память ? А проц ?

·>Это не совсем сетевой трафик.

Пудозреваю, ты про нагрузку. Счетчики никто не отменял. Рисуется себе картинка по каждому счетчику и все. В конце сессии смотришь, чего худо, а чего — нет. Элементарно

·>Я понимаю, что всё можно сделать вручную. Толпа людей вполне может быть эквивалентна Машине Тьюринга... Но это, мягко говоря, не совсем хороший подход. Если можно автоматизировать — нужно автоматизировать, если нельзя автоматизировать — что можно сделать чтобы стало можно?

"Автоматизировать" человеческий фактор пока еще никто не научился.

I>>Пудозреваю или разгильдяи или неопытные. В таких формах №1-обязательных-кейсов == прокликать все варианты.
·>Кликаться-то оно кликлалось, но неправильно устаравливался планировщик.. А чтобы тестировать планировщик надо было играться с виндовым системным временем. Короче такой тест был жутко хитрый, с огромным количеством кликов мыши, аккуратно проверять для каждого дня недели (и их разных комбинаций) было жутко сложно и долго, легко запутаться.

Сначала ты сказал, что вторники никто не проверил. А оказалось, планировщик был не той системы. Жутко хитрый — это значит, что количество багов в коде примерно равно количеству багов в коде тестов.

·>У нас, кстати, есть, как мы называем, Машина Времени, специальный способ из тестов рулить временем (а система выполняется на 100+ хостах сразу).

Так себе.

Здравствуйте, ·, Вы писали:
·>А Антон, как я понимаю, писал что тесты могут влиять на план релизов. Что в общем-то понятно. И автоматизация тут не причём.
Я говорил о том, что план релизов может влиять на возможность выполнять те или иные тесты. Поэтому утверждения вроде "медленную утечку всегда можно предотвратить при помощи soak test" — неверное. В ситуации, когда нужно релизиться 20го, а RC получен только 10го, дождаться результатов 30-дневного soak test невозможно.
Поэтому для типичного коробочного приложения проще выпустить как есть, а через 20 дней поискать workaround. Может оказаться, что одна KB article с объяснением, как отобрать у приложения права на запись в %TEMP%\Voice\log, будет стоить на порядок дешевле, чем перенос сроков релиза на месяц-другой.

Здравствуйте, Sinclair, Вы писали:

S>·>А Антон, как я понимаю, писал что тесты могут влиять на план релизов. Что в общем-то понятно. И автоматизация тут не причём.
S>Я говорил о том, что план релизов может влиять на возможность выполнять те или иные тесты. Поэтому утверждения вроде "медленную утечку всегда можно предотвратить при помощи soak test" — неверное. В ситуации, когда нужно релизиться 20го, а RC получен только 10го, дождаться результатов 30-дневного soak test невозможно.
S>Поэтому для типичного коробочного приложения проще выпустить как есть, а через 20 дней поискать workaround. Может оказаться, что одна KB article с объяснением, как отобрать у приложения права на запись в %TEMP%\Voice\log, будет стоить на порядок дешевле, чем перенос сроков релиза на месяц-другой.
Эээ, не совсем согласен. Perftests обычно определяются требованиями качества и всякими договорами типа SLA.
Исходя из этого строят планы контроля качества, а из этого уже планы релизов.
С другой стороны, продукты типа сабжевого распространяют AS IS.
И качество определяют исходя из баланса стоимости и репутации.

Здравствуйте, Ikemefula, Вы писали:

I>>>Это ж элементарно. Вот твоя вики, раз уж тебе она так нравится
I>>>

I>>>Integration testing typically still relies heavily on humans testing manually; high-level or global-scope testing can be difficult to automate, such that manual testing often appears faster and cheaper.

I>·>Опять непонятно о чём ты говоришь. Если UX — то да, только человеки, я и не спорил никогда. Если функциональность — selenium в зубы, и вперёд, на баррикады.
I>Все понятно, селениум это приложение целиком или почти целиком. Собтсвенно про эти случаи и сказано.
Я не понимаю что ты хочешь сказать. Вроде начали с того, что некое гипотетическое изменение, о ужас, роняет 100500 тестов. И теперь их все надо фиксить. А то что вручную тоже _надо_ (хотя, конечно, можно и забить) проверить эти же 100500 случаев — ты не вспоминаешь. И да, падение 100500 тестов бывает обычно в приложении целиком.

I>>>Одним нужно релизиться раз в неделю. Другим — раз в месяц. Третьим — раз в год. Библиотеку пилит четвертая команда. Всё — конфликт интересов. Или уравниловка, или 3rd-party-like.
I>·>Можно всегда пойти к овнерам библиотеки и поговорить — и оценить риски|"непредвиденные артефакты" из первых уст.
I>Это только так кажется. Овнер библиотеки это менеджер и совершенно точно будет сильно вряд ли в курсе всех деталей разработки. Все детали есть только в одном месте — в коде.
I>Какие именно для тебя детали критичны — никто не знает.
Это уж вообще крутая отмаза. Так можно что угодно отмазать: и команда, сидящая этажом выше, и коллега за соседним столом, и "я вчерашний" — всё 3rd-party-like.

I>>>Это практически про любой UI. Хорошо покрываются только точечные кейсы для проверки регрессии.
I>·>А так же функциональные тесты: в поле записать значение, поставить тикбокс, нажать кнопку, проверить, что другое поле имеет ожидаемое значение и в БД появилась правильная запись аудита.
I>Про это сказано в цитате выше. Здесь на самом деле бесконечное количество кейсов, особенно в браузере.
Близкое к бесконечному количество кейсов автоматически тестировать на порядки проще. У нас более +10к функциональных тестов, включая всевозможные API и WUI, занимает ~25 минут на кластере... Вручную это займёт месяца два, полагаю.

I>>>·>А почему ты это требуешь от авто-тестов? Вроде задачи такой нет, а как появляются авто-тесты, так сразу вдруг надо все 8000.
I>>>ты уже третий раз задаёшь вопрос. Посмотри предыдущие ответы.
I>·>Извини, я их не очень понял. Сформулируй чётко ещё раз, плз.
I>Уже сказал — в обоих случаях два десятка. А 8000 это что бы ты масштабы непротестированой области понимал.
Понятно сейчас. Ты просто отвечал на вопрос который я не задавал, поэтому я и не понимал ответы. Я масштабы и так представляю. Не понимаю только зачем ты это упомянул. Ты, вроде, наоборот ручное тестирование защищаешь, а приводишь аргументы в пользу автоматического — чем больше масштаб, тем более эффективно авто, чем ручное.

I>>>И это вполне достаточно. Ты не волнуйся — свинг никакой не особенный, эвенты есть во всех либах.
I>·>Смелое заявление, но очевидно ошибочное.
I>Очевидно — нет. Вместо эвентов кое где вводятся кастомные схемы навроде
Разве неочевидно, что "кастомная схема навроде" никоим образом эвентами не является?

I>>>Вот-вот.
I>·>Так почему преступление-то?
I>Синклер ответил рядом. Тесты никогда не тестируют реализацию. Они тестируют исключительно ожидания клиентской части. Это называется абстракция, т.е. изоляция клиента от знания ненужных деталей реализации.
I>Тесты сами по себе фиксируют внешний АПИ. Ты дополнительно к этому жостко фиксируешь еще и реализацию.
Разные типы тестов имеют разные цели, средства, сильные и слабые стороны. Ты говоришь слишком общими словами, поэтому смысла никакого.

I>Такие вещи проще, надежнее и эффективнее реализовывать не на тестах, а на внятных формальных моделях, которые поддаются анализу.
Разные задачи — разные решения. Не всё имеет смысл формализовать моделями.

I>Отсюда есть такое взгляд на моки — моки в своем собтсвенном коде есть гарантия говнодизайна.
Хм. Видимо, просто не умеешь готовить. Моки — инструмент. Можно применять с пользой.

I>·>Логично. Но если юнит-тестирование не ловит все ошибки, это не значит что оно не ловит ошибки.
I>1 Оно ловит узкий класс ошибок. В основном это простейшие случаи.
В типичной разработке 90% ошибок — простейшие случаи. Этот узкий класс ошибок является самым массивным.

I>2 оно четко отделено от интеграционного, а у тебя чуть не всё подряд есть юнит-тест.
Почему ты так решил? У нас есть юнит, интеграционные, функциональные, системные тесты и тесты производительности. Всё чётко отделено.

I>>>"In order to guarantee correct behavior for every execution path and every possible input, and ensure the absence of errors, other techniques are required, namely the application of formal methods to proving that a software component has no unexpected behavior."
I>·>Это редко требуется. Только для Ядерных Реакторов™. Эти методы сильно дороже юнит-тестирования.
I>Наоборот. Если тебе нужн протокол, то нужно брать внятную формальную модель на каком нибудь автомате.
I>Вместо лапши из if-else нужно брать pattern matching. Обработка строк это большей частью внятные грамматики и реализация их с помощью тех же регэкспов.
Чтобы всё это имело смысл сразу — нужно разрабатывать софт для Ядерных Реакторов с циклом релизов раз в 10 лет. Чтобы взять паттерн матчинг, надо чтобы у тебя была лапша if-else сразу, в 500-страничном фича-реквесте. При нормальной итеративной разработке изначально вообще ифов нет, после первого фидбака — 1 if, потом 3 if, через пару итераций уже 5, а потом уже можно взять и паттерн матчинг, и автомат, и чёрта лысого — но тесты должны проходить как ни бывало. Рефакторинг называется.

I>Кроме того, вещи навроде контрактов, инвариантов, пред-, пост-условий дают сами по себе гораздо больше пользы. А _вместе_ с юнит-тестами это вообще чудеса.
Для постоянно меняющихся бизнес-требований? Сомнительно... В общем сильно зависит от задач.

I>>>Меня интересует аналитика. Как по вашей истории коммитов получить аналитику ? Вот есть компонент XXX. Как узнать затраты, структуру затрат и тд и тд ?
I>·>Какого типа аналитику? Для чего эта аналитика будет использоваться? Обозначь цель.
I>Цель — обнаружение проблем в разработке, оптимизация процесса в долговременном масштабе — год-два-пять.
Коммиты о затратах не говорят. Может корреляция и есть, но зависимости нет.

I>Например я хочу знать наиболее проблемные компоненты.
Проблемность компонент смотрится в issue tracker. Я же говорю, что для проблем (issues) у нас есть issue tracker. А аннотации в коде — для разработки новых историй (фичи).

I>Или девелоперов, у которых много реопенов, или девелоперов, у которых крайне мало багов вообще.
У нас нет code ownership. Ещё мы часто в парах работаем...

I>>>Более того — сторонние процесс, если активны, влияют точно так же. а иногда даже сильнее.
I>·>А как именно? Ты вырази это в виде цифр и метрик, и вдруг выяснится что ничего особо такого магического в этом нет, простая арифметика. Тем более для UI (не путай с CGI), который по компьютерым меркам — жутко медленный и совершенно нетребовательный.
I>Это так кажется. "жутко медленный" это было примерно 15 лет назад.
I>Для UI надо 50-60 фпс в динамике и 0.3-0.5 секунды отклик в статике.
Поди ещё и среднее. Среднее время у нас около 200-300us. 0.3-0.5с это целая вечность, у нас 20мс задержка чаще чем раз в сутки это prod issue, клиенты звонят, ругаются. А такие как в UI допустимые задержки позволяют и не знать о целом классе проблем с особенностями ОС, ядрами и кешами процов, банками памяти NUMA, файловыми системами, контроллерами SATA, дисками, сетевыми картами, свитчами, деградацией оптических кабелей...
Или ты о мобильных девайсах говоришь?

I>·>Логгирование/статистику надо уметь делать, особенно если важен микросекундный уровень (не верю что такое нужно в UI). У нас, скажем, логгирование работает в других тредах (ядрах CPU) и шлёт UDP-пакеты. Поэтому влияние минимально.
I>·>В общем да, проблемы есть, и нетривиальные. Но всё решаемо.
I>Одна песчинка ничего не весит. И 10 — ничего. И даже 100 — ничего. И 1000 — тоже ничего.
I>Следует ли из этого, что и самосвал песчинок ничего не весит ?
Они весят, но весят в другом месте, не там где мы измеряем.

I>>>Это делается очень легко Пишешь в углу экрана цифры и всё. Можно фпс, можно время отрисовки фрейма.
I>·>И как юзер будет смотреть на экран 20000*10000? Мониторов вроде таких ещё не изобрели, либо стоят дохрена.
I>20000*10000*32 бита = 6.4Gbit пропускная способность. Т.е. на три порядка выше DDR4, удачи в оптимизациях !
I>Глядишь, через 5-6 поколений архитектур приблизишься к успеху
DDR3 это пиковая 2666 MB/s (мегабайт в секунду), т.е. 20 гигабит в секунду, уже Ethernet 100-гигабитный не новость. Не знаю что ты такое насчитал или в каком поколении ты живёшь. Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.

I>>>"перетестировать" == проверки регрессии.
I>·>Сабж — типичная регрессия.
I>Когда ты берёшь либу в хрен знает каком качестве, то вообще не знаешь, ни что в самой либе, ни что в твоем приложения. Поэтому нужно искать не только старые баги, но и новые, к чему авто-тесты принципиально непригодны.
Логично, но именно 99% проблем когда берёшь либу, сабж в том числе, именно регрессия.

I>>>Функциональность начинается с "кнопка недоступна или имеет чужой тайтл"
I>·>Это элементарно автоматизируется. "Нажать кнопку с тайтлом Save." — "упс, у нас нет такой кнопки!".
I>Проверяем твою уверенность. По ссылке ниже в хроме найди "read" поиском. Должно быть 3 вхождения
I>http://www.w3schools.com/cssref/tryit.asp?filename=trycss_content_string
I>Попробуй скопировать каждый из этих трёх в клипборд и проверь что же скопировалось.
I>Идею понял ?
Что можно писать код не поддающийся авто-тестированию? Да запросто. Но правильная идея в том, чтобы так не делать. У нас любая история начинается с вопроса "а как мы это покроем тестами?"

I>>>Вообще, компоненты которые спрятаны от массового юзера и покрытые авто-тестами имеют обыкновение содержать целую пропасть багов.
I>·>А для создания админа может и не быть UI, может быть в prod используется LDAP, а для отладки локально нужно выполнить SQL или послать REST-запрос. Удачи, товарищ кнопкодав...
I>Если нет UI то мануальщику там делать нечего.
UI есть, и дофига. Но некоторые функции не вынесены в UI, аутентикация или аудит, например. И мануальщики тестируют очень просто, сам наблюдал: открывают SQL Console, копипастят из вордового документа запрос и долго тупят над ошибками если что-то пошло не так.

I>>>Это здоровый прагматизм. Перфекционизм окупается крайне редко, исключительно там, где цена ошибки крайне высока.
I>·>А ещё есть технический долг. Начать проект без оглядки на авто-тестирование — сразу минус в карму. Сейчас ты сделаешь всё побыстрее, подешевле, а потом хоть потоп.
I>1. технический долг страшен исключительно в долгосрочной перспективе. Далеко не все проекты такие.
А как же карма? После смерти реинкарнируешься в VB-программиста, всю жизнь с COM воевать будешь! Му-ха-хааа!

I>2. часть проектов принципиально одноразовые, прототипы, пруфы, пилотные и тд и тд. Цель — узнать, что будет дальше.
В таких на качество тупо забивают, лишь бы скриншот снять успеть пока не гронхнулось.

I>3. Ты снова забыл про разную цену ошибок
Для меня неочевидно, что ручное тестирование дешевле автоматического.

I>·>Не поверю, что инфраструктура тут сыграла хоть какую-то значительную роль в провале. Скорее наоборот, с silo инфраструктурой денег бы сожралось гораздо больше. А так, делая уродцев часть сожранных денег уходило и на развитие инфры, уродцы может и сдохли, а технологии остались.
I>Это теоретически, если предположить что гугл не глядя ни на что будет доводить до юзеров всех уродцев. На практике, если куча денег вложена а результата все ещ нет, проект нещадно режется.
Я на 100% уверен, что у них на несколько порядков больше убитых на ранней стадии уродцев, чем доживших до вывода юзерам.

I>"технологии остались" —
I>1 технологии для реализации уродцев в основном пригодны для изготовления уродцев.
I>2 технологии сильно второстепенны, их стоимость около нуля.
Далеко не всегда.
Классический пример — ну потопали американцы на пыль на булыжнике, ну воткнули там свой флажок, толку-то от этих уродцев-марсоходов?

I>>>Ты в курсе, что гугл теперь режут на части ? https://en.wikipedia.org/wiki/Alphabet_Inc.
I>·>Юридически, но технически вроде всё остаётся на месте.
I>Технически у подразделений в разных конторах появляется целый стек менеджеров которые не в курсе дел у соседей.
Менеджеры — это не технология. Технология это их репозиторий и тулзы вокруг него.

I>>>·>Не верю. Сетевой трафик? Место на диске? Память? Проц? Ошибки вычислений? Тестер хорош только для UX.
I>>>Сетевой трафик, если это не HFT, то запросто. Вот нам тестеры часто приносят баги "если в иос кликнуть здесь, в андроиде — там, то новый клиент при синхронизации от сервера получает невалидный json".
I>·>Невалидный json от сервера? Это пипец. И причём тут UI?
I>А сетевой трафик это UI ? А место на диске ? А память ? А проц ?
Нет, но мне удивительно, что мануальные тестеры UI-аппликух приносят баги с невалидным json от сервера. Хо-хо! Мрак. Жуть. И тут кто-то мне рассказывал про протоколы, инварианты и формальные модели.

I>·>Это не совсем сетевой трафик.
I>Пудозреваю, ты про нагрузку. Счетчики никто не отменял. Рисуется себе картинка по каждому счетчику и все. В конце сессии смотришь, чего худо, а чего — нет. Элементарно
Или новая либа стала куда-то лезть в интернет..

I>·>Я понимаю, что всё можно сделать вручную. Толпа людей вполне может быть эквивалентна Машине Тьюринга... Но это, мягко говоря, не совсем хороший подход. Если можно автоматизировать — нужно автоматизировать, если нельзя автоматизировать — что можно сделать чтобы стало можно?
I>"Автоматизировать" человеческий фактор пока еще никто не научился.
Человеческий фактор можно минимизировать.

I>>>Пудозреваю или разгильдяи или неопытные. В таких формах №1-обязательных-кейсов == прокликать все варианты.
I>·>Кликаться-то оно кликлалось, но неправильно устаравливался планировщик.. А чтобы тестировать планировщик надо было играться с виндовым системным временем. Короче такой тест был жутко хитрый, с огромным количеством кликов мыши, аккуратно проверять для каждого дня недели (и их разных комбинаций) было жутко сложно и долго, легко запутаться.
I>Сначала ты сказал, что вторники никто не проверил. А оказалось, планировщик был не той системы. Жутко хитрый — это значит, что количество багов в коде примерно равно количеству багов в коде тестов.
Комбобокс кликался (что ж ему не кликаться — стандартный виндовый контрол), но неправильно функционировал в дальнейшем. А авто-тестов не было... Это было лет 15 назад, когда об этом и не слыхали.

Здравствуйте, ·, Вы писали:

S>>Поэтому для типичного коробочного приложения проще выпустить как есть, а через 20 дней поискать workaround. Может оказаться, что одна KB article с объяснением, как отобрать у приложения права на запись в %TEMP%\Voice\log, будет стоить на порядок дешевле, чем перенос сроков релиза на месяц-другой.
·>Эээ, не совсем согласен. Perftests обычно определяются требованиями качества и всякими договорами типа SLA.
Обычно, никаких договоров нету. Стандартное EULA — AS IS, with no warranties implied.
А в тех (исключительно редких) случаях, когда у нас есть прямые требования по объёму утечек или мин.продолжительности работы без техобслуживания, это учитывается с самого начала. При этом совершенно необязательно решением задачи будут именно soak tests. Ну вот попросят вас написать софт для беспилотного полёта на Юпитер — вы что, будете 7 лет RC на железке гонять?

Здравствуйте, ·, Вы писали:

I>>Все понятно, селениум это приложение целиком или почти целиком. Собтсвенно про эти случаи и сказано.
·>Я не понимаю что ты хочешь сказать. Вроде начали с того, что некое гипотетическое изменение, о ужас, роняет 100500 тестов. И теперь их все надо фиксить. А то что вручную тоже _надо_ (хотя, конечно, можно и забить) проверить эти же 100500 случаев — ты не вспоминаешь. И да, падение 100500 тестов бывает обычно в приложении целиком.

цитирую себя "регрессию нужно детектить автотестами"
снова цитирую себя "новые баги ищутся только руками"

Кроме того, UI обычно переделывается очень сильно. И очень часто — когда меняется вообще всё. Было "три радиобатона", стало "комбобоксы", потом "грид", потом "сложная многоуровневая форма", потом "explorer-like UI". И это только одна небольшая часть приложения.
С т.з. юзера все выглядит узнаваемо, с т.з. автотестов это АДъ и Израиль. Кажды раз тебе надо переписывать 100500 тестов.

I>>Какие именно для тебя детали критичны — никто не знает.
·>Это уж вообще крутая отмаза. Так можно что угодно отмазать: и команда, сидящая этажом выше, и коллега за соседним столом, и "я вчерашний" — всё 3rd-party-like.

Кто тебе сказал, что этажом выше ? Яндекс уже давно в разных городах и даже странах разработку ведёт.

I>>Про это сказано в цитате выше. Здесь на самом деле бесконечное количество кейсов, особенно в браузере.
·>Близкое к бесконечному количество кейсов автоматически тестировать на порядки проще. У нас более +10к функциональных тестов, включая всевозможные API и WUI, занимает ~25 минут на кластере... Вручную это займёт месяца два, полагаю.

API никто в своём уме в ручную не тестирует.
Это что, так трудно запомнить ? API используется программными модулями, для него естественные условия это вызов из программных модулей. Автотесты в этом случае наиболее близки к естественным условиям.

·>Понятно сейчас. Ты просто отвечал на вопрос который я не задавал, поэтому я и не понимал ответы. Я масштабы и так представляю. Не понимаю только зачем ты это упомянул. Ты, вроде, наоборот ручное тестирование защищаешь, а приводишь аргументы в пользу автоматического — чем больше масштаб, тем более эффективно авто, чем ручное.

Если ты протестировал 20 а осталось еще 7980, это значит, что нужно ожидать целую кучу всякого непотребства. Появился новый девайс, автотесты красные, а все работает хорошо. Твои действия ?
Или наоборот — всё зеленое, а UI надо переделывать, ибо выглядит коряво. Переделываем форму... и твои тесты отвалились все до единого. А живому человеку — пофигу.

I>>Очевидно — нет. Вместо эвентов кое где вводятся кастомные схемы навроде
·>Разве неочевидно, что "кастомная схема навроде" никоим образом эвентами не является?

Принципиально ничем не отличается. Событие в одном компоненте транслируется в другие в одном случае чз унифицированый интерфейс, в другом — через кастомный.

I>>Тесты сами по себе фиксируют внешний АПИ. Ты дополнительно к этому жостко фиксируешь еще и реализацию.
·>Разные типы тестов имеют разные цели, средства, сильные и слабые стороны. Ты говоришь слишком общими словами, поэтому смысла никакого.

Клиенту совершенно по барабану, кто вызовет его экшн, твой компонент напрямую, команда или еще кто.
Абсолютно без разницы, главно что бы вызвали.
А если ты прибил к реализации, то внезапно, после рефакторинга надо перелопачивать все тесты. То есть, патчить не код, что бы тесты стали зеленые, а патчить тесты, что бы стали зеленые.
Оптимизация — ровно тоже самое.

I>>Такие вещи проще, надежнее и эффективнее реализовывать не на тестах, а на внятных формальных моделях, которые поддаются анализу.
·>Разные задачи — разные решения. Не всё имеет смысл формализовать моделями.

Сложную логику — практически всю. Сложное поведение — чем больше, тем лучше. Сложное взаимодействие — целиком.

I>>1 Оно ловит узкий класс ошибок. В основном это простейшие случаи.
·>В типичной разработке 90% ошибок — простейшие случаи. Этот узкий класс ошибок является самым массивным.

В типичной разработке ошибок становится больше в зависимости от сложности, при чем зависимость сильно нелинейная. И вот эту самую сложную часть тесты ловят хуже некуда.

Скажем, что бы качественно использовать автотесты верстки, нужен эталонный CSS процессор да с мега возможностями типа "закрывает ли какой контрол марджин вот этой мульки ?".

I>>Вместо лапши из if-else нужно брать pattern matching. Обработка строк это большей частью внятные грамматики и реализация их с помощью тех же регэкспов.
·>Чтобы всё это имело смысл сразу — нужно разрабатывать софт для Ядерных Реакторов с циклом релизов раз в 10 лет. Чтобы взять паттерн матчинг, надо чтобы у тебя была лапша if-else сразу, в 500-страничном фича-реквесте.

Не надо никаких 500 страниц. Эти вещи постояно вылазят, ну по крайней мере в UI так. Чуть не любая форма на самом деле сложный автомат. Переходы, навигация унутре приложения == автомат. И тд

I>>Кроме того, вещи навроде контрактов, инвариантов, пред-, пост-условий дают сами по себе гораздо больше пользы. А _вместе_ с юнит-тестами это вообще чудеса.
·>Для постоянно меняющихся бизнес-требований? Сомнительно... В общем сильно зависит от задач.

Вот как раз для меняющихся требований это идеально работает. Убрал условие, добавил новое и всё.
Изменилось требование "операция должна начинаться с А, включать Б, заканчиваться С" и теперь все авто-тесты которые имеют к этому отношение, надо взять и пределать, потому что они отвалились.

I>>·>Какого типа аналитику? Для чего эта аналитика будет использоваться? Обозначь цель.
I>>Цель — обнаружение проблем в разработке, оптимизация процесса в долговременном масштабе — год-два-пять.
·>Коммиты о затратах не говорят. Может корреляция и есть, но зависимости нет.

И я об чем. Вещи которые трекер умеет искаропки вы заменили на ручной привод.

I>>Например я хочу знать наиболее проблемные компоненты.
·>Проблемность компонент смотрится в issue tracker. Я же говорю, что для проблем (issues) у нас есть issue tracker. А аннотации в коде — для разработки новых историй (фичи).

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

I>>Или девелоперов, у которых много реопенов, или девелоперов, у которых крайне мало багов вообще.
·>У нас нет code ownership. Ещё мы часто в парах работаем...

А при чем здесь овнершип код ? Вот сказали тебе авторизацию пофиксить, ты пофиксил. А потом в этом месте еще десяток реопенов вылез.

·>А такие как в UI допустимые задержки позволяют и не знать о целом классе проблем.

Ты выйди в реальный мир и позапускай самый разный софт. Через одну софтины лагают и даже тормозят нещадно.
Твоё сравнение с сервером не работает. Ресурсы используются принципиально иначе.
На сервере ты никогда не вгружаешь вагоны данных целиком. Для UI это вобщем норма. Позволяет реализовать адские возможности в той же визуализации.

I>>·>В общем да, проблемы есть, и нетривиальные. Но всё решаемо.
I>>Одна песчинка ничего не весит. И 10 — ничего. И даже 100 — ничего. И 1000 — тоже ничего.
I>>Следует ли из этого, что и самосвал песчинок ничего не весит ?
·>Они весят, но весят в другом месте, не там где мы измеряем.

Я могу тебе назвать не менее сотни багов связанных именно с логированием. Проявлялось именно в виде лагов в UI. Но вообще сильно уверен, что ты выдашь "просто вы не умеете..."


I>>Глядишь, через 5-6 поколений архитектур приблизишься к успеху
·>DDR3 это пиковая 2666 MB/s (мегабайт в секунду), т.е. 20 гигабит в секунду, уже Ethernet 100-гигабитный не новость. Не знаю что ты такое насчитал или в каком поколении ты живёшь. Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.

Немного обсчитался, но возможностей шины тебе по любому уже не хватает.
1 2666 это пиковая. Реальная много меньше
2 кроме UI есть и другие потребители шины
Более того, на данный момент в большинстве платформ тебе
1 не хватит адресного пространства
2 OS не сможет переварить данные если ап хватит
Итого — твои цифры взяты от балды.

I>>Когда ты берёшь либу в хрен знает каком качестве, то вообще не знаешь, ни что в самой либе, ни что в твоем приложения. Поэтому нужно искать не только старые баги, но и новые, к чему авто-тесты принципиально непригодны.
·>Логично, но именно 99% проблем когда берёшь либу, сабж в том числе, именно регрессия.

Это статистика от балды. По опыту предыдущих проектов, после перехода на новую версию UI либы тестеры всегда находили целую кучу _новых_ багов, при том что вендор гарантировал обратную совместимость. Что характерно, такие баги сложнее всего фиксить.

·>Что можно писать код не поддающийся авто-тестированию? Да запросто. Но правильная идея в том, чтобы так не делать. У нас любая история начинается с вопроса "а как мы это покроем тестами?"

А ты в курсе, что это _удорожает_ разработку ? Кроме того, где гарантия, что тестопригодные средства вообще могут дать внятное решение ?

I>>Если нет UI то мануальщику там делать нечего.
·>UI есть, и дофига. Но некоторые функции не вынесены в UI, аутентикация или аудит, например. И мануальщики тестируют очень просто, сам наблюдал: открывают SQL Console, копипастят из вордового документа запрос и долго тупят над ошибками если что-то пошло не так.

А твои авто-тесты надо полагать умеют работать на раз с кейсом "что-то пошло не так" ?

I>>3. Ты снова забыл про разную цену ошибок
·>Для меня неочевидно, что ручное тестирование дешевле автоматического.

Потому что ты никак не поймешь — рич UI и серверный бакенд это две разные вселенные.
В UI у тебя никогда не будет четкого набора требований.
Постоянно будут изменения "подвинь, перенеси, убери, подкрасы, выдели"
Регулярно будут изменения "давайте попробуем новый flow" — вот это убивает все твои тесты.
Скажем, один скрин в визард добавить гарантировано ломает вообще все тесты для этого визарда.
Нужно что бы ломались кейсы чувствительные для юзера. А вот добавление скрина в визард таким не является.

I>>Это теоретически, если предположить что гугл не глядя ни на что будет доводить до юзеров всех уродцев. На практике, если куча денег вложена а результата все ещ нет, проект нещадно режется.
·>Я на 100% уверен, что у них на несколько порядков больше убитых на ранней стадии уродцев, чем доживших до вывода юзерам.

И тем не менее Гугл лидер по количеству уродцев, при чем настолько, что во многих областях гуглу в принципе нельзя доверять.

·>Далеко не всегда.
·>Классический пример — ну потопали американцы на пыль на булыжнике, ну воткнули там свой флажок, толку-то от этих уродцев-марсоходов?

Марсоходы как раз никакие не уродцы.

I>>Технически у подразделений в разных конторах появляется целый стек менеджеров которые не в курсе дел у соседей.
·>Менеджеры — это не технология. Технология это их репозиторий и тулзы вокруг него.

Ога, так прям и вижу — дать тебе 2тб репу, так в в секунду любой компонент раздраконишь. Чтото мне кажется, будешь писать письма. Кому ? Девелопер может быть занят, ибо у него явный блокер от другой тимы. Итого — тебя поставили в очередь. Всё. Хочешь побыстрее — надо учиться писать письма вверх-вниз по стеку.

I>>А сетевой трафик это UI ? А место на диске ? А память ? А проц ?
·>Нет, но мне удивительно, что мануальные тестеры UI-аппликух приносят баги с невалидным json от сервера. Хо-хо! Мрак. Жуть. И тут кто-то мне рассказывал про протоколы, инварианты и формальные модели.

Это элементарно. Один из клиентов загоняет неверные данные, но сам рисует их корректно. Другой клиент их не может проглотить. Отсюда ясно, что нужен ответ сервера — кому что откуда пришло. Т.е. выяснить, чье подразделение сломало — тоже задача тестера.

I>>Пудозреваю, ты про нагрузку. Счетчики никто не отменял. Рисуется себе картинка по каждому счетчику и все. В конце сессии смотришь, чего худо, а чего — нет. Элементарно
·>Или новая либа стала куда-то лезть в интернет..

Открой для себя прокси-сервер.

I>>"Автоматизировать" человеческий фактор пока еще никто не научился.
·>Человеческий фактор можно минимизировать.

Это юзеров на софтварные модули заменить ? Интересная идея.

I>>Сначала ты сказал, что вторники никто не проверил. А оказалось, планировщик был не той системы. Жутко хитрый — это значит, что количество багов в коде примерно равно количеству багов в коде тестов.
·>Комбобокс кликался (что ж ему не кликаться — стандартный виндовый контрол), но неправильно функционировал в дальнейшем. А авто-тестов не было... Это было лет 15 назад, когда об этом и не слыхали.

Пудозреваю, дело совсем не в автотестах. Такие вещи сначала прокликиваются руками, а уже по результатам строятся авто-тесты.