Перейти к содержимому

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Логи как инструмент тестировщика
онлайн, начало 30 ноября
Тестирование REST API
онлайн, начало 30 ноября
Фотография

Как грамотно построить архитектуру автотестов?

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

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 7

#1 3id010n

3id010n

    Новый участник

  • Members
  • Pip
  • 2 сообщений
  • ФИО:Zed Shaw

Отправлено 28 ноября 2019 - 14:01

Всем доброго времени суток! Не первый раз слышу от многих (более опытных) коллег в сети, что нужно строить архитектуру автотестов так же как и архитектуру основного ПО, в том смысле, что (внезапно) автотесты - это точно такое же ПО (только более узкоспециализированное) и оно подвержено точно таким же проблемам и особенностям как и обычное ПО. Есть наиболее распространенные паттерны проектирования, такие как, например, PageObject'ы, DataProvider'ы, etc. Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?
  • 0

#2 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 28 ноября 2019 - 15:00

храните тесты прямо рядом с тестируемым кодом, в соседних классах


  • 0

#3 3id010n

3id010n

    Новый участник

  • Members
  • Pip
  • 2 сообщений
  • ФИО:Zed Shaw

Отправлено 29 ноября 2019 - 00:27

а и, да, забыл сказать, что доступа к исходному коду тестируемого ПО нет (черный ящик), конечные UI сценарии
  • 0

#4 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 891 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 29 ноября 2019 - 11:02

Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

Если вообще нет доступа ни к исходному коду, ни к его создателям, то адекватного решения не будет.

 

Придётся не через N лет выбросить автотесты, а уже через N недель (повторять в цикле).

 

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

 

Это будет совершенно недоброе время суток, но без этого никак.


  • 0

Software Testing Glossary - простыми словами о непростых словах.


#5 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 29 ноября 2019 - 11:17

согласен, надо выбрасывать уже сейчас

 

и чем раньше, тем лучше


  • 0

#6 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 29 ноября 2019 - 11:52

Всем доброго времени суток! Не первый раз слышу от многих (более опытных) коллег в сети, что нужно строить архитектуру автотестов так же как и архитектуру основного ПО, в том смысле, что (внезапно) автотесты - это точно такое же ПО (только более узкоспециализированное) и оно подвержено точно таким же проблемам и особенностям как и обычное ПО. Есть наиболее распространенные паттерны проектирования, такие как, например, PageObject'ы, DataProvider'ы, etc. Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

 

Рассмотрим альтернативу выбрасыванию :wink:

Если ПО развивается, тесты придется развивать параллельно с ним. Тесты, работаюшие через N лет - это фантастика.

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

А если по теме вопроса - "Как это всё более-менее грамотно построить", то этого не рассказать на форуме.

Читайте книги, например Р. Мартин "Чистый код" и "Чистая архитектура", и черпайте из них то, что кажется уместным для тестирования.


  • 0

#7 user12

user12

    Специалист

  • Members
  • PipPipPipPipPip
  • 843 сообщений
  • ФИО:Виктор
  • Город:Минск


Отправлено 29 ноября 2019 - 12:31

Вопрос очень общий, что могу порекомендовать:

https://www.youtube.com/watch?v=vrjN8VTeuOk

Также отличное видео про не только паттерны, но и какой должен быть фрейворк:

https://www.youtube.com/watch?v=EnooA2kEhY0

Видео почему-то норм не вставляются :(


  • 0

#8 Evgenii163

Evgenii163

    Новый участник

  • Members
  • Pip
  • 31 сообщений
  • ФИО:Клочков Евгений Анатольевич
  • Город:Тольятти

Отправлено 29 ноября 2019 - 14:52

Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

В моей конторе разработчики не особо хотят что-либо делать ради удобства разработки и поддержки АТ. Получается что мои тестируемые проекты тоже в некоторой степени для меня черный ящик. По этому я выкручиваюсь следующим образом:

 

Изучив главные аспекты автоматизации, советую максимально избегать управления тестовыми данными через UI. Используй API например для авторизации или создания пререквезитов для теста. Уж к API у тебя всегда должен быть доступ и ты должен уметь написать запрос к серверу в твоем фреймворке для автоетстов. В моем случае такой подход упрощает мне поддержку и разработку тестов.


  • 0


Программирование на С# для тестировщиков
онлайн
Автоматизатор мобильных приложений
онлайн
Selenium WebDriver: полное руководство
онлайн
Программирование на Python для тестировщиков
онлайн




Темы с аналогичным тегами автотесты, архитектура

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале