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

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

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

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

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

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

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

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

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

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

Учим 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);

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

Практичный WWW::Mechanize

Так сложилось, что мне частенько приходится пользоваться различными виртуальными хостингами.
С недавнего времени среди тех, которыми я часто пользуюсь появился такой хостер, который разрешает подключаться к серверу по SSH только с одного IP.
При этом , конечно же, позволяет указывать разрешенный IP в хостинг-панели.
В целом, штука конечно-же, секьюрная , но немного неудобная.
Теперь мы все стали мобильные, наши IP-ы часто меняются - дома один, в дороге или кафе - другой,  в офисе - третий.
Один раз залезешь - переключишь, другой, а на третий уже автоматизируешь.
Так поступил и я... В голове сразу мелькнули мысли от трех вариантах - Selenium, Jmeter и гипотетический perl-скрипт с использованием WWW::Mechanize.

По ряду причин решил использовать второй третий вариант...

Для этого нужно:

1. perl  c установленным WWW::Mechanize, а лучше и Test::WWW::Mechanize
2. Firefox с включенным плагином MozRepl ( ТОЛЬКО ЕСЛИ ЗАХОТИТЕ СНИМАТЬ СКРИНШОТЫ!)
3. Пара минут времени

#!/usr/bin/perl -w use utf8;
 use Test::More "no_plan"; 
 use Test::WWW::Mechanize; 
 use constant URL => 'нужный урл'; 
 use constant LOGIN =>; 'логин к админ панели'; 
 use constant PASSWORD =>; 'пароль к админ панели'; 

 my $m = Test::WWW::Mechanize->new(autolint=>0); 
 $m->get_ok( URL , 'Open login page'); 
 $m->content_contains( 'Контрольная панель' , 'Check we are on right page'); 
 $m->submit_form_ok({ 
    form_number =>; 1, 
    fields => { 
      login => LOGIN, 
      password => PASSWORD, 
    }, 
 } , 'Submit login form' ); 
 $m->follow_link_ok( { 
        text_regex => qr/Настройки SSH/i 
     } , 'Follow ssh settings link'); 
 $m->content_contains( 'Настройки SSH' , "Check we are on right page"); 
 $m-$gt;follow_link_ok( {id =>; 'user-ip' }, "Allow current ip"); 
 my $link =$m->find_link( id => 'user-ip' ); ok($link, 'Get current ip from page'); 
 $m->submit_form_ok({ form_number => 1, fields => { ip => $link->text, }, } , 'Submit ip changing form' );


В скрипте используется Test::WWW::Mechanize - обертка над WWW::Mechanize  , которая используется в написании автотестов, что делает этот скрипт по сути автотестом с наглядным логированием в консоль:

$ ./ssh_switcher 
ok 1 - Open login page 
ok 2 - Check we are on right page 
ok 3 - Submit login form 
ok 4 - Follow ssh settings link 
ok 5 - Check we are on right page 
ok 6 - Allow current ip 

ok 7 - Get current ip from page
ok 8 - Submit ip changing form
1..8

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

Таким образом, скрипт реально экономит мне время и нервы, позволяя одним кликом разрешить текущий ip-с которым я вышел в сеть - не надо открывать браузер, панель, помнить и вводить логин , пароль (очень хитрый и длинный пароль)...

Разумеется, это  подходит только для данного конкретного хостера и его алгоритма смены разрешенного ip ) И, конечно же, хостер может изменить названия переменных, ссылок, вообще поменять логику - это не проблема, скорректировать скрипт дело пары минут :)

Не а ежели хостер навесит капчу, то будет очень интересно решить эту задачу, тем более, что кое-какие наработки где-то в дебрях харда валялись )

p.s. в целом WWW::Mechanize очень даже применим для автоматизации сценариев , а его обертка Test::WWW::Mechanize - даже для создания функциональных автотестов.

эти хрупкие автотесты

Ни для кого не секрет, что одним из обстоятельств, удерживающих некоторых от создания gui-шных автотестов по типу Selenium-овских , является большая вероятность написания хрупких (fragile) тестов. И действительно , для подобного вида тестов вероятность получить хрупкий тест более высока, чем для других видов.

