t.me/atinfo_chat Telegram группа по автоматизации тестирования

Спор возник касательно функционального тестирования

Теги: #<Tag:0x00007f7487ed6680> #<Tag:0x00007f7487ed6590> #<Tag:0x00007f7487ed6478> #<Tag:0x00007f7487ed63b0>

У нас с коллегой возник спор по одному поводу.
Итак, выслушайте две стороны.

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

  1. Одна сторона: проверяем по честному как пользователь: кликаем #webdriver на каждую ссылку и проверяем содержимое страницы и открытый URL. Возвращаемся обратно и кликаем на второй. Ну или, если открывается по ссылке в новом окне - закрываем окно и кликаем на остальные ссылки
  2. Вторая сторона: проверяем к примеру первую ссылку - кликаем #webdriver, убеждаемся, что открылась нужная страница с нужным содержимым. Остальные 99 страниц проверяем простым GET-запросом, дергая за URL’ы, которые в теге <a href=''></a>, и парсим содержимое. Что естественно быстрее.

Вопрос, имеет ли право на жизнь вариант второй стороны? А как бы проверили вы данный сценарий?

За какой Вы вариант?

  • Первая сторона
  • Вторая сторона
  • Другое, отвечу в комментариях

0 участников

1 Симпатия

Если время не важно - первый вариант да ещё и в нескольких браузерах.
Если хочется побыстрее - конечно второй вариант + несколько браузеров.
Но лучше сразу сделать быстро. На крайняк, добавить открытие последней ссылки тоже полностью.

1 Симпатия

Вам сначала про тест-дизайн надо было бы поспорить, а не “как это решить в лоб”.
Такие задачи не решаются приведенными способами.

3 Симпатий

Спасибо за отклик.
Ответьте на вопрос, не касаясь тест-дизайна (это не наша прерогатива): как решаются такие задачи?

если надо протестить только что выдаётся статус 200 то веб драйвер я бы даже не запускал, проверял бы через запросы.

Это же один из сценариев, их много. Все равно вебдрайвер уже стартовал.

Ну я бы не была так категорична, мы же не знаем цель задачи.

  1. Если задача протестировать 100% доступность юзеру всех линок и взаимодействия сними, то однозначно клики, причем на разных резрешениях, чтобы убедиться, что ничего не закрывает элемент, и пользователь может реально кликнуть на ссылку. А то бывает так что перекрыто чем-то полупрозрачным или частично, и элемент видим, а кликнуть на него нельзя
  2. Если цель проверить целостность данных. То достаточно будет просто пройтись гетом по списку урлов.

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

4 Симпатий

Подробнее про тест-дизайн можно? спасибо.

Спасибо за подробный ответ. Вариант с кликом на рандомную мне нравится.

Ваша задача не до конца определена. Вы что тестируете - список или фильтр?
Мануальный кейс есть на это?
Тесты с неопределенным количеством степов и ожидаемых результатов не имеет права на жизнь :slight_smile:

Данного рода необпределенность всегда легко нивелируется словом “все” :wink:

Проверить целостность Всех ссылок

1 Симпатия

За слово “все” в ТС виновник награждается увлекательным занятием “аппдейт тест-кейсов”.
Но даже слово “все”, при тщательном подходе к подготовке данных, можно в результате привести к определенности.

1 Симпатия

Тестируется список.
Мануальный кейс примерно такой:
1.Кликнуть по полю поиска
2. Выбрать из выпадающего списка некий пункт
3. Кликнуть на кнопку Найти
4. Проверить, что открылась ожидаемая страница

Все-равно “размыто”. Общий посыл такой - если вы не можете контролировать состояние AUT, вы не можете его тестировать.
По вашему кейсу вы должны привести AUT в такому состоянию, в котором вы точно будете значить результат после каждого шага.

Имелось ввиду:

1.Кликнуть по полю поиска
2. Выбрать из выпадающего списка конкретный пункт
3. Кликнуть на кнопку Найти
4. Проверить, что открылась конкретная страница

Не вижу тут ничего “динамического”.

В данном конкретном случае действительно ничего динамического нет.
Давайте рассмотрим его.
Что вы скажете относительно этого кейса с точки зрения тест-дизайна? Возвращаясь к вашему первому ответу в этом топике.

Трудно сказать не зная вашей предметной области и что есть “конкретный”.
Ну пложим что все ок (хотя по факту это будет скорее всего не так) - и в этом случае будет корректнее проверять “прямыми” кликами/переходами.

Хорошо, спасибо за мнение.

Я бы по честному проверял клик (как это будет делать пользователь. Мы ведь для него тестируем, да?).
Пускай не будет быстро но будет честно!
Если есть необходимость ускорить процесс то можно задаться вопросом “а действительно ли нам нужно каждый раз проверять все 100 ссылок?” и сделать проверку рандомных ссылок при каждом прогоне. Ну и параллелизацию никто не отменял. Второй вариант тоже имеет право на жизнь конечно, но это не имитация действий пользователя и нет гарантий что такие тесты не пропустят багу. Например, чисто гипотетически - что если по клику на кнопке действия не будет? Получим зеленые тесты при наличии багов.

2 Симпатий