Неплохой фаззер

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

Фаззер: uniofuzz



Написан на python. Довольно прост и в то же время универсален -  умеет генерировать рандомные файлы, фаззить tcp-соединения, пайпы и т.д.(см -help)

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

"Почти" - потому что пришлось научить ее фаззить udp вместо tcp и немного "поиграться" с длиной содержимого пакета.

Патч прост:
 
235c235
<               sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
---
>               sock=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

Пример фаззинга (2 пакета в секунду) в сетевом соединении:

./uniofuzz.py -n -i 0.5 -ip 127.0.0.1 -port 12345 -s 9999

Утилита проста и эффективна, код открыт и прямолинеен - допилить под свои нужды - не проблема.

Кому нужен ISO или история обесценивания

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

Водительские права? Пожалуйста - полиционер сам за тебя все кнопки нажмет при сдаче теории, разыграв спектакль "самостоятельная сдача экзамена в гибдд".
Талон техосмотра - пожалуйста! Гарантирует ли эта бумаженция то, то твое корыто не развалится по среди мкад и не пришибет кого-нибудь отвалившимся на ходу колесом? Нет. Это лишь повод заработать.

И так везде. В том числе и в сфере сертификации систем качества производства ПО.
Есть такие замечательные международный стандарты ISO 900x , в которых даны исчерпывающие рецепты того, какой должна быть идеальная СМК - расписаны ее компоненты, документы, процессы, роли. Есть и родной наш ГОСТ, в котором не меньше полезной информации для тех, кто действительно хочет вывести качество своего продукта на высокий и даже международный уровень. В общем, все есть - изучай, инвестируй, внедряй и получай результат. Но что получается на практике? Как грибы после дождя расплодились сертифицирующие органы, направо и налево раздающие красивые "сертификаты соответствия", за круглые суммы и в сжатые сроки, даже не ступая ногой на территорию предприятия. Эти разноцветные бумажки попадают в стеклянные рамочки топ-манагеров, на главные страницы сайтов софтверных фирм - вот , дескать, смотрите все ! Вот почему наш софт на 200% дроже остальных! А на деле -  в лучшем случае вся СМК состоит из одного лишь выходного контроля  в виде отдельчика или группки тестирования, которые с переменным успехом сдерживают лавину проблем, которые уходят корнями во все отделы и даже в кабинет  в топ-манеджеру , у которого на стене красивая рамочка.

Обесценивание повсюду -  во всех , за микроскопическми исключениями сферах.

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

Зачем тратить здоровье и нервы грызя матанализ, когда можно списать, договориться, умаслить и получить-таки свой диплом?
Зачем стыдливо носить баночки с анализами и не есть по утрам, чтобы сдать кровь из пальчика , чтобы получить справку в бассейн, когда терапевт за 500 рублей просканировав твое состояние взглядом выпишет нужную справку?
Зачем стоять в очереди на ТО, тратить деньги на запчасти, ремонт, если можно заказать талон чуть ли ни через интернет с доставкой?

Ну и нафига , спрашивается, создавать целую службу контроля качества, платить зарплату менеджеру по качеству, напрягать всех и вся, писать технологии, следить за соблюдением, учиться , развиваться , если "бумажку в рамку" мне выдаст ушлый  сертификатор в нужные мне сроки?

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

Показательный пример -  на собеседованиях (по крайней мере ИТ-специалистов ) все реже смотрят на диплом (если , конечно, это не диплом физтеха или мехмата МГУ :),  а все больше на опыт, на способность мыслить...  Заказчиков все сложнее заманить "бумажкой в рамке" им нужно реальное качество... Мы обесценили все эти лейблы, мы перестаем их замечать.. Проблема лишь в том, что весь остальной мир на полном серьезе учится, получает честные дипломы и сертифицируется не понарошку ...

Грабли от HTML5

Сегодня попался забавный баг в корзине одного интернет-магазина , в верстке которой активно использовались всяческие новшества  HTML5, в том числе и новые типы полей ввода.

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

Баг такой:

1. клиент положил  в корзину товар
2. перешел в корзину
3. и решил накрутить количество, зажав кнопку увеличения 
4. накручивал-накручивал так несколько секунд, пока не надоело, и отпустил...

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

Разбор был недолог: при каждом обновлении значения в поле "количество" на сервер слался асинхронный запрос (ajax) на получение пересчитанной корзины... сервер просто начинал давиться :) и ответы на запросы невпопад продолжали приходить в броузер еще некоторое время после того, как юзер устал накручивать ...

К чему это все я?

1. разработчикам - всяческие новые "плюшки" в стандартах не отменяют обдуманного их применения
2. тестировщикам - применяя и осваивая навороченные техники тестирования иногда можно просто "взять и сломать" по-старинке :)

Учим Test::Class контролировать зависшие тесты

Есть такой популярный модуль Test::Class -  реализация xUnit для Perl.

Довольно удачная реализация - есть все или почти все, что требуется для xUnit-фреймворка.

TestSuite можно описать с помощью класса (пакета) например так (код не постеснялся скопипастить прямо с cpan):

  package Example::Test;
  use base qw(Test::Class);
  use Test::More;

  # setup methods are run before every test method. 
  sub make_fixture : Test(setup) {
      my $array = [1, 2];
      shift->{test_array} = $array;
  };

  # a test method that runs 1 test
  sub test_push : Test {
      my $array = shift->{test_array};
      push @$array, 3;
      is_deeply($array, [1, 2, 3], 'push worked');
  };

  # a test method that runs 4 tests
  sub test_pop : Test(4) {
      my $array = shift->{test_array};
      is(pop @$array, 2, 'pop = 2');
      is(pop @$array, 1, 'pop = 1');
      is_deeply($array, [], 'array empty');
      is(pop @$array, undef, 'pop = undef');
  };

  # teardown methods are run after every test method.
  sub teardown : Test(teardown) {
      my $array = shift->{test_array};
      diag("array = (@$array) after test(s)");
  };

Вот только контролировать продолжительность тестов по таймауту этот фреймворк не умеет.

Чтобы решить эту проблему, не поручая такой контроль каким бы то ни было внешним утилитам, можно воспользоваться возможностями ООП и fork примерно так:

package TTL::Test::Class; use base qw(Test::Class); use Test::More; use POSIX ":sys_wait_h"; use constant DEFAULT_TIMEOUT => 60; # переопределяем метод запуска тестов sub runtests{ my $t = DEFAULT_TIMEOUT; my $pid = fork; my $child_ret_code; if( $pid > 0 ){ # parent process #child waiting loop my $ok_flag = 0; for(my $i=0; $i < $t; $i++){ if(waitpid($pid, WNOHANG)){ $child_ret_code = $?/256; ok($child_ret_code); $ok_flag = 1; last; }; sleep(1); }; if( not $ok_flag ){ diag "Killing test by its timetolive..."; kill TERM => $pid; return $ok_flag; }; return $child_ret_code; } elsif( $pid == 0 ) { #child exit $self->SUPER::runtests; } elsif ( not defined($pid) ) { #unsuccessfull fork die "Cannot fork child process: $!"; } } 1;

далее в сьюте меняем базовый класс на наш:

#use base qw(Test::Class);
use base qw(TTL::Test::Class);

Теперь каждый сьют будет принудительно завершен через нужный нам таймаут.
Мораль сей басни такова (с),  никакой готовый фреймфорк полностью не удовлетворит всем возможным нуждам при конкретном его применении.
Поэтому можно и нужно допиливать и улучшать.

О верификации и валидации

«Ты суслика видишь?
— Нет.
— И я нет. А он есть!»
("ДМБ")

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

Не всякий сходу сможет объяснить , в чем различие. Но оно есть и оно довольно существенно.

Неофициально эти термины можно расшифровать так:

Верификация - это проверка того, соответствует ли продукт (ПО, например) неким требованиям , которые считаются эталоном.

Валидация - это проверка применимости продукта в конкретных условиях, соответствует ли он им, может ли использоваться в этих условиях.

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

Анализ причины пропуска , как правило, не занимает много времени:

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

