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

Практикум по тест-дизайну 2.0
онлайн, начало 20 cентября
Python для начинающих
онлайн, начало 25 сентября
Первый Онлайн ИНститут Тестировщиков
онлайн, начало 23 сентября
Тестирование REST API
онлайн, начало 23 сентября
Фотография

Стратегия организации большого количества авто тестов


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

#1 Iryna

Iryna

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

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Iryna


Отправлено 12 Июль 2018 - 11:38

Друзья, поделитесь опытом организации авто тестов?

В частности, подходом к организации тэгов.

 

У нас в текущем test suite около 900 тестов (в этом посте речь о UI) и набор не очень продуманных тэгов (добавляли, как и что получалось, в итоге их никто не поддерживает, некоторые тесты отмечены, некоторые - нет, некоторые - неправильными тэгами). Поэтому, на сегодняшний день, надежнее всего - запускать всё, что есть.

И это:

1. Долго (ну... относительно... у нас хороший Grid, но хотелось бы сделать прогоны более полезными). Кроме того, набор тестов растет каждый день.

2. Часто ломаются тесты, которые точно не имеют отношения к твоей текущей фиче и это блокирует релиз (или по крайней мере его замедляет).

 

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

 

К сожалению, мне пока не удалось найти материалы по этой теме.

 

Из очевидных стратегий:

  1. По фазе тестирования (Smoke, Full Regression) -  предполагаю, поделить будет довольно легко, но это не решает проблему тестирования только необходимых компонент.
  2. По приоритетам (Critical, Major, Medium, Minor) -  думаю, это может быть слишком субъективный критерий. Кроме того, это не решает проблему тестирования только необходимых компонент.
  3. По функционалу (User profile, Search, Checkout, etc.) - это решает проблему тестирования только необходимых компонент, но думаю, будет очень сложно четко определить границы разделения функционала и правильно его назвать, ведь один тест может относиться к нескольким областям, также есть зависимые области (придётся создавать и поддерживать ручную  матрицу зависимости компонент???)
  4. Комбинация из пары стратегий - скорее всего более точная, но команда может быть не в восторге от сложности определения к какому (-им) тэгу отнести тест.

  • 0

#2 checo

checo

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

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

Отправлено 12 Июль 2018 - 14:28

А как организована ручная регрессия? Как она разбивается по компонентам?

 

Часто ломаются тесты, которые точно не имеют отношения к твоей текущей фиче

Если нужно выделять именно текущие фичи, можно ставить тэги с номерами фич.

 

А если надо прогнать еще и старые тесты на этот компонент, то:

 

один тест может относиться к нескольким областям

что плохого в том, чтобы добавить тэги для всех областей, чтобы потом точно всё проверить?


  • 0

#3 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 245 сообщений
  • Город:Москва


Отправлено 12 Июль 2018 - 14:38

Прикрепленный файл  MD4net.wmv   39,85МБ   9 Количество загрузок:

 

10 лет прошло. Мало, что изменилось. 

 

Надеюсь Михаил и Павел не обидятся.


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней

 


#4 ch_ip

ch_ip

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 097 сообщений
  • ФИО:Павел Абдюшев
  • Город:Москва


Отправлено 12 Июль 2018 - 15:38

Добавлю презентацию, а то в видео слайды очень сложно читать.

Прикрепленные файлы


  • 0

#5 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 066 сообщений
  • Город:Москва

Отправлено 12 Июль 2018 - 23:25

Smoke ST -> ST -> Smoke IFT -> IFT
  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#6 Iryna

Iryna

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

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Iryna


Отправлено 13 Июль 2018 - 10:36

Добавлю презентацию, а то в видео слайды очень сложно читать.

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


  • 0

#7 Iryna

Iryna

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

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Iryna


Отправлено 13 Июль 2018 - 10:49


А как организована ручная регрессия? Как она разбивается по компонентам?

 

Часто ломаются тесты, которые точно не имеют отношения к твоей текущей фиче

Если нужно выделять именно текущие фичи, можно ставить тэги с номерами фич.

 

А если надо прогнать еще и старые тесты на этот компонент, то:

 

один тест может относиться к нескольким областям

что плохого в том, чтобы добавить тэги для всех областей, чтобы потом точно всё проверить?

 

 

 

Ручной регресии нет (и мы стремимся это соблюдать). Авто тесты сейчас - два больших куска, которые мы как раз и хотим дробить на более мелкие. Но я не уверена, что разбивка по фичам - оптимальный вариант (отсюда и опрос выше).

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

 

"что плохого в том, чтобы добавить тэги для всех областей, чтобы потом точно всё проверить?" - совсем ничего, это было бы идеально, но проблема - однозначно определить все области и связи между ними, т.к. если например взять область под названием "Log in and Registration", то, с одной стороны, в нее можно добраться через разные страницы (тесты использующие эти страницы тоже включать в этот тэг?) и, с другой стороны, эта область является предпосылкой для других шагов в других тестах (эти тесты тоже этим тэгом отмечать?). Конечно, идеально было бы создать список однозначно определяющий непересекающиеся функциональные области, но я не могу найти материалов о подходе к такой задаче. И вторая проблема этого подхода - необходимость поддержания матрицы связей компонентов, чтобы проверять зависимые компоненты. Хочется минимум наиболее содержательных тэгов :)


  • 0

#8 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 806 сообщений
  • ФИО:Dmitry Petrov

Отправлено 13 Июль 2018 - 13:12

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


  • 0

#9 Iryna

Iryna

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

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Iryna


Отправлено 13 Июль 2018 - 15:32

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

 

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


  • 0


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



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

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

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