Подготовка к собесу
ОСНОВНЫЕ ВИДЫ ТЕСТИРОВАНИЯ ПО
Все классификации тестирования:
Классификация по запуску кода на исполнение:
Классификация по доступу к коду и архитектуре:
Классификация по уровню детализации приложения (Пирамида тестирования):
- Модульное тестирование или юнит-тестирование (англ. unit testing)
- Интеграционное тестирование (Integration testing)
- Системное тестирование (System testing)
- Приёмочное тестирование (acceptance test):
А) Пользовательское приемное тестирование
Б) Эксплуатационное
В) На соответствие контракту
Классификация по принципам работы с приложением
Классификация по целям тестирования
- Тестирование доступности
- Тестирование локализации и интернетизации
- Тестирование безопасности
- Проверка удобства
- Нагрузочное тестирование
- Стресс-тестирование
- Тестирование стабильности
- Инсталляционное тестирование
Классификация по цели тестирования
- Тестирование новой функциональности
- Re-test
- Регрессионное тестирование
Регрессионное тестирование проводится: - после появления нового билда (новой версии нашего продукта)
- тестирование того функционала в котором часто обнаруживаются дефекты
- плановое тестирование
- того функционала, который часто меняется в ходе разработки
Классификация по запуску кода на исполнение:
- Статическое тестирование — тестирование без запуска кода на исполнение. Это процесс обнаружения и устранения ошибок и дефектов в документации: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
Запускаться на исполнение может как код всего приложения целиком (системное тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование), отдельных частей и даже отдельные участки кода.
Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по уровню детализации приложения (Пирамида тестирования):
- Модульное тестирование или юнит-тестирование (англ. unit testing) — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
Модульное тестирование производят сами разработчики, не тестировщики. - Интеграционное тестирование (Integration testing) — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
Взаимодействие компонентов, модулей и иных систем между собой. Тестирование части системы, состоящей из 2-х и более модулей. - Системное тестирование (System testing) — тестирование взаимодействия между всеми компонентами системы или разных систем между собой или тестирование интерфейсов, между которыми взаимодействует система. Полная проверка приложения, всех модулей, можно ли пройти весь бизнес путь.
- Приёмочное тестирование (acceptance test) — тестирование на сдаче приемки всего программного продукта или его части Заказчику
А) Пользовательское приемное тестирование (User Acceptance Testing) – перед релизом собирается группа конечных пользователей, тестируется основной функционал, при наличии дефектов-устраняются.
Б) Эксплуатационное (Operational acceptance testing) – производится пользователем или администратором в среде, которая имитирует реальные условия эксплуатации ПО, производится тестирование резервного копирования, аварийное восстановление системы, безопасность ПО.
В) На соответствие контракту – на соответствие гостов, нормативных актов и т.д
Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
Классификация по целям тестирования
- Функциональное тестирование – тестирование которое направленно на проверку соответствия функциональных требований ПО к его реальным характеристикам. Подтверждение того, что наш продукт обладает всем функционалом, который требует заказчик.
Функциональное тестирование отвечает на вопрос – что должен делать наш продукт? - Нефункциональное тестирование – направленно на проверку соответствия свойств ПО с его нефункциональными требованиями. Тестирование свойств, которые не относятся к функциональности системы – надежность, производительность и т.д.
Нефункциональное тестирование отвечает на вопрос – как это должен делать наш продукт?
Функциональное тестирование
- Smoke test — тестирование, которое проводится после появления нового билда . Направлено на проверку готовности разработанного продукта к проведению расширенного тестирования и определения общего качества продукта.
Проверяет заявленную бизнес-логику ПО. - Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
Основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при их стандартном использовании. - Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Проверка нестандартного использования продукта (например, вводить не корректные логин и пароль в окне авторизации, работать на многих вкладках одновременно, подгрузка файлов недопустимых размеров или форматов. Максимально загружать нашу систему, проводить множество негативных тестов.
Нефункциональное тестирование
- Тестирование доступности - доступно ли людям с ограниченными возможностями.
Пример: Может ли человек, получив голосовое, прослушать его из верхнего динамика. - Тестирование локализации и интернетизации - тестирование с целью проверки адаптации ПО к любой культуре или особенностям языка другой страны.
Пример: Можно ли писать сообщения иероглифами (поддерживает ли кодировку)(локализация) или есть ли функция в мессенджере для оповещения о молитвенном времени (интернационализация). - Тестирование безопасности - тестирование направленное на проверку безопасности конфиденциальных данных и защиту от хакерских атак, вирусов и тд.
Пример: Отправить файл, зараженный вирусом и проверить, пропустит ли его мессенджер. Или встроить в картинку инъекцию. - Проверка удобства - тестирование направленное на удобство пользования и дизайна.
Пример: Проверить, удобно ли будет пользоваться одной рукой, не режет ли глаз цвета, не маленькая ли кнопка отправить и тд. - Нагрузочное тестирование - проводимое тестирование использования в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, и им пользуются 10 человек, отправляя сообщения и допустимые файлы допустимых размеров. - Стресс-тестирование - нагрузка, превышающая норму в несколько раз.
Пример: Сервер мессенджера рассчитан на 10 человек, а им одновременно пользуются 30 человек, активно отправляя сообщения, фото и файлы друг другу. - Тестирование стабильности - тестирование, направленное на продолжительное испытание в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, им пользуются 10 человек в рамках стандартного использования в течении месяца (переписываются, отправляют картинки и тд). - Инсталляционное тестирование - тестирование, направленное на проверку установки, обновления и удаления приложения.
Пример: Скачать приложение, установить его, удалить, установить еще раз и после обновить.
Классификация по цели тестирования
- Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.
То есть, как только разработчик выполнил свою часть работы, по созданию новой функциональности, он передает ее на тестирование. - Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.
- Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил.
Регрессионное тестирование проводится: - после появления нового билда (новой версии нашего продукта)
- тестирование того функционала в котором часто обнаруживаются дефекты
- плановое тестирование
- того функционала, который часто меняется в ходе разработки
ТЕСТИРОВАНИЕ И QA/QC, ЖИЗНЕННЫЕ ЦИКЛЫ
Баг – это дефект – это отклонение ожидаемого поведения работы программного продукта от фактического.
Что такое тестирование программного обеспечения?
Тестирование - процесс, направленный на исследование, испытание программного продукта (ПП) на соответствие ожидаемого результата поведения программного продукта и фактического.
Что такое контроль качества и обеспечение качества?
Контроль качества QC (Quality Control) — это тщательное тестирование программы на наличие дефектов, а также проверка того, что программное обеспечение соответствует всем требованиям, выдвинутым заказчиком.
Обеспечение качества QA (Quality assurance) – это подход, который помогает убедиться, что методы, технологии и процессы, используемые для создания качественных результатов, применяются правильно.
7 принципов тестирования
Принцип 1 — Тестирование демонстрирует наличие дефектов
Принцип 2 — Исчерпывающее тестирование невозможно
Принцип 3 — Раннее тестирование
Принцип 4 — Скопление дефектов
Принцип 5 — Парадокс пестицида
Принцип 6 — Тестирование зависит от контекста
Принцип 7 — Заблуждение об отсутствии ошибок
Что такое SDLC (Жизненный цикл разработки программного продукта)?
Жизненный цикл разработки программного продукта - процесс, направленный на создание, поддержание работоспособности, качества и надежности ПП.
Что такое STLC Жизненный цикл тестирования программного продукта?
Жизненный цикл тестирования программного продукта (STLC – Software testing lifecycle) - процесс, направленный на тестирование программного продукта.
- Анализ требований
- Тестовое планирование
- Написание тестовых сценариев
- Подготовка тестовой среды
- Выполнение тестов
- Завершающая фаза
ВСЕ О ТЕСТ-ДИЗАЙНЕ
Что такое Тест-дизайн?
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Цели тест-дизайна:
- Придумать тесты которые смогли бы обнаружить наиболее серьезные ошибки для ПО
- Минимизация количества тестов
Техники тест-дизайна:
Классы эквивалентности - это группировка тестовых данных, в рамках которой все элементы ведут себя одинаково. То есть, если система корректно обработает одно значение из класса, то она корректно обработает и все остальные значения этого класса
Граничные значения - Это метод тестирования, в котором основное внимание уделяется значениям на границах допустимого диапазона. Ошибки часто проникают именно в этих "крайних" точках, и проверка их помогает быстро их находить.
Попарное тестирование - это метод тестирования, при котором из множества возможных вариантов входных данных выбираются и проверяются только уникальные пары. Это позволяет сократить общее количество тестовых примеров, при этом охватывая наиболее критичные комбинации.
Таблица принятия решений - это инструмент для визуализации и анализа различных комбинаций условий и их ожидаемых результатов. Она представляет собой таблицу, в которой столбцы представляют условия, а строки - действия или результаты на основе этих условий.
Сценарное тестирования - инструмент, подразумевающий прохождение пути пользователя.
ADHOC - тестирование без документации, больше относится к исследовательскому тестированию. Но сценарий такого тестирования должен преследовать какую то цель.
Предугадывание ошибок - сценарий, подразумевающий предугадывание уязвимых мест в программе.
ДОКУМЕНТАЦИЯ (кейсы, листы, репорты)
Требования — это документ, описание того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Чек-лист
Чек-лист- список проверок, в котором мы указываем, что мы будем тестировать, результат и статус проверок.
Чек-лист включает в себя следующие атрибуты:
- Проект
- Цель проверки
- Идентификатор
- Требования
- Дата проведения
- Исполнитель
- Среда тестирования
- Тип тестов
- Название проверок
- Результат проверки
Тест-кейс
Тест-кейс – пошаговый сценарий, описывающий как проводится тестирование, и включающий более детализированные проверки (шаги).
То есть если в чек-листах мы указывали название самих проверок, не детализировали их, то в тест-кейсах необходимо расписать каждый шаг, то есть переход по ссылкам, заполнение полей, нажатие кнопок и т.д.
Обязательные атрибуты тест-кейсов
- Название проекта
- ID
- Требования
- Модуль
- Название
- Приоритет
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low) - Среда тестирования
- Шаги-теста
- Ожидаемый результат
Тестовый набор
Тестовый набор (Testsuite) – набор тест-кейсов, объединенный по одному модулю или цели проверки.
Включает в себя те же атрибуты, которые и включает в себя тест-кейс.
Баг-репорт
Баг-репорт – это отчет об ошибках
- Проект
- Название документа
- Ссылка на требования
- Цель проверки
- Дата проведения
- Исполнитель
- Среда тестирования
- Шаги теста
- Ожидаемый результат
- Фактический результат
- Статус бага
- Серьезность бага
- Приоритет устранения бага
- Прикрепленный файл
Серьезность (severity) – показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
У серьезности могут быть следующие статусы:
- Blocker – блокировка, работа ПО невозможна
- Critical –критический, приводит наш функционал в нерабочее состояние
- Major-серьезные ошибки, которые свидетельствуют об отклонении работы от БЛ или нарушающие работу программы, но не имеют критическое воздействие на ПО
- Minor – незначительный дефект не нарушающий функционал нашего приложения, который является несоответствием ожидаемого результата (ошибка дизайна, пример)
- Trivial –не имеет влияния на функционал и работу нашей программы, но может быть обнаружен визуально.
Приоритет - показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, team-lead или заказчиком.
- P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее. - P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения. - P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения.
КЛИЕНТ - СЕРВЕРНАЯ АРХИТЕКТУРА
Клиент-Серверная архитектура – это структура, в которой нагрузка распределяется между поставщиками услуг и заказчиками услуг, а также промежуточными звеньями.
2 вида клиент-серверной архитектуры:
Что включает в себя КСА:
- Клиент
- Сервер
- Базы данных
- Промежуточное ПО - драйверы, набор протоколов, язык SQL
- Прикладной программный интерфейс (API) - набор функций и подпрограмм, обеспечивающих взаимодействие клиентов и серверов, набор методов, которые можно использовать для доступа функциональности к другой программе
Существует 2 вида клиентов:
- Толстый клиент - приложение, которое обеспечивает расширенную функциональность независимо от центрального сервера. Сервер выступает в качестве хранилища данных
- Тонкий клиент - большую часть нагрузки берет на себя сервер, а не пользователь.
Плюсы и Минусы Монолитной Архитектуры:
- Простота: Проще создавать и тестировать, так как все функции в одном месте.
- Меньше взаимодействий: Нет необходимости в сетевых вызовах между компонентами.
- Производительность: Обычно быстрее из-за прямых вызовов функций.
- Масштабирование: Затруднено горизонтальное масштабирование из-за требований к целостности данных.
- Сложность обновлений: Изменения в большом приложении могут быть сложными и опасными.
- Гибкость: Недостаточно гибкая для больших и комплексных проектов.
Плюсы и Минусы Микросервисной Архитектуры:
- Гибкость: Легко масштабировать и обновлять отдельные микросервисы.
- Распределенная разработка: Команды могут работать независимо друг от друга на разных сервисах.
- Отказоустойчивость: Если один сервис падает, другие могут продолжать работу.
- Сложность управления: Необходимо учитывать большое количество сервисов и их взаимодействие.
- Сложнее отлаживать: Взаимодействие между микросервисами может быть сложным для отладки.
- Затраты на инфраструктуру: Дополнительные расходы на поддержку и развертывание сервисов.
HTTP ПРОТОКОЛЫ
HTTP- «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML.
Протокол – набор правил передачи информации. Мы регламентируем то, как будет передаваться в сети интернет наша информация.
Метод HTTP
GET - запрос для получения статуса, получение какой либо информации от сервера
POST – отправка данных, файлов
Коды состояния запроса
100-е – это информационный код состояния, дает информационные сообщения.
200-е – информируют нас об успешной отработке запроса
300-е – это перенаправление, то есть, к примеру, когда был изменен url и нужно идти на другой.
400-е – обозначают что на стороне клиента есть ошибка.
500-е – это ошибка на стороне сервера.
Передача протокола осуществляется по Модели TCP/IP.
- сетевые интерфейсы – передаются физические импульсы (оптоволокно) (протокол Ethernet)
- сетевой – происходит передача физических сигналов, основной протокол –IP
- транспортный – транспортные взаимодействия в нашей сети:
TCP - надежный транспортный протокол, в результате которого происходит гарантия того, что информация доходит до клиента, если нет подтверждения о получении информации, то происходит повторная отправка, например в почтовых сервисах, где очень важно чтоб письмо дошло до адресатов.
UDP – нет гарантии того что информация дошла, она идет непрерывным потоком, нет обратной связи, то есть подтверждения получения, например в онлайн-играх.
SOAP И REST
SOAP (Simple Object Access Protocol) — стандартный протокол. Четко структурирован и задокументирован.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети, основанный на методах протокола HTTP.
SOAP
Любое сообщение в протоколе SOAP — это XML документ
REST
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол.
Управление данными происходит с помощью методов HTTP: GET, POST, PUT, DELETE.
Разница между архитектурным стилем и протоколом в том что к АС не применяются какие-то жесткие правила
REST (Representational State Transfer) и SOAP (Simple Object Access Protocol) - это два различных способа построения архитектуры для веб-сервисов. Вот основные различия между ними:
- Принципы дизайна:
REST базируется на принципах архитектуры веб, таких как использование HTTP методов (GET, POST, PUT, DELETE), представление ресурсов через URL
SOAP основывается на строгих стандартах и предполагает использование XML для обмена сообщениями - Формат сообщений:
REST использует различные форматы для обмена данными, такие как JSON, XML, HTML, и другие.
SOAP использует только XML в качестве формата сообщений. - Простота и гибкость:
REST считается более простым и гибким для использования.
SOAP предлагает большую степень стандартизации - Производительность:
REST обычно обеспечивает более высокую производительность благодаря более легковесным форматам данных и возможности кэширования.
SOAP зачастую требует большего объема данных из-за использования XML, что может негативно отразиться на производительности.
Что выбрать SOAP или REST?
Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается действиями: чтение, добавление, изменение и удаление данных (те самые наши 4 метода get, post, put, delete ) — смело выбирайте REST. Он наиболее популярен и быстр.
POSTMAN И API
API – интерфейс, который определяет, как одна программа должна взаимодействовать с другой программой.
- Локальные API - то, что позволяет компонентам одной системы взаимодействовать между собой (микросервисная архитектура)
- Удаленные API - позволяет связывать между собой несколько систем (SOAP и REST).
API появляется раньше GUI поэтому API тестируется раньше.
- Вызов функции системой (прямой вызов)
- Вызов метода другой системой (прямой вызов)
- Вызов метода человеком (прямой вызов)
- GUI -> API. (косвенный)
Коллекции в Postman представляют собой группы запросов, скриптов и переменных, организованные вместе для удобного управления и использования
Вот несколько основных целей использования коллекций в Postman:
- Организация запросов:
- Коллекции позволяют организовать ваши API-запросы по темам, проектам или любым другим категориям. Это облегчает навигацию и поиск конкретных запросов.
- Совместная работа:
- Вы можете делиться коллекциями с другими участниками команды, что упрощает совместную работу над API и обмен знаниями.
- Использование переменных и сред:
- В коллекциях можно определять переменные и среды, что облегчает настройку запросов для различных сред или конфигураций.
- Управление тестами:
- Коллекции позволяют легко настраивать и управлять тестами для ваших API-запросов, что помогает обеспечить качество и надежность вашего API.
- Сценарии и потоки работы:
МОБИЛЬНОЕ ТЕСТИРОВАНИЕ
Типы мобильных приложений:
Нативными - написаны на родном (с англ. native – родной) для определённой платформы языке программирования.
Web – веб-сайт, адаптированный для нашего мобильного приложения.
Веб-приложение, представляет собой сайт, который адаптирован и оптимизирован под любой смартфон.
Гибридные приложения представляют собой сочетание веб и нативных приложений. Они могут быть загружены из маркетов вроде Google Play и App Store. Для их работы необходимо интернет-подключение.
Так же часто гибридные приложения являются кроссплатформенными, что ускоряет и облегчает процесс разработки.
Тестирование и особенности тестирования мобильных приложений
Зависимости мобильного тестирования:
- всплывающие окна/уведомления
- прерывания при разрядке/подзарядке
- сворачивание/разворачивание приложения
4.Работа с функциями телефона:
- размер экрана, разрешение, ориентация
- отпечаток пальца, узнавание лица, пароль, графический ключ
- работа со съемными картами памяти
- динамики, микрофоны, гнездо для гарнитуры
5.Тестирование производительности:
- зависимость от заряда батареи
- запуск с внутренней памяти/ с накопителя
6. Тестирование на соответствие гайдлайнам и мокапам
ЛОКАЛИЗАЦИЯ БАГА
Локализация бага - процесс обнаружения бага и поиск условий, при которых баг повторяется. Найти конкретные условия и минимальные для воспроизведения шаги.
Локализация - это поиск первопричины возникновения ошибки.
Нужно проверить себя еще раз: воспроизвести баг снова при тех же условиях. Если ошибка не повторилась при очередном тестировании, то нужно разобраться, точно ли были соблюдены все действия и шаги воспроизведения, приведшие к этому результату. Для того, чтобы более точно определить условия воспроизведения ошибки, необходимо эту ошибку локализовать.
Чтобы локализовать баг, необходимо собрать максимальное количество информации о его воспроизведении:
- Выявить причины возникновения дефекта
- Проанализировать возможность влияния найденного дефекта на другие области
- Отклонение от ожидаемого результата
- Исследовать окружение
- Проверить на разных устройствах
- Проверить в разных версиях ПО
- Проанализировать ресурсы системы
Локализация бага на интеграционном уровне
Локализация бага (дефекта) включает в себя процесс анализа проблемы с целью выявления максимальной детализации причины ее возникновения. Чем больше информации о проблеме собрано, тем быстрее ее решит команда.
DEVTOOLS
- Консоль - прописываются действия и ошибка JS. Так же в этой консоли можно исполнять JS. Ошибки, предупреждения о возможных ошибках. Все эти ошибки копируются (текст из консоли) и отправляется в баг репорт.
- Источники - здесь содержится информация о серверах, к которым общается клиент.
- Сеть - информация об общении сервера и клиента. Показывает запросы, которые отправляет клиент и ответы, которые отправляет сервер.
- Производительность - для оценки быстродействия сайта.
- Защита - проверка на безопасность протоколов.
СНИФФЕРЫ
Снифферы - инструменты, которые позволяют отслеживать запросы и ответы от сервера, и, при необходимости, их изменять. Используются для тестирования веб-приложений или мобильного тестирования.
Самые популярные инструменты: Charles и Fiddler.
Charles
При работе в браузере все запросы и ответы будут отображаться в программе.
Можно выбирать запрос и нажать на Focus. И тогда можно отслеживать именно этот запрос. Так же, как и в devtools.
Что можно посмотреть в запросах: header, body, служебную информацию, статус коды, методы (http).
Так же можно с помощью Charles отслеживать трафик с телефона или эмулятора. Для этого в настройках WiFi нужно выбрать сеть, к которой подключен компьютер с Charles на борту и подключится к той же WiFi сети, а так же настроить прокси для этой сети. В прокси нужно вписать ip адрес компьютера. Порт - 8888. Так же на телефоне нужно установить сертификат чтобы перехватывать трафик.
Что можно тестировать в Charles:
- Переадресация (Tools - Map Remote). Можно выставить поведение при переадресации. Например, чтобы с сайта google.com происходила переадресация на ya.ru.
- Подмена (Tools - Rewrite). Используется чаще всего. Можно подменить запросы, URL, ответы, отдельные параметры, отдельные header.
- Подмена ответа сервера в целом (Tools - Map Local). Например, работаем на сайте и загружаем определенную картинку или заказчик что то загрузил на сайт и появилась ошибка. Нужно запросить у заказчика материал и попробовать повторить его путь. Берем эту картинку, добавляем ее в body и смотрим, что происходит. Тогда могут пригодится ответы сервера.
- Занижать скорость интернета (Tools - Enable Trottling).
- Работа с breakpoint (Proxy - Breakpointing Settings). Можно ставить как для ответа, так и для запроса.
SQL
Первичный и внешний ключи:
Первичный ключ (PRIMARY KEY) - это уникальный идентификатор для каждой строки в таблице. Он используется для определения единственности данных и обеспечения быстрого доступа к ним.
Код: PRIMARY KEY
Внешний ключ (FOREIGN KEY) - это отношение между двумя таблицами, которое устанавливает связь между ними. Внешний ключ используется для ограничения взаимосвязи между таблицами и предотвращения несоответствий данных. Внешний ключ ссылается на первичный ключ другой таблицы.
Код: band_id INTEGER REFERENCES band(band_id)
Типы взаимосвязи таблиц SQL
1. Связь один ко многим (one-to-many): Это тип взаимосвязи, когда одна запись в одной таблице может относиться к нескольким записям в другой таблице.
2. Связь многие ко одному (many-to-one): Это тип взаимосвязи, когда несколько записей в одной таблице могут относиться только к одной записи в другой таблице.
3. Связь один к одному (one-to-one) - это тип взаимосвязи между двумя таблицами в базе данных, когда каждая запись в одной таблице связана с только одной записью в другой таблице.
4. Связь многие ко многим (many-to-many) - это тип взаимосвязи между двумя таблицами в базе данных, когда каждая запись в одной таблице может быть связана с несколькими записями в другой таблице, и наоборот.
Inner Join и Outer Join
INNER JOIN - способ соединения таблиц, при котором остаются те строки, где значения ключа совпадают в обеих таблицах.
LEFT OUTER JOIN - способ соединения таблиц, при котором возвращаются все строки из левой таблицы и соответствующие строки из правой таблицы. Если в правой таблице нет соответствующих строк, тогда возвращает NULL
FULL OUTER JOIN - способ соединения таблиц, при котором возвращаются строки из обеих таблиц. Если в левой или правой таблице нет соответствующих данных для второй таблицы - тогда подставляется NULL
Основные запросы:
CREATE - Создает новую таблицу, представление таблицы или другой объект в БД
DROP - Удаляет существующую таблицу
SELECT - Извлекает записи из одной или нескольких таблиц
BETWEEN - Проверяет вхождение значения в диапазон от минимального до максимального
IN - Выполняет поиск значения в списке значений
LIKE - Сравнивает значение с похожими
NOT - Инвертирует (меняет на противоположное) смысл других логических операторов
OR - Комбинирует условия (одно из условий должно совпадать)
IS NULL - Определяет, является ли значение нулевым
UNIQUE - Определяет уникальность строки
KAFKA, СИНХРОННОЕ И АСИНХРОННОЕ ВЗАИМОДЕЙСТВИЕ
Kafka
Кафка позволяет различным приложениям отправлять, получать и обрабатывать данные, такие как сообщения, логи и события, в режиме, близком к реальному времени. Это позволяет создавать масштабируемые и отказоустойчивые системы обработки данных.
Главное отличие Кафки от большинства брокеров в том, что Кафка добавляет сообщения в журнал (в топик), а консьюмер сам забирает из этого журнала данные. Кафку часто используют для сбора и агрегации из большого количества источников.
- Более высокая производительность.
- Все сообщения после прочтения не удаляются и могут быть прочитаны консьюмерами повторно. Удаление задается вручную.
- Из Кафки нельзя удалить конкретное сообщение (партицию), а только удалить топик целиком.
- При перезапуске консьюмера в брокере сохраняется коммит (снимок состояния), и тем самым происходит фиксация и консьюмер продолжает читать.
Синхронное взаимодействие:
- Определение: В синхронном взаимодействии одна часть программы ждет завершения другой части программы, прежде чем продолжить свое выполнение.