У нас с коллегой возник спор по одному поводу.
Итак, выслушайте две стороны.
Есть сценарий, где надо проверить некий список ссылок, который динамически меняется в результате некоего выбора в фильтре. Допустим, их сто штук на экране.
Одна сторона: проверяем по честному как пользователь: кликаем #webdriver на каждую ссылку и проверяем содержимое страницы и открытый URL. Возвращаемся обратно и кликаем на второй. Ну или, если открывается по ссылке в новом окне - закрываем окно и кликаем на остальные ссылки
Вторая сторона: проверяем к примеру первую ссылку - кликаем #webdriver, убеждаемся, что открылась нужная страница с нужным содержимым. Остальные 99 страниц проверяем простым GET-запросом, дергая за URL’ы, которые в теге <a href=''></a>, и парсим содержимое. Что естественно быстрее.
Вопрос, имеет ли право на жизнь вариант второй стороны? А как бы проверили вы данный сценарий?
Если время не важно - первый вариант да ещё и в нескольких браузерах.
Если хочется побыстрее - конечно второй вариант + несколько браузеров.
Но лучше сразу сделать быстро. На крайняк, добавить открытие последней ссылки тоже полностью.
Ну я бы не была так категорична, мы же не знаем цель задачи.
Если задача протестировать 100% доступность юзеру всех линок и взаимодействия сними, то однозначно клики, причем на разных резрешениях, чтобы убедиться, что ничего не закрывает элемент, и пользователь может реально кликнуть на ссылку. А то бывает так что перекрыто чем-то полупрозрачным или частично, и элемент видим, а кликнуть на него нельзя
Если цель проверить целостность данных. То достаточно будет просто пройтись гетом по списку урлов.
А дальше полет для оптимизации и принятия рисков. Комбинируйте, кликайте рандомную, но обязательно в логах указывайте, на какую именно вы кликали в этот раз, иначе разбираться будете долго.
Ваша задача не до конца определена. Вы что тестируете - список или фильтр?
Мануальный кейс есть на это?
Тесты с неопределенным количеством степов и ожидаемых результатов не имеет права на жизнь
За слово “все” в ТС виновник награждается увлекательным занятием “аппдейт тест-кейсов”.
Но даже слово “все”, при тщательном подходе к подготовке данных, можно в результате привести к определенности.
Тестируется список.
Мануальный кейс примерно такой:
1.Кликнуть по полю поиска
2. Выбрать из выпадающего списка некий пункт
3. Кликнуть на кнопку Найти
4. Проверить, что открылась ожидаемая страница
Все-равно “размыто”. Общий посыл такой - если вы не можете контролировать состояние AUT, вы не можете его тестировать.
По вашему кейсу вы должны привести AUT в такому состоянию, в котором вы точно будете значить результат после каждого шага.
1.Кликнуть по полю поиска
2. Выбрать из выпадающего списка конкретный пункт
3. Кликнуть на кнопку Найти
4. Проверить, что открылась конкретная страница
В данном конкретном случае действительно ничего динамического нет.
Давайте рассмотрим его.
Что вы скажете относительно этого кейса с точки зрения тест-дизайна? Возвращаясь к вашему первому ответу в этом топике.
Трудно сказать не зная вашей предметной области и что есть “конкретный”.
Ну пложим что все ок (хотя по факту это будет скорее всего не так) - и в этом случае будет корректнее проверять “прямыми” кликами/переходами.
Я бы по честному проверял клик (как это будет делать пользователь. Мы ведь для него тестируем, да?).
Пускай не будет быстро но будет честно!
Если есть необходимость ускорить процесс то можно задаться вопросом “а действительно ли нам нужно каждый раз проверять все 100 ссылок?” и сделать проверку рандомных ссылок при каждом прогоне. Ну и параллелизацию никто не отменял. Второй вариант тоже имеет право на жизнь конечно, но это не имитация действий пользователя и нет гарантий что такие тесты не пропустят багу. Например, чисто гипотетически - что если по клику на кнопке действия не будет? Получим зеленые тесты при наличии багов.
testomat.io управление авто тестами