Посмотрим, что же делает подобные тесты хрупкими:

1. Несогласованность с разработчиками. Зачастую тестировщику-автоматизатору достается интерфейс и функционал мало пригодный для "нехрупкой" автоматизации. Например (Если говорить о web), беспорядочное отношение к именованию контролов, присовению идентификаторов важным контейнерам, таблицам и т.д. В данной ситуации необходима совместная выработка общих правил и дальнейшее соблюдение соглашений. Разработчики любят хорошие ТЗ для того, чтобы было "комфортно" программировать, а тестировщики любят предсказуемый код и интерфейсы, которые "комфортно" автоматизировать.
2. Бездумное использование "записанных" тестов. Тут лучше привести пример. Есть таблица со списком объектов из БД. Гипотетический тест проверяет то, что она содержит запись об определенном объекте. Записывалка тестов генерирует код, который ищет нужную ячейку с текстом по xpath локатору с явным индексами tr и td. Тестировщик использует сгенерированный код без изменений и через некоторое время получает провал теста. В чем дело? А просто список объектов пополнен новым и старый сдвинут. Или разработчик выводит список без сортировки и СУБД вдруг "сфетчила" записи в новом порядке. Тут, конечно, можно запросить "поддержку тестирования" в виде добавления сортировки. Но правильнее сначала отредактировать локатор , убрав индексы (если, конечно, соблюдение порядока следования записей не критично), ну а потом можно и сортировку попросить.. для предсказуемости )
3. Часто меняющиеся требования к продукту. Тут уж никуда не деться от переделывания тестов. Рынок диктует свои условия. Поменялись требования, поменялся функционал / внешний вид , меняются тесты. Если подобные правки слишком часты и накладны, то стоит подумать о том, чтобы отказаться от автоматизации данного участка.
4. Плохой дизайн тестов. Тестируемая система не менялась,  а тест то и дело проваливается. Причиной может послужить недостаточно вдумчивое проектирование теста, не учитывающее возможное изменение тех или иных внешних по отношению к тесту условий при неизменности тестируемого функционала. Грубо говоря, тестировщик создал код , похожий на тот, что создают "записывалки". Рекордеры ничего не "знают" об особенностях, которые обязан знать и учитывать автоматизатор.

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

"Сыпятся" диски - "валятся" тесты

Все мы привыкли к провалам автотестов из-за ошибок в тестируемом коде, в самих тестах , в конфигурации и т.д.
Но иногда случаются действительно редкие вещи. Как, например, сегодня в моей практике.
На одном из серверов автоматического тестирования часть тестов провалилась без видимых на то причин. Изменений, способных привести к провалам, не было ни в коде, ни в самих тестах , ни в тестовом окружении. Тесты имели длинную историю успешного прохождения - скучно даже было. И вот провалились.
После поверхностного анализа стало ясно, что не были созданы все тестовые данные - Oracle ругнулся так, что я никогда такого раньше не видел ) А точнее - не смог добавить extent в один из TABLESPACE-ов.
Смотрю в субд - инстанс в RO-режиме.
При попытке перезапустить бд получаю ошибку:

ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/u02/oradata/index01.dbf'

Пробую рекавери файла данных не помогает - из ругани Oracle становится ясно, что файловая система, где располагается том для файлов данных, находится также в RO-режиме. Сервер никто не трогал. Свет не отрубали (uptime сервака 52 дня). Лезу в /var/log/messages и вижу, что возникла проблема с ФС из-за проблемных блоков харда и ядро само перемонтировало раздел в RO-режиме. Теперь все встало на свои места. Далее лечение последствий в виде последовательных вызовов: umount, fsck, mount Ну и перезапуск oracle. В общем, мораль , железо тоже не выдерживает иногда :)

Взаимное влияние автотестов

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

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

Если у вас, как и большинства, тесты запускаются всегда в одном и том же порядке, то можно применить "метод перемешивания" автотестов. Сделав их порядок запуска каждый раз разным.
Чтобы это реализовать, скорее всего, потребуется реализация "перемешивателя" (mixer) списка тестов.
Отмечу, что не всегда можно просто взять и перемешать тесты.

Вот три основных типовых случая:

1. Ваши тесты ДОЛЖНЫ быть автономными согласно принятым у вас принципам автоматизации
Тут вы законно можете ожидать одинаковых результатов в независимости от порядка запуска

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

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

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

Еще важно понимать, что данный метод не выявит сразу ВСЕХ проблемных зависимостей. Но постепенно от запуска к запуску позволит минимизировать их количество.
Так картина будет даже нагляднее..

Автотесты: почему важно "не делать лишних движений"

Несколько слов о дизайне автоматических тестов.
Точнее о вопросе избыточности проверок. Существует подход к разработке модульных (Unit) автоматических тестов, который можно описать так "Проверяем одно условие за один тест" (Verify one condition per test). Применение такой стратегии дает множество плюсов: при провале тестов можно максимально быстро выявить узкое место, и, как следствие, максимально быстро устранить проблему. Пусть тестов станет больше, но плюсы, как правило перевешивают.
При автоматизации более громоздких регрессионных функциональных тестов подобная стратегия также применима. Только в роли единицы проверки должны выступать уже не "условия" , а конкретный вариант поведения. При этом, все что лишнее, и не влияющее на данный конкретный вариант поведения должно быть безжалостно ампутировано. Лишними могут быть: некоторые инициализирующие параметры объектов, а также проверки , которые уже делались или будут делаться в тестах, специально для этого предназначенных. В общем, не надо делать лишних движений, у которых нет конкретных целей.
Вот пример из реальной практике, иллюстрирующий вышесказанное:

1. есть автоматический функциональный тест, проверяющий некий вариант поведения системы
2. в ходе его инициализации создается объект "клиент", у которого есть как обязательные так и необязательные параметры, причем данному тесту ни один из них не важен - важен факт наличия объекта "клиент" и все..
3. тестировщик, который создавал тест, то ли копипастом, то ли для разнообразия решил заполнить поле email , причем указал там строку с емейлом "не по RFC" (на момент написания теста проверке необязательного email внимания не уделялось)
4. тест долгое время работал, проверял нужные варианты, давал результат
5. в какой-то момент проверке полей данного объекта уделили внимание, и ужесточили ее, создав соответствующие автотесты на эту новую "функциональность"
6. старый же тест начал проваливаться, причем, не доходя до своей целевой проверки - проваливаться на этапе инициализации. Причина, думаю, ясна - строка "отбалды" в поле email.

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

Вывод: чуть больше осознанности может сэкономить чуть больше времени для чуть более полезных вещей :)

Анализ покрытия кода с помощью gcov+lcov

Сегодня наконец-то выделил время на то, чтобы наладить анализ покрытия кода. Пока только покрытие операторов и функций.
Тестируемое приложение написано на Си, ОС linux. Компиллятор gcc. Приложение должно быть собрано с флагами компиллятора : -ftest-coverage -fprofile-arcs.
Для анализа покрытия использовалась утилита gcov, которая помогает провести анализ того, какие строчки кода и сколько раз были задействованы в ходе выполнения приложения.
В результате выполнения приложения генерируются специальные файлы для каждого файла исходников , в которых и содержится собранная информация о покрытии. Дальше с помощью утилиты lcov полученные данные обрабатываются и генерируется , цветастый и веселый html-отчет . Я , как преимущественно визуалист, особенно был рад получившейся наглядности :) Даже в первом приближении мне стало понятно, что в плане автоматизации будут некоторые изменения :)
Упомянутые утилиты бесплатны, присутствуют в репозиториях всех популярных дистрибутивов linux, а также могут быть скачаны с sourceforge, например.
Итак, метод опробовал. Планирую проводить отдельный анализ покрытия для сеансов unit-тестирования и отдельно для сеансов автоматического регрессионного тестирования.
В более отдаленной перспективе постараюсь также наладить анализ покрытия путей выполнения и условий, а также освоить gcov в связке с gprof, для профилирования приложения.

