четверг, 30 августа 2012 г.

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

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

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

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

4 комментария:

  1. В копилку - хрупкими тесты через интерфейс могут сделать:

    1. Асинхронный интерфейс: страница загрузилась. А, нет, сейчас еще. И еще чуть-чуть. Подождем пару секунд и еще немного.

    2. Неумение тестировщиков администрировать/мониторить сервера. Оказывается, если поднять на одном серваке базу, тестируемую и тестирующую систему, то им всем не хватает памяти. Или процессора. Или ввода-вывода. И что-нибудь начинает тормозить, с вытекающими.

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

    4. Низкое покрытие unit тестами программного интерфейса приложения. Мы же его используем для настройки тестируемой системы, верно? Он меняется, приложение продолжает работать, а тесты падают, падают...

    ОтветитьУдалить
  2. Спасибо за дополнения! 1,2,3 - это я бы отнес к "непредсказуемым" внешним условиям. А вот 4 действительно - отдельная песня. Бывает даже не "низкое покрытие" , а его полное отсутствие )

    ОтветитьУдалить
  3. Плохой дизайн это еще когда наш дизайн не предусматривает изменений в системе и чувствителен к "непредсказуемым" внешним факторам.

    Кстати, п.2 это по факту квинтэссенция плохого дизайна - его просто нет.

    ОтветитьУдалить
    Ответы
    1. Увы, всех изменений не предсказать. Вы правы, надо стараться написать менее "чуствительные" тесты. Главное не потерять при этом в качестве проверки)
      И по п.2 согласен. Вообще до осмысленного "дизайна" надо дорости, дойти. Начинающие автоматизаторы часто грешат подобным использованием record+playback механизмов.

      Удалить