⚛️Исторические баги🏺
Когда погружаешься в новую область или находишься в ней долго, неплохо знать знаменитые и исторические моменты с ней связанные.
Поэтому буду делиться с вами информацией о таких историях.
Итак..
Amazon
На старте Amazon у покупателей была возможность оформить заказ на отрицательное количество товаров, при этом деньги не списывались, а наоборот зачислялись клиенту. Данный баг появился из-за стремления разработчика выпускать обновления как можно скорее.
.. неплохо бы вернуть такой баг на все маркетплейсы))
#bug #знаменитые_баги
@testorest
Когда погружаешься в новую область или находишься в ней долго, неплохо знать знаменитые и исторические моменты с ней связанные.
Поэтому буду делиться с вами информацией о таких историях.
Итак..
Amazon
На старте Amazon у покупателей была возможность оформить заказ на отрицательное количество товаров, при этом деньги не списывались, а наоборот зачислялись клиенту. Данный баг появился из-за стремления разработчика выпускать обновления как можно скорее.
.. неплохо бы вернуть такой баг на все маркетплейсы))
#bug #знаменитые_баги
@testorest
🔥8
⚛️Исторические баги🏺
Баг 2000 года.
В 1900-х годах разработчики ПО зачастую записывали в дате только две последние цифры года (например, 01.12.99) с целью более эффективного хранения информации.
Но с наступлением 2000 года по всему миру начали происходить сбои в системах. В каких-то городах даже были отключены электричество и отопление. Причиной послужило то, что машины воспринимали 2000 год как 1900.
#bug #знаменитые_баги
@testorest
Баг 2000 года.
В 1900-х годах разработчики ПО зачастую записывали в дате только две последние цифры года (например, 01.12.99) с целью более эффективного хранения информации.
Но с наступлением 2000 года по всему миру начали происходить сбои в системах. В каких-то городах даже были отключены электричество и отопление. Причиной послужило то, что машины воспринимали 2000 год как 1900.
#bug #знаменитые_баги
@testorest
👍2
⚛️Поделать на выходных
🟢Почитать книгу про тест-дизайн
На мой взгляд - очень полезная вещь, чтобы понять откуда брать идеи для тестов и как начать думать как тестировщик. Расширит ваши горизонты, гарантирую))
🟢Прокачать английский
Изучаем английский по песням - мне очень заходит, попробуйте и вы, возможно понравится 😉
#саморазвитие #навыходных
@testorest
🟢Почитать книгу про тест-дизайн
На мой взгляд - очень полезная вещь, чтобы понять откуда брать идеи для тестов и как начать думать как тестировщик. Расширит ваши горизонты, гарантирую))
🟢Прокачать английский
Изучаем английский по песням - мне очень заходит, попробуйте и вы, возможно понравится 😉
#саморазвитие #навыходных
@testorest
🥰4
⚛️Исторические баги🏺
Баг Skype
В 2000 году миллионы пользователи популярного сервиса Skype остались без коннекта на 2 дня. Программа зависала и выдавала постоянные сбои.
Сотрудники Skype на протяжении двух дней искали причину ошибки и рассказывали о каждом ходе своего расследования в блогах. В конце концов неполадка была найдена, она появилась из-за патча Windows, который автоматически устанавливался на компьютеры и перезагружал их, из-за чего все одновременно пытались залогиниться в Скайп.
Этот случай наглядно показал на неправильное распределение ресурсов на серверах.
#bug #знаменитые_баги
@testorest
Баг Skype
В 2000 году миллионы пользователи популярного сервиса Skype остались без коннекта на 2 дня. Программа зависала и выдавала постоянные сбои.
Сотрудники Skype на протяжении двух дней искали причину ошибки и рассказывали о каждом ходе своего расследования в блогах. В конце концов неполадка была найдена, она появилась из-за патча Windows, который автоматически устанавливался на компьютеры и перезагружал их, из-за чего все одновременно пытались залогиниться в Скайп.
Этот случай наглядно показал на неправильное распределение ресурсов на серверах.
#bug #знаменитые_баги
@testorest
👍6
⚛️Исторические баги🏺
Цепная реакция
Когда один из множества коммутаторов AT&T был поврежден, он отправил сообщение об этом соседнему, а тот в свою очередь следующему.
Запустившаяся цепная реакция на 9 часов положила мобильную связь, из-за чего более 50 тысяч человек не могли ей воспользоваться. Проблема была в том, что вместо одного сообщения о поломке, коммутатор рассылал два.
Второе сообщение доходило до других как раз во время их перезагрузки, из-за чего они считали, что сами повреждены и продолжали рассылку. Эта “рассылка” обошлась компании в более 60 млн. долларов.
#bug #знаменитые_баги
@testorest
Цепная реакция
Когда один из множества коммутаторов AT&T был поврежден, он отправил сообщение об этом соседнему, а тот в свою очередь следующему.
Запустившаяся цепная реакция на 9 часов положила мобильную связь, из-за чего более 50 тысяч человек не могли ей воспользоваться. Проблема была в том, что вместо одного сообщения о поломке, коммутатор рассылал два.
Второе сообщение доходило до других как раз во время их перезагрузки, из-за чего они считали, что сами повреждены и продолжали рассылку. Эта “рассылка” обошлась компании в более 60 млн. долларов.
#bug #знаменитые_баги
@testorest
👍5
⚛️Поделать на выходных
🟢Узнать что требуется знать по международной сертификации тестировщиков на базовом уровне
Certified Tester Foundation Level (схема на англ.)
🟢Вспомнить что есть пирамида тестирования
#саморазвитие #навыходных
@testorest
🟢Узнать что требуется знать по международной сертификации тестировщиков на базовом уровне
Certified Tester Foundation Level (схема на англ.)
🟢Вспомнить что есть пирамида тестирования
#саморазвитие #навыходных
@testorest
⚡2👍2
⚛️Исторические баги🏺
Баг The Brain🤯
В конце 80-х и в 90-е зарождались многие термины и процессы тестирования и качества ПО.
В тоже время появлялись и новые баги.
Некоторым были присвоены имена.
Баг на картинке к посту назывался The Brain.
Считается первым вирусом для MS-DOS.
Он перезаписывал загрузочный сектор и замедлял компьютер до невозможности. Создатели этого бага — два пакистанских программиста.
Заражение компьютера происходило путём записи копии вируса в загрузочный сектор дискеты.
Старая информация переносилась в другой сектор и помечалась как «повреждённая». Метка тома изменялась на «©Brain», а в загрузочном секторе отображался текст, который видно на картинке.
Вирус замедлял работу дискеты и делал 7 килобайт памяти недоступными для DOS. Brain был написан пакистанцами Базитом и Амжадом Фарук Альви, жившими в то время в Лахоре.
Brain «не умел» работать с разделами жёстких дисков, поэтому в него была встроена проверка, не позволявшая ему заражать жёсткий диск. Это отличает его от многих вирусов того времени, которые не обращали внимание на разделы, что приводило к уничтожению данных. Благодаря относительной «миролюбивости» вирус часто оставался незамеченным, особенно, когда пользователь не обращал внимание на замедление работы дискет.
Вирус также содержал сообщение с адресом, контактными телефонами создателей и предупреждением о заражении.
Произошло это в 1986 году. Именно тогда стала очевидной возможность существования вирусов, уязвимостей и прочих вещей, которые сейчас кажутся данностью.
Вирус The Brain попал в десятки стран и заразил тысячи компьютеров. Он был доказательством того, что софт мог быть написан злоумышленниками и быть вредоносным.
Это было одним из шагов к тому, чтобы задуматься над тестированием ПО.
#bug #знаменитые_баги
@testorest
Баг The Brain🤯
В конце 80-х и в 90-е зарождались многие термины и процессы тестирования и качества ПО.
В тоже время появлялись и новые баги.
Некоторым были присвоены имена.
Баг на картинке к посту назывался The Brain.
Считается первым вирусом для MS-DOS.
Он перезаписывал загрузочный сектор и замедлял компьютер до невозможности. Создатели этого бага — два пакистанских программиста.
Заражение компьютера происходило путём записи копии вируса в загрузочный сектор дискеты.
Старая информация переносилась в другой сектор и помечалась как «повреждённая». Метка тома изменялась на «©Brain», а в загрузочном секторе отображался текст, который видно на картинке.
Вирус замедлял работу дискеты и делал 7 килобайт памяти недоступными для DOS. Brain был написан пакистанцами Базитом и Амжадом Фарук Альви, жившими в то время в Лахоре.
Brain «не умел» работать с разделами жёстких дисков, поэтому в него была встроена проверка, не позволявшая ему заражать жёсткий диск. Это отличает его от многих вирусов того времени, которые не обращали внимание на разделы, что приводило к уничтожению данных. Благодаря относительной «миролюбивости» вирус часто оставался незамеченным, особенно, когда пользователь не обращал внимание на замедление работы дискет.
Вирус также содержал сообщение с адресом, контактными телефонами создателей и предупреждением о заражении.
Произошло это в 1986 году. Именно тогда стала очевидной возможность существования вирусов, уязвимостей и прочих вещей, которые сейчас кажутся данностью.
Вирус The Brain попал в десятки стран и заразил тысячи компьютеров. Он был доказательством того, что софт мог быть написан злоумышленниками и быть вредоносным.
Это было одним из шагов к тому, чтобы задуматься над тестированием ПО.
#bug #знаменитые_баги
@testorest
❤5👍2
⚛️AI-инструменты для тестирования
Предлагаю вам подборку инструментов AI, которые можно пощупать и попытаться внедрить в ваш процесс тестирования
1. Applitools 👁️
▫️Visual AI для автоматизации визуального тестирования
▫️Кросс-браузерное и кросс-платформенное тестирование
▫️Автоматическое обслуживание тестов
2. Mabl 🤖
▫️Самоисцеляющиеся тесты
▫️Сквозное тестирование
▫️Визуальное регрессионное тестирование
3. Testim 🧠
▫️Машинное обучение для стабильности тестов
▫️Создание тестов с низким уровнем кода
▫️Умные локаторы
4. Functionize 🗣️
▫️NLP для создания тестов
▫️Автономное тестирование
▫️Облачное тестирование
5. Sauce Labs ☁️
▫️Кросс-браузерное тестирование
▫️Мобильное тестирование
▫️Визуальное тестирование с AI-поддержкой
6. Selenium + AI 🔧
▫️Интеграции с AI -инструментами
▫️Широкая поддержка сообщества
▫️Гибкость и расширяемость
Почему стоит смотреть в сторону AI- инструментов?
• 📈 Повышение эффективности
• 🚀 Ускорение процесса разработки/ тестирования
• 🎯 Улучшение точности тестов
• 💡 Интеллектуальная адаптация к изменениям
Если вы еще не применяли ИИ, то самое время попробовать😉
#ai #ИИ
@testorest
Предлагаю вам подборку инструментов AI, которые можно пощупать и попытаться внедрить в ваш процесс тестирования
1. Applitools 👁️
▫️Visual AI для автоматизации визуального тестирования
▫️Кросс-браузерное и кросс-платформенное тестирование
▫️Автоматическое обслуживание тестов
2. Mabl 🤖
▫️Самоисцеляющиеся тесты
▫️Сквозное тестирование
▫️Визуальное регрессионное тестирование
3. Testim 🧠
▫️Машинное обучение для стабильности тестов
▫️Создание тестов с низким уровнем кода
▫️Умные локаторы
4. Functionize 🗣️
▫️NLP для создания тестов
▫️Автономное тестирование
▫️Облачное тестирование
5. Sauce Labs ☁️
▫️Кросс-браузерное тестирование
▫️Мобильное тестирование
▫️Визуальное тестирование с AI-поддержкой
6. Selenium + AI 🔧
▫️Интеграции с AI -инструментами
▫️Широкая поддержка сообщества
▫️Гибкость и расширяемость
Почему стоит смотреть в сторону AI- инструментов?
• 📈 Повышение эффективности
• 🚀 Ускорение процесса разработки/ тестирования
• 🎯 Улучшение точности тестов
• 💡 Интеллектуальная адаптация к изменениям
Если вы еще не применяли ИИ, то самое время попробовать😉
#ai #ИИ
@testorest
👍5🔥4
⚛️Слышали новость?
Wildberries тестирует виртуальную примерку одежды.
Wildberries запустил сервис "Виртуальная фотостудия" для избранных продавцов.
Сервис позволяет "примерять" одежду на виртуальных моделях, созданных нейросетью.
Это поможет партнёрам сэкономить на фотосъёмках.
Источник: тут
Это как раз то, что незаметно происходит.
Технологии, в данном случае нейросеть, внедрили для сокращения расходов бизнеса и упрощения процесса.
Замечаете как технологии медленно наступают?))
Сильно переживать не стоит, но в связи с такими изменениями актуально пересмотреть и свою рабочую сферу и не останавливаться в развитии.
Самообучение, саморазвитие, углубление в предмет или, еще лучше, объединение с другой сферой. Начните изучать что-то новое, близкое к своей деятельности или то, что давно хотели.
@testorest
Wildberries тестирует виртуальную примерку одежды.
Wildberries запустил сервис "Виртуальная фотостудия" для избранных продавцов.
Сервис позволяет "примерять" одежду на виртуальных моделях, созданных нейросетью.
Это поможет партнёрам сэкономить на фотосъёмках.
Источник: тут
Это как раз то, что незаметно происходит.
Технологии, в данном случае нейросеть, внедрили для сокращения расходов бизнеса и упрощения процесса.
Замечаете как технологии медленно наступают?))
Сильно переживать не стоит, но в связи с такими изменениями актуально пересмотреть и свою рабочую сферу и не останавливаться в развитии.
Самообучение, саморазвитие, углубление в предмет или, еще лучше, объединение с другой сферой. Начните изучать что-то новое, близкое к своей деятельности или то, что давно хотели.
@testorest
❤6
⚛️Поделать на выходных 🤪
🟢Начать учить английский.
Например, в skyeng
http://skyeng.ru/referral?inviterHash=4d7a67304f4451784d44593d
🔥По этой ссылке вам накинут еще дополнительно 4 урока🔥
🟢Почитать статью про саморазвитие и решить куда двигаться дальше
Статья
🟢Начать вести ежедневник
Можно выбрать из этих в интернете или посмотрите в этом посте.
Там есть ссылки и обзоры на планеры, которые у меня были/есть. И они довольно хороши.
#саморазвитие #навыходных
@testorest
🟢Начать учить английский.
Например, в skyeng
http://skyeng.ru/referral?inviterHash=4d7a67304f4451784d44593d
🔥По этой ссылке вам накинут еще дополнительно 4 урока🔥
🟢Почитать статью про саморазвитие и решить куда двигаться дальше
Статья
🟢Начать вести ежедневник
Можно выбрать из этих в интернете или посмотрите в этом посте.
Там есть ссылки и обзоры на планеры, которые у меня были/есть. И они довольно хороши.
#саморазвитие #навыходных
@testorest
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2👎1
⚛️Как составить необходимый и достаточный набор тест-кейсов?
Создание оптимального набора тест-кейсов — это баланс между полнотой покрытия и экономией ресурсов. Но в любом случае вам нужно будет пройти следующие стадии:
1️⃣Анализ требований:
🔸Начните с тщательного изучения требований и спецификаций.
🔸Определите ключевые функциональные и нефункциональные требования.
2️⃣Идентификация тестируемых областей:
🔸Разделите приложение на логические модули и компоненты.
🔸Выделите критические сценарии.
3️⃣Применение техник тестирования:
🔸Примените классы эквивалентности и анализ граничных значений.
🔸Используйте метод попарного тестирования для сокращения числа тестов.
🔸Если уместно, используйте и другие техники тестирования(метод состояний и переходов, таблица решений).
4️⃣Позитивные и негативные тест-кейсы:
🔸Проверьте, что присутствуют тест-кейсы для негативных и позитивных сценариев.
5️⃣Приоритизация тест-кейсов:
🔸Определите критические тест-кейсы, которые необходимо выполнить в первую очередь.
🔸Учтите риски и возможные последствия неработающего функционала.
P.S. И помните, именно тестировщики обладают секретным знанием сколько и какие тест-кейсы нужно выполнить 😉
По крайне мере , в идеале. Дальше уже идет торг со временем.
#тест_кейс
@testorest
Создание оптимального набора тест-кейсов — это баланс между полнотой покрытия и экономией ресурсов. Но в любом случае вам нужно будет пройти следующие стадии:
1️⃣Анализ требований:
🔸Начните с тщательного изучения требований и спецификаций.
🔸Определите ключевые функциональные и нефункциональные требования.
2️⃣Идентификация тестируемых областей:
🔸Разделите приложение на логические модули и компоненты.
🔸Выделите критические сценарии.
3️⃣Применение техник тестирования:
🔸Примените классы эквивалентности и анализ граничных значений.
🔸Используйте метод попарного тестирования для сокращения числа тестов.
🔸Если уместно, используйте и другие техники тестирования(метод состояний и переходов, таблица решений).
4️⃣Позитивные и негативные тест-кейсы:
🔸Проверьте, что присутствуют тест-кейсы для негативных и позитивных сценариев.
5️⃣Приоритизация тест-кейсов:
🔸Определите критические тест-кейсы, которые необходимо выполнить в первую очередь.
🔸Учтите риски и возможные последствия неработающего функционала.
P.S. И помните, именно тестировщики обладают секретным знанием сколько и какие тест-кейсы нужно выполнить 😉
По крайне мере , в идеале. Дальше уже идет торг со временем.
#тест_кейс
@testorest
👍4🔥1
⚛️Частые проблемы в тестировании
1. Частые изменения требований
Описание: Частые изменения требований могут создавать хаос в процессе тестирования. Когда требования постоянно меняются, приходится проводить очередной ретест и менять тест-кейсы. А это дополнительное время и возможные баги.
2. Нехватка времени на тестирование
Описание: Сжатые сроки и давление со стороны бизнеса часто приводят к сокращению времени, отведенного на тестирование, что сказывается на качестве продукта.
3. Недостаток коммуникации и сотрудничества
Описание: Плохая коммуникация внутри команды (между разработчиками, тестировщиками, аналитиками, менеджерами) может привести к решению не приоритетных задач, и, как следствие, выпуску очередной версии с ненужными заказчику фичами(потому что ждал он, скорее всего, другие)).
4. Технические долги
Описание: Накопленные из-за временных ограничений технические долги могут замедлить процесс тестирования и сделать его менее эффективным. Если баги не править, качество ПО не вырастет. Но важно править нужные баги. Все остальные могут подождать))
5. Отсутствие тестовых данных
Описание: Недостаток или неполные тестовые данные могут затруднить обеспечение нужного уровня качества, т.к. Вы не сможете проверить часть важного функционала.
6. Ограниченные ресурсы и бюджет
Описание: Недостаток ресурсов, таких как тестовые среды, инструменты и персонал, может ограничивать возможности тестирования.
7. Проблемы с интеграцией
Описание: Интеграция всегда является одним из тонких мест в приложениях - в этой части всегда есть баги). Кроме того, бывает непросто проверить интеграцию, если система, с которой осуществляется обмен, недоступна.
@testorest
1. Частые изменения требований
Описание: Частые изменения требований могут создавать хаос в процессе тестирования. Когда требования постоянно меняются, приходится проводить очередной ретест и менять тест-кейсы. А это дополнительное время и возможные баги.
2. Нехватка времени на тестирование
Описание: Сжатые сроки и давление со стороны бизнеса часто приводят к сокращению времени, отведенного на тестирование, что сказывается на качестве продукта.
3. Недостаток коммуникации и сотрудничества
Описание: Плохая коммуникация внутри команды (между разработчиками, тестировщиками, аналитиками, менеджерами) может привести к решению не приоритетных задач, и, как следствие, выпуску очередной версии с ненужными заказчику фичами(потому что ждал он, скорее всего, другие)).
4. Технические долги
Описание: Накопленные из-за временных ограничений технические долги могут замедлить процесс тестирования и сделать его менее эффективным. Если баги не править, качество ПО не вырастет. Но важно править нужные баги. Все остальные могут подождать))
5. Отсутствие тестовых данных
Описание: Недостаток или неполные тестовые данные могут затруднить обеспечение нужного уровня качества, т.к. Вы не сможете проверить часть важного функционала.
6. Ограниченные ресурсы и бюджет
Описание: Недостаток ресурсов, таких как тестовые среды, инструменты и персонал, может ограничивать возможности тестирования.
7. Проблемы с интеграцией
Описание: Интеграция всегда является одним из тонких мест в приложениях - в этой части всегда есть баги). Кроме того, бывает непросто проверить интеграцию, если система, с которой осуществляется обмен, недоступна.
@testorest
🔥4👍1
С какими проблемами вы чаще всего сталкиваетесь в тестировании? (можно несколько)
Anonymous Poll
61%
Частые изменения требований
53%
Нехватка времени на тестирование
35%
Недостаток коммуникации и сотрудничества
27%
Технические долги
39%
Отсутствие тестовых данных
16%
Ограниченные ресурсы и бюджет
35%
Проблемы с интеграцией
2%
Свое(пишите в комментариях)
⚛️Поделать на выходных 🤪
🟢 Пройти курс по БД YDB(Yandex DB)
Некоторые уже переходят на YDB(Yandex DB)
Вот небольшой бесплатный курс по теме.
Мне очень помог при первом подключении к серверу, потому что там есть нюансы.
А информации в интернете, так чтобы было понятно, очень мало.
🟢 Воспользоваться полезными чек-листами(приложены ниже):
✔️Как учиться, когда ты взрослый
✔️30 дней достижения цели
#саморазвитие #навыходных
@testorest
Некоторые уже переходят на YDB(Yandex DB)
Вот небольшой бесплатный курс по теме.
Мне очень помог при первом подключении к серверу, потому что там есть нюансы.
А информации в интернете, так чтобы было понятно, очень мало.
✔️Как учиться, когда ты взрослый
✔️30 дней достижения цели
#саморазвитие #навыходных
@testorest
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
⚛️Плюсы и минусы тестирования микросервисов
Рассмотрим основные плюсы и минусы, которые следует учитывать при тестировании микросервисной архитектуры.
Кстати, это частый вопрос на собеседованиях.
➕ Плюсы:
1️⃣ Модульность:
Плюс: Микросервисы представляют собой независимые модули, что позволяет тестировать их изолированно. Это упрощает поиск и локализацию ошибок.
Объяснение: Каждый сервис можно тестировать независимо от других, что упрощает процесс тестирования и уменьшает вероятность возникновения взаимозависимых проблем.
2️⃣ Масштабируемость:
Плюс: Тестирование микросервисов можно масштабировать по мере роста системы. Можно добавить новые тесты для новых сервисов без значительного изменения существующих тестов.
Объяснение: Легкость в добавлении новых тестов для новых компонентов системы.
3️⃣ Использование CI/CD:
Плюс: Микросервисы легко интегрируются с CI/CD-пайплайнами, что позволяет автоматизировать тестирование и быстро получать обратную связь, если это необходимо.
Объяснение: Автоматизация тестирования и быстрая доставка изменений.
4️⃣ Гибкость в выборе технологий:
Плюс: Разные микросервисы могут быть написаны на разных языках программирования и использовать различные технологии, что позволяет выбирать наиболее подходящие инструменты для тестирования каждого микросервиса.
Объяснение: Возможность использования лучших инструментов и технологий для каждого конкретного случая.
➖ Минусы:
1️⃣ Сложность интеграционного и регрессионного тестирования:
Минус: Интеграционное и регрессионное тестирование микросервисов может быть сложным из-за множества взаимосвязанных компонентов и необходимости эмулировать взаимодействие между ними.
Объяснение: Трудности в установлении и поддержании тестовых сред, имитирующих реальные условия, оказание влияния на связанные компоненты.
2️⃣ Сетевые задержки и проблемы с сетью:
Минус: Тестирование микросервисов должно учитывать сетевые задержки и ошибки, что усложняет процесс тестирования.
Объяснение: Необходимо учитывать сетевые проблемы, которые могут не проявляться в локальных тестах.
3️⃣ Повышенные требования к инструментам и инфраструктуре:
Минус: Необходимость использования сложных инструментов для оркестрации тестового окружения, таких как Docker и Kubernetes, что может требовать дополнительных знаний и ресурсов.
Объяснение: Дополнительные затраты на обучение и поддержку инфраструктуры.
#микросервисы
@testorest
Рассмотрим основные плюсы и минусы, которые следует учитывать при тестировании микросервисной архитектуры.
Кстати, это частый вопрос на собеседованиях.
Плюс: Микросервисы представляют собой независимые модули, что позволяет тестировать их изолированно. Это упрощает поиск и локализацию ошибок.
Объяснение: Каждый сервис можно тестировать независимо от других, что упрощает процесс тестирования и уменьшает вероятность возникновения взаимозависимых проблем.
Плюс: Тестирование микросервисов можно масштабировать по мере роста системы. Можно добавить новые тесты для новых сервисов без значительного изменения существующих тестов.
Объяснение: Легкость в добавлении новых тестов для новых компонентов системы.
Плюс: Микросервисы легко интегрируются с CI/CD-пайплайнами, что позволяет автоматизировать тестирование и быстро получать обратную связь, если это необходимо.
Объяснение: Автоматизация тестирования и быстрая доставка изменений.
Плюс: Разные микросервисы могут быть написаны на разных языках программирования и использовать различные технологии, что позволяет выбирать наиболее подходящие инструменты для тестирования каждого микросервиса.
Объяснение: Возможность использования лучших инструментов и технологий для каждого конкретного случая.
Минус: Интеграционное и регрессионное тестирование микросервисов может быть сложным из-за множества взаимосвязанных компонентов и необходимости эмулировать взаимодействие между ними.
Объяснение: Трудности в установлении и поддержании тестовых сред, имитирующих реальные условия, оказание влияния на связанные компоненты.
Минус: Тестирование микросервисов должно учитывать сетевые задержки и ошибки, что усложняет процесс тестирования.
Объяснение: Необходимо учитывать сетевые проблемы, которые могут не проявляться в локальных тестах.
Минус: Необходимость использования сложных инструментов для оркестрации тестового окружения, таких как Docker и Kubernetes, что может требовать дополнительных знаний и ресурсов.
Объяснение: Дополнительные затраты на обучение и поддержку инфраструктуры.
#микросервисы
@testorest
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
⚛️Поделать на выходных
🟢Пройти курс "Основы командной строки"
🟢Воспользоваться полезным чек-листом(приложен ниже):
✔️100 способов как изменить свою жизнь
Уверена, что найдете что-то подходящее именно для вас ☺️
#саморазвитие #навыходных
@testorest
🟢Пройти курс "Основы командной строки"
Этот курс подойдет всем, кто знакомится с *NIX-системами (Linux, MacOS) и хочет упростить работу с файлами и программами.
🟢Воспользоваться полезным чек-листом(приложен ниже):
✔️100 способов как изменить свою жизнь
Уверена, что найдете что-то подходящее именно для вас ☺️
#саморазвитие #навыходных
@testorest
👍3❤2🔥2