Тем, кто планирует внедрять подобные практики позволю сразу дать совет. Использование тех или иных инструментов для генерации статистики покрытия влияет на скорость работы приложения, поэтому для анализа покрытия необходимо запускать сеансы отдельные от сеансов регрессионного автоматического тестирования.
p.s.

лучше 1 раз увидеть, чем 100 раз предположить :)

UPD 05/10/2011
При анализе результатов ночного прогона обнаружил небольшой бонус - gcov умеет и условия анализировать (см. пример на картинке вверху статьи ) . Приятная неожиданность :)

Загрузка файлов клиентом и Selenium

В целях автоматизации тестирования  некоторых сценариев точечно применяю Selenium-тесты на perl-е + Selenium RC.
До сих пор не приходилось сталкиваться с автоматизацией кейсов, связанных  с аплоадом файлов. И вот такая необходимость возникла.
Итак , запускаю Firefox + Selenium IDE , записываю действия по аплоаду и экспортирую в perl-виде.
Смотрю, какими же командами IDE мне сэмулировал нужную последовательность. Удивленно вижу, что для указания нужного файла используется всего навсего type с локатором файлового INPUT-поля и полным путем файла.
Отсекаю лишнее ,добавляю нужное , встраиваю в perl-фреймворк и вижу , что тест не проходит.
Копаю perl-библиотеку для работы с Selenium (WWW::Selenium) , радостно нахожу команду attach_file , пытаюсь ее применить и не получаю результата.
Гуглю, вижу всяческие рецепты,  как можно извратиться с помощью спец js-скриптов, дополнительных exe-утилит (для Windows).. Ни то ни то не подходит. Как раз в тот момент, когда хотелось "забить" на аплоад, в "буржнете" попался очень простой совет - принудительно установить фокус на поле с именем файла после его заполнения. НЕ веря в успех, попробовал и получилось...Работает (в *chrome - режиме) , аплоадит, тестируется =)

p.s.
По поводу Selenium 2.0 - слышал, что там проблема пользовательского аплоада стоит гораздо менее остро. Лишний повод познакомится и попробовать.

UPD 22/08/2011:
Перечитал пост и понял, что из него до конца неясно, какая же последовательность команд решает проблему? Ответ: focus +  type . attachfile можно вообще не использовать. По крайней мере, в моей ситуации со стандартными контролами пользы от этой команды  никакой.

lsof+gdb - надежные помощники при "трудном" моделировании

Совсем недавно в ходе попыток моделирования очередного "мигающего" и трудновоспроизводимого бага потребовалось запустить очень продолжительную серию испытаний , в ходе которой требовалось эмулировать частую потерю соединения приложения с СУБД. Эмуляция активности приложения , естественно, автоматизирована. Продолжительность теста - минимум 30 минут, максимум - 2-3 часа. В общем, понятно, что вручную "дергать" витую пару - не вариант =) Первое, что пришло в голову использовать файер (iptables). Попробовали - и по ряду причин (здесь их не описываю) вынуждены были отказаться от этого способа.

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

С помощью lsof узнаем дескрипторы соединений (у ислледуемого нами их могло быть несколько), а с помощью gdb в "batch"-режиме закрываем сокеты по их дескрипторам.


#генерируем файл с командами на закрытие нужных нам дескрипторов (в данном случае дескрипторы соединения с СУБД висящей на фиксированном порту 1521)

lsof -p 5239 | grep ':1521' | awk '{print $4}' | sed 's/u//' | awk '{print "call shutdown("$1",2)"}' > commands

#скармливаем пакет команд gdb

gdb -p 5239 -batch -x commands



Указанные команды помещаем в цикл с произвольными задержками между итерациями и в результате приложение начинает работать в условиях периодичеких "проблем с сетью и соединением с СУБД".

Все это под linux, все это бесплатно , быстро и эффективно.

Возможно, кто-то спросит "Как сделать аналогичное под Windows?" - сразу не отвечу, но на досуге ничего не мешает выяснить, если это действительно кому-то понадобится =)

Selenium RC + Firefox + crond

