Тестировщик | Вопросы собесов

🤔 Что такое статические переменные? Статическая переменная — это переменная, значение которой сохраняется между вызовами функции или существования класса. В разных языках программирования она работает по-разному, но общий смысл — она общая для всех экземпляров и хранит свое значение в одном месте в памяти. 🟠В Java (статические переменные в классах) В Java статическая переменная объявляется с ключевым словом static внутри класса. Она принадлежит самому классу, а не его объектам. class Counter { static int count = 0; // Статическая переменная Counter() { count++; // Увеличиваем значение } void showCount() { System.out.println("Общее количество объектов: " + count); } } public class Main { public static void main(String[] args) { Counter obj1 = new Counter(); Counter obj2 = new Counter(); Counter obj3 = new Counter(); obj1.showCount(); // Выведет: Общее количество объектов: 3 } } 🟠В C (статические переменные в функциях и файлах) В C и С++ статическая переменная объявляется с static, но работает немного по-другому #include <stdio.h> void counter() { static int count = 0; // Значение сохраняется между вызовами count++; printf("Count: %d\n", count); } int main() { counter(); // Count: 1 counter(); // Count: 2 counter(); // Count: 3 return 0; } Внутри файла (ограниченная область видимости) static int secretValue = 42; // Эта переменная доступна только в этом файле 🟠В Python (статические переменные в классах) В Python нет ключевого слова static, но аналог статической переменной — переменная класса. class Counter: count = 0 # Это статическая переменная def __init__(self): Counter.count += 1 print(Counter.count) # 0 a = Counter() b = Counter() print(Counter.count) # 2 🟠В JavaScript (через замыкания и свойства класса) В JavaScript можно создать статическую переменную с помощью static внутри класса class Counter { static count = 0; // Статическая переменная constructor() { Counter.count++; } static getCount() { return Counter.count; } } new Counter(); new Counter(); console.log(Counter.getCount()); // 2 Ставь 👍 и забирай 📚 Базу знаний

🤔 Что лучше Postman или полноценный фреймворк? Выбор между Postman и полноценным фреймворком для API-тестирования (например, RestAssured, JMeter, Cypress, Karate) зависит от задач и масштаба тестирования. Давайте разберем, когда лучше использовать Postman, а когда стоит писать тесты в коде. 🚩Когда Postman — хороший выбор? Это удобный инструмент с графическим интерфейсом для тестирования API. Подходит для ручного тестирования и быстрого создания автотестов. 🚩Плюсы Postman ➕ Простота не требует программирования, удобный UI. ➕Автоматизация есть встроенный JavaScript для тестов (pm.test). ➕Коллекции можно сохранять запросы и запускать их пакетами. ➕Интеграции Postman поддерживает CI/CD, Newman, экспорт в другие форматы. 🚩Минусы Postman ➖Медленный при больших тестах сложно поддерживать сотни сценариев. ➖Ограниченные возможности сложные проверки требуют костылей на JavaScript. ➖Мало гибкости сложные логики (например, работа с БД) реализовать сложно. ➖Трудно версионировать хранение тестов в Postman сложнее, чем в коде (например, в Git). 🚩Когда лучше использовать фреймворк для API-тестирования? Фреймворки, такие как RestAssured (Java), Cypress (JavaScript), Karate (Java), JMeter, Playwright API позволяют писать мощные тесты с полной автоматизацией. 🚩Плюсы фреймворка ➕Гибкость можно писать сложные тесты с циклами, логикой, базами данных. ➕Хорошая интеграция с CI/CD удобно запускать в Jenkins, GitHub Actions, GitLab CI. ➕Версионирование хранится в Git, легко отслеживать изменения. ➕Масштабируемость подходит для больших тестов и многопоточного выполнения. 🚩Минусы фреймворка ➖Сложнее в освоении нужно знать язык программирования (Java, Python, JS). ➖Дольше настраивать требует конфигурации проекта, зависимостей. ➖Меньше визуального удобства нет готового UI, как в Postman. Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем разница между promise.all и promise.any? В JavaScript Promise.all() и Promise.any() – это методы, которые работают с массивом промисов и возвращают один итоговый промис. Но они ведут себя по-разному при успешных и неуспешных результатах. 🚩`Promise.all()` – ждет ВСЕ промисы Успешно выполняется только если ВСЕ промисы успешны. Если хотя бы ОДИН промис ошибочный, Promise.all() сразу отклоняется (reject). const p1 = Promise.resolve(1); const p2 = Promise.resolve(2); const p3 = Promise.resolve(3); Promise.all([p1, p2, p3]).then(result => { console.log(result); // [1, 2, 3] (все успешны) }); Пример с ошибкой const p1 = Promise.resolve(1); const p2 = Promise.reject("Ошибка!"); const p3 = Promise.resolve(3); Promise.all([p1, p2, p3]).catch(error => { console.log(error); // "Ошибка!" (первый reject ломает всё) }); 🚩`Promise.any()` – ждет ЛЮБОЙ успешный промис Выполняется, как только первый промис исполнится (resolve). Если все промисы завершаются с ошибкой, Promise.any() отклоняется с AggregateError. const p1 = Promise.reject("Ошибка 1"); const p2 = Promise.resolve(2); const p3 = Promise.resolve(3); Promise.any([p1, p2, p3]).then(result => { console.log(result); // 2 (берётся первый успешный) }); Пример (все с ошибками – ошибка) const p1 = Promise.reject("Ошибка 1"); const p2 = Promise.reject("Ошибка 2"); Promise.any([p1, p2]).catch(error => { console.log(error.errors); // ["Ошибка 1", "Ошибка 2"] }); Ставь 👍 и забирай 📚 Базу знаний

🤔 Что тестируется на smoke? Smoke-тестирование (дымовое тестирование) – это поверхностная проверка критически важного функционала приложения перед основными тестами. 🚩Что тестируется в Smoke? 🟠Основной функционал приложения Запускается ли система без ошибок? Работает ли авторизация? Можно ли создать, редактировать, удалять объекты? Загружаются ли основные страницы/экраны? 🟠Основные API и интеграции Отвечает ли сервер? Работают ли основные эндпоинты? Доступна ли база данных? 🟠UI и кнопки (если тестируем веб или мобильное приложение) Загружается ли интерфейс? Работает ли навигация по основным страницам? 🟠Ошибки и креши Нет ли фатальных ошибок, из-за которых приложение "падает"? Корректно ли обрабатываются основные сценарии? 🚩Как выполняется Smoke-тестирование? 🟠Автоматически (Selenium, Cypress, Postman) Запускаются автотесты для проверки ключевых функций. Например, тест входа в систему, проверка доступности страниц. 🟠Вручную (по чек-листу) QA проверяет базовые сценарии без углубленного тестирования. Например, открылось ли приложение, можно ли зайти в профиль. Ставь 👍 и забирай 📚 Базу знаний

🤔 С какими багами можно выпускать на прод? - с багами, которые: - не влияют на ключевую функциональность; - не затрагивают безопасность; - имеют обходной путь; - известны и задокументированы. Выпуск возможен после согласования с бизнесом и при наличии тикета на фиксы в будущем. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Что делает метод equals()? Метод equals() используется для сравнения двух объектов на семантическое равенство (т.е. их содержимого, а не просто ссылок в памяти). 🚩Как работает `equals()` по умолчанию Метод equals() определён в классе Object, от которого наследуются все классы в Java public boolean equals(Object obj) { return (this == obj); } 🚩Зачем переопределять `equals()`? Если мы работаем с объектами, у которых важно содержимое (например, строки, пользователи, книги), то сравнение по ссылке не подходит. class User { String name; User(String name) { this.name = name; } } public class Main { public static void main(String[] args) { User user1 = new User("Alice"); User user2 = new User("Alice"); System.out.println(user1.equals(user2)); // false, т.к. сравниваются ссылки } } 🚩Как правильно переопределить `equals()` При переопределении equals() важно учитывать: Рефлексивность: x.equals(x) всегда true. Симметричность: x.equals(y) == y.equals(x). Транзитивность: если x.equals(y) и y.equals(z), то x.equals(z). Согласованность: результат вызова equals() не меняется, если объект неизменяемый. Сравнение с null: x.equals(null) всегда false. class User { String name; User(String name) { this.name = name; } @Override public boolean equals(Object obj) { if (this == obj) return true; // Проверяем, не сравниваем ли объект сам с собой if (obj == null || getClass() != obj.getClass()) return false; // Проверяем типы User user = (User) obj; // Приводим obj к типу User return name.equals(user.name); // Сравниваем содержимое } } public class Main { public static void main(String[] args) { User user1 = new User("Alice"); User user2 = new User("Alice"); System.out.println(user1.equals(user2)); // true, теперь работает корректно } } Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие знаешь ящики тестирования? В тестировании ПО часто используются различные подходы, известные как "ящики тестирования" (или "методы тестирования"), для определения уровня знания о внутреннем устройстве системы и способах её тестирования. 🚩Белый ящик (White Box Testing) Также известен как структурное тестирование. В этом подходе тестировщики имеют полное представление о внутренней структуре и коде программы. Тесты разрабатываются с учётом алгоритмов, ветвлений кода, путей выполнения и внутренних интерфейсов. Цель — проверить внутренние операции продукта и убедиться, что все внутренние компоненты функционируют правильно. 🚩Чёрный ящик (Black Box Testing) В этом методе тестировщики не знают о внутреннем устройстве тестируемой системы. Тесты разрабатываются на основе требований и спецификаций функциональности, без знания о том, как система реализует эти функции. Цель — проверить, соответствует ли система внешним требованиям и ожиданиям пользователя. Тестируется функциональность и поведение системы. 🚩Серый ящик (Grey Box Testing) Этот метод является комбинацией подходов белого и чёрного ящиков. Тестировщики имеют частичное знание о внутреннем устройстве системы, что позволяет им создавать более целенаправленные тестовые сценарии, основываясь как на внутренней структуре, так и на функциональных требованиях. Это может включать доступ к базам данных, архитектурным схемам и документации API. Ставь 👍 и забирай 📚 Базу знаний

🤔 Как идет процесс разработки по waterfall? Это традиционная последовательная модель разработки программного обеспечения. В ней каждая фаза должна быть завершена полностью перед началом следующей. Возврат к предыдущим этапам либо невозможен, либо требует значительных усилий. 🚩Этапы разработки по Waterfall 1⃣Анализ требований (Requirements Analysis) На этом этапе собираются, анализируются и документируются все требования к системе. Результат: детальная документация с описанием того, что должно быть разработано. Примеры: Техническое задание (ТЗ), спецификация требований. 2⃣Проектирование системы (System Design) Планирование архитектуры и структуры системы. Результат: документация по архитектуре, макеты интерфейса, диаграммы базы данных. 3⃣Разработка (Implementation) Программисты пишут код на основе проектной документации. Код разделяется на модули, которые разрабатываются и интегрируются. 4⃣Тестирование (Testing) Проверка всей системы на соответствие требованиям. Проверяются функциональность, производительность, безопасность, совместимость. 5⃣Развертывание (Deployment) После успешного тестирования продукт доставляется заказчику и разворачивается на рабочем окружении. 6⃣Сопровождение (Maintenance) Поддержка продукта, исправление багов, добавление небольших изменений. 🚩Особенности Waterfall 🟠Последовательность Каждый этап выполняется строго один за другим. 🟠Фокус на документации Вся работа документируется (например, ТЗ, проектная документация, тест-планы). 🟠Отсутствие гибкости После завершения этапа сложно вернуться назад, если обнаружены ошибки. 🟠Подходит для проектов с четкими требованиями Эффективна, если требования понятны и не изменяются в процессе разработки. Ставь 👍 и забирай 📚 Базу знаний

🤔 Зачем нужна команда Git Cherry-pick? Команда git cherry-pick используется для выбора конкретных коммитов из одной ветки и их переноса в другую. Это позволяет взять отдельные изменения, внесённые в одном месте, и применить их в другом, без необходимости переносить всю историю изменений. 🚩Почему это важно и где используется? 🟠Решение локальных проблем Если в одной ветке был сделан важный фикс (например, исправление багов), но вы не хотите сливать всю ветку, можно выбрать только нужный коммит. 🟠Избежание конфликтов Вместо объединения (merge) или ребейза (rebase), которые могут привести к большим конфликтам, cherry-pick позволяет избирательно брать изменения. 🟠Поддержка нескольких веток Когда вы работаете над несколькими версиями продукта (например, основная ветка и версия с долгосрочной поддержкой), cherry-pick помогает перенести исправления между ними. 🚩Как работает git cherry-pick? Основной синтаксис git cherry-pick <commit-hash> Пример: Допустим, вы работаете в ветке main и вам нужно перенести коммит из ветки feature-branch. # Сначала переключаемся в нужную ветку git checkout main # Берем конкретный коммит из другой ветки git cherry-pick a1b2c3d Если вы хотите выбрать несколько коммитов, это можно сделать так git cherry-pick a1b2c3d e4f5g6h Вы также можете выбрать диапазон коммитов git cherry-pick a1b2c3d..e4f5g6h 🚩Что происходит в процессе cherry-pick? Git создает новый коммит в текущей ветке с изменениями из указанного коммита. Хеш нового коммита будет другим, но содержимое изменений сохранится. Если изменения конфликтуют с текущей веткой, Git остановится и попросит вручную разрешить конфликты. 🚩Пример Предположим, в ветке feature-branch есть два коммита: a1b2c3d — Исправление бага. e4f5g6h — Обновление документации. Вы хотите перенести только исправление бага в ветку main. # Находитесь в ветке main git checkout main # Переносите исправление git cherry-pick a1b2c3d Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое открытое бета-тестирование? Открытое бета-тестирование (Open Beta Testing) – это этап тестирования программного обеспечения, при котором продукт становится доступным для широкой аудитории пользователей перед официальным релизом. 🚩Зачем нужно открытое бета-тестирование? 🟠Поиск багов и проблем с производительностью Реальные пользователи могут найти ошибки, которые не удалось выявить в лабораторных тестах. Например, на большом количестве устройств может выявиться нестабильность работы. 🟠Сбор фидбэка от пользователей Пользователи оставляют отзывы о функционале, удобстве интерфейса. Это помогает улучшить продукт перед релизом. 🟠Тестирование нагрузки и масштабируемости Проверяется, как система ведёт себя при высокой нагрузке. Например, если игра при запуске наберёт миллион пользователей, серверы должны выдержать. 🟠Маркетинговый эффект Бета-версия позволяет привлечь внимание к продукту и создать сообщество вокруг него. 🚩Как проходит открытое бета-тестирование? Объявление бета-теста – разработчики публикуют информацию, как можно присоединиться. Доступ пользователям – выкладывается публичная ссылка на скачивание или тестирование. Сбор данных – отслеживаются баги, отчёты пользователей, метрики работы системы. Исправление багов – команда исправляет найденные ошибки. Анализ фидбэка – вносятся изменения в интерфейс, механику. Финальный релиз – после завершения теста выходит стабильная версия продукта. Ставь 👍 и забирай 📚 Базу знаний

🤔 Каким типом данных могут быть ключи в JSON? JSON (JavaScript Object Notation) хранит данные в формате "ключ-значение", но ключи всегда должны быть строками в двойных кавычках "...". { "name": "Alice", "age": 25, "isActive": true } 🚩Какие ключи нельзя использовать? Числа { 123: "Number key" // ❌ Ошибка! Число не может быть ключом } Правильный вариант { "123": "Number key" } Логические значения (true, false), null { true: "Boolean key", // ❌ Ошибка! null: "Null key" // ❌ Ошибка! } Правильный вариант { "true": "Boolean key", "null": "Null key" } Объекты, массивы { { "key": "value" }: "Invalid", // ❌ Ошибка! ["array"]: "Also invalid" // ❌ Ошибка! } Ставь 👍 и забирай 📚 Базу знаний

🤔 Зачем нужны чек-листы? 🚩Чек-листы нужны для 🟠Систематизации работы: Помогают организовать и структурировать выполнение задач, обеспечивая последовательность действий. 🟠Повышения качества: Гарантируют, что все важные шаги учтены и выполнены, что минимизирует пропуски и улучшает результат. 🟠Уменьшения ошибок: За счет контроля каждого пункта снижается вероятность ошибок и упущений. 🟠Упрощения проверок: Облегчают процесс контроля и аудита выполненных задач, делая их более прозрачными и легко проверяемыми. 🟠Обучения и адаптации: Служат полезным инструментом для обучения новых сотрудников, ускоряя их адаптацию и обеспечивая соблюдение стандартов работы. Ставь 👍 и забирай 📚 Базу знаний

🤔 Что можно ожидать с implicit wait? - Ожидание появления элемента в DOM; - Работает для поиска по селекторам; - Не подходит для ожидания условий (например, смены текста или класса). Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Как бы провел автоматизацию валидации имейла (кейса)? Автоматизация валидации email-адреса — это важная задача в тестировании, так как неправильный ввод email может привести к проблемам с регистрацией, авторизацией или отправкой уведомлений. Я бы провел автоматизацию следующим образом: 🟠Определение требований и правил валидации Прежде чем писать тесты, нужно понять, какие требования предъявляются к email. Обычно email должен: Содержать "@" и "." Иметь корректную структуру (username@domain.com) Не содержать запрещенные символы (например, пробелы, кириллицу) Не быть слишком коротким (a@b.c — невалидно) Не быть слишком длинным (например, > 320 символов) Соответствовать формату регулярного выражения (RFC 5322) Пример регулярного выражения для валидации email: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ 🟠Написание автоматических тестов Я бы реализовал тестирование с помощью Selenium + Pytest или JUnit/TestNG в Java. import pytest from selenium import webdriver from selenium.webdriver.common.by import By @pytest.fixture def driver(): driver = webdriver.Chrome() driver.get("https://example.com/signup") # Открываем страницу регистрации yield driver driver.quit() @pytest.mark.parametrize("email, expected", [ ("valid.email@example.com", True), # Валидный email ("invalid-email.com", False), # Нет "@" ("@nodomain.com", False), # Нет имени ("user@.com", False), # Нет домена ("user@domain..com", False), # Двойная точка ("user@domain.c", False), # Слишком короткое доменное расширение ]) def test_email_validation(driver, email, expected): email_input = driver.find_element(By.NAME, "email") submit_button = driver.find_element(By.NAME, "submit") email_input.clear() email_input.send_keys(email) submit_button.click() error_message = driver.find_element(By.ID, "email-error") if expected: assert error_message.is_displayed() is False, f"Ошибка для валидного email: {email}" else: assert error_message.is_displayed() is True, f"Нет ошибки для невалидного email: {email}" 🟠Проверка на сервере (API-тестирование) Помимо UI, нужно проверять валидацию на сервере через API-запросы. Пример API-теста с Postman + Newman или RestAssured в Java import pytest import requests BASE_URL = "https://example.com/api/register" @pytest.mark.parametrize("email, expected_status", [ ("valid.email@example.com", 200), ("invalid-email.com", 400), ("user@.com", 400), ]) def test_email_validation_api(email, expected_status): response = requests.post(BASE_URL, json={"email": email}) assert response.status_code == expected_status 🟠Интеграция тестов в CI/CD Чтобы автоматические тесты запускались регулярно, их можно интегрировать в Jenkins, GitHub Actions, GitLab CI. name: Run Email Validation Tests on: push: branches: - main jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v3 with: python-version: '3.9' - name: Install dependencies run: pip install -r requirements.txt - name: Run tests run: pytest tests/ Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие направления данных используются у REST? В REST (Representational State Transfer) используются три основных направления передачи данных между клиентом и сервером. Эти направления определяют, как данные передаются и используются в процессе взаимодействия. 🚩Передача данных от клиента к серверу (Request Data) Клиент отправляет данные серверу для выполнения определенных операций, таких как создание, обновление или удаление ресурсов. GET /products?category=electronics&sort=price_asc 🟠Пути запроса (Path Parameters) - Данные передаются как часть URL. - Используются для указания конкретного ресурса. GET /products/123 🟠Тело запроса (Request Body) - Данные передаются в основном для POST, PUT, PATCH запросов. - Используются для передачи сложных структур данных. - Форматы: JSON, XML, форматы форм (form-data, x-www-form-urlencoded). POST /users { "name": "John Doe", "email": "john.doe@example.com" } 🚩Передача данных от сервера к клиенту (Response Data) Сервер возвращает данные клиенту в ответ на его запрос. 🟠Способы передачи данных - Тело ответа (Response Body): - Основной способ передачи данных. - Формат обычно JSON или XML. { "id": 123, "name": "Smartphone", "price": 499.99 } 🟠Заголовки ответа (Response Headers): - Передают метаинформацию о запросе или ответе. - Примеры: Content-Type, Authorization, Cache-Control. Content-Type: application/json 🟠Статус ответа (Response Status) - HTTP-коды состояния указывают результат операции. - Примеры: - 200 OK — успешный запрос. - 201 Created — ресурс успешно создан. - 404 Not Found — ресурс не найден. - 500 Internal Server Error — внутренняя ошибка сервера. 🚩Двусторонняя передача данных (Real-time Communication) В REST взаимодействие обычно происходит по запросу-ответу, но в некоторых случаях требуется поддерживать двустороннюю связь между клиентом и сервером. 🟠Long Polling Клиент отправляет запрос и ожидает ответа от сервера. Сервер отвечает только при наличии новых данных. Используется для чатов, уведомлений. 🟠WebSockets (не REST, но часто совместно используется): Устанавливается постоянное соединение между клиентом и сервером. Сервер может отправлять данные клиенту без явного запроса. Пример: уведомления, онлайн-игры. 🟠Server-Sent Events (SSE): Сервер отправляет данные клиенту в режиме реального времени через HTTP. Ставь 👍 и забирай 📚 Базу знаний

🤔 Что будет в билде на альфа-тестировании? Альфа-тестирование – это первая фаза тестирования перед бета-релизом, которая проводится внутри компании. Билд на этом этапе может быть нестабильным, но уже включает основные функции для тестирования. 🚩Что включает билд на альфа-тестировании? Основной функционал – ключевые функции уже работают, но могут быть недочёты. Отладочная информация – логирование, дебаг-панели, метрики для диагностики багов. Известные баги – разработчики могут оставить список проблем, которые ещё не исправлены. Тестовые данные – могут быть заглушки вместо реальных данных (фейковые платежи, тестовые аккаунты). Функции в разработке – некоторые части могут быть недоделаны или отключены. Инструменты отладки – иногда включаются специальные команды для тестирования. 🚩Что тестируется на альфа-версии? Критические баги – краши, зависания, ошибки работы системы. Основной функционал – соответствие требованиям, корректность логики. Производительность – скорость работы, потребление памяти, нагрузка. Интеграции – взаимодействие с API, базами данных, сторонними сервисами. UI/UX – базовая проверка интерфейса, удобство использования. 🚩Кто тестирует альфа-билд? QA-инженеры – проводят основное тестирование. Разработчики – могут тестировать функции перед передачей QA. Менеджеры, аналитики – проверяют соответствие требованиям. Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем отличается тестирование монолитного бэкенда и тестирование схемы веб сервисов? Тестирование монолитного бэкенда и сети веб-сервисов (микросервисной архитектуры) сильно различается из-за их архитектурных особенностей. 🚩Тестирование монолитного бэкенда Монолит – это единое приложение, где вся логика, база данных и API находятся в одном коде. 🟠Фокус на функциональном тестировании Проверяем, работает ли бэкенд как единое целое (API, БД, бизнес-логика). 🟠Юнит-тестирование (Unit Tests) Проверяем отдельные функции и классы (обычно через pytest, JUnit). 🟠Интеграционные тесты (Integration Tests) Проверяем связь между слоями (БД, API, бизнес-логика). 🟠Проще дебажить Весь код в одном месте, можно легко найти ошибку. def test_login(api_client): response = api_client.post("/login", json={"user": "admin", "pass": "123"}) assert response.status_code == 200 🚩Тестирование схемы веб-сервисов (микросервисов) В микросервисной архитектуре каждый сервис – отдельное приложение, взаимодействующее через API. 🟠Тестирование API-коммуникаций Проверяем REST или gRPC-запросы между сервисами. 🟠Контрактное тестирование (Contract Testing, Pact) Проверяем, что микросервисы обмениваются данными по заданному контракту. 🟠End-to-End (E2E) тестирование Проверяем, что все сервисы вместе работают корректно. 🟠Мониторинг и логирование Используем Jaeger, Prometheus для отслеживания ошибок между сервисами. 🟠Тестирование отказоустойчивости Проверяем, что система работает при сбоях (Chaos Monkey). import requests def test_order_service(): response = requests.get("http://order-service/api/orders") assert response.status_code == 200 Ставь 👍 и забирай 📚 Базу знаний

🤔 Как составлять traceability matrix? Матрица трассируемости — таблица, показывающая связь требований и тестов: - строки: требования; - столбцы: тест-кейсы; - на пересечениях — метки (покрыто/не покрыто); Она помогает убедиться, что все требования протестированы. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний