В чем плюс для сотрудников: человек спокойно дорабатывает положенные две недели без опасений, что его обвинят в каком-нибудь «вредительстве», спишут штраф и т. д.
Хотелось рассмотреть именно back-box тестирование, а так да, изучение конфига и кода иногда помогает. Ну вот конкретно в моём примере как такового конфига и кода у приложения вообще не было (был, конечно, в либах питона).
Про рефакторинг чуда, которое только через strace раздебажишь, согласен :) Но всякое бывает)) Поэтому и написал статью, чтобы показать, что даже если ничего не понятно, можно попробовать расковырять это утилитами.
Во-первых, сразу скажу, что я не имел ввиду ситуацию, когда проблема на проде. В этом случае, естественно, дебагом должны заниматься девопсы/разработчики, как люди, лучше всего знающие инфраструктуру и ПО. Речь в статье шла скорее о ситуации, когда проблема возникает при тестировании какой-то новой фичи, и ситуации, описанные в статье, сильно искуственные. Доступность сервисов определённо должна проверяться автоматизацией.
Во-вторых, я считаю, что тестировщик всё-таки должен «блистать знаниями» в разумных пределах. Пример: отдают сервис на тестирование, тестировщик запускает тест, получает в ответ Connection reset by peer. Дальше есть 2 варианта: либо тестировщик просто пишет разрабам «тут странная ошибка, воспроизводится тестом XXX, вот вам Reopen задачи», либо он понимает, что клиент получил TCP-пакет с RST, что сервис упал, пойдёт в лог и приложит к задаче стектрейс. Или, если сервис отложил core dump-файл, заюзает gdb на этот файл, сделает там bt и приложит трейс из дампа к задаче.
Оба варианта имеют право на жизнь, всё зависит от процесса и культуры разработки и тестирования в компании/отделе. Лично мне ближе второй :)
Спасибо за комментарий! curl на localhost действительно может дать информации, а про ss я написал в конце без подробностей. netstat же уже устарел, хоть пользоваться им никто не запрещает :)
Ваня такое встречал редко. Так редко делают, потому что обычно вся связка сервисов находится в какой-то внутренней сети, в которую нет доступа снаружи, и использовать там HTTPS — это нормальный такой оверхед. Проще всего переконфигурить nginx, чтоб ходил по HTTP. Либо использовать ssldump, но Ваня не пользовался им.
Плохое правило, если есть поддержка любых языков и символов :) В таком случае и рандомизатор напишут скорее всего для latin1, и ничего он не найдет. А если будут осознанно запихивать в тест рандомизатор любых UTF-символов, то сразу же решат проверить и кейсы с многобайтными символами, и снова приходим к тому, что лучше просто добавить в data provider теста таких сложных символов, а не надеяться на рандом.
Классная статья, спасибо! В тестировании тоже периодически приходится использовать strace.
Может быть удобно использовать флаг -ff, который вместе с -o распределяет весь вывод по файлам с постфиксом ".%PID%"
Также стоит упомянуть и про -s — иначе все строки обрезаются до 32 символов, а иногда хочется иметь весь вывод, чтобы что-нибудь погрепать в нём.
Просто вопросы были заданы так, будто я написал «сертификат нужен всем!» :)
Лично моё мнение: эта сертификация не особо полезна людям, имеющим опыт в этой сфере. Для начинающих специалистов она может быть полезна, потому что позволяет ознакомиться с предметной областью в целом и познать основную суть тестирования (но, как мне кажется, это можно сделать более быстро: например, посмотрев пару видео или почитав пару статей, а не вычитывая кучу страниц сухой теории).
Но если есть желание в будущем уехать за границу, то надо иметь ввиду, что у многих вакансий в описании написано «желательно иметь сертификат ISTQB», а процентов для 5 вакансий (по моим наблюдениям, вакансии в Европе) эта сертификация обязательна.
Не совсем понял вопрос. По времени изучения: на базовом уровне всё довольно быстро познаётся.
Про shell: всё субъективно, скорее надо знать на уровне уверенного пользователя + знать инструменты дебага (strace, tcpdump, gdb и прочее).
Про SQL: спасибо за замечание, именно MySQL и правда ни к чему, исправил на просто SQL-запросы.
Про ООП: зависит от компании, лично меня не раз спрашивали про принципы ООП и пару раз про пару паттернов.
Кейсы работы бывают разнообразные, именно поэтому хорошо иметь широкий кругозор. В частности, если не знать основ архитектуры распределенных систем, то на задаче с формочкой ты не сможешь придумать кейс «а вдруг данные из формы идут на несколько серверов, надо как-то проверить, что работает фоллбэк». А дальше уже раскручиваешь это: посмотрим tcpdump'ом, что трафик действительно есть на нескольких серверах. А теперь зафаерволлим один с помощью iptables. Проверим, что форма до сих пор работает и т.п. И это самый простой пример. Согласитесь, будет здорово, если кандидат что-то подобное скажет вам на интервью? :) И это явно будет дополнительный плюсик кандидату.
Как нечто более общее, чем TCP/IP. Опять же, это не значит, что нужно знать все эти протоколы, но просто надо знать, что они есть.
Ну и да, это всё субъективно + зависит от требований конкретной вакансии.
И я не имею ни малейшего представления как работает TCP. Кто-то кому-то присылает syn, syn-ack, дальше они там договариваются про окна, расширения, улучшения, rfc 800 какого-то по 8000 какой-то. А да, ещё там в конце FIN.
А как это противоречит статье? Я как раз и написал, что очень круто, если кандидат знает про 3-way handshake, про скользящее окно и про флаги.
Спасибо за наводку! Прикреплю тогда здесь полное описание этого экстеншна:
statistic
This module matches packets based on some statistic condition. It supports two distinct modes settable with the --mode option.
Supported options:
--mode mode
Set the matching mode of the matching rule, supported modes are random and nth.
[!] --probability p
Set the probability for a packet to be randomly matched. It only works with the random mode. p must be within 0.0 and 1.0. The supported granularity is in 1/2147483648th increments.
[!] --every n
Match one packet every nth packet. It works only with the nth mode (see also the --packet option).
--packet p
Set the initial counter value (0 <= p <= n-1, default 0) for the nth mode.
А поделитесь примерами ситуаций, когда pmap используется при тестировании? По моему опыту, lsof и strace приходится использовать прям нечасто, а pmap вообще не довелось использовать :)
Но есть идея написать статью как раз про чуть более специфичные утилиты и разобрать их использование на примерах, потому что, например, ещё с помощью iptables или tc можно делать интересные вещи.
Вот это плюс так плюс!
Ну и кто захочет посмотреть bcc-tools, убедитесь, что у вас версия kernel-devel соответствует версии-релизу ядра :)
Ну а чтоб дойти до SELinux, надо и правда совсем отчаяться))
Про рефакторинг чуда, которое только через strace раздебажишь, согласен :) Но всякое бывает)) Поэтому и написал статью, чтобы показать, что даже если ничего не понятно, можно попробовать расковырять это утилитами.
Во-первых, сразу скажу, что я не имел ввиду ситуацию, когда проблема на проде. В этом случае, естественно, дебагом должны заниматься девопсы/разработчики, как люди, лучше всего знающие инфраструктуру и ПО. Речь в статье шла скорее о ситуации, когда проблема возникает при тестировании какой-то новой фичи, и ситуации, описанные в статье, сильно искуственные. Доступность сервисов определённо должна проверяться автоматизацией.
Во-вторых, я считаю, что тестировщик всё-таки должен «блистать знаниями» в разумных пределах. Пример: отдают сервис на тестирование, тестировщик запускает тест, получает в ответ Connection reset by peer. Дальше есть 2 варианта: либо тестировщик просто пишет разрабам «тут странная ошибка, воспроизводится тестом XXX, вот вам Reopen задачи», либо он понимает, что клиент получил TCP-пакет с RST, что сервис упал, пойдёт в лог и приложит к задаче стектрейс. Или, если сервис отложил core dump-файл, заюзает gdb на этот файл, сделает там bt и приложит трейс из дампа к задаче.
Оба варианта имеют право на жизнь, всё зависит от процесса и культуры разработки и тестирования в компании/отделе. Лично мне ближе второй :)
Ваня такое встречал редко. Так редко делают, потому что обычно вся связка сервисов находится в какой-то внутренней сети, в которую нет доступа снаружи, и использовать там HTTPS — это нормальный такой оверхед. Проще всего переконфигурить nginx, чтоб ходил по HTTP. Либо использовать ssldump, но Ваня не пользовался им.
Плохое правило, если есть поддержка любых языков и символов :) В таком случае и рандомизатор напишут скорее всего для latin1, и ничего он не найдет. А если будут осознанно запихивать в тест рандомизатор любых UTF-символов, то сразу же решат проверить и кейсы с многобайтными символами, и снова приходим к тому, что лучше просто добавить в data provider теста таких сложных символов, а не надеяться на рандом.
Может быть удобно использовать флаг -ff, который вместе с -o распределяет весь вывод по файлам с постфиксом ".%PID%"
Также стоит упомянуть и про -s — иначе все строки обрезаются до 32 символов, а иногда хочется иметь весь вывод, чтобы что-нибудь погрепать в нём.
Лично моё мнение: эта сертификация не особо полезна людям, имеющим опыт в этой сфере. Для начинающих специалистов она может быть полезна, потому что позволяет ознакомиться с предметной областью в целом и познать основную суть тестирования (но, как мне кажется, это можно сделать более быстро: например, посмотрев пару видео или почитав пару статей, а не вычитывая кучу страниц сухой теории).
Но если есть желание в будущем уехать за границу, то надо иметь ввиду, что у многих вакансий в описании написано «желательно иметь сертификат ISTQB», а процентов для 5 вакансий (по моим наблюдениям, вакансии в Европе) эта сертификация обязательна.
Не совсем понял вопрос. По времени изучения: на базовом уровне всё довольно быстро познаётся.
Про shell: всё субъективно, скорее надо знать на уровне уверенного пользователя + знать инструменты дебага (strace, tcpdump, gdb и прочее).
Про SQL: спасибо за замечание, именно MySQL и правда ни к чему, исправил на просто SQL-запросы.
Про ООП: зависит от компании, лично меня не раз спрашивали про принципы ООП и пару раз про пару паттернов.
Кейсы работы бывают разнообразные, именно поэтому хорошо иметь широкий кругозор. В частности, если не знать основ архитектуры распределенных систем, то на задаче с формочкой ты не сможешь придумать кейс «а вдруг данные из формы идут на несколько серверов, надо как-то проверить, что работает фоллбэк». А дальше уже раскручиваешь это: посмотрим tcpdump'ом, что трафик действительно есть на нескольких серверах. А теперь зафаерволлим один с помощью iptables. Проверим, что форма до сих пор работает и т.п. И это самый простой пример. Согласитесь, будет здорово, если кандидат что-то подобное скажет вам на интервью? :) И это явно будет дополнительный плюсик кандидату.
Как нечто более общее, чем TCP/IP. Опять же, это не значит, что нужно знать все эти протоколы, но просто надо знать, что они есть.
Ну и да, это всё субъективно + зависит от требований конкретной вакансии.
А как это противоречит статье? Я как раз и написал, что очень круто, если кандидат знает про 3-way handshake, про скользящее окно и про флаги.
This module matches packets based on some statistic condition. It supports two distinct modes settable with the --mode option.
Supported options:
--mode mode
Set the matching mode of the matching rule, supported modes are random and nth.
[!] --probability p
Set the probability for a packet to be randomly matched. It only works with the random mode. p must be within 0.0 and 1.0. The supported granularity is in 1/2147483648th increments.
[!] --every n
Match one packet every nth packet. It works only with the nth mode (see also the --packet option).
--packet p
Set the initial counter value (0 <= p <= n-1, default 0) for the nth mode.
А поделитесь примерами ситуаций, когда pmap используется при тестировании? По моему опыту, lsof и strace приходится использовать прям нечасто, а pmap вообще не довелось использовать :)
Но есть идея написать статью как раз про чуть более специфичные утилиты и разобрать их использование на примерах, потому что, например, ещё с помощью iptables или tc можно делать интересные вещи.