Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как правильно проверять повторяющийся функционал на разных страницах сайта?

design-patterns
architecture
webdriver
Теги: #<Tag:0x00007f7b5fcbcf00> #<Tag:0x00007f7b5fcbcdc0> #<Tag:0x00007f7b5fcbcb90>

(Ordyntcev Dmitry) #1

Если имеется один и тот же функционал (к примеру “Поиск”) на различных экранах сайта, но на выходе получаем результат с той страницы, с которой был вызван поиск (то есть, если я воспользовался поиском на экране 1, я получаю на выходе результаты поиска с экрана 1, если я воспользовался поиском на экране 2, я получаю на выходе результаты поиска с экрана 2)…Вопрос, необходимо проверять функционал поиска как на экране 1, так и на экране 2, 3, N…??? Либо достаточно будет проверить только на экране 1 (так как функционал поиска будет относится к эквивалентным классам)


(Stanislav Lomakov) #2

Думаю можно проверить функцию поиска на одной странице + проверки что после поиска с разных страниц (экранов) результаты показаны на той, с которой был поиск.


(Ordyntcev Dmitry) #3

А как быть если страниц с поиском будет к примеру 100?? Что на всех 100 страницах проверять поиск??


(Михаил Братухин) #4

Почему нет? Пока вы не подтвердите экспериментальным путем (с помощью теста), что он работает - вы не сможете утверждать обратного (т.е. утверждать-то сможете, но это будет бездоказательно). Более того вы не будете застрахованы от ситуации, что в будущем где-то на одной из страниц какой-то разработчик сломает этот код.

Создание грамотной тест-стратегии это самое важное в тестировани, а заавтоматизировать это уже намного проще.

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


(Ordyntcev Dmitry) #5

Давай рассматривать с точки зрения чёрного ящика. Ну по сути если поиск одинаков на всех страницах ( код одинаковый для этого функционала не всех страницах, меняютс только входные данные), то разве нельзя проверять один вариант этого функционала…? Проверяя калькулятор ведь нет нужды прибегать к сложению всех цифр которые возможны, если проверяем сложение… это же метод эквивалентых классов будет в случае со сложением


(Ильдар Бекмансуров) #6

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


(Nikita) #7

В общем разделяйте задачи.

  1. Проверка работы поиска (или любого общего блока)

    • К примеру поиск лучше тестировать на более низких уровнях приложения.
    • На уровне UI стоит лишь проверить несколько базовых сценариев по корректному отображению результата и когда ничего не нашли.
  2. Проверка того, что результаты поиска остались на той же странице. Тут надо смотреть на реализацию, если у вас страница не перезагружается, а результат выводится лишь выполнением js, то у вас проверки будут сводиться к корректному отображению результата в контексте текущей страницы.

Автоматизировать 2-ой пункт, я бы не стал.


(Дмитрий Мирошник) #8

Если проверяем сложение - разумеется. А если проверяем, что все числовые кнопки на калькуляторе активны?
Нет задачи - проверить сложение. Есть задача - протестировать калькулятор. И в контексте 2-й задачи проверить все его кнопки - это нормально.
Аналогично в Вашем случае: если при запуске поиска вызывается некий одинаковый js класс - Вам необходимо проверить 2 вещи:
1). Что js класс действительно работает - достаточно проверить на 1 странице;
2). Что нажатие кнопки поиска действительно вызывает именно этот класс - необходимо проверить на каждой странице.
Именно действие 2 является обоснованием утверждать, что функциональность поиска на разных страницах есть 1 класс эквивалентности. До тер пор, пока Вы это не проверили - таких оснований у Вас нет.