Selenium Flashcards

Question

Как обрабатывать браузерные сообщения (alerts)?

Answer 1

1. driver.switch_to.alert - этот метод позволяет переключиться на активное браузерное сообщение. 2. alert.text - с помощью этого метода можно получить текст сообщения. 3. alert.accept() - метод для подтверждения (нажатия на кнопку "OK") браузерного сообщения. 4. alert.dismiss() - метод для отклонения (нажатия на кнопку "Cancel") браузерного сообщения. 5. alert.send_keys(text) - метод для ввода текста в поле браузерного сообщения (только для prompt). В selene: `browser.driver().switch_to.alert.accept()`

Answer 2

Electron - фреймворк разработки кроссплатформенных приложений на основе web (html, css, js)

Answer 3

* Действия – функциональное действие над тестируемым веб-приложением в браузере. Например, заполнение полей, нажатие на кнопку и т.п. * Проверки – выполнение проверок на тестируемой странице. Например, проверка того, что определенное поле формы имеет указанное значение, или проверка заголовка окна. * Ожидания – организация того как, сколько и какого события будет дожидаться Selenium (ожидания загрузки страницы, ajax и т.д.).

Answer 4

`driver.findElement(By.*).isDisplayed()`

Answer 5

`driver.find_element(By.CSS_SELECTOR)` По ID: `driver.find_element_by_id("testing_form")` По классу CSS: `driver.find_element_by_class_name(" form-control ")` По XPath: `driver.find_element_by_xpath("//input[@name='email']")` Пот тэгу: `driver.find_element_by_tag_name("input")` По тексту ссылки: `driver.find_element_by_link_text('Start Free Testing')` selene - `browser.element()`

Answer 6

`driver.find_elements(By.CSS_SELECTOR)` selene - `browser.all()`

Answer 7

`driver.get(absolute_url)` `browser.open(absolute_or_relative_url)`

Answer 8

Декоратор pytest запускающий код до и после теста. Используется для: 1. Конфигурации браузера и драйвера 2. Сохранения логов, скриншотов, html 3. Закрытия браузера Все что не требует teardown (после yeild) - должно быть функцией\методом @pytest.fixture(autouse=True)

Answer 9

* Arrange * Act * Assert * Cleanup - Предусловия - Логин - Тест - Положить товар в корзину - Проверить наличие товара в корзине - Постусловия - Удаление тестовых данных - Скриншот браузера - Собрать логи браузера Постусловия выполняются независимо от успешности теста 1. Arrange 1. Act 1. Assert 1. Cleanup **Arrange** is where we prepare everything for our test. This means pretty much everything except for the “act”. It’s lining up the dominoes so that the act can do its thing in one, state-changing step. This can mean preparing objects, starting/killing services, entering records into a database, or even things like defining a URL to query, generating some credentials for a user that doesn’t exist yet, or just waiting for some process to finish. **Act** is the singular, state-changing action that kicks off the behavior we want to test. This behavior is what carries out the changing of the state of the system under test (SUT), and it’s the resulting changed state that we can look at to make a judgement about the behavior. This typically takes the form of a function/method call. **Assert** is where we look at that resulting state and check if it looks how we’d expect after the dust has settled. It’s where we gather evidence to say the behavior does or does not align with what we expect. The assert in our test is where we take that measurement/observation and apply our judgement to it. If something should be green, we’d say assert thing == "green". **Cleanup** is where the test picks up after itself, so other tests aren’t being accidentally influenced by it. At its core, the test is ultimately the act and assert steps, with the arrange step only providing the context. Behavior exists between act and assert. ## Footnote https://docs.pytest.org/en/stable/explanation/anatomy.html#test-anatomy

Answer 10

1. Лежит в папке с тестами 2. Запускается перед тестами 3. Содержит фикстуры 4. Используется для конфигурирования тестов

Answer 11

Через len() коллекции. Обязательно с вейтом ``` webelements = driver.find_elements(*to_locator(selector)) actual_value = len(webelements) if actual_value != value: raise AssertionError(f'Number of elements is not {value}\nActual value = {actual_value}') else: return webelements ```

Answer 12

> Кто нибудь использовал selene на большом проекте как основной инструмент для автоматизации? > > Он сильно уступает в удобстве selenide+ java? > Вопрос в такой форме не совсем коректный, нельзя сравнивать без контекста. Нельзя сравнивать какой то там астон мартин с тойотой. Ибо не знаем где надо ездить (траса, город, бездорожье, гоночный трек), какие задачи стоят перед автомобилем. Язык и фреймворк всегда надо подбирать под проект, и размер проекта это только один из критериев, при том не факт що самый важный. Поскольку контекст не озвучен, то могу просто поделиться следующими тезисами выведенными из моего опыта: - java как язык программирования именно для автоматизации (а не разработки) - самое ограниченное и неудобное из всего что только можно придумать. Если на проекте уже используется на бекенде хотя бы или на мобильном фронте котлин - то лучше взять его. - javascript = гибкий мощный и сложноватый для большинства - но лучший выбор если библиотека в связке с ним (плейврайт, сайпрес, и т.д.) - подходит под задачи автоматизации, поддержку нужных девайсов и так далее - потому что ближе всего к фронтенду и проще всего построить настоящий QA где девы берут участие в автоматизации тестирования - python, ruby - простые легкие во многом приятные языки, с# посложней но иногда еще мощней - всех их лучше выбирать, если js не подходит а бекенд написан на одном из этих языков (тогда такой и выбираем). Джаву выбираем по этой же и только по этой причине, а не потому что она популярней и в ней есть селенид. - если проект очень большой, состоит из множества компонентов, и разных команд за них ответственных, и за E2E тестирование отвечает отдельная команда, и всегда будет отвечать, то тогда пофиг на чем ей автоматизировать эти E2E тесты, и можно взять что-то максимально простое для такой команды, и в большинстве случаев - это именно python. Соответственно, python + selene "удобней чего бы то ни было в том числе и java + selenide" в случаях: - когда на бекенде питон, а js не подошел - когда надо писать E2E тесты силами отдельно выделенной команды, которая всегда такой "выделенной" и "отделенной от других" и останется

Answer 13

1. Точность (находит то, что нужно) 2. Уникальность (не находит то, что не нужно) 1. Хороший локатор должен быть устойчив к изменениям. 2. Хороший локатор должен быть понятным. 3. Хороший локатор должен существовать ___ * Хороший локатор должен быть устойчив к изменениям * Это, пожалуй, самое главное. Если после небольшого изменения тестируемого приложения все тесты приходится переделывать – это просто катастрофа. * Есть изменения, которые изначально заложены в приложение и могут определяться его настройками – локализация, расположение блоков на странице (например, включить/отключить рекламные блоки), “шкурки” (skins) и прочее. Локаторы нужно сразу проектировать так, чтобы они работали с разными вариантами настроек. * Есть изменения, которые случатся в будущем. Тут заранее подготовиться на 100% нельзя, но можно хотя бы постараться предугадать, с чем эти изменения будут связаны. Например, если сейчас пока приложение одноязычное, но есть планы выхода на новые рынки – вероятно, добавятся разные локализации, поэтому поиск элементов по тексту перестанет работать. Если дизайнер скажет, что кнопки нужно сделать не прямоугольными, а закруглёнными – поменяются стили и вёрстка кнопок, поэтому полагаться при поиске на конкретный стиль рискованно, лучше выбрать какие-то более стабильные признаки. Конечно, при массированном изменении тестируемого приложения противостоять изменениям в тестах не удастся, но это вполне ожидаемо. Но незначительные изменения не должны приводить к разрушению тестов. * Хороший локатор должен быть понятным. * Когда вы разрабатываете тесты, вы помните структуру страницы и можете легко представить, что найдётся по тому или иному локатору. Но через несколько месяцев память будет уже не так свежа, и глядя на запутанный локатор будет уже не так легко догадаться, что он ищет или хотя бы что он должен искать. * Конечно, можно добавить комментарии и пояснения. Но лучше всё таки стремиться к выразительности и понятности самих локаторов. Они должны быть простыми и осмысленными. Тогда читать и понимать старые тесты будет легко и приятно. * Хороший локатор должен быть. * Увы, иногда хороший локатор вообще не удаётся построить. Вёрстка страницы плывёт, свойства элементов постоянно меняются. Если пытаться написать простой локатор – он оказывается неустойчивым, уже на следующий он не работает. В попытках повысить устойчивость повышаем сложность локаторов – но уже не через месяц, а через неделю становится непонятно, что они ищут, потому что прочитать локатор длиной в две строчки вообще невозможно. * И тогда у тестировщика опускаются руки, он говорит “приложение невозможно автоматизировать” и уходит. * Это неправильно. Нужно бороться за свои права. * Идите к разработчикам и договаривайтесь о повышении тестопригодности приложения. Вообще-то они хорошие люди, просто они думали о своих проблемах и не думали о ваших. Если вы не расскажете им о том, что вам нужно от приложения – как они узнают? ## Footnote https://barancev.github.io/good-locators/

