Хабр не выдержал хабраэффекта )

Универсальное резюме :)

Автотесты на автотесты ?

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

Наверное, почти любой тестер скажет - "Хорошо, когда разработчики пишут unit-тесты на свои библиотеки".. Кто-то при этом дополнит " а если не пишут, то давайте напишем мы..." Для чего? Конечно же для того, чтобы итоговый продукт был более качественным. Это все банально и понятно.  Но когда дело касается кода тестерских либ, то тут повсеместно наблюдается весьма странная вещь  - код этих библиотек довольно редко обкладывается тестами.

Попробуем разобраться, почему так происходит...

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

Первый пункт обсуждать, думаю, не имеет смысла - это вопрос опыта, осознанности..

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

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

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

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

uml для описания тест-кейсов

Уже довольно продолжительное время приходится заниматься дизайном тестов для ПО из сферы телекомуникаций.
Как правило тест-кейсы направлены на проверку взаимодействия абонента, сетевого оборудования , ААА-серверов и т.д.
Для описания тестовых случаев мною обычно применялся классический способ - текстовое описание предусловий, последовательности действий, результата.
С некоторых пор стал замечать, что описанным классическим способом тестовым случаям не хватает наглядности, а само описание текстом последовательности пакетов, действий с БД и так далее - довольно утомительное занятие, при котором сам дизайнер нет-нет да оставит что-то между строк как само собой разумеещееся.
Все это приводит к появлению риска неполного или неправильного понимания описания тестировщиком, увеличивает число уточняющих вопросов к дизайнеру при выполении теста. Для решения этой "проблемы" решил попробовать uml-диаграммы. А точнее activity-диаграммы.
Например:
 
На мой взгляд, гораздо нагляднее и лаконичнее, чем расписанная по пунктам последовательность действий, пакетов , ответов...
И чем сложнее тестовый-случай (взять хотя бы сценарий использования Cisco SSG , личного кабинета с какой-нибудь турбокнопкой ) , тем оправданнее становится применение подобных схем. Текстовое описание входных данных , к которым прикрепляется подобная activity-диаграмма делают тест-кейсы подобного рода более наглядными и понятными конечному тестировщику.
Конечно же возникает вопрос способа рисования такой диаграммы.
Лично я не использую никаких десктопных приложений в стиле "перенеси и брось", а просто компиллирую uml-код в изображение.

Вот код для картинки, которая помещена выше:

@startuml
title 
Тест-кейс "Неверный пароль"
end title

participant User
participant NAS
participant Radiusd
participant DB

User    -> NAS: Start internet session with username = 'ivan' and password='007'
NAS     -> Radiusd: Access Request 
Radiusd -> DB: User authentication (check username and password)
DB      -> Radiusd: Incorrect password
Radiusd -> NAS: Access Reject
NAS     -> User: failed to establish internet connection

@enduml

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

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

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

Фаззер: 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

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