QA

1. **Погружение в QA**

1.1. Что такое тестирование?

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

1.2. Цели тестирования? За что платят?

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

1.3. Обычный рабочий день QA

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

2. **База тестирования**

2.1. Что такое QA, QC и Testing?

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

2.1.2. QA инженер — это специалист, занимающийся обеспечением качества программного обеспечения на всех этапах разработки.

2.1.3. QC инженер или специалист по контролю качества подключается к проекту после завершения разработки и занимается проверкой соответствия продукта требованиям заказчика.

2.1.3.1. Разница их в том, что QA занимается и валидацией, и верификацией, а QC занимается только валидацией.

2.2. Верификация и Валидация

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

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

2.3. Что такое требования ПО?

2.3.1. Требования - это спецификация (описание) того, что должно быть реализовано в программном обеспечении. Они играют ключевую роль в обеспечении качественного результата, поэтому важно, чтобы они были четкими и понятными. Бывают системные и бизнес требования.

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

2.3.2. Атрибуты требований

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

2.3.2.2. Атомарность: Требования не должны быть разбиты на отдельные части без потери деталей.

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

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

2.3.2.5. Полнота: Требования должны содержать всю необходимую информацию для реализации функциональности.

2.3.2.6. Недвусмысленность: Требования должны быть сформулированы однозначно.

2.4. Принципы тестирования

2.4.1. Тестирование демонстрирует наличие дефектов (Testing shows presence of defects) Тестирование показывает, что в программном обеспечении есть дефекты. Оно снижает вероятность их наличия, но не гарантирует полное отсутствие ошибок.

2.4.2. Исчерпывающее тестирование невозможно (Exhaustive testing is impossible) Полное тестирование с использованием всех возможных комбинаций входных данных, результатов и предусловий физически невыполнимо, за исключением тривиальных случаев.

2.4.3. Раннее тестирование (Early testing) Тестирование должно начинаться на ранних стадиях жизненного цикла разработки ПО. Это позволяет находить дефекты как можно раньше и устранять их до того, как они станут критическими.

2.4.4. Скопление дефектов (Defects clustering) Большая часть дефектов находится в ограниченном количестве модулей. Это явление называется "скоплением дефектов".

2.4.5. Парадокс пестицида (Pesticide paradox) Если повторять одни и те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты. Это называется "парадоксом пестицида".

2.4.6. Тестирование зависит от контекста (Testing is context depending) Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.

2.4.7. Заблуждение об отсутствии ошибок (Absence-of-errors fallacy) Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю и удовлетворять его ожиданиям и потребностям. Это включает в себя прохождение как верификации, так и валидации.

2.5. Серьезность и приоритет (Severity vs Priority)

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

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

2.5.3. Priority — это срочность исправления дефекта. Приоритеты могут быть высокими, средними и низкими в зависимости от необходимости их исправления.

2.6. SDLC, STLC и SBLC

2.6.1. SDLC (Software Development Life Cycle) SDLC — это жизненный цикл разработки программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при создании программного продукта.

2.6.1.1. Этапы SDLC: Планирование Анализ требований Проектировка и дизайн Разработка ПО Тестирование Развертывание/релиз

2.6.2. STLC (Software Testing Life Cycle) STLC — это жизненный цикл тестирования программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при проведении тестирования программного продукта.

2.6.2.1. Этапы STLC: Анализ требований Стратегия тестирования (уточнение критериев приемки (DoD, DoR)) Разработка тестов Выполнение тестов и фиксирование результатов Анализ результатов и отчетность

2.6.2.1.1. Definition of Ready (DoR) — это набор критериев, которые должны быть выполнены перед началом работы над задачей или пользовательской историей. DoR помогает команде убедиться, что задача готова к разработке и тестированию.

2.6.2.1.2. Definition of Done (DoD) — это набор критериев, которые должны быть выполнены для того, чтобы задача или пользовательская история считалась завершенной. DoD помогает команде убедиться, что работа выполнена качественно и готова к выпуску или демонстрации.

2.6.3. SBLC (Software Bug Life Cycle) SBLC — это жизненный цикл бага, который описывает этапы, через которые проходит баг от момента его обнаружения до окончательного разрешения.

2.6.3.1. Этапы SBLC: Новый ⬇️ Назначен ⬇️ Открыт ➡️ Отклонен или Отложен ⬇️ Исправлен ⬇️ Ожидает повторного тестирования ⬇️ Повторно тестируется ➡️ Повторно открыт ⬇️ Проверен ⬇️ Закрыт

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

3. **Компьютер саинс**

3.1. Фронтенд

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

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

3.1.2. Технологии фронтенда

3.1.2.1. Различные фреймворки и библиотеки, такие как React, Angular, Vue.js и другие, помогают разработчикам упростить и ускорить процесс создания интерфейса и его функциональности.

3.1.2.2. HTML (HyperText Markup Language) — это язык разметки, используемый для создания структуры веб-страниц. Он определяет элементы, такие как заголовки, абзацы, ссылки, изображения и другие компоненты.

3.1.2.3. CSS (Cascading Style Sheets) — это язык стилей, который используется для описания внешнего вида HTML-документов. Он определяет такие параметры, как цвет, шрифты, отступы и расположение элементов на странице.

3.1.2.4. JavaScript — это язык программирования, который позволяет создавать динамические и интерактивные веб-страницы. Он может изменять контент HTML и стили CSS на лету, реагируя на действия пользователя.

3.2. Бэкенд

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

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

3.2.2. Технологии бэкенда

3.2.2.1. Бэкенд может использовать различные технологии и языки программирования в зависимости от его функциональности. Это может быть написано на: Python, JavaScript (Node.js), Java, PHP, Ruby, Go и на других языках.

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

3.2.2.2.1. Сервер обрабатывает запросы от клиентов, выполняет нужные операции, и отправляет ответы обратно клиентам.

3.3. Дополнительные ключевые аспекты

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

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

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

3.3.1.3. Что можно сохранять в куки? Идентификаторы сеансов Настройки пользователя Историю посещений Данные корзины покупок

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

3.3.2.1. Кэш на клиенте: Это данные, которые клиент (например, браузер) сохраняет локально, чтобы ускорить доступ к ним при повторных запросах. Это может включать статические ресурсы, такие как изображения, стили CSS и скрипты.

3.3.2.2. Кэш на сервере: Это данные, которые сохраняются на сервере, чтобы уменьшить нагрузку на источники данных (например, базы данных) и ускорить обработку запросов. Кэш может быть реализован на уровне веб-сервера (например, Apache, Nginx) или на уровне приложений.

3.3.2.3. Что можно кэшировать? Полные страницы Фрагменты страниц Результаты запросов в базе данных Данные из внешних источников

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

3.3.3.1. JWT (JSON Web Token): Это cтандартный формат токенов, используемый для передачи информации между сторонами безопасным способом. Содержит полезную нагрузку, которую можно проверить и доверять.

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

3.3.3.3. Что можно делать с помощью токенов? Проверка личности пользователя Управление правами доступа Обеспечение безопасности взаимодействия с API

3.4. Сетевые концепции

3.4.1. IP (Internet Protocol) — это протокол, который используется для передачи данных по сети. Он отвечает за адресацию и маршрутизацию пакетов данных, чтобы они могли достичь правильного места назначения.

3.4.1.1. IPv4 — это наиболее распространенная версия IP, использующая 32-битные адреса, что позволяет создать около 4,3 миллиарда уникальных адресов.

3.4.1.2. IPv6 — это новая версия IP, которая использует 128-битные адреса, предоставляя значительно большее количество уникальных адресов (примерно 3,4×10^38 адресов).

3.4.2. DNS (Domain Name System) — это система, которая переводит доменные имена (например, www.example.com) в IP-адреса (например, 192.0.2.1), которые используются для маршрутизации запросов в интернете.

3.4.2.1. DNS-запрос — это процесс, при котором клиент (обычно веб-браузер) отправляет запрос к DNS-серверу, чтобы получить IP-адрес, соответствующий доменному имени.

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

3.4.3. HTTP (HyperText Transfer Protocol) — это протокол для передачи данных в интернете. Он используется для передачи веб-страниц от серверов к клиентам (веб-браузерам).

3.4.3.1. HTTP/1.1 — это версия протокола, которая позволяет поддерживать одно постоянное соединение для передачи нескольких ресурсов, что снижает задержки по сравнению с предыдущими версиями.

3.4.3.2. HTTP/2 — это улучшенная версия HTTP, которая включает мультиплексирование (позволяет отправлять несколько запросов через одно соединение одновременно) и сжатие заголовков, что улучшает производительность и скорость загрузки страниц.

3.4.4. HTTPS (HyperText Transfer Protocol Secure) — это расширение HTTP, которое использует шифрование для обеспечения безопасности передачи данных в интернете. Оно использует SSL/TLS для шифрования данных между сервером и клиентом, чтобы защитить их от перехвата и несанкционированного доступа.

3.4.4.1. Отличия от HTTP: Шифрование: HTTPS использует SSL/TLS для шифрования данных, что делает их недоступными для злоумышленников. HTTP передает данные в открытом виде, что делает их уязвимыми для перехвата. Аутентификация: HTTPS использует цифровые сертификаты для подтверждения подлинности веб-сайта, что помогает предотвратить атаки типа "человек посередине" (MITM). HTTP не предоставляет такого уровня аутентификации. Защита целостности данных: HTTPS обеспечивает целостность данных, предотвращая их изменение во время передачи. HTTP не защищает данные от изменений.

3.4.5. TCP (Transmission Control Protocol) — это протокол транспортного уровня, который обеспечивает надежную, ориентированную на соединение передачу данных. Он гарантирует доставку данных в правильном порядке и без потерь.

3.4.6. UDP (User Datagram Protocol) — это протокол транспортного уровня, который обеспечивает ненадежную, неориентированную на соединение передачу данных. Он не гарантирует доставку данных и порядок их получения.

3.5. **Ключевые концепции сетевой безопасности и взаимодействия**

3.5.1. **Аутентификация** — это процесс проверки подлинности пользователя (например, через логин и пароль).

3.5.2. **Авторизация** — это процесс определения прав доступа пользователя к ресурсам после аутентификации.

3.5.3. **WebSocket** — это протокол для установления двустороннего взаимодействия между клиентом и сервером. Он позволяет отправлять и получать данные в реальном времени, что полезно для чат-приложений, игр и других интерактивных сервисов.

3.5.4. **Браузер** — это программа, которая запрашивает, получает и отображает веб-страницы. Браузеры используют HTML, CSS и JavaScript для рендеринга контента, а также управляют сессиями, куки и кэшем для улучшения пользовательского опыта.

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

3.5.6. **Регистрация** - это процесс, при котором пользователь создает учетную запись на веб-сайте или в приложении.

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

4.1. Фронтенд и бэкенд связаны через сетевое взаимодействие посредством API (интерфейса прикладного программирования). Фронтенд отправляет запросы на бэкенд, запрашивая данные или запуская определенные операции. Бэкенд, в свою очередь, обрабатывает эти запросы, выполняет необходимые действия (например, извлечение данных из базы данных, обработка информации) и отправляет обратно результаты на фронтенд для отображения пользователю.

5. Теория тестирования

5.1. Виды тестирования

5.1.1. Функциональное тестирование — это процесс тестирования, который направлен на проверку соответствия ПО его функциональным требованиям и спецификациям. Основная задача заключается в том, чтобы убедиться, что каждая функция программы работает в соответствии с определёнными требованиями и выполняет предназначенные задачи. В функциональном тестировании, мы проверяем, что все работает именно так как оно задумывалось

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

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

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

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

5.1.2.1. Нагрузочное тестирование (Тестирование производительности)

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

5.1.2.1.2. Тестирование масштабируемости проверяет, как система может справляться с увеличением нагрузки путём добавления ресурсов, таких как серверы или процессоры. Метафора: Тестирование масштабируемости — это как проверка, сколько человек может обслужить ресторан, добавляя больше официантов и столов, чтобы увидеть, насколько быстро растёт скорость обслуживания.

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

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

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

5.1.2.1.6. Пиковое тестирование проверяет, как система справляется с резкими увеличениями нагрузки в короткие периоды времени. Метафора: Пиковое тестирование — это как проверка, как водопроводная система справляется с неожиданным резким увеличением потребления воды, чтобы убедиться, что она не протечёт и не сломается.

5.1.2.2. Тестирование безопасности Описание: Проверка системы на наличие уязвимостей и обеспечения защиты данных от несанкционированного доступа. Это включает в себя тестирование на предмет защиты от атак и соблюдения стандартов безопасности. Пример: Проверка на наличие уязвимостей, таких как SQL-инъекции или XSS, а также тестирование шифрования данных и механизмов аутентификации.

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

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

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

5.1.2.6. Тестирование на совместимость - Кроссбраузерность/Кроссплатформенность Описание: Проверка работы системы на различных платформах и браузерах, чтобы обеспечить её корректное функционирование в разных средах. Пример: Тестирование веб-приложения на разных браузерах (Chrome, Firefox, Safari) и операционных системах (Windows, macOS, Linux).

5.1.2.7. Тестирование установки (Installation testing) – проверка успешности установки приложения, его настройки и удаления. Описание: Проверка процесса установки, настройки и удаления приложения. Это включает в себя тестирование установщика и проверку успешности всех этапов установки и удаления. Пример: Проверка установки приложения на различных операционных системах и проверка корректности удаления приложения, включая очистку всех связанных файлов и настроек.

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

5.1.3.1. Ретестирование (Retesting) Ретестирование - это когда мы однажды завели баг, и разработчик сказал, что пофиксил его “QA, сделай ретест бага плз, я вроде все исправил” и мы начинаем перепроверять наши же замечания или замечания других тестеров

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

5.1.3.3. Смоук-тестирование (Smoke Testing) Описание: Базовое тестирование после внесения изменений, чтобы убедиться, что основная функциональность приложения работает без критических проблем. Это тестирование служит для быстрого выявления серьезных проблем перед проведением более глубоких тестов. Пример: После развертывания новой версии приложения, проверка, что основные функции, такие как логин и загрузка главной страницы, работают корректно. СМОУК мы используем почти всегда, чтобы мы не начинали. Нам нужно проверять, что фича хотя-бы запускается.

5.1.3.4. Тестирование нового функционала (New feature testing) Нью фича тестинг - это когда добавляют что-то новое в наше приложение, например возможность оплатить банковской картой “мир”, и мы проверяем работает ли данная функциональность.

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

5.2. Классификация тестирования

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

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

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

5.2.1.2.1. Тестирование внутренней интеграции (модулей/компонентов) Описание: Это проверка взаимодействия между различными модулями или компонентами внутри одного приложения. Цель — убедиться, что компоненты корректно обмениваются данными и выполняют свои функции вместе как единое целое. Пример: Представьте, что у вас есть модуль авторизации и модуль личного кабинета. Тестирование внутренней интеграции включает проверку того, как модуль авторизации передает данные о пользователе в модуль личного кабинета, чтобы гарантировать, что информация правильно отображается и доступ к личному кабинету предоставляется без ошибок. Метафора: Это как проверка, что различные отделы в одном офисе (например, отдел продаж и бухгалтерия) правильно обмениваются информацией и работают вместе, чтобы обеспечить успешное выполнение задач.

5.2.1.2.2. Тестирование внешней интеграции (системное) Описание: Это проверка взаимодействия между различными системами или приложениями, которые могут быть независимыми друг от друга. Цель — убедиться, что системы корректно обмениваются данными и взаимодействуют через внешние интерфейсы или API. Пример: Представьте, что на вашей форме авторизации есть кнопка "Войти через Госуслуги". При нажатии на эту кнопку происходит перенаправление на внешний сервис Госуслуг для аутентификации. Тестирование внешней интеграции проверяет, что процесс перенаправления и обмен данными между вашим сайтом и Госуслугами проходит без проблем, и вы успешно возвращаетесь на сайт после аутентификации. Метафора: Это как проверка, что ваш офис правильно взаимодействует с внешними поставщиками и партнерами, чтобы обеспечить бесперебойное выполнение бизнес-процессов, таких как получение материалов или услуг.

5.2.1.2.3. Техники интеграционного тестирования

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

5.2.1.4. Приемочное тестирование (Acceptance Testing) Описание: Тестирование, проведенное для проверки, соответствует ли система требованиям и ожиданиям заказчика. Часто выполняется пользователями или тестировщиками по заказу. Пример: Тестирование функциональности нового модуля пользователем, чтобы убедиться, что он удовлетворяет его потребности и работает в реальных условиях.

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

5.2.2. Методы тестирования (По знанию кода)

5.2.2.1. Тестирование методом черного ящика (black box testing): Тестирование, функциональное или нефункциональное, без знания внутренней структуры или кода. Тестировщик проверяет входные данные и ожидает правильные выходные данные, не беспокоясь о внутреннем устройстве системы.

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

5.2.2.3. Тестирование методом белого ящика (white-box testing): Метод тестирования, при котором тестировщик имеет доступ к внутреннему коду и структуре программы. Цель — проверка логики работы программы, её функций и структур. Пример: Проверка алгоритма сортировки в коде, тестирование его на различных наборах данных, чтобы убедиться, что он правильно сортирует элементы. У нас есть прямой доступ к коду, и мы можем прямо как разработчик дописать новые функции или поправить старые методы.

5.2.3. В зависимости от исполнителя

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

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

5.2.4. По степени позитивности

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

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

5.2.5. Типы тестирования (По запуску кода)

5.2.5.1. Статическое тестирование Этот вид тестирования проводится без выполнения кода программы. Оно включает в себя анализ исходного кода, проектной документации и других артефактов. Цель — найти ошибки и уязвимости до того, как программа будет запущена. Методы: Анализ кода: Использование инструментов статического анализа для проверки кода на ошибки, уязвимости, нарушения стиля кодирования и потенциальные проблемы. Примеры инструментов: SonarQube, Checkmarx. Пример: Инструмент может обнаружить непроверенные исключения или потенциальные утечки памяти в коде. Анализ требований: Оценка документации и спецификаций на соответствие требованиям, проверка полноты и ясности требований. Пример: Проверка документации на наличие ошибок и несоответствий, таких как отсутствие важной функциональности. Ревью: Процесс, в котором разработчики и тестировщики просматривают код или документацию, чтобы найти ошибки и предложить улучшения. Не может выявить ошибки, которые зависят от выполнения кода. Пример: Код-ревью может выявить логические ошибки или улучшения, которые улучшат читаемость и поддержку кода. Преимущества: Выявление ошибок на ранних этапах разработки. Улучшение качества кода и документации. Снижение количества дефектов, которые могут быть обнаружены на более поздних этапах. Ограничения: Не может выявить ошибки, которые зависят от выполнения кода. Может пропустить проблемы, которые проявляются только при реальном использовании программы.

5.2.5.2. Динамическое тестирование Этот вид тестирования проводится с выполнением кода программы. Оно фокусируется на проверке функциональности программы в реальных условиях, чтобы убедиться, что она работает правильно и эффективно. Методы: Функциональное и нефункциональное тестирование. Тестирование по уровню детализации приложения. Преимущества: Выявление ошибок и дефектов, которые проявляются только при фактическом выполнении программы. Позволяет проверить реальные условия эксплуатации и производительность. Ограничения: Может выявить ошибки слишком поздно в процессе разработки, когда исправление может быть сложным и затратным. Не всегда охватывает все возможные сценарии использования, особенно если тестовые случаи не полностью отражают реальные условия.

5.2.6. По степени автоматизации

5.2.6.1. Ручное тестирование В ручном тестировании все проверки и тестовые сценарии выполняются вручную. Тестировщик сам вводит данные, проверяет результаты и фиксирует баги, если они есть. Применяется для уникальных тестов, требующих визуальной оценки, проверки интерфейса или анализа пользовательского опыта (UX). Плюсы: Простота выполнения. Возможность адаптироваться к изменениям в процессе тестирования. Подходит для небольших проектов и тестирования специфичных кейсов. Минусы: Высокая вероятность ошибок из-за человеческого фактора. Большие временные затраты на выполнение тестов. Трудность в повторном выполнении тестов, особенно на больших объемах данных.

5.2.6.2. Автотестирование Автоматизированные тесты выполняются с помощью программных скриптов, которые выполняют тесты по заданным сценариям без участия человека. Применяется для регрессионного тестирования, нагрузочного тестирования, а также для проверки функционала, который повторяется на регулярной основе. Плюсы: Быстрое выполнение тестов, особенно при большом объеме. Тесты можно запускать параллельно и автоматически, что значительно экономит время. Легко масштабируется и позволяет быстрее находить баги. Минусы: Высокая стоимость начальной разработки и поддержки тестов. Не подходит для проверки уникальных и визуальных аспектов (например, цвет интерфейса, эмоции пользователей). Требует навыков программирования и знания специальных инструментов.

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

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

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

5.3.1.2. Kanban Канбан ― это система постановки задач и организации рабочих процессов для эффективного достижения поставленных целей. Данная методология предполагает прозрачность продвижения работы и является одним из подходов Agile. Киллер фича это визуализация работы при помощи канбан доски.