Answer 14

Иногда можно. Но в основном это говнокод и мы всегда в тестах должны знать - что мы получим в конце.

Answer 15

`browser.element().with_(click_by_js=True)`

Answer 16

`browser.element("#uploadPicture").set_value(...)`

Answer 17

Оптимальное: ``` import os import resources RES_DIR = os.path.abspath(os.path.join(os.path.dirname(resources.__file__), "images")) ``` Соедняем с файлом изображения: ``` browser.element("#uploadPicture").set_value(os.path.join(RES_DIR, img_name)) ``` Короткая альтернатива: ``` from pathlib import Path browser.element("#uploadPicture").set_value(str(Path(resources.__file).joinpath('resources/foto.jpg').absolute()) ``` Старое: ``` import os import tests CURRENT_FILE = os.path.abspath(tests.__file__) CURRENT_DIR = os.path.dirname(CURRENT_FILE) RES_DIR = os.path.join(CURRENT_DIR, os.path.pardir, "resources/images") ```

Answer 18

`os.path.abspath(os.path.join(RES_DIR, "tom-byrom.jpg"))`

Answer 19

`browser.element().should(have.text('...'))`

Answer 20

`browser.element().wait_until(have.title'TodoMvc')`

Answer 21

`browser.element().matching(have.title'title')`

Answer 22

В тестах ветвлений и циклов быть не может. Они должны быть максимально простыми - KISS Но если требуется (иногда всплывающее окно) - то надо спрятать ветвление в функцию (аналогично с циклом)

Answer 23

На вкладке sources в devtools ввести: `setTimeout(()=>{debugger},3000)` Или Chrome: * break on * subtree modificaton, * attribute modifications, * node removal

Answer 24

`pip install -r .\requirements.txt`

Answer 25

`actions = ActionChains(browser.driver)` `actions.key_down(Keys.COMMAND).send_keys('a').key_up(Keys.COMMAND).perform()` Аналог без ActionChains: `browser.element().type(Keys.COMMAND + 'a' + Keys.NULL)` * Но Keys.COMMAND - остаётся зажат * Т.е. может произойти ctrl+v и в таком духе если отправить текст с этой буквой * Keys.Null - отжимает все клавиши ``` browser.element('#new-todo').type( Keys.COMMAND + 'a' + Keys.NULL + 'this task will overwrite original' ) ```

Answer 26

``` @pytest.fixture() def driver(): pass @pytest.fixture() def config(): pass @pytest.fixture() def firefox(driver, config): return "" ```

Answer 27

1. Находим элемент и пробуем кликнуть 2. Если не получается, то находим родителя и смотрим похож ли он на контейнер полноценный (его оболочка) 3. Поднимаеся через xpath и кликаем по нему 4. Если есть читаемый атрибут, то кликаем сразу по нему 5. В более сложных случаях приходится искать: (./preceding-sibling::* или ./following-sibling::*) - элементы рядом 6. В еще более служных происходит подъем на родителя, потом к сиблингу, потом у сиблинга взять дочерний элемент обычно логика такая, находишь нужный элемент - пробуешь на нем кликнуть через browser.element(selector).click() Не получается? - Смотришь внутри какого элемента твой элемент находится - если родитель похож на прям вот осмысленного родителя контейнера этого элемента, типа "его оболочка" - пробуешь на нем кликнуть "поднявшись с помощью икспас на один уровень выше от найденного тобой элемента" - browser.element(selector).element('..').click() может быть у родителя есть тоже хороший атрибут читабельный, тогда можно будет упростить до browser.element(parent_selector).click() в более сложных случаях, придется искать не parent (.. – в икспас) а сиблингов (./preceding-sibling::* или ./following-sibling::*) , то есть тех элементов что рядышком... в еще более сложных, может придется подняться на перента, потом от него к сиблингу перейти, и потом у сиблинга взять ребенка 🙂 это как раз и есть те случаи когда икспас решает

Answer 28

`browser.element().set_value('...')` - очищает значение и устанавливает значение. Не всегда срабатывает. * Альтернатива - просто type * Альтернатива - ctrl+A + 'text'

Answer 29

