Авто-тесты падали, падают и будут падать. Это данность данная нам в болевых ощущениях, яркостью которых конечно же хочется управлять - перезапуская упавшие тесты например. TestNG поддерживает это желание и предоставляет набор стандартных средств для программного перезапуска. Как, что и где хорошо написано вот в этой статье (и в этой), однако "есть нюансы". А именно, каждый прогон теста попадает в отчёт, т.е. перезапущенные тесты показываются и в "пропущенных" и в "прошедших"/"упавших" - тест 1 раз упал, 3 раза был перезапущен (два раза упал, на последнем прогоне внезапно "позеленел") - в итоге отчёт честно покажет 3 пропущенных и один успешных прогон, но нужно ли это нам? По-хорошему в итоговом отчёте "для начальства" нам интересен только последний раз, именно он идёт в зачёт. Итого появляется задача убирать "ложные" прогоны из отчёта. Как обычно"всё придумали до нас". Добавлю что отфильтровывать лишнее можно по-разному и в разных местах:
- #onFinish() в собственной реализации TestListenerAdapter;
- @AfterMethod/Group/Suite в базовом классе;
- #retry() в реализации IRetryAnalyzer. Но! Это будет работать только для тестов которые так и на "позеленели" в процессе перепрогона.
Выбирайте кому что и когда.
2017-12-30
Почему падают авто-тесты?
Летним ветром навеяло:
Почему падают авто-тесты, какие типовые причины и вообще - доколе? Я бы выделил четыре группы причин:
1. "Битая" функциональность, т.е. таки изъян в тестируемой системе;
2. "Поломанные" тесты - кто-то что-то улучшил, изменились локаторы, поменялась логика работы системы ... ;
3. Что-то нездоровое было с окружением: сеть(задержки-огнестены-впн-ы и т.д.), драйверы, электропитание, админы празднуют Новый Год ... ;
4. НЁХ - "неведомое ёлочное художество". Упали потому что упали, жалко что ли?
Почему падают авто-тесты, какие типовые причины и вообще - доколе? Я бы выделил четыре группы причин:
1. "Битая" функциональность, т.е. таки изъян в тестируемой системе;
2. "Поломанные" тесты - кто-то что-то улучшил, изменились локаторы, поменялась логика работы системы ... ;
3. Что-то нездоровое было с окружением: сеть(задержки-огнестены-впн-ы и т.д.), драйверы, электропитание, админы празднуют Новый Год ... ;
4. НЁХ - "неведомое ёлочное художество". Упали потому что упали, жалко что ли?
Метки:
автоматизация,
рабочее,
тестирование,
process,
test automation
2017-12-08
ИИ всё ближе / AI is closing.
Разум изнурённый борьбой с постоянными падениями на СИ, протухаущими данными и прочими прелестями "взрослого проекта с длинной историей" начинает требовать внедрения ИИ в тесты - "что оно как-то там само разруливала мелкие падения и вопросы типа 'откуда брать кошерные данные прямо вот сейчас'". Главное чтоб потом код тестов не стал на порядок сложнее кода тестируемого приложения.
-------------
All those failing tests and suddenly became invalid data are so frustrating that engineer's mind strats to demand an AI in the test automation solution - just to decide-on-the-fly what-to-do and where-to-go if something went wrong in runtime. The main concern - test automation code should not be more complex than AUT's one.
Метки:
мысли вслух,
производственное,
рабочее,
тестирование,
test automation,
thoughts,
work
2017-12-05
Актуальная банальность (е.н. Прописная истина) / Actuality.
Если нет стабильных тестовых окружений, то количество отличных тестов в наборе это просто цифра.
-------------------
If you do not have stable environments then it does not really matter how many excellent tests you have in the suite.
-------------------
If you do not have stable environments then it does not really matter how many excellent tests you have in the suite.
Метки:
автоматизация,
мысли вслух,
рабочее,
test automation,
thoughts
2017-09-20
Что бы такого учесть при оценке трудозатрат на АТ.
Классический вопрос обоснования необходимости автоматизации тестирования(и не только) -
"Что мы с этого будем иметь? Сколько сэкономим, сколько заработаем, скольких уволим и сколько можно будет перевести в премии?". И как всегда есть очевидные, известные и не очень вещи. Обычно пишут об эффективности автоматизации функционального тестирования как некоей загадочной величине пропорциональной отношению затрат на ручное тестирование к затратам на автоматизированное. И что включать в каждый вид затрат - тут каждый сам себе художник и научрук.
"Что мы с этого будем иметь? Сколько сэкономим, сколько заработаем, скольких уволим и сколько можно будет перевести в премии?". И как всегда есть очевидные, известные и не очень вещи. Обычно пишут об эффективности автоматизации функционального тестирования как некоей загадочной величине пропорциональной отношению затрат на ручное тестирование к затратам на автоматизированное. И что включать в каждый вид затрат - тут каждый сам себе художник и научрук.
На мой выпуклый
военно-морской в затратах на автоматизацию
следует в том числе учитывать:
- людей: кто,
когда, с какой мотивацией и под какой
стимуляцией будет всё это делать,
развивать и поддерживать;
-
документированность: насколько быстро
можно получить ответы на внезапные
вопросы,
нужно ли
разрабатывать сценарии или использовать
готовые и проверенные тестослучаи для
ручного тестирования, каков вообще
порог вхождения в проект(в месяцах).
Здесь же можно упомянуть и общую зрелость
проекта — если всё работает «не-так»,
то автоматизация вряд ли будет быстрой
и эффективной;
- архитектуру
и структуру. Проистекает из вопроса
"что покрываем?". Навскидку:
а. микросервисы
или монолит;
б. сервисы
на основе бинарных протоколов или РЕСТ
какой-нибудь;
в. нужно
воздействовать на одну систему или
несколько.
- технологии
тестируемого: есть ли вообще инструменты
позволяющие это автоматизировать
(пример - мордочки на флеше которые не
всякий популярный инструмент возьмёт);
- технологии
тестового решения. Например использовать
Селениум или Сикули это две большие
разницы в затратах и на разработку и на
поддержку;
- данные:
стабы, моки или живые данные? Как
генерировать и валидировать тестовые
данные(особенно в случае критических
систем(медицина, авиация))? Если моки-стабы,
то есть ли что-то готовое или нужно будет
писать своё?
- безопасников
- дадут ли доступ и добро на манипуляции
с системой, тестовые сборки с
"дополнительными"(отладочными)
функциями?
- среды:
всяко-разные, начиная от где это запускать
и где разворачивать тестируемое. Далеко
не всегда можно получить стенды вот так
сразу, возможно придётся подождать
годик-два;
- СИ: строить
с ноля или интегрироваться в существующее
решение?
- 3-и стороны:
не всем наши усилия могут нравиться,
некоторые могут посчитать, что отбиваем
хлеб, забираем масло и плюём в душу. А уж палки в
колёса ставить могут просто рефлекторно.
Вышеперечисленное
конечно же требует творческого расширения,
углубления и всяческого дополнения. На
то она и затравка.
Ссылки
россыпью:
Метки:
автоматизация,
методичка,
мысли вслух,
рабочее,
тестирование,
test automation,
testing,
thoughts
2017-04-17
2017-03-27
А не позапускать ли мордочковые тесты локально и спокойно?
Если вы когда либо запускали мордочковые тесты локально, то должны знать как ужасно раздражают эти прыгающие окошки, которые так ни к месту перехватывают фокус и вообще ведут себя вызывающе.
А хочется же как? Запустил-забыл-вспомнил-посмотрел отчёт.
Можно завести себе удалённую машину, поднять там Луниевский сервер, гонять тесты через него и т.д. . Можно и виртуалку поднять с аналогичной начинкой. Или виртуалку, но в облаке.
Но есть и другой способ. Тёплый, ламповый, рабоче-погрузочно-крестьянский.
Некая ватага, объединённая высокой и благородной целью сделать мир лучше, краски ярче, а прогоны тестов на основе Луния - быстрее, взяла и устала от всяческих Луниевых Сеток. И от усталости создала свой "каменный цветок" - Selenoid-Луниоид. Вещь эта отлично держит "немеряные тыщщщи" потоков и т.д., но кроме этого облегчает и локальную жизнь, для чего нужно:
2. Настроить (укажите один браузер для начала);
3. Запустить всё это докерное чудо;
4. Указать http://127.0.0.1:4444/wd/hub в качестве урла удалённого сервака Линия;
5. Запустить тесты;
6. Наслаждаться.
В итоге - ничего не мельтешит, всё по-модному в Докере, ещё и в куче браузеров можно запускать. Лепота.
Ссылки:
Метки:
автоматизация,
Луний,
Луниоид,
хитрост,
Selenium,
Selenoid,
test automation,
tricks
2017-03-01
Надумалось по поводу нагрузочных тестов и когда начинать всё то.
Надумалась тут банальщина - если "тормоза" системы заметны невооружённым взглядом, то о нагрузочных тестах задумываться уже поздно и ещё рано.
Метки:
нагрузочное тестирование,
процесс
2017-02-25
Рекламное немного.
Контора "КостыльТехРеш" в сжатые сроки преодолеет любые технические трудности заказчика использую многовековые наработки в области самобытных и маловремязатратных решений.
Метки:
производственное,
реклама,
юмор
2017-02-19
О вежливости и эффективности в переписке, Н-2.
Ещё один совет из области рабочего общения:
-------------------------------------------------------------
A short translation for language impaired ones:
"Do NOT IM like
- You: Hello
- Your colleague: Hello
- You: Would you be able to .... .
---
DO it like:
- You: Hello. Would you be able to ... ."
Just save the time.
Подписаться на:
Сообщения (Atom)