5.3.1.3. Принципы Agile: Гибкость: Способность команды адаптироваться к изменениям, даже если они происходят на поздних стадиях разработки. Непрерывная доставка: Постоянная поставка работающего программного обеспечения с короткими циклами (итерациями), обычно от нескольких недель до месяца. Сотрудничество: Тесное взаимодействие между разработчиками и заказчиками на протяжении всего проекта. Уделение внимания качеству: Постоянное улучшение и рефакторинг кода для поддержания высокого качества продукта. Методологии Agile: Agile — это не конкретная методология, а подход, включающий несколько методологий, таких как Scrum, Kanban, XP (Extreme Programming) и другие. Итеративный процесс: Проекты в Agile развиваются через итерации, каждая из которых включает планирование, разработку, тестирование и оценку. Итерации короткие, что позволяет быстро адаптироваться к изменениям и поставлять частично готовый продукт.

5.3.1.4. Преимущества Agile: Быстрая реакция на изменения: Команды могут легко адаптироваться к изменениям требований или приоритетов. Удовлетворенность заказчика: Регулярные поставки работающего программного обеспечения и тесное сотрудничество с клиентом помогают удовлетворять его ожидания. Повышение мотивации команды: Постоянные улучшения и участие команды в принятии решений способствуют более высокому уровню вовлеченности. Недостатки Agile: Трудности с масштабированием: Agile может быть сложным для внедрения в крупных организациях или на масштабных проектах, требующих координации множества команд. Требования к вовлеченности: Agile требует высокого уровня вовлеченности от заказчика и команды на протяжении всего проекта, что может быть сложно обеспечить. Недостаток документации: В Agile основной упор делается на работающий продукт, а не на документацию, что может создать проблемы при передаче проекта другой команде или при поддержке.

5.3.2. Водопадная модель (Waterfall) Водопадная модель — это последовательный и линейный процесс разработки программного обеспечения, при котором каждая фаза должна быть завершена перед началом следующей. Его суть заключается в том, что процесс разработки разбивается на несколько этапов, каждый из которых следует строго один за другим, без возврата на предыдущие стадии.

5.3.2.1. Этапы Waterfall: Сбор требований (Requirements): На этом этапе собираются все требования к системе. Эти требования фиксируются в документации, и любые изменения после этого этапа усложняются. Проектирование (Design): На основе собранных требований разрабатывается архитектура системы, определяются технологии, базы данных и интерфейсы. Реализация (Implementation): На этом этапе осуществляется разработка программного кода на основе проектной документации. Разработчики пишут код в соответствии с проектными спецификациями. Тестирование (Testing): После завершения кода начинается этап тестирования, чтобы убедиться, что все функции работают корректно и нет критических ошибок. Внедрение (Deployment): На этом этапе готовое программное обеспечение разворачивается в рабочую среду и передается пользователям. Поддержка (Maintenance): После внедрения начинается этап сопровождения, включающий исправление ошибок, обновление и доработку системы.

5.3.2.2. Особенности: Линейный процесс: Каждая фаза проекта строго следует за предыдущей и возврат на предыдущие этапы затруднен. Жесткая структура: Waterfall предполагает четкую последовательность шагов, что требует тщательного планирования и строгого следования процессу. Документированность: На каждом этапе создается подробная документация, которая фиксирует все требования, дизайн и процессы, что облегчает контроль и понимание процесса разработки.

5.3.2.3. Преимущества Waterfall: Четкая структура и контроль: Благодаря четкой последовательности этапов, легко контролировать процесс и управлять проектом. Документированность: Подробная документация на каждом этапе облегчает переход проекта между командами или передачу знаний. Подходит для проектов с четкими требованиями: Если требования проекта заранее известны и не предполагают значительных изменений, Waterfall может быть эффективным подходом. Недостатки Waterfall: Жесткость: Из-за линейной природы модели, внесение изменений на поздних этапах разработки сложно и дорого. Длительные циклы разработки: Весь продукт разрабатывается как единое целое, что может привести к тому, что пользователи увидят готовую систему только на финальном этапе. Риск потери актуальности: В случае долгих проектов требования могут измениться до момента завершения, что приведет к устареванию системы еще до её завершения.

5.4. Пирамида тестирования

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

5.4.1.1. Пирамида тестирования: Нижний уровень - юнит тесты Апи тесты в середине Ui test/e2e наверху Чем выше находимся в пирамиде, тем выше затраты времени (а время это деньги) на поддержку, на разработку, медленно прогоняются, менее стабильные. Чем ниже - меньше затрат на поддержку и разработку, быстрее прогоняются и более стабильные.

5.4.1.1.1. Уровни пирамиды: Нижний уровень: Юнит-тесты (Unit Tests): Юнит-тесты составляют основу пирамиды и являются наиболее многочисленными. Они проверяют работу отдельных компонентов или функций приложения в изоляции. Юнит-тесты быстры, дешевы в разработке и легки в поддержке. Они также стабильны и позволяют быстро находить ошибки на ранних этапах разработки. Затраты: Низкие на разработку и поддержку, быстрые в выполнении. Средний уровень: API-тесты (Integration/API Tests): API-тесты проверяют взаимодействие между различными модулями или сервисами приложения. Они помогают убедиться, что компоненты правильно работают вместе. Эти тесты занимают среднее место в пирамиде, так как их сложнее поддерживать, чем юнит-тесты, и они выполняются дольше. Затраты: Средние на разработку и поддержку, умеренные по времени выполнения. Верхний уровень: UI-тесты/End-to-End тесты (UI Tests/E2E Tests): Вершину пирамиды занимают тесты пользовательского интерфейса (UI-тесты) и End-to-End тесты. Они проверяют работу приложения в целом, включая взаимодействие с интерфейсом и работу всех компонентов вместе. Эти тесты наиболее сложные, дорогие в разработке и поддержке, а также выполняются дольше и менее стабильны по сравнению с другими типами тестов. Затраты: Высокие на разработку и поддержку, медленные по времени выполнения.

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

7. Тестовая документация и Техники тест дизайна

7.1. Теория “Тестовая документация”

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

7.1.1.1. Написание тестовой документации на проекте

7.1.1.1.1. 1 этап. Уточнение требований.

7.1.1.1.2. 2 этап. Дизайн тестов

7.1.1.1.3. 3 этап. Написание тест-кейсов

7.1.1.1.4. 4 этап. Ревью кейсов

7.1.2. Тестовые Артефакты

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

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

7.1.2.2.1. **Детали:** Тест-кейс включает в себя описание действий, которые нужно выполнить, чтобы проверить работу определенной функции, а также ожидания по результатам этих действий. Тест-кейсы помогают обеспечить структурированный подход к тестированию, позволяя отслеживать, какие функции были проверены, и какие результаты были получены. Обычно тест-кейс включает в себя следующие элементы: идентификатор тесткейса, название, предпосылки, шаги выполнения, ожидаемый результат, фактический результат и статус выполнения (успешно, неудачно). Верхнеуровневый тест-кейс - это более простой тест-кейс без супер детального описания. Низкоуровневый тест-кейс - супер детальный тесткейс с большим кол-вом шагов.

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

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

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

7.1.2.4.1. **Детали:** Баг репорт включает в себя описание ошибки, шаги для ее воспроизведения, ожидаемый результат, фактический результат, а также прилагает необходимые скриншоты или логи. Цель баг репорта — предоставить разработчикам полную информацию о дефекте, чтобы они могли его исправить. Важными элементами баг репорта являются: уникальный идентификатор, приоритет, статус, версия ПО, описание проблемы, среда тестирования, и шаги для воспроизведения. **Пример:** Баг репорт может описывать проблему с кнопкой "Отправить", которая не работает при определенных условиях, включая шаги по воспроизведению проблемы, и прилагаемые скриншоты.

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

7.1.3. Ревью тест-кейсов

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

7.1.3.1.1. **Детали:** Ревью тесткейсов играет важную роль в обеспечении качества процесса тестирования. В этом процессе: **Проверка логики и корректности:** Проверяются сами тестовые сценарии на наличие ошибок, логических несоответствий и правильность последовательности шагов. **Оценка полноты тестирования:** Проверяется, охватывают ли тесты все возможные случаи, включая позитивные и негативные сценарии, граничные значения и случаи на основе классов эквивалентности. **Анализ на дублирование:** Выявляются повторяющиеся тесты, чтобы избежать избыточности и сосредоточить внимание на уникальных аспектах приложения. **Проверка соответствия требованиям:** Оценивается, соответствуют ли тесты исходным требованиям и спецификациям, если таковые имеются. **Обратная связь и предложения:** В процессе ревью участники могут предлагать улучшения, альтернативные подходы или добавлять новые тестовые случаи для улучшения покрытия.

7.1.4. TMS (Test Management System)

7.1.4.1. TMS (Test Management System) — это система управления тестированием, которая помогает организовать и управлять процессом тестирования программного обеспечения. TMS используется для планирования тестирования, создания и хранения тестовых случаев, отслеживания их выполнения и результатов, а также для управления багами и отчетами о тестировании. Эти системы помогают тестировщикам и разработчикам работать более эффективно и упорядоченно.

7.1.4.1.1. TMS - Это “домик” для хранения тест-кейсов Иначе обычно это сайты (веб-приложения), такие, как TestIT или Allur TestOps где мы храним ручные тест-кейсы, автоматические или чек-листы. Так же они могут быть в виде программы desktop.

7.1.5. JIRA

7.1.5.1. Тасктрекеры - Это “домик” для хранения задач и баг репортов. Иначе обычно это сайты (веб-приложения), такие как JIRA или Yandex Tracker, где у нас есть канбан доска и на ней мы планируем свой день, грубо говоря, трекаем таски. Так же мы имеем возможность создавать баг репорты на эту доску и линковать их с задачами для отслеживания связей.

7.1.5.2. Это инструмент для управления проектами и отслеживания задач, разработанный компанией Atlassian. Он широко используется в IT-индустрии для планирования, отслеживания и управления программными проектами. Jira особенно популярна среди команд, использующих методологии Agile, такие как Scrum и Kanban.

7.1.6. Confluence

7.1.6.1. Confluence — это онлайн-пространство, где команды могут создавать и хранить документы, делиться информацией и работать вместе над проектами. Это как общий блокнот для всей компании, где все могут оставлять заметки, редактировать их и легко находить нужные данные. Confluence — это “домик” для хранения инструкций и документации.(как Wiki)

7.1.7. Прогон

7.1.7.1. **Тестовый прогон, или тест-ран (test run)** - это процесс выполнения одного или нескольких тест-кейсов для проверки части или всего программного продукта на наличие ошибок и проверку соответствия его требованиям и спецификациям. В процессе тестового прогона могут быть задействованы как ручные, так и автоматизированные тесты.

7.1.7.2. **Детали:** **Подготовка:** 1) Определение набора тестов для выполнения. 2) Подготовка тестового окружения. **Запуск тестов:** 1) Выполнение тестов согласно плану. 2) Фиксация результатов тестов. **Анализ результатов:** 1) Анализируется статистика выполнения тестов, включая количество пройденных, не пройденных тестов, и выявленные дефекты. 2) Оценивается, насколько система соответствует установленным критериям качества. **Документация:** 1) Результаты тестового прогона документируются в виде отчета, который может включать список пройденных тестов, выявленные дефекты и рекомендации по их устранению. 2) Отчет о тестовом прогоне обычно передается заинтересованным сторонам (например, команде разработчиков, менеджерам проекта) для принятия решений о дальнейших действиях.

7.1.7.3. **Виды тестовых прогонов:** 1) Полный тестовый прогон 2) Частичный тестовый прогон 3) Регрессионный тестовый прогон 4) Sanity тестовый прогон

7.2. Техники тест дизайна

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

7.2.1.1. Основные техники тест-дизайна

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

7.2.1.1.2. **Граничные значения (Boundary Value Analysis)** Граничные значения — это техника, при которой тестируются пограничные значения диапазонов входных данных. **Пример:** Для поля ввода числа от 1 до 100 тестирование будет включать значения 0, 1, 100 и 101.

7.2.1.1.3. **Ошибка и предположение (Error Guessing)** Ошибка и предположение — это техника, основанная на интуиции и опыте тестировщика для предсказания потенциальных ошибок. **Пример:** Обычно тестировщики начинают с проверки следующих распространенных ошибок: 1) Ввод пробелов в текстовые поля. 2) Нажатие кнопки "Submit" без ввода данных. 3) Ввод некорректных параметров (например, адрес электронной почты вместо номера телефона). 4) Загрузка файлов, превышающих максимально допустимый размер, и другие подобные действия.

7.2.1.1.4. **Тестирование на основе чек-листов (Checklist-based Testing)** Тестирование на основе чек-листов включает использование списков проверок для обеспечения выполнения всех необходимых тестов. **Пример:** При тестировании нового веб-приложения чек-лист может включать проверки для каждой страницы, всех функций и всех возможных пользовательских сценариев, таких как регистрация, вход, редактирование профиля и т.д.

7.2.1.1.5. **Диаграмма переходов и состояний (State Transition Testing)** Таблица переходов и состояний используется для проверки системы, когда она переходит из одного состояния в другое в зависимости от входных данных. **Пример:** В системе авторизации состояние "Гость" может перейти в состояние "Зарегистрированный пользователь" после успешной регистрации, и состояние "Зарегистрированный пользователь" может перейти в "Администратор" после получения соответствующих прав.

7.2.1.1.6. **Таблица принятия решений (Decision Table Testing)** Таблица принятия решений помогает тестировать различные комбинации входных данных и условий для проверки их влияния на результат. **Пример:** Таблица может включать различные условия, такие как "проверка возраста пользователя" и "наличие подписки", и определять, что должно произойти в зависимости от этих условий, например, предоставление доступа или отказ в доступе.

7.2.1.1.7. **Попарное тестирование (Pairwise testing)** Попарное тестирование — это метод, при котором тестируются все возможные пары значений входных данных для выявления дефектов, которые могут возникнуть из-за взаимодействия этих пар. **Пример:** Предположим, у нас есть веб-приложение для заказа пиццы. У этого приложения есть следующие параметры: 1) Размер пиццы: Маленькая, Средняя, Большая 2) Тип корки: Тонкая, Пышная 3) Соус: Томатный, Сливочный 4) Дополнительные ингредиенты: Пепперони, Грибы, Оливки, Ветчина Без применения парного тестирования нам нужно было бы создать 3 * 2 * 2 * 4 = 48 тестовых случаев, чтобы протестировать все возможные комбинации параметров. Однако с использованием парного тестирования мы можем сократить это количество до значительно более управляемого уровня, например, 6 или 7 тестов, покрывающих все основные комбинации параметров. Пример комбинаций (применение парного тестирования): 1) Маленькая, Тонкая, Томатный, Пепперони 2) Средняя, Тонкая, Сливочный, Грибы 3) Большая, Тонкая, Томатный, Оливки 4) Маленькая, Пышная, Сливочный, Ветчина 5) Средняя, Пышная, Томатный, Грибы 6) Большая, Пышная, Сливочный, Пепперони

7.2.1.1.8. **Классы эквивалентности + Граничные значения (Equivalence Partitioning and Boundary Value Analysis)** Комбинация двух техник, где сначала разделяются входные данные на эквивалентные классы, а затем проверяются граничные значения в этих классах. **Пример:** Для поля ввода числа от 1 до 100, классы эквивалентности могут быть: положительные числа, отрицательные числа, ноль и нецелые числа. Граничные значения будут 0, 1, 100 и 101.

7.3. Тестирование без документации

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

7.3.2. **Детали:** Когда тестировщику приходится работать без документации, он сталкивается с рядом вызовов. В таких ситуациях важно: **Исследовательское тестирование:** Исследовательское тестирование — это подход к тестированию программного обеспечения, при котором тестировщик активно изучает приложение без заранее подготовленных тест-кейсов, исследует его, пытается предсказать поведение системы и выявляет баги на основе своего опыта и интуиции. **Обратная связь с разработчиками:** В отсутствие документации, тестировщики могут обращаться к разработчикам за разъяснениями. Разработчики могут дать представление о том, как должно работать приложение, и что именно нужно тестировать. **Анализ существующего кода:** Если доступны исходные коды, тестировщики могут просматривать их, чтобы понять, как должна работать система. **Пользовательские сценарии:** Если доступны конечные пользователи или бизнес-аналитики, можно провести сессии для понимания того, как они используют приложение в реальных условиях. Это помогает создать тестовые сценарии, которые приближены к реальным условиям эксплуатации. **Исторические данные и баг-репорты:** Анализ предыдущих багов и работа над исправлениями может дать полезную информацию о проблемных местах приложения. **Ad-hoc тестирование:** Это неформальный метод тестирования, при котором тестировщик проверяет систему без заранее подготовленных тест-кейсов или плана. Основная цель этого вида тестирования — выявить дефекты случайным образом, полагаясь на опыт, интуицию и понимание приложения. Оно часто используется в тех случаях, когда времени на подготовку полноценного тестирования нет, или чтобы быстро проверить новый функционал. **Monkey Testing:** Это вид тестирования, при котором приложение тестируется путем случайных действий и ввода данных, как будто с ним взаимодействует "обезьяна" — то есть абсолютно непредсказуемо и хаотично. Цель такого тестирования — попытаться выявить неожиданные сбои или баги, которые могут возникнуть из-за некорректного ввода или необычного поведения пользователей.

7.4. Тестирование критических путей

7.4.1. **Тестирование критических путей (Critical Path Testing)** — это метод тестирования, который фокусируется на проверке наиболее важных и часто используемых функциональных сценариев в приложении. Эти сценарии представляют собой "критические пути" пользователя, то есть те, которые имеют наибольшее значение для функционирования системы и наиболее важны для конечных пользователей.

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

7.4.2. **Детали:** **Критические пути** — это ключевые сценарии использования системы, такие как регистрация пользователя, оформление заказа или процесс оплаты. Эти функции должны работать безотказно, поскольку сбой в их работе может сильно повлиять на пользовательский опыт и бизнес в целом. **Фокус на важности:** В процессе тестирования критических путей тестировщики выделяют те сценарии, которые имеют наибольшее значение для работы системы. Эти сценарии проходят приоритетное тестирование, чтобы гарантировать их стабильную и правильную работу. **Минимизация рисков:** Поскольку критические пути включают наиболее важные функции, их тестирование помогает минимизировать риски отказа системы и улучшить качество продукта.

8. **Клиент-серверная архитектура**

8.1. **Теория**

8.1.1. **Клиент-серверная архитектура** — это модель взаимодействия, где клиент (например, веб-браузер или мобильное приложение) отправляет запросы серверу (например, веб-серверу или базе данных) для получения или передачи данных. Сервер обрабатывает запросы, выполняет бизнес-логику, хранит информацию и возвращает результаты клиенту. Клиент занимается пользовательским интерфейсом и взаимодействием с пользователем, а сервер управляет данными и обеспечивает безопасность и стабильность системы. **Канал связи между клиентом и сервером это API.** Взаимодействие клиента и сервера основано на протоколах коммуникации, таких как HTTP, TCP/IP.

8.1.1.1. **API** - это сокращение от **Application Programming Interface** (интерфейс прикладного программирования). Это набор определенных правил, протоколов и инструментов, которые позволяют различным программным приложениям взаимодействовать между собой. API определяет способы, с помощью которых приложения могут отправлять запросы друг к другу для получения данных или выполнения определенных операций. Это позволяет разным системам обмениваться информацией и функциональностью без необходимости раскрытия своей внутренней реализации.

8.1.1.1.1. API определяет набор правил и инструкций, которые определяют способы взаимодействия между разными программами или компонентами программного обеспечения. **Рассмотрим некоторые из основных правил общения, которые могут быть частью API.**

8.1.1.1.2. **Детали:**

8.1.1.1.3. **Кейсы тестирования API**

8.1.1.1.4. **Основы тестирования бэкенда**

8.1.1.1.5. **REST и SOAP**

8.1.1.1.6. **Еще раз про “http”**

8.1.1.2. **Уровни клиент-сервера**

8.1.1.2.1. **Двухуровневая архитектура (Client-Server):** *Пример: * - **1.** Веб-приложение, где клиент — это браузер, а сервер отвечает за обработку запросов и управление базой данных. - **2.** Клиент-серверные базы данных, такие как приложение на компьютере, которое напрямую подключается к серверу базы данных.

8.1.1.2.2. **Трехуровневая архитектура (Three-Tier Architecture):** *Пример: * Веб-приложение, где клиент (браузер) взаимодействует с сервером приложений (например, фреймворк на Python), который обрабатывает логику и обращается к базе данных для получения информации.

8.1.1.2.3. **Многоуровневая архитектура (N-Tier Architecture):** *Пример: * Комплексная система с фронтендом, сервером приложений, несколькими микросервисами, базой данных и системой управления очередями сообщений.

8.1.1.3. **Архитектура приложений**

8.1.1.3.1. **Монолитная архитектура** — это способ разработки, при котором все компоненты приложения собираются в единый проект и тесно связаны между собой. В такой архитектуре интерфейс, логика приложения, базы данных и т. д. собраны в одно целое. Система работает как единое целое в рамках одного процесса.

8.1.1.3.2. **Микросервисная архитектура** — это способ создания программных продуктов, при котором большая сложная система разбивается на много маленьких независимых блоков — микросервисов.

8.1.2. **Гайд по микросервисам**

8.1.2.1. 🖥️ **Клиент (Client)** *Программа: веб-браузер (гугл хром) * **Клиент** — это любое приложение или устройство, которое взаимодействует с сервером для получения или отправки данных. В контексте веб-приложений клиентом обычно является веб-браузер. **Существуют два вида клиентов.**

