Все специализации

QA-инженер, тестировщик: вопросы на собеседовании

133 вопроса с разбором ответов — те формулировки, которые действительно встречаются на интервью.

Эстимация в тестировании — это процесс прогнозирования времени, ресурсов и усилий, необходимых для выполнения определенного набора тестовых активностей.

Цели эстимации:

Планирование тестовых работ.

Определение сроков завершения тестирования.

Распределение ресурсов.

Оценка рисков.

Факторы, влияющие на эстимацию:

Объем функциональности.

Сложность функциональности.

Качество требований.

Опыт команды.

Наличие тестовой документации.

Стабильность тестовой среды.

Риски, связанные с проектом.

Используемые инструменты и технологии.

Методы эстимации:

Экспертная оценка: Оценка на основе опыта и знаний членов команды.

Аналогия: Оценка на основе сравнения с похожими предыдущими проектами.

分解 (Decomposition): Разбиение крупных задач на более мелкие и оценка каждой подзадачи.

Parametric Estimation: Использование статистических моделей, основанных на исторических данных.

Three-Point Estimation: Использование оптимистичной, пессимистичной и наиболее вероятной оценок для вычисления среднего (например, PERT).

PERТ E = (O + 4M + P) / 6

Инструменты для эстимации:

Jira (с плагинами).

Excel.

Специализированное программное обеспечение для управления проектами.

Процесс эстимации включает:

Понимание объема работ.

Разбиение работ на более мелкие задачи.

Оценка времени и усилий для каждой задачи.

Суммирование оценок для получения общей эстимации.

Учет рисков и буферов.

Обзор и согласование эстимации.

Важно пересматривать и уточнять эстимацию по мере продвижения проекта.

Убедиться в правильности воспроизведения бага. Провести регрессионное тестирование затронутой функциональности.

Предоставить разработчику более детализированное описание шагов воспроизведения, включая среду, тестовые данные, актуальные логи и скриншоты/видео записи.

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

Обсудить с разработчиком возможные причины возникновения бага и получить его точку зрения.

Если баг критичный или блокирующий, эскалировать проблему:

Руководителю группы тестирования (тимлиду QA): Для получения поддержки, дополнительной экспертизы или помощи в переговорах с разработчиком.

Руководителю проекта (ПМ): Для оценки влияния бага на сроки, бюджет и качество продукта, а также для принятия решения о приоритете исправления.

Владельцу продукта (PO): Для подтверждения важности бага с точки зрения бизнеса и определения его приоритета.

Оформить баг-репорт максимально подробно, указав все собранные данные, проведенные исследования и результаты обсуждений. Установить соответствующий приоритет и серьезность бага.

Следить за статусом бага в баг-трекинговой системе и ходом обсуждений.

Предложить альтернативные решения или временные обходные пути, если это возможно.

Нельзя однозначно сказать, что лучше Swagger или Postman, так как у них разные назначение и области применения.

Swagger (или OpenAPI Specification) — это спецификация, формат для описания RESTful API. Он позволяет документировать, проектировать и генерировать код для API.

Postman — это инструмент для тестирования и отладки API. Он позволяет отправлять HTTP-запросы, анализировать ответы, создавать коллекции запросов и автоматизировать тестирование.

Вот таблица для сравнения их ключевых особенностей:

Swagger идеально подходит для:

Документирования API, делая его понятным для разработчиков и потребителей.

Дизайна API до его реализации.

Автоматической генерации клиентского или серверного кода из спецификации.

Postman идеально подходит для:

Ручного и автоматизированного тестирования API.

Отладки API.

Исследования API и понимания его поведения.

Создания наборов запросов для различных тест-кейсов.

В практике QA Automation, Swagger полезен для понимания структуры API и формирования тестовых запросов на основе его спецификации. Postman же является основным инструментом для написания, запуска и автоматизации тестов API. Часто эти инструменты используются совместно: спецификация Swagger может быть импортирована в Postman для облегчения создания запросов и тестов.

