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