8.1.2.1.1. **Толстый клиент** — клиент, у которого основная логика и обработка данных выполняются на стороне клиента. Примером может служить компьютерная игра.

8.1.2.1.2. **Тонкий клиент** — клиент, где основная логика и обработка данных происходят на сервере, а клиентская часть (например, браузер) просто отображает информацию и отправляет запросы на сервер. Примером служит веб-браузер, который загружает страницы с сервера и отображает их пользователю, но вся основная логика обработки данных происходит на стороне сервера.

8.1.2.2. 💻 **Сервер (Бизнес логика) (Server - Business Logic)** *Программа: Python (с использованием фреймворков, таких как Django или Flask) * **Назначение:** Серверы, написанные на Python, обрабатывают бизнес-логику приложения. Это включает обработку запросов пользователей, взаимодействие с базой данных и другими компонентами системы.

8.1.2.3. ⚙️ **Балансировщик нагрузки** *Программа: Kubernetes * **Назначение:** Kubernetes управляет контейнерами и выполняет роль балансировщика нагрузки. Он распределяет входящие запросы между контейнерами с вашими приложениями (сервером бизнес-логики), обеспечивая масштабируемость и отказоустойчивость.

8.1.2.4. 🌐 **Веб-сервис** **Определение:** Веб-сервис — это специализированный тип API (Application Programming Interface), работающий через Интернет. Он позволяет программным приложениям взаимодействовать друг с другом с помощью веб-технологий, таких как HTTP, HTTPS, SOAP и REST. **Примеры:** - Веб-сервис погоды, предоставляющий информацию о текущей погоде и прогнозах. - Веб-сервис обмена валют, предоставляющий курсы валют в реальном времени.

8.1.2.5. 📦 **Брокер очередей (Message Broker)** *Программа: Apache Kafka * **Назначение:** Apache Kafka используется для асинхронного обмена сообщениями между различными компонентами системы. Сервер может отправлять сообщения в очереди Kafka, чтобы их позже обработали другие сервисы или воркеры.

8.1.2.6. 🗄️ **Сервер базы данных (Server - Database)** *Программа: Oracle Database * **Назначение:** Oracle Database хранит структурированные данные, необходимые для работы вашего приложения. Серверы бизнес-логики обращаются к этой базе данных для чтения и записи информации.

8.2. **Сетевые технологии, которые так же используются в современных архитектурах**

8.2.1. **Сетевая модель TCP/IP состоит из четырех уровней:** прикладного, транспортного, сетевого и канального. Каждый из этих уровней выполняет определённую функцию в передаче данных по сети.

8.2.1.1. 1. **Прикладной уровень (Application Layer):** - Это верхний уровень модели TCP/IP, который отвечает за взаимодействие с приложениями пользователя. Он обеспечивает интерфейс для взаимодействия приложений с сетью, используя протоколы, такие как HTTP, FTP, SMTP и DNS. - **Пример:** Когда вы открываете веб-страницу в браузере, прикладной уровень использует протокол HTTP для передачи данных.

8.2.1.2. 2. **Транспортный уровень (Transport Layer):** - Этот уровень отвечает за установление, поддержание и завершение соединений между устройствами, а также за надежную передачу данных. Основные протоколы этого уровня — TCP (обеспечивает надёжную доставку данных) и UDP (быстрая, но ненадёжная передача). - **Пример:** Когда вы отправляете файл через интернет, транспортный уровень гарантирует, что все части файла будут доставлены правильно и в нужном порядке (если используется TCP).

8.2.1.3. 3. **Сетевой уровень (Network Layer):** - Сетевой уровень отвечает за определение маршрута и передачу пакетов данных между устройствами в разных сетях. Основной протокол на этом уровне — IP (Internet Protocol), который использует IP-адреса для маршрутизации пакетов. - **Пример:** Когда вы отправляете электронное письмо, сетевой уровень определяет путь, по которому данные будут переданы от вашего устройства к получателю.

8.2.1.4. 4. **Канальный уровень (Link Layer)_физический уровень:** - Это самый нижний уровень модели TCP/IP, который управляет физической передачей данных между устройствами в одной сети (например, в локальной сети). Он обеспечивает правильную передачу битов по физическому каналу связи, управляет доступом к среде передачи и обработкой ошибок на уровне канала. - **Пример:** Когда ваше устройство подключается к Wi-Fi, канальный уровень управляет передачей данных между вашим устройством и маршрутизатором.

8.2.2. **Модель OSI (Open Systems Interconnection)** — это концептуальная сетевая модель, состоящая из семи уровней, которая используется для стандартизации и объяснения процессов передачи данных в сети.

8.2.2.1. 1. **Прикладной уровень (Application Layer):** Это верхний уровень модели OSI, который предоставляет приложениям интерфейс для взаимодействия с сетью. Он отвечает за поддержку сетевых услуг, таких как электронная почта, веб-браузеры, и другие приложения. **Пример:** HTTP, FTP, SMTP — протоколы, работающие на прикладном уровне.

8.2.2.2. 2. **Представительный уровень (Presentation Layer):** Этот уровень отвечает за преобразование данных в формат, пригодный для передачи по сети. Он занимается шифрованием, дешифрованием, сжатием и разжатием данных. **Пример:** SSL/TLS для шифрования данных перед их передачей по сети.

8.2.2.3. 3. **Сеансовый уровень (Session Layer):** Управляет сессиями между приложениями. Он отвечает за установление, поддержание и завершение сеансов связи, а также за синхронизацию данных в случае их прерывания. **Пример:** Установка сеанса связи между клиентом и сервером во время видеоконференции.

8.2.2.4. 4. **Транспортный уровень (Transport Layer):** Обеспечивает надёжную передачу данных между узлами в сети. Он разбивает данные на сегменты и собирает их на принимающей стороне. Основные протоколы: TCP и UDP. **Пример:** TCP обеспечивает надежную передачу данных, гарантируя их доставку в правильном порядке.

8.2.2.5. 5. **Сетевой уровень (Network Layer):** Отвечает за определение маршрута и передачу пакетов данных между устройствами в разных сетях. Протокол IP (Internet Protocol) используется для адресации и маршрутизации данных. **Пример:** IP-адресация и маршрутизация данных между разными узлами сети.

8.2.2.6. 6. **Канальный уровень (Data Link Layer):** Управляет передачей данных между узлами в одной сети. Он обеспечивает правильную передачу кадров данных по физической линии связи, включая обнаружение и исправление ошибок. **Пример:** Ethernet — протокол канального уровня, обеспечивающий передачу данных по локальной сети.

8.2.2.7. 7. **Физический уровень (Physical Layer):** Самый нижний уровень модели OSI, который отвечает за передачу сырых битов данных по физическому каналу связи. Этот уровень определяет электрические, механические и процедурные аспекты соединения. **Пример:** Кабели, разъемы, электрические сигналы — всё это относится к физическому уровню.

8.3. **HTTP/HTTPS**

8.3.1. **HTTP (Hypertext Transfer Protocol)** - это протокол передачи данных, который используется для обмена информацией между клиентами и серверами в сети Интернет.

8.3.1.1. Порт 80

8.3.1.2. Данные не шифруются

8.3.1.3. Не использует сертификаты

8.3.1.4. URL начинается с http://

8.3.2. **HTTPS (HTTP Secure)** - это версия HTTP, которая добавляет шифрование с использованием SSL/TLS для обеспечения безопасной передачи данных. SSL/TLS использует алгоритмы для шифрования передаваемых данных, что не позволяет злоумышленникам считать их при передаче через зашифрованное соединение. Эти данные включают потенциально конфиденциальную информацию, такую как имена, адреса, номера кредитных карт и другие финансовые данные.

8.3.2.1. Порт 443

8.3.2.2. Данные шифруются

8.3.2.3. Использует сертификаты

8.3.2.4. URL начинается с https://

8.3.3. **Методы HTTP**

8.3.3.1. **Методы HTTP (GET, POST, PUT, DELETE и другие)** — это действия, которые клиент может выполнять над ресурсами на сервере. Каждый метод определяет тип операции, которую клиент хочет выполнить, и имеет свои особенности и правила использования. **Рассмотрим эти методы:**

8.3.3.1.1. **GET**

8.3.3.1.2. **POST**

8.3.3.1.3. **PUT**

8.3.3.1.4. **DELETE**

8.3.3.1.5. **PATCH**

8.3.3.1.6. **HEAD**

8.3.3.1.7. **OPTIONS**

8.3.3.1.8. **CONNECT**

8.3.3.1.9. **TRACE**

8.3.4. **Основные элементы HTTP-запроса(request) на сервер**

8.3.4.1. HTTP-запрос состоит из нескольких ключевых элементов: метода запроса, URL, заголовков, тела запроса, параметров запроса, и куки.

8.3.4.1.1. 1. **Метод запроса**: Определяет тип операции, которую нужно выполнить, например, `GET` для получения данных или `POST` для отправки данных на сервер. 2. **URL (Uniform Resource Locator)**: Указывает адрес ресурса на сервере, с которым клиент хочет взаимодействовать. 3. **Заголовки (Headers)**: Содержат дополнительную информацию о запросе, такую как тип содержимого, параметры аутентификации и другие. 4. **Тело запроса (Body)**: Используется для передачи данных на сервер в запросах типа `POST`, `PUT`, или `PATCH`. 5. **Параметры запроса (Query Parameters)**: Дополнительные ключи и значения, которые добавляются к URL после знака вопроса `?`, для передачи дополнительной информации серверу. 6. **Куки (Cookies)**: Маленькие фрагменты данных, которые позволяют серверу запоминать информацию о пользователе между запросами.

8.3.5. **Как выглядит ответ (Response) на сервере**

8.3.5.1. Ответ (response) сервера состоит из статусной строки, заголовков ответа, пустой строки и тела ответа.

8.3.5.1.1. 1. **Статусная строка (Status Line)**: Содержит версию протокола HTTP, статусный код и текстовое описание статуса. 2. **Заголовки ответа (Response Headers)**: Предоставляют дополнительную информацию о сервере и инструкции по обработке ответа, такие как тип содержимого, параметры кэширования и куки. 3. **Пустая строка**: Отделяет заголовки ответа от тела ответа. 4. **Тело ответа (Response Body)**: Содержит данные, запрошенные клиентом, такие как веб-страница, данные в формате JSON или сообщение об ошибке.

8.3.6. **Как происходит формирование HTTPS запроса**

8.3.6.1. 1. **Установка TCP-соединения:** Клиент устанавливает TCP-соединение с сервером на порту 443. Порт 443 является стандартным портом для HTTPS.

8.3.6.2. 2. **Процесс SSL/TLS (Handshake):** После установки TCP-соединения, происходит процесс рукопожатия SSL/TLS, который включает в себя следующие шаги: - **Приветствие (Hello):** Клиент и сервер обмениваются сообщениями, включая поддерживаемые версии протокола и криптографические алгоритмы. - **Обмен сертификатами:** Сервер предоставляет свой цифровой сертификат клиенту, который содержит открытый ключ сервера и подпись центра сертификации. - **Аутентификация:** Клиент проверяет, что сертификат подписан доверенным центром сертификации, что гарантирует подлинность сервера.

8.3.6.3. 3. **Формирование HTTP запроса (Request):** После успешного установления безопасного соединения клиент формирует HTTP запрос так же, как и в случае HTTP, но с использованием "https" в URL и с префиксом "https://" перед именем хоста.

8.3.6.4. 4. **Шифрование данных:** Все данные, включая заголовки и тело запроса, шифруются с использованием симметричного ключа, который был установлен в процессе рукопожатия SSL/TLS.

8.3.6.5. 5. **Отправка запроса:** Зашифрованный HTTP запрос отправляется по безопасному соединению.

8.3.6.6. 6. **Обработка сервером:** Сервер расшифровывает полученные данные, обрабатывает HTTP запрос и отправляет зашифрованный HTTP ответ (Response) обратно клиенту.

8.3.7. **Статус коды**

8.3.7.1. HTTP-статус-коды представляют собой трехзначные числа, которые сервер отправляет в ответ на запрос клиента. Они указывают на успешность выполнения запроса, перенаправление, ошибку сервера и другие сценарии.

8.3.7.1.1. ⚙ **1xx (Информационные коды):** Например: - **100 Continue:** Сервер понял запрос клиента и продолжает обработку. Сообщают какую-либо информацию, не несут обычно полезной нагрузки.

8.3.7.1.2. ⚙ **2xx (Успешные коды):** Например: - **200 OK:** Запрос успешно выполнен. Это стандартный код для успешных HTTP-запросов. - **201 Created:** Ресурс успешно создан в ответ на POST-запрос. Говорят об успешном выполнении запроса с различными условиями.

8.3.7.1.3. ⚙ **3xx (Коды перенаправления):** Например: - **301 Moved Permanently:** Ресурс перемещен на постоянной основе. Клиент должен использовать новый URL для доступа к ресурсу. - **302 Found (или Moved Temporarily):** Ресурс временно перемещен. Клиент должен использовать новый URL, но запросы к старому URL могут продолжаться. - **304 Not Modified:** Ресурс не был изменен с момента последнего запроса. Клиент может использовать кэшированную версию. Их называют по-другому редиректами или перенаправлением

8.3.7.1.4. ⚙ **4xx (Коды ошибок клиента):** Например: - **400 Bad Request:** Запрос некорректен или не может быть обработан сервером. - **401 Unauthorized:** Клиент не авторизован для доступа к ресурсу. - **403 Forbidden:** Клиент имеет доступ к ресурсу, но сервер отказывает в выполнении запроса. - **404 Not Found:** Запрашиваемый ресурс не найден на сервере. - **405 Method Not Allowed:** Метод запроса не разрешен для данного ресурса.

8.3.7.1.5. ⚙ **5xx (Коды ошибок сервера):** Например: - **500 Internal Server Error:** Общая ошибка сервера. Обычно это свидетельствует о программной ошибке или неполадке на сервере. - **503 Service Unavailable:** Сервер временно не может обрабатывать запросы. Это может быть вызвано перегрузкой или временной неполадкой.

8.4. **Логи**

8.4.1. **Логи** — это записи событий и сообщений, создаваемые программой или системой во время ее работы. **Логи нужны для локализации ошибок.**

8.4.1.1. **Уровни логирования**

8.4.1.1.1. **Уровень Trace (10)** Уровень **Trace** очень подробно описывает каждое событие и поэтому очень полезен для тестировщика, когда нужно локализовать какую-то проблему. Уровень **Trace** показывает нам все возможные данные, возможно D-шники, подключение к базам, обращение к базам данных.

8.4.1.1.2. **Уровень Debug (20)** Уровень **Debug** означает, что мы можем дебажить. Логи написаны достаточно подробно. И мы можем поставить уровень дебаг, а параллельно разработчик будет останавливать процесс работы программы, вкидывая какие-то данные для того, чтобы можно было отследить поведение программы.

8.4.1.1.3. **Уровень INFO (30)** Уровень **INFO** - это тот самый уровень, который зачастую стоит у нас на проде, так как этот уровень в основном показывает нам обычные ивенты, кратко описанные. Например, пользователь создал платежку и будет так выведено: пользователь создал платежку с таким-то айдишником, без каких-либо подробностей, достаточно емко и, понятно, немного весит для вывода прод.

8.4.1.1.4. **Уровень Warning (40)** Уровень **warning** обычно выводит нам предупреждение. Вы могли замечать на примере DevTools, что часто есть предупреждение об возможных ошибках. То же самое и в логировании тоже могут быть предупреждения о всяких ошибках, допустим, осталось мало памяти на сервере. Оно не нарушает работу системы, обычно на них не обращают внимания, и, соответственно, они не очень важны в нашем плане.

8.4.1.1.5. **Уровень ERROR (50)** Уровень **ERROR** направлен на вывод ошибок. Эти ошибки не всегда означают, что это какой-либо баг. Эти ошибки могут быть, когда вы отправляете какие-то невалидные данные, которые система не может обработать. Допустим, пытаетесь купить 20 билетов, когда доступно только 15. Соответственно, в логах будет выведена ошибка. Помимо также ошибочных каких-то действий со стороны пользователя, могут быть и выводиться какие-либо ошибки. На самом деле, допустим, прикладной микросервис мог отправить вам данные, которые вы не можете обработать по каким-либо причинам. Здесь есть два варианта. Либо это действительно баг, что ваша система не может обработать какие-либо данные, но при этом прикладной сервис отправляет вам все правильно. Либо второй вариант событий, когда прикладной микросервис отправляет вам неверные данные, и вы верно их обрабатываете (выводите ошибку).

8.4.1.1.6. **Уровень FATAL (60)** Уровень **FATAL** выводит нам ошибки, которые максимально сильно нарушаю работу системы, которые “кладут” систему, после которых система не работает. Это критические ошибки, вы их могли бы видеть очень-очень редко, когда у вас сервис падает по различным причинам. Например закончилась память, кто-то отключил работу сервиса непреднамеренно, слишком большая нагрузка, которую сервер не может выдержать в виду своих характеристик.

8.4.1.2. **Дополнительно файл логирования может расширяться записями еще двух уровней:**

8.4.1.2.1. **Trace** — пошаговые записи процесса. Полезен, когда сложно локализовать ошибку.

8.4.1.2.2. **Info** — общая информация о работе службы или сервиса.

8.4.1.3. **Типы логов** Для удобства обработки логов их делят на типы:

8.4.1.3.1. **Системные**, связанные с системными событиями. **Серверные**, отвечающие за процесс обращения к серверу. **Почтовые**, работающие с отправлениями. **Логи баз данных**, которые отражают процессы обращения к базам данных. **Авторизационные и аутентификационные**, которые отвечают за процесс входа, выхода из системы, восстановление доступа и пр.

8.4.1.4. **Пакетное логирование**

8.4.1.4.1. На разные пакеты могут стоять разные уровни логирования. В рамках одного микросервиса функции могут быть разделены на пакеты. **Пакет — что это такое?** Представим, что у нас есть какая-то функциональность, например, импорт. В импорте можно импортировать документы и получать отчеты по результатам проверок или по результатам импортирования этих документов. И здесь можно разделить их на два пакета. Это импортирование документов – один пакет. И, соответственно, получение отчетов – это второй пакет. И пакеты можно поставить на разные уровни логирования, в зависимости от того, что нам нужно отследить. Это сделано, чтобы разграничить нагрузку и также легче локализовать ошибки.

8.5. **Асинхронность/Синхронность**

8.5.1. **Синхронность** — это способ выполнения операций, при котором одна операция должна завершиться перед тем, как начнется следующая. **Синхронный пример:** Запрос на получение данных с сервера через REST API (GET /data), где клиент ожидает, пока сервер вернет ответ, прежде чем продолжить выполнение других действий.

8.5.2. **Асинхронность** — это способ выполнения операций, при котором другие операции могут выполняться одновременно, не дожидаясь завершения предыдущих. **Асинхронный пример:** Отправка запроса на сервер (POST /process) для запуска длительной задачи, где клиент получает подтверждение, что задача начата, и продолжает выполнение других задач, пока сервер обрабатывает запрос. Когда сервер завершит обработку, он может отправить результат клиенту через уведомление или другой запрос.

9. **Идемпотентные методы**

9.1. **Идемпотентность** — это свойство методов, которое означает, что повторный вызов такого метода с теми же данными не изменит результат.

10. **Отличия GET и POST** GET и POST — это два основных метода HTTP, которые используются для разных целей. GET запрашивает данные с сервера, не изменяя его состояние, тогда как POST отправляет данные на сервер для создания или изменения ресурсов.

11. **Разница между PUT и POST**

11.1. PUT идемпотентный, а POST нет. PUT заменяет или обновляет ресурс по конкретному URI, а POST создает новый ресурс или выполняет операции. Результат PUT - один и тот же ресурс будет обновлен. Результат POST - каждый запрос может создавать новый ресурс. URI ресурса при PUT заранее известен (например, /users/123), URI ресурса POST определяется сервером (например, /users).

12. **Тестирование фронта**

12.1. **Теория**

12.1.1. **Веб-элементы** — это интерактивные компоненты на веб-страницах, которые позволяют пользователю взаимодействовать с веб-приложением. Примеры веб-элементов включают кнопки, текстовые поля, радиокнопки, флажки и выпадающие списки.

12.1.2. **GUI (Graphical User Interface)** — это интерфейс, который позволяет пользователю взаимодействовать с программами и устройствами с помощью визуальных элементов, таких как кнопки, иконки и окна.

12.1.3. **Отличие GUI и веб элементов**

12.1.3.1. GUI (Graphical User Interface) и веб-элементы связаны, но они не одно и то же. GUI — это общая концепция интерфейса, который использует визуальные элементы для взаимодействия с программами, а веб-элементы — это конкретные компоненты GUI, используемые на веб-страницах.

12.1.4. **Ключевые критерии качества GUI**

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

12.1.5. **Методы тестирования фронта**

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

12.1.6. **Чит-лист**

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