Объекты в памяти обычно хранятся в куче (heap) — это область динамической памяти, где выделяется память для объектов во время выполнения программы. В отличие от стека (stack), который хранит локальные переменные и вызовы функций, куча предназначена для объектов с неопределённым временем жизни. Управление памятью в куче часто осуществляется с помощью сборщика мусора (garbage collector), который освобождает память от объектов, на которые больше нет ссылок. Например, в языках с автоматическим управлением памятью (Java, C#) объекты создаются в куче, а сборщик мусора заботится об их удалении.

При многократном использовании одних и тех же тестовых случаев эти тесты перестают выявлять новые дефекты в программном обеспечении. Это связано с тем, что разработчики оптимизируют код под существующие тесты. Чтобы избежать этого эффекта, необходимо регулярно пересматривать, обновлять и добавлять новые тестовые случаи, а также использовать различные методы и техники тестирования.

Веб-сервер — программа, которая принимает HTTP/HTTPS запросы от клиентов (браузеров) и возвращает в ответ веб-страницы, изображения, видео и другие файлы.

Веб-сервис — совокупность технологий для обмена данными между приложениями по сети. Он не обязательно возвращает веб-страницы, а часто использует форматы вроде XML, JSON или передачи сообщений (например, по протоколу SOAP, REST).

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

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

Основная разница:

HTTP статус-коды — это трехзначные числа, указывающие состояние запроса клиента после получения его сервером. Они группируются по первому числу:

1xx (Informational): Запрос получен, идет обработка.

2xx (Successful): Запрос успешно получен, понят и принят.

3xx (Redirection): Необходимы дополнительные действия для завершения запроса.

4xx (Client Error): Сервер не может обработать запрос из-за предполагаемой ошибки клиента.

5xx (Server Error): Сервер не смог обработать правильно сформированный запрос.

Наиболее распространенные коды:

В тестировании мы проверяем правильность статус-кодов в ответах сервера, чтобы убедиться, что бэкенд корректно обрабатывает различные типы запросов (успешные, с ошибками клиента, серверные проблемы). Это критично для проверки логики API.

Автоматизация проверки статус-кодов:

Октет IP – это одна из четырех частей IPv4-адреса, разделенных точками. Каждая часть представляет собой 8 бит (1 байт).

Например, в IP-адресе 192.168.1.1:

192 - первый октет

168 - второй октет

1 - третий октет

1 - четвертый октет

Значение каждого октета лежит в диапазоне от 0 до 255, так как 2^8 = 256 возможных значений (от 00000000 до 11111111 в двоичном представлении).

Пример двоичного представления октетов:

192 в двоичном виде: 11000000

168 в двоичном виде: 10101000

1 в двоичном виде: 00000001

Таким образом, IP-адрес 192.168.1.1 в двоичном виде - это 11000000.10101000.00000001.00000001.

Понимание октетов важно для:

Идентификации сетевых адресов: Октеты помогают определить часть адреса, относящуюся к сети, и часть, относящуюся к хосту, в зависимости от маски подсети.

Классификации IP-адресов: Исторически октеты использовались для разделения IP-адресов на классы (A, B, C, D, E).

Маска подсети: Маска подсети также представляется в виде четырех октетов и используется для определения сетевой части IP-адреса.

Толстый клиент – это тип архитектуры клиент-сервер, где большая часть логики приложения и обработки данных выполняется на стороне клиента.

Характеристики толстого клиента:

Высокая нагрузка на клиент: Клиентское приложение выполняет основные вычисления, рендеринг интерфейса и обработку пользовательских действий.

Минимальная нагрузка на сервер: Сервер в основном используется для хранения данных и выполнения простых запроcов.

Требовательность к ресурсам клиента: Клиентское устройство нуждается в достаточной вычислительной мощности и памяти для работы приложения.

Зависимость от клиента: Функциональность приложения сильно зависит от версии клиентского приложения и его корректной установки.

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

Примеры использования:

Традиционные настольные приложения (word процессоры, графические редакторы).

Некоторые корпоративные системы (CRM, ERP).

Игровые клиенты.

Атомарность в контексте тестирования и QA означает, что каждый тест-кейс или автоматизированный тест должен быть независимым, самодостаточным и выполнять проверку одной минимальной единицы функциональности.

Основные принципы атомарности:

Независимость: Результат одного теста не должен зависеть от выполнения другого. Тесты могут выполняться в любом порядке.

Самодостаточность: Каждый тест должен содержать все необходимые данные и действия для своего выполнения (настройка, исполнение, очистка).

Проверка одной единицы: Тест должен фокусироваться на проверке одного конкретного аспекта функциональности, одной бизнес-логики или одного сценария использования.

Преимущества атомарности:

Стабильность: Независимые тесты более устойчивы к изменениям в других частях системы или в наборе тестов.

Удобство отладки: При падении теста легко определить причину, поскольку он проверяет только одну вещь.

Параллельное выполнение: Атомарные тесты идеально подходят для параллельного запуска, что значительно сокращает время выполнения тестового набора, особенно для автоматизированных тестов.

Повторное использование: Независимые, сфокусированные тесты легче переиспользовать или адаптировать для других сценариев.

Надежность отчетов: Результаты по каждому тесту четко показывают, какая именно функциональность прошла или не прошла проверку.

Пример атомарного vs. неатомарного теста (автоматизированного):

Неатомарный (связанные шаги):

Атомарные (отдельные тесты):

В ручном тестировании атомарность также важна и достигается за счет четкого определения шагов, ожидаемого результата и тестируемой функциональности в каждом тест-кейсе.

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

Соблюдение принципа атомарности значительно повышает качество, надежность и поддерживаемость тестового набора.

В Charles Proxy для настройки троттлинга (ограничения скорости соединения) можно использовать следующие параметры:

Bandwidth: Ограничивает максимальную скорость загрузки (Download) и выгрузки (Upload) данных в килобитах в секунду (kbps).

Latency: Добавляет задержку (пинг) к каждому запросу и ответу в миллисекундах (ms).

Reliability: Эмулирует потери пакетов (%) на заданном проценте запросов.

Stability: Эмулирует нестабильное соединение, добавляя случайные короткие отключения.

Эти параметры можно применять глобально ко всему трафику, либо выборочно для определенных хостов или IP-адресов через настройки окна Throttling Settings.

Пример конфигурации в интерфейсе Charles (визуальный):

PUT используется для создания или полной замены ресурса по указанному URL. Если ресурс существует, он будет полностью перезаписан предоставленными данными. Если не существует, будет создан новый ресурс. Является идемпотентным методом.

POST используется для отправки данных на сервер для обработки. Это может быть создание нового ресурса, отправка данных формы, выполнение какой-либо операции. URL обычно указывает на "коллекцию", к которой применяется действие. Не является идемпотентным.

PATCH используется для частичного изменения ресурса. Вместо отправки полного представления ресурса, отправляются только те данные, которые необходимо изменить.

LEFT JOIN выбирает все строки из левой таблицы и соответствующие строки из правой. Если соответствия в правой таблице нет, для столбцов правой таблицы будут значения NULL.

RIGHT JOIN выбирает все строки из правой таблицы и соответствующие строки из левой. Если соответствия в левой таблице нет, для столбцов левой таблицы будут значения NULL.

Фактически, RIGH T JOIN — это зеркальное отражение LEFT JOIN. Результат RIGHT JOIN (таблица A JOIN таблица B) идентичен результату LEFT JOIN (таблица B JOIN таблица A) с переставленными столбцами.

Пример SQL:

Визуализация:

Конструкция SwitchKeys не является стандартной или общепринятой в большинстве популярных языков программирования или фреймворков для автоматизации тестирования (например, Java, Python, C#, JavaScript, Selenium, Cypress, Playwright).

Возможно, вы имеете в виду:

Комбинацию клавиш (Keyboard Shortcuts) в инструментах автоматизации: Специальные методы или классы для эмуляции нажатия комбинаций клавиш, например, send_keys в Selenium с использованием Keys.CONTROL, Keys.SHIFT и т.д.

Специфическую конструкцию в конкретной тестовой фреймворке или библиотеке: Некоторые инструменты могут иметь свои уникальные синтаксические конструкции.

Опечатку: Возможно, имелось в виду что-то другое (например, sendKeys, switch window, switch frame).

Если вы имели в виду комбинацию клавиш в Selenium с Python, вот пример:

Без дополнительного контекста или названия фреймворка/языка, использующего SwitchKeys, дать более точный ответ сложно.

Если речь идет о другом, могли бы вы уточнить контекст или инструмент, где вы встречали эту конструкцию?

Реляционные базы данных (РБД) хранят и организуют данные в виде таблиц. Смысл РБД заключается в следующем:

Структурированное хранение данных: Данные организованы в строки и столбцы, что обеспечивает четкую структуру и предсказуемость. Каждая строка представляет собой запись, а каждый столбец — атрибут записи.

Управление связями между данными: РБД позволяют устанавливать связи между различными таблицами с помощью внешних ключей. Это предотвращает дублирование данных и обеспечивает их целостность. Например, в таблице с заказами можно ссылаться на записи в таблице с клиентами, используя ID клиента.

Поддержка ACID-транзакций: Это гарантирует надежность и целостность данных даже при одновременных операциях или системных сбоях. ACID расшифровывается как:

Atomicity (Атомарность): Транзакция либо выполняется полностью, либо не выполняется вовсе.

Consistency (Согласованность): Транзакция переводит базу данных из одного согласованного состояния в другое.

Isolation (Изолированность): Параллельно выполняющиеся транзакции не влияют друг на друга.

Durability (Надежность): Результаты успешно выполненной транзакции сохраняются даже при сбоях.

Использование SQL в качестве основного языка запросов: SQL (Structured Query Language) является стандартным языком для взаимодействия с РБД. Он позволяет эффективно извлекать, вставлять, обновлять и удалять данные.

Пример простой структуры РБД:

Таблица Customers (Клиенты):

Таблица Orders (Заказы):

Здесь CustomerID в таблице Orders является внешним ключом, ссылающимся на CustomerID в таблице Customers, устанавливая связь между клиентами и их заказами.

Пример SQL-запроса:

В итоге смысл РБД — обеспечить надежное, эффективное и структурированное хранение и управление данными, поддерживая их целостность и предоставляя мощные средства для работы с ними через SQL.

Техника анализа классов эквивалентности (Equivalence Partitioning) – это метод проектирования тестовых случаев, основанный на разделении входных данных (или выходных условий) на классы, представители которых будут обрабатываться программой схожим образом. Тестирование одного представителя из каждого класса считается достаточным для покрытия всего класса.

Основная идея: Если тест на одном представителе класса выявляет ошибку, то, вероятно, тест на любом другом представителе того же класса тоже выявит ошибку. Если тест на одном представителе не выявляет ошибку, то, вероятно, тест на любом другом представителе того же класса тоже не выявит ошибки.

Применение:

Идентификация классов эквивалентности:

Определяются допустимые и недопустимые классы для каждого входного поля (числовой диапазон, набор строк, булевы значения и т.д.).

Для числовых диапазонов:

Допустимый диапазон.

Числа меньше нижней границы (недопустимый класс).

Числа больше верхней границы (недопустимый класс).

Для наборов значений:

Допустимые значения.

Недопустимые значения (например, строки в поле для чисел).

Например, для поля "Возраст" от 18 до 65 лет:

Допустимый класс: 18-65 (например, 25, 40, 60)

Недопустимый класс: < 18 (например, 17, 0)

Недопустимый класс: > 65 (например, 66, 100)

Создание тестовых случаев:

Выбирается по одному представителю из каждого идентифицированного класса (допустимого и недопустимого).

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

Пример:

Форма для заказа, поле "Количество товара", допустимое значение от 1 до 99.

Из каждого класса выбирается хотя бы один представитель для создания тестового случая. Например, для этого поля будет как минимум 4-6 тестовых случая, покрывающих все идентифицированные классы.

Преимущества:

Уменьшает избыточность тестовых случаев.

Помогает систематизировать процесс тестирования.

Обеспечивает хорошее тестовое покрытие с меньшим количеством тестов по сравнению с тестированием каждого возможного входного значения.

Недостатки:

Может не выявить ошибки на граничных значениях (часто используется в комбинации с анализом граничных значений).

Эффективность зависит от правильности идентификации классов эквивалентности.

Непрерывная доставка (Continuous Delivery, CD) — это методология разработки программного обеспечения, фокусирующаяся на возможности быстро, безопасно и устойчиво поставлять изменения в продакшн-среду. Основной принцип — всегда иметь готовый к релизу артефакт, который можно развернуть в любой момент времени.

Основные составляющие:

Автоматизированная сборка: Код собирается и упаковывается автоматически при каждом коммите.

Автоматизированное тестирование: Включает модульные, интеграционные, системные и другие виды тестов для проверки качества изменений.

Автоматизированное развертывание: Процесс доставки артефакта в различные среды (разработка, тестирование, стейджинг, продакшн) автоматизирован.

Пайплайн доставки (Delivery Pipeline): Визуализация workflow, через который проходят изменения от коммита до продакшена, включая сборку, тестирование и развертывание.

Ключевое отличие от Continuous Deployment:

В Continuous Delivery релиз в продакшн является ручным шагом (хотя и возможным в любой момент), тогда как в Continuous Deployment этот шаг тоже автоматизирован при успешном прохождении всех тестов и проверок.

Преимущества:

Сокращение времени выхода на рынок (Time to Market).

Снижение рисков при релизах за счет частых и небольших изменений.

Повышение качества за счет интенсивного автоматизированного тестирования.

Улучшение обратной связи от пользователей.

Повышение эффективности команды за счет автоматизации рутинных операций.

Инструменты (примеры):

Системы контроля версий: Git

Системы сборки: Maven, Gradle, npm

Серверы CI/CD: Jenkins, GitLab CI, GitHub Actions, CircleCI

Инструменты для тестирования: JUnit, TestNG, Selenium, Cypress

Инструменты для управления конфигурацией: Ansible, Chef, Puppet

Платформы контейнеризации: Docker, Kubernetes

CD требует сильной культуры автоматизации, DevOps-практик и тесного сотрудничества между разработчиками, тестировщиками и операционными командами.

Да, знаком с основными методиками проектирования тестов.

Наиболее часто применяемые методики:

Тестирование на основе спецификации / Black Box Testing:

Классы эквивалентности (Equivalence Partitioning)

Анализ граничных значений (Boundary Value Analysis)

Таблицы принятия решений (Decision Tables)

Попарное тестирование (Pairwise Testing)

Тестирование состояний/переходов (State Transition Testing)

Сценарии использования (Use Case Testing)

Тестирование на основе структуры / White Box Testing:

Покрытие операторов (Statement Coverage)

Покрытие ветвлений (Branch / Decision Coverage)

Покрытие условий (Condition Coverage)

Покрытие множественных условий (Multiple Condition Coverage)

Покрытие путей (Path Coverage)

Тестирование на основе опыта / Experience-Based Testing:

Исследовательское тестирование (Exploratory Testing)

Тестирование на основе ошибок (Error Guessing)

Выбор методики зависит от типа тестируемого приложения, наличия и качества документации, требуемого уровня покрытия и доступного времени.

Назначение баг-репорта может варьироваться в зависимости от процесса и структуры команды. Обычно он назначается:

На тимлида или менеджера проекта: Он может распределить баг между разработчиками или другими членами команды.

На конкретного разработчика: Если тестировщик точно знает, кто ответственен за функционал.

На компонент или модуль: Баг назначается на ответственного за конкретную часть системы.

На ответственного за triage: В больших проектах может быть выделенный специалист для первичной оценки и распределения багов.

Наиболее частый сценарий – назначение на тимлида или разработчика, ответственного за затронутый функционал.

Тестирование поля "Дата рождения" включает различные аспекты, от валидации формата до проверки граничных значений и взаимодействия с другими элементами.

Функциональное тестирование:

Позитивные сценарии:

Ввод корректной даты в поддерживаемом формате (например, DD.MM.YYYY, MM/DD/YYYY).

Выбор даты с помощью календаря/дейтпикера.

Ввод даты, соответствующей минимально допустимому возрасту (если есть такое требование).

Ввод даты, соответствующей максимально допустимому возрасту (если есть такое требование).

Негативные сценарии:

Ввод некорректного формата даты.

Ввод невалидных значений (например, 31 февраля, 32 марта).

Ввод букв, символов, специальных знаков вместо чисел.

Оставление поля пустым, если оно обязательное.

Ввод даты в будущем (если не разрешено).

Ввод даты, нарушающей ограничения по возрасту.

Копирование и вставка некорректных значений.

Тестирование валидации:

Проверка отображения сообщений об ошибке при вводе некорректных данных.

Проверка корректности текста сообщений об ошибке.

Проверка, что форма не отправляется при наличии ошибок валидации.

Проверка снятия сообщений об ошибке после ввода корректных данных.

Тестирование UI/UX (если используется дейтпикер или календарь):

Удобство выбора даты с помощью календаря.

Корректное отображение текущего месяца/года.

Навигация по месяцам и годам.

Выделение выбранной даты.

Доступность для пользователей с ограниченными возможностями (если применимо).

Тестирование производительности:

Скорость загрузки и отображения поля.

Скорость работы календаря/дейтпикера при выборе даты.

Тестирование безопасности:

Проверка на XSS (Cross-Site Scripting) путем ввода скриптов в поле.

Граничные значения:

Тестирование года рождения: минимально возможный год (например, 1900), текущий год минус минимальный возраст, текущий год минус максимальный возраст.

Тестирование даты: первый день месяца, последний день месяца, 1 января, 31 декабря.

Тестирование високосных годов.

Интеграционное тестирование:

Как поле "Дата рождения" взаимодействует с другими полями формы (например, "Возраст", "Год выпуска").

Как дата рождения влияет на логику приложения (например, расчет возраста, определение доступных функций).

Примеры тест-кейсов (высокоуровнево):

ID: TC_DOB_001

Описание: Ввод корректной даты рождения в формате DD.MM.YYYY.

Шаги: 1. Открыть форму. 2. В поле "Дата рождения" ввести "01.01.1990". 3. Отправить форму.

Ожидаемый результат: Форма успешно отправлена, дата сохранена корректно.

ID: TC_DOB_001

ID: TC_DOB_002

Описание: Ввод некорректной даты (31 февраля).

Шаги: 1. Открыть форму. 2. В поле "Дата рождения" ввести "31.02.2000". 3. Покинуть поле.

Ожидаемый результат: Отображается сообщение об ошибке валидации: "Некорректная дата".

ID: TC_DOB_002

ID: TC_DOB_003

Описание: Выбор даты с помощью дейтпикера.

Шаги: 1. Открыть форму. 2. Нажать на иконку дейтпикера рядом с полем "Дата рождения". 3. В календаре выбрать произвольную дату.

Ожидаемый результат: Выбранная дата отображается в поле "Дата рождения".

ID: TC_DOB_003

Пример автоматизированного теста (Selenium с Python):

Тестирование критического пути (Critical Path Testing) - это подход к тестированию, который фокусируется на проверке самых важных и часто используемых сценариев использования системы.

Цель:

Обеспечить стабильную работу ключевых функций системы.

Минимизировать риски сбоев в наиболее важных business-процессах.

Убедиться, что основные user-journeys работают корректно.

Критерии определения критического пути:

Частота использования: Сценарии, которыми пользуется большинство пользователей.

Бизнес-ценность: Сценарии, напрямую связанные с получением дохода, выполнением ключевых операций или достижением основных целей бизнеса.

Влияние отказа: Сценарии, сбой в которых приведет к серьезным последствиям (потеря данных, финансовые убытки, репутационный ущерб).

Взаимосвязь с другими функциями: Сценарии, от которых зависят или которые включают в себя множество других функций.

Этапы тестирования критического пути:

Идентификация: Определение ключевых бизнес-процессов и сценариев использования.

Приоритизация: Выделение наиболее критичных путей на основе установленных критериев.

Разработка тест-кейсов: Создание подробных тест-кейсов для проверки каждого шага критического пути.

Выполнение: Прогон разработанных тест-кейсов.

Анализ результатов: Оценка результатов тестирования и устранение дефектов, выявленных на критических путях в первую очередь.

Преимущества:

Максимальное покрытие наиболее важных функций.

Эффективное использование ресурсов тестирования.

Раннее выявление критических дефектов.

Повышение уверенности в стабильности системы.

Недостатки:

Менее полное покрытие остальных функций системы.

Необходимость четкого определения критических путей.

Пример критического пути для интернет-магазина:

Вход или регистрация пользователя.

Поиск товара по названию или категории.

Добавление товара в корзину.

Переход к оформлению заказа.

Выбор способа доставки.

Выбор способа оплаты.

Осуществление оплаты.

Подтверждение заказа.

Apple Human Interface Guidelines (HIG) — это набор принципов и рекомендаций Apple для создания интуитивно понятных, последовательных и удобных пользовательских интерфейсов на платформах компании (iOS, iPadOS, macOS, watchOS, tvOS).

Основные влияния на разработку:

Принципы дизайна: HIG задает ключевые принципы, такие как ясность (Clarity), отличительность (Deference) и глубина (Depth), которые определяют общую эстетику и логику взаимодействия. Это помогает создавать приложения, которые гармонично вписываются в экосистему Apple.

Элементы управления: Определяет внешний вид и поведение стандартных компонентов UI (кнопки, переключатели, слайдеры, таблицы и т.д.). Использование стандартных элементов в соответствии с HIG обеспечивает привычное поведение для пользователя.

Шаблоны взаимодействия: Описывает стандартные паттерны навигации, ввода данных, отображения информации (например, использование Tab Bar для основных разделов, Navigation Bar для иерархии, Alert для важных сообщений). Следование этим паттернам снижает когнитивную нагрузку на пользователя.

Адативность и доступность: Содержит рекомендации по созданию адаптивных интерфейсов, которые хорошо выглядят и работают на разных устройствах и ориентациях, а также по обеспечению доступности для пользователей с ограниченными возможностями (например, поддержка Dynamic Type для изменения размера шрифта, VoiceOver).

Производительность и отклик: Влияет на то, как приложения должны обрабатывать жесты, анимации и переходы, чтобы ощущение от взаимодействия было плавным и отзывчивым.

Последовательность: Следование HIG обеспечивает единообразие внешнего вида и поведения между различными приложениями на платформе, что улучшает общую user experience.

Процесс ревью в App Store: Соблюдение HIG является важным критерием при проверке приложений перед публикацией в App Store или Mac App Store. Несоответствие может привести к отклонению.

Влияние на QA:

Тест-кейсы: HIG является основой для написания тест-кейсов на соответствие дизайна, поведения и доступности элементов интерфейса стандартам платформы.

Поиск дефектов: Позволяет выявлять дефекты, связанные с несоответствием стандартным жестам, анимациям, размерам элементов, шрифтам и цветам.

Критерии приемки: Стандарты HIG включаются в критерии приемки фич, связанных с пользовательским интерфейсом.

Пример соответствия (псевдокод):

Пример несоответствия (псевдокод):

Санитарное тестирование (Sanity Testing) — это подмножество регрессионного тестирования, проводимое после внесения небольших изменений или исправлений ошибок в приложение, чтобы убедиться, что изменения не внесли серьезных проблем в основную функциональность. Оно быстрое и поверхностное.

Основные характеристики:

Цель: убедиться, что недавно внесенные изменения функционируют как задумано и не нарушили критическую часть системы.

Область: сосредоточено только на измененной области кода и связанных с ней компонентах.

Глубина: поверхностное, не углубляется в тестирование всех возможных сценариев.

Когда проводится: после развертывания сборки с небольшими изменениями или исправлениями ошибок, но перед более полным регрессионным тестированием.

Кто проводит: обычно тестировщики.

Отличие от смоук-тестирования:

Смоук-тестирование: проверяет основные, критические функции всего приложения (весьма широкая, но поверхностная проверка) для решения, можно ли вообще проводить дальнейшие тесты.

Санитарное тестирование: проверяет конкретную измененную область и связанные с ней функции (более сфокусированная, но все еще поверхностная проверка) для решения, можно ли продолжать тестирование этой specific фичи/исправления.

Пример сценария:

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

Тестирование зависит от контекста (Context-Driven Testing) означает, что подход, методы и инструменты тестирования выбираются исходя из уникальных характеристик проекта, команды, продукта и бизнес-целей. Нет универсального "лучшего" способа тестировать, применимого ко всем ситуациям.

Основные принципы контекстно-зависимого подхода:

Ценность: Тестирование должно приносить ценность заинтересованным сторонам. Эта ценность определяется контекстом.

Непредсказуемость: Внешние факторы (изменение требований, сроки, технологии) постоянно влияют на проект, требуя гибкости в подходах к тестированию.

Навыки и знания: Успех тестирования зависит от навыков, опыта и знаний тестировщиков в конкретном контексте.

Адаптивность: Тестовые стратегии, планы и активности должны постоянно адаптироваться к меняющемуся контексту.

Нет "лучших практик" вне контекста: То, что хорошо работает в одном проекте, может быть неэффективно или даже вредно в другом.

Примеры влияния контекста:

Тип продукта: Тестирование медицинского оборудования (высокая безопасность) отличается от тестирования мобильного приложения (скорость выхода на рынок).

Размер команды: В маленькой команде тестирование может быть неформальным, в большой — требовать жесткой стандартизации.

Бизнес-модель: Продукт с подпиской и постоянными обновлениями требует более гибкого и автоматизированного тестирования, чем коробочное решение.

Технологический стек: Тестирование микросервисной архитектуры отличается от монолита.

Временные ограничения: Сжатые сроки могут требовать приоритизации и отказа от некоторых видов тестирования.

Стек в контексте разработки и тестирования программного обеспечения может означать несколько вещей:

Технологический стек (Tech Stack): Набор технологий, фреймворков, языков программирования, баз данных и инструментов, используемых для разработки и поддержки приложения.

Примеры:

Frontend: React, Angular, Vue.js

Backend: Node.js, Python (Django/Flask), Java (Spring), Ruby on Rails

Базы данных: PostgreSQL, MongoDB, MySQL

Инфраструктура: Docker, Kubernetes, AWS, Google Cloud

Ci/CD: Jenkins, GitLab CI, GitHub Actions

Инструменты тестирования: Selenium, Cypress, JUnit, TestNG, Postman, JMeter

Значение для QA: Понимание технологического стека помогает определить подходящие инструменты и подходы для тестирования (например, выбор фреймворка для автоматизации UI, знание особенностей базы данных при нагрузочном тестировании).

Примеры:

Примеры:

Стек вызовов (Call Stack): Структура данных (часто в виде стека) в памяти, используемая для хранения информации о активных подпрограммах или функциях во время выполнения программы. При вызове функции ее контекст (локальные переменные, адрес возврата) помещается в стек. При возврате из функции этот контекст удаляется из стека.

Пример: Трассировка стека (Stack Trace)

// Пример стека вызовов при исключении

public class StackExample {

public static void main(String[] args) {

methodA();

}

public static void methodA() {

methodB();

}

public static void methodB() {

methodC();

}

public static void methodC() {

throw new RuntimeException("Ошибка в методе C");

}

}

// Вывод трассировки стека при возникновении исключения:

// java.lang.RuntimeException: Ошибка в методе C

// at StackExample.methodC(StackExample.java:16) // Последний вызов

// at StackExample.methodB(StackExample.java:12) // Вызов methodC из methodB

// at StackExample.methodA(StackExample.java:8) // Вызов methodB из methodA

// at StackExample.main(StackExample.java:4) // Вызов methodA из main

Значение для QA: Анализ трассировки стека при возникновении ошибки (креша приложения) помогает локализовать место возникновения проблемы в коде. Для QA automation это критично при анализе падений тестов, особенно в backend или unit тестах.

Структура данных Стек (Stack Data Structure): Абстрактный тип данных, который работает по принципу LIFO (Last-In, First-Out - последний пришел, первый ушел). Основные операции: push (добавить элемент на вершину) и pop (удалить и вернуть элемент с вершины).

Пример: Использование стека для проверки скобок

# Проверка сбалансированности скобок с помощью стека

def is_balanced(text):

stack = []

mapping = {")": "(", "}": "{", "]": "["}

for char in text:

if char in mapping.values():

stack.append(char)

elif char in mapping.keys():

if not stack or mapping[char] != stack.pop():

return False

return not stack # Стек должен быть пустым в конце

# Применение в тестировании:

# is_balanced("([{}])") -> True

# is_balanced("[(}]") -> False

Значение для QA: Понимание структуры данных "стек" полезно для анализа алгоритмов, используемых в логике приложения, или при работе с определенными структурами данных, если это требует глубокого понимания тестируемой системы.

В контексте собеседования на позицию QA / QA Automation, наиболее часто под "стеком" подразумевается Технологический стек. Важно продемонстрировать понимание компонентов стека, с которым вы работаете или будете работать, и их влияния на процессы тестирования.

Параметры запроса (query parameters) — это пары ключ-значение, добавляемые к URL после знака ?. Они используются для передачи дополнительной информации на сервер при HTTP-запросах (чаще всего GET).

Пример URL с параметрами запроса:

https://example.com/api/items?category=electronics&sort=price_asc

Здесь:

category=electronics — первый параметр, ключ category, значение electronics.

sort=price_asc — второй параметр, ключ sort, значение price_asc.

Параметры разделяются амперсандом (&).

Назначение параметров запроса:

Фильтрация данных: Отбор данных по определенным критериям.

Сортировка данных: Определение порядка сортировки получаемых данных.

Постраничная навигация (pagination): Указание номера страницы и количества элементов на странице.

Передача идентификаторов: Идентификация ресурса или пользователя.

Дополнительные инструкции для сервера: Например, какие поля вернуть в ответе.

На стороне сервера приложения парсят эти параметры и используют их для формирования ответа.

В автоматизации тестирования параметры запроса часто используются для:

Генерации тестовых данных с различными условиями.

Проверки логики API при различных входных данных.

Тестирования фильтрации, сортировки и пагинации на бэкенде.

Пример использования параметров запроса в Python с библиотекой requests:

Брейкпоинт (breakpoint) в адаптивной верстке — это пороговое значение ширины экрана устройства, при достижении или пересечении которого меняются CSS-стили элементов страницы.

Основное назначение брейкпоинтов:

Обеспечение оптимального отображения контента: На разных размерах экранов блоки могут иметь разные размеры, расположение, отступы.

Скрытие/отображение элементов: Например, на мобильных устройствах можно скрыть боковую панель, а на десктопах – показать.

Изменение шрифтов и изображений: Для лучшей читаемости и производительности.

Брейкпоинты задаются с помощью медиазапросов (media queries) в CSS:

Типичные брейкпоинты основаны на стандартных размерах устройств, но могут быть кастомизированы под конкретный дизайн. Примеры стандартных брейкпоинтов:

Важно разрабатывать дизайн "mobile-first", начиная с наименьших брейкпоинтов и добавляя стили для больших экранов, что упрощает переопределение стилей.

Тестовый набор (тест-сьют) — это коллекция тестовых сценариев (тест-кейсов), объединенных по определенному признаку.

Основное назначение:

Организация тестов.

Структурирование процесса тестирования.

Облегчение планирования и выполнения тестовых прогонов.

Признаки объединения:

Функциональная область приложения.

Тип тестирования (например, регрессионный, smoke).

Приоритет или критичность тестовых сценариев.

Версия тестируемого продукта.

Пример структуры тестового набора:

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

Переопределение метода (Overriding) — это возможность подкласса предоставлять свою собственную реализацию метода, который уже определен в его родительском классе. Сигнатура переопределяемого метода (имя, количество и типы параметров) в подклассе должна полностью совпадать с сигнатурой метода в родительском классе. Тип возвращаемого значения также должен быть либо тем же, либо являться ковариантным (подтипом) типа возвращаемого значения родительского метода.

Основные аспекты переопределения:

Наследование: Переопределение возможно только в контексте отношений наследования, где подкласс наследует метод от суперкласса.

Полиморфизм: Переопределение является одним из механизмов реализации полиморфизма времени выполнения (runtime polymorphism). Это означает, что в зависимости от фактического типа объекта, вызываемого через ссылку на родительский тип, будет выполняться соответствующая реализация метода (либо из родительского, либо из дочернего класса).

Ключевое слово @Override: В некоторых языках (например, Java) используется аннотация @Override. Она не является обязательной для корректной работы переопределения, но рекомендуется для улучшения читаемости кода и предотвращения ошибок компиляции, если метод не соответствует правилам переопределения.

Доступ к родительскому методу: Внутри переопределенного метода подкласса часто требуется вызвать реализацию того же метода из родительского класса. Для этого используется ключевое слово super (например, super.метод()).

Пример на Java:

Пример на Python:

Переопределение используется для адаптации поведения базового класса к специфике дочернего класса, сохраняя при этом общий интерфейс. Это ключевой элемент объектно-ориентированного дизайна.

Ad Hoc тестирование — это неформальное, незапланированное и неструктурированное тестирование без использования документации. Цель — быстро найти дефекты в неожиданных местах. Зависит от интуиции и опыта тестировщика.

Отличия от исследовательского тестирования:

Исследовательское тестирование — это формализованный подход, при котором тестирование рассматривается как процесс обучения о продукте. Тестировщик исследует функциональность, строит гипотезы о её работе и потенциальных проблемах, документирует свои наблюдения и результаты. Используются тест-чартеры, карты сознания.

В целом, исследовательское тестирование более структурировано и целенаправленно, чем Ad Hoc, и направлено не только на поиск дефектов, но и на глубокое понимание тестируемого продукта.

C# (для разработки на .NET)

C++ (классический язык для системного программирования и разработки на WinAPI/MFC)

Visual Basic .NET (для разработки на .NET)

XAML (для описания пользовательских интерфейсов в WPF/UWP)

Примеры использования C# и C++:

Куча (Heap) - это область памяти, используемая для динамического выделения, где порядок доступа к данным не имеет фиксированной структуры.

Основные характеристики:

Динамическое выделение памяти: Память выделяется (malloc/new) и освобождается (free/delete) во время выполнения программы.

Отсутствие строгой структуры: Данные расположены произвольно, нет линейной организации как в стеке.

Время доступа: Время доступа к элементам может варьироваться, так как зависит от расположения элемента и необходимости поиска.

Управление памятью: Требует явного управления памятью (ручное или сборщик мусора) для предотвращения утечек или повреждений.

Используется для: Объектов, массивов и других данных, чьи размеры неизвестны на этапе компиляции или которые должны существовать дольше, чем текущая функция или блок кода.

Доменное тестирование (Domain Testing) — это техника тест-дизайна, сфокусированная на проверке корректности обработки входных данных в пределах допустимых диапазонов. Цель — убедиться, что система правильно обрабатывает значения из различных подмножеств допустимого домена. Используются техники, такие как анализ граничных значений (Boundary Value Analysis) и классы эквивалентности (Equivalence Partitioning).

Применение:

Выявление ошибок, связанных с обработкой границ диапазонов или некорректной обработкой значений внутри допустимого множества.

Эффективное сокращение количества тестовых случаев при большом количестве возможных входных значений.

Обеспечение покрытия наиболее критичных для логики приложения входных данных.

Пример:

Для поля "Возраст" с допустимыми значениями от 1 до 120:

Классы эквивалентности: Некорректные (< 1), Допустимые (1-120), Некорректные (> 120).

Граничные значения: 0, 1, 2, 119, 120, 121.

Тестирование будет сфокусировано на значениях, покрывающих эти классы и границы.

Реляция, или связь между таблицами в базе данных, нужна для:

Устранения избыточности данных: Вместо дублирования информации в нескольких таблицах, она хранится в одной, а другие ссылаются на нее. Это экономит место и упрощает обновление.

Обеспечения целостности данных: Связи помогают поддерживать согласованность данных. Например, нельзя удалить строку в одной таблице, если на нее ссылается строка в другой (в зависимости от типа ограничения).

Упрощения запросов: Позволяет легко извлекать связанные данные из нескольких таблиц с использованием операций JOIN.

Создания структуры базы данных: Отражает логическую взаимосвязь между сущностями реального мира, делая структуру базы данных более понятной и организованной.

Примеры типов реляций:

Один к одному (One-to-one): Одна строка в таблице А связана только с одной строкой в таблице Б, и наоборот.

Один ко многим (One-to-many): Одна строка в таблице А может быть связана с несколькими строками в таблице Б, но строка в Б связана только с одной строкой в А.

Многие ко многим (Many-to-many): Строка в таблице А может быть связана с несколькими строками в таблице Б, и наоборот. Обычно реализуется через промежуточную таблицу.

Реализация на примере SQL:

Test Run (Тестовый прогон) – это процесс выполнения одного или нескольких тест-кейсов в рамках конкретного тестового цикла (Test Cycle).

Основные характеристики:

Исполнение: Фактическое выполнение шагов тест-кейсов на определенной тестовой среде с конкретными входными данными.

Результат: Фиксация результата выполнения каждого тест-кейса (Passed, Failed, Skipped, Blocked и т.д.).

Отчетность: Сбор данных о прохождении тестов для последующего анализа и формирования отчетов.

Связь: Тестовый прогон всегда связан с определенным тестовым циклом, версией продукта и тестовой средой.

Примерный жизненный цикл тест-кейса в рамках тестового прогона:

Selection: Выбор тест-кейсов для включения в прогон.

Execution: Выполнение шагов тест-кейса.

Status Reporting: Запись статуса выполнения.

Defect Logging (if needed): Создание дефекта при неуспешном прохождении.

Analysis: Анализ результатов прогона.

Closing: Закрытие тестового прогона.

Test Run является фундаментальным понятием в управлении тестированием и позволяет отслеживать прогресс, эффективность и качество тестируемого продукта.

Принцип скопления или кластеризация дефектов (Defect Clustering) — это одно из семи основных принципов тестирования ПО, утверждающее, что небольшое количество модулей или компонентов системы содержит большинство найденных дефектов. Иными словами, дефекты распределены неравномерно.

Это не означает, что нужно тестировать только эти "проблемные" области. Скорее, этот принцип подчеркивает важность анализа истории дефектов и концентрации усилий по тестированию на тех частях системы, где дефекты обнаруживались чаще всего.

Причины кластеризации могут быть разными:

Сложность кода или бизнес-логики модуля.

Частые изменения в компоненте.

Опыт и навыки разработчика, работавшего над модулем.

Недостаточное покрытие тестами ранее.

Применение принципа на практике:

Использование данных из систем отслеживания дефектов (Jira, Azure DevOps и др.) для выявления "горячих" точек.

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

Проведение дополнительного регрессионного тестирования в областях с высокой плотностью дефектов.

Приоритизация автоматизации тестов для таких модулей.

Критерии входа (Entry Criteria) – это набор условий, которые должны быть выполнены до начала определенного этапа тестирования. Они помогают гарантировать, что у нас есть все необходимые ресурсы, готовность продукта и окружение для успешного старта тестирования.

Примеры критериев входа:

Готовность спецификаций: Требования к функциональности зафиксированы и утверждены.

Готовность тест-плана: Разработан и утвержден план тестирования для текущего этапа.

Готовность тестового окружения: Тестовая среда развернута и настроена согласно требованиям.

Готовность тестовых данных: Подготовлены и доступны необходимые тестовые данные.

Качество сборки/версии: Получена стабильная сборка продукта, прошедшая первичные проверки (например, smoke-тестирование).

Отсутствие блокирующих дефектов: critical/blocker дефекты предыдущих этапов тестирования (если применимо) устранены.

Доступность команды: Все участники команды тестирования доступны и готовы начать работу.

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

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

Виды кросс-платформенного тестирования:

Десктопные платформы: Windows, macOS, Linux (разные дистрибутивы).

Мобильные платформы: Android (разные версии и производители устройств), iOS (разные версии и модели iPhone/iPad).

Веб-браузеры: Chrome, Firefox, Safari, Edge (разные версии).

Разрешения экрана и ориентации: Проверка отображения контента и элементов управления при различных разрешениях и в портретной/альбомной ориентации.

Ключевые аспекты:

Функциональность: Проверка выполнения всех функций приложения на каждой платформе.

Визуальное соответствие: Проверка корректного отображения интерфейса, элементов дизайна и контента.

Производительность: Оценка скорости загрузки, отзывчивости и потребления ресурсов на разных платформах.

Юзабилити: Проверка удобства использования приложения на каждой платформе с учетом особенностей управления (мышь, тачскрин).

Безопасность: Проверка уязвимостей на разных платформах.

Инструменты:

Ручное тестирование: Проведение тестов на физических устройствах или виртуальных машинах.

Автоматизированное тестирование: Использование фреймворков и инструментов для автоматизации тестов на различных платформах.

Облачные платформы: Сервисы, предоставляющие доступ к широкому спектру реальных устройств и браузеров для тестирования (например, Sauce Labs, BrowserStack).

Проблемы и вызовы:

Различия в поведении: Одни и те же действия могут приводить к разным результатам на разных платформах.

Фрагментация: Большое количество версий ОС, устройств и разрешений усложняет покрытие тестами.

Сложность настройки окружения: Требуется настройка и поддержка тестовых сред для каждой платформы.

Время и ресурсы: Проведение кросс-платформенного тестирования требует значительных временных и финансовых затрат.

Стратегии и подходы:

Приоритизация платформ: Фокусировка на наиболее популярных или критичных для бизнеса платформах.

Создание матрицы тестирования: Определение комбинаций платформ и функций для тестирования.

Использование виртуализации и облачных сервисов: Сокращение затрат на оборудование и упрощение настройки.

Применение автоматизации: Ускорение процесса тестирования и повышение точности.

Регулярное тестирование: Включение кросс-платформенного тестирования в каждый цикл разработки.

Кросс-платформенное тестирование является важным этапом QA, обеспечивающим качество и единообразный пользовательский опыт для широкой аудитории.

Оператор instanceof используется для проверки, является ли объект экземпляром определенного класса или подкласса, либо реализует ли указанный интерфейс. Он возвращает true, если объект соответствует типу, итерабельный для проверки, иначе false.

Примеры использования:

Логи можно разделить на следующие виды:

Системные логи: Записывают события, связанные с работой операционной системы и аппаратного обеспечения.

Серверные логи: Фиксируют активность веб-серверов, серверов приложений и баз данных (запросы, ошибки, доступ).

Логи приложений: Содержат информацию о работе самого приложения (действия пользователей, ошибки, предупреждения, информационные сообщения).

Логи безопасности/аудита: Отслеживают попытки входа, изменения прав доступа, подозрительную активность для обнаружения и предотвращения инцидентов безопасности.

Логи производительности: Регистрируют метрики производительности системы или приложения (время отклика, использование ЦПУ, памяти).

Логи отладки: Используются разработчиками для выявления и устранения ошибок в коде. Как правило, они содержат очень подробную информацию.

Логи транзакций: Записывают каждую отдельную операцию или транзакцию в системе, например, в базе данных или платежной системе.

Имя хоста (hostname) и порт (port) — это два ключевых компонента, используемые для идентификации и доступа к сетевым ресурсам.

Имя хоста — это уникальный читаемый человеком идентификатор устройства или сервера в сети. Оно может быть:

Полное доменное имя (FQDN): Например, www.google.com, которое включает имя хоста (www) и доменное имя (google.com).

Локальное имя хоста: Например, MyPC или WebServer, используемое в пределах локальной сети.

Система доменных имен (DNS) преобразует имя хоста в IP-адрес, необходимый для маршрутизации данных в сети.

Порт — это числовое значение (от 1 до 65535), используемое для идентификации конкретного процесса или приложения, работающего на сервере. Когда данные приходят на определенный IP-адрес, порт указывает, какое приложение должно обработать эти данные.

Известные порты (1-1023) зарезервированы для стандартных сетевых служб (например, 80 для HTTP, 443 для HTTPS, 22 для SSH).

Зарегистрированные порты (1024-49151) могут быть зарегистрированы организациями для своих приложений.

Динамические/приватные порты (49152-65535) используются временно клиентами при установлении соединения или для специфических приложений.

Комбинация IP-адреса (или имени хоста) и порта однозначно определяет конкретную службу на конкретной машине в сети.

Пример: При запросе веб-страницы http://www.google.com:80/, вы используете:

Имя хоста: www.google.com (которое преобразуется в IP-адрес)

Порт: 80 (стандартный порт для HTTP)

Это указывает на необходимость подключения к веб-серверу (www.google.com) по протоколу HTTP (через порт 80) для получения запрошенной страницы.

Билд — это сборка исходного кода проекта в исполняемое приложение, готовую к тестированию или развертыванию. Результатом билда чаще всего является исполняемый файл, архив или пакет.

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

Дефект — любое несоответствие требуемым характеристикам или ожиданиям пользователя в продукте или процессе.

Баг — специфический тип дефекта в программном обеспечении, вызванный ошибкой в коде или логике программы.

Проще говоря, все баги — дефекты, но не все дефекты — баги. Дефектом может быть, например, отсутствие документации, которое не связано напрямую с ошибкой в коде.

Сборщик мусора — это процесс автоматического управления памятью, который освобождает память, занятую объектами, которые больше не используются программой.

Основные методы работы сборщика мусора:

Счетчик ссылок (Reference Counting):

Каждый объект имеет счетчик, который хранит количество ссылок на него.

При создании ссылки на объект счетчик увеличивается.

При исчезновении ссылки (например, переменная выходит из области видимости) счетчик уменьшается.

Когда счетчик достигает нуля, объект считается недостижимым и его память освобождается.

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

Трассирующий сборщик мусора (Tracing Garbage Collector):

Работает в два этапа: пометка (marking) и сборка (sweeping) или сжатие (compacting).

Этап пометки: Начинается с "корней" (root set) - объектов, которые гарантированно доступны (например, глобальные переменные, объекты на стеке). GC обходит все достижимые из корней объекты, помечая их как "живые".

Этап сборки: GC просматривает всю кучу. Непомеченные объекты считаются "мусором" и их память освобождается.

Этап сжатия (опционально): После сборки GC может перемещать "живые" объекты, чтобы устранить фрагментацию памяти.

Преимущества: Может обрабатывать циклические ссылки.

Недостатки: Может вызывать паузы в выполнении программы (стоп-мир), пока GC работает.

Наиболее распространенные алгоритмы трассирующего сборщика мусора:

Mark-and-Sweep: Помечает живые объекты, затем собирает мусор.

Mark-and-Compact: Помечает живые объекты, затем перемещает их для дефрагментации.

Copying: Делит кучу на две половины. Во время сборки GC копирует живые объекты из одной половины в другую. Затем освобождает всю исходную половину.

Generational: Основан на гипотезе, что большинство объектов умирает молодым. Куча делится на поколения (например, молодое и старое). GC чаще собирает мусор в молодом поколении, что приводит к меньшим паузам.

Конкретный метод работы сборщика мусора зависит от используемого языка программирования и его реализации. Например, Java и C# используют различные варианты трассирующих сборщиков мусора, включая generational. Python традиционно использовал Reference Counting с дополнительным механизмом для обнаружения циклических ссылок, а в более поздних версиях также применяются элементы трассирующей сборки.

Позитивные тесты:

Допустимые символы (латиница, кириллица).

Различная длина (минимальная, максимальная, средняя).

Имя с пробелами (например, двойная фамилия).

Специальные символы, которые могут быть разрешены (например, дефис).

Негативные тесты:

Пустое поле.

Символы, не разрешенные спецификацией (цифры, большинство спецсимволов).

Длина, превышающая максимально допустимую.

Имена, состоящие только из пробелов.

SQL-инъекции и XSS-атаки (при тестировании веб-приложений).

Пустое поле.

Граничные условия:

Минимально допустимая длина (одна буква).

Максимально допустимая длина.

Кросс-браузерное/кросс-платформенное тестирование (для веб/мобильных приложений):

Ввод имени в разных браузерах/на разных устройствах.

Тестирование производительности:

Ввод очень длинного допустимого имени (если это может влиять на производительность).

Тестирование безопасности:

Попытки ввести вредоносные скрипты или команды.

При автоматизации:

При тестировании API:

Отправка запросов с различными значениями поля 'Имя' в теле запроса или URL.

Проверка статусов ответов (200 OK для успешных, 400 Bad Request для некорректных данных и т.п.) и содержимого ответа (сообщения об ошибках).

Идемпотентность — это свойство операции или функции, означающее, что многократное применение этой операции приводит к тому же результату, что и однократное. Состояние системы после повторного выполнения идемпотентной операции не меняется по сравнению с состоянием после первого выполнения.

В контексте программирования:

Примеры идемпотентных операций:

Чтение данных из базы (GET-запрос), если оно не меняет состояние данных.

Обновление записи в базе данных с заданным значением (PUT-запрос к конкретному ресурсу с полным состоянием).

Удаление ресурса (DELETE-запрос). Повторное удаление уже удаленного ресурса приводит к тому же состоянию (ресурс отсутствует).

Инициализация переменной определенным значением.

Примеры неидемпотентных операций:

Добавление новой записи в базу данных (POST-запрос). Повторное выполнение добавит новую запись.

Увеличение счетчика на единицу.

Отправка email.

В контексте тестирования:

Тестирование идемпотентности важно для систем, где возможны повторные вызовы операций, например, при работе с API, распределенными системами или системами сообщений.

Цель тестирования: Убедиться, что повторное выполнение идемпотентной операции не вызывает нежелательных побочных эффектов или изменения состояния системы, кроме того, которое ожидается после первого выполнения.

Методы тестирования:

Выполнение операции N раз (N > 1) и проверка состояния системы и результата после каждого выполнения.

Сравнение состояния системы до и после повторных выполнений операции (после первого успешного).

Проверка логов и метрик на отсутствие аномалий при повторных вызовах.

Примеры тест-кейсов:

Выполнить GET-запрос к ресурсу 5 раз. Убедиться, что данные в ответе идентичны, а состояние ресурса на сервере не изменилось.

Выполнить PUT-запрос на обновление записи. Повторить запрос. Убедиться, что запись в базе данных остается в том же состоянии после второго запроса, что и после первого.

Выполнить DELETE-запрос на удаление ресурса. Повторить запрос. Убедиться, что ресурс отсутствует после первого запроса, и второй запрос возвращает ожидаемый статус (например, 404 Not Found).

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

QUIC (Quick UDP Internet Connections) — это сетевой протокол транспортного уровня, разработанный Google, который работает поверх UDP. Он предназначен для снижения задержек и повышения производительности по сравнению с традиционным TCP.

Основные преимущества QUIC:

Уменьшение задержки установления соединения (handshake): Благодаря интеграции TLS 1.3, первый "рукопожатие" может быть завершено с меньшим количеством RTTs (Round Trip Times), а при повторных подключениях возможно установление 0-RTT.

Устранение Head-of-Line Blocking на уровне потоков: В отличие от TCP, где потеря одного сегмента данных блокирует доставку последующих сегментов для всех потоков, в QUIC потери в одном потоке не влияют на другие потоки в том же соединении.

Улучшенная обработка потери пакетов: Раздельное квитирование (acknowledgement) для каждого потока позволяет быстрее определить потерянные пакеты и ускорить их повторную передачу.

Гибкая конгестионная механика: QUIC позволяет использовать различные алгоритмы контроля перегрузки, которые могут быть адаптированы под конкретные условия сети.

Миграция соединения: Соединение QUIC привязано не к IP-адресу и порту, а к connection ID, что позволяет клиенту менять сетевой интерфейс (например, переключаться между Wi-Fi и мобильной сетью) без прерывания активного соединения.

Встроенное шифрование: Весь трафик QUIC по умолчанию зашифрован с использованием TLS 1.3, что обеспечивает более высокий уровень безопасности и предотвращает возможность посредникам модифицировать протокол.

QUIC используется, в частности, для ускорения доступа к веб-сайтам и сервисам, требующим низкой задержки, например, видеостриминга и онлайн-игр.

В контексте QA, тестирование приложений, использующих QUIC, требует специальных инструментов и подходов для анализа трафика (например, Wireshark с поддержкой расшифровки QUIC), проверки корректности установления соединения, обработки потерь пакетов и работы алгоритмов контроля перегрузки. Также важно тестировать сценарии миграции соединения.

Техника тест-дизайна 'Предугадывание ошибок' (Error Guessing) основана на интуиции, опыте и знаниях тестировщика о возможных дефектах в программном обеспечении. Суть заключается в предположении, где и какие ошибки могут возникнуть, и создании тестов, направленных непосредственно на обнаружение этих предполагаемых дефектов.

Основные аспекты:

Опора на опыт: Тестировщик использует свой предыдущий опыт работы с подобными системами, знание типичных ошибок программирования, уязвимостей и проблем, возникающих при определенных условиях.

Знание приложения: Глубокое понимание функциональности, архитектуры и логики работы тестируемого приложения позволяет предсказать проблемные зоны.

Анализ требований: Изучение документации и требований может выявить неоднозначности, противоречия или пропущенные сценарии, которые могут привести к ошибкам.

Типичные области для тестирования:

Граничные условия.

Обработка некорректных, нулевых или пустых входных данных.

Обработка исключений и ошибок.

Работа с базами данных (ограничения, типы данных, связи).

Поведение при высокой нагрузке или нехватке ресурсов.

Работа с сессиями и авторизацией.

"Злые" пути (негативные сценарии).

Граничные условия.

Примеры предполагаемых ошибок:

Переполнение буфера при вводе длинной строки.

Деление на ноль.

Некорректная обработка даты и времени.

Проблемы конкурентного доступа к ресурсам.

Утечки памяти.

Неправильная обработка спецсимволов.

Техника эффективна для быстрого нахождения критических дефектов, но сильно зависит от квалификации и опыта тестировщика. Она часто используется в комбинации с формальными техниками тест-дизайна для обеспечения более полного покрытия.

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

Цели декомпозиции:

Упрощение понимания: Разделение на мелкие части облегчает анализ и понимание функциональности.

Управление сложностью: Позволяет эффективно планировать, выполнять и отслеживать тестирование.

Повышение тестируемости: Мелкие компоненты проще тестировать изолированно.

Оптимизация ресурсов: Позволяет распределять усилия тестирования более целенаправленно.

Раннее обнаружение дефектов: Тестирование на более низком уровне позволяет выявить проблемы раньше.

Примеры декомпозиции в тестировании:

Функциональная декомпозиция: Разделение системы на отдельные функции или потоки пользователей.

Декомпозиция по компонентам: Разделение на логические или физические модули/сервисы.

Декомпозиция по уровням (слоям): Разделение на уровни представления, бизнес-логики, данных и т.д.

Декомпозиция тестовых случаев: Разделение крупного тестового сценария на более мелкие шаги или предусловия/постусловия.

Применение декомпозиции:

Планирование тестирования: Определение объема тестирования для каждой части.

Проектирование тестовых случаев: Создание точных и сфокусированных тестовых случаев.

Организация тестовых наборов: Группировка тестовых случаев по декомпозированным частям.

Автоматизация тестирования: Разработка автоматизированных тестов для отдельных компонентов или функций.

Декомпозиция является ключевым принципом при организации эффективного и масштабируемого процесса тестирования.

Кэш хранит статические ресурсы веб-сайта (изображения, CSS, JavaScript) для ускорения загрузки при повторных посещениях. Куки хранят небольшие фрагменты данных о пользователе (например, настройки сеанса, авторизация) для персонализации взаимодействия.

Планирование (Planning): Происходит в начале итерации (спринта). Команда выбирает задачи из бэклога продукта на основе их приоритета и оценки. Определяется объем работы на спринт, распределяются задачи между участниками команды. Цель — сформировать четкий план работы на итерацию, определить цели и договориться, что будет готово к концу спринта.

Груминг (Backlog Refinement / Grooming): Длительный, постоянный процесс (может занимать до 10% времени команды), который происходит в течение итерации. Фокусируется на проработке и уточнении элементов бэклога продукта. Обсуждаются пользовательские истории, добавляются детали, уточняются критерии готовности, оценивается сложность. Цель — убедиться, что элементы бэклога достаточно понятны, детализированы и оценены для последующего планирования. Груминг делает планирование более эффективным, так как команда уже знакома с задачами.

Swagger (или Open API) — это спецификация и набор инструментов для проектирования, построения, документирования и использования RESTful веб-сервисов.

Основные компоненты:

Спецификация OpenAPI (OAS): Языково-независимый формат описания RESTful API в виде JSON или YAML. Описывает доступные эндпоинты, параметры, ответы, схемы данных, авторизацию и метаданные.

Swagger UI: Инструмент для визуализации и интерактивного взаимодействия с API, описанным в спецификации OpenAPI. Позволяет просматривать документацию и выполнять запросы прямо из браузера.

Swagger Codegen: Набор инструментов для автоматической генерации серверного кода (скелетов) и клиентских SDK на основе спецификации OpenAPI.

Преимущества использования:

Единая документация: Создает стандартизированную и всегда актуальную документацию для API.

Разработка по контракту: Позволяет командам бэкенда и фронтенда работать параллельно, договорившись о контракте API.

Автоматизация тестирования: Используется для автоматической генерации тестов API (например, с помощью Swagger Inspector).

Обнаружение API: Упрощает поиск и понимание доступных API в системе.

Пример части спецификации в YAML:

Успешное повторное подключение:

Отключить сеть во время активного соединения.

Восстановить сеть.

Проверить автоматическое повторное подключение.

Проверить сохранение состояния (если применимо).

Восстановить сеть.

Неудачное повторное подключение:

Отключить сеть.

Не восстанавливать сеть.

Проверить отображение ошибки или таймаута повторного подключения.

Проверить предлагаемые пользователю действия (повторить попытку, выйти).

Отключить сеть.

Многократные повторные отключения/подключения:

Циклично отключать и включать сеть.

Проверить стабильность повторного подключения при частых изменениях состояния сети.

Изменение IP-адреса:

Отключить сеть.

Изменить IP-адрес на другом конце соединения (если возможно).

Восстановить сеть.

Проверить повторное подключение к новому IP.

Отключить сеть.

Восстановить сеть.

Различные сетевые условия:

Низкая пропускная способность.

Высокая задержка (latency).

Потеря пакетов (packet loss).

Проверить поведение повторного подключения в деградированных сетевых условиях.

Таймаут повторного подключения:

Отключить сеть.

Оставить отключенной дольше времени, заданного для таймаута повторного подключения.

Проверить наступление таймаута и соответствующее действие.

Отключить сеть.

Повторное подключение после длительного простоя:

Оставить соединение активным, но без обмена данными в течение длительного времени.

Отключить сеть.

Восстановить сеть.

Проверить повторное подключение.

Отключить сеть.

Восстановить сеть.

Повторное подключение при высокой нагрузке:

Вызвать высокую нагрузку на сервер/клиент во время активного соединения.

Отключить сеть.

Восстановить сеть.

Проверить производительность и успешность повторного подключения в условиях нагрузки.

Отключить сеть.

Восстановить сеть.

Повторное подключение с неверными учетными данными (если применимо):

Отключить сеть.

Изменить учетные данные на неверные.

Восстановить сеть.

Проверить обработку отказа в повторном подключении из-за неверных данных.

Отключить сеть.

Восстановить сеть.

Повторное подключение после перезапуска приложения/системы:

Закрыть/перезапустить приложение или систему, когда соединение отключено.

Запустить приложение/систему заново.

Проверить попытку повторного подключения при запуске.

Билд - это скомпилированная, собранная и упакованная версия программного обеспечения в определенный момент времени. Он может быть неполным, содержать ошибки и использоваться для внутреннего тестирования.

Релиз - это финальная, протестированная и утвержденная версия программного обеспечения, готовая к поставке конечным пользователям или развертыванию на продакшене. Он проходит через несколько этапов тестирования и контроля качества.

Ключевые отличия:

Блокирующие дефекты в некритичном функционале, который может быть временно отключен или исправлен патчем в кратчайшие сроки без значительного ущерба для бизнеса.

Незначительные дефекты UI/UX (например, опечатки, небольшие отступы), не влияющие на основную функциональность и удобство использования.

Дефекты, обнаруженные в редких сценариях использования, не затрагивающие ключевые бизнес-процессы и имеющие низкую вероятность воспроизведения пользователями.

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

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

Проблемы, которые являются известными ограничениями системы или функционала, четко документированы и согласованы с продуктовой командой и заказчиком как приемлемые на момент релиза.

Эквивалентное разбиение: Разделяю входные данные на классы эквивалентности. Тестирую каждый класс только одним представителем, так как предполагается, что все значения в классе обрабатываются системой одинаково. Снижает количество тест-кейсов при высокой уверенности в покрытии.

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

Таблицы решений: Использую для тестирования функциональности, где поведение системы зависит от комбинации нескольких условий. Каждая строка таблицы представляет собой уникальную комбинацию условий и соответствующий ожидаемый результат. Обеспечивает полное покрытие комбинаций.

Тестирование состояний перехода: Применяю для систем, имеющих конечное число состояний и переходов между ними. Строю диаграмму состояний и тестирую переходы между ними, недопустимые переходы и циклические переходы. Эффективно для тестирования пользовательского интерфейса, рабочих процессов.

Сценарии использования (Use Cases): Описываю взаимодействие пользователя с системой для достижения определенной цели. Тест-кейсы основаны на шагах основного успешного сценария и альтернативных путях (с ошибками или другими исходами). Помогает тестировать систему с точки зрения конечного пользователя.

Попарное тестирование (Pairwise Testing): Использую для систем с большим количеством параметров, когда нет возможности проверить все комбинации. Гарантирует, что каждая пара параметров будет протестирована вместе хотя бы один раз. Снижает количество тест-кейсов по сравнению с полным комбинаторным тестированием.

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

HATEOAS (Hypermedia as the Engine of Application State) — это ограничение архитектуры REST, которое предписывает, что клиент взаимодействует с REST-сервисом полностью через гипермедиа, предоставляемую сервером в ответах.

Вместо того чтобы знать заранее URI всех ресурсов и действий, клиент получает эту информацию в виде ссылок и форм, встроенных в representations ресурсов.

Ключевые аспекты:

Самоописывающие сообщения: Каждое сообщение, отправляемое клиенту, помимо данных, содержит ссылки на связанные ресурсы и доступные действия.

Отсутствие необходимости знать URI заранее: Клиент следует за гипермедиа, чтобы перемещаться по API и выполнять действия. Он знает только начальную точку доступа.

Улучшенная эволюционность: Сервер может изменять URI ресурсов без изменения логики клиента, пока он продолжает предоставлять соответствующие гипермедиа.

Снижение связности клиент-сервер: Клиент меньше зависит от внутренней структуры сервера.

Пример представления ресурса с HATEOAS:

Здесь _links содержит URIs для самого ресурса, возможности отмены заказа и связанного клиента. Клиент, получив это представление, знает, как выполнить эти действия, не имея их URI "зашитыми" в своем коде.

Хотя HATEOAS является ключевым принципом REST, его полное и последовательное применение может быть сложным на практике.

Объектно-ориентированное программирование (ООП) — это методология разработки программного обеспечения, основанная на концепции "объектов", которые сочетают в себе данные (свойства, атрибуты) и функции (методы, поведение) для работы с этими данными.

Основные принципы ООП:

Инкапсуляция: Объединение данных и методов, работающих с этими данными, в единую сущность - объект. Скрытие внутренней реализации от внешнего мира, доступ к данным осуществляется через методы объекта.

Наследование: Возможность создания новых классов (наследников) на основе существующих (родительских), при этом наследники перенимают свойства и методы родителя и могут добавлять свои или изменять унаследованные. Позволяет переиспользовать код и строить иерархии классов.

Полиморфизм: Возможность использования одного интерфейса для представления различных типов данных или объектов. Позволяет вызывать методы с одним и тем же именем у разных объектов, при этом фактическое выполняемое действие будет зависеть от типа объекта.

Абстракция: Выделение существенных характеристик объекта, игнорируя несущественные детали. Создание упрощенных моделей сложных систем.

Преимущества ООП:

Повышение переиспользуемости кода.

Улучшение читаемости и структурированности кода.

Упрощение отладки и модификации.

Более легкая масштабируемость системы.

Недостатки ООП:

Может быть сложнее для понимания и проектирования на начальном этапе.

Может приводить к некоторому overhead (дополнительные накладные расходы).

Матрица устройств (Device Matrix) — это таблица или список, который включает в себя различные устройства, браузеры, операционные системы и их версии, на которых производится тестирование программного обеспечения. Она помогает определить оптимальный набор сред для тестирования, исходя из целевой аудитории продукта, его функциональности и требований.

Основные элементы матрицы устройств:

Устройства: Список физических устройств (смартфоны, планшеты, компьютеры, IoT-устройства) разных производителей и моделей.

Операционные системы: Список операционных систем, установленных на устройствах (например, iOS, Android, Windows, macOS, Linux) с указанием их версий.

Браузеры: Список веб-браузеров (Chrome, Firefox, Safari, Edge) с указанием их версий, которые используются для доступа к веб-приложениям.

Разрешение экрана: Различные разрешения экрана, которые необходимо поддерживать.

Сеть: Типы сетевых подключений (Wi-Fi, Cellular 3G/4G/5G) и их скорость.

Преимущества использования матрицы устройств:

Покрытие: Обеспечивает тестирование на наиболее релевантных для пользователя комбинациях устройств и сред.

Оптимизация: Помогает избежать избыточного тестирования на малоиспользуемых комбинациях, экономя время и ресурсы.

Приоритизация: Позволяет определить приоритет тестирования на наиболее критичных или распространенных средах.

Документация: Служит официальным документом, определяющим scope тестирования на различных средах.

Пример простой матрицы устройств для веб-приложения:

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

Степени серьезности (severity) проблем обычно классифицируются следующим образом:

Blocker (Критическая) — ошибка, которая полностью блокирует работу системы или тестирования. Например, приложение не запускается.

Critical (Серьезная) — ошибка, приводящая к сбоям или потере данных, но есть обходные пути.

Major (Значительная) — ошибка, которая существенно влияет на функциональность, но не блокирует работу.

Minor (Незначительная) — ошибка, которая не мешает работе, но ухудшает пользовательский опыт (например, неправильный текст).

Trivial (Мелкая) — косметические дефекты, опечатки, незначительные визуальные несоответствия.

Эти уровни помогают приоритизировать исправление багов и планировать релизы.

Оценить критичность новых проблем. Определить, какие из них являются шоустопперами для релиза, а какие можно исправить в следующем спринте или патче.

Провести совместный митинг команды разработки, тестирования и продакт-менеджмента для принятия решения о дальнейших действиях. Варианты:

Отложить релиз до исправления критичных проблем.

Выпустить релиз с известными некритичными проблемами, задокументировав их.

Выпустить фикс-версию (патч) сразу после релиза с исправлениями критичных проблем.

Параллельно с принятием решения:

Фокусировать усилия на тестировании критичных частей функционала.

Эффективно коммуницировать о статусе и найденных проблемах. Использовать общие доски задач (Jira, Azure DevOps и др.).

Проанализировать причины постоянного появления новых проблем:

Недостаточное покрытие тестами (ручными или автоматизированными).

Проблемы с процессом разработки (код-ревью, культура написания кода).

Спешка в разработке и тестировании.

Недостаточная спецификация требований.

При необходимости усилить регрессионное тестирование, приоритезируя его. Возможно, потребуются дополнительные ресурсы или перераспределение задач внутри команды тестирования.

Автоматизировать наиболее частые и критичные сценарии регрессии, если это возможно в сжатые сроки.

После релиза провести ретроспективу для выявления и устранения первопричин проблем.

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

CONNECT метод используется HTTP для установления туннеля к серверу, идентифицированному указанным ресурсом. Обычно применяется для SSL/TLS шифрования.

Принцип работы CONNECT:

Клиент отправляет запрос: Клиент (например, браузер) отправляет POST запрос прокси-серверу с методом CONNECT и адресом назначения (hostname:port).CONNECT example.com:443 HTTP/1.1

Host: example.com:443

Прокси устанавливает соединение: Прокси-сервер получает запрос, устанавливает TCP-соединение с указанным сервером назначения (example.com:443).

Прокси отвечает клиенту: Если соединение установлено успешно, прокси отправляет клиенту ответ с кодом состояния 200 OK. Это означает, что туннель готов.HTTP/1.1 200 Connection Established

Установление туннеля: После получения ответа 200 OK, клиент и сервер назначения могут свободно обмениваться данными через установленный прокси-сервером туннель. Прокси в этом случае действует как ретранслятор, просто пересылая данные между клиентом и сервером, не анализируя их содержимое (если это не специализированный HTTPS-прокси с функцией Man-in-the-Middle).

Основные применения:

HTTPS-соединения через прокси: Наиболее распространенный сценарий использования. CONNECT позволяет клиенту установить зашифрованное соединение с HTTPS-сервером через прокси, который сам не может (или не должен) расшифровывать трафик.

Другие протоколы через прокси: Может использоваться для туннелирования других протоколов, работающих поверх TCP, хотя это менее типично.

Преимущества:

Безопасность: Позволяет сохранить сквозное шифрование в HTTPS, даже при использовании прокси.

Простота для прокси: Прокси не нужно понимать специфику протоколов, туннелируемых через CONNECT.

Недостатки:

Увеличенные задержки: Дополнительный шаг установления соединения с прокси может добавить небольшие задержки.

Прокси может блокировать: Некоторые прокси-сервера могут ограничивать или блокировать использование метода CONNECT для определенных портов или адресов.

TCP (Transmission Control Protocol):

Надежный: Гарантирует доставку пакетов, повторную передачу потерянных, сохраняет порядок. Использует подтверждения ( acknowledgments ) и таймеры.

С установлением соединения: Требуется "рукопожатие" (three-way handshake) для начала обмена данными.

Потоковый: Данные передаются как непрерывный поток байтов.

Замедленный: Накладные расходы на установление соединения и гарантии доставки делают его медленнее UDP.

Применение: HTTP/HTTPS, FTP, SMTP, Telnet.

UDP (User Datagram Protocol):

Ненадежный: Не гарантирует доставку, порядок или отсутствие дубликатов.

Без установления соединения: Не требует "рукопожатия".

Дейтаграммный: Данные передаются отдельными пакетами (дейтаграммами).

Быстрый: Низкие накладные расходы обеспечивают высокую скорость.

Применение: DNS, DHCP, потоковое аудио/видео, онлайн-игры.

Механизм работы сессии в веб-приложениях основан на идентификации пользователя между запросами, которые по природе своей без сохранения состояния (stateless).

Процесс обычно выглядит так:

Первый запрос пользователя: Клиент (браузер) отправляет запрос на сервер.

Создание сессии: Сервер получает запрос и, если это первый запрос от данного клиента или сессия еще не создана, генерирует уникальный идентификатор сессии (Session ID).

Хранение данных сессии: Сервер хранит данные, связанные с этим Session ID. Это могут быть данные о пользователе (логин, роль), состояние корзины покупок, настройки и т.д. Хранение может осуществляться на самом сервере (в памяти, файлах) или в отдельном хранилище (база данных, Redis).

Передача Session ID клиенту: Сервер отправляет ответ клиенту, включая Session ID. Наиболее распространенные способы передачи:

Cookie: Сервер устанавливает cookie с Session ID в браузере пользователя. Браузер автоматически отправляет этот cookie с каждым последующим запросом к тому же домену.

URL: Session ID включается в параметры URL (менее безопасный и рекомендуемый метод).

Скрытые поля формы: Session ID помещается в скрытое поле <input type="hidden"> в HTML-форме (используется при отправке форм).

Последующие запросы: Когда клиент отправляет следующий запрос, он включает в него Session ID (например, из cookie).

Идентификация пользователя: Сервер получает запрос, извлекает Session ID и использует его для поиска соответствующих данных сессии. Таким образом, сервер "узнает" пользователя и его предыдущее состояние.

Обновление данных сессии: По мере взаимодействия пользователя с приложением, сервер может изменять или добавлять данные в хранилище сессий, связанные с текущим Session ID.

Завершение сессии: Сессия может быть завершена явно (например, при выходе пользователя) или автоматически по истечении определенного времени неактивности (таймаута сессии). При завершении сессии данные, связанные с Session ID, удаляются с сервера.

Основные компоненты:

Session ID: Уникальный идентификатор сессии.

Серверное хранилище сессий: Место, где хранятся данные, связанные с Session ID.

Механизм передачи Session ID клиенту: Обычно Cookie.

Этот механизм позволяет веб-приложениям поддерживать контекст взаимодействия с каждым пользователем на протяжении его работы с сайтом, несмотря на безстатусный характер протокола HTTP.

Подтверждающее тестирование (Confirmation Testing / Re-testing): Проверка конкретного исправления дефекта, чтобы убедиться, что заявленная проблема решена, а исправление работает корректно. Выполняется после каждого исправления дефекта.

Регрессионное тестирование (Regression Testing): Проверка существующей функциональности программного обеспечения после внесения изменений (исправления дефектов, добавление новых функций, изменения конфигурации), чтобы убедиться, что эти изменения не внесли новые дефекты и не нарушили работу ранее функционировавших частей системы.

Основная разница:

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

С точки зрения архитектуры, приложение может быть:

Клиент-серверным

Трёхзвенным

Микросервисным

Монолитным

Примеры типов приложений:

Десктопные (например, текстовый редактор)

Веб (например, интернет-магазин)

Мобильные (например, мессенджер)

Встраиваемые (например, ПО стиральной машины)

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

Quality Gates — это контрольные точки в процессе разработки ПО, где команда принимает решение о переходе к следующему этапу, основываясь на выполнении определенных критериев качества.

Основные этапы контроля качества или Quality Gates:

Входные критерии (Entry Criteria): Проверка готовности к началу определенного этапа (например, теста). Включает наличие утвержденных требований, тестовой документации, подготовленной тестовой среды.

Выходные критерии (Exit Criteria): Определение условий для завершения определенного этапа (например, тестирования). Часто включает:

Покрытие тестами (структурное и функциональное).

Пройденный процент критических и приоритетных тест-кейсов.

Приемлемое количество и серьезность открытых дефектов.

Прохождение регрессионного тестирования.

Анализ статического кода (Static Code Analysis): Проверка исходного кода на наличие потенциальных ошибок, нарушений стандартов кодирования и уязвимостей с помощью автоматизированных инструментов (SonarQube, Checkstyle). Критерии могут включать:

Отсутствие критических предупреждений.

Допустимый уровень технического долга.

Соответствие правилам форматирования.

Результаты юнит-тестов (Unit Test Results): Проверка покрытия кода юнит-тестами и успешности их прохождения. Критерии:

Заданный процент покрытия кода (например, 80%).

Отсутствие упавших юнит-тестов.

Результаты интеграционного (Integration Test Results) и системного тестирования (System Test Results): Оценка успешности тестов, выполняемых на разных уровнях интеграции. Критерии схожи с Exit Criteria, но применимы к соответствующему уровню тестирования.

Результаты приемочного тестирования (Acceptance Test Results): Проверка соответствия продукта бизнес-требованиям глазами пользователя или заказчика. Критерии:

Успешное прохождение ключевых бизнес-сценариев.

Утверждение продукта заказчиком или представителем бизнеса.

Анализ уязвимостей безопасности (Security Vulnerability Analysis): Проверка продукта на наличие известных уязвимостей с помощью сканеров безопасности (OWASP ZAP, Burp Suite). Критерии:

Отсутствие критических уязвимостей.

Приемлемый уровень уязвимостей средней и низкой критичности.

Анализ производительности (Performance Analysis): Оценка соответствия продукта требованиям по времени отклика, пропускной способности и стабильности под нагрузкой. Критерии:

Соответствие метрикам производительности.

Отсутствие критических проблем при заданных нагрузках.

Проверка документации (Documentation Check): Убеждение в наличии и актуальности необходимой документации (руководства пользователя, техническая документация, тестовые отчеты).

Примеры критериев для Exit Gate тестирования:

Принцип KISS (Keep It Simple, Stupid или Keep It Short and Simple) — это парадигма дизайна и разработки, целью которой является поддержание максимальной простоты системы.

Основные элементы принципа KISS:

Простота: Решения должны быть максимально простыми, без излишней сложности.

Ясность: Код, дизайн и документация должны быть легко понятными.

Избегание избыточности: Не следует добавлять ненужные функции или слои абстракции.

Легкость поддержки: Простые системы легче поддерживать, модифицировать и отлаживать.

Итеративность: Предпочтение отдается небольшим, инкрементальным изменениям перед большими, комплексными.

Минимизация зависимостей: Следует уменьшать взаимосвязи между различными частями системы.

Quality Gate – это набор критериев, которые должны быть выполнены командой перед переходом на следующий этап жизненного цикла разработки или развертывания ПО.

Основные качества контроля (Quality Gates):

Static Code Analysis: Проверка исходного кода на соответствие стандартам кодирования, потенциальные ошибки, уязвимости и "запахи" кода с использованием автоматизированных инструментов (например, SonarQube).

Unit Test Coverage: Определение процента или количества исходного кода, который покрывается автоматизированными модульными тестами. Устанавливается минимальный порог покрытия.

Integration Test Success Rate: Успешность выполнения автоматизированных интеграционных тестов, проверяющих взаимодействие между различными компонентами или модулями системы.

End-to-End (E2E) Test Success Rate: Успешность выполнения сквозных автоматизированных тестов, имитирующих действия конечного пользователя в системе.

Performance Thresholds: Соответствие производительности приложения установленным метрикам (например, время отклика, пропускная способность) по результатам автоматизированных нагрузочных и стресс-тестов.

Security Scan Results: Отсутствие или приемлемый уровень критических и высокоприоритетных уязвимостей, обнаруженных автоматизированными сканерами безопасности (например, SAST, DAST).

Documentation Status: Актуальность и полнота соответствующей технической документации (например, API-документация, пользовательские руководства).

Resolved Defects Rate: Показатель количества исправленных и подтвержденных дефектов за определенный период или долю от общего числа обнаруженных дефектов.

Code Review Completion: Наличие подтверждения о прохождении или завершении процесса ревью кода другими членами команды.

Feature Completeness: Подтверждение реализации функциональности согласно требованиям (часто субъективный критерий, требующий согласования).

Generics (обобщения) — это возможность определить типы данных, которые класс, интерфейс или метод обрабатывает позже, во время использования или компиляции. Это позволяет создавать компоненты, работающие с различными типами данных, сохраняя при этом типобезопасность.

Роль в программировании:

Повторное использование кода: Позволяют писать один алгоритм или структуру данных, которая может работать с любым типом, вместо написания специфического кода для каждого типа.

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

Повышенная производительность: В некоторых языках (например, C#), использование дженериков может избежать упаковки (boxing) и распаковки (unboxing) при работе со структурами значений, что улучшает производительность.

Более чистый и понятный код: Уменьшают количество повторяющегося кода и делают намерения разработчика более ясными.

Пример на Java:

Без дженериков:

С дженериками:

Пример на C#:

Тестирование совместимости – это проверка работоспособности программного продукта в различных средах. Оно гарантирует, что приложение корректно функционирует на разных платформах, в разных браузерах, операционных системах, устройствах, сетях и их комбинациях.

Основные аспекты тестирования совместимости:

Совместимость с браузерами (Browser Compatibility Testing): Проверка работы веб-приложения в разных браузерах (Chrome, Firefox, Safari, Edge и т.д.) и их версиях.

Совместимость с операционными системами (Operating System Compatibility Testing): Проверка работы приложения на разных ОС (Windows, macOS, Linux, Android, iOS) и их версиях.

Совместимость с устройствами (Device Compatibility Testing): Тестирование на различных устройствах (десктопы, ноутбуки, планшеты, смартфоны) с разными разрешениями экрана и характеристиками.

Совместимость с сетью (Network Compatibility Testing): Проверка поведения приложения при различных сетевых условиях (быстрое/медленное соединение, Wi-Fi, 3G/4G/5G).

Совместимость с оборудованием (Hardware Compatibility Testing): Проверка работы приложения с различным периферийным оборудованием (принтеры, сканеры и т.п.).

Совместимость с версиями (Backward/Forward Compatibility Testing): Проверка совместимости новой версии приложения со старыми данными/конфигурациями и наоборот.

Цель тестирования совместимости – выявить дефекты, связанные с окружением, такие как:

Неправильное отображение интерфейса (UI).

Нарушение функциональности.

Проблемы с производительностью.

Ошибки безопасности.

Инструменты для тестирования совместимости могут включать:

Эмуляторы и симуляторы (для мобильных устройств).

Виртуальные машины.

Облачные сервисы для тестирования на реальных устройствах/браузерах (BrowserStack, Sauce Labs).

Инструменты разработчика в браузерах.

Пример таблицы для планирования тестирования совместимости:

Тестирование совместимости является критически важным для обеспечения качества программного продукта в реальных условиях использования.

Guide flow (или Happy Path) — это тестирование наиболее типичного и ожидаемого сценария использования функционала, который представляет собой последовательность шагов без возникновения ошибок или исключительных ситуаций.

Процесс реализации включает:

Определение happy path: Анализ требований и пользовательских историй для выявления основного сценария использования функционала.

Разработка тест-кейсов: Создание подробных шагов test-кейса, описывающих последовательность действий в рамках happy path, ожидаемый результат на каждом шаге и предусловия.

Приоритизация: Присвоение высокого приоритета test-кейсам, покрывающим happy path, поскольку они проверяют базовую работоспособность.

Автоматизация (при возможности): Написание автоматизированных тестов для happy path, так как они выполняются часто и являются стабильными.

Выполнение: Проведение ручного или автоматизированного тестирования happy path на каждой новой сборке или при внесении изменений.

Использование guide flow в тестировании:

Быстрая проверка работоспособности: Позволяет убедиться, что основной функционал работает корректно после развертывания или внесения изменений.

Основа для регрессионного тестирования: Автоматизированные тесты happy path часто включаются в регрессионные наборы для контроля стабильности системы.

Минимизация рисков: Убедившись в работоспособности основного сценария, можно переходить к тестированию менее приоритетных или негативных сценариев.

Упрощение анализа неработающего функционала: Если happy path не проходит, это указывает на серьезные базовые проблемы в системе.

Пример тест-кейса для happy path "Авторизация пользователя":

Название: УСПЕШНАЯ АВТОРИЗАЦИЯ С КОРРЕКТНЫМИ УЧЕТНЫМИ ДАННЫМИ

Предусловия: Зарегистрированный пользователь с логином "user@example.com" и паролем "password123".

Шаги:

Перейти на страницу авторизации.

Ввести "user@example.com" в поле "Электронная почта".

Ввести "password123" в поле "Пароль".

Нажать кнопку "Войти".

Ожидаемый результат: Пользователь успешно авторизован и перенаправлен на главную страницу личного кабинета. Отображается сообщение "Добро пожаловать, User Name!".

Пример автоматизированного теста на Python с использованием Selenium:

Шифрование между браузером и сервером осуществляется c использованием протокола HTTPS, который является надстройкой над HTTP с использованием протоколов SSL/TLS (Secure Sockets Layer / Transport Layer Security).

Процесс установки защищенного соединения (Handshake):

Client Hello: Браузер отправляет серверу сообщение, содержащее поддерживаемые им версии SSL/TLS, список шифровальных алгоритмов (cipher suites), алгоритмы сжатия и случайное число (клиента).

Server Hello: Сервер выбирает наилучшую версию протокола, шифровальный набор и алгоритм сжатия из предложенных браузером, а также генерирует собственное случайное число (сервера) и отправляет их браузеру вместе со своим SSL/TLS-сертификатом.

Authentication: Браузер проверяет сертификат сервера:

Доверенность корневого центра сертификации (Root CA).

Срок действия сертификата.

Соответствие доменного имени в сертификате адресу веб-сайта.

Отсутствие сертификата в списке отозванных (CRL или OCSP).

Premaster Secret: Браузер генерирует случайное число (premaster secret), шифрует его открытым ключом сервера (из сертификата) и отправляет серверу.

Session Key Generation: Оба, браузер и сервер, используют клиентский (Client Random), серверный (Server Random) случайные числа и premaster secret для генерации симметричного сеансового ключа (session key).

Change Cipher Spec: Браузер отправляет серверу сообщение, информирующее о переходе к использованию сгенерированного сеансового ключа для дальнейшей коммуникации.

Finished: Браузер отправляет серверу хэш всех предыдущих сообщений рукопожатия, зашифрованный сеансовым ключом. Это сообщение проверяет корректность рукопожатия.

Change Cipher Spec: Сервер отправляет браузеру сообщение о переходе к зашифрованной связи.

Finished: Сервер отправляет браузеру хэш всех предыдущих сообщений рукопожатия, зашифрованный сеансовым ключом.

После успешного рукопожатия вся последующая передача данных между браузером и сервером происходит с использованием симметричного шифрования на основе сгенерированного сеансового ключа. Симметричное шифрование гораздо производительнее асимметричного, что делает его подходящим для шифрования больших объемов данных.

Применяемые алгоритмы (пример):

Асимметричное шифрование (для обмена сеансовым ключом): RSA, Diffie-Hellman (DH), Elliptic Curve Diffie-Hellman (ECDH).

Симметричное шифрование (для шифрования данных): AES, 3DES, ChaCha20.

Хэширование (для проверки целостности сообщений): SHA-256, SHA-384.

Чекбокс (checkbox) — это элемент графического интерфейса пользователя (GUI), позволяющий выбрать один или несколько пунктов из предложенного списка.

В отличие от радиокнопки, где можно выбрать только один вариант из группы, чекебокс допускает независимый выбор каждого элемента.

Состояние чекбокса:

Не отмечен (Unchecked / Cleared): Состояние по умолчанию, когда пункт не выбран.

Отмечен (Checked / Selected): Состояние, когда пункт выбран пользователем.

Неопределенное (Indeterminate / Mixed): Промежуточное состояние, используемое, например, когда родительский чекбокс представляет группу дочерних, и часть из них отмечена, а часть — нет.

Визуально чекбокс обычно представлен в виде квадрата, который может быть пустым (не отмечен) или содержать галочку/крестик/закрашенный квадрат (отмечен). Рядом с ним располагается текстовая метка, описывающая выбираемый пункт.

Примеры использования:

Выбор дополнительных опций при установке программного обеспечения.

Фильтрация данных в таблицах или списках.

Согласие с условиями пользовательского соглашения (единичный чекбокс).

В HTML чекбокс реализуется тегом <input> с type="checkbox":

При тестировании чекбоксов проверяют:

Правильное переключение состояния (отмечен/не отмечен) при клике.

Сохранение состояния после отправки формы или перезагрузки страницы (если требуется).

Корректность передачи выбранных значений на сервер.

Соответствие связанной метки (label) функцией чекбокса (кликабельность по метке).

Видимость и доступность элемента.

Состояние по умолчанию (checked/unchecked).

Правильное отображение неопределенного состояния (если применимо).

Влияние выбора/снятия отметки с чекбокса на другие элементы интерфейса (например, активация/деактивация кнопки).

Куча (Heap) в контексте программирования — это область динамической памяти, выделяемая во время выполнения программы для хранения объектов, размер которых может быть неизвестен на этапе компиляции.

С точки зрения тестирования, понимание кучи важно для:

Тестирования производительности: Утечки памяти в куче могут приводить к замедлению работы приложения или его краху.

Тестирования стабильности: Переполнение кучи (Heap Overflow) или некорректное управление памятью (например, двойное освобождение) может вызывать ошибки сегментации.

Отладки: Анализ содержимого кучи может помочь выявить причины некорректного состояния объектов или утечек памяти.

Использования инструментов: Профилировщики и инструменты для анализа памяти (вроде Valgrind, Memory Analyzer for Java) активно работают с информацией о куче.

Основные характеристики кучи:

Динамическое выделение: Память выделяется и освобождается явно программистом (например, malloc/free в C/C++) или автоматически сборщиком мусора (например, в Java, Python).

Неупорядоченность: В отличие от стека, элементы в куче не хранятся последовательно; их адреса могут быть разбросаны.

Время жизни: Объекты в куче живут до тех пор, пока на них есть ссылки или пока они явно не освобождены.

Примеры проблем, связанных c кучей, которые могут выявляться при тестировании:

Утечки памяти (Memory Leaks): Выделенная память в куче больше не используется, но не освобождена, что ведет к постепенному исчерпанию доступной памяти.

Двойное освобождение (Double Free): Попытка освободить один и тот же блок памяти в куче несколько раз.

Использование после освобождения (Use After Free): Попытка доступа к памяти в куче после того, как она была освобождена.

Переполнение кучи (Heap Overflow): Запись данных за пределы выделенного блока памяти в куче, что может перезаписать соседние данные или метаинформацию о куче.

Quality Assurance (QA) — это комплекс мероприятий по контролю качества процессов разработки программного обеспечения. Основная цель QA — предотвращение дефектов на всех этапах жизненного цикла продукта. Это включает в себя работу с требованиями, планирование, разработку, тестирование, внедрение и поддержку.

Тестирование — это один из этапов процесса QA. Тестирование представляет собой процесс анализа программного продукта с целью выявления дефектов (отличий фактического поведения от ожидаемого).

Ключевые отличия:

Существует несколько способов перечисления параметров в SQL-запросах, которые помогают предотвратить SQL-инъекции и улучшить читаемость:

Позиционные параметры: Параметры определяются знаком-заполнителем (часто ? или $N) и передаются в функцию выполнения запроса в определенном порядке.

SELECT * FROM users WHERE id = ? AND status = ?;

При выполнении: параметры передаются в массив или список в том же порядке, что и вопросительные знаки.

Именованные параметры: Параметры определяются префиксом (часто : или @) за которым следует имя параметра.

SELECT * FROM products WHERE category = :category_name AND price > :min_price;

При выполнении: параметры передаются в виде словаря или карты, где ключ — имя параметра, а значение — его значение.

Составные параметры (некоторые СУБД и ORM): Позволяют передавать структуры данных или объекты в качестве одного параметра. Это менее универсально и зависимо от конкретной реализации. Например, в PostgreSQL можно использовать JSON.

SELECT * FROM orders WHERE details @> ?; -- details - поле типа JSONB

При выполнении: передается JSON-строка или объект, который СУБД может разобрать.

Выбор способа зависит от используемой СУБД, драйвера/ORM и личных предпочтений. Наиболее распространены позиционные и именованные параметры. Использование параметризованных запросов является стандартной практикой для безопасной работы с базами данных.

Wrapper классы в Java — это классы, предоставляющие объектно-ориентированное представление примитивных типов данных. Они позволяют использовать примитивные значения в контекстах, где требуются объекты, например, в коллекциях или при работе с многопоточностью.

Основные Wrapper классы:

Byte

Short

Integer

Long

Float

Double

Boolean

Character

Примеры использования:

Использование примитива:

Использование Wrapper класса:

Преобразование между примитивами и Wrapper объектами:

Autoboxing: Автоматическое преобразование примитива в Wrapper объект.// Autoboxing

int primitiveInt = 100;

Integer wrapperInt = primitiveInt;

Unboxing: Автоматическое преобразование Wrapper объекта в примитив.// Unboxing

Integer wrapperInteger = new Integer(200);

int primitiveInteger = wrapperInteger;

Преимущества Wrapper классов:

Работа с коллекциями: Коллекции (List, Set, Map) хранят только объекты.

Работа с null: Wrapper объекты могут иметь значение null, в отличие от примитивов.

Предоставление полезных методов: Wrapper классы имеют методы для преобразования строк, сравнения значений и т.д. Например, Integer.parseInt(String s).

Работа с обобщениями (Generics): Обобщения работают только с объектами.

Недостатки Wrapper классов:

Потребление памяти: Wrapper объекты занимают больше памяти, чем примитивы.

Снижение производительности: Автоматическое преобразование (автобоксинг и анбоксинг) может незначительно снижать производительность.

Пример использования в коллекции:

Метод OPTIONS используется для описания параметров связи для целевого ресурса. Он позволяет клиенту определить, какие методы HTTP разрешены для ресурса, какие заголовки запроса могут быть отправлены, и какие заголовки ответа могут быть получены.

Применение:

Проверка разрешенных методов (Allow заголовок).

Определение доступных заголовков (Access-Control-Allow-Headers заголовок в CORS).

Использование в механизмах CORS (пре-запрос).

Пример запроса:

Пример ответа:

Default state: Проверить, в каком состоянии (отмечен/не отмечен) находится чекбокс при загрузке страницы или открытии окна, соответствует ли это спецификации.

Selection/Deselection:

Проверить возможность установить отметку (кликнуть по самому чекбоксу).

Проверить возможность снять отметку (кликнуть по отмеченному чекбоксу).

Проверить возможность установить/снять отметку кликом по связанной метке (<label>).

Visual feedback: Убедиться, что состояние чекбокса визуально меняется при установке/снятии отметки.

Functionality impact: Проверить, как изменение состояния чекбокса влияет на остальную функциональность страницы или приложения (включает/выключает определенные элементы, меняет данные, активирует/деактивирует кнопки и т.д.).

State persistence: Если применимо, проверить сохраняется ли состояние чекбокса после перезагрузки страницы или повторного открытия формы/окна.

Disabled state: Если чекбокс может быть неактивным:

Проверить, что он визуально отличается от активного.

Проверить, что на него нельзя кликнуть (ни на сам чекбокс, ни на метку).

Проверить, что его состояние нельзя изменить.

Required state: Если чекбокс является обязательным:

Проверить, что при попытке отправить форму без его отметки появляется соответствующее сообщение об ошибке.

Group behaviour (Radio/Checkbox Groups): Если чекбоксы являются частью группы:

Checkbox Group: Проверить возможность выбрать несколько чекбоксов. Проверить возможность снять отметку с любого из выбранных.

Radio Group (хоть и не чекбоксы, но схожий контроль): Проверить, что выбор одного элемента автоматически снимает отметку с других в той же группе.

Keyboard navigation: Проверить возможность фокусироваться на чекбоксе с помощью клавиши Tab и изменять его состояние с помощью пробела.

Accessibility: Проверить доступность для пользователей с ограниченными возможностями (например, корректное чтение состояния и метки скринридерами).

Browser compatibility: Проверить корректное отображение и работу в различных браузерах.

Responsiveness: Проверить, как отображается и работает на устройствах с разным размером экрана.

Performance: Убедиться, что изменение состояния чекбокса не вызывает заметных задержек или проблем с производительностью.

Data submission: При отправке формы проверить, что состояние отмеченных чекбоксов корректно передается на сервер.

При автоматизации используются локаторы для элементов (CSS-селекторы, XPath) и методы фреймворка (например, Selenium, Cypress) для кликов и проверки состояний (isSelected(), isChecked(), isEnabled(), getAttribute()).

При перегрузке (overloading) метода или конструктора можно изменить:

Типы параметров: Последовательность и количество параметров могут быть одинаковыми, но хотя бы один тип параметра должен отличаться.

// Пример перегрузки по типу параметра

void print(int i) { }

void print(String s) { }

Количество параметров: Методы или конструкторы с одинаковым именем, но разным количеством параметров.

// Пример перегрузки по количеству параметров

void calculate(int a) { }

void calculate(int a, int b) { }

Порядок параметров (при разных типах): Если имеется несколько параметров, и их типы отличаются, изменение порядка этих параметров создает уникальную сигнатуру.

// Пример перегрузки по порядку параметров (при разных типах)

void process(int a, String s) { }

void process(String s, int a) { }

Что НЕЛЬЗЯ изменить при перегрузке:

Тип возвращаемого значения: Перегруженные методы могут иметь разный тип возвращаемого значения, но это не является достаточным условием для перегрузки. Тип возвращаемого значения игнорируется при определении сигнатуры метода.

// Это не перегрузка

int getValue() { return 0; }

String getValue() { return ""; }

Модификаторы доступа: Модификаторы доступа (public, private, protected, default) не влияют на возможность перегрузки.

Модификаторы non-access: Модификаторы static, final, abstract и другие не влияют на перегрузку.

Пример, иллюстрирующий, что изменение типа возвращаемого значения недостаточно для перегрузки:

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

Оценка сложности алгоритма часто проводится путем анализа количества базовых операций, выполняемых алгоритмом, в зависимости от размера входных данных (n). Асимптотическая сложность описывает поведение алгоритма при увеличении n до бесконечности, игнорируя постоянные множители и младшие члены. Для определения асимптотики используют нотацию "O большое" (O-notation).

Основные шаги:

Выделить базовую операцию: Определить операцию, которая выполняется наиболее часто и ее количество пропорционально общему времени выполнения алгоритма. Это может быть сравнение, присваивание, арифметическая операция и т.д.

Подсчитать количество базовых операций: Выразить количество базовых операций как функцию от размера входных данных n.

Определить асимптотику: Из полученной функции оставить только старший член и отбросить постоянные множители. Это и будет асимптотическая сложность алгоритма в нотации O-notation.

Часто встречающиеся классы асимптотической сложности:

O(1) - постоянная сложность (не зависит от n)

O(log n) - логарифмическая сложность

O(n) - линейная сложность

O(n log n) - линейно-логарифмическая сложность

O(n²) - квадратичная сложность

O(2ⁿ) - экспоненциальная сложность

Примеры:

Поиск элемента в неотсортированном массиве: В худшем случае требуется просмотреть все n элементов. Базовая операция: сравнение. Количество операций: n. Асимптотика: O(n).

Поиск элемента в отсортированном массиве (бинарный поиск): На каждом шаге размер области поиска уменьшается вдвое. Базовая операция: сравнение. Количество операций: log₂ n. Асимптотика: O(log n).

Пузырьковая сортировка: Требуется n-1 проходов, в каждом из которых до n-1 сравнений. Базовая операция: сравнение и обмен. Количество операций: примерно n²/2. Асимптотика: O(n²).

При анализе также учитываются худший, средний и лучший случаи выполнения алгоритма, хотя чаще всего оценивают худший случай.

Открытое бета-тестирование (Open Beta) — это стадия разработки программного продукта, на которой он становится доступен широкой публике для тестирования до официального релиза.

Цели открытого бета-тестирования:

Выявление ошибок и дефектов, которые не были обнаружены на предыдущих стадиях тестирования (альфа, закрытая бета).

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

Тестирование масштабируемости инфраструктуры под нагрузкой большого количества одновременных пользователей.

Оценка готовности продукта к полноценному запуску.

Основные характеристики:

Доступен любому желающему, без приглашений.

Пользователи активно используют продукт в реальных условиях.

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

Продукт может содержать известные дефекты и быть нестабильным. Пользователи предупреждаются об этом.

Преимущества:

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

Получение разнообразной и ценной обратной связи от широкой аудитории.

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

Недостатки:

Негативное впечатление пользователей при столкновении с большим количеством ошибок или нестабильностью.

Необходимость обработки большого объема обратной связи.

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

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

Использование дженериков:

Классы: Создание контейнеров или структур данных, которые могут хранить элементы любого типа.

// Пример generic-класса в Java

class Box<T> {

private T item;

public void setItem(T item) {

this.item = item;

}

public T getItem() {

return item;

}

}

Интерфейсы: Определение контрактов, которые могут быть реализованы для различных типов.

// Пример generic-интерфейса в C#

interface IRepository<T>

{

void Add(T entity);

T GetById(int id);

}

Методы: Создание универсальных функций, способных обрабатывать аргументы разных типов.

# Пример generic-метода (с аннотациями типов) в Python

from typing import TypeVar, List

T = TypeVar('T')

def first_element(items: List[T]) -> T | None:

"""Возвращает первый элемент списка или None, если список пуст."""

if not items:

return None

return items[0]

Преимущества использования дженериков:

Типобезопасность: Компилятор проверяет соответствие типов во время компиляции, предотвращая ошибки времени выполнения, связанные с несовместимостью типов.

Повторное использование кода: Один дженерик класс, интерфейс или метод может работать с множеством типов, сокращая дублирование кода.

Производительность (зависит от языка): В некоторых языках (например, C++) использование дженериков (шаблонов) может привести к более производительному коду по сравнению с использованием базовых типов или Object, так как компилятор может генерировать специализированный код для каждого типа.

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

Абстракция в ООП — это механизм, позволяющий сосредоточиться на существенных характеристиках объекта, скрывая при этом несущественные детали реализации. Она помогает управлять сложностью системы, представляя объекты с точки зрения их поведения и взаимодействия, а не их внутренней структуры.

Основные аспекты абстракции:

Выделение ключевых свойств и поведения: Описываются только те характеристики, которые важны для решаемой задачи.

Сокрытие деталей реализации: Внутреннее устройство объекта скрыто от внешнего мира.

Создание обобщенных моделей: Позволяет работать с объектами через общий интерфейс, независимо от их конкретного типа.

Примеры реализации в языках ООП:

Абстрактные классы: Классы, которые не могут быть инстанцированы напрямую. Могут содержать абстрактные методы, которые должны быть реализованы в классах-наследниках.

// Абстрактный класс Shape

abstract class Shape {

// Абстрактный метод для получения площади

abstract double getArea();

// Обычный метод

void display() {

System.out.println("Это фигура.");

}

}

Интерфейсы: Полностью абстрактные типы, определяющие набор методов без реализации. Служат для определения контракта поведения, который должны соблюдать реализующие классы.

// Интерфейс ILogger

public interface ILogger {

// Метод для логирования сообщения

void Log(string message);

}

Использование модификаторов доступа: private, protected, public помогают контролировать видимость и доступ к членам класса, скрывая внутренние детали.

Абстракция способствует:

Уменьшению сложности: Скрывает ненужные детали, упрощая понимание системы.

Повышению гибкости: Легче изменять внутреннюю реализацию объекта, не затрагивая использующий его код, если сохраняется контракт.

Повторному использованию кода: Абстрактные классы и интерфейсы позволяют создавать обобщенные решения.

В контексте QA, понимание абстракции помогает:

Эффективнее проектировать тестовые сценарии, фокусируясь на поведении, а не на внутренней логизации.

Лучше понимать структуру тестируемого кода и точки взаимодействия между компонентами.

Проектировать более надежные и поддерживаемые автоматизированные тесты.

Для успешного выполнения DDoS-атаки атакующему необходимо знать следующее:

Цель атаки: Адрес (IP, доменное имя), тип сервиса (веб-сервер, игровой сервер, DNS), порт.

Слабые места цели:

Пропускная способность канала связи.

Ограничения по количеству одновременных подключений.

Уязвимости в программном обеспечении (веб-сервер, база данных).

Конфигурация сетевого оборудования (файерволы, балансировщики нагрузки).

Доступные ресурсы для атаки (ботнет):

Количество зараженных устройств (ботов).

Географическое распределение ботов.

Типы каналов связи ботов (домашний интернет, мобильный).

Возможность использования различных протоколов (HTTP, UDP, TCP SYN).

Методы атаки (типы DDoS):

Объемные атаки: UDP Flood, ICMP Flood.

Протокольные атаки: SYN Flood, Fragmented Packet Attack.

Атаки на уровне приложений: HTTP Flood, Slowloris, RUDY.

Инструменты для атаки:

Скрипты и программы для генерации трафика.

Malware для создания ботнетов.

Сервисы для аренды ботнетов (DDoS-for-hire).

Способы сокрытия источника атаки:

Использование прокси-серверов и VPN.

Подмена IP-адресов (спуфинг).

Использование анонимных сетей (Tor).

Планирование и координация атаки:

Время начала атаки.

Продолжительность атаки.

Стратегия атаки (постепенное увеличение трафика, массированный удар).

Координация действий ботов.

Время начала атаки.

Мониторинг и обратная адаптация:

Отслеживание эффективности атаки.

Изменение методов атаки в ответ на меры защиты.

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

Неявное ожидание в Selenium — это глобальная настройка драйвера, которая указывает ему, сколько времени ждать любого элемента, прежде чем выбросить исключение NoSuchElementException. Драйвер будет повторно пытаться найти элемент в течение указанного времени.

Преимущества:

Простота настройки: устанавливается один раз для всего объекта драйвера.

Уменьшает количество NoSuchElementException в случае не мгновенной загрузки элементов.

Недостатки:

Может замедлить выполнение тестов, если ждать приходится часто и по максимальному времени.

Время ожидания применяется ко всем поискам элементов, даже тем, которые не требуют ожидания.

Неэффективно для сложных ожиданий (например, ожидания изменения текста или атрибута).

Применяется следующим образом:

V-образная модель — это методология разработки ПО, представляющая собой расширение каскадной модели. Она подчеркивает взаимосвязь между фазами разработки и фазами тестирования на каждом соответствующем уровне абстракции. Модель имеет V-образную форму, где левая сторона представляет фазы разработки (нисходящий путь), а правая — соответствующие фазы тестирования (восходящий путь).

Фазы V-образной модели:

Левая сторона (Разработка):

Анализ требований (Requirements analysis): Определение и документирование требований пользователя и системы.

Проектирование системы (System Design): Проектирование архитектуры системы на высоком уровне.

Проектирование архитектуры (Architectural Design): Детализация архитектуры системы, определение модулей и их взаимодействия.

Проектирование модулей (Module Design): Детальное проектирование каждого модуля или компонента.

Реализация (Coding): Написание кода согласно проектным документам.

Правая сторона (Тестирование и верификация/валидация):

Модульное тестирование (Unit Testing): Тестирование каждого отдельного модуля кода. Соответствует фазе Реализации. Цель: проверить корректность работы отдельных компонентов.

Интеграционное тестирование (Integration Testing): Тестирование взаимодействия между интегрированными модулями. Соответствует фазе Проектирования модулей и Проектирования архитектуры. Цель: проверить правильность взаимодействия модулей.

Системное тестирование (System Testing): Тестирование всей интегрированной системы на соответствие системным требованиям. Соответствует фазе Проектирования системы. Цель: проверить соответствие системы функциональным и нефункциональным требованиям.

Приемочное тестирование (Acceptance Testing): Тестирование системы конечными пользователями или заказчиком. Соответствует фазе Анализа требований. Цель: проверить, соответствует ли система потребностям бизнеса и ожиданиям пользователей.

Преимущества:

Акцент на тестировании на ранних этапах разработки.

Четкое соответствие между фазами разработки и тестирования.

Улучшенная верификация и валидация продукта.

Легко понять и применять.

Недостатки:

Менее гибкая по сравнению с итеративными моделями.

Не очень подходит для проектов с изменяющимися требованиями.

Трудоемкий процесс, особенно для небольших проектов.

Не учитывает итеративность разработки и Agile-методологии.

V-образная модель подходит для проектов со стабильными и четко определенными требованиями, где риск изменения требований низок.

Тестировал бы в виртуализированной среде, используя Windows с Safari Technology Preview for Windows.

Установка:

Загрузил и установил актуальную версию VirtualBox, VMware или аналогичного гипервизора.

Создал виртуальную машину с установленной операционной системой Windows (например, Windows 10 или 11).

Загрузил и установил Safari Technology Preview for Windows, так как официальный Safari для Windows прекратил свое существование после версии 5.1.7, которая сильно устарела и неактуальна для современного веб-тестирования.

Установка:

Области тестирования:

Базовая функциональность: Загрузка страниц, навигация (вперед/назад), работа закладок, истории, менеджера загрузок.

Отрисовка и CSS: Корректное отображение элементов, верстки, шрифтов, изображений, работа с CSS-свойствами, Flexbox, Grid. Тестирование на разных разрешениях экрана (изменение размера окна).

JavaScript: Работа скриптов, обработка событий, взаимодействие с DOM, AJAX-запросы, работа с современными JS-фреймворками (React, Angular, Vue).

Производительность: Скорость загрузки страниц, потребление памяти и ресурсов процессора при работе с тяжелыми веб-приложениями. Использование инструментов разработчика Safari для анализа.

Совместимость с веб-стандартами: Проверка поддержки HTML5, CSS3, WebGL, SVG и других стандартов.

Безопасность: Проверка работы HTTPS, обработка cookie, межсайтовый скриптинг (XSS) и другие уязвимости (если это в рамках задачи тестирования браузера).

Инструменты разработчика: Проверка их корректной работы (элементы, консоль, отладчик, сеть, производительность).

Расширения: Если есть поддержка расширений в данной версии Safari Technology Preview, тестировал бы их установку и работу (например, блокировщики рекламы, инструменты для разработчиков).

Media: Проверка воспроизведения аудио и видео, работа с WebRTC.

Автоматизация тестирования (при необходимости):

Использовал бы Selenium WebDriver или Playwright с драйверами для Safari.

Написал бы автотесты для ключевых сценариев взаимодействия с веб-приложениями в браузере.

Пример на Python с Playwright:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:

# Запуск браузера Safari

# Safari в Playwright поддерживается через WebKit-драйвер,

# который имитирует поведение Safari.

browser = p.webkit.launch()

page = browser.new_page()

page.goto("https://www.example.com")

# Проверка заголовка страницы

assert page.title() == "Example Domain"

print("Test passed: Title is correct")

browser.close()

Инструменты: Использовал бы встроенные инструменты разработчика Safari, онлайн-сервисы для кросс-браузерного тестирования (если есть возможность интеграции с локальной установкой или для сравнения поведения с другими платформами), тестовые стенды с различными версиями Windows в виртуальной машине.

Важно понимать, что Safari Technology Preview for Windows не является полноценно поддерживаемой версией Safari и может не отражать полностью поведение Safari на macOS и iOS. Основное тестирование Safari проводится на нативных платформах Apple. Тестирование на Windows с Technology Preview скорее исследовательское или для проверки каких-то базовых аспектов отрисовки WebKit на этой ОС.

Идемпотентность означает, что многократное выполнение операции с одинаковыми входными данными приводит к тому же состоянию системы, что и однократное.

Методы обеспечения идемпотентности включают:

Применение уникальных идентификаторов (Idempotency Key): Клиент при каждом запросе отправляет уникальный ключ. Сервер хранит информацию о выполненных запросах с этим ключом и для повторных запросов с тем же ключом возвращает результат первого успешного выполнения, не обрабатывая запрос повторно.

Проверка предусловий: Перед выполнением операции проверяется состояние системы. Если система уже находится в желаемом состоянии, операция не выполняется.

Пример: При попытке создать запись, проверяется, существует ли уже запись с такими же ключевыми параметрами.

Использование версионирования/ETags: При обновлении ресурса клиент включает текущую версию или ETag ресурса. Сервер выполняет обновление только в том случае, если версия/ETag на сервере совпадает с переданной клиентом, что предотвращает повторное обновление устаревших данных.

Транзакционные операции: Группировка нескольких действий в одну транзакцию. Если транзакция прерывается или повторяется, система должна вернуться к исходному состоянию или завершить транзакцию атомарно.

Использование асинхронных очередей с гарантией доставки "один раз": Некоторые системы очередей (например, Kafka с определенными настройками) могут гарантировать доставку сообщений ровно один раз, что помогает избежать дублирования при обработке.

Проверка результатов выполнения: После потенциально неидемпотентной операции, производится проверка, достигнуто ли желаемое состояние. При необходимости, корректирующие действия предпринимаются только если состояние не соответствует требуемому.

Система трекинга багов (Bug Tracking System) — это программное обеспечение для управления процессом обнаружения, отслеживания и устранения дефектов (багов) в программном продукте.

Основные функции:

Регистрация багов: Создание записей о найденных дефектах с подробным описанием, шагами воспроизведения, ожидаемым и фактическим результатом, средой тестирования и прикрепленными файлами (скриншоты, логи).

Присвоение статусов: Управление жизненным циклом бага (например, New, Open, In Progress, Resolved, Closed).

Назначение ответственных: Делегирование багов конкретным участникам команды (разработчикам, тестировщикам).

Приоритезация иSeverity: Определение степени важности и влияния бага на работу продукта.

История изменений: Отслеживание всех изменений, внесенных в запись о баге.

Отчетность и статистика: Генерация отчетов о количестве багов, их статусах, скорости исправления и т.д.

Интеграция: Возможность интеграции с другими инструментами разработки (системы контроля версий, CI/CD).

Примеры популярных систем: Jira, Redmine, Asana, Bugzilla, Trello (может использоваться как простая система трекинга).

Использование системы трекинга багов улучшает коммуникацию в команде, повышает прозрачность процесса разработки и обеспечивает эффективное управление качеством продукта.

Отладка (debug) в контексте логирования — это уровень детализации логов, предназначенный для фиксации информации, полезной разработчикам и тестировщикам в процессе поиска и устранения ошибок.

Логи уровня debug содержат подробные данные о ходе выполнения программы:

Значения переменных в ключевых точках.

Вызовы функций и методов.

Результаты промежуточных операций.

Внутренние состояния компонентов.

Пример использования в коде:

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

Матрица трассируемости — это документ, связывающий требования проекта с соответствующими артефактами разработки, тестирования и документации.

Основные цели:

Проверка покрытия требований тестами.

Выявление недостающих или избыточных тестов.

Обеспечение соответствия продукта требованиям.

Управление изменениями (оценка влияния изменений требований на другие артефакты).

Облегчение аудита и контроля.

Типичная структура матрицы трассируемости:

Типы матриц:

Прямая трассируемость: Отслеживает требования к тестовым сценариям (от "что мы требуем" к "как мы тестируем").

Обратная трассируемость: Отслеживает тестовые сценарии к требованиям (от "что мы тестируем" к "какое требование покрывается").

Двунаправленная трассируемость: Объединяет прямую и обратную трассируемость.

Матрица может быть реализована в различных инструментах: электронные таблицы, системы управления требованиями/тестами (например, Jira + плагины, Azure DevOps, TestRail).

Consumer Driven Contracts (CDC)

Потребитель (клиент) определяет формат и структуру данных, которые ему требуются от поставщика (сервера).

Поставщик создает контракт, основанный на требованиях потребителя, и гарантирует, что он будет соблюдать этот контракт.

Тестирование контракта выполняется на стороне потребителя.

Основные преимущества: снижает связанность между сервисами, позволяет потребителям развиваться независимо от поставщиков.

Недостатки: каждый потребитель может иметь свой контракт, что может привести к большому количеству контрактов для поставщика.

Producer Driven Contracts (PDC)

Поставщик (сервер) определяет формат и структуру данных, которые он предоставляет.

Потребитель (клиент) использует контракт, определенный поставщиком.

Тестирование контракта выполняется на стороне поставщика.

Основные преимущества: единый контракт для всех потребителей, упрощает управление поставщиком.

Недостатки: потребитель должен адаптироваться к контракту поставщика, изменения в контракте поставщика могут затронуть всех потребителей.

Сравнение

CDC лучше подходит для систем с большим количеством разнообразных потребителей и когда важно, чтобы потребители могли развиваться независимо. PDC подходит, когда поставщик имеет сильный контроль над предоставляемыми данными и изменения происходят не так часто.

Для хранения и использования данных, особенно в контексте автоматизации тестов, предпочтительнее использовать API напрямую, а не Postman.

Преимущества использования API напрямую:

Гибкость: Полный контроль над процессом, возможность интеграции с любыми фреймворками и библиотеками.

Масштабируемость: Легче обрабатывать большие объемы данных и сложные сценарии.

Автоматизация: Идеально подходит для написания автоматизированных тестов, которые можно запускать как часть CI/CD пайплайна.

Версионирование: Код с использованием API можно хранить в системах контроля версий (Git).

Модульность: Возможность создавать переиспользуемые функции для работы с данными API.

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

В Postman данные можно хранить в:

Environment (Переменные окружения): Для задания URL, логинов, паролей и других настроек, зависящих от среды выполнения.

Global Variables (Глобальные переменные): Доступны во всех коллекциях.

Collection Variables (Переменные коллекции): Доступны в пределах конкретной коллекции.

Data Files (Файлы данных): Для параметризации запросов (CSV или JSON).

При использовании API напрямую для хранения и использования данных можно задействовать различные подходы в зависимости от языка программирования и тестового фреймворка:

Использование переменных в коде.

Чтение данных из файлов (CSV, JSON, YAML, TXT).

Работа с базами данных.

Получение данных от других сервисов через их API.

Пример получения данных через API на Python с использованием библиотеки requests:

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

Инструмент для определения и запуска многоконтейнерных Docker-приложений. Позволяет описать сервисы, сети и тома в одном YAML-файле и запустить их одной командой.

Основные функции:

Определение нескольких сервисов в одном файле.

Создание и запуск всех сервисов одной командой.

Управление жизненным циклом приложения (запуск, остановка, перезапуск, масштабирование).

Сетевое взаимодействие между контейнерами.

Применение конфигурации на лету.

Пример файла docker-compose.yml:

Команды:

docker-compose up: Запускает контейнеры.

docker-compose down: Останавливает и удаляет контейнеры.

docker-compose build: Собирает образы.

docker-compose ps: Показывает статус запущенных контейнеров.

Преимущества:

Упрощает управление сложными многоконтейнерными приложениями.

Обеспечивает повторяемость развертывания.

Облегчает локальную разработку и тестирование.

Factory Method.

Он позволяет создавать объекты без указания конкретного класса в коде клиента. Это важно для гибкости и расширяемости автотестов, например, при работе с различными браузерами или платформами.

Пример использования в контексте автоматизации:

Предположим, у нас есть интерфейс WebDriverFactory и его реализации для разных браузеров (ChromeWebDriverFactory, FirefoxWebDriverFactory). Factory Method позволяет получить экземпляр нужного драйвера, не прибегая к условным конструкциям (if/else) в тестовом коде.

Преимущества:

Низкая связность: Клиентский код зависит только от интерфейса фабрики, а не от конкретных реализаций.

Расширяемость: Легко добавить поддержку нового браузера, создав новую фабрику и изменив метод getWebDriverFactory.

Изоляция: Логика создания объекта сосредоточена в одном месте (фабрике), что упрощает поддержку.

Техника анализа граничных значений (Boundary Value Analysis, BVA) — это метод тест-дизайна, который основан на предположении, что ошибки часто возникают на границах входных данных или выходных результатов.

Принцип BVA заключается в тестировании значений:

На самой границе допустимого диапазона.

В непосредственной близости от границы (слева и справа, или ниже и выше).

Для диапазона [min, max] тестируются значения min, min+1, max-1, max. Иногда также включают min-1 и max+1 для проверки обработки недопустимых значений.

Пример:

Поле ввода для возраста, допустимый диапазон от 18 до 65 лет.

Тестируемые значения по BVA:

Допустимые: 18, 19, 64, 65

Недопустимые (для проверки ошибок): 17, 66

Эта техника хорошо дополняет технику эквивалентного разбиения (Equivalence Partitioning). Сначала разбиваются данные на классы эквивалентности, а затем в каждом классе (особенно на границах) применяют BVA.

Преимущества BVA:

Высокая вероятность нахождения ошибок, связанных с условиями сравнения (<, >, <=, >=).

Систематический подход к выбору тестовых данных на границах.

Снижение избыточности тестов по сравнению с полным перебором.

Недостатки BVA:

Не всегда применима к нечисловым данным (если не определены четкие "границы").

Не выявляет ошибки, не связанные с граничными условиями.

Контрактное тестирование — это метод тестирования, который проверяет, соответствуют ли каждая пара взаимодействующих сервисов (клиент и провайдер) своему общему "контракту". Контракт описывает формат запросов и ответов, которые сервисы ожидают друг от друга.

Особенности контрактного тестирования микросервисов:

Фокус на взаимодействии: Тестируется не внутренняя логика сервисов, а их способность корректно обмениваться данными.

Выявление расхождений в контрактах: Помогает быстро обнаружить несовместимость версий сервисов или изменения в API, которые ломают интеграцию.

Макеты (Stubs/Mocks): Клиентский тест использует макет провайдера, который возвращает данные согласно контракту. Провайдерский тест верифицирует, что он соответствует контракту, используя данные, записанные клиентским тестом.

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

Инструменты: Существуют специализированные инструменты для контрактного тестирования, например, Pact.

Процесс:

Клиентский тест: Клиентский сервис имитирует запрос к провайдеру и записывает ожидаемый ответ (контракт).

Публикация контракта: Записанный контракт публикуется в центральном репозитории (например, Pact Broker).

Провайдерская верификация: Провайдерский сервис загружает контракт из репозитория и выполняет тесты, чтобы убедиться, что он может ответить согласно контракту.

Преимущества:

Раннее обнаружение ошибок: Проблемы интеграции выявляются на ранних стадиях разработки.

Уменьшение зависимости между командами: Команды могут разрабатывать и развертывать сервисы независимо, полагаясь на контракт.

Снижение необходимости в интеграционном тестировании: Контрактное тестирование заменяет часть интеграционных тестов.

Быстрая обратная связь: Тесты выполняются быстро, обеспечивая оперативное уведомление о поломках контракта.

Пример использования Pact:

Таблица: Сравнение контрактного и интеграционного тестирования

Контрактное тестирование является важной практикой для обеспечения надежности и гибкости микросервисной архитектуры.

Установка/Удаление приложения.

Запуск приложения/Фоновый режим/Восстановление из фона.

Регистрация/Авторизация/Восстановление пароля.

Доступ к ключевым разделам/экранам приложения.

Базовые действия (например, создание/редактирование сущности).

Проверка работоспособности основных функций (согласно ТЗ или здравому смыслу).

Отсутствие критических сбоев (крашей).

Принцип Triple A (Arrange,Act,Assert) помогает структурировать юнит-тесты для повышения их читаемости и поддерживаемости. Он делит каждый тест на три четкие фазы:

Arrange (Подготовка):

В этой фазе настраивается тестовое окружение, инициализируются необходимые объекты, создаются фикстуры, моки или стабы для изоляции тестируемого компонента.

Определяются входные данные для тестируемой функции или метода.

Act (Действие):

Выполняется основное действие, которое необходимо протестировать.

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

Act (Действие):

Assert (Проверка):

Проверяется результат выполнения действия.

Сравнивается ожидаемый результат с фактическим.

Используются методы утверждения (assertions) из тестового фреймворка (например, JUnit, NUnit, pytest) для проверки условий.

Assert (Проверка):

Пример на Python с использованием pytest:

Преимущества использования Triple A:

Читаемость: Структура теста становится более понятной, что облегчает его чтение и понимание.

Поддерживаемость: Ясное разделение фаз упрощает внесение изменений и исправление ошибок в тестах.

Фокус: Каждая фаза концентрируется на своей конкретной задаче, что помогает писать более целенаправленные тесты.

Стандартизация: Внедрение Triple A в коман14бе способствует единообразию в написании тестов.

Mock-объекты используются в юнит-тестах для изоляции тестируемого компонента от его зависимостей, позволяя контролировать поведение этих зависимостей. Postman — это инструмент для ручного или автоматизированного тестирования API, отправки HTTP-запросов и анализа ответов.

В контексте тестирования, сравнение "Mock лучше чем Postman" некорректно, потому что они служат разным целям:

Mock-объекты: Применяются для имитации поведения зависимостей (например, внешних сервисов, баз данных) в автоматизированных юнит-тестах. Это позволяет тестировать логику отдельного компонента без необходимости развертывания или обращения к реальным зависимостям, делая тесты быстрыми, стабильными и изолированными.

Postman: Используется для тестирования API в целом, проверки HTTP-запросов/ответов, автоматизации интеграционных тестов или ручного исследования API. Он работает с реальными запросами к реальным эндпоинтам.

Взамен некорректного сравнения, можно говорить о сферах применения:

Mock-объекты лучше для: Юнит-тестирования, изоляции компонентов, быстрой обратной связи при разработке.

Postman лучше для: Интеграционного тестирования API, ручного исследования API, разработки запросов.

Таким образом, это инструменты из разных категорий тестирования с разными целями.

Объектно-ориентированные базы данных (ООБД) – это тип баз данных, в которых информация хранится в виде объектов, подобных тем, что используются в объектно-ориентированном программировании.

Основные характеристики:

Объекты: Данные представлены как экземпляры классов с атрибутами (данными) и методами (поведениями).

Инкапсуляция: Данные и методы, относящиеся к объекту, связаны и защищены от прямого внешнего доступа.

Наследование: Классы могут наследовать свойства и методы от других классов, формируя иерархию.

Полиморфизм: Объекты разных классов могут отвечать на одно и то же сообщение по-разному.

Ссылочная целостность: Объекты могут ссылаться на другие объекты.

Преимущества:

Более естественное представление сложных, связанных данных.

Удобство работы с объектно-ориентированными языками программирования.

Улучшенная производительность для определенных типов данных (например, мультимедийных).

Недостатки:

Не такой широкий выбор инструментов и поддержки, как у реляционных баз данных.

Сложность миграции существующих реляционных данных.

Не всегда подходят для приложений с простыми структурированными данными и частыми запросами с JOIN.

Примеры: GemStone/S, Versant, Objectivity/DB.

Применение: Системы проектирования (CAD), геоинформационные системы (ГИС), мультимедийные приложения, финансовое моделирование.

В сравнении с реляционными базами данных, которые хранят данные в таблицах со строками и столбцами, ООБД лучше подходят для работы с данными, имеющими сложную, иерархическую или сетевую структуру, где связи между объектами являются ключевыми.

Инструменты разработчика (DevTools) – это набор встроенных в браузер инструментов, используемых веб-разработчиками и QA-инженерами для инспектирования, отладки, анализа производительности и оптимизации веб-страниц и приложений.

Основные возможности:

Просмотр и изменение HTML и CSS: Позволяют в реальном времени изучать и модифицировать структуру DOM и стили элементов.

Отладка JavaScript: Возможность ставить точки останова, пошагово выполнять код, просматривать переменные и стек вызовов.

Мониторинг сетевых запросов: Отображение всех запросов к серверу (файлы, изображения, API), их статуса, времени загрузки и размера.

Анализ производительности: Измерение времени загрузки страницы, профилирование JavaScript, выявление "узких мест".

Проверка доступности: Анализ элементов на соответствие стандартам доступности.

Имитация устройств: Просмотр страницы в различных разрешениях экрана и с имитацией мобильных устройств.

Работа с хранилищем браузера: Просмотр и изменение данных в Local Storage, Session Storage, Cookies.

Консоль: Выполнение команд JavaScript, просмотр логов, ошибок и предупреждений.

Примеры использования в QA:

Просмотр логов ошибок в консоли.

Анализ сетевых запросов для выявления проблем с загрузкой или ответом API.

Изучение DOM для проверки структуры и атрибутов элементов.

Имитация различных устройств для проверки адаптивности интерфейса.

Проверка данных, хранящихся в Local Storage или Cookies.

Принцип Code-On-Demand (Код по требованию) — один из опциональных архитектурных стилей взаимодействия в REST, когда сервер может временно расширять функциональность клиента, передавая ему исполняемый код.

Это позволяет сделать клиент более тонким, перекладывая часть логики на сервер, которая загружается "по требованию" в случае необходимости.

Примеры использования:

JavaScript в веб-приложениях: Сервер отправляет JavaScript-код браузеру, который выполняется на стороне клиента для реализации интерактивности, валидации данных, асинхронных запросов и т.д.

Плагины и расширения: Сервер может предоставить код для расширения функциональности приложения или клиента.

Преимущества:

Уменьшение объема передаваемых данных: Код отправляется только при необходимости его использования.

Гибкость: Сервер может динамически изменять поведение клиента.

Более тонкий клиент: Клиент не нуждается в предварительной реализации всей возможной функциональности.

Недостатки:

Сложность реализации и безопасности: Требуется механизм для надежной передачи и выполнения кода на стороне клиента.

Производительность: Загрузка и выполнение кода может занимать время.

Алгоритм K-ближайших соседей (kNN) — это простой, непараметрический алгоритм машинного обучения, используемый как для классификации, так и для регрессии.

Суть: Относит новый объект (точку данных) к классу, наиболее представленному среди k ближайших к нему объектов в обучающей выборке. Для регрессии predicts значение как среднее/медианное значение k ближайших соседей.

Основные шаги для классификации:

Выбор K: Определить число ближайших соседей (K).

Расчет расстояния: Вычислить расстояние между новым объектом и каждым объектом в обучающей выборке (например, евклидово расстояние).

Поиск K ближайших: Отсортировать объекты по расстоянию и выбрать K ближайших.

Голосование: Определить класс нового объекта на основе мажоритарного голосования среди K ближайших соседей.

Преимущества:

Простота реализации и понимания.

Не требует обучения модели (ленивый алгоритм).

Адаптируется к новым данным по мере их появления.

Недостатки:

Вычислительно затратен при больших объемах данных (на этапе предсказания).

Выбор K и метрики расстояния критически важны.

Чувствителен к масштабу признаков и "проклятию размерности".

Не работает хорошо с категориальными признаками напрямую (требуется кодирование).

Применение:

Распознавание образов.

Рекомендательные системы.

Медицинская диагностика.

Поиск похожих документов.

Извлечение подстроки:

По индексу начала и конца.

По индексу начала и длине.

Извлечение одного символа по индексу.

Поиск и замена:

Поиск первого/последнего вхождения подстроки.

Проверка наличия подстроки.

Замена всех вхождений подстроки.

Удаление подстроки.

Удаление подстроки.

Разбиение и объединение:

Разбиение строки на массив подстрок по разделителю.

Объединение массива строк в одну строку с разделителем.

Преобразование регистра:

Преобразование к верхнему регистру.

Преобразование к нижнему регистру.

Trim (удаление пробелов):

Удаление пробелов в начале и конце строки.

Удаление пробелов только в начале.

Удаление пробелов только в конце.

Форматирование:

Форматирование строк с использованием шаблонов или спецификаторов.

Проверки:

Проверка на пустоту или null.

Проверка на то, является ли строка числовой.

Сравнение:

Посимвольное сравнение строк (с учетом регистра и без).

Примеры методов на разных языках:

Точный набор и синтаксис методов зависит от конкретного языка программирования.

Последовательное тестирование (Serial Testing) — это подход к выполнению тестовых наборов, при котором тесты выполняются по очереди, один за другим. Следующий тест начинается только после полного завершения предыдущего.

Ключевые характеристики:

Выполнение тестов: Тесты запускаются в строго определенной последовательности или в порядке, заданном инструментом/системой.

Зависимость: Тесты могут зависеть от состояния системы, созданного предыдущими тестами, хотя это не обязательное условие.

Ресурсы: Обычно требует меньше вычислительных ресурсов, чем параллельное тестирование, так как задействован только один поток выполнения.

Отладка: Отладка проще, так как легче изолировать причину сбоя, зная, какой тест выполнялся в момент ошибки.

Преимущества:

Простота реализации и настройки.

Легкость отладки.

Подходит для тестов с зависимостями.

Недостатки:

Длительное время выполнения, особенно при большом количестве тестов.

Неэффективное использование доступных ресурсов (многопроцессорных систем).

Пример псевдокода для выполнения тестов последовательно:

Существует несколько общепринятых уровней серьезности дефектов:

Blocker: Дефект блокирует дальнейшую работу с основной функциональностью или всей системой, нет обходных путей. Например, приложение не запускается, невозможно войти в систему.

Critical: Дефект приводит к полной неработоспособности ключевой функциональности, но не блокирует всю систему целиком. Обходных путей обычно нет или они крайне сложны. Например, невозможно оформить заказ в интернет-магазине, не отправляется критически важный отчет.

Major: Дефект нарушает работу важной, но не критической функциональности, либо серьезно ухудшает пользовательский опыт. Возможны обходные пути. Например, некорректное отображение данных в отчете, не работает поиск по определенным параметрам.

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

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

Классификация может варьироваться в зависимости от проекта, компании и используемой методологии разработки. Важно также учитывать приоритет (priority) - срочность исправления дефекта, который может не совпадать с серьезностью.

Получение значения из первого ответа:

В разделе "Tests" первого запроса:

// Парсим JSON ответ

const responseJson = pm.response.json();

// Получаем значение нужного поля (например, id)

const itemId = responseJson.id;

// Устанавливаем переменную окружения или глобальную переменную

pm.environment.set("itemId", itemId);

// Или для глобальной переменной: pm.globals.set("itemId", itemId);

Использование параметра во втором запросе:

Во втором запросе, в URL, теле или заголовках, используйте синтаксис {{variableName}}:

Например, в URL:

GET /api/items/{{itemId}}

При выполнении коллекции или последовательности запросов, Postman автоматически подставит значение переменной "itemId", установленное в первом запросе.

Например, в URL:

Дополнительно: Можно использовать вкладку "Pre-request Script" во втором запросе для более сложной логики перед его выполнением, если это необходимо. Например:

Шифрование как таковое не является прямой функцией алгоритма Диффи-Хеллмана. Его основная цель — безопасный обмен криптографическими ключами по открытому каналу. Далее этот общий секретный ключ может быть использован для симметричного шифрования данных.

Процесс обмена ключами выглядит так:

Выбор общедоступных параметров: Две стороны (Алиса и Боб) договариваются о большом простом числе p и базовом числе g (генераторе циклической группы Zₚ*). g должно быть примитивным корнем по модулю p.

Генерация секретных чисел: Каждая сторона генерирует свое секретное случайное число. Алиса выбирает a, Боб выбирает b. a и b держатся в секрете.

Вычисление публичных ключей:

Алиса вычисляет A = g^a mod p.

Боб вычисляет B = g^b mod p.

A и B являются публичными ключами и могут быть безопасно отправлены по открытому каналу.

Вычисление общего секретного ключа:

Алиса получает B от Боба и вычисляет общий секретный ключ S = B^a mod p.

Боб получает A от Алисы и вычисляет общий секретный ключ S = A^b mod p.

Математически (g^b mod p)^a mod p = g^(b*a) mod p и (g^a mod p)^b mod p = g^(a*b) mod p. Поскольку a*b = b*a, обе стороны вычисляют одинаковое значение S, которое становится их общим секретным ключом.

После успешного обмена ключами, обе стороны могут использовать полученное значение S в качестве ключа для симметричного алгоритма шифрования (например, AES, DES) для последующего шифрования и расшифрования сообщений. Сам Диффи-Хеллман не выполняет шифрование данных. Он решает проблему их безопасного обмена ключами для последующего симметричного шифрования.

Да, у меня есть опыт работы с техническими брендами.

Работал с продуктами в различных технических областях:

Программное обеспечение (веб, мобильные приложения, десктопные)

Аппаратное обеспечение (взаимодействие ПО и устройств)

Корпоративные IT-решения

Телекоммуникации

В рамках этого опыта выполнял следующие задачи:

Создание и выполнение тест-кейсов для проверки функциональности, производительности, безопасности и удобства использования технических продуктов.

Автоматизация тестирования с использованием различных инструментов и фреймворков (Selenium, Appium, Cypress, TestNG, JUnit, Pytest).

Интеграционное и системное тестирование сложных распределенных систем.

Тестирование API с использованием Postman, Swagger, Rest-Assured.

Анализ требований и участие в design-обзорах с точки зрения тестируемости.

Взаимодействие с разработчиками и менеджерами продукта.

Использование систем управления тестами (TestRail, Zephyr) и баг-трекинга (Jira, Azure DevOps).

Например, учавствовал в тестировании платформы для мониторинга серверного оборудования, где требовалось знание основ сетевых протоколов и архитектуры распределенных систем. Или занимался тестированием мобильного приложения крупного телеком-оператора, где важны были особенности работы приложения на различных устройствах и версиях ОС. Этот опыт позволил мне глубже понять специфику тестирования продуктов в высокотехнологичной среде.

Структурированная база данных — это база данных, в которой данные хранятся в строго заданном, предопределенном формате.

Основные характеристики:

Предсказуемая структура: Схема данных (таблицы, столбцы, типы данных, связи) определяется заранее и поддерживает целостность данных.

Реляционные модели: Чаще всего строятся на принципах реляционной модели, где данные представлены в виде таблиц со строками и столбцами.

Формальный язык запросов: Используется язык, такой как SQL (Structured Query Language), для управления и запроса данных.

Легкость доступа и управления: Благодаря четкой структуре, данные легко искать, фильтровать, обновлять и анализировать.

Примеры:

Реляционные базы данных (RDBMS): MySQL, PostgreSQL, Oracle, SQL Server.

Данные в электронных таблицах с фиксированными столбцами.

Данные в формате CSV или XML с жестко определенной структурой.

Основное преимущество для QA: Структурированные данные упрощают тестирование, так как можно четко определить ожидаемые результаты запросов и валидировать целостность данных по предопределенным правилам.

Пример SQL-запроса:

Если в программе S является подтипом T, то объекты типа T в программе могут быть заменены на объекты типа S без нарушения работоспособности программы.

Ключевые моменты:

Сохранение поведения: Подтип должен вести себя так же, как его базовый тип, с точки зрения внешнего наблюдателя.

Инварианты: Инварианты базового класса должны сохраняться в подклассах.

Постусловия: Постусловия (условия, которые должны быть истинны после выполнения метода) подкласса должны быть такими же или более сильными, чем постусловия базового класса.

Предусловия: Предусловия (условия, которые должны быть истинны перед выполнением метода) подкласса должны быть такими же или более слабыми, чем предусловия базового класса.

Пример на Python:

Этот принцип важен для обеспечения корректности наследования и полиморфизма, делая код более надежным и предсказуемым.

STLC (Software Testing Life Cycle) — это последовательность этапов, выполняемых в процессе тестирования программного обеспечения для обеспечения качества продукта. Это структурированный подход, гарантирующий, что тестирование проводится систематически и эффективно.

Основные этапы STLC:

Анализ требований: Изучение функциональных и нефункциональных требований к ПО для понимания области тестирования.

Планирование тестирования: Определение стратегии тестирования, целей, ресурсов, сроков и оценки усилий.

Разработка тест-кейсов: Создание подробных тест-кейсов на основе проанализированных требований.

Настройка тестового окружения: Подготовка необходимой среды (оборудование, ПО, данные) для выполнения тестирования.

Выполнение тестирования: Запуск тест-кейсов, фиксация результатов и обнаружение дефектов.

Завершение цикла тестирования: Подготовка отчетов, анализ результатов, закрытие дефектов и подведение итогов.

STLC помогает гарантировать, что тестирование проводится всесторонне и эффективно, что в свою очередь приводит к более качественному программному продукту.

Массив хранит коллекцию элементов одного типа данных, расположенных в непрерывной области памяти. Доступ к элементам осуществляется по индексу.

Критерии завершения тестирования определяют готовность продукта к выпуску или следующему этапу разработки. Основные критерии включают:

Покрытие тестами: Определенный процент кода, требований или функционала покрыт тестовыми случаями.

Стабильность дефектов: Скорость нахождения новых дефектов снижается до минимального уровня.

Плотность дефектов: Количество открытых дефектов определенного типа (например, блокирующих, критических) упало ниже установленного порога.

Статус тестовых случаев: Большой процент (например, > 95%) выполненных тестовых случаев имеет статус "Пройден" (Passed).

Результаты приемочного тестирования: Пройдены необходимые раунды приемочного тестирования, возможно, с участием заказчика или конечных пользователей.

Отсутствие блокирующих дефектов: Нет открытых дефектов, которые阻нокируют ключевые функции продукта или делают его неиспользуемым.

Соответствие требованиям: Продукт в целом соответствует спецификациям и функциональным требованиям.

Покрытие автоматизацией: Определенный набор регрессионных тестов автоматизирован.

Дополнительные критерии могут включать:

Выполнение всех запланированных циклов тестирования (регрессионное, интеграционное, нагрузочное и т.д.).

Получение положительных отзывов от заинтересованных сторон (например, Product Owner'а, руководства).

Наличие необходимой документации (отчеты о тестировании, user guides).

Критерии завершения всегда должны быть определены заранее и согласованы командой и заинтересованными сторонами.

Критический набор тестов (Critical Path Test Suite, CPTS) фокусируется на проверке самой важной и часто используемой функциональности приложения. Его включают:

Проверка авторизации/аутентификации (login, logout, регистрация).

Основные сценарии использования продукта, отражающие ключевые бизнес-процессы. Например, для интернет-магазина: поиск товара -> добавление в корзину -> оформление заказа -> оплата -> отслеживание статуса.

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

Валидация критических форм и ввода данных.

Проверка основных интеграций с внешними системами, если они критичны для работы продукта.

Тестирование критических ограничений (например, невозможность создать заказ без товара).

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

Цель CPTS — быстро подтвердить, что основные функции работают корректно и приложение в целом готово к более глубокому тестированию или выпуску, минимизируя риск блокирующих дефектов.

В теории, уникальных MAC-адресов существует $2^{48}$, что составляет число порядка $2.81 \times 10^{14}$.

На практике, количество используемых MAC-адресов ограничено производителями сетевых устройств (EUI-48 стандарта), каждый из которых получает диапазон адресов.

В конкретной системе (например, компьютере) может быть несколько MAC-адресов, по одному на каждый сетевой интерфейс:

Ethernet-порт

Wi-Fi адаптер

Bluetooth-адаптер

Виртуальные сетевые интерфейсы (для виртуальных машин, VPN и т.д.)

Таким образом, количество MAC-адресов в системе зависит от количества и типа установленных сетевых адаптеров.

Тестирование на восстановление после сбоев (Failover Testing) — это тип нефункционального тестирования, который проверяет способность системы или приложения автоматически переключаться на резервный компонент (сервер, базу данных и т.д.) в случае отказа основного.

Основная цель: обеспечить непрерывность работы и доступность системы в нештатных ситуациях.

Проверяемые аспекты:

Время переключения: Насколько быстро система обнаруживает сбой и переключается на резерв.

Потеря данных: Минимизация или полное отсутствие потери данных при переключении.

Целостность данных: Сохранение целостности данных после переподключения к резервному узлу.

Функциональность: Корректная работа всех функций приложения после переключения.

Нагрузка: Способность резервного компонента справляться с текущей нагрузкой.

Сценарии сбоев включают:

Отказ сервера.

Отказ сетевого соединения.

Отказ базы данных.

Отказ отдельного сервиса/компонента.

Примеры тестов:

Имитация отключения основного сервера при активной пользовательской сессии. Ожидается автоматический переход на резервный сервер без прерывания сессии (или с минимальной потерей прогресса).

Имитация отказа основной базы данных во время транзакции. Ожидается корректное завершение транзакции на резервной базе данных.

Failover тестирование часто проводится в тестовых средах, максимально приближенных к продакшену, и может требовать использования специализированных инструментов для имитации сбоев.

Обертки (Wrapper классы) используются для следующих целей:

Преобразование примитивных типов в объекты: В Java и других языках, где есть примитивные типы данных (int, boolean, float и др.) и объекты, обертки позволяют работать с примитивами как с объектами. Это необходимо, например, для использования их в коллекциях (List, Map), которые хранят только объекты.

Предоставление дополнительных методов: Классы-обертки часто предоставляют полезные методы для работы с соответствующими примитивными типами. Например, Integer имеет методы для парсинга строк в числа, преобразования в различные системы счисления и т.д.

Обработка null значений: Объекты-обертки могут хранить null, что невозможно для примитивных типов. Это важно при работе с базами данных или внешними источниками данных, где поля могут быть пустыми.

Дженерики: При работе с дженериками (например, List<Integer>, Map<String, Boolean>) требуется использовать классы, а не примитивные типы. Обертки позволяют использовать параметризованные типы с примитивными значениями.

Автоупаковка и автораспаковка (Autoboxing/Unboxing): В Java существует механизм автоматического преобразования между примитивными типами и соответствующими им классами-обертками, что упрощает написание кода.

Создание неизменяемых объектов: Обертки часто используются для создания неизменяемых представлений примитивных типов. Например, объекты класса String или классы-обертки для примитивов являются неизменяемыми.

Использование в потоках ввода/вывода: Некоторые потоки ввода/вывода (например, ObjectOutputStream) работают только с объектами, что требует использования оберток для записи примитивных данных.

Chrome DevTools — это встроенный в браузер набор инструментов для веб-разработки и отладки.

Основные панели:

Elements: Просмотр и рефакторинг HTML-структуры страницы и стилей CSS в реальном времени.

Console: Вывод логов, выполнение JavaScript-кода, отладка.

Sources: Отладка JavaScript-кода с помощью точек останова, профилирование производительности.

Network: Мониторинг сетевых запросов (HTTP/HTTPS), анализ их времени выполнения и содержимого.

Performance: Анализ производительности загрузки и выполнения кода страницы.

Memory: Профилирование использования памяти, выявление утечек.

Application: Исследование ресурсов приложения — хранилище (Local Storage, Session Storage, IndexedDB), куки, кэш.

Security: Анализ безопасности страницы, включая проверку сертификатов SSL.

Lighthouse: Аудит веб-страницы по критериям производительности, доступности, SEO и передовым практикам.

Использование в QA:

Проверка UI/UX: Анализ стилей (Elements), адаптивности (Toggle device toolbar).

Отладка фронтенда: Выявление ошибок в JavaScript (Console, Sources).

Анализ API-взаимодействий: Мониторинг запросов и ответов (Network).

Проверка производительности: Оценка времени загрузки и выполнения скриптов (Performance).

Исследование хранилищ: Проверка Local Storage, куки и т.д. (Application).

Симуляция устройств: Тестирование на разных размерах экрана и сетевых условиях (Network – Throttling).

HATEOAS (Hypermedia as the Engine of Application State) — ключевой принцип RESTful-сервисов. Он предполагает, что клиент должен переходить между состояниями приложения исключительно через гипермедийные ссылки, предоставляемые сервером в ответах. Это делает API самообнаруживаемым и менее жестко связанным с конкретными URL-адресами, повышая его гибкость и масштабируемость.

Представим, что мы получаем информацию о заказе. Без HATEOAS ответ может выглядеть так:

Для выполнения действий с этим заказом (например, оплаты или отмены) клиент должен знать соответствующие URL-адреса и методы HTTP заранее.

С применением HATEOAS сервер включает в ответ ссылки на доступные действия:

Теперь клиент, получив этот ответ, видит доступные действия (pay, cancel) и URL к ним, не имея предварительных знаний о структуре API. Если сервер решит изменить URL для оплаты, клиент получит обновленную ссылку в ответе и сможет продолжить работу без необходимости изменения своего кода.

Преимущества HATEOAS:

Гибкость: API становится менее жестко связанным с конкретными URL. Изменения в структуре или URL не требуют перекодирования клиента.

Самообнаруживаемость: Клиент может исследовать API, просто следуя ссылкам в ответах.

Эволюция API: Сервер может добавлять новые возможности (новые ссылки) или удалять старые, и клиент сможет адаптироваться.

Недостатки HATEOAS:

Усложнение реализации: Серверу необходимо генерировать и включать ссылки в каждый ответ, что может быть сложнее реализовать.

Более объемные ответы: Ответы становятся больше из-за включения гипермедийных ссылок.

Клиентская сложность: Клиентская логика должна быть адаптирована для обработки и следования гипермедийным ссылкам.

В QA / QA Automation, тестирование API, использующего HATEOAS, требует особого подхода. Вместо жесткого задания URL-адресов в тестах, необходимо извлекать ссылки из ответов и использовать их для последующих запросов. Это делает тесты более устойчивыми к изменениям в API. Например, в автоматизированных тестах на Java с использованием RestAssured:

Таким образом, HATEOAS является важным принципом для создания по-настоящему RESTful API, повышающим гибкость и удобство использования. Для тестировщиков это означает необходимость адаптации стратегий тестирования для работы с динамическими гипермедийными ссылками.

Стандартная продолжительность спринтов в гибких методологиях разработки (например, Scrum) обычно составляет от 1 до 4 недель. Наиболее распространенная и рекомендуемая продолжительность — 2 недели.

Выбор продолжительности зависит от следующих факторов:

Размер команды: Большие команды могут предпочесть более короткие спринты для лучшей синхронизации.

Сложность продукта: Более сложные продукты могут требовать более длинных спринтов для завершения значимых объемов работы.

Стабильность требований: При частых изменениях требований более короткие спринты позволяют быстрее реагировать.

Необходимая скорость обратной связи: Короткие спринты обеспечивают более частую обратную связь с заказчиком и стейкхолдерами.

Продолжительность спринта определяется командой и Product Owner'ом и должна быть фиксированной на протяжении всего проекта или до тех пор, пока изменения не станут критически необходимыми.

Оператор UNION объединяет результаты двух или более инструкций SELECT.

Он сравнивает и объединяет строки из результирующих наборов. Для успешного использования UNION:

Количество столбцов в каждой инструкции SELECT должно быть одинаковым.

Типы данных соответствующих столбцов в каждой инструкции SELECT должны быть совместимыми (хотя не обязательно идентичными). Например, можно объединять INT и FLOAT, но не INT и BLOB.

UNION по умолчанию удаляет дублирующиеся строки из объединенного результата. Для включения дубликатов используется UNION ALL.

Пример:

Пример с UNION ALL:

Поле — это переменная, объявленная внутри класса, но вне любого метода. Поля определяют свойства объекта класса.

Переменная — это любое место в памяти, выделенное для хранения данных определенного типа. Переменные могут быть:

Полями (field): объявлены на уровне класса.

Локальными переменными (local variable): объявлены внутри метода, конструктора или блока.

Параметрами методов (method parameter): объявлены в сигнатуре метода.

Главное отличие: область видимости и время жизни. Поля принадлежат объекту (для нестатических) или классу (для статических) и существуют на протяжении их жизненного цикла. Локальные переменные и параметры методов существуют только внутри блока, в котором они объявлены, и уничтожаются после выхода из него.

Пример:

F# - это многопарадигменный язык, но его основу составляет функциональное программирование. Это означает, что программы в F# строятся преимущественно вокруг функций, которые являются "чистыми" - не имеют побочных эффектов и всегда возвращают один и тот же результат при одинаковых входных данных. Основные концепции включают:

Неизменяемость (Immutability): По умолчанию данные в F# неизменяемы. Переменные являются связываниями (bindings), и их значения нельзя изменить после создания. Это упрощает рассуждения о программе и повышает безопасность в многопоточных средах.

Функции как первоклассные объекты: Функции можно присваивать переменным, передавать как аргументы другим функциям и возвращать из функций.

Каррирование (Currying): Функции в F# принимают только один аргумент. Функции, принимающие несколько аргументов, автоматически преобразуются в последовательность функций, каждая из которых принимает один аргумент.

Сопоставление с образцом (Pattern Matching): Мощная конструкция для декомпозиции данных и выполнения действий в зависимости от их структуры.

Вывод типов (Type Inference): Компилятор F# может автоматически определять типы большинства выражений, что уменьшает необходимость явного указания типов.

Выражения (Expressions): Большинство конструкций в F# являются выражениями, которые возвращают значение. Это позволяет строить более лаконичный код.

F# активно использует алгебраические типы данных (ATDs):

Записи (Records): Неизменяемые типы данных с именованными полями.

Дискриминированные объединения (Discriminated Unions): Типы данных, представляющие одно из нескольких возможных значений, каждое из которых может иметь связанные данные. Используются для моделирования конечного числа возможных состояний или вариантов.

Функциональный подход в F# способствует созданию модульных, легко тестируемых и параллелизуемых программ.

Тест G-unit не является стандартным или общепринятым термином в области тестирования программного обеспечения. Возможно, это опечатка или специфичное внутреннее обозначение в какой-либо компании или проекте.

Наиболее близкие и широко используемые понятия:

Unit Test (Модульный тест): Тестирование наименьшей тестируемой части приложения (модуля, класса, функции) изолированно от остальных компонентов. Цель — убедиться, что каждый отдельный блок работает корректно.

Google Test (GTest): Популярный open-source фреймворк для написания C++ Unit Tests, разработанный Google. Возможно, "G-unit тест" относится к тестам, написанным с использованием GTest.

Если речь идет о Google Test, то его ключевые особенности:

Поддержка различных платформ.

Богатый набор макросов для утверждений (assertions).

Возможность параметризованных тестов.

Обнаружение утечек памяти.

Интеграция с различными системами сборки.

Пример кода с использованием GTest:

Без дополнительного контекста сложно точно определить, что подразумевается под "G-unit тестом". Если это специфический термин в данной компании, потребуется уточнение его значения. Вероятнее всего, речь идет либо о модульных тестах в целом, либо о тестах, написанных на фреймворке Google Test.

Подзапрос (или вложенный запрос) в SQL — это запрос SELECT, вставленный внутрь другого оператора SQL (SELECT, INSERT, UPDATE, DELETE, CREATE TABLE). Подзапрос выполняется первым, и его результат используется внешним запросом.

Использование:

В предложении WHERE для фильтрации данных.

В предложении FROM как виртуальная таблица (производная таблица).

В предложении SELECT для вывода агрегированных или связанных данных (скалярный подзапрос).

С операторами IN, EXISTS, ANY, ALL.

Использование:

Преимущества:

Позволяют выполнять сложные выборки данных.

Улучшают читаемость запросов по сравнению со сложными соединениями.

Могут использоваться в качестве источника данных.

Преимущества:

Типы:

Скалярный: Возвращает одно значение (одну строку и один столбец).

Многострочный: Возвращает один столбец и несколько строк. Используется с IN, ANY, ALL.

Многоколоночный: Возвращает несколько столбцов. Используется редко.

Коррелированный: Зависит от внешнего запроса и выполняется для каждой строки внешнего запроса.

Типы:

Пример использования в WHERE:

Пример использования в FROM:

Веб-приложения:

Архитектура: Клиент-серверная. Тестирование API (REST/SOAP), тестирование пользовательского интерфейса в различных браузерах и устройствах.

Технологии: HTTP/HTTPS, HTML, CSS, JavaScript, фреймворки (React, Angular, Vue).

Особенности: Межбраузерность, адаптивность, производительность (скорость загрузки, отклик), безопасность (CSRF, XSS), тестирование на различных разрешениях экрана, обработка сессий.

Мобильные приложения:

Типы: Нативные (Android, iOS), гибридные, веб.

Платформы: iOS, Android (множество устройств, версий ОС).

Особенности: Зависимость от аппаратного обеспечения (камера, GPS, датчики), тестирование в различных условиях сети (2G, 3G, 4G, Wi-Fi), тестирование прерываний (звонок, SMS), тестирование на разных ориентациях экрана, автономный режим, тестирование уведомлений, управление жестами.

Десктопные приложения:

Архитектура: Часто толстый клиент.

Платформы: Windows, macOS, Linux.

Особенности: Инсталляция/деинсталляция, тестирование совместимости с различными версиями ОС, тестирование взаимодействия с другими приложениями, тестирование доступа к файловой системе и периферийным устройствам.

REST/SOAP API:

Архитектура: Сервисная.

Особенности: Тестирование конечных точек с различными методами (GET, POST, PUT, DELETE), проверка структуры и содержания ответов (JSON, XML), тестирование кодов состояния HTTP, тестирование авторизации и аутентификации, нагрузочное тестирование API. Инструменты: Postman, SoapUI, Rest Assured.

Микросервисы:

Архитектура: Распределенная.

Особенности: Тестирование взаимодействия между сервисами, тестирование устойчивости (fault tolerance), трассировка запросов, тестирование контрактов, автоматизация тестирования на уровне сервисов.

Встроенные системы (Embedded systems):

Особенности: Ограниченные ресурсы (память, процессор), взаимодействие с аппаратным обеспечением, тестирование реального времени, тестирование в суровых условиях (температура, вибрация). Требует специфического оборудования и инструментов.

Базы данных:

Типы: Реляционные (SQL), NoSQL.

Особенности: Тестирование целостности данных, тестирование производительности запросов, тестирование безопасности данных, тестирование резервного копирования и восстановления.

Различия в технических аспектах тестирования:

Гонка данных (Race Conditions): Несколько потоков одновременно обращаются к общим данным, и порядок доступа влияет на результат.

Взаимная блокировка (Deadlock): Два или более потока ожидают освобождения ресурсов, занятых другими потоками, входящими в ту же группу ожидания.

Старвация (Starvation): Поток с низким приоритетом или неблагоприятным расписанием постоянно не может получить доступ к нужным ресурсам, в то время как другие потоки их используют.

Тестирование и отладка: Параллельные системы сложнее отлаживать из-за непредсказуемого порядка выполнения потоков и зависимости результатов от времени.

Нагрузка на ресурсы: Чрезмерное количество потоков может привести к высокому потреблению памяти, CPU и повышенному накладным расходам на переключение контекста.

Недетерминированность: Результаты выполнения параллельной программы могут отличаться при каждом запуске из-за различных порядков выполнения потоков. Это усложняет воспроизведение ошибок.

Разделение данных и синхронизация: Корректное разделение данных и использование механизмов синхронизации (мьютексы, семафоры, барьеры) необходимо для предотвращения проблем, но их некорректное применение может вызвать другие сложности.

Масштабируемость: Эффективное использование параллелизма на большем количестве ядер / процессоров не всегда линейно масштабирует производительность из-за накладных расходов на синхронизацию и координацию.

Накладные расходы на создание и управление потоками: Создание, запуск и завершение потоков требует некоторого времени и ресурсов.

Совместимость с библиотеками и фреймворками: Некоторые библиотеки не являются потокобезопасными, что требует дополнительной осторожности при их использовании в параллельном коде.

А если вопрос прозвучит не так, как вы готовились?

Так бывает чаще всего. ИзиСобес слышит вопрос интервьюера и подсказывает ответ прямо во время разговора — его не видно ни в Zoom, ни при демонстрации экрана.

Посмотреть ИзиСобес