- все это может привести к неожиданностям при реальном использовании.

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

Проверяем локальный web на соответствие стандартам разметки

Всем , наверняка знакомы полезные валидирующие сервисы от w3c.org, с помощью которых можно быстро проверить url на соответствия, например, разметки (markup) стандартам.

Но не все, наверное, знают, что для локальных web-ресурсов, находящихся в тестировании или просто за NAT-ом, можно проделать легко и просто, установив и запустив сервер валидатора прямо у себя в локальной сети.

Вот незамысловатая инструкция для linux debian (все то же самое можно проделать практически на любой другой десктопной или серверной ос):

#ставим пакет из репозитория
apt-get install w3c-markup-validator

#ставим нужные perl-библиотеки
cpan Bundle::W3C::Validator

#запускаем инсталлятор сервера
w3c-validator-install.sh  all

#пробуем запустить с дефолтными настройками (запущенный сервер будет "ждать" http на 5000-м порту)
w3c-validator-server.psgi

#дальше пробуем проверить локальный url и видим сообщение об ошибке:

#разрешаем в конфиге private-адреса: vim /home/someuser/.w3c-validator-server/config/validator.conf



Allow Private IPs = yes

далее перезапускаем сервер и натравливаем валидатор на локальный ресурс после этого правим разметку :)

To resolve this problem, it is best to upgrade to newer version of Internet Explorer

Уже довольно продолжительное время говорится об ущербности IE 6.0 и о том, что учитывать его "особенности" при web-разработке не стОит.

Наверное , это правильно.

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

До этого момента IE 6.0 был в списке поддерживаемых,и  проблем с версткой даже под таким атавизмом не наблюдалось. Но в этот раз, верстка-таки поплыла , причем так, что пользоваться  страницами стало затруднительно.

Проблема зафиксирована, разработчики думают, что дальше делать...

Не знаю кто меня дернул за руку, что я полез из этого тестового IE 6 на поисковую страницу google и даже попробовать что-то там найти.. Начинаю, значит, вводить критерий поиска и получаю Access Violation по нулевому адресу.

IE приучил не обращать внимания на такие вещи , если они не повторяются... А когда повторяются, то становится уже интересно.  Этот баг повторился. OllyDbg показал на mshtml.dll - либа, отвечающая за рендеринг страниц.

Покопался  в том, что же такого криминального  в простенькой на вид страничке google.com...

Выяснилось, что причиной падения является хитрый cookie вида "search?client=heirloom-hp&hl=ru&gs_rn....&q=t" , который поисковик создает при каждой попытке поиска. Прежде , чем копать дальше и думать, чем такой баг может реально грозить, решил поискать , не сталкивался ли кто с такой проблемой до меня ... и точно, нашел... Ответ google-a убил желание копать дальше... "Обновите броузер".

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

..но почему-то не написал :)

Ретроспективка

А все-таки чертовски большой скачок совершило "тестирование" за последние лет 5-10.

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

Да и не было по большому счету такой ПРОФЕССИИ - "тестировщик". Этому не учили толком в наших ВУЗах, за это не давали сертификатов, и в конечном итоге за это платили смешные деньги. Такое положение дел было естественным для нашей страны, на годы отстающей от информационно-технологичного запада, сего Канером. Редко кто из кампаний-разработчиков софта выдвигал повышенные требования к качествую своих продуктов... хотя бы потому что не было таких требований со стороны рынка... Да, были такие "гиганты" типа CBOSS ( это не реклама :), которые с самого начала возвели качество во главу угла и где тестирование было организовано на отличном уровне даже много лет назад.. но это были исключения.

Но и у таких "белых ворон" рынка программного обеспечения в тестировании зачастую были люди случайные: студенты, подработчики, технари в возрасте , пытающиеся хоть как-то встроиться в набирающие обороты ИТ..., текучка , соответственно, была бешенная. Очень многие уходили в разработчики и такие, кстати, очень часто потом затмевали "штатных" разрабов... уходили и в другие сферы - смежные и не очень...

Кто остался?

Кто-то остался в профессии из-за малодушия, кто-то из-за понимания перспектив и настоящего призвания к этому делу, кто-то остался , найдя для себя приемлемые компромиссы и горизонты развития в тестировании...

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

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

Специфика использования open-source проектов

  Как принято считать, стоимость исправления дефектов в ПО тем ниже, чем раньше стадия, на которой этот дефект был выявлен.Эта теорема не раз доказана практикой тысяч конкретных программных проектов. Тестирование идей и требований пока еще звучит как экзотика. Но стимуляция разработчиков к более тщательному выходному контролю кода уже стала нормой. Программисты клепают unit-тесты ( и теперь уже кто-то даже до написания логики ), многие обзаводятся своими собственными тестовыми стендами, и даже прогоняют на них основные по их мнению варианты. Этому нельзя ни радоваться и это нельзя не приветствовать. Но мышление разработчика остается мышлением разработчика. О многих вариантах использования, вариациях входных данных ему думать не досуг. И это правильно. Там, где за разработчиками стоят грамотные тестировщики, можно не беспокоиться - они позаботятся о проверке всех нужных вариантов, в том числе и довольно редких, но все-таки нужных.
  Но не все программные проекты подвергаются экзекуции тестировщиками, не все проекты проходят стадию "тестирования" перед выпуском в свет.. Особенно это касается многих open-source решений. Среди них много таких, которые кроме unit-тестирования никакого более тестирования не проходят. Баги ловят реальные пользователи, кто-то постит их в открытые багтреккеры и, если проект продолжает поддерживаться, он постепенно становится лучше. Бывает так, что баг висит годами без фиксов и пользователям этого открытого софта, библиотеки приходится патчить самим. Все бы ничего, схема работает. Да здравствует open source и GPL в руки! Но когда речь идет о создании коммерческого софта с использованием открытых библиотек, то не все удосуживаются анализировать используемый сторонний (3rd party) софт на наличие ошибок. Вот и вылезают потом неожиданности в виде багов, которые непонятно кому исправлять - то ли ждать фиксов от авторов сторонней софтины, то ли самим патчить. Если самим , то как это сделать так, чтобы не сломать - а для этого надо разобораться с внутренней архитектурой стороннего решения...
   В общем, не так гладко может все сложиться. А ведь даже поверхностный анализ баг-треккера той или ной открытой либы может помочь понять , стоит ее использовать в коммерческой разработке или нет.

• Покрыта ли библиотека unit-тестами, если да , то на сколько ? 
• Проходят ли unit-тесты в окружении, в котором планируется использовать будущий коммерческий софт? 
• Даже если внешне все гладко, то не стоит ли поручить тестировщикам помучать с помошью заглушек эту библиотеку и дать свою экспертную оценку о ее качестве?  

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

  Одно ясно точно - использовать open-source разработки в коммерческих проектах надо обязательно ( чтобы не изобретать велосипедов) , но чтобы потом не переписывать половину кода, из-за того, что "либа оказалась Г..", все сторонние решения надо тщательно анализировать.

+27 к жизни

Помните песню Сюткина "ежедневно 42 минуты под землей", где он складывал в года время, потраченное на езду в метро?

Песня - песней, а для многих жителей мегаполиса и окружающих его окраин - это большая проблема... Например, я до недавнего времени тратил час - полтора на дорогу только в одну сторону. Было много причин, для того, чтобы мириться с этим положением дел. Было много компромиссов в виде аудиокниг (если в машине), читалок с полезным контентом (если на общ.тренспорте), прослушанных курсов английского и так далее...
Но простая арифметика показывала , что в год набегало что-то около 27 дней только на стояние в пробках, у которых пока не видно тенденции к уменьшению.. И когда я просто физически перестал успевать делать многие важные вещи, когда терпение лопнуло и здравый смысл перевесил все эмоции, то я перебрался поближе к основному месту работы. Какая красота - 15 минут от двери до двери!
Теперь в моем распоряжении совсем не лишних ~27 дней в году, которые можно как минимум потратить на хороший отдых )

Вот такой вот тайм-менеджмент...