12.1.6.1.1. - **Отображение интерфейса:** - [ ] Проверить корректность отображения всех элементов на странице (тексты, изображения, кнопки, поля ввода и т.д.). - [ ] Проверить соответствие макету (шрифты, цвета, отступы). - [ ] Проверить адаптивность интерфейса на разных разрешениях экрана. - **Функциональность:** - [ ] Проверить работу всех кнопок и ссылок. - [ ] Проверить отправку форм, валидацию полей и сообщения об ошибках. - [ ] Проверить функциональность выпадающих списков, радио-кнопок, чекбоксов. - [ ] Проверить корректность загрузки данных на странице (таблицы, списки и т.д.). - [ ] Проверить наличие и правильность работы всплывающих окон и модальных диалогов. - **Кроссбраузерное тестирование:** - [ ] Проверить работу приложения в основных браузерах (Chrome, Firefox, Safari, Edge). - [ ] Проверить работу в разных версиях браузеров, включая мобильные версии. - [ ] Проверить корректность работы на разных операционных системах (Windows, macOS, Linux). - **Адаптивность (Responsive Design):** - [ ] Проверить корректность отображения на мобильных устройствах (iOS, Android). - [ ] Проверить работу приложения на планшетах. - [ ] Проверить отображение интерфейса на больших экранах (мониторы высокого разрешения). - **Производительность:** - [ ] Проверить время загрузки страницы. - [ ] Проверить скорость рендеринга элементов на странице. - [ ] Проверить плавность работы интерфейса (анимации, переходы). - [ ] Проверить скорость отклика на действия пользователя. - **Доступность (Accessibility):** - [ ] Проверить возможность навигации по странице с помощью клавиатуры. - [ ] Проверить наличие альтернативных текстов для изображений. - [ ] Проверить контрастность текста и фона. - [ ] Проверить поддержку экранных читалок. - **Безопасность:** - [ ] Проверить защиту от XSS-атак (ввод скриптов в поля ввода). - [ ] Проверить безопасность передачи данных (наличие HTTPS). - [ ] Проверить, что чувствительные данные не сохраняются на клиенте (например, пароли в localStorage). - **Локализация:** - [ ] Проверить корректность отображения текста на всех поддерживаемых языках. - [ ] Проверить правильность работы переключения языков. - [ ] Проверить соответствие перевода контексту интерфейса. - **Интеграция:** - [ ] Проверить работу API-запросов (GET, POST, PUT, DELETE). - [ ] Проверить корректность интеграции с внешними сервисами (например, платежные системы, карты). - [ ] Проверить обработку ошибок при недоступности внешних сервисов. - **Регрессионное тестирование:** - [ ] Проверить, что новая функциональность не нарушила работу старой. - [ ] Проверить, что баги, исправленные ранее, не воспроизводятся снова.

12.1.7. **HTML/CSS**

12.1.7.1. **HTML**, сокращение от **Hyper Text Markup Language** (язык разметки гипертекста), представляет собой основу веб-страниц. Он определяет структуру и содержимое страницы, устанавливает, где и как следует размещать каждый элемент, от текста и изображений до ссылок и таблиц.

12.1.7.2. **CSS (Cascading Style Sheets)** — это язык стилей, который используется для описания внешнего вида и форматирования HTML-документов. CSS определяет, как элементы HTML должны отображаться на экране, в печати или в других средах. Вот основные концепции и особенности CSS:

12.1.7.2.1. Внешние стили размещаются в отдельных файлах с расширением .css и подключаются к HTML-странице при помощи тега <link> в секции <head>

12.1.7.2.2. Внутренние стили могут быть определены непосредственно внутри HTML-страницы при помощи тега <style> в секции <head> Или применены как атрибуты к конкретным HTML-элементам: <p style="color: red; font-size: 16px;">Текст</p>

12.1.7.2.3. **Основные моменты CSS, которые важны для тестировщиков:**

12.2. **DevTools (Developer Tools)** — это набор встроенных инструментов, которые помогают разработчикам и тестировщикам анализировать и отлаживать веб-страницы прямо в браузере.

12.2.1. Современные браузеры, например Safari, Firefox, Edge, Chrome, Яндекс и другие — имеют встроенные инструменты разработчика (Devtools). С их помощью можно посмотреть исходный код сайта, какая информация хранится в cookie, а какая в local storage. Проверить какие запросы отправляет сайт и какие ответы присылает сервер. И много что ещё.

12.3. **Кроссплатформенность/Кроссбраузерность**

12.3.1. **Кроссплатформенность** — это способность программного обеспечения или приложения работать на разных операционных системах и устройствах без необходимости внесения изменений в код. Кроссплатформенные приложения разрабатываются таким образом, чтобы они могли выполняться на различных платформах, таких как Windows, macOS, Linux, Android, и iOS, с минимальными изменениями или вообще без них.

12.3.1.1. **Основные аспекты кроссплатформенности через DevTools:**

12.3.1.1.1. 1. Тестирование на различных устройствах

12.3.1.1.2. 2. Эмуляция различных браузеров

12.3.1.1.3. 3. Проверка адаптивного дизайна

12.3.1.1.4. 4. Тестирование различных сетевых условий

12.3.1.1.5. 5. Отладка и анализ производительности

12.3.1.1.6. 6. Просмотр и изменение DOM и CSS

12.3.2. **Кроссбраузерность** — это способность веб-приложения или веб-сайта корректно отображаться и функционировать в разных веб-браузерах. Веб-браузеры, такие как Google Chrome, Mozilla Firefox, Safari, Microsoft Edge, и другие, могут по-разному интерпретировать HTML, CSS и JavaScript, что может привести к различиям в отображении и поведении веб-страниц. Задача кроссбраузерного тестирования — убедиться, что ваше приложение одинаково хорошо работает во всех этих браузерах.

12.3.2.1. **Основные аспекты кроссбраузерности:**

12.3.2.1.1. 1. Совместимость с разными браузерами

12.3.2.1.2. 2. Совместимость с различными версиями браузеров

12.3.2.1.3. 3. Поддержка разных операционных систем

12.3.2.1.4. 4. Обработка CSS-стилей и JavaScript

12.3.2.1.5. 5. Адаптивный дизайн

13. **SQL + БД**

13.1. **Теория SQL**

13.1.1. **SQL (Structured Query Language)** — язык запросов для управления данными в реляционных базах данных.

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

13.1.3. **С помощью SQL-запросов можно:** - Создавать и удалять таблицы в реляционной БД - Изменять данные в существующих таблицах - Наполнять таблицы данными - Доставать из таблиц необходимую информацию

13.1.4. **Запрос** — это команда к базе данных, написанная в синтаксисе SQL. В запросе указываются, какие данные выбрать, как их обработать или изменить. Запрос формируется с помощью специальных слов или символов в синтаксисе SQL, называемых операторами.

13.2. **Основы работы с данными**

13.2.1. **SELECT**

13.2.1.1. ➖ Оператор **`SELECT`** является одним из основных операторов и почти всегда знакомство с SQL начинается именно с него. Его используют для получения выборки данных. В запросе два ключевых слова: **`SELECT`** и **`FROM`** — буквально «выбрать из». **`SELECT`** указывает, какие столбцы выбрать из таблицы базы данных. **`FROM`** (англ. «из») указывает, из какой таблицы взять данные.

13.2.1.2. Таким образом синтаксис запроса с SELECT выглядит следующим образом:

13.2.1.2.1. **Выбор конкретного столбца:** SELECT product_name FROM products; Здесь product_name — это столбец, который нужно выбрать, а products— таблица, из которой берутся данные.

13.2.1.2.2. **Выбор всех столбцов:** SELECT * FROM products; Символ * обозначает выбор всех столбцов из таблицы products.

13.2.2. **WHERE**

13.2.2.1. Условие в SQL-запросе, которое покажет ограниченную выборку, прописывают командой **WHERE (англ. «где»)**. Оператор проверяет, соответствует ли каждая строчка таблицы условию, и выбирает подходящие. Синтаксис запроса строится так же, как и SELECT, но добавляется WHERE: SELECT product_name FROM products WHERE product_price = '100' При выполнении подобного запроса в результате мы получим один столбец product_name и все строки, где **product_price = '100'**

13.2.2.2. ➖** Порядок операторов строго определён. Они должны идти так:** 1. SELECT 2. FROM 3. WHERE **Обозначить границы выборки в условиях помогают операторы сравнения:** = равно <>, != не равно > больше < меньше >= больше или равно <= меньше или равно

13.2.2.3. ➖ **Также, можно использовать математические операторы** Ниже перечислены математические операторы PostgreSQL. Некоторые математические операторы являются стандартными и присутствуют в любой СУБД. Некоторых операторов может не быть в других СУБД или их синтаксис может отличаться. + Сложение — Вычитание * Умножение / Деление % Остаток от деления ^ Возведение в степень

13.2.2.4. ➖ **В тестировании API встречаются тест-кейсы, которые проверяют изменение данных в базе. Обычно их тестируют в таком порядке:** - сначала нужно изменить содержимое таблиц в БД: добавить строки с нужными значениями, отредактировать уже существующие записи или удалить лишние. Это делают, чтобы получить определённое состояние БД, которое подходит для тестирования; - затем проходят по шагам тест-кейса; - в последнюю очередь проверяют соответствие ОР и ФР оператором SELECT.

13.2.3. **BETWEEN**

13.2.3.1. **BETWEEN** — это оператор в SQL, который используется для фильтрации данных по диапазону значений. Он возвращает строки, где значение находится между двумя заданными границами (включительно). - **`value1`** — нижняя граница диапазона. - **`value2`** — верхняя граница диапазона.

13.2.3.2. **Ключевые моменты:** 1. **Включительные границы:** Оператор `BETWEEN` включает в себя как нижнюю, так и верхнюю границу диапазона (значения `value1` и `value2`). 2. **Работает с числами, датами и текстом:** Вы можете использовать `BETWEEN` для числовых значений, дат и даже текстовых строк. **Пример с датами в комментах**

13.2.4. **DISTINCT**

13.2.4.1. SQL оператор **DISTINCT** используется для удаления дубликатов из результирующего набора оператора SELECT. SELECT DISTINCT product_name FROM products При выполнении подобного запроса в результате мы получим только уникальные значения, содержащиеся в поле product_name

13.2.4.2. Если в операторе **`DISTINCT`** указано только одно выражение, запрос возвратит уникальные значения для этого выражения. Если в операторе **`DISTINCT`** указано несколько выражений, запрос извлекает уникальные комбинации для перечисленных выражений. В SQL оператор **`DISTINCT`** не игнорирует значения NULL. Поэтому при использовании **`DISTINCT`** в вашем операторе SQL ваш результирующий набор будет содержать значение NULL в качестве отдельного значения.

13.2.5. **LIKE**

13.2.5.1. **`LIKE`** в SQL выполняет функцию оператора, который помогает фильтровать результаты. Оператор **`LIKE` (англ. «подобный»)** находит схожие значения в таблице. Искать можно не только целое слово, но и его часть. Перед оператором **`LIKE`** указывают столбец, в котором нужно искать, а после **`LIKE`** — шаблон для поиска — паттерн. **Паттерн (маска)** — это шаблон, который позволяет найти целую строку по подстроке. Паттерны построены из символов, которые помогают заменить значение. *Например,* знак нижнего подчёркивания _ в паттерне заменяет одно подстановочное значение, то есть 1 символ. Знак процента % заменяет любое количество символов.

13.3. **Операции изменения данных**

13.3.1. **INSERT**

13.3.1.1. Оператор **`INSERT`** используется для добавления новых строк в таблицу базы данных. Он позволяет вставлять данные в одну или несколько колонок таблицы. В запросе **`INSERT`** ключевыми словами являются: **`INSERT INTO`** и **`VALUES`**. - **`INSERT INTO`** указывает, в какую таблицу будут добавлены данные и какие столбцы будут заполнены. - **`VALUES`** определяет значения, которые будут вставлены в указанные столбцы.

13.3.1.2. Таким образом синтаксис запроса с `INSERT` выглядит следующим образом: **Пример 1. Вставка данных в конкретные столбцы:** INSERT INTO products (product_name, product_price, product_count) VALUES ('Microphone', 100, 10); Здесь product_name, product_price, product_count— это столбцы, в которые будут вставлены значения, а Microphone, 100, 10 — это сами значения. **Пример 2. Вставка данных во все столбцы:** INSERT INTO products VALUES ('Microphone', 100, 10); В этом случае значения будут вставлены во все столбцы таблицы. Важно, чтобы количество значений совпадало с количеством столбцов в таблице.

13.3.2. **UPDATE**

13.3.2.1. ➖ Оператор **`UPDATE`** используется для изменения данных в существующих строках таблицы базы данных. Вы можете обновить одно или несколько полей в одной или нескольких строках, соответствующих указанному условию. В запросе **`UPDATE`** ключевыми словами являются: **`UPDATE`, `SET`, и `WHERE`**. - **`UPDATE`** указывает таблицу, в которой будут обновлены данные. - **`SET`** определяет столбцы и значения, которые должны быть обновлены. - **`WHERE`** определяет условие, которому должны соответствовать строки для обновления. Если условие не указано, будут обновлены все строки в таблице.

13.3.2.2. ➖ Таким образом, синтаксис запроса с `UPDATE` выглядит следующим образом: **Пример 1. Обновление строки, соответствующей условию:** UPDATE products SET product_name = 'Headphones', product_price = 150 WHERE product_id = 1; Здесь: - `products`— имя таблицы, в которой обновляются данные. - `product_name` и `product_price` — это столбцы, в которых обновляются значения, а `'Headphones'` и `150` — новые значения, которые будут присвоены. - Условие `product_id = 1` определяет, какую строку нужно обновить. **Пример 2. Обновление всех строк в таблице:** UPDATE products SET product_price = 200; Этот запрос обновляет все строки в таблице products, присваивая столбцу product_price значение 200.

13.3.3. **DELETE**

13.3.3.1. Оператор **`DELETE`** используется для удаления строк из таблицы базы данных. Вы можете удалить определённые строки, соответствующие условию, или удалить все строки из таблицы. В запросе **`DELETE`** ключевыми словами являются: **`DELETE FROM` и `WHERE`**. - **`DELETE FROM`** указывает таблицу, из которой будут удалены данные. - **`WHERE`** определяет условие, которое должны удовлетворять строки для удаления. Если условие не указано, будут удалены все строки в таблице.

13.3.3.2. Таким образом синтаксис запроса с **`DELETE`** выглядит следующим образом: **Пример 1. Удаление строк, соответствующих условию:** DELETE FROM products WHERE product_id = 1; Здесь **products** — это таблица, из которой будут удалены данные, а условие **product_id = 1** определяет, какие строки будут удалены. В данном примере будет удалена строка, где **product_id равно 1**. **Пример 2. Удаление всех строк из таблицы:** DELETE FROM products; Этот запрос удаляет все строки в таблице **products**, не удаляя саму таблицу. Будьте осторожны при использовании этого запроса, так как он полностью очищает таблицу от данных.

13.3.3.3. ❗ **Важные моменты:** - **Использование `WHERE`:** Будьте осторожны при использовании команды **`DELETE`** без **`WHERE`**, так как это приведет к удалению всех данных в таблице. - **Безвозвратное удаление:** После удаления строки, её невозможно восстановить с помощью стандартных SQL-команд, если не была настроена система резервного копирования. Таким образом, команда **`DELETE`** является мощным инструментом для управления данными в таблицах, но требует внимательности при использовании, чтобы избежать случайного удаления важных данных.

13.4. **Агрегирующие функции**

13.4.1. Если вам нужно определить количество строк для среза, объедините функцию **COUNT()** с конструкцией **WHERE**.

13.4.2. ➖ В зависимости от цели количество строк считают по-разному: **COUNT(*)** возвращает общее количество строк в таблице: SELECT COUNT(*) FROM products; **COUNT(product_name)** возвращает число строк в столбце product_name, которые не равны NULL: SELECT COUNT(product_name) FROM products; **COUNT(DISTINCT product_name)** возвращает количество уникальных строк в столбце product_name: SELECT COUNT(DISTINCT product_name) FROM products; Кстати, данный оператор можно использовать и в обычной выборке после слова SELECT, что позволит получить нам только уникальные записи.

13.4.3. ➖ Функция **SUM(column)** возвращает сумму по столбцу column. Когда функция выполняется, пропуски игнорируются. *!Обратите внимание:* функция **SUM()** работает только с числовым форматом данных. **AVG (column)** возвращает среднее значение по столбцу column. SELECT AVG(product_price) FROM products; Минимальное и максимальное значения вычисляют функциями **MIN()** и **MAX()**. SELECT MIN(product_price) FROM products; SELECT MAX(product_price) FROM products; При выполнении подобного запроса в результате мы получим минимальное/максимальное значение в столбце product_price

13.4.4. **MAX**

13.4.4.1. Оператор **MAX** — это агрегатная функция в SQL, которая используется для нахождения наибольшего значения в заданном столбце таблицы. Она возвращает максимальное значение из выбранных строк. Эта функция может применяться к числовым данным, датам или строкам (алфавитный порядок). SELECT MAX(product_price) FROM products WHERE category = 'Electronics'; - **`product_price`** — имя столбца, в котором ищется максимальное значение. - **`products`** — имя таблицы, из которой извлекаются данные. - **`category = 'Electronics'`** — необязательное условие, определяющее, что будут учтены только строки, где категория продукта равна `'Electronics'`.

13.4.5. **MIN**

13.4.5.1. Оператор **MIN** — это агрегатная функция в SQL, которая используется для нахождения наименьшего значения в заданном столбце таблицы. Она возвращает минимальное значение из выбранных строк. Эта функция может применяться к числовым данным, датам или строкам (алфавитный порядок). SELECT MIN(product_price) FROM products WHERE category = 'Electronics'; - **`product_price`** — имя столбца, в котором ищется минимальное значение. - **`products`** — имя таблицы, из которой извлекаются данные. - **`category = 'Electronics'`** — необязательное условие, определяющее, что будут учтены только строки, где категория продукта равна `'Electronics'`.

13.5. **Работа с именами и группами**

13.5.1. **AS**

13.5.1.1. **Оператор AS** в SQL используется для присвоения псевдонимов (имен) столбцам или таблицам в результатах запросов. Псевдонимы делают вывод данных более понятным и читаемым, особенно если исходные имена столбцов или таблиц слишком длинные или сложные. **1. Для столбцов:** SELECT product_name AS item_name, product_price AS price FROM products; В этом примере столбцу **product_name** присваивается псевдоним **item_name**, а столбцу **product_price** — псевдоним **price**. В результате запроса в выводе будут отображаться столбцы с именами **item_name** и **price**. **2. Для таблиц:** SELECT column_name FROM products AS p; В этом примере таблице products присваивается псевдоним p. Это упрощает ссылку на таблицу в запросе, особенно если нужно использовать её несколько раз, например, в сложных запросах с объединением (JOIN).

13.5.2. **HAVING**

13.5.2.1. **Оператор HAVING** в SQL используется для фильтрации групп записей, полученных с помощью агрегатных функций, таких как COUNT, SUM, AVG, MAX, MIN. Он позволяет задавать условия на группы данных после выполнения операции GROUP BY. Оператор HAVING применяется аналогично оператору WHERE, но WHERE используется для фильтрации строк до агрегации, а HAVING — для фильтрации уже агрегированных данных. *Пример в заметках * - **`category`** — имя столбца, по которому выполняется группировка. - **`COUNT(product_id)`** — агрегатная функция, которая считает количество продуктов в каждой категории. - **`products`** — имя таблицы, из которой извлекаются данные. - **`HAVING COUNT(product_id) > 10`** — условие, которое фильтрует категории, где количество продуктов больше 10.

13.6. **Группировка и сортировка данных**

13.6.1. Команду **GROUP BY (англ. «группировать по»)** применяют, когда данные нужно разделить на группы по значениям полей. SELECT category AS product_category, COUNT(product_id) AS product_count FROM products GROUP BY category; После того как вы вызовете агрегирующую функцию, имя столбца выведется в неудобном виде. Чтобы исправить это, применяется команда **AS (англ. «как»)**. После команды **GROUP BY** перечисляют все поля из блока **SELECT**. Саму агрегирующую функцию включать в блок **GROUP BY** не нужно — с ней запрос не выполнится. Конструкцию **GROUP BY** можно применять со всеми агрегирующими функциями: **COUNT(), AVG(), SUM(), MAX(), MIN()**.

13.6.2. ➖ Чтобы сортировать данные по указанным полям, применяют команду **ORDER BY (англ. order by, «упорядочить по»)**. В отличие от **GROUP BY**, в блоке с командой **ORDER BY** нужно перечислить только поля, по которым вы хотите сортировать информацию. У команды **ORDER BY** есть аргумент, регулирующий порядок сортировки в столбцах. Он может принимать такие значения: - **ASC (от англ. ascending, «восходящий»)** сортирует данные в порядке возрастания. Это значение аргумента **ORDER BY** по умолчанию. - **DESC (от англ. descending, «нисходящий»)** сортирует данные по убыванию. Аргументы команды **ORDER BY** указывают сразу после поля, по которому сортировали данные: SELECT category, COUNT(product_id) AS product_count FROM products GROUP BY category ORDER BY product_count DESC;

13.6.3. **LIMIT** в SQL используется для ограничения количества строк, которые возвращаются в результате запроса. Это особенно полезно, когда вам нужно получить только первые несколько строк из таблицы. Пример с **LIMIT 10**: **Задача:** Вывести первых 10 сотрудников из таблицы `employees`. SELECT * FROM employees LIMIT 10; **Результат:** Этот запрос вернет только первые 10 строк из таблицы `employees`.

13.7. **Объединение данных**

13.7.1. **Почему нельзя объединять разные типы данных** SQL является строго типизированным языком, что означает, что каждый столбец или выражение имеет определенный тип данных — например, строка (VARCHAR), число (INT), дата (DATE) и так далее. Когда вы пытаетесь объединить данные разных типов, SQL требует, чтобы эти типы были совместимы друг с другом. Например, если вы попытаетесь объединить строку и число следующим образом: SELECT 'ID: ' + 123 FROM users Этот запрос вызовет ошибку, так как SQL не знает, как корректно объединить строку и число. Различные типы данных хранятся в памяти по-разному, и их объединение может привести к непредсказуемым результатам, поэтому SQL требует, чтобы вы сначала преобразовали данные к одному и тому же типу.

13.7.2. ➖ Как правильно объединять разные типы данных? Чтобы объединить данные разных типов, их нужно привести к общему типу. Наиболее распространенный подход — преобразовать оба значения в строку, поскольку строки могут легко объединяться между собой. Использование **CAST** или **CONVERT** Функции **CAST** и **CONVERT** позволяют явно преобразовать один тип данных в другой. - **CAST**: более стандартная функция, поддерживаемая большинством СУБД. - **CONVERT**: часто используется в SQL Server и позволяет также задать стиль преобразования. - Пример использования **CAST**: SELECT 'ID: ' + CAST(123 AS VARCHAR) FROM users; Этот запрос сначала преобразует число 123 в строку 123, а затем успешно объединяет его с текстом 'ID: '. Пример использования **CONVERT**: SELECT 'ID: ' + CONVERT(VARCHAR, 123) FROM users; Этот запрос делает то же самое, что и предыдущий, но с использованием функции **CONVERT**.

13.7.2.1. ➖ Использование функции **CONCAT** Если вы используете современные версии SQL (например, MySQL, SQL Server, PostgreSQL), то функция **CONCAT** упрощает процесс объединения данных. Она автоматически преобразует все входящие данные в строковый тип. Пример использования **CONCAT**: SELECT CONCAT('ID: ', 123) FROM users; Этот запрос автоматически преобразует число 123 в строку и объединяет его с текстом 'ID: ', без необходимости явно указывать преобразование типов.

13.7.3. **JOIN**

13.7.3.1. ➖ Не всегда удобно идти в одну таблицу, смотреть первичные ключи, и искать их же во второй таблице. Удобнее получить понятный результат с помощью одного запроса. Чтобы это сделать, применяют соединение таблиц — используют оператор **JOIN (англ. «соединять»)**. Таблицы можно соединить через **INNER (англ. «внутренний»)** и **OUTER (англ. «внешний»)**: - Соединение **INNER** возвращает строки строго на пересечении двух таблиц.

13.7.3.1.1. ➖ **INNER JOIN** формирует выборку только из тех данных, у которых выполнено условие присоединения. От порядка присоединения таблиц результат не изменится. Пример структуры запроса с **INNER JOIN**: SELECT orders.order_id, orders.order_date, customers.customer_id, customers.customer_name FROM orders INNER JOIN customers ON orders.customer_id = customers.customer_id; ➖ В этом примере: - **`orders`** и **`customers`** — это две таблицы, которые соединяются. - **`orders.customer_id = customers.customer_id`** — условие соединения, которое определяет, как строки из таблицы `orders` должны сопоставляться со строками из таблицы `customers`. Запрос вернет только те строки, у которых есть совпадение между `customer_id` в таблице `orders` и `customers`. Это означает, что будут выбраны только те заказы, для которых есть информация о соответствующем клиенте.

13.7.3.2. **Различают три вида OUTER JOIN: LEFT, RIGHT и FULL**

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

13.7.3.2.2. **RIGHT OUTER JOIN:** возвращаются все строки правой таблицы. Если у строк правой таблицы выполняется условие соединения, они дополнятся данными левой таблицы. Если есть недостающие данные, вместо строк левой таблицы подставляются NULL-значения. **RIGHT JOIN** — брат-близнец **LEFT JOIN**. Вот только в отличие от него: в результат своей работы он берёт всю правую таблицу, и строки на пересечении с левой, если они соответствуют условию.

13.7.3.2.3. **FULL OUTER JOIN**: возвращаются строки и левой, и правой таблиц. Если у строк левой таблицы и правой таблицы выполняется условие соединения, они объединятся в одну строку. Если есть строки, у которых не выполняется условие соединения, они дополнятся NULL-значениями.

13.8. **Ключи, индексы и транзакции**

13.8.1. **Первичный ключ (Primary Key)**

13.8.1.1. ➖ **Первичный ключ (Primary Key)** в SQL — это специальный столбец или комбинация столбцов в таблице базы данных, который однозначно идентифицирует каждую строку в этой таблице. Он обеспечивает уникальность записей и служит для обеспечения целостности данных. Вот основные моменты, которые стоит знать о первичном ключе: 1. **Уникальность**: Значения в столбце (или столбцах) первичного ключа должны быть уникальными. Это означает, что ни одно значение не может повторяться в этом столбце. 2. **Не допускает NULL**: В столбце первичного ключа не могут быть значения NULL. Каждая строка в таблице должна иметь значение первичного ключа, которое однозначно идентифицирует ее. 3. **Индексы**: SQL автоматически создает индекс на столбец первичного ключа. Это позволяет ускорить поиск и операции, связанные с этим столбцом. 4. **Один первичный ключ на таблицу**: В одной таблице может быть только один первичный ключ. Этот ключ может состоять из одного или нескольких столбцов, но только один первичный ключ. 5. **Примеры использования**: - Если у вас есть таблица с информацией о пользователях, вы можете использовать столбец `user_id` в качестве первичного ключа, чтобы однозначно идентифицировать каждого пользователя. - В таблице заказов столбец `order_id` может быть первичным ключом, чтобы гарантировать, что каждый заказ имеет уникальный идентификатор.

13.8.1.1.1. **Пример создания таблицы с первичным ключом** CREATE TABLE users ( user_id INT PRIMARY KEY, username VARCHAR(50), email VARCHAR(100) ); В этом примере столбец user_id является первичным ключом таблицы users. Каждое значение user_id должно быть уникальным и не может быть NULL.

13.8.1.1.2. **Пример создания первичного ключа на нескольких столбцах** CREATE TABLE orders ( order_id INT, product_id INT, order_date DATE, PRIMARY KEY (order_id, product_id) ); В этом примере первичный ключ составляется из двух столбцов: order_id и product_id. Комбинация значений в этих двух столбцах должна быть уникальной в каждой строке таблицы.

13.8.2. **Вторичный ключ (Foreign Key)**

13.8.2.1. ➖ **Вторичный ключ (Foreign Key)** в SQL — это столбец или комбинация столбцов, которые создают связь между двумя таблицами в базе данных. Он используется для обеспечения целостности данных и создания отношений между таблицами. Вот основные моменты, кото рые стоит знать о втор ичном ключе: 1. **Создание связи**: Вторичный ключ в одной таблице указывает на первичный ключ в другой таблице. Это связывает строки в одной таблице со строками в другой таблице, устанавливая отношение между ними. 2. * *Поддержание целостности данных**: Вторичные ключи помогают поддерживать ссылочную целостность. Это означает, что значение вторичного ключа должно совпадать с одним из значений первичного ключа в связанной таблице или быть NULL (если это разрешено). 3. **Ограничение целостности (Constraints)**: При создании вторичного ключа можно задать ограничения, такие как `ON DELETE CASCADE`, чтобы определить, что произойдет с записями в зависимой таблице, если запись в родительской таблице будет удалена. 4 . **Множественные связи**: В одной таблице может быть несколько вторичных ключей, которые ссылаются на разные таблицы. 5 . **Примеры использования**: - В таблице `orders` может быть столбец `user_id`, который является вторичным ключом и ссылается на первичный ключ `user_id` в таблице `users`. Это позволяет связывать заказы с пользователями. - В таблице `order_items` столбец `order_id` может быть вторичным ключом, ссылающимся на столбец `order_id` в таблице `orders`, что связывает конкретные товары с заказами.

13.8.2.1.1. **Пример создания таблицы с вторичным ключом** CREATE TABLE orders ( order_id INT PRIMARY KEY, user_id INT, order_date DATE, FOREIGN KEY (user_id) REFERENCES users(user_id) ); В этом примере столбец user_id в таблице orders является вторичным ключом, который ссылается на столбец user_id в таблице users. Это связывает заказы с пользователями.

13.8.2.1.2. **Пример использования ограничения ON DELETE CASCADE** CREATE TABLE order_items ( item_id INT PRIMARY KEY, order_id INT, product_id INT, quantity INT, FOREIGN KEY (order_id) REFERENCES orders(order_id) ON DELETE CASCADE ); В этом примере столбец order_id является вторичным ключом, который ссылается на order_id в таблице orders. Если заказ будет удален из таблицы orders, связанные с ним строки в таблице order_items также будут автоматически удалены благодаря использованию ON DELETE CASCADE.

13.8.3. **Индексы**

13.8.3.1. ➖ **Индекс** в SQL — это специализированная структура данных, которая улучшает скорость выполнения запросов к базе данных. Индексы создаются на столбцах таблицы для быстрого поиска и доступа к данным без необходимости сканирования всей таблицы. **Основные моменты:** 1. **Ускорение поиска данных**: Индексы позволяют быстро находить строки, соответствующие условиям запроса, что значительно улучшает производительность базы данных. 2. **Создание индекса**: Индексы могут создаваться на одном столбце или на комбинации столбцов. SQL автоматически создает индексы на столбцах первичных ключей, но индексы могут быть созданы и на других столбцах для улучшения производительности. 3. **Влияние на производительность операций записи**: Хотя индексы ускоряют операции чтения (запросы SELECT), они могут замедлить операции записи (INSERT, UPDATE, DELETE), поскольку индекс также должен быть обновлен каждый раз, когда изменяются данные в столбцах, на которых он создан. 4. **Виды индексов**: - **Уникальные индексы (Unique Indexes)**: Индексы, которые гарантируют, что все значения в индексе уникальны. - **Композитные индексы (Composite Indexes)**: Индексы, созданные на нескольких столбцах таблицы. - **Кластерные индексы (Clustered Indexes)**: Индексы, которые определяют физический порядок данных в таблице. - **Некластерные индексы (Non-Clustered Indexes)**: Индексы, которые не изменяют физический порядок данных, но создают отдельную структуру данных для быстрого поиска.

13.8.3.1.1. **Пример использования индексов** CREATE INDEX idx_customer_name ON customers(name); Этот пример создает индекс на столбце name в таблице customers. Теперь поиск по имени в этой таблице будет выполняться быстрее.

13.8.4. **NULL**

13.8.4.1. ➖ **NULL** — это специальное значение в SQL, которое обозначает отсутствие данных или значения. Это не то же самое, что 0 или пустая строка; NULL указывает на то, что значение неизвестно или не было указано. **Основные моменты:** 1. **Отсутствие значения**: NULL используется для обозначения, что в данной ячейке таблицы отсутствует значение. Например, если в базе данных хранится информация о клиентах, и для некоторого клиента не указана дата рождения, то в соответствующем поле будет стоять NULL. 2. **NULL в выражениях**: При использовании NULL в выражениях SQL, результат выражения будет NULL, если хотя бы одно из участвующих значений равно NULL. Например, `5 + NULL` вернет NULL. 3. **Сравнение с NULL**: Обычные операторы сравнения (например, `=`, `<>`, `<`, `>`) не работают с NULL. Для проверки значения на NULL нужно использовать специальные операторы `IS NULL` или `IS NOT NULL`. 4. **Работа с NULL в агрегатных функциях**: Агрегатные функции, такие как `COUNT`, `SUM`, `AVG`, `MIN`, `MAX`, обычно игнорируют NULL. Например, при подсчете среднего значения с помощью `AVG`, строки с NULL не будут учитываться.

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

13.8.5. **Транзакции**

13.8.5.1. ➖ **Транзакции** — это важный механизм в базах данных, который обеспечивает целостность и согласованность данных. Транзакция представляет собой последовательность одной или нескольких операций с базой данных, которые выполняются как единое целое. Это значит, что все операции внутри транзакции либо выполняются полностью, либо не выполняются вообще. **Основные свойства транзакций (ACID):** 1. **Атомарность (Atomicity):** Все операции в транзакции рассматриваются как единое целое. Если одна из операций не может быть выполнена, то транзакция отменяется, и все изменения, внесенные до этого момента, откатываются. 2. **Согласованность (Consistency):** Транзакция переводит базу данных из одного согласованного состояния в другое. Это означает, что все правила и ограничения, установленные в базе данных, соблюдаются. 3. **Изоляция (Isolation):** Изоляция гарантирует, что результаты транзакции не будут видны другим транзакциям до завершения текущей транзакции. Это предотвращает влияние одной транзакции на другую. 4. **Долговечность (Durability):** После завершения транзакции ее результаты сохраняются и становятся постоянными, даже если система выйдет из строя.

13.8.5.1.1. **Пример использования транзакций:** ➖ Представьте, что вы переводите деньги с одного банковского счета на другой. Эта операция должна включать два шага: 1. Списание суммы с одного счета. 2. Зачисление этой суммы на другой счет. Оба шага должны быть выполнены как одна транзакция. Если первый шаг прошел успешно, а второй нет, система должна откатить изменения и вернуть деньги на исходный счет. BEGIN TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE account_id = 1; UPDATE accounts SET balance = balance + 100 WHERE account_id = 2; COMMIT; Если возникает ошибка на каком-либо этапе транзакции, система выполнит **ROLLBACK**, и никакие изменения в базе данных не будут зафиксированы.

13.9. **Операторы DDL (Data Definition Language)**

13.9.1. Операторы DDL используются для определения и изменения структуры базы данных. Они позволяют создавать, изменять и удалять объекты базы данных, такие как таблицы, индексы и схемы.

13.9.1.1. **CREATE TABLE**

13.9.1.1.1. ➖ **Описание:** Оператор **CREATE TABLE** используется для создания новой таблицы в базе данных. Вы можете определить структуру таблицы, указав имена столбцов и их типы данных. **Пример использования:** CREATE TABLE products ( product_id INT PRIMARY KEY, product_name VARCHAR(100), price DECIMAL(10, 2) ); - **`VARCHAR(100)`** — тип данных для хранения строк, где 100 — максимальная длина строки. - **`DECIMAL(10, 2)`** — тип данных для хранения чисел с плавающей точкой, где 10 — общее количество цифр, а 2 — количество цифр после запятой.

13.9.1.2. **ALTER TABLE**

13.9.1.2.1. ➖ **Описание:** Оператор **ALTER TABLE** используется для изменения структуры существующей таблицы. Вы можете добавлять, удалять или изменять столбцы, а также добавлять или удалять ограничения. **Пример использования:** ALTER TABLE products ADD description VARCHAR(255); Этот запрос добавляет новый столбец description в таблицу products.

13.9.1.3. **DROP TABLE**

13.9.1.3.1. **Описание:** Оператор **DROP TABLE** используется для удаления существующей таблицы и всех данных в ней из базы данных. **Пример использования:** DROP TABLE products; Этот запрос удаляет таблицу products из базы данных.

13.9.1.4. **CREATE INDEX**

13.9.1.4.1. **Описание:** Оператор **CREATE INDEX** используется для создания индекса на одном или нескольких столбцах таблицы. Индексы ускоряют выполнение запросов, особенно при сортировке и фильтрации данных. CREATE INDEX idx_product_name ON products (product_name); Этот запрос создает индекс idx_product_name на столбце product_name в таблице products.

13.9.1.5. **DROP INDEX**

13.9.1.5.1. ➖ **Описание:** Оператор **DROP INDEX** используется для удаления индекса из таблицы. Индексы могут быть удалены, если они больше не нужны или если они были созданы по ошибке. **Пример использования:** DROP INDEX idx_product_name ON products; Этот запрос удаляет индекс idx_product_name из таблицы products.

13.9.1.6. **TRUNCATE TABLE**

13.9.1.6.1. ➖ **Описание:** Оператор **TRUNCATE TABLE** используется для удаления всех строк из таблицы, но не удаляет саму таблицу. Это быстрый способ очистить таблицу, так как не производит логгирование отдельных операций удаления. **Пример использования:** TRUNCATE TABLE products; Этот запрос удаляет все данные из таблицы products, но сохраняет структуру таблицы.

13.10. **Базы данных**

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

13.10.2. **Основные компоненты баз данных**

13.10.2.1. 1. **Данные:** Это информация, которая хранится в базе данных. Данные могут быть любого типа — текстовые, числовые, мультимедийные и т.д. 2. **Таблицы:** Основная структура хранения данных в реляционных базах данных. Таблица состоит из строк (записей) и столбцов (полей), где каждый столбец хранит данные определенного типа (например, имена, даты, числа). 3. **Первичный ключ (Primary Key):** Уникальный идентификатор записи в таблице. Это значение, которое однозначно определяет каждую запись. 4. **Вторичный ключ (Foreign Key):** Поле в таблице, которое указывает на первичный ключ другой таблицы, создавая связь между двумя таблицами. 5. **Индексы:** Специальные структуры, которые ускоряют поиск данных в базе. Индексы создаются на основе столбцов таблицы и позволяют быстрее находить нужные записи. 6. **Триггеры:** Это специальные процедуры, которые автоматически выполняются при выполнении определенных операций с данными (например, вставка, обновление, удаление). 7. **Представления (Views):** Это виртуальные таблицы, которые позволяют представлять данные в удобном для пользователя виде. Представления могут включать данные из одной или нескольких таблиц. 8. **Хранимые процедуры:** Это наборы SQL-запросов, сохраненные в базе данных и выполняемые как одна единица. Хранимые процедуры помогают автоматизировать повторяющиеся задачи и сложные операции с данными. 9. **Транзакции**: это последовательность операций, выполняемых как единое целое. Если хотя бы одна операция в транзакции не выполняется успешно, все остальные операции также отменяются (откатываются), чтобы сохранить целостность данных.

13.10.3. **Типы баз данных**

13.10.3.1. **Реляционные базы данных (RDBMS):**

13.10.3.1.1. **Реляционные базы данных (RDBMS)** — это тип базы данных, в котором данные хранятся в виде таблиц, состоящих из строк и столбцов. Главная идея реляционной модели заключается в том, что данные организуются в виде наборов связанных таблиц, а связи между этими таблицами устанавливаются через ключи.

13.10.3.1.2. - **Основные понятия реляционных баз данных** - **Таблица:** Основная структура хранения данных в реляционной базе данных. Каждая таблица состоит из строк (записей) и столбцов (полей). Каждая строка представляет отдельную запись, а каждый столбец — атрибут этой записи. - **Строка (Запись):** Одна запись в таблице, представляющая собой набор связанных данных. Например, в таблице "Сотрудники" строка может представлять одного сотрудника с его именем, фамилией, должностью и зарплатой. - **Столбец (Поле):** Атрибут или характеристика данных в таблице. Например, в таблице "Сотрудники" столбцы могут включать такие поля, как "Имя", "Фамилия", "Должность", "Зарплата". - **Первичный ключ (Primary Key):** Уникальный идентификатор для каждой записи в таблице. Этот ключ гарантирует, что каждая запись в таблице уникальна. Например, столбец "ID сотрудника" может быть первичным ключом. - **Вторичный ключ (Foreign Key):** Поле в одной таблице, которое ссылается на первичный ключ другой таблицы. Это создает связь между двумя таблицами. Например, в таблице "Заказы" поле "ID клиента" может быть вторичным ключом, ссылающимся на "ID клиента" в таблице "Клиенты". - **Связь (Relationship):** Логическая связь между таблицами. В реляционных базах данных существуют различные типы связей, такие как "один-к-одному", "один-ко-многим" и "многие-ко-многим". - **SQL (Structured Query Language):** Язык запросов, используемый для управления данными в реляционных базах данных. С помощью SQL можно создавать, изменять, удалять таблицы, а также выполнять операции над данными (поиск, вставка, обновление, удаление).

13.10.3.1.3. **Преимущества реляционных баз данных** - **Структурированность данных:** Данные в реляционных базах данных организованы в четкую и логическую структуру, что облегчает их понимание и управление. - **Целостность данных:** Использование первичных и вторичных ключей помогает поддерживать целостность данных и предотвращает несоответствия. - **Гибкость запросов:** SQL позволяет легко выполнять сложные запросы для поиска, фильтрации и агрегации данных. - **Безопасность:** Реляционные базы данных обеспечивают контроль доступа, позволяя ограничить доступ к данным для различных пользователей.

13.10.3.1.4. **Примеры реляционных баз данных** - **MySQL:** Одна из самых популярных реляционных баз данных, широко используемая в веб-разработке. - **PostgreSQL:** Открытая реляционная база данных с мощными возможностями, включая поддержку сложных запросов и расширений. - **Oracle Database:** Коммерческая реляционная база данных, известная своими высокими показателями производительности и безопасности. - **Microsoft SQL Server:** Реляционная база данных от Microsoft, часто используемая в корпоративных средах.

13.10.3.2. **Нереляционные базы данных(NoSQL)**

13.10.3.2.1. **Нереляционные базы данных (NoSQL)** — это тип баз данных, который отличается от традиционных реляционных баз данных тем, что не использует фиксированные таблицы с строками и столбцами. NoSQL базы данных предназначены для работы с большими объемами данных, высокой скоростью обработки и гибкой структурой данных. Они часто используются в случаях, когда реляционные базы данных не могут обеспечить достаточную производительность или гибкость.

