Здравствуйте, chaotic-kotik, Вы писали:
L>>Наверное, поэтому технику юнит-тестирования до сих пор освоили считанные единицы. CK>Я не знаю где ты работаешь, но по моему опыту это не так. Практикуют все кому не лень.
Вовсе не так. Правильно применять юнит-тесты умеют единицы. В остальных случаях тесты пишут либо потому, что менеджер заставляет, либо разрождаются уродцем вроде того, что в твоей ссылке, когда уж совсем припрет.
CK>Можно с тем же успехом написать консольное приложение, которое будет как-то использовать код. Для этих целей не обязательно использовать именно юнит-тесты.
И это консольное приложение будет чем? Правильно, юнит-тестом
L>>Юнит-тесты, внимание, это не инструмент для поиска ошибок. Это инструмент, помогающий эту ошибку не допустить. Он не гарантирует отсутствие ошибок, но при правильном пользовании позволяет свести вероятность их появления к минимуму CK>С последней фразой не согласен. До стабилизации — да, юнит-тесты помогают искать ошибки, код часто меняется и запускать функциональные тесты на каждый чих — дорого и сложно. А вот юнит-тесты — в самый раз. Поэтому разработчики их и любят, пока пишешь код — видишь эффект от их использования, ну а когда код стабилизирован — не видишь, но и с этим кодом ты не работаешь.
Распространенное мнение. С позиции "одноразового кода". Много раз его слышал, и чаще всего от людей, которым в жизни не приходилось поддерживать или развивать свой собственный или чужой код. Написали — фигакс в продакшен — в следующую контору, на следующий проект. А то, что в следующей версии пришедшие на их место программисты переписывают половину этого кода, это их не касается. Они просто гения не поняли, им еще расти и расти.
CK>Основные проблемы юнит-тестов в том что они а) изолированны б) пишутся разработчиками. Изолированность, означает что тест не увидит регрессию, которая появилась из-за изменений внешней среды (изменился код, использующий твой код, по отдельности все тесты проходят, но приложение падает). Bias разработчика в том, что его код всегда будет использоваться корректно и так как он(она) предполагал.
Уже только это помогает изолировать проблемы интеграции.
L>>Здрасте. Правильные юнит-тесты — это первая и зачастую самая главная линия регрессии. Они обязаны обнаруживать сломанную функциональность просто по определению. CK>Потому что старый код редко меняется, пишется новый. Новый код неправильно конфигурирует твой компонент, который проходит все юнит-тесты. В тестах нового кода твой компонент замокан. Баг в стелс режиме едет на прод.
А у вас разработчики вообще не запускают сами систему после сборки?
В стелс режиме баг дальше QA не поедет. Там он проваливает регрессию. Возвращается разработчикам, которые сразу видят, что проблема в неправильном использовании компонента.
L>>Бывает. Когда юнит-тесты пишут без понимания их сути или просто из-под палки. CK>Либо код покрытый юнит-тестами хреново тестируют дальше, поэтому большая часть багов после них не находится.
Проблемы хреновой постановки QA ортогональны юнит-тестированию.
CK>Хорошую систему функциональных тестов сделать куда сложнее. Существуют классы ошибок, которые модульным тестирование невозможно обнаружить в принципе. Ну и еще раз повторю — юнит-тесты не находят ошибки взаимодействия компонентов.
Зато их находят интеграционные тесты. Которые во многих случаях являются теми же самыми юнит-тестами, только в качестве юнита используют интегрированный компонент.
L>>С моего последнего проекта, переданного в тестирование, ни одного креш-дампа не пришло. Так и ушел в продакшен, не предоставив мне возможности отточить классические навыки отладки. CK>У меня тоже такое было. Все зависит от проекта. Когда я один делал проект (сравнительно мало SLOC) такое было. Когда я работал на больших проектах — такого не было.
Это был очень большой и весьма сложный проект.
L>>Ой. Фаззинг — это просто модное словечко, которым называют один из вариантов написания автотеста. Только вот верить в то, что он "много находит"... ну не знаю. У вас еще все впереди CK>А ты использовал когда-нибудь фаззинг?
Еще до того, как это модное слово придумали.
CK> CK>Это не код на выборс, а большой инфраструктурный проект для fb и модульных тестов там нет (что за говнотест ты там нашел?). Можешь посмотреть на код google brotli или LZ4, там та же песня. Причина в том, что ты не напишешь нормальный юнит-тест для компрессора.
Я? Я-напишу.
CK>Что там тестировать можно модульно?
Эээ, модули. Или там весь компрессор представляет собой void compress()?
CK>Как ты себе это представляешь? Ну вот есть компонент генерирующих хаффмановский словарь — как ты узнаешь, правильно ли он сгенерирован? Захардкодишь веса или сделаешь параллельную реализацию?
Что значит "правильно"? Если есть понятие "правильно", значит, оно формализуется. А раз формализуется, значит — тестируется.
CK>Компрессоры тестируют с помощью round-trip тестов (есть и в zstd и в brotli и в lz4). Это когда берут кучу файлов и каждый из них сначала сжимают, а потом разжимают и сравнивают с оригиналом.
Так тоже можно. Но если внутрь компрессора закрался компонент с неопределенным поведением в определенном редком случае, то подобные тесты этот баг могут пропустить. И чаще всего пропускает.
Здравствуйте, landerhigh, Вы писали:
L>Вовсе не так. Правильно применять юнит-тесты умеют единицы. В остальных случаях тесты пишут либо потому, что менеджер заставляет, либо разрождаются уродцем вроде того, что в твоей ссылке, когда уж совсем припрет.
Пример тех самых правильных юнит-тестов в исполнении этих "единиц" которые "умеют" можно увидеть?
L>И это консольное приложение будет чем? Правильно, юнит-тестом
Нет, оно не будет юнит-тестом, так как дергает много всего и сразу.
L>Распространенное мнение. С позиции "одноразового кода". Много раз его слышал, и чаще всего от людей, которым в жизни не приходилось поддерживать или развивать свой собственный или чужой код. Написали — фигакс в продакшен — в следующую контору, на следующий проект. А то, что в следующей версии пришедшие на их место программисты переписывают половину этого кода, это их не касается. Они просто гения не поняли, им еще расти и расти.
Я не предлагаю не писать юнит-тесты. Я просто утверждаю, что после определенного уровня зрелости и стабильности большая часть юнит-тестов теряет актуальность. Они так же могут замедлять разработку при радикальных рефакторингах.
L>Уже только это помогает изолировать проблемы интеграции.
Ты же сам в предыдущем сообщении присал что юнит-тесты не гарантируют наличие ошибок. Получается что и проблемы интеграции они не изолируют.
L> А у вас разработчики вообще не запускают сами систему после сборки?
Система большая, баг может проявляться под нагрузкой или при обработке какого-нибудь хитрого запроса на какой-нибудь отдельной платформе. У нас есть отдельная стойка, на которой только гоняются тесты и ничего больше. На полный прогон уходит много часов.
L>В стелс режиме баг дальше QA не поедет. Там он проваливает регрессию. Возвращается разработчикам, которые сразу видят, что проблема в неправильном использовании компонента.
Хочу обратить внимание на "замечательный" подход — я написал тесты и они проходят, остальное проблема QA. Собственно я и топлю за то, чтобы проактивно искать баги функциональными тестами, а не надеяться на то что QA прокликает страничку и что-то там найдет. Работа программиста не заканчивается на написании юнит-теста или интеграционного теста. Необходим постоянный поиск способов сломать код. Иначе получается что каждый разраб живет в своем уютном мирке, окруженном юнит-тестами, в полной уверенности в том что проблема не на его стороне.
L>Проблемы хреновой постановки QA ортогональны юнит-тестированию.
Не везде есть QA, иногда программисты сами себе QA.
L>Зато их находят интеграционные тесты. Которые во многих случаях являются теми же самыми юнит-тестами, только в качестве юнита используют интегрированный компонент.
Интеграционное тестирование трудоемко, плохо масштабируется и редко встречается в природе.
L>Это был очень большой и весьма сложный проект.
По твоему мнению (нет, ну серьезно, у программистов каждый проект большой, серьезный и сложный, без исключений)
L>Еще до того, как это модное слово придумали.
По моему ты просто не понимаешь о чем идет речь, рандомизированные тесты это не фаззинг.
CK>>Как ты себе это представляешь? Ну вот есть компонент генерирующих хаффмановский словарь — как ты узнаешь, правильно ли он сгенерирован? Захардкодишь веса или сделаешь параллельную реализацию? L>Что значит "правильно"? Если есть понятие "правильно", значит, оно формализуется. А раз формализуется, значит — тестируется.
Проверить правильность словаря можно, ввод, на основе которого создан словарь, должен содержать в себе его элементы и частота встречаемости того или иного элемента должна соответствовать. Проблема в том, что ты юнит-тестом не докажешь, что не существует такой ввод, который сломает этот компонент. Этот тест будет не лучше round-trip тестов на корпусе документов. А фаззинг это может показать, если такой кейс есть, его скорее всего можно найти с помощью afl.
L>Так тоже можно. Но если внутрь компрессора закрался компонент с неопределенным поведением в определенном редком случае, то подобные тесты этот баг могут пропустить. И чаще всего пропускает.
И какова вероятность того что ты именно это найдешь своими юнит-тестами? По крайней мере я могу масштабировать round-trip тест и гонять его на хорошем железе в кучу потоков день и ночь.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Пример тех самых правильных юнит-тестов в исполнении этих "единиц" которые "умеют" можно увидеть?
Естествтенно, но для этого придется устроиться туда на работу сначала.
L>>И это консольное приложение будет чем? Правильно, юнит-тестом CK>Нет, оно не будет юнит-тестом, так как дергает много всего и сразу.
А вот проблемы терминологии являются надуманными. Оно тестирует некий юнит? Тестирует. А то, что этот юнит "надерган" из кучи юнитов поменьше, к делу имеет уже опосредованное отношение.
CK>Я не предлагаю не писать юнит-тесты. Я просто утверждаю, что после определенного уровня зрелости и стабильности большая часть юнит-тестов теряет актуальность.
Значит, это были хорошие тесты. Они уже помогли при разработке и внедрении.
CK>Они так же могут замедлять разработку при радикальных рефакторингах.
А могут и наоборот.
L>>Уже только это помогает изолировать проблемы интеграции. CK>Ты же сам в предыдущем сообщении присал что юнит-тесты не гарантируют наличие ошибок. Получается что и проблемы интеграции они не изолируют.
Вообще-то изолируют. Проблемы интеграции, как правило, ортогональны багам самих юнитов. Зачастую даже смотреть в кору не надо, чтобы понять, что именно случилось.
L>> А у вас разработчики вообще не запускают сами систему после сборки? CK>Система большая, баг может проявляться под нагрузкой или при обработке какого-нибудь хитрого запроса на какой-нибудь отдельной платформе.
Воооооот. А может и не проявиться, пока через пару лет в продакшене не стрельнет. И, что характерно, практически всегда этот стрельнувший баг сводится к тому, что "в юните A не предусмотрена обработка события B". Потому что разработчики посчитали такое событие невозможным, а тестовая стойка вела себя корректно и совсем невероятные данные не генерировала. А клиенты по дешевке закупили в Китае оборудования, которое им нагенерировало всякого.
CK>У нас есть отдельная стойка, на которой только гоняются тесты и ничего больше. На полный прогон уходит много часов.
И все равно все возможные комбинации стойка прогнать не сможет.
CK>Хочу обратить внимание на "замечательный" подход — я написал тесты и они проходят, остальное проблема QA. Собственно я и топлю за то, чтобы проактивно искать баги функциональными тестами,
А кто тебе сказал, что у нас нет функциональных тестов? У нас все есть. И QA тоже есть поверху.
L>>Проблемы хреновой постановки QA ортогональны юнит-тестированию. CK>Не везде есть QA, иногда программисты сами себе QA.
Это и есть хреновая постановка QA.
L>>Зато их находят интеграционные тесты. Которые во многих случаях являются теми же самыми юнит-тестами, только в качестве юнита используют интегрированный компонент. CK>Интеграционное тестирование трудоемко, плохо масштабируется и редко встречается в природе.
Кроме случаев, когда немного подумали о том, как его сделать не трудоемким и масштабируемым
L>>Это был очень большой и весьма сложный проект. CK>По твоему мнению (нет, ну серьезно, у программистов каждый проект большой, серьезный и сложный, без исключений)
Это как раз по мнению моего начальства. Проект болтался 5 лет в категории "надо бы, но песец как сложно".
L>>Еще до того, как это модное слово придумали. CK>По моему ты просто не понимаешь о чем идет речь, рандомизированные тесты это не фаззинг.
Еще раз, на новомодные словечки мне давно положить.
CK>Проверить правильность словаря можно, ввод, на основе которого создан словарь, должен содержать в себе его элементы и частота встречаемости того или иного элемента должна соответствовать. Проблема в том, что ты юнит-тестом не докажешь, что не существует такой ввод, который сломает этот компонент.
Эээ, юнит-тесты вообще-то не для этого предназначены. Они проверяют, что на корректном, некорректном и граничном вводе поведение юнита соответствует ожидаемому. Не больше и не меньше. Задача программиста и состоит в том, чтобы выделить эти домены и определить критерии поведения.
CK>Этот тест будет не лучше round-trip тестов на корпусе документов. А фаззинг это может показать, если такой кейс есть, его скорее всего можно найти с помощью afl.
В крайне ограниченном домене.
L>>Так тоже можно. Но если внутрь компрессора закрался компонент с неопределенным поведением в определенном редком случае, то подобные тесты этот баг могут пропустить. И чаще всего пропускает. CK>И какова вероятность того что ты именно это найдешь своими юнит-тестами? По крайней мере я могу масштабировать round-trip тест и гонять его на хорошем железе в кучу потоков день и ночь.
Примерно 100%. Я пишу код, и вижу, что у него есть такой вариант валидных с точки зрения вызывающего кода входных данных, при котором корректное поведение юнита невозможно. Соответственно нужно было решить, как должен повести себя юнит в таком случае и как это протестировать. На уровне юнита это сделать элементарно. На уровне стойки с оборудованием — невозможно.
Так мы отловили проблему со сторонним оборудованием, которое в редких случаях кодировало в посылке метки времени что-то забавное вроде 32 глюкабря. Если бы мы этого не предусмотрели на этапе юнит-тестирования, создали бы огромные проблемы клиентам. Вместо этого клиент получил доказательство и повод для рекламации поставщику оборудования.
Здравствуйте, landerhigh, Вы писали:
L>Естествтенно, но для этого придется устроиться туда на работу сначала.
Т.е. нельзя. Ясно-понятно. Волшебные юнит тесты, которые существуют, но показать их нельзя. Видимо практика "правильно применять юнит-тесты" настолько сложная, что формализовать ее и описать не представляется возможным.
L>А вот проблемы терминологии являются надуманными. Оно тестирует некий юнит? Тестирует. А то, что этот юнит "надерган" из кучи юнитов поменьше, к делу имеет уже опосредованное отношение.
Поинт юнит-теста в том, что он тестирует что-то одно, поэтому ты можешь увидеть какой тест сломался и сразу понять что именно работает не так. Если тест работает не так, это не юнит-тест.
L>Кроме случаев, когда немного подумали о том, как его сделать не трудоемким и масштабируемым
Вот опять, никакой конкретики.
L>Еще раз, на новомодные словечки мне давно положить.
Звучит пассивно-агрессивно. Это не новомодные словечки а очень крутая современная технология, которая наряду с property based testing-ом, позволяет находить очень хитрые ошибки (например дыры в безопасности). Heartbleed был найден с помощью фаззинга (https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html), интересно, как бы ты его юнит-тестами искал?
L>Эээ, юнит-тесты вообще-то не для этого предназначены. Они проверяют, что на корректном, некорректном и граничном вводе поведение юнита соответствует ожидаемому. Не больше и не меньше. Задача программиста и состоит в том, чтобы выделить эти домены и определить критерии поведения.
Ну так покажи как ты это будешь тестировать? А может не граничный ввод сломает поведение юнита, а может просто качество работы снизится?
L>В крайне ограниченном домене.
Почему?
L>Примерно 100%. Я пишу код, и вижу, что у него есть такой вариант валидных с точки зрения вызывающего кода входных данных, при котором корректное поведение юнита невозможно.
Тебе знакомо словосочетание "комбинаторный взрыв"?
L>Так мы отловили проблему со сторонним оборудованием, которое в редких случаях кодировало в посылке метки времени что-то забавное вроде 32 глюкабря. Если бы мы этого не предусмотрели на этапе юнит-тестирования, создали бы огромные проблемы клиентам. Вместо этого клиент получил доказательство и повод для рекламации поставщику оборудования.
Ты меня ребячишь? Проверить на тупо некорректный ввод — самое первое и простое что можно сделать, даже юнит тестом. Метка времени у них не такая была, где такое видано вообще? :D
Здравствуйте, chaotic-kotik, Вы писали:
L>>Естествтенно, но для этого придется устроиться туда на работу сначала. CK>Т.е. нельзя. Ясно-понятно. Волшебные юнит тесты, которые существуют, но показать их нельзя. Видимо практика "правильно применять юнит-тесты" настолько сложная, что формализовать ее и описать не представляется возможным.
Наоборот, настолько простая, что даже не ясно, что там нужно рассказыват-показывать, и тем более формализовывать.
L>>А вот проблемы терминологии являются надуманными. Оно тестирует некий юнит? Тестирует. А то, что этот юнит "надерган" из кучи юнитов поменьше, к делу имеет уже опосредованное отношение. CK>Поинт юнит-теста в том, что он тестирует что-то одно, поэтому ты можешь увидеть какой тест сломался и сразу понять что именно работает не так. Если тест работает не так, это не юнит-тест.
Это от размера и сложности юнита не зависит.
L>>Кроме случаев, когда немного подумали о том, как его сделать не трудоемким и масштабируемым CK>Вот опять, никакой конкретики.
А какая тебе нужна конкретика? На любой пример найдется возражение про детский сад.
L>>Еще раз, на новомодные словечки мне давно положить. CK>Звучит пассивно-агрессивно. Это не новомодные словечки а очень крутая современная технология, которая наряду с property based testing-ом, позволяет находить очень хитрые ошибки (например дыры в безопасности). Heartbleed был найден с помощью фаззинга (https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html),
Вот именно, что крутая современная технология, которая на поверку существует столько же, сколько и вся практика юнит-тестирования, пока некие блоггеры не придумали ей псевдонаучное название. Мы ее использовали ... да всегда, наверное. Удобный подход для определенных задач и совершенно неприменимый для других.
CK>интересно, как бы ты его юнит-тестами искал?
Никак. Юнит-тесты для этого не предназначены.
L>>Эээ, юнит-тесты вообще-то не для этого предназначены. Они проверяют, что на корректном, некорректном и граничном вводе поведение юнита соответствует ожидаемому. Не больше и не меньше. Задача программиста и состоит в том, чтобы выделить эти домены и определить критерии поведения. CK>Ну так покажи как ты это будешь тестировать? А может не граничный ввод сломает поведение юнита, а может просто качество работы снизится?
Что значит "покажи"? Юнит-тестирование — это прикладная технология, на сферических юнитах в вакууме не рабоатет.
L>>В крайне ограниченном домене. CK>Почему?
Каким бы крутым этот fuzzing тест не был, на сколько-нибудь сложной системе он тупо не сможет сгенерировать все возможные комбинации за обозримое время. Ты как раз про комбинаторный взрыв упоминал. Вот именно поэтому.
L>>Примерно 100%. Я пишу код, и вижу, что у него есть такой вариант валидных с точки зрения вызывающего кода входных данных, при котором корректное поведение юнита невозможно. CK>Тебе знакомо словосочетание "комбинаторный взрыв"?
Именно поэтому я тестирую отдельные мелкие юниты.
L>>Так мы отловили проблему со сторонним оборудованием, которое в редких случаях кодировало в посылке метки времени что-то забавное вроде 32 глюкабря. Если бы мы этого не предусмотрели на этапе юнит-тестирования, создали бы огромные проблемы клиентам. Вместо этого клиент получил доказательство и повод для рекламации поставщику оборудования. CK>Ты меня ребячишь? Проверить на тупо некорректный ввод — самое первое и простое что можно сделать, даже юнит тестом. Метка времени у них не такая была, где такое видано вообще? :D
Ага, это когда тебе рассказали и объяснили на пальцах, все кажется простым. А на подобных ерундовинах ежедневно крупные компании, сплошь из PhD и сортировщиков гномиков состоящие, апсираются.
Фишка в том, что некорректным вводом это становится только после скрупулезного обдумывания "а как мне это тестировать".
Здравствуйте, landerhigh, Вы писали:
L>Наоборот, настолько простая, что даже не ясно, что там нужно рассказыват-показывать, и тем более формализовывать.
Тогда почему ты думаешь, что никто кроме тебя это не делал?
L>А какая тебе нужна конкретика? На любой пример найдется возражение про детский сад.
Детский сад.
L>Вот именно, что крутая современная технология, которая на поверку существует столько же, сколько и вся практика юнит-тестирования, пока некие блоггеры не придумали ей псевдонаучное название. Мы ее использовали ... да всегда, наверное. Удобный подход для определенных задач и совершенно неприменимый для других.
Щито?
Fuzzing существует давно и именно так и называется в научной литературе (о каких еще блоггерах ты говоришь?). Mutation-based fuzzing тулы появились сравнительно недавно, AFL где-то в конце 2014-го года стал более или менее юзабельным, libFuzzer еще позже. Ты по прежнему не понимаешь о чем я тут толкую, очевидно.
L>Никак. Юнит-тесты для этого не предназначены.
Ну вот видишь, целый класс ошибок, непаханное поле, а юнит-тесты не помогут.
L>Что значит "покажи"? Юнит-тестирование — это прикладная технология, на сферических юнитах в вакууме не рабоатет.
Классная отмазка. Так ведь про все что угодно можно сказать! А потом еще сослаться на NDA!
L>Каким бы крутым этот fuzzing тест не был, на сколько-нибудь сложной системе он тупо не сможет сгенерировать все возможные комбинации за обозримое время. Ты как раз про комбинаторный взрыв упоминал. Вот именно поэтому.
ОК. Фаззинг он такой, перебирает все возможные комбинаци ввода конечно же.
L>Именно поэтому я тестирую отдельные мелкие юниты.
ОК, юнит-тесты это самое главное. Видишь юнит-тесты в проекте, значит проект хороший, если их нет — то проект говно (привет google.brotli).
Здравствуйте, chaotic-kotik, Вы писали:
L>>Наоборот, настолько простая, что даже не ясно, что там нужно рассказыват-показывать, и тем более формализовывать. CK>Тогда почему ты думаешь, что никто кроме тебя это не делал?
Многолетние наблюдения показывают, что внедрение юнит-тестирования чаще всего идет в виде карго-культа.
L>>А какая тебе нужна конкретика? На любой пример найдется возражение про детский сад. CK>Детский сад.
Вот именно
CK>Fuzzing существует давно и именно так и называется в научной литературе (о каких еще блоггерах ты говоришь?). Mutation-based fuzzing тулы появились сравнительно недавно, AFL где-то в конце 2014-го года стал более или менее юзабельным, libFuzzer еще позже. Ты по прежнему не понимаешь о чем я тут толкую, очевидно.
Не появились, а ты о них прочитал. Почувствуйте разницу
L>>Никак. Юнит-тесты для этого не предназначены. CK>Ну вот видишь, целый класс ошибок, непаханное поле, а юнит-тесты не помогут.
Помогут. Не сделать этих ошибок.
L>>Что значит "покажи"? Юнит-тестирование — это прикладная технология, на сферических юнитах в вакууме не рабоатет. CK>Классная отмазка. Так ведь про все что угодно можно сказать! А потом еще сослаться на NDA!
Ну а "покажи" к чему тогда?
L>>Каким бы крутым этот fuzzing тест не был, на сколько-нибудь сложной системе он тупо не сможет сгенерировать все возможные комбинации за обозримое время. Ты как раз про комбинаторный взрыв упоминал. Вот именно поэтому. CK>ОК. Фаззинг он такой, перебирает все возможные комбинаци ввода конечно же.
Вообще-то да. Для того, чтобы в системе из N компонентов, каждый из которых принимает всего лишь 3 разделимых домена данных (валидные, невалидные, и граничные), найти единственный, в котором забыли обработать один из этих доменов, случается переполнение, потребуется 3^N наборов данных. Твой любимый комбинаторный взрыв.
И это если у компонентов нет состояний.
L>>Именно поэтому я тестирую отдельные мелкие юниты. CK>ОК, юнит-тесты это самое главное. Видишь юнит-тесты в проекте, значит проект хороший, если их нет — то проект говно (привет google.brotli).
Гугль в последнее время как раз эталон говнопроектов, так что камент весьма в тему.
Здравствуйте, landerhigh, Вы писали:
L>Не появились, а ты о них прочитал. Почувствуйте разницу
L>Вообще-то да. Для того, чтобы в системе из N компонентов, каждый из которых принимает всего лишь 3 разделимых домена данных (валидные, невалидные, и граничные), найти единственный, в котором забыли обработать один из этих доменов, случается переполнение, потребуется 3^N наборов данных. Твой любимый комбинаторный взрыв. L>И это если у компонентов нет состояний.
Я уже много раз упоминал afl, ты бы хоть загуглил и почитал как оно работает. Ну стыдно же!
Вот удивительно, ты (да и кто угодно тут вообще) мог бы узнать от меня много интересного, ну например как фаззить проекты в промышленных масштабах, у нас в проекте фаззится все что приходит от юзера, плюс те компоненты, которые декодируют данные БД (на случай corruption-а этих данных, чтобы быть уверенными в том что повреждение данных будет обработано и не повалит или повесит систему во время восстановления после сбоя). Ну либо узнать что-нибудь про системное тестирование перформанса, про те же функциональные тесты, как гонять их на _ВСЕХ_ платформах и всех возможных пользвоательских конфигурациях. Видимо поспорить интереснее, но раз так, то это сознательный выбор и глубокая убежденность в своей правоте, заслуживающие уважения, поэтому больше не буду лезть со своим
Здравствуйте, chaotic-kotik, Вы писали:
L>>Не появились, а ты о них прочитал. Почувствуйте разницу CK>
Перед зеркалом можешь это делать.
Мы точно использовали фаззер в 2008 для тестирования протоколов. Только называли его иначе.
Даже проект был по нахождению уязвимостей.
L>>Вообще-то да. Для того, чтобы в системе из N компонентов, каждый из которых принимает всего лишь 3 разделимых домена данных (валидные, невалидные, и граничные), найти единственный, в котором забыли обработать один из этих доменов, случается переполнение, потребуется 3^N наборов данных. Твой любимый комбинаторный взрыв. L>>И это если у компонентов нет состояний. CK>Я уже много раз упоминал afl, ты бы хоть загуглил и почитал как оно работает. Ну стыдно же!
Australian Football League?
CK>Вот удивительно, ты (да и кто угодно тут вообще) мог бы узнать от меня много интересного, ну например как фаззить проекты в промышленных масштабах,
Тебе говорят, что этой технике в обед сто лет. Ну назвали модным словом, суть от этого не меняется.
В любом случае, никакой алгоритм не победит комбинаторный взрыв.
Можно сколько угодно гонять фаззер, но баг, о котором никто не подозревал и который проявляется только в момент перевода часов на час назад, он в лучшем случае имеет шанс найти раз в год.
Здравствуйте, landerhigh, Вы писали:
L>Перед зеркалом можешь это делать. L>Мы точно использовали фаззер в 2008 для тестирования протоколов. Только называли его иначе. L>Даже проект был по нахождению уязвимостей.
В 2008-м году ты использовал "тупой" фаззер, либо описывал протокол вручную и скармливал фаззеру.
L>Australian Football League?
American Fuzzy Lop
я тут уже и так и так писал, и по ссылке моей он есть, нужно очень сильно не желать слушать собеседника чтобы этого не заметить
L>Тебе говорят, что этой технике в обед сто лет. Ну назвали модным словом, суть от этого не меняется. L>В любом случае, никакой алгоритм не победит комбинаторный взрыв. L>Можно сколько угодно гонять фаззер, но баг, о котором никто не подозревал и который проявляется только в момент перевода часов на час назад, он в лучшем случае имеет шанс найти раз в год.
Фаззингу 100 лет в обед, да, кто спорит? Я тебе пытаюсь объяснить что туллинг поменялся, он больше не перебирает тупо все комбинации. Тот же afl — инструментирует исполняемый файл, гоняет твой код, определяет какие бранчи пройдены а какие нет и пытается сгенирировать такой ввод, который выдаст максимальное покрытие. Эта штука генерирует сама валидные структуры данных на диске, которые приложение потом может понять. В 2008-м ты ничего подобного использовать не мог, ничего подобного тогда не существовало.
И кстати, модное слово придумал чувак, который эту технику изобрел лет эдак 30 назад.
А у вас разработчики вообще не запускают сами систему после сборки?
