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

Первый Онлайн ИНститут Тестировщиков
онлайн, начало 15 ноября
Практикум по тест-дизайну 2.0
онлайн, начало 16 ноября
Программирование на Java для тестировщиков
онлайн, начало 16 ноября
Тестирование веб-приложений 2.0
онлайн, начало 16 ноября
Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 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
  • 319 сообщений
  • Город:Н.Новгород

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

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

 

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

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

 

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

 

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

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


  • 0

#3 SALar

SALar

    Гуру

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


Отправлено 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
  • PipPipPipPipPip
  • 885 сообщений
  • Город:Москва

Отправлено 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
  • 731 сообщений
  • ФИО:Dmitry Petrov

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

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


  • 0

#9 Iryna

Iryna

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

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


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

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

 

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


  • 0


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



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

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

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