13.10.3.2.2. **Основные типы NoSQL баз данных:** 1. **Документно-ориентированные базы данных:** - **Описание:** Хранят данные в виде документов, обычно в формате JSON, BSON или XML. Каждый документ может содержать сложные и вложенные структуры данных, такие как списки и другие документы. - **Примеры:** MongoDB, CouchDB. - **Применение:** Используются для хранения данных, которые могут изменяться по структуре и не требуют жесткой схемы. Например, для хранения данных пользователей, продуктов, заказов. 2. **Базы данных типа "ключ-значение":** - **Описание:** Хранят данные в виде пар "ключ-значение". Ключи уникальны и используются для быстрого доступа к значениям. - **Примеры:** Redis, Amazon DynamoDB, Riak. - **Применение:** Идеальны для приложений, где требуется быстрое чтение и запись данных, таких как кэширование, управление сессиями, хранение настроек. 3. **Графовые базы данных:** - **Описание:** Хранят данные в виде узлов, ребер и свойств. Узлы представляют собой объекты, а ребра — связи между этими объектами. - **Примеры:** Neo4j, OrientDB, ArangoDB. - **Применение:** Используются для работы с сильно связанными данными, такими как социальные сети, управление сетями, рекомендационные системы. 4. **Колонко-ориентированные базы данных:** - **Описание:** Хранят данные по столбцам вместо строк. Это позволяет эффективно сжимать данные и быстро выполнять запросы на агрегирование. - **Примеры:** Apache Cassandra, HBase. - **Применение:** Подходят для аналитики больших объемов данных, где необходимо быстро выполнять операции над большими наборами данных.

13.10.3.2.3. **Преимущества NoSQL баз данных** - **Гибкость структуры данных:** NoSQL базы данных не требуют заранее определенной схемы, что позволяет легко изменять структуру данных по мере их роста и изменения требований. - **Высокая производительность:** NoSQL базы данных оптимизированы для быстрого чтения и записи данных, что делает их подходящими для работы с большими объемами данных и высоким уровнем параллельных запросов. - **Масштабируемость:** NoSQL базы данных легко масштабируются горизонтально, что позволяет распределять данные и нагрузку между множеством серверов. - **Поддержка больших данных:** NoSQL базы данных могут эффективно работать с неструктурированными и полуструктурированными данными, такими как мультимедиа, журналы событий и данные IoT.

13.10.3.2.4. **Примеры использования NoSQL баз данных:** - **Социальные сети:** Хранение и обработка данных пользователей, их связей, постов и комментариев. - **Рекомендационные системы:** Управление связями между пользователями и продуктами для предоставления персонализированных рекомендаций. - **Интернет-магазины:** Хранение информации о товарах, заказах, корзинах и историях покупок. - **Кэширование данных:** Быстрое хранение и доступ к часто запрашиваемым данным для повышения производительности приложений.

13.10.4. **Зачем нужны базы данных?** - **Хранение данных:** Базы данных обеспечивают надежное хранение данных, предотвращая их потерю или повреждение. - **Управление данными:** Базы данных предоставляют мощные инструменты для управления данными, включая их сортировку, фильтрацию и агрегацию. - **Поиск и извлечение данных:** Базы данных позволяют быстро и эффективно находить нужную информацию. - **Безопасность:** Базы данных обеспечивают контроль доступа к данным, защищая их от несанкционированного использования. - **Масштабируемость:** Базы данных могут обрабатывать огромные объемы данных и поддерживать большое количество пользователей одновременно.

14. **Devops - Ci/cd, Docker, Kuber**

14.1. **Ci/cd**

14.1.1. 💡 **CI/CD (Continuous Integration/Continuous Deployment)** — это практика в разработке программного обеспечения, которая включает непрерывную интеграцию и непрерывную доставку или развертывание кода. Она позволяет командам автоматизировать процесс сборки, тестирования и развертывания, обеспечивая быструю и надежную доставку изменений в коде. **CI (Continuous Integration)** — это процесс, при котором изменения в коде регулярно интегрируются в общую кодовую базу. Каждый коммит разработчиков автоматически проверяется с помощью набора тестов, чтобы выявить ошибки на ранних этапах. CI помогает снизить риск конфликтов при интеграции кода и обеспечивает, что кодовая база всегда находится в стабильном состоянии. **CD (Continuous Delivery)** — это практика, при которой изменения, прошедшие автоматическое тестирование, могут быть автоматически подготовлены к развертыванию на сервере. Этот процесс включает дополнительные проверки, такие как ручное утверждение релиза, чтобы убедиться, что код готов к выпуску. **CD (Continuous Deployment)** — это еще один этап автоматизации, при котором код, прошедший все проверки, автоматически разворачивается на продакшен. Это исключает необходимость ручного вмешательства в процесс развертывания, обеспечивая быструю и частую доставку новых функций пользователям. Все это происходит параллельно с другими задачами. Правильно настроенный CI/CD гарантирует, что ничего не сломается, когда все будут пушить свой код.

14.1.2. **Какие инструменты относятся к этому подходу:** CI- Team city, Jenkins, bamboo, Гитлаб CI CD - DOCKER, KUBER

14.1.3. **Что такое пайплайн?** Можно перевести как “конвейер” - он настроен так, что в нем есть несколько этапов, которые выполняются последовательно один за другим, все эти настройки пишутся в файлике. Мы можем настроить пайплайн таким образом, что когда мы заливаем код в определенную ветку, у нас триггерится —> процесс сборки приложения, которые в случае успеха —>запускают тесты—> приложение деплоится на определенном серваке, например на тесте.

14.1.3.1. **Как изображают Pipeline**

14.1.3.1.1. Plan

14.1.3.1.2. Code

14.1.3.1.3. Build

14.1.3.1.4. Test

14.1.3.1.5. Release

14.1.3.1.6. Deploy

14.1.3.1.7. Operate

14.1.4. **Дженкенс**

14.1.4.1. **Jenkins** — это инструмент для автоматизации процессов, в первую очередь, для автоматизации сборки, тестирования и развертывания программного обеспечения. Он активно используется для реализации концепции CI/CD (Continuous Integration и Continuous Delivery), что позволяет ускорить и упростить процесс разработки и доставки программных продуктов.

14.1.4.2. **Ключевые моменты:** 1. **Автоматизация задач**: Jenkins позволяет автоматизировать повторяющиеся задачи, такие как сборка проекта, тестирование кода, развертывание приложений и проверка качества кода. 2. **Интеграция с различными инструментами**: Jenkins поддерживает огромное количество плагинов для интеграции с другими инструментами (Git, Docker, Kubernetes, Maven, Gradle, Selenium и многие другие). 3. **Open Source**: Jenkins — это бесплатный инструмент с открытым исходным кодом, что делает его доступным и гибким для настройки под любые потребности. 4. **Масштабируемость**: Jenkins легко масштабируется для работы в больших командах и проектах, можно настраивать распределённые сборки, когда разные задачи выполняются на разных серверах.

14.1.5. **Деплой** — это процесс развертывания или внедрения изменений в приложении, сервисе или системе в целевой среде. Целевые среды могут включать в себя: рабочую среду (production), тестовую среду (staging), среду разработки (development) и другие. Процесс деплоя включает в себя несколько этапов.

14.1.5.1. **Основные этапы деплоя:** 1. **Сборка (Build):** - Код, написанный разработчиками, компилируется и собирается в исполняемые файлы или контейнеры. На этом этапе также могут выполняться автоматические тесты, чтобы убедиться в отсутствии ошибок. 2. **Тестирование (Testing):** - После сборки артефактов они развертываются в тестовой среде, где проходят более детальные тесты, включая интеграционные и нагрузочные тесты. Это позволяет убедиться, что приложение работает корректно и стабильно. 3. **Упаковка (Packaging):** - Скомпилированный код и его зависимости упаковываются в артефакты, такие как контейнеры Docker или WAR-файлы, которые будут развернуты в целевой среде. 4. **Развертывание (Deployment):** - После успешного прохождения тестов артефакты развертываются на серверах в целевой среде. В случае с микросервисной архитектурой, это может включать развертывание отдельных сервисов в контейнеры, управляемые оркестраторами, такими как Kubernetes. 5. **Мониторинг и проверка (Monitoring and Verification):** - После развертывания проводится мониторинг работы приложения, чтобы убедиться в его стабильности и работоспособности. Это может включать проверку логов, мониторинг производительности и отзывов пользователей. 6. **Откат (Rollback), если требуется:** - В случае возникновения проблем после деплоя, может быть выполнен откат к предыдущей версии приложения. Это важно для минимизации влияния багов или других непредвиденных проблем на пользователей.

14.1.6. **Репозиторий** — это место для хранения, управления и отслеживания кода и его изменений.

14.1.7. **Джобы (Jobs)** в контексте CI/CD (Continuous Integration/Continuous Deployment) — это отдельные задачи или этапы, которые выполняются в рамках конвейера (pipeline) автоматизированной сборки и доставки программного обеспечения. Каждая джоба представляет собой конкретное действие, такое как сборка кода, запуск тестов, развертывание приложения или проверка безопасности.

14.1.8. **Artifact** — это файл или набор файлов, которые являются результатом одного из этапов CI/CD pipeline, например, скомпилированный код, сгенерированная документация или Docker-образ.

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

14.1.10. **GitFlow** — это популярная модель управления ветками в Git, которая помогает организовать процесс разработки, тестирования и выпуска новых версий программного обеспечения. В этой модели используются несколько типов веток, каждая из которых имеет своё предназначение.

14.1.10.1. **Как код попадает в ветки Разработки и Тестирования:** 1. **Создание фича ветки**: Разработчик, получив задачу, создает новую фича ветку из ветки **`develop`**. Эта ветка может называться, например, **`feature/new-login-page`**, что говорит о том, что в этой ветке разрабатывается новая страница логина. 2. **Разработка**: Ветвь **`feature`** является изолированной от основной ветки разработки **(`develop`)**, и разработчик может вносить изменения, не опасаясь сломать что-то в основной ветке. После завершения работы разработчик делает commit и push изменений в фича ветку. 3. **Код-ревью и тестирование**: Когда разработка завершена, создаётся pull request (PR) из фича ветки в **`develop`**. Этот PR проходит код-ревью, а также запускаются автоматические тесты. Если всё проходит успешно, фича ветка сливается с веткой **`develop`**. 4. **Подготовка к релизу**: Когда достаточно много изменений накопилось в ветке **`develop`**, или наступил срок релиза, создаётся новая ветка релиза **(`release`)**. Здесь проводятся финальные тесты и вносятся мелкие правки. Если баги находят, их исправляют прямо в ветке релиза. 5. **Релиз**: После успешного завершения тестов, код из ветки релиза сливается в ветку **`main`** (или **`master`**). После этого релиз становится доступным пользователям. Параллельно ветка релиза сливается обратно в **`develop`**, чтобы все исправления были учтены в дальнейшем процессе разработки. 6. **Горячие исправления (Hotfix)**: Если после релиза обнаруживается критический баг, создаётся ветка **`hotfix`** из ветки **`main`**. Исправление делается в этой ветке и затем сливается обратно как в **`main`**, так и в **`develop`**.

14.1.11. **Крон джоба (cron job)** — это задача, которая автоматически выполняется в определенное время или через определенные промежутки времени на сервере. Cron — это системный планировщик задач в Unix-подобных операционных системах (таких как Linux), который позволяет пользователю настроить регулярное выполнение команд или скриптов.

14.1.11.1. **Как работает:** - Cron job состоит из расписания (минуты, часы, дни, месяцы, дни недели) и команды, которую нужно выполнить. - Cron демон (фоновой процесс) постоянно проверяет файл crontab и запускает задачи в нужное время.

14.1.12. **Canary Release (Канареечный релиз)** — это стратегия развертывания, при которой новая версия приложения сначала развертывается на небольшой группе пользователей (канарейках). Если не выявляется проблем, новая версия разворачивается на всех пользователей.

14.2. **Docker**

14.2.1. **Docker 🐳** — это такой инструмент, который упаковывает код приложений, системные инструменты, среду выполнения, библиотеки, зависимости и файлы конфигурации в виртуальный контейнер, который сможет работать на любом компьютере (линукс макбук или винда), на котором установлен докер.

14.2.1.1. **Изоляция среды:** Docker позволяет запустить каждый компонент вашего приложения в изолированном контейнере. Например, сервер на Python может работать в одном контейнере, база данных — в другом, и так далее. Все контейнеры могут взаимодействовать друг с другом, как если бы они находились на одной машине, но при этом они полностью изолированы друг от друга и от основной операционной системы.

14.2.1.2. **Портативность:** Контейнеры Docker могут быть развернуты на любом сервере, где установлен Docker, независимо от операционной системы. Это значит, что вы можете разрабатывать на Windows, тестировать на Mac, а развертывать на Linux — и все это без необходимости беспокоиться о совместимости программного обеспечения.

14.2.1.3. **Docker** — это платформа для создания и запуска изолированных контейнеров, содержащих приложение со всеми зависимостями, гарантируя их работу в единообразной среде на разных системах.

14.2.2. **Окружение (Environment) в Разработке**

14.2.2.1. **Окружение** — это совокупность всех компонентов и настроек, необходимых для выполнения и тестирования приложения. В контексте разработки программного обеспечения окружения создаются для разных этапов жизненного цикла приложения, таких как разработка, тестирование, демонстрация и эксплуатация.

14.2.2.2. **Основные Типы Окружений** 1. **Локальное окружение (Local Environment):** - **Описание:** Окружение, установленное на машине разработчика. Здесь разработчики пишут код, тестируют и отлаживают его до того, как отправить на другие уровни. - **Пример:** Установленный на ноутбуке разработчика сервер с необходимыми базами данных и инструментами, такими как Docker или VirtualBox. 2. **Окружение разработки (Development Environment, Dev):** - **Описание:** Общая среда для всей команды разработчиков, где они могут интегрировать и тестировать свой код. Это окружение часто используется для того, чтобы убедиться, что код работает правильно до его переноса на тестовые сервера. - **Пример:** Сервер разработки, на котором интегрируются изменения от нескольких разработчиков для проверки совместимости и общего тестирования. 3. **Тестовое окружение (Testing Environment, Test/Staging):** - **Описание:** Окружение, максимально приближенное к боевому (production) окружению, используется для тестирования приложения перед его развертыванием. Здесь проводят функциональное, интеграционное, нагрузочное и регрессионное тестирование. - **Пример:** Клон боевого окружения, где тестировщики проводят проверку всех функций приложения, чтобы убедиться в его готовности к релизу. 4. **Демонстрационное окружение (пред прод) (Demo/QA Environment):** - **Описание:** Среда, в которой приложение показывается заинтересованным сторонам или клиентам для предварительного ознакомления и получения обратной связи перед финальным релизом. - **Пример:** Сервер, на котором развернута версия приложения, готовая для демонстрации клиентам или руководству. 5. **Боевое окружение(прод) (Production Environment, Prod):** - **Описание:** Основное окружение, где приложение используется конечными пользователями. Здесь система должна работать стабильно и без сбоев, так как это окружение напрямую влияет на клиентов. - **Пример:** Реальный сервер, где развернута финальная версия приложения, доступная для всех пользователей.

14.2.3. **Основные понятия**

14.2.3.1. **Виртуальные машины**

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

14.2.3.2. **Контейнеры 📦**

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

14.2.3.3. **Образы**

14.2.3.3.1. **Образ** — это шаблон или инструкция, которая содержит все необходимые файлы, библиотеки и настройки для создания контейнера. Он статичен и не выполняется. **Пример:** В Docker образ может быть создан из файла Dockerfile, который описывает инструкции по сборке образа, включая установку зависимостей и настройку окружения. Например, образ может включать в себя операционную систему, веб-сервер и ваше приложение.

14.2.3.4. **⚙Из чего состоит docker 🐳**

14.2.3.4.1. **1. Docker Engine:** - **Описание:** Это основной движок Docker, который отвечает за управление контейнерами. Он включает в себя серверную часть (Docker Daemon), которая обрабатывает Docker API-запросы и управляет контейнерами, а также клиентскую часть, которая позволяет пользователям взаимодействовать с Docker через командную строку. - **Основные компоненты:** - **Docker Daemon (`dockerd`):** Это сервис, который выполняется на фоне и управляет контейнерами Docker. Он обрабатывает команды от Docker CLI и взаимодействует с контейнерами. - **Docker CLI:** Это интерфейс командной строки, который позволяет пользователям выполнять команды Docker для создания, управления и мониторинга контейнеров.

14.2.3.4.2. **2. Dockerfile:** **Описание:** Это текстовый файл, содержащий последовательность инструкций для создания Docker-образа (или image). В Dockerfile описываются базовый образ, команды для установки программ, копирования файлов и настройки окружения. **Пример:** FROM ubuntu:latest RUN apt-get update && apt-get install -y nginx COPY . /usr/share/nginx/html CMD ["nginx", "-g", "daemon off;"]

14.2.3.4.3. **3. Образы (Images):** **Описание:** Docker-образы — это неизменяемые шаблоны, которые включают всё необходимое для запуска контейнера: операционную систему, приложения, библиотеки, зависимости и конфигурации. Образы могут быть основаны на других образах, позволяя создавать цепочки изменений (слои). **Основные компоненты:** **Слои (Layers):** Каждый образ состоит из нескольких слоёв, которые накладываются друг на друга. Каждый слой представляет собой разницу (diff) по сравнению с предыдущим слоем. Это позволяет Docker эффективно использовать дисковое пространство и повторно использовать слои.

14.2.3.4.4. **4. Контейнеры:** **Описание:** Контейнеры — это запущенные экземпляры Docker-образов. Они изолированы от системы хоста и других контейнеров, что позволяет запускать несколько контейнеров на одном хосте без конфликта между ними. **Основные компоненты:** **Изоляция:** Контейнеры изолированы с помощью таких технологий, как namespaces (имена пространств) и cgroups (контрольные группы), что обеспечивает независимость процессов внутри контейнера от системы хоста.

14.2.3.4.5. **5. Тома (Volumes):** **Описание:** Тома используются для сохранения данных вне контейнеров, что позволяет сохранить данные даже после завершения работы контейнера. Это особенно важно для баз данных и других приложений, где нужно сохранять состояние. **Пример использования:** docker run -v /my/own/datadir:/var/lib/postgresql/data postgres

14.2.3.4.6. **6. Docker Compose:** **Описание:** Docker Compose — это инструмент, который позволяет управлять многоконтейнерными приложениями. С его помощью можно определять и запускать связанные контейнеры из одного YAML-файла. **Пример:** version: '3' services: web: image: nginx ports: - "8080:80" db: image: postgres environment: POSTGRES_PASSWORD: example

14.2.3.4.7. **7. Сетевые драйверы (Networking):** **Описание:** Docker позволяет контейнерам взаимодействовать друг с другом и с внешним миром через различные сетевые драйверы, такие как bridge, host, overlay и др. **Основные компоненты:** **Bridge Network:** Стандартная сеть по умолчанию, которая создаётся при запуске контейнера. Контейнеры, подключённые к bridge-сети, могут взаимодействовать друг с другом. **Overlay Network:** Сеть, используемая для объединения нескольких Docker-демонов, что особенно полезно в кластерах Docker Swarm.

14.2.3.4.8. **8. Docker Hub:** **Описание:** Docker Hub — это облачное хранилище образов, где можно найти готовые образы, созданные сообществом или официальные образы от разработчиков. Пользователи могут также загружать свои образы в Docker Hub для совместного использования. **Основные функции:** **Публичные и приватные репозитории:** Хранение образов, доступных для всех или только для вас и вашей команды. **Автоматизация сборок:** Автоматическая сборка образов на основе изменений в репозиториях кода, таких как GitHub.

14.2.3.5. **Базовые команды:**

14.2.3.5.1. **Проверить, что Docker установлен, можно с помощью команды:** docker -v

14.2.3.5.2. **Запустить контейнер можно командой:** docker run <метка образа> **Например, для запуска Ubuntu:** docker run ubuntu

14.2.3.5.3. **Для запуска контейнера в интерактивном режиме используется ключ it:** docker run -it ubuntu

14.2.3.5.4. **Выйти из контейнера можно командой:** exit

14.2.3.5.5. **Посмотреть работающие контейнеры можно командой:** docker ps

14.2.3.5.6. **Посмотреть все образы можно командой:** docker images

14.2.3.5.7. **Присоединиться к работающему контейнеру можно командой attach (необходимо указать ID контейнера):** docker attach <container_id>

14.2.3.5.8. **Остановить контейнер можно командой:** docker stop <container_id>

14.2.3.5.9. **Запустить контейнер можно командой:** docker start <container_id>

14.2.3.5.10. **Чтобы запустить контейнер с открытым портом, нужно передать флаг p и указать, какой порт операционной системы переадресовать в открытый порт контейнера (через двоеточие):** docker run -p 8888:80 nginx

14.3. **Оркестрация 🥁(Kubernetes)**

14.3.1. **Kubernetes (k8s)🥁** — это система для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями. Работает как оркестратор контейнеров. Поддерживает множество container runtime (Docker, containerd, CRI-O).

14.3.2. **Основные объекты Kubernetes** Kubernetes оперирует с объектами, которые представляют различные аспекты инфраструктуры и приложений.

14.3.2.1. **Из чего состоит кубер:**

