Junior QA [147] Flashcards
Что такое тестирование?
Теория тестирования
Проверка продукта на соответствие требованиям.
Тестирование - процесс в рамках жизненного цикла разработки программного обеспечения, который оценивает качество компонента или системы, а также связанных с ними рабочих продуктов. [ISTQB Glossary]
Тестирование программного обеспечения — процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта. [Святослав Куликов]
Тестирование ПО — проверка соответствия между реальным и ожидаемым поведением программы [Что-то из интернета]
Контроль качества (QC) - набор действий, предназначенных для оценивания качества компонента или системы. [ISTQB Glossary]
Обеспечение качества (QA) - активности, направленные на обеспечение уверенности в том, что требования к качеству будут выполнены [ISTQB Glossary]
Давайте разберемся на примере создания мобильного приложения, потому что определения не всегда отражают суть:
- В рамках тестирования мы выполним проверки и задокументируем дефекты, убедимся, что продукт соответствует требованиям.
- В рамках контроля качества мы проанализируем полученные данные и убедимся, что соблюдены все требования, предъявляемые к качеству как продукта, так и самого процесса. Мы должны убедиться, что уровень качества нашего продукта высокий и он готов к релизу.
- В рамках обеспечения качества мы формируем процесс QA для соответствия стандартам качества на всех этапах SDLC, еще до этапа создания нашего продукта, который будет минимизировать количество дефектов и предупреждать их.
Основные отличия процессов:
- Контроль качества и тестирование (как его часть) направлены на продукт, а обеспечение качества на процесс.
- Тестирование и контроль качества являются контролирующими мерами, а обеспечение качества - превентивными, или предупреждающими.
https://stepik.org/lesson/1036731/step/3?auth=login&unit=1045216
https://easyoffer.ru/question/7800
Зачем тестировать ПО?
Теория тестирования
Чтобы убедиться, что продукт работает как задумано, а так же найти возможные недостатки для их последующего устранения
Какие этапы тестирования?
Теория тестирования
1) Инициация
2) Выявление требований прямых и косвенных
3) Создание тест-кейсов
4) Отбор тест-кейсов
5) Проведение проверок
6) Фиксация результатов
7) Анализ результатов
8) Передача результатов о соответствии продукта требованиям
https://easyoffer.ru/question/8134
Какие типы тестирования вы можете назвать?
Теория тестирования
- По доступности кода:
- Black box
- Grey box
- White box
- По исполнению кода
- Статическое
- Динамическое
- По степени формализации
- На основе тест-кейсов
- Исследовательское тестирование
- Свободное тестирование (ad hoc)
- По уровням тестирования
- Компонентное
- Интеграционное
- Системное
- По позитивности
- Позитивные
- Негативные
- По степени автоматизации
- Ручное
- Автоматизированное
- Полуавтоматизированное
- Связанное с изменениями:
- Регрессионное (Regression testing)
- Тест работоспособности (Sanity testing)
- Дымовое (Smoke testing)
- По исполнителям
- Альфа-тестирование
- Бета-тестирование
- По целям и задачам
- Инсталляционное
- Usability (удобства использования)
- Доступности (accessibility testing, A11Y)
- Безопасности
- Интернационализации (internationalization testing, i18n testing, globalization testing, localizability testing)
- Локализации (localization testing, l10n)
- Совместимости (compatibility testing, interoperability testing)
- Надёжности (reliability testing)
- Восстанавливаемости (recoverability testing)
- Отказоустойчивости (failover testing)
- Производительности (performance testing)
- Нагрузочное тестирование (load testing, capacity testing)
- Тестирование масштабируемости (scalability testing)
- Объёмное тестирование (volume testing)
- Стрессовое тестирование (stress testing)
- Конкурентное тестирование (concurrency testing)
https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/osnovnye-vidy-testirovaniya-po
Какие уровни тестирования знаете?
Теория тестирования
- Модульное
- Интеграционное
- Системное
- Приёмочное
Модульное тестирование (Unit Testing)
Это процесс проверки отдельных компонентов программного обеспечения, таких как функции, методы или классы. Цель этого уровня тестирования — убедиться, что каждый отдельный компонент работает корректно в изоляции от остальной части системы.
Пример: Проверка функции сложения в программе калькулятора.
Интеграционное тестирование (Integration Testing)
На нем проверяется взаимодействие между различными модулями или компонентами системы. Цель интеграционного тестирования — обнаружить дефекты в взаимодействии и передаче данных между различными частями программы.
Пример: Проверка того, как модуль калькулятора обрабатывает данные, полученные от пользовательского интерфейса.
Системное тестирование (System Testing)
Проверяется вся система в целом. Системное тестирование направлено на выявление дефектов в комплексе, включая требования к функциональности, надёжности, производительности и безопасности.
Пример: Тестирование веб-приложения в различных браузерах и на разных устройствах.
Приемочное тестирование (Acceptance Testing)
Это финальный этап тестирования, на котором проверяется, соответствует ли программа ожиданиям и требованиям конечных пользователей.
Пример: Бета-тестирование программы с участием реальных пользователей.
https://easyoffer.ru/question/7802
Какие техники тест-дизайна знаете?
Теория тестирования
Чёрный ящик (Black-box techniques):
- Эквивалентное разбиение (Equivalence Partitioning): Разделение входных данных на группы (классы эквивалентности), которые можно обрабатывать одинаково. Достаточно тестировать по одному представителю от каждой группы.
- Граничные значения (Boundary Value Analysis): Тестирование на значениях на границах или около границ классов эквивалентности.
- Комбинаторные
- Попарное тестирование (Pairwise testing) - тестирование всех комбинаций пар параметр-значение
- Таблицы решений (Decision Table Testing): тестировщик определяет условия (входы) и результирующие действия системы (выходы). Пары условий и действий образуют строки таблицы, при этом условия указываются сверху, а действия – снизу.
- Тестирование переходов состояний (State Transition Testing): Проверка переходов между различными состояниями системы на основе событий или условий.
- Use Case Testing (Случаи использования): Создание тестов на основе сценариев использования программы пользователями.
Техники основанные на опыте (Experience-based techniques):
- Предугадывание ошибки (Error Guessing): Основано на опыте и интуиции тестировщика, который предполагает, где могут возникнуть ошибки.
- Тестирование на основе чек-листов (Checklist-based Testing): Использование чек-листов, основанных на предыдущем опыте, для проверки определённых аспектов программы.
- Исследовательское тестирование (Exploratory testing)
- Произвольное тестирование (Ad-hoc testing)
- Attack Testing: Software attacks (sometimes called fault attacks) are focused on trying to induce a specific type of failure. When performing attack testing, you should consider all areas of the software and its interaction with its environment as opportunities for failures. Attacks target the user interface, the operating system, interfacing systems, database interfaces, APIs, and any file system interaction. Anytime data is being exchanged, it is potentially vulnerable to a failure and consequently is an excellent target for an attack.
Белый ящик (White-box techniques):
- Тестирование путей (Path Testing): Анализ выполнимых путей через код для проверки всех возможных путей выполнения.
- Тестирование на основе управляющих структур (Control Structure Testing): Фокусируется на логических операциях и условиях в коде, проверяя все условные операторы.
https://vladislaveremeev.gitbook.io/qa_bible/test-dizain
https://easyoffer.ru/question/7819
Что такое техника анализа классов эквивалентности?
Теория тестирования
Техника при которой разделяются все возможные входные данные на группы или классы таким образом, чтобы все значения внутри одного класса считались эквивалентными.
Принципы:
- Определение эквивалентных классов: Входные данные или условия тестирования разделяют на классы, внутри которых система должна вести себя одинаково. Эти классы могут быть как допустимыми (валидными), так и недопустимыми (невалидными).
- Выбор представителей: Для каждого эквивалентного класса выбирается хотя бы один представитель (тестовый случай), который будет использован в тестировании.
- Тестирование: Проводится тестирование на основе выбранных представителей каждого класса. Результаты тестирования для представителя класса экстраполируются на весь класс.
https://easyoffer.ru/question/7825
Что такое техника анализа граничных значений?
В чем ценность этой техники?
Теория тестирования
Суть: Проверяются все значения на границах эквивалентных классов
Метод анализа граничных значений является продолжением метода эквивалентного разбиения, но может быть применим, только если классы состоят из упорядоченных числовых значений. Максимальное и минимальное значение класса являются его границами [Beizer 1990]. Некорректное поведение более вероятно на границах класса, чем внутри класса. [ISTQB CTFL Syllabus 2018]
Почему она важна:
- Высокая эффективность: большое количество ошибок с минимальным количеством тестов.
- Экономия времени и ресурсов: Сосредоточение усилий на наиболее вероятных местах возникновения ошибок - сокращает время на тестирование и оптимизирует использование ресурсов.
- Улучшение качества продукта: Гарантия корректной обратоки данных на границах значений
https://easyoffer.ru/question/7835
https://stepik.org/lesson/1036738/step/6?auth=login&unit=1045223
Что такое Regression и Confirmation тестирования, какая между ними разница?
Теория тестирования
Краткая суть: проверка уже протестированного функционала для того, чтобы убедиться, что при внесении изменений ничего не поломалось
Регрессионное тестирование (regression testing): Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении. (ISTQB)
Confirmation тестирование (retest) - ретест не пройденных ранее сценариев
https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing
https://easyoffer.ru/question/7801
Как часто следует проводить регрессионное тестирование продукта?
Теория тестирования
При каждом изменении в системе.
Какие виды интеграционного тестирования?
Теория тестирования
- Big bang - все компоненты приложения тестируются сразу после того, как они были разработаны, без поэтапного интегрирования. Этот подход обычно используется в небольших проектах.
-
Инкрементное тестирование - разработка приложения разбивается на отдельные этапы, после завершения каждого из которых происходит интеграция уже готовых компонентов. Этот подход позволяет обнаруживать проблемы на ранних этапах и быстрее реагировать на изменения в требованиях.
- Нисходящий подход
- Восходящий подход
- Гибридный подход
https://easyoffer.ru/question/8982
Что такое Configuration Testing?
Теория тестирования
Краткая суть:
Тестирование различных конфигураций системы - железа, драйверов, операционных систем
Конфигурационное тестирование (Configuration testing) - специальный вид тестирования, направленный на проверку работы ПО при различных аппаратных и программных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д.).
Configuration = performance + compatibility:
- performance аспект: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы;
- compatibility аспект: проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм;
Существует два главных уровня конфигурационного тестирования: серверный и клиентский.
Серверный уровень тестирования конфигурации
Если говорить о первом уровне, то смысл его состоит в проверке взаимодействия между программным обеспечением и внешним окружением, в которое планируется его установка.
Клиентский уровень тестирования конфигурации
На втором уровне тестирование программного обеспечения производится с позиции интересов его непосредственного пользователя, то есть будут исследованы удобство пользования и функциональность программного продукта.
В тех случаях, когда число системных требований к работе программного обеспечения велико, рекомендуем автоматизировать весь процесс тестирования с целью экономии и времени, и ресурсов.
https://software-testing.org/testing/chto-takoe-konfiguracionnoe-testirovanie-configuration-testing.html
Что такое Exploratory Testing?
Теория тестирования
Краткая суть: неформальный метод, где проектирование тестов и тестирование происходит в реальном времени. Полученная информация в ходе тестирования используется для проектирования новых и улучшенных тестов
Исследовательское тестирование (Exploratory Testing) — это подход к тестированию ПО, который совмещает процесс обучения, проектирования тестов и само тестирование в реальном времени. В отличие от традиционного , где тест-кейсы создаются заранее и затем выполняются, исследовательское тестирование предполагает одновременное проектирование и выполнение тестов. Это динамичный процесс, в котором тестировщик использует свой опыт, интуицию и творческий подход для идентификации и проверки потенциальных проблем в программном продукте.
Основные принципы исследовательского тестирования:
- Самоуправляемость: Тестировщики самостоятельно определяют, какие аспекты ПО тестировать, в какой последовательности и как глубоко.
- Личный опыт и интуиция: Важным инструментом являются знания и предчувствия тестировщика, позволяющие ему эффективно навигировать по процессу тестирования.
- Обучение в процессе тестирования: Тестировщик постоянно учится в процессе работы ПО, а затем применяет новые знания для расширения и углубления тестирования.
- Адаптивность: Методика предполагает гибкость и способность быстро адаптироваться к новой информации о программном продукте и изменениям в тестовой среде.
Преимущества исследовательского тестирования:
- Гибкость: Возможность быстро адаптироваться к изменениям в программном обеспечении и требованиях.
- Выявление сложных дефектов: Благодаря творческому подходу и опыту тестировщиков могут быть обнаружены ошибки, которые сложно выявить с помощью традиционных методов тестирования.
- Эффективность: Может быть очень эффективным в условиях ограниченного времени, так как позволяет сосредоточиться на наиболее важных аспектах программного продукта.
- Повышение качества: Способствует более глубокому пониманию продукта и, как следствие, к повышению его качества.
Когда применять исследовательское тестирование:
- В условиях неопределённости или когда требования к продукту не полностью известны или часто меняются.
- Для дополнения других форм тестирования, например, автоматизированных тестов или тестов, основанных на требованиях.
- В рамках комплексного тестирования пользовательского интерфейса, функциональности или производительности.
Исследовательское тестирование — это гибкий и динамичный подход к тестированию ПО, который позволяет использовать свой опыт и интуицию для обнаружения ошибок. Это как исследование неизвестной территории с картой, которую вы рисуете по ходу движения, адаптируясь к новым обстоятельствам и применяя знания, полученные на месте
https://easyoffer.ru/question/7823
https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/issledovatelskoe-testirovanie-exploratory-testing
Какие существуют стандарты UI?
Теория тестирования
- Material Design
- Apple Human Interface Guidelines
- Microsoft Design Language
- Bootstrap
- Materialize
Существует множество UI-стандартов, некоторые из которых являются общепризнанными и широко используются в индустрии разработки ПО. Ниже перечислены некоторые из них:
1) Material Design - стандарт дизайна, разработанный компанией Google. Включает в себя рекомендации по использованию цветовой палитры, шрифтов, иконок и анимаций.
2) Apple Human Interface Guidelines - руководство от Apple, в котором описываются стандарты дизайна для приложений под iOS, macOS и watchOS.
3) Microsoft Design Language - стандарт дизайна, используемый в операционных системах и приложениях от Microsoft. Он включает в себя рекомендации по использованию типографики, цвета, анимации и иконок.
4) Bootstrap - фреймворк, который содержит рекомендации по использованию готовых компонентов интерфейса, таких как кнопки, формы, таблицы и другие элементы.
5 ) Materialize - фреймворк, основанный на Material Design, который содержит готовые компоненты интерфейса, такие как кнопки, навигационные панели, формы и др.
Кроме этого, многие компании имеют свои собственные UI-стандарты и руководства для разработки интерфейсов своих продуктов.
https://easyoffer.ru/question/8980
Что такое Black/Grey/White Box Testing?
Теория тестирования
Краткая суть:
* Черный ящик: Нет доступа ко внутренней структуре приложения и коду. Тестирование проводится с точки зрения конечного пользователя.
* Белый ящик: Основывается на внутренней структуре системы или ее реализации (код, архитектура, принципы работы и\или потоки данных внутри системы)
* Серый ящик: доступ к базам данных, архитектурным схемам и документации API.
Белый ящик (White Box Testing)
Также известен как структурное тестирование. В этом подходе тестировщики имеют полное представление о внутренней структуре и коде программы. Тесты разрабатываются с учётом алгоритмов, ветвлений кода, путей выполнения и внутренних интерфейсов. Цель — проверить внутренние операции продукта и убедиться, что все внутренние компоненты функционируют правильно.
Чёрный ящик (Black Box Testing)
В этом методе тестировщики не знают о внутреннем устройстве тестируемой системы. Тесты разрабатываются на основе требований и спецификаций функциональности, без знания о том, как система реализует эти функции. Цель — проверить, соответствует ли система внешним требованиям и ожиданиям пользователя. Тестируется функциональность и поведение системы.
Серый ящик (Grey Box Testing)
Этот метод является комбинацией подходов белого и чёрного ящиков. Тестировщики имеют частичное знание о внутреннем устройстве системы, что позволяет им создавать более целенаправленные тестовые сценарии, основываясь как на внутренней структуре, так и на функциональных требованиях. Это может включать доступ к базам данных, архитектурным схемам и документации API.
https://easyoffer.ru/question/7858
Что такое Performance Testing?
Теория тестирования
Краткая суть: проверка поведения системы при рабочей нагрузке: скорость, время отклика, стабильность, надежность, мастштабируемость и использование ресурсов ПО при определенной рабочей нагрузке.
Тестирование производительности - это нефункциональный вид тестирования программного обеспечения, используемый для проверки скорости, времени отклика, стабильности, надежности, масштабируемости и использования ресурсов программного приложения при определенной рабочей нагрузке, обычно регрессионным образом, когда в приложение ежедневно или еженедельно вносятся небольшие изменения.
Основная цель тестирования производительности - выявить и устранить узкие места производительности в программном приложении. Это подмножество performance engineering, также известное как «Perf Testing». Само по себе оно не призвано находить дефекты, но оно помогает в обнаружении узких мест в системе.
Обычно продолжительность теста производительности составляет 1 час (устойчивое состояние) на средней / ожидаемой нагрузке; это может варьироваться в зависимости от вашего SLA / требований.
Примечание 1: все подвиды тестирования производительности отличаются, грубо говоря, только параметрами (тип возрастания нагрузки, ее количество, длительность и т.п.) и собираемыми метриками (без которых это тестирование бессмысленно). Точкой отсчета для всех подвидов принято брать результаты Capacity testing.
Примечание 2: несмотря на необходимость понимания многих математических и статистических концепций, многие тестировщики и менеджеры либо не имеют достаточных знаний в области математики и статистики, либо не пользуются ими. Это приводит к значительным искажениям и неверной интерпретации результатов тестирования производительности (те же перцентили).
Что такое Smoke и Sanity тестирование и какая между ними разница?
Теория тестирования
Smoke - проверка стабильности билда, что он вообще работает
Sanity - более глубокая проверка важного функционала
Что такое Traceability Matrix?
Теория тестирования
Краткая суть:
Таблица для отслеживания взаимосвязей между требованиями проекта и выполненной по ним работе. (Учёт реализации требований)
Матрица трассируемости (Traceability Matrix) — это документ или таблица, используемая в управлении проектами и разработке программного обеспечения для отслеживания и демонстрации взаимосвязей между требованиями проекта и работой, выполненной для их удовлетворения. Этот инструмент позволяет убедиться, что все требования к проекту или системе были учтены и реализованы на различных этапах разработки, включая дизайн, разработку и тестирование.
Основные цели:
- Подтверждение полноты: Гарантировать, что каждое требование отражено в конечном продукте и что все элементы продукта обоснованы требованиями.
- Упрощение валидации и верификации: Помочь в проверке соответствия продукта требованиям, обеспечивая легкую отслеживаемость от требований к тестовым случаям и обратно.
- Управление изменениями: Облегчить оценку влияния изменений требований на проект, позволяя быстро определить, какие компоненты системы будут затронуты.
- Улучшение коммуникации: Служить средством общения между всеми заинтересованными сторонами проекта, предоставляя прозрачный вид на статус требований и их реализацию.
Типы:
- Вертикальная трассируемость: Отслеживает взаимосвязь между требованиями на разных уровнях (например, от бизнес-требований к пользовательским историям и далее к функциональным и нефункциональным требованиям).
- Горизонтальная трассируемость: Связывает требования с соответствующими артефактами разработки, такими как техническая документация, исходный код, тестовые сценарии и результаты тестирования.
Структура:
Матрица может быть структурирована различными способами в зависимости от потребностей проекта, но обычно она содержит:
- ID требований: Уникальные идентификаторы для каждого требования.
- Описание требований: Краткое описание требований для удобства отслеживания.
- Ссылки на артефакты: Ссылки на дизайн, исходный код, тестовые случаи и другие документы, связанные с каждым требованием.
Статус: Текущее состояние реализации требования (например, “Не начато”, “В процессе”, “Завершено”).
Матрица трассируемости является мощным инструментом управления качеством и рисками в проектах разработки, позволяя эффективно контролировать выполнение требований и обеспечивать высокое качество конечного продукта.
https://easyoffer.ru/question/7931
Что такое Sanity Testing?
Теория тестирования
Sanity - подвид регрессионного тестирования, используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений.
Тест работоспособности (sanity test): См. тест “на дым”. (ISTQB)
Другие источники:
Sanity testing также является подмножеством регрессионного тестирования и выполняется до или вместо полной регрессии, но после smoke. Эти два подвида похожи, но в целом Sanity используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений.
Примечание. Санитарным это тестирование в русскоязычной среде назвалось по совершенно непонятным причинам, но гуглится только так. На самом же деле дословно переводится как тестирование на вменяемость / разумность / работоспособность / согласованность или по версии ISTQB “Тест работоспособности”.
Sanity тестирование (от англ. “sanity” — “здравомыслие”) — это вид тестирования, который проводится для подтверждения того, что после внесения небольших изменений или исправлений в программный продукт основные функции по-прежнему работают корректно. Этот тип тестирования обычно выполняется в конце тестового цикла и перед выпуском продукта для убеждения в том, что внесенные изменения не привели к возникновению новых критических ошибок в уже проверенных и работающих частях программы.
Данное тестирование часто путают с Smoke тестированием, но между ними есть различия. Smoke тестирование выполняется для проверки стабильности и работоспособности всего программного продукта или его ключевых компонентов и обычно проводится в начале тестового цикла. В то время как Sanity фокусируется на конкретных функциях или изменениях, которые были внесены в программный продукт, и проводится для подтверждения того, что эти последние изменения не нарушили основную функциональность.
Пример:
Допустим, команда разработки вносит изменения в модуль регистрации пользователей в веб-приложении. После внесения изменений QA инженер проводит Sanity тестирование этого модуля, чтобы убедиться, что регистрация по-прежнему работает корректно: пользователь может зарегистрироваться, получить подтверждение регистрации и войти в систему используя новые учетные данные.
Цели:
- Быстрая проверка: Убедиться, что после небольших изменений или исправлений в программном продукте не возникло критических проблем.
- Сосредоточение на изменениях: Проверка только тех аспектов программного продукта, которые подверглись изменениям, без проведения глубокого и всеобъемлющего тестирования.
- Экономия времени и ресурсов: Позволяет быстро оценить влияние внесенных изменений, не тратя время на полный цикл тестирования.
- Такое тестирование является важной частью процесса обеспечения качества программного продукта, так как оно позволяет быстро и эффективно подтвердить, что внесенные изменения не повлияли негативно на уже проверенную и работающую функциональность. Этот тип тестирования особенно полезен в условиях ограниченного времени и ресурсов, когда необходимо сделать быструю проверку перед выпуском продукта или передачей его на дальнейшие этапы тестирования.
Sanity тестирование — это быстрая проверка того, что после внесения небольших изменений в программное обеспечение основные функции продолжают работать корректно. Этот тип тестирования помогает подтвердить здравомыслие программного продукта перед его дальнейшим тестированием или выпуском.
https://easyoffer.ru/question/7810
https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing
Что такое End-to-End тест?
Теория тестирования
Сквозное тестирование - Сквозное тестирование (End-to-end, E2E, Chain testing) — используется для проверки ПО от начала до конца, а также его интеграцию с внешними интерфейсами.
Цель сквозного тестирования состоит в проверке всего программного обеспечения на предмет зависимостей, целостности данных и связи с другими системами, интерфейсами и базами данных для проверки успешного выполнения полного производственного сценария.
Пример: На примере интернет магазина, это одна объемная проверка, которая включает в себя все шаги пользователя, начиная от регистрации в системе и заканчивая покупкой товара в магазине.
https://habr.com/ru/companies/otus/articles/681066/
Что такое тестирование безопасности?
Теория тестирования
Суть: выявляет уязвимости, угрозы и риски.
Целью тестов безопасности является выявление всех возможных лазеек и слабых мест в ПО, которые могут привести к потере информации, доходов, репутации компании, сотрудников или клиентов. Общая стратегия безопасности основывается на трех основных принципах:
* Конфиденциальность - сокрытие определенных ресурсов или информации;
* Целостность - ресурс может быть изменен только в соответствии с полномочиями пользователя;
* Доступность - ресурсы должны быть доступны только авторизованному пользователю, внутреннему объекту или устройству;
Тестирование безопасности обычно выполняет отдельный специалист по безопасности. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:
- попытки узнать пароль с помощью внешних средств;
- атака системы с помощью специальных утилит, анализирующих защиты;
- перегрузка системы (в надежде, что она откажется обслуживать других клиентов);
- целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;
- просмотр несекретных данных в надежде найти ключ для входа в систему;
При неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему. Задача проектировщика системы - сделать цену проникновения более высокой, чем цена получаемой в результате информации.
https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/testirovanie-bezopasnosti-security-and-access-control-testing
Что такое тестирование на основе рисков?
Теория тестирования
Краткая суть приоритеты в тестировании устанавливаются на основе оценки рисков. Акцент на частях системы с наибольшим риском возникновения серьёзных проблем, влияющих на работоспособность продукта и удовлетворённость пользователя.
Подход позволяет оптимизировать процесс тестирования, обеспечивая наибольшую эффективность при ограниченных ресурсах.
Тестирование рисков (Risk-Based Testing) — это подход к тестированию ПО, при котором приоритеты в тестировании устанавливаются на основе оценки рисков. Это означает, что внимание и ресурсы сосредотачиваются прежде всего на тех частях системы, которые несут наибольший риск возникновения серьёзных проблем или ошибок, влияющих на работоспособность продукта и удовлетворённость пользователя. Подход позволяет оптимизировать процесс тестирования, обеспечивая наибольшую эффективность при ограниченных ресурсах.
Основные этапы:
- Идентификация рисков: Определение потенциальных угроз для проекта, которые могут включать технические аспекты (например, сложность реализации определённой функции), а также факторы, связанные с бизнес-целями (например, важность функции для клиента).
- Анализ и оценка рисков: Оценка вероятности возникновения каждого риска и степени его воздействия на проект. Это помогает определить приоритеты для тестирования.
- Планирование тестирования: Разработка стратегии и плана тестирования, в котором тест-кейсы распределяются с учётом установленных приоритетов риска.
- Выполнение тестирования: Тестирование программного обеспечения с акцентом на области, представляющие наибольший риск.
- Мониторинг и контроль: Отслеживание процесса тестирования и внесение корректировок в план в соответствии с изменениями в проекте и повторной оценкой рисков.
- Анализ результатов: Оценка результатов тестирования и определение, как риски были снижены до приемлемого уровня.
Преимущества:
- Фокус на критически важных аспектах: Тестирование сосредотачивается на наиболее важных с точки зрения бизнеса и технической сложности функциях.
- Эффективное использование ресурсов: Ресурсы для тестирования распределяются таким образом, чтобы максимизировать покрытие наиболее рискованных областей при ограниченных времени и бюджете.
- Улучшение качества продукта: Снижение рисков, связанных с программным обеспечением, ведёт к повышению общего качества продукта.
- Повышение удовлетворённости клиентов: Защита от потенциальных проблем, которые могли бы наиболее негативно сказаться на пользовательском опыте.
Тестирование рисков требует тщательной подготовки и глубокого понимания как бизнес-целей проекта, так и технических аспектов программного обеспечения. Это позволяет оптимизировать процесс тестирования и обеспечивает создание качественного продукта, соответствующего ожиданиям клиентов.
https://easyoffer.ru/question/7932
Что такое динамическое тестирование?
Теория тестирования
Краткая суть: через выполнение кода (через запуск программы.
Динамическое тестирование — это процесс проверки ПО путём выполнения его кода с целью обнаружения ошибок. В отличие от статического тестирования, которое анализирует код без его выполнения, динамическое требует запуска программы в реальной или эмулированной среде выполнения. Этот подход позволяет проверить поведение программы в различных ситуациях, включая обработку данных, взаимодействие с другими системами, реакцию на ввод пользователя и выполнение предназначенных функций.
Основные аспекты динамического тестирования:
- Виды тестирования: Включают функциональное (проверка соответствия функциональным требованиям), нефункциональное (проверка производительности, безопасности, удобства использования и т. д.), а также регрессионное (проверка, что новые изменения не привели к появлению ошибок в уже протестированных частях программы).
- Уровни: Различают несколько уровней, включая модульное (тестирование отдельных компонентов или модулей), интеграционное (проверка взаимодействия между модулями или системами) и системное (проверка всей системы в целом).
- Автоматизация: Динамическое тестирование может быть как ручным, так и автоматизированным. Автоматизация включает использование специального ПО для создания и выполнения тестов, что позволяет повысить эффективность тестирования и ускорить процесс разработки.
- Тестовые сценарии и данные: Разработка тестовых сценариев и подготовка тестовых данных являются ключевыми аспектами динамического тестирования. Они описывают условия и шаги для проверки конкретных функций или сценариев использования, а тестовые данные предоставляют необходимую информацию для выполнения этих тестов.
Преимущества:
- Практическая проверка: Динамическое тестирование демонстрирует реальное поведение программы, позволяя обнаружить ошибки, которые могут не быть очевидны при статическом анализе.
- Валидация функциональности: Помогает убедиться, что программное обеспечение выполняет все требуемые функции и соответствует спецификациям.
- Повышение качества продукта: Помогает улучшить надёжность, производительность и безопасность программного продукта, повышая тем самым удовлетворённость пользователя.
Динамическое тестирование — это проверка программного обеспечения путём его выполнения для обнаружения ошибок. Этот процесс позволяет оценить реальное поведение программы, её функциональность и производительность в различных условиях, что является ключом к обеспечению высокого качества и надёжности разрабатываемого продукта.
https://easyoffer.ru/question/7826
Что такое «парадокс пестицида»?
Теория тестирования
Суть: Повторное использование одних и тех же тестовых сценариев со временем становится всё менее эффективным в обнаружении новых дефектов.
Аналогия с пестицидами в сельском хозяйстве подразумевает, что так же, как вредители могут со временем развить устойчивость к определённым химическим веществам, программное обеспечение может “привыкнуть” к постоянно повторяемым тестам, и эти тесты перестанут быть эффективными для нахождения новых ошибок.
Причины:
- Ограниченное покрытие: Повторяющиеся тесты часто проверяют одни и те же аспекты программного обеспечения, оставляя другие части кода мало исследованными.
- Привыкание к дефектам: Со временем разработчики и тестировщики могут начать игнорировать известные проблемы, считая их “нормой”.
- Неадаптивность к изменениям: В процессе разработки ПО постоянно вносятся изменения, но если тесты не адаптируются под эти изменения, их эффективность уменьшается.
Как преодолеть эффект
- Регулярное обновление тестов: Необходимо периодически пересматривать и обновлять тестовые сценарии для адаптации к изменениям в программном обеспечении и среде.
- Использование разнообразных методов тестирования: Применение различных подходов и техник тестирования помогает обеспечить более полное покрытие тестами и увеличивает шансы на обнаружение дефектов.
- Эксплораторское тестирование: Помимо автоматизированных и ручных тестов по сценариям, полезно включать эксплораторское тестирование, которое предполагает исследовательский подход к поиску ошибок.
- Перемешивание тестов: Изменение порядка тестов и данных может помочь выявить новые ошибки, которые не обнаруживаются при стандартном выполнении тестов.
Эффект пестицида подчёркивает важность постоянного обновления и улучшения процессов тестирования в динамичной среде разработки программного обеспечения. Постоянное стремление к улучшению тестов и методов тестирования помогает поддерживать высокое качество продукта и эффективность процесса обнаружения дефектов.
https://easyoffer.ru/question/7872
Опишите основные фазы STLC?Дайте определение Entry и Exit Criteria.
Теория тестирования
Software Testing Life Cycle:
1. Анализ требований
2. Планирование тестирования
3. Разработка тест-кейсов
4. Настройка тестовой среды
5. Выполнение тестов
6. Завершение цикла испытаний
Критерии входа: обязательные элементы, которые должны быть выполнены перед началом тестирования.
Критерии выхода: определяют элементы, которые должны быть выполнены до завершения тестирования.
STLC - это процесс тестирования, который включает в себя определенную последовательность шагов, чтобы гарантировать достижение целей в области качества. В процессе STLC каждое действие выполняется планомерно и систематически. Каждый этап имеет разные цели и результаты. У разных организаций разные этапы STLC, однако основа остается прежней.
STLC имеет несколько взаимосвязанных фаз и в целом очень похож на SDLC. Эти фазы являются последовательными и называются:
- Анализ требований (Requirement Analysis): один из важнейших этапов, потому что именно на нем можно почти бесплатно исправить недостатки проекта. Этап анализа требований также определяет потенциальную потребность в автоматизированном тестировании и позволяет производить экономические расчеты затрат на рабочую силу на основе оценки проекта. На этом же этапе обсуждаются и документируются критерии начала и окончания тестирования
- Планирование тестирования (Test Planning): на этом этапе формируется план тестирования, т.е. мы определяем действия и ресурсы, которые помогут достичь целей тестирования (участники и их роли, инструменты, окружение). Во время планирования мы также пытаемся определить метрики, метод сбора и отслеживания этих метрик. План составляют исходя из требований, тестовой стратегии и анализа рисков
- Разработка тест-кейсов (Test Case Development): подразумевает использование ручного и автоматизированного тестирования для достижения полного охвата функциональности программного обеспечения, при этом процесс основан на заранее установленных требованиях. Чаще всего тест-кейсы для автоматического тестирования пишутся отдельно, так как кейсы для ручного тестирования описаны в виде шпаргалок (cheat sheets)
- Настройка тестовой среды (Test Environment Setup): в плане тестирования четко указано, какую тестовую среду следует использовать. На этом этапе STLC настраиваются операционные системы и виртуальные машины, развертываются инструменты тестирования, такие как Selenium, Katalon Studio, а также тестовая среда и базы данных проекта. Мы также обращаемся с запросами к DevOps и администраторам, если требуется поддержка
- Выполнение тестов (Test Execution): тесты выполняются на основе готовой тестовой документации и правильно настроенной тестовой среды. Все результаты тестирования регистрируются в Системе управления тестированием. Отрицательно пройденные тесты, в которых фактический результат отличается от ожидаемого, регистрируются как ошибки и передаются команде разработчиков на доработку с последующей перепроверкой после исправления
- Завершение цикла испытаний (Test Cycle Closure): окончательная генерация отчетов о тестировании для клиента. Они должны включать затраченное время, процент обнаруженных ошибок и положительных результатов тестирования, общее количество обнаруженных и исправленных ошибок. Что касается отдела тестирования, то это момент для анализа его работы, подведения итогов, анализа его продуктивности и возможности внести предложения по улучшению качества тестирования.
Критерии входа: Критерии входа содержат обязательные элементы, которые должны быть выполнены перед началом тестирования.
1. Выход билда для тестирования
2. 100% требований и мокапов утверждены и проверены
Критерии выхода: Критерии выхода определяют элементы, которые должны быть выполнены до завершения тестирования.
1. Выполнение более 80 % запланированных на итерацию тест-кейсов
2. Исправлено 100% критических багов
3. Автоматизированно 80% регрессионных тест-кейсов
https://stepik.org/lesson/1036729/step/4?auth=login&unit=1045214
https://vladislaveremeev.gitbook.io/qa_bible/sdlc-i-stlc/zhiznennyi-cikl-testirovaniya-po-stlc-software-testing-lifecycle
Что такое Bug, Error, Failure, Fault?
Теория тестирования
Суть: Некорректная работа программы, вызванная ошибкой в программном коде или дизайне продукта.
Баг — это ошибка, дефект или недочёт в коде, из-за которого ПО ведёт себя непредсказуемо, некорректно или не соответствует спецификациям и требованиям. Это может проявляться в виде сбоев, неправильной обработки данных, отклонений от заданных функциональных требований или других нежелательных поведений программы.
Причины возникновения могут включать:
- Ошибки в логике программы или алгоритмах.
- Неправильное использование типов данных или структур.
- Ошибки в коде, связанные с неучтёнными условиями или краевыми случаями.
- Непредвиденное взаимодействие между различными частями программы или с внешними системами.
- Ошибки в документации, приводящие к неправильной реализации функционала.
Обработка и исправление включает в себя несколько этапов:
- Идентификация и регистрация: Сначала он должен быть обнаружен, что может произойти в процессе разработки, тестирования или уже после релиза продукта пользователями. Затем ошибка регистрируется в системе учёта задач или баг-трекере с подробным описанием проблемы, условий, при которых она возникает, и, по возможности, шагов для её воспроизведения.
- Анализ и приоритизация: Команда разработки анализирует зарегистрированные баги, определяет их причины и приоритеты для исправления на основе важности функционала и влияния ошибки на пользователей.
- Исправление: Разработчики вносят необходимые изменения в код для устранения ошибки.
- Тестирование: После исправления бага проводится повторное тестирование соответствующего функционала, а также регрессионное тестирование для убедительности в том, что исправления не привели к новым проблемам в программе.
- Деплоймент: Исправленный код включается в следующую версию программного продукта, которая после прохождения всех тестов и проверок выкладывается для пользователей.
Управление багами является важной частью процесса разработки программного обеспечения, поскольку позволяет систематически улучшать качество продукта, устраняя обнаруженные недостатки и повышая удовлетворённость пользователей.
Какие атрибуты у баг-репорта?Какие основные поля для заполнения?
Теория тестирования
-
Какая разница между приоритетом и серьезностью?
Теория тестирования
Приоритет - как быстро нужно исправить ошибку
Серьезность - насколько серьезно ошибка затрагивает функциональность
Приведите примеры серьезного, но не приоритетного бага
Теория тестирования
У компании Google на главной странице ошибка в слове “Gogle”.
Высокий приоритет, но низкая серьёзность
Это означает, что дефект нужно исправить как можно скорее, хотя он и не оказывает значительного влияния на функциональность системы. Примеры могут включать:
- Ошибки в ключевых текстах или логотипах на главной странице: Хотя это не влияет на функциональность, такая ошибка может негативно сказаться на репутации компании.
- Незначительные ошибки в функционале, используемом во время демонстраций для важных клиентов: Например, ошибка в отображении логотипа компании-клиента в демо-версии продукта.
Низкий приоритет, но высокая серьёзность
Такие дефекты оказывают значительное влияние на работу системы, но их исправление может быть отложено из-за низкого влияния на текущие бизнес-процессы или из-за малой вероятности возникновения.
Примеры могут включать:
- Критические ошибки в редко используемых функциях: Например, сбой системы при выполнении специфической операции, которую используют единицы пользователей.
- Серьёзные ошибки в функционале, планируемом к скорому удалению или переработке: Если известно, что данный функционал будет скоро заменён, может быть принято решение не тратить ресурсы на исправление серьёзной ошибки.
https://easyoffer.ru/question/7895
В чем разница между валидацией и верификацией?
Теория тестирования
Верификация отвечает на вопрос “Строим ли мы продукт правильно?”, проверяя соответствие продукта требованиям и спецификациям на каждом этапе разработки.
Валидация отвечает на вопрос “Строим ли мы правильный продукт?”, подтверждая, что конечный продукт удовлетворяет потребностям и ожиданиям конечного пользователя.
https://easyoffer.ru/question/7811
Зачем требуется тестовая документация?Какие ее виды?
Теория тестирования
Суть: Помогает планировать, отслеживать процесс и результаты, а также обеспечивать эффективное взаимодействие внутри команды и с другими заинтересованными сторонами.
- Тестовая стратегия (Test Strategy)
- План тестирования (Test Plan)
- Тестовый сценарий (Test Case)
- Тестовый набор (Test Suite)
- Тестовые данные (Test Data)
- Баг (Bug report)
- Отчёт о тестировании (Test Report)
Она включает в себя различные типы документов, каждый из которых выполняет свои задачи на разных этапах тестирования.
Вот основные ее виды:
- Тестовая политика (Test Policy):
Описывает общие принципы и подходы к тестированию на уровне организации. Это стратегический документ, который не вдается в детали исполнения. - Тестовая стратегия (Test Strategy):
Определяет основные стратегические направления тестирования для конкретного проекта или серии проектов. Включает в себя выбор методологий, описание процессов управления рисками, ресурсов, инструментов и прочее. - План тестирования (Test Plan):
Описывает общий план тестирования для конкретного проекта или фазы, включая цели тестирования, объекты тестирования, ресурсы, ответственных и график работ. Он также определяет критерии начала и завершения тестирования, а также методы отслеживания и управления. - Тестовый сценарий (Test Case):
Подробное описание условий и шагов для проверки конкретного аспекта системы или приложения. Тестовый сценарий включает в себя входные данные, условия выполнения, шаги для выполнения и ожидаемый результат. - Тестовый набор (Test Suite):
Коллекция тестовых сценариев, объединённых по определённому признаку, например, функциональности, которую они тестируют, или типу тестирования (регрессионное, приёмочное и т.д.). - Тестовые данные (Test Data):
Данные, используемые для выполнения теста. Могут включать в себя входные файлы, данные для заполнения форм, конфигурационные файлы и так далее. - Протокол тестирования (Test Log):
Журнал, в котором фиксируется информация о процессе выполнения тестов, включая время начала и окончания тестирования, исполнителя, результаты и возникшие проблемы. - Отчёт о дефектах (Defect Report):
Описывает найденные в процессе тестирования ошибки. Включает информацию о способе воспроизведения ошибки, её серьёзности, состоянии и любые дополнительные сведения, которые могут помочь в её исправлении. - Отчёт о тестировании (Test Report):
Итоговый документ, который подводит итоги проведённого тестирования, включая общее качество продукта, обнаруженные дефекты, оценку выполнения тестового плана и рекомендации.
Каждый из этих документов играет важную роль в обеспечении качества и эффективности процесса тестирования, помогая улучшить коммуникацию в команде, обеспечивать прозрачность и отслеживаемость процессов, а также способствуя более глубокому пониманию и анализу тестируемой системы.
Тестовая документация — это набор документов, которые поддерживают и организуют процесс тестирования ПО. Она включает в себя планы, стратегии, сценарии, данные для тестирования, журналы выполнения тестов, отчёты о дефектах и итоговые отчёты, каждый из которых выполняет свою уникальную функцию для обеспечения качества и эффективности тестирования.
https://easyoffer.ru/question/7821
Что такое тест-план? Какие элементы у него есть?
Теория тестирования
Суть: документ для планирования тестирования
- Что надо протестировать
- Что будем действительно тестировать
- Как будем тестировать
- Когда будем тестировать
- Критерии сдачи
- Критерии приёмки
Тест-план — это документ, который описывает объем, подход, ресурсы и план тестирования ПО. Он служит руководством для тестирования продукта, определяя стратегию, задачи, приоритеты, ресурсы, графики и риски, связанные с процессом тестирования. Он помогает всей команде понимать задачи тестирования и ожидаемые результаты, а также обеспечивает структурированный подход к обеспечению качества.
Основные элементы:
- Введение: Краткое описание проекта и целей тестирования.
- Объекты тестирования: Список компонентов или функций программного обеспечения, которые будут тестироваться.
- Задачи тестирования: Четкое определение целей тестирования, включая что должно быть протестировано и что должно быть достигнуто в результате тестирования.
- Область тестирования и исключения: Описание того, что будет тестироваться, а также того, что будет исключено из тестирования.
- Подход к тестированию: Описание методологии и техник тестирования, которые будут использоваться, включая уровни тестирования (например, модульное, интеграционное, системное, приемочное).
- Критерии начала и завершения тестирования: Определение условий, при которых тестирование начнется и завершится.
- Ресурсы: Перечень всех необходимых ресурсов для тестирования, включая персонал, тестовое оборудование, и тестовые данные.
- Ответственные: Распределение ролей и обязанностей в команде тестирования.
- График тестирования: Временная шкала выполнения тестовых задач и этапов.
- Управление рисками: Оценка потенциальных рисков для плана тестирования и стратегии их минимизации.
- План выпуска тестов: Порядок выполнения тестов, включая зависимости между тестами.
- Требования к документированию: Описание того, как будут документироваться найденные дефекты, отчеты о тестировании и итоговые результаты.
Тест-план играет важную роль в успешном тестировании ПО. Он помогает обеспечить, что процесс тестирования является организованным, систематическим и эффективным. Тест-план также способствует обеспечению прозрачности и понимания процесса тестирования для всех участников проекта, а также помогает в управлении ожиданиями заинтересованных сторон относительно объема и глубины тестирования. Создание тест-плана является критическим шагом в обеспечении качества программного продукта и должно предшествовать началу любых тестовых действий.
https://easyoffer.ru/question/7846
Какую обязательную информацию должен содержать тест-план?
Как правильно его использовать, поддерживать и вообще он нужен для большинства проектов?
Теория тестирования
Суть: планирование требуется всегда, тест план нужен не всегда
- Что надо протестировать
- Что будем действительно тестировать
- Как будем тестировать
- Когда будем тестировать
- Критерии сдачи
- Критерии приёмки
В то время как стратегия излагает общие принципы или теорию, план детально описывает практические аспекты того, как проект будет протестирован в реальности.
Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования - по крайней мере, на высоком уровне - процесса выпуска на ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется на свет. Планирование - это непрерывное обучение, а не задача с конечным результатом.
В гибких методологиях всё чаще говорят о концепции одностраничного тест-плана, а в случае необходимости дополнений и уточнений просто создаются ссылки на внешние страницы/документы.
Тест-план призван отвечать на те вопросы, ради которых его создают. Порой весомую часть пользы от данной активности можно получить на этапе самого планирования и составления плана, а не от самого документа. Если команда понимает, что никакой практической “боли” этот документ и его создание не решает, на него нет времени, то можно прекрасно обойтись и без его формализации, т.к. в некоей словесной форме он всё равно будет существовать всегда.
Какая разница между чек-листом и тест-кейсом?
Теория тестирования
Тест-кейс и чек-лист являются инструментами в области тестирования ПО, но они служат разным целям и используются в различных контекстах.
Тест-кейс
Это документ, который содержит подробные инструкции для проверки конкретного аспекта системы или приложения. Он включает в себя информацию о предварительных условиях, входных данных, действиях, которые нужно выполнить, ожидаемых результатах и фактических результатах. Они разрабатываются для того, чтобы обеспечить систематическую проверку функциональности продукта и гарантировать, что все сценарии использования были тщательно протестированы.
Особенности:
- Подробное описание процедуры тестирования.
- Четко определенные шаги.
- Ожидаемые результаты для каждого шага.
- Предназначен для повторного использования в разных циклах тестирования.
Чек-лист
Это более обобщенный документ, который содержит список элементов или задач, которые нужно проверить, но без подробного описания того, как именно эти проверки должны быть выполнены. Они используются для упрощения процесса тестирования и обеспечения того, чтобы все важные аспекты были учтены. Они могут служить напоминанием для тестировщиков о том, что необходимо проверить, но оставляют за тестировщиком свободу выбора способа проверки.
Особенности:
- Список проверок без подробных инструкций.
- Гибкость в использовании.
- Может не содержать ожидаемых результатов.
- Подходит для общего обзора тестирования и помощи в организации тестов.
Различия
- Детализация: Тест-кейс содержит подробные шаги и ожидаемые результаты, в то время как чек-лист представляет собой простой список элементов для проверки.
- Цель использования: Тест-кейсы разработаны для детального тестирования функциональности и обеспечения полного покрытия тестами. Чек-листы же чаще используются для быстрой проверки или в качестве напоминания о том, что нужно протестировать.
- Гибкость: Чек-листы более гибкие и могут быть легко адаптированы под разные задачи и условия тестирования. Тест-кейсы, с другой стороны, требуют точного следования предписанным шагам.
И тест-кейсы, и чек-листы являются важными инструментами, выбор между которыми зависит от конкретной задачи, целей тестирования и требуемой глубины проверки.
Приведите пример хорошего тест-кейса.
Теория тестирования
Что такое ООП?
Назовите его принципы с примерами?
Программирование
Суть парадигма программирования, в основе которой лежат объекты. Где объекты это конкретные сущности создаваемые из класса, где класс это шаблон для создания объектов.
Принципы
* Абстракция
* Наследование
* Инкапсуляция
* Полиморфизм
Наследование — способ создания класса. Его суть заключается в том, что функциональность нового класса наследуются от уже существующего класса. Новый класс называется производным (дочерним). Существующий — базовым (родительским).
Инкапсуляция — мы можем ограничить доступ к методам и переменным, что предотвратит модификацию данных — это и есть инкапсуляция. Приватные атрибуты выделяются нижним подчеркиванием: одинарным _ или двойным __.
Полиморфизм — особенность ООП, позволяющая использовать одну функцию для разных форм (типов данных).
Абстракция — используется, чтобы скрыть внутренние характеристики функции от пользователей.
Парадигмой называют набор правил и критериев, которые соблюдают разработчики при написании кода. Если представить, что код — это рецепт блюда, то парадигма — то, как рецепт оформлен в кулинарной книге. Парадигма помогает стандартизировать написание кода. Это снижает риск ошибок, ускоряет разработку и делает код более читабельным для других программистов.
https://easyoffer.ru/question/335
https://easyoffer.ru/question/333
Что такое SOLID? Приведите примеры.
Программирование
SOLID - это принципы разработки программного обеспечения, следуя которым Вы получите хороший код, который в дальнейшем будет хорошо масштабироваться и поддерживаться в рабочем состоянии.
S - Single Responsibility Principle - принцип единственной ответственности. Каждый класс должен иметь только одну зону ответственности.
O - Open closed Principle - принцип открытости-закрытости.
Классы должны быть открыты для расширения, но закрыты для изменения.
L - Liskov substitution Principle - принцип подстановки Барбары Лисков.
Должна быть возможность вместо базового (родительского) типа (класса) подставить любой его подтип (класс-наследник), при этом работа программы не должна измениться.
I - Interface Segregation Principle - принцип разделения интерфейсов.
Данный принцип обозначает, что не нужно заставлять клиента (класс) реализовывать интерфейс, который не имеет к нему отношения.
D - Dependency Inversion Principle - принцип инверсии зависимостей.
Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те, и другие должны зависеть от абстракции. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
https://easyoffer.ru/question/332
Что такое интерфейс?
Что такое абстрактный класс?
Чем они отличаются?
Программирование
Интерфейс: Позволяет определить некоторый функционал не имеющий конкретной реализации
Абстрактный класс: базовый класс, который не предполагает создания экземпляров и может содержать всебе нереализованные элементы
Простыми словами: интерфейс - это просто описание методов, без их реализации. У абстрактного класса может быть и реализация методов.
- Класс может реализовать несколько интерфейсов, но наследовать только один абстрактный класс.
- Абстрактный класс может содержать конструкторы, поля и другие методы, в то время как интерфейс предоставляет только сигнатуры методов.
Интерфейс — это контракт, который должен быть реализован конкретным классом. Позволяет определить некоторый функционал не имеющий конкретной реализации.
У интерфейса не может быть состояния, поэтому в нем нельзя использовать изменяемые поля экземпляра. В интерфейсе могут быть только неизменяемые final-поля.
Абстрактный класс — похож на обычный, но отличается тем, что может содержать абстрактные методы — методы без реализации, и нельзя создать экземпляр абстрактного класса.
- Абстрактный класс может содержать как абстрактные, так и неабстрактные методы. Интерфейс содержит только абстрактные методы.
- Абстрактный класс может содержать поля и реализованные методы. В интерфейсе можно объявлять только константы.
- Класс может расширять только один абстрактный класс. Класс может реализовывать несколько интерфейсов.
- Абстрактный класс может иметь конструктор. Интерфейс не имеет конструктора.
- От абстрактного класса можно создать объект с помощью наследования и реализации всех абстрактных методов. От интерфейса нельзя создать объект, его можно только реализовать.
- Абстрактные методы в абстрактном классе могут иметь модификатор доступа. В интерфейсе методы абстрактны по умолчанию и не могут иметь модификатор доступа.
- Абстрактный класс используют, когда нужно предоставить частичную реализацию и определить поведение базового класса. Интерфейс - когда нужно только определить контракт класса, не затрагивая реализации.
Таким образом, абстрактный класс более гибкий и функциональный, а интерфейс используется для стандартизации и полиморфизма. Выбор между ними зависит от конкретных потребностей проектирования.
https://easyoffer.ru/question/8139
Что такое DRY, KISS, YAGNI?
Программирование
DRY (Don’t Repeat Yourself) - это принцип, который подразумевает, что каждая часть знаний или функциональности в программе должна иметь единственное, безошибочное и авторитетное представление в рамках системы. Он бращает внимание на избегание дублирования кода, данных и концепций в программном коде.
Основные идеи, связанные с этим принципом:
- Избегайте дублирования кода: Дублирование кода увеличивает сложность кодовой базы, делает ее труднее в поддержке и изменении. Поэтому следует стараться избегать повторения одинаковых или похожих кусков кода.
- Разделение кода на модули и функции: Часто используемый код должен быть вынесен в отдельные функции или модули, чтобы он мог быть повторно использован в различных частях программы.
- Использование абстракций и шаблонов проектирования: Использование абстракций и шаблонов проектирования позволяет создавать универсальные решения, которые можно использовать повторно в различных контекстах.
- Управление данными: Дублирование данных также может привести к проблемам согласованности и целостности. Поэтому следует стремиться к хранению данных в единственном источнике и использованию ссылок на него в других частях программы.
Преимущества применения этого принципа:
- Уменьшение объема кода: Избегание дублирования кода приводит к уменьшению объема кода, что облегчает его понимание и поддержку.
- Улучшение читаемости кода: Код становится более понятным и читаемым, так как повторяющиеся фрагменты убираются в отдельные функции или модули.
- Облегчение обслуживания: Изменения в программе требуют меньше усилий, так как они вносятся в единственном месте, а не в нескольких копиях кода.
Принцип DRY является одним из основных принципов разработки ПО и помогает создавать более эффективный, гибкий и поддерживаемый код.
KISS (Keep It Simple, Stupid) - это принцип проектирования ПО, который призывает к тому, чтобы решения были максимально простыми и непритязательными.
- Простота и ясность: ПО должно быть простым и понятным для понимания, как для его создателей, так и для пользователей. Простота снижает сложность, упрощает разработку и обслуживание кода.
- Отказ от избыточности: Избегайте излишних деталей и сложных конструкций в коде. Пишите только тот код, который необходим для решения задачи.
- Работоспособность и надежность: Простота не должна жертвовать работоспособностью и надежностью программы. ПО должно продолжать работать правильно и стабильно при любых условиях.
- Легкость сопровождения и расширения: ПО должно быть легко поддерживаемым и расширяемым. Простой код легче изменить, доработать и адаптировать под новые требования.
Принцип KISS подчеркивает важность обеспечения минимального количества сложности в ПО, что способствует повышению его читаемости, надежности и производительности. Он учитывает тот факт, что чем проще решение, тем менее вероятно наличие ошибок и проблем в будущем.
YAGNI (You Ain’t Gonna Need It) - подход к реализации проектов строго по ТЗ верен с нескольких ракурсов. Заказчик не должен платить за то, что ему не надо, а продукт должен быть максимально сопровождаем и его качество не должно страдать от интеграции ненужных функций.
Если упрощенно, то следование данному принципу заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. Это позволяет вести разработку, руководствуясь экономическими критериями — заказчик не должен оплачивать ненужные ему функции, а разработчики не должны тратить своё оплачиваемое время на реализацию того, что не требуется.
Основная проблема, которую решает принцип YAGNI — это устранение тяги программистов к излишней абстракции, к экспериментам «из интереса» и к реализации функционала, который сейчас не нужен, но, по мнению разработчика, может либо вскоре понадобиться, либо просто будет полезен, хотя в реальности такого очень часто не происходит.
«Бесплатных» функций в программных продуктах просто не бывает. Если рассматривать материальную сторону, то любые ненужные, но фактически реализованные «фичи» оплачиваются либо заказчиком (в бюджет закладываются расходы на те функции, которые не нужны), либо исполнителем из прибыли по проекту. И тот, и другой варианты с точки зрения бизнеса неверны. Если же говорить о нематериальных затратах, то любые «бонусные» возможности усложняют сопровождение, увеличивают вероятность ошибок и усложняют взаимодействие с продуктом, — между объёмом кодовой базы и описанными характеристиками есть прямая зависимость. Больше написанного кода — труднее сопровождать и выше вероятность появления «багов», тут очень уместна поговорка: «лучший код — это ненаписанный код».
Принципы YAGNI и KISS очень похожи, если KISS нацелен на упрощение и полезен в плане работы с теми требованиями, которые имеют место быть, то YAGNI более категоричен и применяется для ограждения проектов по разработке ПО от «размывания» их рамок.
Какие паттерны GOF вам известны?Приведите примеры их использования.
Программирование
Паттерны проектирования GoF (Gang of Four - от 4-х авторов) - это набор шаблонов проектирования, описанных в книге “Design Patterns: Elements of Reusable Object-Oriented Software” (“Паттерны проектирования. Переиспользуемые объектно-ориентированные программы”), написанной Эрихом Гаммой, Ричардом Хелмом, Ральфом Джонсоном и Джоном Влиссидесом. Эта книга является классическим источником знаний о паттернах проектирования.
- Порождающие (Creational)
- Структурные (Structural)
- Поведенческие (behavioral)
Паттерн проектирования — это часто встречаемое решение определённой проблемы при проектировании архитектуры программ.
В отличие от готовых функций или библиотек, паттерн нельзя просто взять и скопировать в программу. Паттерн представляет собой не какой-то конкретный код, а общую концепцию или пример решения той или иной проблемы, которое нужно будет подстроить под нужды вашей программы.
Паттерны часто путают с алгоритмами, ведь оба понятия описывают типовые решения каких-то известных проблем. И если алгоритм — это чёткий набор действий, то паттерн — это высокоуровневое описание решения, реализация которого может отличаться в двух разных программах. Если привести аналогии, то алгоритм — это кулинарный рецепт с чёткими шагами, а паттерн — инженерный чертёж, на котором нарисовано решение, но не конкретные шаги его получения.
Описания паттернов обычно формальны и чаще всего состоят из таких пунктов:
* проблемы, которую решает паттерн;
* мотивации к решению проблемы способом, который предлагает паттерн;
* структуры классов, составляющих решение;
* примера на одном из языков программирования;
* особенностей реализации в различных контекстах;
* связей с другими паттернами.
Порождающие (Creational)
Шаблоны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов.
- Factory(Фабрика) Сам по себе не является паттерном. Подход, при котором логика создания объектов выносится в отдельный класс.
- Фабричный метод(Factory Method) — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.
- Абстрактная фабрика (Abstract factory) — порождающий шаблон проектирования, предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов. Шаблон реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса он может создавать окна и кнопки). Затем пишутся классы, реализующие этот интерфейс.
- Прототип (Prototype) Задаёт виды создаваемых объектов с помощью экземпляра-прототипа и создаёт новые объекты путём копирования этого прототипа. Он позволяет уйти от реализации и позволяет следовать принципу «программирование через интерфейсы». В качестве возвращающего типа указывается интерфейс/абстрактный класс на вершине иерархии, а классы-наследники могут подставить туда наследника, реализующего этот тип. Проще говоря, это паттерн создания объекта через клонирование другого объекта вместо создания через конструктор.
- Строитель(Builder) — порождающий шаблон проектирования предоставляет способ создания составного объекта. Отделяет конструирование сложного объекта от его представления, так что в результате одного и того же процесса конструирования могут получаться разные представления.
- Одиночка (Singleton) — порождающий шаблон проектирования, гарантирующий, что в однопоточном приложении будет единственный экземпляр класса с глобальной точкой доступа.
Структурные (Structural)
Определяют различные сложные структуры, которые изменяют интерфейс уже существующих объектов или его реализацию, позволяя облегчить разработку и оптимизировать программу. Структурные шаблоны проектирования упрощают проектирование путем выявления простого способа реализовать отношения между субъектами.
- Адаптер (Adapter) — структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс.
- Мост (Bridge) — структурный шаблон проектирования, используемый в проектировании программного обеспечения чтобы «разделять абстракцию и реализацию так, чтобы они могли изменяться независимо». Шаблон мост использует инкапсуляцию, агрегирование и может использовать наследование для того, чтобы разделить ответственность между классами.
- Компоновщик (Composite pattern) — структурный шаблон проектирования, объединяющий объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково
- Декоратор (Decorator) — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Шаблон Декоратор предоставляет гибкую альтернативу практике создания подклассов с целью расширения функциональности.
- Фасад (Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.
- Приспособленец (Flyweight, “легковесный (элемент)”) — структурный шаблон проектирования, при котором объект, представляющий себя как уникальный экземпляр в разных местах программы, по факту не является таковым.
- Заместитель (Proxy) — структурный шаблон проектирования, который предоставляет объект, который контролирует доступ к другому объекту, перехватывая все вызовы (выполняет функцию контейнера).
Поведенческие (behavioral)
Шаблоны проектирования, определяющие алгоритмы и способы реализации взаимодействия различных объектов и классов. Поведенческие шаблоны проектирования определяют общие закономерности связей между объектами, реализующими данные паттерны. Следование этим шаблонам уменьшает связность системы и облегчает коммуникацию между объектами, что улучшает гибкость программного продукта.
- Цепочка обязанностей (Chain of responsibility) — поведенческий шаблон проектирования, предназначенный для организации в системе уровней ответственности.
- Команда (Command) — поведенческий шаблон проектирования, используемый при объектно-ориентированном программировании, представляющий действие. Объект команды заключает в себе само действие и его параметры.
- Интерпретатор (Interpreter) — поведенческий шаблон проектирования, решающий часто встречающуюся, но подверженную изменениям, задачу. Также известен как Little (Small) Language
- Итератор (iterator) — интерфейс, предоставляющий доступ к элементам коллекции (массива или контейнера) и навигацию по ним. В различных системах итераторы могут иметь разные общепринятые названия. В терминах систем управления базами данных итераторы называются курсорами.
- Посредник (Mediator) — поведенческий шаблон проектирования, обеспечивающий взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга
- Хранитель (Memento) — поведенческий шаблон проектирования, позволяющий, не нарушая инкапсуляцию, зафиксировать и сохранить внутреннее состояние объекта так, чтобы позднее восстановить его в это состояние.
- Наблюдатель (Observer) — поведенческий шаблон проектирования. Также известен как «подчинённые» (Dependents). Создает механизм у класса, который позволяет получать экземпляру объекта этого класса оповещения от других объектов об изменении их состояния, тем самым наблюдая за ними.
- Состояние (State) — поведенческий шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния.
- Стратегия (Strategy) — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путём определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.
- Шаблонный метод (Template method) — поведенческий шаблон проектирования, определяющий основу алгоритма и позволяющий наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом.
- Посетитель (visitor) — поведенческий шаблон проектирования, описывающий операцию, которая выполняется над объектами других классов. При изменении visitor нет необходимости изменять обслуживаемые классы.
Что такое PageObject и PageFactory?
Программирование
Page Object - это шаблон проектирования, который предполагает создание отдельного класса для каждой веб-страницы вашего приложения. В этом классе содержатся методы для взаимодействия с элементами на странице (кнопки, поля ввода и т. д.), а также для выполнения различных действий на странице. Page Object помогает абстрагировать логику работы с веб-страницей от сценариев тестов, делая код более понятным и поддерживаемым.
Page Factory - это дополнительный паттерн, который позволяет удобно и эффективно инициализировать экземпляры Page Object. Page Factory автоматически находит элементы на веб-странице и инициализирует их, что позволяет избежать дублирования кода и упрощает разработку и поддержку автоматизированных тестов.
Если коротко:
- Page Object - класс с методами для работы с веб-страницей.
- Page Factory - помогает удобно инициализировать элементы в Page Object.
Что такое Selenium и зачем его используют?
Selenium
Selenium WebDriver - программная библиотека для управления браузерами. Cемейство драйверов для различных браузеров, а также набор клиентских библиотек на разных языках, позволяющих работать с этими драйверами.
Selenium – это проект, в рамках которого разрабатывается серия программных продуктов с открытым исходным кодом (open source):
- Selenium WebDriver,
- Selenium RC,
- Selenium Server,
- Selenium Grid,
- Selenium IDE.
Называть просто словом Selenium любой из этих пяти продуктов, вообще говоря, неправильно, хотя так часто делают, если из контекста понятно, о каком именно из продуктов идёт речь, или если речь идёт о нескольких продуктах одновременно, или обо всех сразу.
Selenium WebDriver
Selenium WebDriver – это программная библиотека для управления браузерами. Часто употребляется также более короткое название WebDriver.
Иногда говорят, что это «драйвер браузера», но на самом деле это целое семейство драйверов для различных браузеров, а также набор клиентских библиотек на разных языках, позволяющих работать с этими драйверами.
Это основной продукт, разрабатываемый в рамках проекта Selenium.
Selenium RC
Selenium RC – это предыдущая версия библиотеки для управления браузерами. Аббревиатура RC в названии этого продукта расшифровывается как Remote Control, то есть это средство для «удалённого» управления браузером.
Эта версия с функциональной точки зрения значительно уступает WebDriver. Сейчас она находится в законсервированном состоянии, не развивается и даже известные баги не исправляются. А всем, кто сталкивается с ограничениями Selenium RC, предлагается переходить на использование WebDriver.
Selenium Server
Selenium Server – это сервер, который позволяет управлять браузером с удалённой машины, по сети. Сначала на той машине, где должен работать браузер, устанавливается и запускается сервер. Затем на другой машине (технически можно и на той же самой, конечно) запускается программа, которая, используя специальный драйвер RemoteWebDriver, соединяется с сервером и отправляет ему команды. Он в свою очередь запускает браузер и выполняет в нём эти команды, используя драйвер, соответствующий этому браузеру.
Selenium Grid
Selenium Grid – это кластер, состоящий из нескольких Selenium-серверов. Он предназначен для организации распределённой сети, позволяющей параллельно запускать много браузеров на большом количестве машин.
Selenium IDE
Selenium IDE – плагин к браузеру Firefox, который может записывать действия пользователя, воспроизводить их, а также генерировать код для WebDriver или Selenium RC, в котором выполняются те же самые действия. В общем, это «Selenium-рекордер».
https://habr.com/ru/articles/152653/
Что такое драйвер браузера?
Selenium
Суть: библиотека, позволяющая взаимодействовать с браузером.
По своей сущности Selenium WebDriver представляет собой:
- спецификацию программного интерфейса для управления браузером,
- референсные реализации этого интерфейса для нескольких браузеров,
- набор клиентских библиотек для этого интерфейса на нескольких языках программирования.
Selenium WebDriver, или просто WebDriver – это драйвер браузера, то есть не имеющая пользовательского интерфейса программная библиотека, которая позволяет различным другим программам взаимодействовать с браузером, управлять его поведением, получать от браузера какие-то данные и заставлять браузер выполнять какие-то команды.
Исходя из этого определения, ясно, что WebDriver не имеет прямого отношения к тестированию. Он всего лишь предоставляет автотестам доступ к браузеру. На этом его функции заканчиваются.
https://habr.com/ru/articles/152971/
Какие виды локаторов страницы есть?Каковы их преимущества и недостатки?
Selenium
CSS и XPath
Что такое Selenium Waits?
Какие есть и чем отличаются?
Selenium
Суть: есть явные и неявные ожидания. Явные объявляются каждый раз, неявные объявляются один раз, но ждут только до появления элемента в DOM. Оптимально использовать явные ожидания в рамках фреймворка типа selenide\selene.
Explicit Wait - явное (непосредственное, прямое) ожидание используется “здесь и сейчас” на один конкретный поиск элемента. В частности, даже паттерн “sleep” (ждать и ничего не делать) является примером explicit wait, но его применение не поощряется.
На практике рекомендуется использование WebDriverWait в сочетании с методами класса ExpectedConditions, которые позволяют сократить ожидание. Если элемент появился раньше времени, заданного при инициализации WebDriverWait - Selenium не будет ждать, а продолжит исполнение теста.
Implicit Wait - неявное (косвенное, скрытое) ожидание устанавливается один раз в коде вне операции поиска и действительно до изменения. Значение по умолчанию - 0, т.е. никакого ожидания. Implicit Wait применяется ко всем последующим операциям поиска неявно (т.е. скрытно, без указания напрямую в методе поиска, как мы видели в примере выше).
Единственная разница между Explicit и Implicit Waits заключается в том, что первый действителен только в для того поиска, где он определен, а второй - для всех последующих поисков.
Документация Seleniuma не рекомендует мешать в коде Explicit и Implicit Waits потому что тогда, будет сложно рассчитать настоящее максимальное ожидание. Как отменить установленный Implicit Wait? Очень просто - поставьте его обратно на 0.
Яков:
Самой главный нюанс - неявный вейт ждет только до появления элемента в ДОМе.
Козырь явных вейтов состоит в том - что они могут ждать до любого состояния элемента (виден, невиден, энейблд, дисейблд), причем вы можете как угодно кастомизировать (если знаете как) это ожидание, то есть - указывать - чего именно ждать.
В наш мир динамических сингл пейдж приложений, от неявных вейтов - толку мало. Если вы будете следовать принципу - всегда имплисит вейты, то у вас время от времени тесты будут падать, потому что не будут учитывать то, что некоторые элементы появляются в ДОМе раньше чем они становятся “видимыми”. Плюс когда тесты начнут падать (а вы ведь уже используете неявные ожидания) - вам прийдется встравивать явные - и тогда типа как не будете следовать официальной рекомендации - “не мешать их вместе”.
Поэтому я предлагаю не запариваться, а всегда юзать явные ожидания ;). Но для того что бы не запариваться - нужно либо использовать selenide\selene либо уметь построить свой собственний аналог из чистого селениума ;)
http://qa-blog.alexei-vinogradov.de/2015/07/%D0%BF%D1%80%D0%B0%D0%B2%D0%B4%D0%B0-%D0%BE-%D1%8F%D0%B2%D0%BD%D1%8B%D1%85-%D0%B8-%D0%BD%D0%B5%D1%8F%D0%B2%D0%BD%D1%8B%D1%85-%D0%BE%D0%B6%D0%B8%D0%B4%D0%B0%D0%BD%D0%B8%D1%8F%D1%85-%D0%B2-selenium/
Какие exceptions может оставить Selenium?
Что они значат и как их обрабатывать?
Selenium
Most Common Selenium Exceptions
- NoSuchWindowException
- NoSuchFrameException
- NoSuchElementException
- NoAlertPresentException
- InvalidSelectorException
- TimeoutException
- ElementNotVisibleException
- ElementNotSelectableException
- NoSuchSessionException
- StaleElementReferenceException
- NoSuchWindowException
One of the most frequent exceptions in Selenium Webdriver, NoSuchWindowException occurs if the current list of windows is not updated. The previous window does not exist, and you can’t switch to it.
To handle this exception, use webdriver methods called “driver.getWindowHandles().” - NoSuchFrameException
Similar to NoSuchWindowException, the NoSuchFrameException occurs when switching between multiple frames is not possible.
The solution used for handling NoSuchWindowException must ideally work for this exception too. - NoSuchElementException
Happens when the locators are unable to find or access elements on the web page or application. Ideally, the exception occurs due to the use of incorrect element locators in the findElement(By, by) method.
To handle this exception, use the wait command. Use Try/Catch to ensure that the program flow is interrupted if the wait command doesn’t help. - NoAlertPresentException
Happens when the user is trying to you switch to an alert which is not present. In simple terms, it means that the test is too quick and is trying to find an alert that has not yet been opened by the browser.
To handle or simply avoid this exception, use explicit or fluent wait in all events where an alert is expected. - InvalidSelectorException
This exception occurs due to an incorrect selector. More often than not, the selector syntax is wrong.
To avoid this exception, first, check the locator syntax. If it is incorrect, make sure the locator is syntactically correct. - TimeoutException
This exception is thrown if the command did not execute or complete within wait time. As already mentioned, waits are used to avoid NoSuchElementException. However, TimeoutException will be thrown after the page components fail to load within wait time.
Avoiding this exception is simple. All one needs to do is to calculate the average page load time and adjust the wait time accordingly. - ElementNotVisibleException
This exception occurs when the WebDriver tries to find an element that is hidden or invisible. To handle this exception, it is essential that the exact reason is identified, which can be due to nested web elements or overlapping web elements.
In the first case, you have to locate and correct the specific element. In the second case, use explicit wait. - ElementNotSelectableException
This exception belongs to the same class as InvalidElementStateException. In such exceptions, the element is present on the web page, but the element cannot be selected.
To handle this exception, the wait command must be used. - NoSuchSessionException
As the name suggests, the exception is thrown if a method is called post the browser is closed. Other reasons for this exception include a browser crash.
To avoid this handle, ensure that your browser is updated and stable. - StaleElementReferenceException
This exception occurs when the web element is no longer part of the web page. The element may have been part of the source code, but it is no longer part of the window. There can be multiple reasons for this exception. It can occur either from a switch to a different page, the element is no longer part of DOM or due to frame/window switch
To handle this exception, you can either use Dynamic Xpath for handling DOM operations or try to use the Page Factory Model or try to access the element in loops before throwing the exception.
Для чего используют JavaScriptExecutor?Приведите примеры.
Selenium
JavaScriptExecutor — это интерфейс, который помогает выполнять JavaScript посредством Selenium WebDriver.
Примеры:
1. Кликнуть через JS
2. Проскроллить страницу до элемента
3. Ввести текст полностью
Что такое Selenium Grid?
Selenium
Selenium Grid
Selenium Grid – это кластер, состоящий из нескольких Selenium-серверов. Он предназначен для организации распределённой сети, позволяющей параллельно запускать много браузеров на большом количестве машин.
Какие способы click и send keys в Selenium?
Selenium
Метод sendKeysusername.sendKeys("TestSelenium ");
Метод sendKeys() используется для ввода указанного значения (в круглых скобках) в текстовом поле. Обратите внимание, что метод sendKeys() вызывается для объекта WebElement, который был создан с помощью переменной element, соответствующей элементу пользовательского интерфейса страницы.
Приведенный выше блок кода вводит строку “TestSelenium” в текстовое поле Email в приложении Gmail.
sendKeys – одна из наиболее часто используемых команд в сценариях WebDriver.
Метод clickSignInButton.click();
Как и sendKeys(), click() является еще одной часто используемой командой для взаимодействия с веб-элементами. Метод click() используется для нажатия на веб-элемент, присутствующий на веб-странице.
Приведенный выше блок кода нажимает на кнопку “Войти” на главной странице Gmail.
Примечания:
В отличие от метода sendKeys(), метод click() не может принимать какие-либо параметры.
Иногда нажатие на веб-элемент может привести к загрузке новой страницы. Для предотвращения таких случаев метод click() реализовывается таким образом, чтобы дождаться загрузки этой страницы.
Как вы запускаете параллельное выполнение тестов?
Selenium
pytest + pytest-xdistpytest -n 2 (количество потоков)
pytest-xdist автоматически распределяет тестовые сценарии между потоками для параллельного выполнения.
Какая разница между Action и Actions?
Selenium
Action (интерфейс) - это отдельное действие (клик, движение курсора, ввод текста)
Actions (класс) - цепочка последовательных действий.
Как вычитать данные из динамической веб таблицы?
Selenium
Найти таблицу на странице
Найти строки и столбцы таблицы
Извлечь данные из ячеек
Как написать способ isElementPresent?
Selenium
Изучить потом если понадобится
Можете ли вы назвать 10 интерфейсов в Selenium?
Selenium
- WebDriver (ядро - интерфейс со всеми ключевыми методами)
- Window (операции с текущим окном)
- Options (доступ к меню браузера)
- Timeouts
- JavaScriptExecutor
- TakesScreenshot
- HasCapabilities
Назовите два способа автоматизации капчи.
Selenium
- Использование сервисов распознавания текстовой капчи
- Моделирование пользовательского поведения
Вспомните типы навигационных команд Selenium.
Selenium
Как найти поврежденные ссылки в Selenium WebDriver?
Selenium
- Получить ссылки на странице
- Сделать запрос к ссылке и проверить статус код через response