Некоторое время назад потребовалось обеспечить бесперебойность работы selenium rc на одном из linux-серверов с установленной X-window.
До этого RC вручную запускался вручную либо непосредственно на сервере (DISPLAY :0) либо вручную же через vnc. После перезагрузки сервера или из-за пока неустановленных редких сбоев в самом RC процесс автоматического тестирования нарушался. Для решения проблемы было решено добавить запуск Selenium RC в cron.
В crontab была добавлена соответствующая строчка, запускающая RC-сервер. В этот момент не было учтено , что firefox оконное приложение и требует возможности работать на конкретном дисплее =) Соответственно по крону RC-сервер стартовать не мог. Вернее сам-то сервер стартовал, но запустить X-овое приложение (firefox) без дисплея уже не мог.
Возник вопрос о том, о каком вообще дисплее может идти речь, если приложение запускается в ситуации отсутствия каких-либо X-сессий? На некоторое (короткое) время возможность запуска X-программ из под cron была поставлена под сомнение, но довольно быстро было найдено решение.
В описанной ситуации можно использовать утилиту Xvfb, которая позволяет совершать графические операции в памяти и запускать "иксовые" приложения на виртуальных дисплеях.
Ниже привожу последовательность команд, решившая мою проблему:

Xvfb :1
export DISPLAY=:1
java -jar selenium-server.jar

Таким образом, если SeleniumRC будет запущен из-под cron описанным образом , то запускаемый им firefox будет запускаться на дисплее :1 и послушно выполнять все команды автотеста, с которого при желании можно даже снять скриншоты)

Надеюсь, данная информация кому-нибудь поможет и сэкономит время.

Первый опыт непрерывной интеграции

Пару лет назад, когда я только начинал проектировать систему автоматического тестирования программного обеспечения, которое производит мой работодатель, я еще не знал такого понятия как "непрерывная интеграция" (wiki). Теперь, оценивая сделанное, я прихожу к выводу, что во многом (но не во всем) этой самой "непрерывной интеграции" удалось достичь. Далее я вкратце попытаюсь рассказать какими именно средствами это было реализовано...

Для сборки проекта используется кроссплатформенная система сборки CMake (взамен устаревших и более сложных в использовании Autotools), а также две другие утилиты из CMake-семейства: CTest и CDash.
CTest используется для прогона модульных и комплексных автотестов.
CDash для обработки, хранения и отображения результатов автоматических сборок (результатов работы CTest-а).

Для проведения автосборок и сеансов автоматического тестирования выделен отдельный сервер.
cron-настроен на проведение автоматических ночных сборок.
Результаты каждого ночного сеанса тестирования автоматически экспортируются в CDash(в xml-формате) для обработки , архивирования и возможности отображения и анализа в любой момент времени.
Так "система" работает сейчас. Но, как говорится, всегда есть к чему стремиться. Проведение ночных сборок хоть и повышает скорость реакции на "поломки" в коде, но иногда и такая скорость недостаточна.
Сейчас есть желание и потребность прогона сборки после каждого коммита в репозиторий. Проблема в том, что коммиты могут быть многочисленны в течение одного дня и прогонять весь набор тестов (модульных и комплексных) после каждого изменения может стать трудновыполнимой задачей. В связи с этим вижу 2 варианта решения проблемы:

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

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

В общем, в ближайшее время задуманное будет реализовано.

Комментарии, вопросы, отзывы - милости прошу )

Слишком умная мозилла (к вопросу о кроссброузерности)

Основным броузером для отладки и тестирования веб-интерфейса нашего продукта является Firefox. Недавно опытным путем выяснилась одна его особенность: дописывать закрывающие '>' для html-тегов.

Выявили так: была сделана доработка, протестирована вручную под Firefox. Написан Seleinum-автотест , который был прогнан на IE - тест провалился.
Причина - не был закрыт один из тегов td из-за чего не отобразился на форме один из ключевых контролов.
Этот же тест затем провалился и на Opera.

Вопрос, на что лучше - этот "искусственный интеллект" Мозиллы, позволяющий все-таки работать с формой, имеющей мелкие недоработки, или более четкое соблюдение стандартов в IE и Opera ?