**UI auto - critical path** 1. Уточняем основные цепочки действий, которые пользователи выполняют каждый день. 2. Узнаём какие из них имеют самый большой приоритет. 3. Автоматизируем happy path 4. На каждый happy path - обычно есть несколько причин, почему он ломается 5. Только один из них покрывается тестом селениума 6. Остальные негативные варианты покрываются API тестами * Порядок рендеринга и различные детали фронта - лучше всего покрываются frontend unit тестами 8. Это должны делать разработчики 9. Если они это не делают - то им надо помогать 10. Выучить немного фронтенд и писать фронтовые юнит тесты - меньше боли, чем задалбываться с тысячами селениумовских тестов, которые даже с парралелизацией ждать пол ночи. Потом они падают и мы ищем и разбираемся в причинах

Answer 30

``` class User: name: str age: int status: str items: list[str] def __init__(self, name, age, status, items): self.name = name self.age = age self.status = status self.items = items def __eq__(self, other): # позволяет сравнивать объекты return (self.name == other.name and self.age == other.age and self.status == other.status and self.items == other.items) ``` Dataclass позволяет не прописывать __init__ и __eq__. Он это делает за нас: ``` from dataclasses import dataclass @dataclass # декоратор class User: name: str age: int status: str items: list[str] ```

Answer 31

``` browser.element('.modal-content').element('.table').all('tr').all('td').should( ... ) ```

Answer 32

browser.element('selector**:not**(selector)').click ``` browser.element(f'react-datepicker_day--0{01}:not(.react-datepicker_day--outside-month)').click() ```

Answer 33

Зависит от контекста. В большинстве случаев должно храниться в тесте как явный pre-condition Тест должен быть явным и простым. То что происходит - должно быть видно - для упрощения поддержки

Answer 34

`browser.config.wait_for_no_overlap_found_by_js = True`

Answer 35

1. Либо мы это делаем не по тому элементу, по которому нужно 2. Возможно есть скрытые элементы или клоны 3. В этом случае можно сделать `browser.all(...).element_by(be.visible).click()` 2. Элемент не готов к действию

Answer 36

`with allure.step('step_description')` - Используется в современном мире. Код почти не переиспользуется. Т.к. современные тесты это гибриды UI+API. Например - создается максимально полный issue. Подверждается его создание через API. Затем все остальные issue создаются через API. `Декоратор @allure.step` - Раньше при сложных UI (самописные, без фреймворков) использовался этот вариант. Очень удобно, когда надо переиспользовать код. В сорвеменном мире используется часто в банках.

Answer 37

Комбинация UI + API 1. Создаётся самый жирный E2E тест учитывающий все параметры 2. А затем все остальные проверки делаются через API

Answer 38

1. Зависит от цели 2. Если бизнес шаг - отправить форму и зарегистрировать пользователя, то происходит разделение на 3. Открыть страницу 4. Заполнить страницу 5. Отправить 6. Если бизнес шаги это - заполнить имя, заполнить фамилию, телефон и т.д. - то они все оформляются как отдельные шаги

Answer 39

1. Выносим в функцию 2. Функцию переносим в корневой пакет (`demoqa_ui_tests`) в папку с подходящим именем, например resources 3. Импортируем сам модуль и обращаемся к функции через имя модуля `resources.path(img_name)`

Answer 40

1. Используйте то, что не подвержено изменениям 1. Меняется верстка - не ссылаемся на нее 2. Меняются адреса серверов - не используем их 2. Семантические признаки 1. Использовать семантические (смысловые) признаки, а не синтаксические 3. Проверяйте уникальность 4. Использовать якоря (2-3 зацепки это обычно предел): 1. `.product a` 2. `#box-most-popular .product a` 3. `#site-menu-li` 5. Используйте комбинации (использование нескольких частей создающих уникальность) 1. `#box-most-popular .product a` (уникальный элемент и внутри него менее уникальный 1. `#footer a[href*=privacy-policy)` 2. `select[name=zone_code]` 3. `li[id^=select2-country_code][id$=US]` 4. `a[href*=user_edit]:not([href$='user_id=1'])` 6. Избегайте избыточности 1. Должно быть минимально необходимое количество признаков 7. “Где-то в” или “прямо в” 1. Элемент находится где-то внутри или прямо внутри блока 1. Где-то внутри: 1. `#box-most-popular .product a` 2. `site-menu li` 1. Прямо внутри: 1. `#site-menu > ul > li` 8. Не ищите по тексту 1. Можно использовать только в самом крайнем случае (из-за интернациональности) 9. Не используйте номера 1. Порядковые номера это всегда плохо 2. Нужно использовать семантические признаки 10. Общайтесь с разработчиками

Selenium Flashcards

(64 cards)