14.3.2.1.1. **Pod**

14.3.2.1.2. **Node**

14.3.2.1.3. **Service**

14.3.2.1.4. **Namespace**

14.3.2.1.5. **Deployment**

14.3.2.1.6. **ConfigMap и Secret**

14.3.2.1.7. **Класстер кубернетес**

15. **Continuous Integration**

16. **Continuous Deployment**

17. **Брокеры сообщений или работа с очередью (Kafka, rabbit MQ)**

17.1. **Разница между синхронным общением и асинхронным**

17.1.1. Обычно общение микросервисов посредством апи происходит моментально. Клиент что-то запросил, один сервис обратился к другому, и данные уже возвращаются клиенту за 0.2 секунды. Это **синхронное общение**. Но в некоторых случаях мы настраиваем общение с серверами не моментальное, тогда оно будет называться **асинхронным**. Мы сможем забрать сообщение у посредника не моментально, может через минуту или может через день.

17.1.2. **Лучше всего организовать асинхронность через брокер сообщений, например Kафку**

17.1.2.1. **Пример асинхронной обработки заказа через Kafka**

17.1.2.1.1. **Шаг 1. Клиент делает заказ:** - Клиент на сайте добавляет товар в корзину и нажимает кнопку "Подтвердить заказ". - Фронтенд отправляет запрос на **Order Service** (сервис заказов) для обработки этого заказа.

17.1.2.1.2. **Шаг 2. Заказ отправляется в Kafka:** - **Order Service** принимает заказ и отправляет его в **Kafka** в специальный **топик "order-events"** . - Клиент получает ответ "Ваш заказ принят" почти сразу (код 202 Accepted), без ожидания завершения всех операций.

17.1.2.1.3. **Шаг 3. Системы забирают заказ из Kafka:** - **Система оплаты (Payment Service)** подписана на топик "order-events" и получает заказ для обработки платежа. - **Склад (Inventory Service)** также забирает информацию о заказе, проверяет наличие товаров и резервирует их. - **Система доставки (Shipping Service)** подготавливает данные для отправки товара клиенту.

17.1.2.1.4. **Шаг 4. Оповещение клиента:** - После того как оплата подтверждена, **система уведомлений** (Notification Service) получает данные через Kafka и отправляет клиенту email или SMS, что оплата прошла успешно, и заказ скоро будет отправлен.

17.1.2.1.5. **Шаг 5. Обновление статуса заказа:** - **Order Service** следит за всеми системами через Kafka. Когда все процессы завершены (оплата, резерв товара, доставка), статус заказа обновляется, и клиент получает уведомление о завершении всех шагов.

17.1.2.1.6. **Вывод:** Используя Kafka, каждая система работает независимо, не дожидаясь друг друга, а клиент сразу получает подтверждение, что заказ принят, даже если обработка продолжается в фоне.

17.1.3. **Как организовать асинхронное общение без брокера сообщений посредством Rest api**

17.1.3.1. **Как организовать асинхронное общение через REST API**

17.1.3.1.1. 1. **Клиент отправляет запрос**: - Клиент (например, браузер) отправляет запрос на сервер с помощью REST API.

17.1.3.1.2. 2. **Сервер отвечает сразу, но не с результатом**: - Вместо того чтобы ждать завершения всех операций (например, долгой обработки), сервер может сразу ответить клиенту, что запрос принят. Это может быть ответ с кодом HTTP 202 (Accepted), который сообщает, что запрос принят на обработку, но его выполнение займёт время.

17.1.3.1.3. 3. **Фоновая обработка**: - После того как сервер принял запрос, он может начать его обрабатывать в фоновом режиме. Например, сервер может запустить асинхронную задачу для выполнения долгих операций, таких как взаимодействие с базой данных или вызов других микросервисов.

17.1.3.1.4. 4. **Оповещение клиента**: - После завершения фоновой обработки сервер может оповестить клиента о завершении операции. Это может быть сделано через **WebSocket**, **дополнительный API запрос** от клиента (который проверяет статус), или другие способы оповещения (например, отправка email или push-уведомлений).

17.1.3.2. **Пример сценария:** 1. **Клиент** отправляет запрос на загрузку большого объёма данных. 2. **Сервер** принимает запрос, сразу отвечает клиенту "Запрос принят, обработка данных началась", и клиент получает код HTTP 202. 3. Обработка данных происходит в фоне на сервере (вызов других микросервисов, работа с базой и т.д.). 4. После завершения обработки клиент может делать повторные запросы для проверки статуса или сервер сам оповестит клиента о завершении.

17.1.4. **Чем асинхронность через REST API отличается от использования брокеров сообщений**

17.1.4.1. 1. **REST API**: - Вы сами управляете логикой асинхронности. Сервер обрабатывает запросы в фоне, но ответственность за контроль и оповещение лежит на стороне вашего приложения. 2. **Брокеры сообщений** (например, Kafka): - Весь процесс асинхронности автоматизирован. Продюсеры отправляют сообщения в очередь, а консюмеры забирают их для обработки, не требуя немедленного ответа. Этот подход используется для разделения обязанностей между микросервисами и лучше подходит для систем с большими объемами данных и сложными взаимодействиями. **Вывод:** Да, асинхронное общение можно настроить через REST API, но в этом случае вся логика асинхронности (обработка, уведомления и контроль статуса) будет реализована на стороне серверов. Брокеры сообщений упрощают это, делая передачу данных и обработку более автоматизированной.

17.2. **Что такое брокеры очередей и для чего они нужны**

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

17.2.2. **Преимущества использования брокера очередей по сравнению с прямым общением**

17.2.2.1. 1. **Асинхронность**: - При прямом общении один сервис должен ждать, пока другой ответит, что увеличивает задержки. Брокер позволяет сервисам работать независимо — один сервис отправляет сообщение в очередь и продолжает свою работу, не дожидаясь, пока другой обработает его. **Пример**: При оформлении заказа клиент не ждет завершения всех процессов (обработка платежей, отправка уведомлений), что ускоряет пользовательский опыт. 2. **Надежность**: - Брокеры очередей гарантируют, что сообщение будет доставлено даже если принимающий сервис временно недоступен. Как только сервис возобновит работу, он получит все пропущенные сообщения. **Пример**: Если сервис обработки платежей на короткое время упал, он сможет обработать заказ, как только снова заработает. 3. **Масштабируемость**: - Микросервисы могут быть горизонтально масштабированы, и сообщения из очереди будут обрабатываться несколькими экземплярами сервисов параллельно, что позволяет легче справляться с пиковыми нагрузками. **Пример**: Если у вас множество заказов, брокер очередей может распределить задачи на несколько серверов обработки платежей. 4. **Развязка компонентов**: - Микросервисы становятся менее зависимыми друг от друга. Если вы меняете один сервис, это не требует изменений в других, поскольку взаимодействие идет через брокера. **Пример**: Если вам нужно обновить систему уведомлений, это не нарушит работу системы заказов. 5. **Ретрай и обработка ошибок**: - Брокеры позволяют настроить политику повторной попытки обработки сообщений, если что-то пошло не так. В случае ошибки сообщение можно повторно обработать без необходимости писать сложные обработчики на стороне сервисов. **Пример**: Если обработка платежа не удалась, можно настроить систему на несколько повторных попыток обработки заказа.

17.2.2.1.1. **Развязка компонентов**

17.3. **Что такое Кафка (Kafka)**

17.3.1. **Зачем нужен брокер сообщений Kafka**

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

17.3.1.2. **Как разобраться в большом кол-ве интеграций? Нужно использовать технику тест-дизайна.**

17.3.1.2.1. **Диаграмма переходов состояний**: - **Описание**: Эта техника полезна, если вы хотите отобразить, как данные перемещаются через систему, как они меняются на каждом этапе, и какие события инициируют эти переходы. Диаграмма переходов состояний визуализирует возможные сценарии использования и изменения состояния системы. - **Применение**: Подходит для отображения взаимодействий между сервисами, показывая, как каждое состояние данных или компонент системы реагирует на разные события или сообщения. Хорошо работает для сложных сценариев обработки данных, где важно отслеживать статус на каждом этапе.

17.3.2. **Основные понятия**

17.3.2.1. **Продюсер (Producer) **- это компонент системы, который создаёт и отправляет сообщения в топики Kafka. Его задача — генерировать данные (сообщения) и направлять их в **топики** (специальные каналы в Kafka), где эти сообщения будут храниться и ожидать, пока их заберут **консумеры** (получатели). Можно представить продюсера как отправителя писем, который пишет и отправляет их в почтовый ящик (топик).

17.3.2.1.1. **Пример:** В реальной системе **продюсером** может быть любой компонент, который генерирует и отправляет данные в Kafka. Вот несколько примеров: 1. **Веб-приложение**: - Приложение, которое собирает данные о действиях пользователей (клики, посещения страниц) и отправляет их в Kafka для дальнейшей обработки (например, для аналитики). 2. **Сервис регистрации пользователей**: - Когда новый пользователь регистрируется, сервис отправляет сообщение в Kafka с данными пользователя для других систем (например, для отправки приветственного письма или создания записи в CRM). 3. **Мобильное приложение**: - Мобильное приложение, которое отправляет данные о местоположении пользователя или его активности (например, завершение тренировки) в Kafka для хранения или обработки. 4. **Система IoT (Интернет вещей)**: - Устройства с датчиками (например, термостаты, камеры наблюдения, умные приборы), которые отправляют телеметрию, показания сенсоров или другие данные в Kafka для дальнейшего анализа и хранения. 5. **Финансовый сервис**: - Приложение для обработки платежей, которое отправляет транзакционные данные в Kafka, чтобы другие системы (бухгалтерия, антифрод) могли обработать и проанализировать эти данные. 6. **Логирование и мониторинг**: - Приложения, которые собирают логи или метрики производительности и отправляют их в Kafka для анализа и мониторинга работы системы. Во всех этих случаях продюсер выступает как источник данных, отправляющий их в Kafka для последующей обработки другими компонентами системы.

17.3.2.2. **Консюмер (Consumer)** - это получатель сообщений, компонент системы, который читает и обрабатывает сообщения из топиков в Kafka. Его задача — забирать сообщения из очереди и выполнять с ними определённые действия, например, анализировать, сохранять в базу данных или передавать дальше другим системам.

17.3.2.2.1. **Примеры консюмеров в реальных системах:** 1. **Аналитическая система**: - Консюмер, который забирает данные о поведении пользователей (например, клики на сайте) из Kafka и анализирует их для создания отчётов или трендов. 2. **Система уведомлений**: - Консюмер, который забирает сообщения об изменениях в заказах и отправляет клиентам уведомления (например, уведомление по электронной почте о подтверждении заказа). 3. **Финансовый сервис**: - Консюмер, который забирает данные о платежах, проверяет их на соответствие правилам и передаёт в бухгалтерию или систему отчетности. 4. **Система машинного обучения**: - Консюмер, который получает данные в реальном времени (например, данные с сенсоров IoT-устройств) и передаёт их модели машинного обучения для прогнозирования и принятия решений. 5. **Система мониторинга и алертинга**: - Консюмер, который читает метрики производительности с разных сервисов и анализирует их для выявления проблем или генерации алертов, если что-то идёт не так (например, превышена нагрузка на сервер). Консюмеры могут быть настроены на получение данных из одного или нескольких топиков Kafka и могут обрабатывать их в зависимости от требований системы.

17.3.2.3. **Topic** — это как отдельные почтовые ящики для разных видов сообщений. Каждый топик хранит сообщения по определённой теме, например, "заказы" или "уведомления". Все сообщения, связанные с одной темой, складываются в один топик, чтобы их было легче найти и обработать. Это логический канал в Kafka, куда продюсеры отправляют сообщения и откуда консюмеры их забирают. Топик служит для разделения и классификации сообщений по категориям или темам. Каждый топик может быть разделён на несколько партиций для параллельной обработки данных.

17.3.2.3.1. **Примеры топиков в реальных системах:** 1. **Топик "orders" в интернет-магазине** : - Все данные о новых заказах отправляются в топик "orders". Продюсеры (система заказов) отправляют туда информацию о покупках, а консюмеры (логистика, платежные системы) забирают эти данные для дальнейшей обработки, например, для доставки или подтверждения оплаты. 2. **Топик "user-activity" в аналитической системе**: - Продюсеры отправляют данные о действиях пользователей (например, клики, просмотры страниц) в топик "user-activity". Консюмеры могут использовать эти данные для анализа поведения пользователей и создания отчетов о том, как они взаимодействуют с сайтом. 3. **Топик "notifications" в системе уведомлений**: - Все события, требующие уведомления пользователей (например, изменения в заказе или статус доставки), отправляются в топик "notifications". Консюмеры (система отправки писем или SMS) забирают сообщения из этого топика и отправляют уведомления клиентам. 4. **Топик "sensor-data" в IoT системе**: - Устройства, собирающие данные с датчиков (например, температурные датчики или камеры наблюдения), отправляют их в топик "sensor-data". Консюмеры забирают эти данные для анализа, построения моделей или принятия решений (например, если температура выше нормы — включить кондиционер). **Вывод**: Топики в Kafka помогают организовать и разделить сообщения по темам, чтобы консюмеры могли легко забрать и обработать именно те данные, которые им нужны.

17.3.2.4. **Партиция** - это как отдельная полка в большом почтовом ящике (топике). Вместо того, чтобы складывать все письма в один ящик, их распределяют по нескольким полкам, чтобы можно было быстрее их разбирать. Каждый топик может быть разбит на несколько партиций. Это позволяет нескольким людям (консюмерам) одновременно забирать письма (сообщения) с разных полок, ускоряя обработку данных. Это подмножество сообщений внутри одного топика в Kafka. Каждый топик может быть разделён на несколько партиций, что позволяет обрабатывать данные параллельно и увеличивает производительность системы. Каждое сообщение в партиции имеет свой уникальный **оффсет**, который определяет его порядок в очереди.

17.3.2.4.1. **Примеры партиций в реальных системах:** 1. **Партиции в топике "orders" интернет-магазина**: - Топик "orders", который хранит данные о заказах, может быть разделён на несколько партиций. Один заказ попадёт в партицию 1, другой — в партицию 2, третий — в партицию 3. Это позволяет разным консюмерам обрабатывать заказы параллельно, ускоряя работу всей системы. Например, если у вас 3 партиции, 3 консюмера могут одновременно обрабатывать заказы из каждой партиции. 2. **Партиции в топике "sensor-data" IoT системы**: - Топик с данными от сенсоров (например, температуры, влажности) может быть разделён на партиции, чтобы каждая партиция хранила данные с определённой группы датчиков. Это позволяет распределять нагрузку и обрабатывать данные параллельно. Один консюмер может обрабатывать данные только с одной партиции, а другой — с другой. 3. **Партиции в топике "user-activity" системы аналитики**: - Данные о действиях пользователей (например, клики, просмотры) могут быть распределены по партициям в зависимости от пользователя или типа действия. Это позволит нескольким консюмерам обрабатывать действия пользователей параллельно. Например, данные пользователя A могут быть в партиции 1, а данные пользователя B — в партиции 2, что ускоряет анализ их активности.

17.3.2.4.2. **Зачем нужны партиции:** - **Масштабируемость**: Партиции позволяют распределять нагрузку на несколько серверов или консюмеров, увеличивая скорость обработки данных. - **Параллельная обработка**: Каждая партиция может обрабатываться отдельным консюмером, что позволяет обрабатывать большое количество данных одновременно. - **Управление нагрузкой**: Если один сервер перегружен, можно перенести часть партиций на другой сервер. **Вывод**: Партиции в Kafka — это способ разбить данные внутри топика на несколько частей, чтобы обрабатывать их быстрее и параллельно, улучшая производительность и масштабируемость системы.

17.3.2.5. **Оффсет ** — это уникальный идентификатор (номер) каждого сообщения внутри партиции в Kafka. Оффсеты назначаются сообщениям последовательно в порядке их поступления, начиная с 0. Он помогает консюмерам отслеживать, какие сообщения уже были прочитаны, а какие ещё остаются в очереди для обработки.

17.3.2.5.1. **Примеры оффсетов в реальных системах:** 1. **Оффсеты в топике "orders" интернет-магазина**: - В партиции 1 топика "orders" может храниться информация о нескольких заказах. Каждый заказ будет иметь уникальный оффсет. Допустим, заказ 12345 имеет оффсет 0, заказ 12346 — оффсет 1, и так далее. Консюмер, обрабатывающий заказы, будет знать, что он уже обработал сообщения с оффсетом 0 и 1, и следующая задача — обработать сообщение с оффсетом 2. 2. **Оффсеты в топике "sensor-data" в IoT системе**: - В системе датчиков температуры каждое сообщение с показаниями сенсоров будет иметь свой оффсет. Например, первое сообщение с температурой 25°C будет иметь оффсет 0, второе сообщение с температурой 26°C — оффсет 1. Консюмер будет обрабатывать данные, начиная с самого последнего обработанного оффсета, чтобы не пропустить никакие сообщения. 3. **Оффсеты в топике "user-activity" для аналитики**: - Когда пользователи кликают по ссылкам на сайте, эти действия записываются в топик "user-activity". Каждое действие пользователя имеет свой оффсет. Например, клик пользователя на кнопку "Купить" может иметь оффсет 10, а следующий клик на "Корзину" — оффсет 11. Консюмер, анализирующий поведение пользователей, может начать с оффсета, который он уже обработал, чтобы анализировать только новые действия.

17.3.2.5.2. **Зачем нужен оффсет:** - **Отслеживание прогресса**: Консюмеры могут точно знать, какое сообщение было последним обработанным, и продолжать с этого места. - **Повторное воспроизведение сообщений**: Если необходимо повторно обработать данные, консюмер может вернуться к определённому оффсету и начать обработку заново. - **Обеспечение надёжности**: Оффсет помогает избежать пропуска сообщений или их повторной обработки, гарантируя, что данные обрабатываются в правильной последовательности. **Вывод**: Оффсет в Kafka — это уникальный идентификатор каждого сообщения в партиции, который помогает консюмерам отслеживать и управлять прогрессом обработки данных, обеспечивая точность и надёжность при работе с большими объёмами сообщений.

17.3.2.6. **Zookeeper** - координатор. В нем храним состояние и конфигурацию кластера. Эту информацию будет запрашивать **Producer** при публикации сообщений. Также, среди брокеров выделяется один и назначается Контроллером. Он обеспечивает согласованность данных. **Важно**: Начиная с Kafka 2.8.0, Kafka может работать без Zookeeper, так как появилась новая система управления метаданными — **KRaft**. Однако Zookeeper до сих пор активно используется в большинстве инсталляций Kafka.

17.3.2.7. **Брокер** - это сервер, который принимает, хранит и передает сообщения между продюсерами и консюмерами. Каждый брокер отвечает за определённые партиции топиков в кластере Kafka. Он сохраняет данные и управляет запросами на чтение и запись сообщений.

17.3.2.7.1. **Топик** — это логическая категория для сообщений. Он разделён на партиции, и каждое сообщение отправляется в одну из партиций топика. Топик помогает организовать сообщения по темам, но сам по себе не хранит данные. Он скорее указывает, куда должны попасть сообщения. **Брокер** — это физический сервер, который принимает, хранит и управляет партициями топиков. Все сообщения, отправленные в топик, фактически хранятся на брокере. Брокер отвечает за то, чтобы данные были доступны для чтения консюмерами. **Как это работает:** 1. **Продюсер** отправляет сообщение в топик (например, "orders"). 2. **Брокер** принимает это сообщение, сохраняет его в одной из партиций топика "orders". 3. **Консюмер** запрашивает сообщения из топика "orders", а брокер предоставляет эти сообщения из соответствующей партиции. **Технически:** - Топики — это логическая структура для маршрутизации сообщений. - Брокеры — это физические узлы, которые управляют партициями и хранят сообщения. Так топики и брокеры работают вместе: топики организуют данные, а брокеры физически хранят и управляют ими.

17.3.2.8. **Кластер** - это координационный сервис, который используется в системах, таких как Apache Kafka, для управления кластером брокеров, отслеживания их состояния и координации различных операций. Он выполняет ключевые функции для обеспечения согласованности и надёжности работы всей системы Kafka. **Кластер** — это группа нескольких **брокеров**, работающих вместе, чтобы обрабатывать данные в распределённой системе. Кластеры обеспечивают надёжность и масштабируемость Kafka. **Технически:** - В кластере может быть несколько брокеров, каждый из которых хранит и управляет определёнными партициями топиков. - Если один брокер выходит из строя, другой брокер в кластере может взять на себя его задачи, чтобы система продолжала работать без сбоев. **Как это работает:** 1. **Продюсер** отправляет сообщение в топик. 2. Сообщение записывается в одну из **партиций**, которая хранится на **одном из брокеров** кластера. 3. **Консюмер** запрашивает сообщения из топика, и брокеры кластера предоставляют эти сообщения. **Преимущества кластера:** 1. **Отказоустойчивость**: Если один брокер выходит из строя, другие брокеры кластера продолжают работать и хранят копии данных. 2. **Масштабируемость**: Когда нужно обрабатывать больше данных, можно просто добавить больше брокеров в кластер. 3. **Распределение нагрузки**: Брокеры кластера распределяют сообщения и запросы между собой, чтобы увеличить производительность системы.

