🐞🔍 Тестирование. Основные понятия
Главное назначение тестирования – проверка соответствия реальных и ожидаемых результатов поведения программы. Тестирование позволяет выявлять дефекты на ранних этапах разработки до того, как с ними столкнётся конечный пользователей. Тестирование несёт в себе и бизнес-ценность: сокращает стоимость разработки за счёт раннего обнаружения дефектов и снижение рисков ухудшения репутации компании и потери лояльности клиентов.
💠 Основные виды тестирования
По запуску кода
● Статическое тестирование — тестирование без фактического выполнения кода
● Динамическое тестирование — не может быть осуществлено без запуска программного кода приложения.
По доступу к коду
● Белый ящик – с использованием доступа к исходному коду
● Чёрный ящик – без использования доступа к исходному коду
По уровню тестирования
● Модульное – проводится над отдельным компонентом системы
● Интеграционное – проверка взаимодействия нескольких компонентов или систем
● Системное – показывает, соответствует ли готовая система функциональным и нефункциональным требованиям
● Приёмочное (UAT) – выполняется самим заказчиком
По степени автоматизации
● Ручное
● Автоматизированное
По целям тестирования различают функциональное и нефункциональное тестирование. К нефункциональному тестированию относят:
● Нагрузочное тестирование – проверка поведения системы при плановой повышенной и пиковой нагрузке
● Стрессовое тестирование – проверка работы системы в критических условиях
● Тестирование удобства использования (usability testing)
● Тестирование безопасности
● Регрессионное тестирование — повторное тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
Тестовые стенды
➖ Среда разработки (Dev) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
➖ Среда тестирования (Test) – среда, в которой работают тестировщики
➖ Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом систем
➖ Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
➖ Продакшн среда (Prod Env) – среда, в которой работают пользователи.
Этапы тестирования
1️⃣ Анализ требований – позволяет выяснить, какие возможные сложности могут возникнуть при тестировании. Также на этом этапе можно выявить возможные несоответствия или недостаточно ясные требования, которые требуют уточнения у разработчиков или заказчика
2️⃣ Планирование тестирования – выбор методов тестирования, определение ресурсов, сроков
3️⃣ Тест-дизайн – разработка тест-кейсов. Тест-кейс — это алгоритм действий, которые требуется совершить для проверки работы системы. Может иметь следующие атрибуты: ID, название, предусловия, шаги, ожидаемый результат, фактический результат, статус
4️⃣ Подготовка к тестированию – включает создание тестового окружения, подготовку тестовых данных, написание автотестов, деплой приложения на тестовом стенде
5️⃣ Выполнение тестирования – Сначала выполняется интеграционное или даже сразу системное тестирование, зависит от специфики тестирования в конкретной компании. Модульное тестирование обычно выполняется разработчиком при написании кода с помощью unit-тестов
6️⃣ Формирование результатов – подготовка отчёта о тестировании, содержащего информацию о результатах выполнения тест-кейсов и о выявленных дефектах
📎 Материалы
1. Фундаментальная теория тестирования
2. Как устроен процесс тестирования
3. Какие бывают этапы и виды тестирования
4. Как писать тест-кейсы
5. Большой учебник по тестированию
6. Курс по тестированию The 100-Year QA-Textbook — полезно и для аналитиков
7. Видео по видам тестирования
#тестирование #развитие
Главное назначение тестирования – проверка соответствия реальных и ожидаемых результатов поведения программы. Тестирование позволяет выявлять дефекты на ранних этапах разработки до того, как с ними столкнётся конечный пользователей. Тестирование несёт в себе и бизнес-ценность: сокращает стоимость разработки за счёт раннего обнаружения дефектов и снижение рисков ухудшения репутации компании и потери лояльности клиентов.
💠 Основные виды тестирования
По запуску кода
● Статическое тестирование — тестирование без фактического выполнения кода
● Динамическое тестирование — не может быть осуществлено без запуска программного кода приложения.
По доступу к коду
● Белый ящик – с использованием доступа к исходному коду
● Чёрный ящик – без использования доступа к исходному коду
По уровню тестирования
● Модульное – проводится над отдельным компонентом системы
● Интеграционное – проверка взаимодействия нескольких компонентов или систем
● Системное – показывает, соответствует ли готовая система функциональным и нефункциональным требованиям
● Приёмочное (UAT) – выполняется самим заказчиком
По степени автоматизации
● Ручное
● Автоматизированное
По целям тестирования различают функциональное и нефункциональное тестирование. К нефункциональному тестированию относят:
● Нагрузочное тестирование – проверка поведения системы при плановой повышенной и пиковой нагрузке
● Стрессовое тестирование – проверка работы системы в критических условиях
● Тестирование удобства использования (usability testing)
● Тестирование безопасности
● Регрессионное тестирование — повторное тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
Тестовые стенды
➖ Среда разработки (Dev) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
➖ Среда тестирования (Test) – среда, в которой работают тестировщики
➖ Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом систем
➖ Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
➖ Продакшн среда (Prod Env) – среда, в которой работают пользователи.
Этапы тестирования
1️⃣ Анализ требований – позволяет выяснить, какие возможные сложности могут возникнуть при тестировании. Также на этом этапе можно выявить возможные несоответствия или недостаточно ясные требования, которые требуют уточнения у разработчиков или заказчика
2️⃣ Планирование тестирования – выбор методов тестирования, определение ресурсов, сроков
3️⃣ Тест-дизайн – разработка тест-кейсов. Тест-кейс — это алгоритм действий, которые требуется совершить для проверки работы системы. Может иметь следующие атрибуты: ID, название, предусловия, шаги, ожидаемый результат, фактический результат, статус
4️⃣ Подготовка к тестированию – включает создание тестового окружения, подготовку тестовых данных, написание автотестов, деплой приложения на тестовом стенде
5️⃣ Выполнение тестирования – Сначала выполняется интеграционное или даже сразу системное тестирование, зависит от специфики тестирования в конкретной компании. Модульное тестирование обычно выполняется разработчиком при написании кода с помощью unit-тестов
6️⃣ Формирование результатов – подготовка отчёта о тестировании, содержащего информацию о результатах выполнения тест-кейсов и о выявленных дефектах
📎 Материалы
1. Фундаментальная теория тестирования
2. Как устроен процесс тестирования
3. Какие бывают этапы и виды тестирования
4. Как писать тест-кейсы
5. Большой учебник по тестированию
6. Курс по тестированию The 100-Year QA-Textbook — полезно и для аналитиков
7. Видео по видам тестирования
#тестирование #развитие
🚆 Релизный процесс. Кратко
Релизный процесс — это совокупность действий, которые необходимы для выпуска новой или обновленной версии программного продукта. Релизный процесс может быть разным в зависимости от типа продукта, методологии разработки, организации команды и других факторов.
К артефактам релиза относятся любые продукты, результаты или документы, которые создаются в ходе релизного процесса.
Артефакты релиза можно условно разделить на две категории:
🔹 Релизные объекты – это физические или логические компоненты, которые составляют релиз, например, исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.
🔸 Документация релиза – это документы, которые описывают релиз. Сюда входят: Release Notes (описание того, что изменилось), план релиза протокол тестирования, отчёт о релизе и т.д.
Управление релизами охватывает все этапы от разработки и тестирования до развертывания.
Этапы релиза могут быть разными, но обычно включают в себя следующие:
1️⃣ Планирование релиза. На этом этапе определяются цели, сроки, приоритеты, ресурсы и ограничения релиза. Также формируется документация, в которой фиксируется список функций, задач, ответственных, рисков и критериев качества релиза. План релиза должен быть согласован с заинтересованными сторонами. Новые фичи полезно оборачивать в тоглы – это специальные механизмы, которые позволяют включать или отключать определенные функции или части релиза без необходимости изменять код или перезапускать приложение.
2️⃣ Сборка релиза. На этом этапе происходит создание и упаковка релизных объектов, таких как исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.
3️⃣ Приемочное пользовательское тестирование (UAT). Финальное тестирование, выполняемое перед выпуском в продуктив. После проведения тестирования руководство вместе с разработчиками принимают окончательное решение о выпуске продукта.
4️⃣ Развертывание релиза. На этом этапе код собирается в исполняемый файл или пакет, который может быть развернут на сервере или облачной платформе. Для этого могут использоваться различные инструменты и методы, такие как непрерывная доставка, контейнеризация, автоматизация и т.д. Цель этого этапа — упростить и ускорить процесс развертывания и обеспечить его надежность и безопасность.
5️⃣ Мониторинг и обратная связь. На этом этапе разработчики и операторы отслеживают работу веб-приложения, собирают данные о его производительности, доступности, ошибках и поведении пользователей. Для этого могут использоваться различные инструменты и сервисы, такие как системы логирования, аналитики, оповещения и т.д. Цель этого этапа — улучшить качество и удовлетворенность веб-приложения, а также выявить и исправить возможные проблемы.
📎 Материалы
1. Всë, что вам нужно знать об управлении релизами
2. Релизный цикл ПО для самых маленьких
3. Автоматизация процесса релиза (+ видео)
4. От пул-реквеста до релиза. Доклад Яндекс.Такси
5. Рецепт гладкого релиза: PMy на заметку
6. Управление релизами, когда и зачем нужно?
7. Как мы автоматизировали процесс генерации Release Notes — опыт МТС
8. Чек-лист: что нужно было делать до того, как запускать микросервисы в prod
9. Релизный поезд. Доклад Яндекса
#devops #управление_релизами
Релизный процесс — это совокупность действий, которые необходимы для выпуска новой или обновленной версии программного продукта. Релизный процесс может быть разным в зависимости от типа продукта, методологии разработки, организации команды и других факторов.
К артефактам релиза относятся любые продукты, результаты или документы, которые создаются в ходе релизного процесса.
Артефакты релиза можно условно разделить на две категории:
🔹 Релизные объекты – это физические или логические компоненты, которые составляют релиз, например, исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.
🔸 Документация релиза – это документы, которые описывают релиз. Сюда входят: Release Notes (описание того, что изменилось), план релиза протокол тестирования, отчёт о релизе и т.д.
Управление релизами охватывает все этапы от разработки и тестирования до развертывания.
Этапы релиза могут быть разными, но обычно включают в себя следующие:
1️⃣ Планирование релиза. На этом этапе определяются цели, сроки, приоритеты, ресурсы и ограничения релиза. Также формируется документация, в которой фиксируется список функций, задач, ответственных, рисков и критериев качества релиза. План релиза должен быть согласован с заинтересованными сторонами. Новые фичи полезно оборачивать в тоглы – это специальные механизмы, которые позволяют включать или отключать определенные функции или части релиза без необходимости изменять код или перезапускать приложение.
2️⃣ Сборка релиза. На этом этапе происходит создание и упаковка релизных объектов, таких как исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.
3️⃣ Приемочное пользовательское тестирование (UAT). Финальное тестирование, выполняемое перед выпуском в продуктив. После проведения тестирования руководство вместе с разработчиками принимают окончательное решение о выпуске продукта.
4️⃣ Развертывание релиза. На этом этапе код собирается в исполняемый файл или пакет, который может быть развернут на сервере или облачной платформе. Для этого могут использоваться различные инструменты и методы, такие как непрерывная доставка, контейнеризация, автоматизация и т.д. Цель этого этапа — упростить и ускорить процесс развертывания и обеспечить его надежность и безопасность.
5️⃣ Мониторинг и обратная связь. На этом этапе разработчики и операторы отслеживают работу веб-приложения, собирают данные о его производительности, доступности, ошибках и поведении пользователей. Для этого могут использоваться различные инструменты и сервисы, такие как системы логирования, аналитики, оповещения и т.д. Цель этого этапа — улучшить качество и удовлетворенность веб-приложения, а также выявить и исправить возможные проблемы.
📎 Материалы
1. Всë, что вам нужно знать об управлении релизами
2. Релизный цикл ПО для самых маленьких
3. Автоматизация процесса релиза (+ видео)
4. От пул-реквеста до релиза. Доклад Яндекс.Такси
5. Рецепт гладкого релиза: PMy на заметку
6. Управление релизами, когда и зачем нужно?
7. Как мы автоматизировали процесс генерации Release Notes — опыт МТС
8. Чек-лист: что нужно было делать до того, как запускать микросервисы в prod
9. Релизный поезд. Доклад Яндекса
#devops #управление_релизами
🟦 Нотация C4. Подборка материалов
С4 – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: Context, Container, Component, Code – отсюда и название.
1️⃣ Диаграммы контекста (Context) – показывают систему в масштабе ее взаимодействия с пользователями и другими системами. Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а люди и системы. С диаграммой этого уровня могут работать “люди из бизнеса”.
2️⃣ Диаграммы контейнеров (Container) – показывают, как система разделена на отдельные контейнеры, которые работают в своих средах выполнения и взаимодействуют друг с другом и с внешним миром. Контейнеры могут быть приложениями, базами данных, файловыми системами, скриптами и другими элементами, необходимыми для работы системы. Диаграмма контейнеров помогает понять, какие технологии используются в системе, как она устроена и как она обслуживает пользователей и другие системы.
3️⃣ Диаграммы компонентов (Component) – показывает устройство контейнера. Здесь компонент – это группа связанных функций, объединённых четко определенным интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса. Целевая аудитория диаграмм уровня Component – разработчики и системные архитекторы.
4️⃣ Диаграммы кода (Code) – создаются по запросу и показывают низкоуровневую реализацию компонентов. Рекомендовано использовать UML Class diagram/Entity relationship diagram и генерировать эти диаграммы автоматически.
Пример используемых инструментов для уровня Code:
▫️ PlantUML – позволяет генерировать UML-диаграммы из текста;
▫️ C4Builder – обеспечивает экспорт в PDF и прочие форматы;
▫️ C4-PlantUML — плагин для IDEA.
Главные преимущества C4
✅ Унифицированный способ рисовать архитектурные схемы. В отличие от “нотации” boxes and lines, когда каждый рисует, как хочет и непонятно что, модель C4 позволяет улучшить читаемость диаграмм благодаря формализации использования элементов и связей.
✅ Нужная степень детализации. Модель позволяет выбрать нужный уровень детализации вместо того, чтобы попытаться запихнуть все системы и сервисы в одну схему. Это похоже на Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.
⛔️ Недостатки C4
➖ Нотация не предъявляет строгих требований, поэтому диаграммы могут выглядеть по-разному в зависимости от автора. Для большего единообразия требуются дополнительные правила на уровне соглашения архитекторов.
➖ Модель не даёт чётких критериев по выделению контейнеров и компонентов. Могут возникать споры, например, по поводу отнесения базы данных к уровню Context или к уровню Component.
➖ Модель предполагает, что система может быть полностью описана четырьмя уровнями детализации, но это не всегда так. В зависимости от размера, сложности и характера системы, может потребоваться больше или меньше уровней, а также различные способы перехода между ними.
➖ Модель не учитывает изменения в архитектуре во времени и не позволяет отображать различные варианты и сценарии.
📎 Материалы
🌐 Официальный сайт
📄 Статьи
1. Как описать архитектуру продукта по нотации C4 — теория (вариант 1)
2. Как описать большую систему в нотации С4 — теория (вариант 2)
3. Аналитик и архитектура: UML-диаграммы для модели C4 — статья от Babok School
4. Описание архитектуры системы с помощью C4 model — взгляд разработчика
5. Опыт составления HLD-документации по нотации C4
⏯ Видео
1. Визуализация архитектуры C4 model / Максим Пальчиков
2. Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
3. C4 models as code — Simon Brown
#проектирование #архитектура #подборка
С4 – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: Context, Container, Component, Code – отсюда и название.
1️⃣ Диаграммы контекста (Context) – показывают систему в масштабе ее взаимодействия с пользователями и другими системами. Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а люди и системы. С диаграммой этого уровня могут работать “люди из бизнеса”.
2️⃣ Диаграммы контейнеров (Container) – показывают, как система разделена на отдельные контейнеры, которые работают в своих средах выполнения и взаимодействуют друг с другом и с внешним миром. Контейнеры могут быть приложениями, базами данных, файловыми системами, скриптами и другими элементами, необходимыми для работы системы. Диаграмма контейнеров помогает понять, какие технологии используются в системе, как она устроена и как она обслуживает пользователей и другие системы.
3️⃣ Диаграммы компонентов (Component) – показывает устройство контейнера. Здесь компонент – это группа связанных функций, объединённых четко определенным интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса. Целевая аудитория диаграмм уровня Component – разработчики и системные архитекторы.
4️⃣ Диаграммы кода (Code) – создаются по запросу и показывают низкоуровневую реализацию компонентов. Рекомендовано использовать UML Class diagram/Entity relationship diagram и генерировать эти диаграммы автоматически.
Пример используемых инструментов для уровня Code:
▫️ PlantUML – позволяет генерировать UML-диаграммы из текста;
▫️ C4Builder – обеспечивает экспорт в PDF и прочие форматы;
▫️ C4-PlantUML — плагин для IDEA.
Главные преимущества C4
✅ Унифицированный способ рисовать архитектурные схемы. В отличие от “нотации” boxes and lines, когда каждый рисует, как хочет и непонятно что, модель C4 позволяет улучшить читаемость диаграмм благодаря формализации использования элементов и связей.
✅ Нужная степень детализации. Модель позволяет выбрать нужный уровень детализации вместо того, чтобы попытаться запихнуть все системы и сервисы в одну схему. Это похоже на Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.
⛔️ Недостатки C4
➖ Нотация не предъявляет строгих требований, поэтому диаграммы могут выглядеть по-разному в зависимости от автора. Для большего единообразия требуются дополнительные правила на уровне соглашения архитекторов.
➖ Модель не даёт чётких критериев по выделению контейнеров и компонентов. Могут возникать споры, например, по поводу отнесения базы данных к уровню Context или к уровню Component.
➖ Модель предполагает, что система может быть полностью описана четырьмя уровнями детализации, но это не всегда так. В зависимости от размера, сложности и характера системы, может потребоваться больше или меньше уровней, а также различные способы перехода между ними.
➖ Модель не учитывает изменения в архитектуре во времени и не позволяет отображать различные варианты и сценарии.
📎 Материалы
🌐 Официальный сайт
📄 Статьи
1. Как описать архитектуру продукта по нотации C4 — теория (вариант 1)
2. Как описать большую систему в нотации С4 — теория (вариант 2)
3. Аналитик и архитектура: UML-диаграммы для модели C4 — статья от Babok School
4. Описание архитектуры системы с помощью C4 model — взгляд разработчика
5. Опыт составления HLD-документации по нотации C4
⏯ Видео
1. Визуализация архитектуры C4 model / Максим Пальчиков
2. Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
3. C4 models as code — Simon Brown
#проектирование #архитектура #подборка
Forwarded from Библиотека Системного Аналитика
P of EAA Фаулер.pdf
54.4 MB
P of EAA: Patterns of Enterprise Application Architecture
(Шаблоны корпоративных приложений)
✍️ Автор: Мартин Фаулер
📅 Год: 2016
🔤 Язык: русский
📚 Объём: 548 стр.
Неустаревающая классика от Мартина Фаулера, которая раскладывает по полочкам создание корпоративных систем, дает ответы на сложные вопросы разработчиков из соответствующей сферы. Фаулер отметил, что даже с быстрым развитием технологий основные принципы проектирования не меняются. Он собрал свыше 40 оптимальных подходов в этом настольном руководстве по корпоративным приложениям. Материал ориентирован на архитекторов, проектировщиков и программистов, задействованных в создании корпоративных ПО и желающих повысить качество своих решений.
#проектирование
(Шаблоны корпоративных приложений)
✍️ Автор: Мартин Фаулер
📅 Год: 2016
🔤 Язык: русский
📚 Объём: 548 стр.
Неустаревающая классика от Мартина Фаулера, которая раскладывает по полочкам создание корпоративных систем, дает ответы на сложные вопросы разработчиков из соответствующей сферы. Фаулер отметил, что даже с быстрым развитием технологий основные принципы проектирования не меняются. Он собрал свыше 40 оптимальных подходов в этом настольном руководстве по корпоративным приложениям. Материал ориентирован на архитекторов, проектировщиков и программистов, задействованных в создании корпоративных ПО и желающих повысить качество своих решений.
#проектирование
🧭 Навигация по материалам
В нашем канале уже вышло несколько десятков полезных статей и давно созрела необходимость систематизировать посты, чтобы было проще ориентироваться. Список будет регулярно обновляться — каждый новый пост будет попадать в соответствующую рубрику в закрепе.
Подборки
📚 Подборка лучших книг для системных аналитиков
🎙 Бесплатные подкасты из Радио "Аналитик"
🟦 Нотация C4. Подборка материалов
💩 Большая подборка открытых API
Работа с требованиями
💩 Требования к требованиям, или свойства качественных требований
💩 Нефункциональные требования и зачем они нужны
💩 Декомпозиция требований и задач
💩 Статьи про User Stories
💩 4 шага как «раскопать» систему
Интеграции
💩 Типы интеграции систем. Преимущества и недостатки
💩 Как выбрать тип межсистемной интеграции
💩 Чем отличаюется синхронное и асинхронное взаимодействие
💩 HTTP. Что нужно знать аналитику
💩 HTTP. Краткие советы по использованию протокола
💩 HTTPS и его отличие от HTTP
💩 Webhook. Что это такое и когда используется
💩 WebSocket: что это, когда следует использовать и какие преимущества дает
💩 Подборка бесплатных вебинаров по основам интеграции систем
API
💩 Интеграция через API
💩 REST. Краткий обзор
💩 Ликбез по понятиям: REST, API, HTTP
💩 Подборка материалов по изучению REST
💩 SOAP. Краткий обзор
💩 REST vs SOAP. Главное
💩 gRPC – краткий обзор
💩 gRPC vs REST: сравнение по пунктам
💩 GraphQL: основные понятия
💩 GraphQL vs REST: сравнение по пунктам
💩 Большая подборка открытых API
💩 JSON-RPC: что это такое и чем отличается от REST
💩 Открытый курс по документированию API
💩 Документирование REST API с помощью Swagger и OpenAPI
Асинхронные интеграции
💩 Что нужно знать про асинхронные интеграции
💩 Очереди сообщений. Основные понятия
💩 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений
💩 Основы Kafka – что нужно знать аналитику
💩 Подборка бесплатных материалов по Kafka
💩 Основы RabbitMQ – что нужно знать аналитику
💩 Подборка бесплатных материалов по RabbitMQ
💩 Kafka vs RabbitMQ: сравнение по пунктам
Архитектура и проектирование
🔹Микросервисная архитектура: основные понятия
🔹Подборка материалов по микросервисной архитектуре
🔹Микросервисы VS монолит: сравнение в карточках
🔹SOA vs MSA: чем отличается микросервисная архитектура от сервисно-ориентированной?
🔹Архитектурные стили и паттерны
🔹Кэширование — разбор по полочкам
🔹Domain Driven Design: что это такое и зачем оно нужно системному аналитику
🔹Как работает клиент-серверная архитектура
🔹Contract First vs Code First: что выбрать
🔹Лучшие практики проектирования API
🔹Авторизация и аутентификация
🔹SSO
Базы данных
▪️Основные понятия баз данных
▪️Подборка полезных материалов по основам баз данных
▪️SQL vs NoSQL: отличие реляционных и нереляционных БД
▪️Типы связей в БД. Нормализация
▪️Виды нереляционных БД. Какие бывают NoSQL базы данных
▪️Шпаргалка по выбору правильной СУБД
▪️Памятка по SQL
Инфраструктура и сети
💩 Разбираемся с моделью OSI на пальцах
💩 Виртуализация, контейнеризация и оркестрация
💩 Балансировка нагрузки. Основные принципы
Информационная безопасность
▫️Безопасность API: базовые принципы
▫️Шифрование, хэширование, хэширование с солью и маскирование
Управление проектами
🔸Agile и Waterfall: главное о методологиях разработки ПО
🔸Релизный процесс. Кратко
Тестирование
💩 Основные понятия тестирования
Развитие навыков
💩 Интерактивная карта навыков системного аналитика
💩 Задачник для системных аналитиков от Тинькофф
💩 Задачи для системных аналитиков из конкурса IT_One Cup 2022 с решениями
💩 Типовые ошибки младшего системного аналитика
💩 Отличие системного аналитика от бизнес-аналитика
Собеседования
💩 Топ ошибок кандидатов при собеседованиях на позицию системного аналитика
💩 123 задачи с IT-собеседований
Инструменты СА
➖PlantUML: полезные материалы
➖Graphana vs Kibana
➖Цикл статьей по изучению Postman
Все теги: #подборка #требования #интеграции #api #архитектура #микросервисы #сравнение #проектирование #бд #инфраструктура #безопасность #управление_проектами #devops #тестирование #развитие #собеседования #инструменты #async #очереди #sql #управление_релизами
В нашем канале уже вышло несколько десятков полезных статей и давно созрела необходимость систематизировать посты, чтобы было проще ориентироваться. Список будет регулярно обновляться — каждый новый пост будет попадать в соответствующую рубрику в закрепе.
Подборки
📚 Подборка лучших книг для системных аналитиков
🎙 Бесплатные подкасты из Радио "Аналитик"
🟦 Нотация C4. Подборка материалов
Работа с требованиями
Интеграции
API
Асинхронные интеграции
Архитектура и проектирование
🔹Микросервисная архитектура: основные понятия
🔹Подборка материалов по микросервисной архитектуре
🔹Микросервисы VS монолит: сравнение в карточках
🔹SOA vs MSA: чем отличается микросервисная архитектура от сервисно-ориентированной?
🔹Архитектурные стили и паттерны
🔹Кэширование — разбор по полочкам
🔹Domain Driven Design: что это такое и зачем оно нужно системному аналитику
🔹Как работает клиент-серверная архитектура
🔹Contract First vs Code First: что выбрать
🔹Лучшие практики проектирования API
🔹Авторизация и аутентификация
🔹SSO
Базы данных
▪️Основные понятия баз данных
▪️Подборка полезных материалов по основам баз данных
▪️SQL vs NoSQL: отличие реляционных и нереляционных БД
▪️Типы связей в БД. Нормализация
▪️Виды нереляционных БД. Какие бывают NoSQL базы данных
▪️Шпаргалка по выбору правильной СУБД
▪️Памятка по SQL
Инфраструктура и сети
Информационная безопасность
▫️Безопасность API: базовые принципы
▫️Шифрование, хэширование, хэширование с солью и маскирование
Управление проектами
🔸Agile и Waterfall: главное о методологиях разработки ПО
🔸Релизный процесс. Кратко
Тестирование
Развитие навыков
Собеседования
Инструменты СА
➖PlantUML: полезные материалы
➖Graphana vs Kibana
➖Цикл статьей по изучению Postman
Все теги: #подборка #требования #интеграции #api #архитектура #микросервисы #сравнение #проектирование #бд #инфраструктура #безопасность #управление_проектами #devops #тестирование #развитие #собеседования #инструменты #async #очереди #sql #управление_релизами
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Системный Аналитик
🔥 Книги для системного аналитика бесплатно без регистрации и СМС 📚
Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком.
👉 Скачать весь архив
Пересылайте коллегам, пусть тоже…
Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком.
👉 Скачать весь архив
Пересылайте коллегам, пусть тоже…
Системный Аналитик pinned «🧭 Навигация по материалам В нашем канале уже вышло несколько десятков полезных статей и давно созрела необходимость систематизировать посты, чтобы было проще ориентироваться. Список будет регулярно обновляться — каждый новый пост будет попадать в соответствующую…»
Как известно, REST не является стандартом, а лишь предоставляет набор принципов, поэтому выбор способа документирования API в REST может быть разным.
OpenAPI — это самая популярная спецификация для документирования REST API. Спецификация OpenAPI не зависит от языка программирования и является машинночитаемой. Она описывается в формате JSON или YAML и содержит подробное описание методов, параметров, структуры данных и другой информации, необходимой для взаимодействия с АПИ.
Разрабатывать документацию по OpenAPI помогает Swagger, который представляет собой набор инструментов:
Способы документирования по OpenAPI
Существует два подхода к проектированию API и его документированию.
🔸 Code first — сначала пишем код, потом по нему генерируем документацию. Для всех популярных языков программирования есть библиотеки и фреймворки, которые с помощью специальных аннотаций/комментариев в коде могут автоматически генерировать спецификацию по OpenAPI.
🔹 Contract first — сначала создаем документацию (контракт), а уже потом по нему пишем код. Так как кода ещё нет, придётся вручную описывать файл спецификации OpenAPI в формате YAML или JSON. Это можно делать с помощью Swagger Editor — онлайн-редактора, который позволяет создавать и редактировать спецификацию OpenAPI в удобном интерфейсе.
В чём разница между OpenAPI и Swagger?
OpenAPI — это спецификация.
Swagger — это инструментарий, использующий спецификацию OpenAPI. Например, OpenAPIGenerator и SwaggerUI.
🖇 Материалы по изучению OpenAPI и Swagger
🌐 Официальная документация:
OpenAPI, Swagger
🎓 Открытый курс по документированию API
📑 Статьи
1. OpenAPI/Swagger для начинающих
2. Как построить REST-like API в крупном проекте
3. Как ускорить тестирование приложения с помощью OpenAPI-спецификаций
1. Что такое Swagger и OpenAPI за 3 минуты
2. Плейлист — OpenAPI и Swagger за 1 час
💻 Практические примеры
1. Знакомимся со Swagger на примере собственного веб-приложения с REST API
2. Пишем спецификацию OpenAPI для интернет-магазина в Swagger
3. Аутентификация в спецификации OpenAPI: расширенный пример интернет-магазина с JWT
4. Небольшой
✏️ Примеры готовых спецификаций OpenAPI
1. Спецификация GitHub
2. Тестовый SwaggerUI
3. Blockchain.com Exchange REST API — сваггер популярной биржи криптовалют
4. Kraken REST API — пример подробной документации API и спецификации в формате OpenAPI + примеры кода на Python
🔧 Инструменты
1. stoplight.io — позволяет упростить написание и ведение спецификаций
#проектирование #api
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Библиотека Системного Аналитика
Системный Аналитик
Мартин Фаулер. UML. Основы.pdf
📚 Подборка книг по UML на русском языке
1️⃣ Мартин Фаулер. UML. Основы.
Совсем небольшая книга, написана простым языком. Подходит для новичков в UML.
2️⃣ Буч Грэди. Язык UML. Руководство пользователя.
Более подробная чем первая, тоже подходит для новичков.
3️⃣ Дж. Шмуллер. Освой самостоятельно UML за 24 часа.
За 24 часа, конечно, вряд ли освоите, но азы в этом книге растолкованы неплохо.
4️⃣ Крэг Ларман. Применение UML и шаблонов проектирования.
В книге основной упор делается на объектно-ориентированный анализ и проектирование. UML является лишь удобным дополняющим инструментом. Для более продвинутых пользователей.
5️⃣ Джим Арлоу. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование. Книга посвящена использованию UML в связке с RUP. Вы узнаете о роли моделирования в цикле разработки ПО, и эти знания помогут вам ответить на вопрос: как и когда использовать (или не использовать) UML, чтобы найти оптимальное решение для своего проекта. Авторы приводят множество примеров и дают рекомендации по разработке моделей.
6️⃣ М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка. Книга помогает научиться мыслить в глобальном понимании проектирования любого приложения, от самого высокого уровня абстракции и до момента написания кода. Книга написана подробно (иногда чересчур) и доступно, особенно раздел, посвященный моделированию. Благодаря сквозному примеру, можно связать все модели логически, что облегчает понимание.
7️⃣ Александр Леоненков. Самоучитель UML. Можно использовать в качестве полного справочника по UML. Для новичков может быть избыточная информация, редко встречающееся на практике.
Скачать можно все книги из поста выше.
🏴☠️ опять напиратили
#проектирование #uml
1️⃣ Мартин Фаулер. UML. Основы.
Совсем небольшая книга, написана простым языком. Подходит для новичков в UML.
2️⃣ Буч Грэди. Язык UML. Руководство пользователя.
Более подробная чем первая, тоже подходит для новичков.
3️⃣ Дж. Шмуллер. Освой самостоятельно UML за 24 часа.
За 24 часа, конечно, вряд ли освоите, но азы в этом книге растолкованы неплохо.
4️⃣ Крэг Ларман. Применение UML и шаблонов проектирования.
В книге основной упор делается на объектно-ориентированный анализ и проектирование. UML является лишь удобным дополняющим инструментом. Для более продвинутых пользователей.
5️⃣ Джим Арлоу. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование. Книга посвящена использованию UML в связке с RUP. Вы узнаете о роли моделирования в цикле разработки ПО, и эти знания помогут вам ответить на вопрос: как и когда использовать (или не использовать) UML, чтобы найти оптимальное решение для своего проекта. Авторы приводят множество примеров и дают рекомендации по разработке моделей.
6️⃣ М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка. Книга помогает научиться мыслить в глобальном понимании проектирования любого приложения, от самого высокого уровня абстракции и до момента написания кода. Книга написана подробно (иногда чересчур) и доступно, особенно раздел, посвященный моделированию. Благодаря сквозному примеру, можно связать все модели логически, что облегчает понимание.
7️⃣ Александр Леоненков. Самоучитель UML. Можно использовать в качестве полного справочника по UML. Для новичков может быть избыточная информация, редко встречающееся на практике.
Скачать можно все книги из поста выше.
#проектирование #uml
🔐 Авторизация и аутентификация. Обзор
Авторизация и аутентификация — это два разных, но тесно связанных процесса, которые обеспечивают безопасность и доступность данных и ресурсов в системе.
🆔 Идентификация — это процесс установления личности пользователя, то есть получение его идентификатора, такого как логин, email, номер телефона и т.д. Идентификация является первым шагом аутентификации, так как без нее система не знает, с кем имеет дело.
🔑 Аутентификация — это проверка подлинности личности пользователя, то есть подтверждение того, что он является тем, кем себя представляет.
🔐 Авторизация — это определение прав пользователя на доступ к определенным данным и ресурсам в системе, то есть установление того, что он может делать после аутентификации.
Пример: когда Вася хочет войти в конфлюэнс и вводит свою почту, система понимает, что аккаунт с таким email существует. Это идентификация. Затем система отправляет на Васин номер СМС с одноразовым паролем, а Вася вводит пароль и тем самым доказывает, что это именно он. Это аутентификация. Система понимает, что Вася настоящий и перенаправляет его на главную страницу – это авторизация, ведь Вася авторизован (то есть имеет право) на чтение главной страницы, как и любой другой сотрудник.
Способы аутентификации
🔗 OAuth 2.0 — это протокол авторизации, предназначенный для организации доступа клиента к ресурсам или данным на другом сервисе. После выполнения процедуры входа клиент получает от сервера
Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается access_token, который затем обменивается на JWT-токен.
📜 JWT (JSON Web Token) – это открытый стандарт для создания и передачи данных в формате JSON, которые могут быть подписаны и/или зашифрованы. Поскольку информация конфиденциальна, такой токен хранится обычно несколько минут.
JWT состоит из трёх частей: заголовка, полезной нагрузки, подписи. Получив JWT от пользователя, приложение сравнивает секретный ключ с тем значением, которое было передано в токене. Если эти значения не совпадут, значит доверять ему приложение не будет.
🔑 API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Ключ обычно передается в заголовке или параметре запроса.
Существует два вида ключей API:
1. Публичный ключ (открытый). Используется для шифрования данных при обращении приложения к серверу.
2. Секретный ключ (закрытый). Известен только пользователю и владельцу сайта. Используется для расшифровки данных, отправленных приложением.
API-ключи применяются при ассиметричном шифровании. Такое шифрование обеспечивает большую безопасность: если злоумышленник получит публичный ключ, то все равно не сможет пройти аутентификацию без секретного ключа.
🔒 mTLS (mutual TLS) — это расширение протокола TLS, которое позволяет обеим сторонам взаимодействия (клиенту и серверу) аутентифицировать друг друга с помощью цифровых сертификатов. Это повышает уровень безопасности и доверия между сторонами, так как исключает возможность подмены или перехвата данных. mTLS часто используется для аутентификации между микросервисами или API.
Есть две пары сертификатов и два закрытых ключа.
1-й закрытый ключ находится на сервере и позволяет расшифровывать данные, которые шифруются открытым ключом, как при обычной работе TLS.
2-й закрытый ключ устанавливается на клиенте, а сервер при ответах клиенту также шифрует данные его открытым ключом. Таким образом, к серверу могут обращаться только те клиенты, у которых есть закрытый ключ для расшифровки данных.
Это не полный перечень всех способов, будем делать отдельные подборки про SSO, SAML, OpenID Connect.
Подборка материалов в следующем посте ➡️
#архитектура #безопасность
Авторизация и аутентификация — это два разных, но тесно связанных процесса, которые обеспечивают безопасность и доступность данных и ресурсов в системе.
🆔 Идентификация — это процесс установления личности пользователя, то есть получение его идентификатора, такого как логин, email, номер телефона и т.д. Идентификация является первым шагом аутентификации, так как без нее система не знает, с кем имеет дело.
🔑 Аутентификация — это проверка подлинности личности пользователя, то есть подтверждение того, что он является тем, кем себя представляет.
🔐 Авторизация — это определение прав пользователя на доступ к определенным данным и ресурсам в системе, то есть установление того, что он может делать после аутентификации.
Пример: когда Вася хочет войти в конфлюэнс и вводит свою почту, система понимает, что аккаунт с таким email существует. Это идентификация. Затем система отправляет на Васин номер СМС с одноразовым паролем, а Вася вводит пароль и тем самым доказывает, что это именно он. Это аутентификация. Система понимает, что Вася настоящий и перенаправляет его на главную страницу – это авторизация, ведь Вася авторизован (то есть имеет право) на чтение главной страницы, как и любой другой сотрудник.
Способы аутентификации
🔗 OAuth 2.0 — это протокол авторизации, предназначенный для организации доступа клиента к ресурсам или данным на другом сервисе. После выполнения процедуры входа клиент получает от сервера
access_token, который позволяет клиентскому приложению получать доступ к ресурсу для выполнения определенных действий от имени пользователя и refresh_token – необходимый для обновления access_token. refresh_token обычно имеет длительный срок действия (исчисляется в месяцах) и обменивается на новый по истечению срока действия. Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается access_token, который затем обменивается на JWT-токен.
📜 JWT (JSON Web Token) – это открытый стандарт для создания и передачи данных в формате JSON, которые могут быть подписаны и/или зашифрованы. Поскольку информация конфиденциальна, такой токен хранится обычно несколько минут.
JWT состоит из трёх частей: заголовка, полезной нагрузки, подписи. Получив JWT от пользователя, приложение сравнивает секретный ключ с тем значением, которое было передано в токене. Если эти значения не совпадут, значит доверять ему приложение не будет.
🔑 API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Ключ обычно передается в заголовке или параметре запроса.
Существует два вида ключей API:
1. Публичный ключ (открытый). Используется для шифрования данных при обращении приложения к серверу.
2. Секретный ключ (закрытый). Известен только пользователю и владельцу сайта. Используется для расшифровки данных, отправленных приложением.
API-ключи применяются при ассиметричном шифровании. Такое шифрование обеспечивает большую безопасность: если злоумышленник получит публичный ключ, то все равно не сможет пройти аутентификацию без секретного ключа.
🔒 mTLS (mutual TLS) — это расширение протокола TLS, которое позволяет обеим сторонам взаимодействия (клиенту и серверу) аутентифицировать друг друга с помощью цифровых сертификатов. Это повышает уровень безопасности и доверия между сторонами, так как исключает возможность подмены или перехвата данных. mTLS часто используется для аутентификации между микросервисами или API.
Есть две пары сертификатов и два закрытых ключа.
1-й закрытый ключ находится на сервере и позволяет расшифровывать данные, которые шифруются открытым ключом, как при обычной работе TLS.
2-й закрытый ключ устанавливается на клиенте, а сервер при ответах клиенту также шифрует данные его открытым ключом. Таким образом, к серверу могут обращаться только те клиенты, у которых есть закрытый ключ для расшифровки данных.
Это не полный перечень всех способов, будем делать отдельные подборки про SSO, SAML, OpenID Connect.
Подборка материалов в следующем посте ➡️
#архитектура #безопасность
Forwarded from Библиотека Системного Аналитика
Guide_to_the_Systems_Engineering_Body_of_Knowledge_v2.9.pdf
35.2 MB
SEBoK — свод знаний по системной инженерии
Все знают про существование BABOK для бизнес-аналитиков, но не каждый знает, что и системные аналитики тоже имеют собственный свод знаний — SEBoK.
К сожалению, нам не удалось найти полноценный перевод на русский за исключением нескольких статей на Хабре.
SEBoK регулярно обновляется, последняя версия выпущена 20 ноября 2023 г. Изменения можно отслеживать на официальном сайте, там же можно почитать свод знаний в формате вики-страниц.
#свод_знаний
Все знают про существование BABOK для бизнес-аналитиков, но не каждый знает, что и системные аналитики тоже имеют собственный свод знаний — SEBoK.
К сожалению, нам не удалось найти полноценный перевод на русский за исключением нескольких статей на Хабре.
SEBoK регулярно обновляется, последняя версия выпущена 20 ноября 2023 г. Изменения можно отслеживать на официальном сайте, там же можно почитать свод знаний в формате вики-страниц.
#свод_знаний