17.3.2.8.1. **Пример:** - У вас есть 3 брокера, объединённые в один кластер. - Топик "orders" с 6 партициями. Партиции могут распределяться между брокерами: - Партиции 1 и 2 хранятся на брокере 1. - Партиции 3 и 4 — на брокере 2. - Партиции 5 и 6 — на брокере 3. - Если брокер 2 выйдет из строя, кластер автоматически переместит данные на другие брокеры, чтобы система продолжала работать. Таким образом, **кластер** — это группа брокеров, которая обеспечивает распределённую и отказоустойчивую обработку данных в Kafka.

17.3.3. **При тестировании действительно важно использовать Kafka, если она есть в системе, по нескольким причинам: ** 1. **Асинхронная природа взаимодействий**: Kafka передает сообщения асинхронно между микросервисами. Логи и DevTools могут показывать результаты выполнения запросов, но они не всегда отражают полный путь данных, особенно в асинхронных системах, где сообщения могут приходить с задержкой или обрабатываться позже. Kafka помогает отследить полный поток данных в реальном времени. 2. **Полный контроль за сообщениями**: В Kafka вы можете увидеть точное содержимое сообщений, которые проходят между микросервисами, включая детали, которые могут быть не видны в логах или DevTools. Это важно для понимания того, какие данные были отправлены, приняты и где они могли потеряться или быть искажены. 3. **Детализация и диагностика**: Логи часто предоставляют общую информацию о том, что произошло, но не всегда дают полную картину взаимодействия между микросервисами. Kafka позволяет увидеть каждое сообщение, его содержимое и статус, что помогает лучше локализовать и диагностировать проблемы в сложных системах. 4. **История сообщений**: В отличие от логов, которые могут быть перезаписаны или устареть, Kafka сохраняет историю сообщений в топиках, что позволяет вернуться к прошлым событиям и провести более детальный анализ, если баг проявляется не сразу. Таким образом, Kafka предоставляет более глубокий уровень контроля и прозрачности, который важен для тестирования сложных микросервисных систем, особенно когда нужно отследить взаимодействие между сервисами в асинхронной архитектуре.

17.4. **Различия между Kafka и RabbitMQ**

17.4.1. **1. Как работают с сообщениями** - Kafka: - Модель: Консюмеры сами запрашивают сообщения. - Процесс: Консюмеры "тянут" сообщения из Kafka, когда им нужно. - RabbitMQ: - Модель: Брокер сам отправляет сообщения консюмерам. - Процесс: RabbitMQ "пихает" сообщения к консюмерам автоматически. **2. Как хранятся сообщения** - Kafka: - Хранение: Сообщения хранятся долго, пока не достигнут лимит хранения или время истечения. - Удаление: Сообщения не удаляются сразу после прочтения, остаются в топике. - RabbitMQ: - Хранение: Сообщения удаляются после того, как консюмер подтвердит их получение. - Удаление: Сообщения удаляются сразу после подтверждения. **3. Подтверждение получения** - Kafka: - Подтверждение: Не нужно подтверждать получение сообщения. Консюмеры управляют своим прогрессом самостоятельно. - RabbitMQ: - Подтверждение: Необходимо подтвердить получение сообщения. Если подтверждения нет, RabbitMQ может повторно отправить сообщение. **4 . Производительность и масштаб** - Kafka: - Производительность: Хорошо работает с большими объёмами данных и обеспечивает высокую пропускную способность. - Использование: Подходит для потоковой обработки данных и записи событий. - RabbitMQ: - Производительность: Хорошо работает для задач с меньшими объёмами данных и требуется надёжная доставка сообщений. - Использование: Подходит для сценариев, где важно подтверждение получения сообщений.

18. **Работа с логами \\ Kibana**

18.1. **Что такое логи**

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

18.1.1.1. В простых системах логи могут храниться в файлах на сервере или в системе. Эти файлы могут быть в текстовом формате (например, .log) или в структурированном виде, как JSON или XML. В более сложных системах логи часто собираются в централизованные хранилища с использованием таких инструментов, как ELK Stack (Elasticsearch, Logstash, Kibana) или Graylog. Это позволяет легче анализировать, фильтровать и визуализировать логи, а также обеспечивает удобный доступ к ним с разных сервисов.

18.1.2. **Что можно посмотреть в логах**

18.1.2.1. 1. **Уровень логов (log level)**: - Например, уровень логов может включать такие значения, как `INFO(10)`(информация), `WARN(30)` (предупреждение), `ERROR(40)` (ошибка), которые помогают определить, как завершился запрос и есть ли проблемы. 2. **Сообщения (message)**: - Описание ошибок или предупреждений. Например, если произошла ошибка, логи могут содержать сообщение об ошибке, которое поможет найти причину проблемы. 3. **Специфичные поля**: - В зависимости от вашей компании или проекта, могут быть добавлены кастомные данные. Например: - ID транзакции - Время выполнения запроса - Информация о пользователе, который сделал запрос - Данные об окружении (продакшн или тестовая среда) - Метки времени (таймстемпы) - Статус код

18.1.3. **Уровни логирования**

18.1.3.1. 1. **TRACE** (Трассировка) - **Описание**: Самый детализированный уровень. Используется для отслеживания пошагового выполнения программы. Включает огромное количество информации, например, переменные и параметры в каждой функции. - **Когда использовать**: Для глубокой отладки, когда нужно знать каждый шаг выполнения программы. - **Пример**: TRACE: Начат цикл обработки заказа 12345

18.1.3.2. 2. **DEBUG** (Отладка) - **Описание**: Этот уровень используется для детальной отладки. Он показывает внутренние состояния и действия системы, помогает понять, как работают конкретные компоненты программы. - **Когда использовать**: Для тестирования и отладки приложения на этапе разработки. - **Пример**: DEBUG: Обработан запрос на создание заказа 12345

18.1.3.3. 3. **INFO** (Информация) - **Описание**: Сообщения об обычных операциях, которые указывают на нормальную работу системы. Этот уровень логирования записывает основные действия, такие как запуск сервера, обработка запросов. - **Когда использовать**: Для информирования о важных, но не критических событиях в системе. - **Пример**: INFO: Пользователь с ID 789 успешно создал заказ 12345

18.1.3.4. 4. **WARN** (Предупреждение) - **Описание**: Сообщения, которые предупреждают о потенциальных проблемах или аномалиях в работе, которые не вызывают сбоя, но требуют внимания. Это не критические ошибки, но они могут повлиять на работу системы в будущем. - **Когда использовать**: Когда есть незначительные проблемы, которые не останавливают выполнение, но требуют проверки. - **Пример**: WARN: Товар с ID 123 закончился на складе

18.1.3.5. 5. **ERROR** (Ошибка) - **Описание**: Сообщения об ошибках, которые препятствуют корректному выполнению какой-то операции, но не останавливают работу всей системы. Это критические сбои на уровне выполнения конкретных задач. - **Когда использовать**: Когда происходят серьёзные ошибки, которые требуют внимания, но не приводят к полному сбою системы. - **Пример**: ERROR: Ошибка при обработке платежа для заказа 12345

18.1.3.6. 6. **FATAL** (Критическая ошибка) - **Описание**: Сообщения об ошибках, которые приводят к полному сбою системы или её критическому компоненту. Такие ошибки требуют немедленного вмешательства, так как они могут вызвать остановку системы. - **Когда использовать**: Для событий, которые приводят к остановке работы приложения. - **Пример**: FATAL: Невозможно запустить сервер базы данных

18.1.3.7. **Идентификаторы уровней логирования (или ID уровней: 10, 20, 30 и т.д.) используют для того, чтобы легко фильтровать и управлять логами в системе. Эти числовые значения позволяют:** - Упрощать настройку фильтрации сообщений в системах логирования. - Легко задавать пороговые уровни логов, чтобы отображать только сообщения с определённой важностью. - Стандартизировать уровни логирования в различных приложениях и библиотеках.

18.2. **Как применяются логи в тестировании (QA) ?**

18.2.1. 1. **Отслеживание ошибок и багов** - Логи помогают быстро находить и диагностировать ошибки в работе системы. Если в процессе тестирования что-то идёт не так, тестировщик может проверить логи, чтобы понять, в каком именно месте произошёл сбой и что его вызвало. **Пример**: Если API возвращает код 500, тестировщик может посмотреть в логи сервера, чтобы увидеть, что именно вызвало ошибку — возможно, это проблема с базой данных или некорректный запрос.

18.2.2. 2. **Трассировка запросов (Tracing)** - В системах с микросервисной архитектурой логи помогают отслеживать путь запроса через несколько сервисов. Это важно для понимания, где именно происходит сбой в сложной системе. **Пример**: Тестировщик может отследить запрос от фронтенда до бэкенда через все микросервисы, чтобы понять, где произошёл сбой или задержка.

18.2.3. 3. **Тестирование асинхронных процессов** - Логи играют важную роль при тестировании асинхронных процессов (например, очередей сообщений или фоновых задач). Тестировщики могут проверять, что все задачи были выполнены корректно и без ошибок. - **Пример**: Когда система отправляет сообщение через очередь, логи помогут проверить, что сообщение было успешно доставлено и обработано.

18.2.4. 4. **Подтверждение результатов автотестов** - В автоматизированном тестировании логи используются для верификации того, что тесты выполняются корректно. Логи помогают убедиться, что автотесты прошли без ошибок или, наоборот, фиксируют причину сбоя тестов. **Пример**: Если автотест падает, можно посмотреть логи, чтобы понять, что пошло не так: проблема в тесте или в приложении.

18.2.5. 5. **Интеграционное тестирование** - Логи помогают в интеграционном тестировании, когда тестируется взаимодействие нескольких систем или сервисов. Тестировщик может использовать логи, чтобы проверить, как данные проходят через все компоненты системы. **Пример**: Тестируя интеграцию между API и базой данных, можно использовать логи для проверки, что данные корректно передаются и обрабатываются.

18.3. **Кибана ELK**

18.3.1. **Что такое ELK?**

18.3.1.1. **ELK **— это стек инструментов для поиска, анализа и визуализации логов и других данных в реальном времени. Он включает в себя три основных компонента:

18.3.1.1.1. **Elasticsearch** Это поисковый движок, который используется для индексации и быстрого поиска данных. Он собирает и хранит структурированные и неструктурированные данные, предоставляя возможность быстро искать и фильтровать огромные объемы информации. **Пример:** Elasticsearch хранит логи со всех серверов и позволяет быстро найти, например, все ошибки с кодом 500 за последние 24 часа.

18.3.1.1.2. **Logstash** Это инструмент для сбора, обработки и передачи данных в Elasticsearch. Logstash может брать данные из различных источников (файлы логов, базы данных, сообщения) и преобразовывать их перед передачей. **Пример:** Logstash может собирать логи с различных серверов, фильтровать ненужные данные и отправлять только важные сообщения в Elasticsearch.

18.3.1.1.3. **Kibana** Это визуализатор данных, который работает с данными, хранящимися в Elasticsearch. Он предоставляет интерфейс для построения графиков, дашбордов и отчётов для более удобного анализа данных. **Пример:** Kibana позволяет построить график, показывающий количество ошибок за последние сутки, или создать дашборд с мониторингом работы всех систем в реальном времени.

18.3.1.2. **Как работает ELK Stack:** 1. **Logstash** собирает логи и данные с разных источников, обрабатывает их (фильтрует, преобразует) и отправляет в **Elasticsearch**. 2. **Elasticsearch** индексирует эти данные, чтобы их можно было быстро искать и анализировать. 3. **Kibana** предоставляет удобный интерфейс для визуализации данных, создания дашбордов и проведения глубокого анализа.

18.3.1.3. **Зачем нужен ELK Stack?** - **Централизованное логирование**: ELK позволяет собирать логи с множества серверов в одном месте. - **Быстрый поиск**: Благодаря Elasticsearch можно легко находить нужные события в логах. - **Визуализация**: Kibana предоставляет удобные графики и дашборды для мониторинга и анализа данных.

18.3.2. Процесс работы в **ELK Stack** выглядит следующим образом: 1. **Сырые логи** собираются из различных источников. 2. **Logstash** обрабатывает логи (фильтрует, обогащает) и передаёт их в Elasticsearch. 3. **Elasticsearch** сохраняет и индексирует данные для быстрого поиска. 4. **Kibana** позволяет визуализировать данные и анализировать их в удобной форме.

18.3.3. **0️⃣ Сырые логи**

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

18.3.3.2. **Пример сырого лога:** 192.168.1.1 - - [14/Sep/2024:10:10:30 +0000] "GET /index.html HTTP/1.1" 200 1024 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

18.3.3.3. **Зачем нужны сырые логи?** Сырые логи полезны для: 1. **Диагностики**: они содержат всю исходную информацию, которая может помочь найти корень проблемы. 2. **Анализа**: сырые данные могут быть позже обработаны и преобразованы для анализа и визуализации (например, с помощью Logstash). 3. **Аудита**: при необходимости можно проследить каждый шаг работы системы на основе этих данных.

18.3.3.4. **Минусы сырых логов:** - **Много лишней информации**: сырые логи могут содержать много ненужных данных, которые усложняют их анализ. - **Неформатированные данные**: они не всегда удобны для непосредственного использования или анализа. - **Объём**: сырые логи могут занимать много места, особенно в больших системах. Поэтому сырые логи часто проходят обработку, фильтрацию и обогащение перед тем, как их анализируют или хранят в централизованной системе, такой как ELK Stack.

18.3.4. **1️⃣ Logstash**

18.3.4.1. **Logstash** — это инструмент для сбора, обработки и передачи данных. Он является частью ELK Stack и выполняет роль конвейера (pipeline) для данных, которые поступают из различных источников в Elasticsearch или другие системы хранения. C Logstash начинается процесс централизованного сбора логов . То есть Logstash — это первый шаг в конвейере обработки данных, который собирает сырые логи и готовит их для дальнейшего анализа.

18.3.4.2. **Что делает Logstash?** 1. **Сбор данных**: Logstash может подключаться к множеству различных источников, таких как: - Лог-файлы (например, системные логи). - Входящие потоки данных (например, сетевые сообщения, очереди сообщений). - API, базы данных и другие сервисы. 2. **Обработка данных**: После того, как данные собраны, Logstash может их фильтровать, трансформировать и обогащать. Например: - Удалять ненужные поля из логов. - Добавлять метаданные, такие как временные метки или IP-адреса. - Конвертировать данные в нужный формат (например, JSON). 3. **Передача данных**: После обработки данные могут быть отправлены в **Elasticsearch**, а также в другие системы хранения или мониторинга (например, базы данных, очереди сообщений, системы аналитики).

18.3.4.3. **Чем является Logstash?** Logstash можно назвать **средством для обработки и маршрутизации данных**. Его основная задача — взять данные из источников, привести их в нужный формат и передать в место назначения (обычно Elasticsearch). Это делает Logstash важным элементом для централизованного логирования и анализа данных.

18.3.5. **2️⃣ Elasticsearch**

18.3.5.1. **Elasticsearch** — это NoSQL решение для хранения данных и высокоскоростной поисковый движок с мощными возможностями аналитики и агрегации.

18.3.5.2. **Чем Elasticsearch отличается от традиционных баз данных?** 1. **Поисковая система**: Основная задача Elasticsearch — это быстрый полнотекстовый поиск. Это отличается от традиционных реляционных баз данных (например, MySQL или PostgreSQL), которые оптимизированы для хранения и манипуляции структурированными данными (таблицы, связи и т.д.). 2. **JSON-документы**: Elasticsearch хранит данные в виде JSON-документов, а не строк в таблицах. Это делает его более гибким для хранения неструктурированных данных. 3. **Индексация**: При добавлении данных в Elasticsearch они автоматически индексируются, что позволяет выполнять очень быстрые поисковые запросы. Индексы — это ключевая часть Elasticsearch, благодаря которой он справляется с огромными объёмами данных и предоставляет мгновенный доступ к ним. 4. **Масштабируемость**: Elasticsearch легко масштабируется на многие серверы (кластеры), распределяя данные и запросы между ними. Это делает его идеальным для работы с большими объёмами данных.

18.3.5.3. **Как работает Elasticsearch на простом уровне:** - **Документы**: В Elasticsearch данные хранятся в виде JSON-документов. Это как отдельные записи с набором полей и значений. - **Индексы**: Все документы группируются в **индексы**. Индекс — это как огромная коробка, где хранятся все документы по одной теме. Например, один индекс может хранить логи веб-сервера, другой — транзакции в интернет-магазине. - **Кластер**: Elasticsearch работает в виде кластера. Это группа серверов, которые совместно хранят и обрабатывают данные. Каждый сервер называется **узлом**. Кластер может включать один узел или десятки. Чем больше узлов, тем больше данных можно хранить и тем быстрее система работает. - **Шарды и реплики**: Каждый индекс (коробка с документами) разделён на **шарды** — это как маленькие кусочки индекса. Это сделано для того, чтобы можно было обрабатывать данные параллельно, что ускоряет поиск и индексацию. Также Elasticsearch создаёт **реплики** — это копии шардов, которые помогают избежать потери данных. Если один узел сломается, система использует реплику с другого узла. - **Запросы (Search)**: Когда вам нужно что-то найти в данных, вы отправляете запрос. Elasticsearch использует язык запросов, который основан на JSON. Elasticsearch быстро пробегает по индексам, находит все подходящие документы и возвращает их. - **Агрегации**: Это один из мощных инструментов Elasticsearch. Агрегации позволяют проводить анализ данных, например, считать количество запросов за день, находить средние значения, строить графики и многое другое.

18.3.5.4. **Как Elasticsearch обрабатывает данные:** 1. **Индексация**: Когда новый документ поступает в Elasticsearch, он преобразуется в JSON и распределяется по шардом. Каждый документ индексируется, то есть для него создаются быстрые указатели, чтобы потом можно было легко его найти. 2. **Хранение**: Все документы хранятся в индексах, которые разбиты на шарды. Шарды распределяются между узлами в кластере. Это позволяет Elasticsearch эффективно обрабатывать даже огромные объёмы данных. 3. **Поиск**: Когда отправляется запрос на поиск, Elasticsearch начинает поиск по всем нужным шардам и узлам, где хранятся данные. Каждый узел возвращает результаты, которые затем объединяются и отправляются обратно пользователю. 4. **Масштабируемость**: Elasticsearch очень легко масштабируется. Если данных становится больше, можно просто добавить новый узел в кластер, и система автоматически перераспределит данные и нагрузку. 5. **Отказоустойчивость**: Если один узел выйдет из строя, данные не потеряются, потому что они дублируются (реплицируются) на других узлах. Это делает Elasticsearch надёжным для работы с критическими данными.

18.3.6. **3️⃣ Kibana**

18.3.6.1. **Kibana** — это удобный инструмент для визуализации и анализа данных, которые хранятся в Elasticsearch. Он позволяет легко строить графики, диаграммы и дашборды, чтобы быстро видеть ключевые показатели и делать глубокий анализ всех собранных данных. Всё это происходит через простой и понятный интерфейс, так что не нужно копаться в коде — всё наглядно и доступно.

18.3.6.2. **Что делает Kibana?** 1. **Визуализация данных**: - Kibana предоставляет различные способы представления данных: линейные графики, гистограммы, таблицы, круговые диаграммы, карты и многое другое. - Это позволяет визуально анализировать большие объемы данных, поступающие в Elasticsearch. 2. **Дашборды**: - Вы можете создавать интерактивные дашборды, которые собирают на одной странице различные визуализации. Это полезно для мониторинга состояния систем в реальном времени или для отображения ключевых метрик бизнеса. 3. **Поиск и фильтрация**: - Kibana позволяет выполнять сложные поисковые запросы к данным в Elasticsearch. Вы можете фильтровать данные по ключевым словам, временным интервалам, типам событий и другим параметрам. 4. **Мониторинг и оповещения**: - Kibana может использоваться для мониторинга состояния систем. Вы можете настроить дашборды, которые показывают, как работает инфраструктура, сколько ошибок возникает, или каково состояние сервера. Также возможны оповещения на основе анализа данных. **Пример использования:** - С помощью Kibana можно создать дашборд для мониторинга серверов в реальном времени. Этот дашборд может отображать количество запросов на сервер, число ошибок, время отклика, статус работы различных микросервисов и так далее.

18.4. **Другие инструменты для логов:** 1. **ClickHouse**: - **Что это**: это колоночная база данных, разработанная для высокоскоростной обработки аналитических запросов. Она идеально подходит для анализа больших объемов данных, таких как логи. - **Использование**: ClickHouse активно используется для хранения и анализа огромных объемов данных, включая логи. Она позволяет быстро выполнять сложные аналитические запросы по логам, что делает ее популярной в больших проектах, где требуется анализ производительности и событий. 2. **Graylog**: - **Что это**: это мощный инструмент для управления журналами, который предоставляет возможность собирать, индексировать и анализировать логи в реальном времени. - **Использование**: Graylog используется для централизованного сбора и анализа логов из различных источников (сервера, приложения, устройства и т.д.). Он обеспечивает возможность фильтрации, поиска и создания дашбордов для удобного анализа логов. 3. **Sentry**: - **Что это**: это инструмент для отслеживания ошибок и мониторинга производительности приложений, который также предоставляет возможность анализа логов для выявления багов. - **Использование**: Sentry фокусируется на логировании ошибок и исключений в коде. Это решение, которое автоматически уведомляет разработчиков о проблемах в приложениях, помогая быстро находить и исправлять баги.