Skip to content

Instantly share code, notes, and snippets.

@abcwalk

abcwalk/q&a.org

Last active August 26, 2024 12:56
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save abcwalk/eb2f070e2884ce003dac75fa322220b7 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save abcwalk/eb2f070e2884ce003dac75fa322220b7 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. abcwalk revised this gist Aug 26, 2024. 1 changed file with 46 additions and 17 deletions.
    63 changes: 46 additions & 17 deletions q&a.org
    View file
    Original file line number Diff line number Diff line change
    @@ -232,29 +232,58 @@

    + Отличия чек-лист и тест-кейс?

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

    1. *Назначение*:
    - *Тест-кейс*: Это документ, который содержит описание шагов, которые тестировщик должен выполнить, и ожидаемых результатов для проверки определенной функциональности или сценария.
    - *Чек-лист*: Это список пунктов или шагов, который помогает проверить выполнение определенных задач, процедур или критериев, но не обязательно предоставляет подробное описание ожидаемых результатов.
    Тест-кейсы

    2. *Детализация*:
    - *Тест-кейс*: Обычно более детализирован и содержит шаги тестирования, входные данные, ожидаемые результаты, и иногда дополнительные сведения о тестовых условиях и предварительных требованиях.
    - *Чек-лист*: Может быть менее подробным и ориентирован на быструю проверку выполнения задачи или соответствия критериям без необходимости подробного описания каждого шага.
    Что это такое?

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

    4. *Структура*:
    - *Тест-кейс*: Структурирован в виде документа, который включает в себя разделы для описания шагов, входных данных, ожидаемых результатов и другой информации.
    - *Чек-лист*: Может быть простым списком пунктов без строгой структуры.
    Зачем они нужны?

    5. *Управление изменениями*:
    - *Тест-кейс*: Обычно поддерживает лучше управление изменениями, поскольку любые изменения в функциональности могут быть обновлены в соответствующих тест-кейсах.
    - *Чек-лист*: Может быть менее удобным для управления изменениями, так как он может представлять собой простой список без подробных описаний.
    1️⃣Подробное руководство: Предоставляют пошаговые инструкции, которые помогают тестировщику точно воспроизвести тестируемый сценарий.
    2️⃣Документирование процесса тестирования: Фиксируют, что было протестировано, как было протестировано и какие результаты были получены.
    3️⃣Повторяемость: Позволяют точно повторить тесты в будущем, что важно для регрессионного тестирования.
    4️⃣Оценка покрытия тестирования: Помогают отслеживать, какие функциональности были протестированы, а какие еще нет.
    5️⃣Обучение новых сотрудников: Подробные тест-кейсы могут служить учебным материалом для новых членов команды, облегчая их введение в проект.

    Оба инструмента могут быть полезными в зависимости от контекста и целей тестирования. Тест-кейсы обычно используются для более формализованных тестов, в то время как чек-листы могут быть удобными для быстрых поверхностных проверок.
    Пример:
    Название: Тестирование функции входа в систему
    Описание: Проверка возможности входа в систему с корректными данными пользователя
    Предусловия: Пользователь зарегистрирован в системе
    Шаги выполнения:
    1. Открыть страницу входа.
    2. Ввести корректный логин пользователя.
    3. Ввести корректный пароль пользователя.
    4. Нажать кнопку "Войти".
    Ожидаемый результат: Пользователь успешно входит в систему и попадает на главную страницу.
    Фактический результат: (заполняется после выполнения теста)
    Статус: (заполняется после выполнения теста, например, "Пройден" или "Не пройден")

    Чек-листы

    Что это такое ?

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

    Зачем они нужны?

    1️⃣Простота и скорость: Позволяют быстро и эффективно проверять основные функции системы.
    2️⃣Гибкость: Легко адаптируются под изменения в требованиях или функциональности системы.
    3️⃣Широкий охват: Помогают убедиться, что основные аспекты системы были проверены, не вдаваясь в подробности.
    4️⃣Поддержка процессов тестирования: Чек-листы могут быть полезны для выполнения смоук-тестирования или поверхностного регрессионного тестирования.
    5️⃣Экономия времени: Не требуют много времени на создание и обновление по сравнению с тест-кейсами.

    Пример:
    Чек-лист для тестирования функции входа в систему:
    - [ ] Проверить возможность входа с корректными данными пользователя.
    - [ ] Проверить, что система отображает ошибку при вводе некорректного пароля.
    - [ ] Проверить, что система отображает ошибку при вводе некорректного логина.
    - [ ] Проверить, что система отображает ошибку при вводе пустых полей логина и пароля.
    - [ ] Проверить возможность восстановления пароля через функцию "Забыли пароль?".

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

    - Цель чек-листа – не пропустить ни одной важной детали в процессе тестирования.
    - Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.
  2. abcwalk revised this gist Jan 25, 2024. No changes.
  3. abcwalk revised this gist Nov 15, 2023. 1 changed file with 299 additions and 69 deletions.
    368 changes: 299 additions & 69 deletions q&a.org
    View file
    Original file line number Diff line number Diff line change
    @@ -2,23 +2,53 @@

    ** Теория тестирования

    + Что такое требования?

    #+begin_quote
    Спецификация (specification): Документ, описывающий (в идеале - исчерпывающе, однозначно и доступно) требования, дизайн, поведение или иные характеристики компонента или системы. Зачастую в спецификацию включаются процедуры контроля исполнения. (ISTQB)
    #+end_quote

    Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль). Результатом выявления требований на этом уровне является общее видение (vision and scope) - документ, который, как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-требований:

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

    + Какие бывают требования?

    До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».

    Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.

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

    Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» – прямое требование, из него проистекают косвенные – она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное – такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.

    Есть маленький грех за мной: я отрицаю существование негативных проверок, поскольку:

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

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

    + *7 принципов тестирования*

    Все 7 принципов тестирования:

    1. Тестирование демонстрирует надичие дефектов, а не их отсутствие
    1. Исчерпывающее тестирование недостижимо

    2. Исчерпывающее тестирование недостижимо
    2. Кластеризация (скопление) дефектов - небольшое количество модулей ПО содержит большенство дефектов

    3. Заблуждение об отсутствии ошибок
    3. Парадокс пестицида

    4. Раннее тестирование сохраняет время и деньги
    4. Тестирование показывает наличие ошибок (не найти все ошибки, а сделать так чтобы клиент не нашел ошибки. показать не отсутствие ошибок, а их наличие)

    5. Принцип скопления или кластеризация дефектов
    5. Отсутствие ошибок это иллюзию (нужно фокусироваться не только на дефектах, а на продукте в целом)

    6. Тестирование зависит от контекста
    6. Раннее тестирование (цена дефекта возрастает с каждой стадией производства ПО)

    7. Парадокс пестицида
    7. Контекст тестирования (подход к тестированию ПО в разных сферах и областях отличается)

    + *Что такое тестирование?*

    @@ -30,9 +60,9 @@

    + Что такое верификация и валидация?

    * Верификация :: Процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям
    * Верификация :: Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

    * Валидация :: Процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям пользователя
    * Валидация :: Это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

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

    @@ -57,6 +87,56 @@
    - Re-test ::
    Повторное тестирование конкретного функционала после исправления бага

    + Функциональные и нефункциональные тесты в чем отличие?

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

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

    + Для чего нужен smoke и regress тест?

    - *Smoke-тесты* ::
    Выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции AUT (Application Under Test) работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьёзные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.

    Если смотреть интегрально, с точки зрения QA и CI-CD-пайплайна, то смок-тестирование — это о том как проверить, что остальные виды тестирования уже валидные, то есть можно идти дальше. Ведь если билд падает при установке, или если половина страниц сайта не грузится, то нет смысла продолжать тестирование, пока такие крупные дефекты не уберут.

    Если смотреть интегрально, с точки зрения QA и CI-CD-пайплайна, то смок-тестирование — это о том как проверить, что остальные виды тестирования уже валидные, то есть можно идти дальше. Ведь если билд падает при установке, или если половина страниц сайта не грузится, то нет смысла продолжать тестирование, пока такие крупные дефекты не уберут.

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

    - *Regression* ::
    Проводится регрессионное тестирование тогда, когда нужно убедиться что новые (добавленные) функции приложения / исправленные дефекты не оказали влияния на текущую, уже существующую функциональность, работавшую (и протестированную) ранее.

    | Дымовые (Smoke) | Санити (Sanity) | Регрессионные (Regression) | Ре-тест (Re-test) |
    |--------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------|
    | Исполняются с целью проверить что критически важные функциональные части AUT работают как положено | Нацелено на установление факта того, что определённые части AUT всё так же работают как положено после минорных изменений или исправлений багов | Подтверждают, что свежие изменения в коде или приложении в целом не оказали негативного влияния на уже существующую функциональность/набор функций | Перепроверяет и подтверждает факт того, что ранее заваленные тест-кейсы проходят после того, как дефекты исправлены |
    | Цель — проверить «стабильность» системы в целом, чтобы дать зелёный свет проведению более тщательного тестирования | Целью является проверить общее состояние системы в деталях, чтобы приступить к более тщательному тестированию | Цель — убедиться что свежие изменения в коде не оказали побочных эффектов на устоявшуюся работающую функциональность | Ре-тест проверяет что дефект исправлен |
    | Перепроверка дефектов не является целью Smoke | Перепроверка дефектов не является целью Sanity | Перепроверка дефектов не является целью Regression | Факт того что дефект исправлен подтверждает Re-Test |
    | Дымовое тестирование выполняется перед регрессионным | Санитарное тестирование выполняется перед регрессионным и после smoke-тестов | Проводится на основании требований проекта и доступности ресурсов (закрывается автотестами), «регресс» может проводиться в параллели с ре-тестами | Ре-тест выполняется перед sanity-тестированием — Так же, приоритет ре-теста выше регрессионных проверок, поэтому должно выполняться перед ними |
    | Может выполняться автоматизированно или вручную | Чаще выполняется вручную | Лучший повод для автоматизации данного вида тестирования, т.к. ручное может быть крайне затратным по ресурсам или времени | Не поддаётся автоматизации |
    | Является подмножеством регрессионного тестирования | Подмножество приёмочного тестирования | Выполняется при любой модификации или изменениях в уже существующем проекте | Ре-тест проводится на исправленной сборке с использованием тех же данных, на том же окружении, но с различным набором входных данных |
    | Тест-кейсы часть регрессионных тест-кейсов, но покрывающие крайне критичную функциональность | Санитарное может выполняться без тест-кейсов, но знание тестируемой системы обязательно | Тест-кейсы регрессионного тестирования могут быть получены из функциональных требований или спецификаций, пользовательских мануалов, и проводятся вне зависимости от того, что исправили разработчики | Используется тот же самый тест-кейс, который выявил дефект |

    + В чем разница между нагрузочным и стресс тестированием?

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

    + Что такое тест-дизайн?

    Тест-дизайн — набор техник, позволяющих с минимальными усилиями расширить тестовое покрытие.

    + Зачем нужен тест-дизайн?

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

    Благодаря тест-дизайну мы:

    - создаем тесты, помогающие выявлять серьезные ошибки

    - вдумчиво подходим к тестированию и не тратим ресурсы впустую

    - сводим к минимуму количество тестов, необходимых для тестирования продукта.

    + Методы тестирования

    * Черный ящик ::
    @@ -128,8 +208,6 @@

    + Что такое дефект / баг?

    Дефект — это отклонение от исходной потребности в выводе, тогда как ошибка — это ошибка программирования.

    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечения.

    * Ошибка — это ошибка кода в программе, которая приводит к неожиданным результатам, а дефект — это недостаток в функциональности или дизайне программы.
    @@ -140,9 +218,9 @@

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

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

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

    | Параметры сравнения | Ошибка | Дефект |
    |-----------------------+---------------------------------------------------------------------------------------+--------------------------------------------------------------|
    @@ -513,9 +591,28 @@

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

    + Что такое тестирование API?

    Подтип тестирования, нацеленный на программный интерфейс приложений (API). Тестирование API проверяет, соответствует ли API приложения требованиям по функциональности, производительности, безопасности, и другим.

    + Что верифицируют в процессе тестирования API

    - Корректность передачи данных

    - Статус-коды HTTP

    - Время отклика (response time)

    - Коды ошибок, если API возвращает ошибки

    - Авторизацию

    - Нефункциональное тестирование, в частности производительность и безопасность


    + Клиент-серверное взаимодействие как происходит?

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

    Вот общая схема клиент-серверного взаимодействия:

    @@ -629,77 +726,102 @@

    - GET запросы кешируются, POST - нет

    + Почему POST запросы не кэшируются, а GET кэширутся?

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

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

    Однако, это поведение может быть изменено с помощью HTTP-заголовков. Например, можно указать, что ответ на POST-запрос может быть кэширован с помощью специальных заголовков Cache-Control или Expires, но это требует аккуратного управления и не используется по умолчанию из-за потенциальной опасности изменения состояния на сервере без необходимости.

    + *Структура HTTP-запроса и ответа*

    HTTP Запрос:

    1. *Строка запроса (Request Line):*
    1. *Строка запроса (Request Line):*

    - Метод запроса (GET, POST, PUT, DELETE и т.д.).
    - URI (Uniform Resource Identifier) - путь к ресурсу.
    - Версия HTTP (например, HTTP/1.1).

    Пример:
    ~GET /index.html HTTP/1.1~

    - Метод запроса (GET, POST, PUT, DELETE и т.д.).
    - URI (Uniform Resource Identifier) - путь к ресурсу.
    - Версия HTTP (например, HTTP/1.1).
    1. *Заголовки (Headers):*

    - Различные метаданные о запросе, такие как ~Host~, ~User-Agent~, ~Accept~, и т.д.

    Пример:
    ~GET /index.html HTTP/1.1~

    2. *Заголовки (Headers):*
    #+BEGIN_SRC none
    Host: www.example.com
    User-Agent: Chrome/91.0.4472.124
    Accept: text/html,application/xhtml+xml,application/xml;
    #+END_SRC

    2. *Тело запроса (Request Body):*

    - Различные метаданные о запросе, такие как ~Host~, ~User-Agent~, ~Accept~, и т.д.
    - Данные, отправляемые с запросом. Обычно используется для POST и PUT запросов.

    Пример:
    ~username=johndoe&password=secret~

    HTTP Ответ:

    #+BEGIN_SRC none
    Host: www.example.com
    User-Agent: Chrome/91.0.4472.124
    Accept: text/html,application/xhtml+xml,application/xml;
    #+END_SRC
    + *Строка состояния (Status Line):*

    3. *Тело запроса (Request Body):*
    - Версия HTTP.
    - Код состояния - трехзначный числовой код, обозначающий успешность или ошибку ответа.
    - Текстовое описание кода состояния.

    - Данные, отправляемые с запросом. Обычно используется для POST и PUT запросов.
    Пример:
    ~HTTP/1.1 200 OK~

    Пример:
    ~username=johndoe&password=secret~
    + *Заголовки (Headers):*

    HTTP Ответ:
    - Метаданные ответа, такие как ~Content-Type~, ~Content-Length~, и т.д.

    1. *Строка состояния (Status Line):*
    Пример:
    #+BEGIN_SRC none
    Content-Type: text/html; charset=utf-8
    Content-Length: 1234
    #+END_SRC

    - Версия HTTP.
    - Код состояния - трехзначный числовой код, обозначающий успешность или ошибку ответа.
    - Текстовое описание кода состояния.
    + *Тело ответа (Response Body):*

    Пример:
    ~HTTP/1.1 200 OK~
    - Данные, возвращаемые сервером. Например, HTML-страница, изображение и т.д.

    2. *Заголовки (Headers):*
    Пример (HTML):
    #+BEGIN_SRC html
    <!DOCTYPE html>
    <html>
    <head>
    <title>Example Page</title>
    </head>
    <body>
    <h1>Hello, World!</h1>
    </body>
    </html>
    #+END_SRC

    - Метаданные ответа, такие как ~Content-Type~, ~Content-Length~, и т.д.
    Это общая структура. Некоторые запросы и ответы могут не содержать тела, и в некоторых случаях могут использоваться дополнительные параметры, такие как параметры запроса (в строке запроса) или куки (в заголовках).

    Пример:
    #+BEGIN_SRC none
    Content-Type: text/html; charset=utf-8
    Content-Length: 1234
    #+END_SRC
    + Что такое cURL?

    3. *Тело ответа (Response Body):*
    Полный запрос.

    - Данные, возвращаемые сервером. Например, HTML-страница, изображение и т.д.
    + Что такое кэш и cookie?

    Пример (HTML):
    #+BEGIN_SRC html
    <!DOCTYPE html>
    <html>
    <head>
    <title>Example Page</title>
    </head>
    <body>
    <h1>Hello, World!</h1>
    </body>
    </html>
    #+END_SRC
    Кэш (cache) и cookie - это два различных механизма, используемых веб-браузерами для оптимизации и управления веб-сайтами.

    Это общая структура. Некоторые запросы и ответы могут не содержать тела, и в некоторых случаях могут использоваться дополнительные параметры, такие как параметры запроса (в строке запроса) или куки (в заголовках).
    * *Кэш* ::
    - *Браузерный кэш* :: Это временное хранилище данных, которое браузер использует для сохранения ранее загруженных ресурсов (таких как HTML-страницы, изображения, стили, скрипты) на компьютере пользователя. Когда вы посещаете веб-сайт, браузер загружает и кэширует ресурсы, чтобы в следующий раз, когда вы посетите тот же сайт, он мог использовать копию из кэша вместо повторной загрузки с сервера. Это улучшает скорость загрузки сайтов и уменьшает нагрузку на сервер.
    - *Серверный кэш* :: Это механизм, который используется сервером для временного хранения данных, чтобы ускорить обработку запросов. Сервер может кэшировать данные (например, вычисленные результаты запросов, содержимое страниц) и отправлять их клиентам без повторных вычислений или запросов к базе данных.

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

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

    ** Клиент-серверное взаимодействие

    @@ -751,18 +873,25 @@ Content-Length: 1234

    + В чем отличия REST и SOAP?

    - REST поддерживает различные форматы: text, JSON, XML, HTML, YAML;
    SOAP - только XML
    REST (Representational State Transfer) и SOAP (Simple Object Access Protocol) - это два различных подхода к созданию веб-сервисов:

    - REST работает только по HTTP(S), а SOAP может работать с различными протоколами
    1. **Архитектурный стиль:**
    - REST: Основывается на принципах взаимодействия клиент-сервер, отсутствии состояния (statelessness - сервер не должен хранить состояние между запросами от одного и того же клиента), кэшировании, использовании унифицированных интерфейсов и многоуровневой архитектуре. Он ориентирован на ресурсы и использует HTTP методы (GET, POST, PUT, DELETE) для работы с ними.
    - SOAP: Это протокол, основанный на XML для обмена структурированными и типизированными сообщениями между клиентом и сервером. SOAP ориентирован на использование спецификаций (WSDL - Web Services Description Language) для определения контрактов и на XML для обмена данными.

    - REST может работать с ресурсами. Каждый URL это представление какого-либо ресурса. SOAP работает с операциями, которые реализуют какую-либо бизнес логику с помощью нескольких интерфейсов
    2. **Формат данных:**
    - REST: Использует различные форматы для представления данных, такие как JSON, XML, HTML и другие. Обычно предпочтителен JSON из-за своей легковесности и удобства в использовании.
    - SOAP: Использует строго типизированные XML-сообщения для обмена данными между клиентом и сервером.

    - SOAP на основе чтения не может быть помещена в кэш, а REST в этом случае может быть закэширован
    3. **Простота использования:**
    - REST: Обычно считается более простым для понимания и использования, так как использует стандартные HTTP методы и не требует сложной настройки.
    - SOAP: Более мощный и расширяемый, но зачастую более сложный в использовании из-за необходимости в строгих схемах данных и формальных контрактах.

    - SOAP поддерживает SSL и WS-security, в то время как REST - только SSL
    4. **Производительность:**
    - REST: Обычно более производительный благодаря простоте передачи данных, использованию кэширования и меньшему объему данных.
    - SOAP: Имеет больший объем данных из-за XML и может быть менее производительным из-за дополнительных слоев безопасности и типизации.

    - SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но не один из ACID не совместим с двух фазовым коммитом.
    Выбор между REST и SOAP зависит от требований проекта, уровня сложности, необходимости типизации данных и других специфических потребностей. REST часто предпочтителен для мобильных приложений и веб-сервисов, где важна легковесность и гибкость, в то время как SOAP может быть полезен в средах, где требуются строгие контракты и типизированные данные.

    + На коленке сделать примитивный JSON

    @@ -789,6 +918,10 @@ Content-Length: 1234

    Идемпотентными методами являются: GET, PUT, DELETE, HEAD и OPTIONS. POST и PATCH не входят в эту группу.

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

    PUT-запросы идемпотентны: многократное выполнение одного и того же PUT-запроса не должно привести к изменению состояния на сервере за пределами обновления ресурса.

    + Статусы HTTP

    Статусы HTTP (HTTP status codes) - это числовые коды, возвращаемые сервером в ответ на запрос клиента к веб-ресурсу. Они предоставляют информацию о результате выполнения запроса. Каждый статус состоит из трех цифр и имеет свое определенное значение.
    @@ -910,6 +1043,103 @@ Content-Length: 1234
    * DDL операторы :: /Data Definition Language/ (язык определения данных) Определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. ~DDL~ операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры ~DDL~ операторов включают ~CREATE~, ~ALTER~, ~DROP~, ~TRUNCATE~ и ~RENAME~. ~DDL~ операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых ~DDL~ операторов. ~DDL~ операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных
    * DML операторы :: /Data Manipulation Language/ (язык манипулирования данными) используется для манипулирования данными в базе данных. ~DML~ операторы используются для вставки, обновления и удаления данных в базе данных. Примерами ~DML~ операторов включают ~SELECT~, ~INSERT~, ~UPDATE~, и ~DELETE~. ~DML~ операторы выполняются немедленно и могут быть отменены с помощью оператора отката. ~DML~ операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных

    #+begin_quote
    В целом, ~DDL~ используется для определения и управления структурой базы данных, в то время как ~DML~ используется для манипулирования данными в базе данных. ~DDL~ утверждения являются постоянными и не могут быть отменены, в то время как ~DML~ утверждения выполняются немедленно и могут быть отменены. ~DDL~ утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют ~DML~ утверждения.
    #+end_quote
    #+begin_quote
    В целом, ~DDL~ используется для определения и управления структурой базы данных, в то время как ~DML~ используется для манипулирования данными в базе данных. ~DDL~ утверждения являются постоянными и не могут быть отменены, в то время как ~DML~ утверждения выполняются немедленно и могут быть отменены. ~DDL~ утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют ~DML~ утверждения.
    #+end_quote

    ** Опыт

    + Как находить критичные баги быстро

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

    Основные принципы:

    1. Сначала мы тестируем те вещи которые поменялись

    2. Сначала мы тестируем базовые функции и потом вспомогательные.
    Вначале тестируем критичные и популярные функции продукта.

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

    4. Тестировать стандартные условия перед гипотетическими

    5. Сначала тестируем стандартные угрозы перед экзотическими, тоесть проводим тесты на наиболее вероятные стрессовые и багоопасные ситуации в первую очередь

    6. Сначала тестируем те части продукта, которые могут нанести больший вред

    7. Сначала тестируем наиболее используемые области продукта, перед невостребованными областями

    Если софт не имеет критичных багов то в теории его можно двигать дальше

    + Тестирование полей и форм

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

    * Начальный уровень представляет из себя простые позитивные и негативные кейсы (в основном на валидацию):

    - Обязательные поля отмечены *

    - Обязательные поля заполнены/нет

    - Галочки на соглашениях проставлены/нет

    - Поле *password* и подтверждение имеет соответствующий тип (в полях формы прописан корректный атрибут *TYPE*, сообщающий браузеру тип элементов формы.)

    - Проверяется, что пароли одинаковы

    - Имя пользователя валидируется как минимум на длину и спец. символы, остальное по ТЗ

    - Адрес почты валидируется в соответствии со стандартом (наличие символа *@*, несколько символов *@*, длины частей до и после *@*, допустимые символы до и после, наличие пробелов перед адресом и после, корректная доменная часть и т.п.)

    - Поля с ожидаемым числовым вводом и текстовым соответственно проверить позитивными и негативными кейсами по типам данных

    * Следующий уровень:

    - Все из предыдущего

    - Кроссбраузерность

    - Понятность формы. Присутствует описание полей или плейсхолдеры

    - Сенситив данные не должны передаваться в *URL*

    - Проверяем, как форма отображается до сабмита и после

    - Поведение, если нажать сабмит несколько раз подряд

    - Если формы очищаются после сабмита, проверить регистрацию существующего пользователя

    - Проверка глобализации - номер телефона, дата, почтовый индекс, валюта, вертикальное или *RTL* письмо и т.п. (опционально)

    - Проверка простых инъекций

    - Правильная работа многошаговых форм (Навигация рядом с формой показывает текущий этап и количество оставшихся шагов.)

    - Для полей, предполагающих загрузку файлов, прописан атрибут *accept*, определяющий тип загружаемых документов

    - Текстовое многострочное поле при вводе объемного сообщения изменяет высоту либо в правой части появляется скроллбар для просмотра всего содержимого

    - Для авторизованного пользователя в поля формы автоматически подставляются все известные о посетителе данные.

    - Форма сохраняется в веб-формах (админ-панели) или *SQL-таблицах*.

    - Прописан реальный *e-mail* лица, отвечающего за обработку заявок (если предполагается ОС)

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

    - Прописан атрибут *autocomplete* для полей, поддерживающих это значение

    * Extra:

    - Проверяем, отправились ли данные после сабмита

    - Проверяем, добавились ли соответствующие записи в бд

    - Проверка загрузки формы и сабмита при медленном/нестабильном интернет-соединении

    - Корректность *cookies/токена* и т.п. после сабмита

    + Что делать если нужно пройти регрессию а времени нет?

    Попробовать поговорить с тиммлидом. Спросить у разработчиков какие части приложения подвергались изменениям.
  4. abcwalk revised this gist Nov 13, 2023. No changes.
  5. pingvi revised this gist Nov 13, 2023. 1 changed file with 66 additions and 1 deletion.
    67 changes: 66 additions & 1 deletion q&a.org
    View file
    Original file line number Diff line number Diff line change
    @@ -340,7 +340,9 @@
    * Низкая производительность
    * Нет доступа к «железу» девайса

    + специфические тестирования мобилок знаешь?
    ** Мобильное тестирование

    + Специфические тестирования мобилок знаешь?

    1. Тестирование на разных платформах

    @@ -370,6 +372,69 @@

    14. Конфигурационное тестирование

    + Что такое гайдлайны?

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

    1. *Покрытие платформ:*

    - Тестируйте приложение на разных мобильных платформах (iOS, Android) и версиях устройств. Обратите внимание на особенности каждой платформы.

    2. *Разнообразие устройств:*

    - Уделяйте внимание разнообразию устройств, разрешений экранов и версий операционных систем.

    3. *Ориентации экрана:*

    - Проверяйте приложение в разных ориентациях экрана (портретной и альбомной).

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

    - Имитируйте различные сетевые условия, такие как 3G, 4G, Wi-Fi с низкой пропускной способностью, чтобы проверить, как ваше приложение ведет себя при ограниченной связи.

    5. *Тестирование на различных разрешениях экрана:*

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

    6. *Тестирование производительности:*

    - Оцените производительность приложения при работе с различными объемами данных и на различных устройствах.

    7. *Обработка различных языков и региональных настроек:*

    - Проверьте, как ваше приложение обрабатывает различные языки и региональные настройки.

    8. *Тестирование в разных версиях ОС:*

    - Убедитесь, что ваше приложение совместимо с различными версиями операционных систем.

    9. **Автоматизация тестирования:**
    - Используйте автоматизацию тестирования для повторяемых сценариев и быстрого обнаружения регрессий.

    10. *Тестирование безопасности:*

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

    11. *Тестирование обновлений и установки:*

    - Протестируйте процесс обновления и установки приложения на устройствах с предыдущими версиями.

    12. *Тестирование в различных окружениях:*

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

    13. *Тестирование интеграции:*

    - Тестируйте взаимодействие вашего приложения с другими приложениями и сервисами.

    14. *Анализ обратной связи пользователей:*

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

    15. *Тестирование резервного копирования и восстановления:*

    - Проверьте, как приложение обрабатывает резервное копирование и восстановление данных.

    ** Тестирование бэкенда

    + Знаешь что такое монолитный бекенд?
  6. abcwalk revised this gist Nov 13, 2023. 5 changed files with 0 additions and 1778 deletions.
    8 changes: 0 additions & 8 deletions .gitignore
    View file
    Original file line number Diff line number Diff line change
    @@ -1,8 +0,0 @@
    .DS_Store
    .idea
    *.log
    tmp/

    *.html
    *.md
    *.tmp
    1,751 changes: 0 additions & 1,751 deletions q&a.html
    View file
    Original file line number Diff line number Diff line change
    @@ -1,1751 +0,0 @@
    <?xml version="1.0" encoding="utf-8"?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
    <head>
    <!-- 2023-11-12 Вс 17:32 -->
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Вопросы на собеседованиях для QA Engineer</title>
    <meta name="author" content="Maxim Rozhkov" />
    <meta name="generator" content="Org Mode" />
    <style>
    #content { max-width: 60em; margin: auto; }
    .title { text-align: center;
    margin-bottom: .2em; }
    .subtitle { text-align: center;
    font-size: medium;
    font-weight: bold;
    margin-top:0; }
    .todo { font-family: monospace; color: red; }
    .done { font-family: monospace; color: green; }
    .priority { font-family: monospace; color: orange; }
    .tag { background-color: #eee; font-family: monospace;
    padding: 2px; font-size: 80%; font-weight: normal; }
    .timestamp { color: #bebebe; }
    .timestamp-kwd { color: #5f9ea0; }
    .org-right { margin-left: auto; margin-right: 0px; text-align: right; }
    .org-left { margin-left: 0px; margin-right: auto; text-align: left; }
    .org-center { margin-left: auto; margin-right: auto; text-align: center; }
    .underline { text-decoration: underline; }
    #postamble p, #preamble p { font-size: 90%; margin: .2em; }
    p.verse { margin-left: 3%; }
    pre {
    border: 1px solid #e6e6e6;
    border-radius: 3px;
    background-color: #f2f2f2;
    padding: 8pt;
    font-family: monospace;
    overflow: auto;
    margin: 1.2em;
    }
    pre.src {
    position: relative;
    overflow: auto;
    }
    pre.src:before {
    display: none;
    position: absolute;
    top: -8px;
    right: 12px;
    padding: 3px;
    color: #555;
    background-color: #f2f2f299;
    }
    pre.src:hover:before { display: inline; margin-top: 14px;}
    /* Languages per Org manual */
    pre.src-asymptote:before { content: 'Asymptote'; }
    pre.src-awk:before { content: 'Awk'; }
    pre.src-authinfo::before { content: 'Authinfo'; }
    pre.src-C:before { content: 'C'; }
    /* pre.src-C++ doesn't work in CSS */
    pre.src-clojure:before { content: 'Clojure'; }
    pre.src-css:before { content: 'CSS'; }
    pre.src-D:before { content: 'D'; }
    pre.src-ditaa:before { content: 'ditaa'; }
    pre.src-dot:before { content: 'Graphviz'; }
    pre.src-calc:before { content: 'Emacs Calc'; }
    pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
    pre.src-fortran:before { content: 'Fortran'; }
    pre.src-gnuplot:before { content: 'gnuplot'; }
    pre.src-haskell:before { content: 'Haskell'; }
    pre.src-hledger:before { content: 'hledger'; }
    pre.src-java:before { content: 'Java'; }
    pre.src-js:before { content: 'Javascript'; }
    pre.src-latex:before { content: 'LaTeX'; }
    pre.src-ledger:before { content: 'Ledger'; }
    pre.src-lisp:before { content: 'Lisp'; }
    pre.src-lilypond:before { content: 'Lilypond'; }
    pre.src-lua:before { content: 'Lua'; }
    pre.src-matlab:before { content: 'MATLAB'; }
    pre.src-mscgen:before { content: 'Mscgen'; }
    pre.src-ocaml:before { content: 'Objective Caml'; }
    pre.src-octave:before { content: 'Octave'; }
    pre.src-org:before { content: 'Org mode'; }
    pre.src-oz:before { content: 'OZ'; }
    pre.src-plantuml:before { content: 'Plantuml'; }
    pre.src-processing:before { content: 'Processing.js'; }
    pre.src-python:before { content: 'Python'; }
    pre.src-R:before { content: 'R'; }
    pre.src-ruby:before { content: 'Ruby'; }
    pre.src-sass:before { content: 'Sass'; }
    pre.src-scheme:before { content: 'Scheme'; }
    pre.src-screen:before { content: 'Gnu Screen'; }
    pre.src-sed:before { content: 'Sed'; }
    pre.src-sh:before { content: 'shell'; }
    pre.src-sql:before { content: 'SQL'; }
    pre.src-sqlite:before { content: 'SQLite'; }
    /* additional languages in org.el's org-babel-load-languages alist */
    pre.src-forth:before { content: 'Forth'; }
    pre.src-io:before { content: 'IO'; }
    pre.src-J:before { content: 'J'; }
    pre.src-makefile:before { content: 'Makefile'; }
    pre.src-maxima:before { content: 'Maxima'; }
    pre.src-perl:before { content: 'Perl'; }
    pre.src-picolisp:before { content: 'Pico Lisp'; }
    pre.src-scala:before { content: 'Scala'; }
    pre.src-shell:before { content: 'Shell Script'; }
    pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
    /* additional language identifiers per "defun org-babel-execute"
    in ob-*.el */
    pre.src-cpp:before { content: 'C++'; }
    pre.src-abc:before { content: 'ABC'; }
    pre.src-coq:before { content: 'Coq'; }
    pre.src-groovy:before { content: 'Groovy'; }
    /* additional language identifiers from org-babel-shell-names in
    ob-shell.el: ob-shell is the only babel language using a lambda to put
    the execution function name together. */
    pre.src-bash:before { content: 'bash'; }
    pre.src-csh:before { content: 'csh'; }
    pre.src-ash:before { content: 'ash'; }
    pre.src-dash:before { content: 'dash'; }
    pre.src-ksh:before { content: 'ksh'; }
    pre.src-mksh:before { content: 'mksh'; }
    pre.src-posh:before { content: 'posh'; }
    /* Additional Emacs modes also supported by the LaTeX listings package */
    pre.src-ada:before { content: 'Ada'; }
    pre.src-asm:before { content: 'Assembler'; }
    pre.src-caml:before { content: 'Caml'; }
    pre.src-delphi:before { content: 'Delphi'; }
    pre.src-html:before { content: 'HTML'; }
    pre.src-idl:before { content: 'IDL'; }
    pre.src-mercury:before { content: 'Mercury'; }
    pre.src-metapost:before { content: 'MetaPost'; }
    pre.src-modula-2:before { content: 'Modula-2'; }
    pre.src-pascal:before { content: 'Pascal'; }
    pre.src-ps:before { content: 'PostScript'; }
    pre.src-prolog:before { content: 'Prolog'; }
    pre.src-simula:before { content: 'Simula'; }
    pre.src-tcl:before { content: 'tcl'; }
    pre.src-tex:before { content: 'TeX'; }
    pre.src-plain-tex:before { content: 'Plain TeX'; }
    pre.src-verilog:before { content: 'Verilog'; }
    pre.src-vhdl:before { content: 'VHDL'; }
    pre.src-xml:before { content: 'XML'; }
    pre.src-nxml:before { content: 'XML'; }
    /* add a generic configuration mode; LaTeX export needs an additional
    (add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
    pre.src-conf:before { content: 'Configuration File'; }

    table { border-collapse:collapse; }
    caption.t-above { caption-side: top; }
    caption.t-bottom { caption-side: bottom; }
    td, th { vertical-align:top; }
    th.org-right { text-align: center; }
    th.org-left { text-align: center; }
    th.org-center { text-align: center; }
    td.org-right { text-align: right; }
    td.org-left { text-align: left; }
    td.org-center { text-align: center; }
    dt { font-weight: bold; }
    .footpara { display: inline; }
    .footdef { margin-bottom: 1em; }
    .figure { padding: 1em; }
    .figure p { text-align: center; }
    .equation-container {
    display: table;
    text-align: center;
    width: 100%;
    }
    .equation {
    vertical-align: middle;
    }
    .equation-label {
    display: table-cell;
    text-align: right;
    vertical-align: middle;
    }
    .inlinetask {
    padding: 10px;
    border: 2px solid gray;
    margin: 10px;
    background: #ffffcc;
    }
    #org-div-home-and-up
    { text-align: right; font-size: 70%; white-space: nowrap; }
    textarea { overflow-x: auto; }
    .linenr { font-size: smaller }
    .code-highlighted { background-color: #ffff00; }
    .org-info-js_info-navigation { border-style: none; }
    #org-info-js_console-label
    { font-size: 10px; font-weight: bold; white-space: nowrap; }
    .org-info-js_search-highlight
    { background-color: #ffff00; color: #000000; font-weight: bold; }
    .org-svg { }
    </style>
    <style>*{font-family: Iosevka Comfy !important; font-size: 24px;}</style>
    </head>
    <body>
    <div id="content" class="content">
    <h1 class="title">Вопросы на собеседованиях для QA Engineer</h1>
    <div id="table-of-contents" role="doc-toc">
    <h2>Table of Contents</h2>
    <div id="text-table-of-contents" role="doc-toc">
    <ul>
    <li><a href="#orgb6dfa78">1. Теория тестирования</a></li>
    <li><a href="#org3a286c8">2. Техники тест-дизайна</a></li>
    <li><a href="#org144af5a">3. Тестирование мобильных приложений</a></li>
    <li><a href="#orge0284c2">4. Тестирование бэкенда</a></li>
    <li><a href="#org411badd">5. Клиент-серверное взаимодействие</a>
    <ul>
    <li><a href="#org3b70000">5.1. RabbitMQ</a></li>
    </ul>
    </li>
    <li><a href="#org87c72fe">6. Базы данных</a></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orgb6dfa78" class="outline-2">
    <h2 id="orgb6dfa78"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div class="outline-text-2" id="text-1">
    <ul class="org-ul">
    <li><p>
    <b>7 принципов тестирования</b>
    </p>

    <p>
    Все 7 принципов тестирования:
    </p>

    <ol class="org-ol">
    <li>Тестирование демонстрирует надичие дефектов, а не их отсутствие</li>

    <li>Исчерпывающее тестирование недостижимо</li>

    <li>Заблуждение об отсутствии ошибок</li>

    <li>Раннее тестирование сохраняет время и деньги</li>

    <li>Принцип скопления или кластеризация дефектов</li>

    <li>Тестирование зависит от контекста</li>

    <li>Парадокс пестицида</li>
    </ol></li>

    <li><p>
    <b>Что такое тестирование?</b>
    </p>

    <p>
    Комплекс мероприятий, направленных на проведение проверок на соответствие продукта требованиям, к нему предъявляемым (прямым или косвенным).
    </p></li>

    <li><p>
    <b>Цель тестирования?</b>
    </p>

    <p>
    Донесение релевантной информации о продукте команде для принятия верных решений.
    </p></li>

    <li>Что такое верификация и валидация?

    <dl class="org-dl">
    <dt>Верификация</dt><dd>Процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям</dd>

    <dt>Валидация</dt><dd>Процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям пользователя</dd>
    </dl></li>

    <li>Виды тестирования

    <dl class="org-dl">
    <dt>Функциональное</dt><dd>Направлено на тестирование всех функций системы, для подтверждения, что каждая функция программы работает в соответствии с документацией</dd>

    <dt>Нефункциональное</dt><dd>Тестирование свойств, которые не относятся к функциональности системы: производительность, безопасность, локализация, удобство использования, установка/удаление</dd>

    <dt>Связанное с изменениями</dt><dd>Тестирование после исправления бага, с целью убедиться что внесенные изменения действительно решили проблему

    <dl class="org-dl">
    <dt>Регресионное</dt><dd>Проверка, что недавное изменение кода или данных сломало другие части разрабатываемого приложения</dd>

    <dt>Smoke</dt><dd>Проверка критически важной функциональности</dd>

    <dt>Sanity</dt><dd>Проверка только части приложения</dd>

    <dt>Re-test</dt><dd>Повторное тестирование конкретного функционала после исправления бага</dd>
    </dl></dd>
    </dl></li>

    <li>Методы тестирования

    <dl class="org-dl">
    <dt>Черный ящик</dt><dd>Тестирование основано на требованиях, при этом нет знаний о внутреннем устройстве системы, работаем только с внешними интерфейсами тестируемой системы</dd>

    <dt>Белый ящик</dt><dd>Тестирование, основанное на анализе внутренней структуры компонента или системы. Есть доступ к коду.</dd>

    <dt>Серый ящик</dt><dd>Нет четкого определения. Например нет доступа к коду, БД, но есть доступ к API, с помощью чего можем проверить интеграционные тесты, к примеру с помощью Postman</dd>
    </dl></li>

    <li><p>
    Пирамида тестирования
    </p>

    <p>
    e2e
    System testing
    Integration testing
    Unit testing
    </p>

    <dl class="org-dl">
    <dt>Unit testing</dt><dd>Тестируется атомарный модуль программы, чаще всего это функция. Таких тестов должно быть больше всего</dd>

    <dt>Integration testing</dt><dd>Тестирование интеграции систем и пакетов программ, тестирование интерфейсов с внешними системами</dd>

    <dt>System testing</dt><dd>Тестирование всей системы в целом, выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом</dd>

    <dt>E2E</dt><dd>Проверить так ли работает программа для конечного клиента, как рассчитывалось изначально. Самый трудозатратный и дорогой, поэтому находится на вершине пирамиды тестирования.</dd>
    </dl></li>

    <li>Аутентификация и авторизация

    <ul class="org-ul">
    <li>Идентификация - xпроцедура распознавания по его личному идентификатору</li>

    <li>Аутентификация - проверят действительно ли вы это вы</li>

    <li>Авторизация - Это предоставление прав пользователю к какому-то ресурсу

    <ul class="org-ul">
    <li>Веб-токен JSON (JWT - JSON web token) - это открытый стандарт для безопасной передачи данных между сторонами, а пользователи авторизуются с помощью пары открытый/закрытый ключ</li>

    <li>OAuth позволяет API аутентифицировать и получать доступ к запрошенной системе или ресурсу</li>
    </ul></li>
    </ul></li>

    <li><p>
    Как устроен жизненный цикл дефекта?
    </p>

    <p>
    Жизненный цикл дефекта - это последовательность этапов, которые проходит дефект от его обнаружения до закрытия. Хотя конкретные этапы могут немного отличаться в различных организациях или проектах, обычно жизненный цикл дефекта включает следующие этапы:
    </p>

    <ul class="org-ul">
    <li>Обнаружение и Локализация: Дефект может быть обнаружен тестировщиком, пользователем или автоматическим инструментом.</li>

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

    <li>Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как не воспроизводимый.</li>

    <li>Анализ/Приоретизация: Разработчик анализирует и исследует дефект, чтобы понять его причину и дать рекомендации по его устранению.</li>

    <li>Устранение: Разработчик исправляет дефект, внося соответствующие изменения в код.</li>

    <li>Тестирование: Исправленный дефект проходит тестирование, чтобы убедиться, что проблема была успешно устранена и не вызвала новых проблем.</li>

    <li>Проверка: Дефект проверяется и подтверждается тестировщиком или другим ответственным лицом.</li>

    <li>Закрытие: Если дефект был успешно исправлен и прошел проверку, он будет закрыт. Если дефект является невоспроизводимым или не может быть исправлен, он может быть помечен как &ldquo;не устранимый&rdquo; и не будет закрыт.

    <ol class="org-ol">
    <li>Баг обнаружен и локализован</li>
    <li>Создание баг-репорта</li>
    <li>Анализ/Приоритезация бага</li>
    <li>Устранения бага</li>
    <li>Тестирование (ре-тест)</li>
    <li>Закрытие (При устранении бага, баг закрывается, либо отправляется на доработку)</li>
    </ol></li>
    </ul></li>

    <li><p>
    Что такое дефект / баг?
    </p>

    <p>
    Дефект — это отклонение от исходной потребности в выводе, тогда как ошибка — это ошибка программирования.
    </p>

    <p>
    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечения.
    </p>

    <ul class="org-ul">
    <li>Ошибка — это ошибка кода в программе, которая приводит к неожиданным результатам, а дефект — это недостаток в функциональности или дизайне программы.</li>
    <li>Ошибка может быть исправлена, не влияя на общую производительность программы, тогда как дефект требует более серьезной переработки.</li>
    <li><p>
    Ошибку исправить легче, чем дефект, поскольку это специфическая проблема кодирования, тогда как дефект может быть более сложным и трудным для выявления.
    </p>

    <p>
    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечени
    </p>

    <p>
    В двух словах, это любое действие или результат, производимый программным обеспечением или системой, для которого оно не предназначено.
    </p></li>
    </ul>

    <p>
    Дефект — это ошибка, обнаруженная после запуска приложения. Это относится к различным проблемам с программными продуктами, например, к их внешнему поведению или внутренним функциям.
    </p>

    <p>
    Другими словами, в контексте тестирования Дефект — это расхождение между прогнозируемыми и фактическими результатами. Это когда критерии клиента не выполняются.
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <thead>
    <tr>
    <th scope="col" class="org-left">Параметры сравнения</th>
    <th scope="col" class="org-left">Ошибка</th>
    <th scope="col" class="org-left">Дефект</th>
    </tr>
    </thead>
    <tbody>
    <tr>
    <td class="org-left">Определение</td>
    <td class="org-left">Баги — это проблемы, обнаруженные в процессе тестирования.</td>
    <td class="org-left">Методологии оперативной разработки и регулярная оцxенка кода.</td>
    </tr>

    <tr>
    <td class="org-left">Был воспитан</td>
    <td class="org-left">Инженеры-испытатели.</td>
    <td class="org-left">Тестеры.</td>
    </tr>

    <tr>
    <td class="org-left">Тип</td>
    <td class="org-left">Логические, алгоритмические и ресурсные ошибки.</td>
    <td class="org-left">Критические, основные, второстепенные и тривиальные.</td>
    </tr>

    <tr>
    <td class="org-left">Причины возникновения</td>
    <td class="org-left">Отсутствующий код, неправильное кодирование или дополнительное кодирование.</td>
    <td class="org-left">Кодовая или логическая ошибка и неправильный ввод.</td>
    </tr>

    <tr>
    <td class="org-left">Предотвращени</td>
    <td class="org-left">Мы используем фундаментальные и точные подходы к разработке программного обеспечения.</td>
    <td class="org-left">Использование фундаментальных и точных подходов к разработке программного обеспечения.</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Отличия чек-лист и тест-кейс?
    </p>

    <p>
    Чек-лист — это список проверок, которые помогают тестировщику протестировать приложение или отдельные функции. Основная цель чеклиста состоит в том, чтобы вы не забыли проверить всё, что планировали (нетривиальное поведение приложения или сложная проверка, результат которой важно отметить уже сейчас, чтобы не забыть)
    </p>

    <ol class="org-ol">
    <li><b>Назначение</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Это документ, который содержит описание шагов, которые тестировщик должен выполнить, и ожидаемых результатов для проверки определенной функциональности или сценария.</li>
    <li><b>Чек-лист</b>: Это список пунктов или шагов, который помогает проверить выполнение определенных задач, процедур или критериев, но не обязательно предоставляет подробное описание ожидаемых результатов.</li>
    </ul></li>

    <li><b>Детализация</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Обычно более детализирован и содержит шаги тестирования, входные данные, ожидаемые результаты, и иногда дополнительные сведения о тестовых условиях и предварительных требованиях.</li>
    <li><b>Чек-лист</b>: Может быть менее подробным и ориентирован на быструю проверку выполнения задачи или соответствия критериям без необходимости подробного описания каждого шага.</li>
    </ul></li>

    <li><b>Применение</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Обычно используется для более формализованных и структурированных тестирований, таких как регрессионное тестирование, интеграционное тестирование и т. д.</li>
    <li><b>Чек-лист</b>: Часто используется для поверхностных проверок, быстрой оценки выполнения стандартов или проверки соответствия простым критериям.</li>
    </ul></li>

    <li><b>Структура</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Структурирован в виде документа, который включает в себя разделы для описания шагов, входных данных, ожидаемых результатов и другой информации.</li>
    <li><b>Чек-лист</b>: Может быть простым списком пунктов без строгой структуры.</li>
    </ul></li>

    <li><b>Управление изменениями</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Обычно поддерживает лучше управление изменениями, поскольку любые изменения в функциональности могут быть обновлены в соответствующих тест-кейсах.</li>
    <li><b>Чек-лист</b>: Может быть менее удобным для управления изменениями, так как он может представлять собой простой список без подробных описаний.</li>
    </ul></li>
    </ol>

    <p>
    Оба инструмента могут быть полезными в зависимости от контекста и целей тестирования. Тест-кейсы обычно используются для более формализованных тестов, в то время как чек-листы могут быть удобными для быстрых поверхностных проверок.
    </p>

    <ul class="org-ul">
    <li>Цель чек-листа – не пропустить ни одной важной детали в процессе тестирования.</li>
    <li>Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.</li>
    </ul></li>

    <li><p>
    При каких условиях будешь писать чек-лист, а при каких тест-кейс?
    </p>

    <p>
    Чек-листы подходят, если система не очень сложная, а тестированием занимаются специалисты, вовлечённые в продукт. Если система многокомпонентная, проверки требуют сложных условий, а тестировать продукт будут менее вовлечённые в него люди, лучше потратить время на тест-кейсы.
    </p>

    <blockquote>
    <p>
    Как утверждает Алексей Баранцев &ldquo;&#x2026; простейший чек-лист &#x2013; это список тест-кейсов.&rdquo; Я с ним согласен. Т.е. чек-лист лишь перечисление тестовых прецедентов, которые могут быть описаны, а могут и не быть. Так вот&#x2026; тестовые прецеденты должны постоянно поддерживаться в актуальном состоянии. А поскольку тестовые прецеденты более детальны, чем чек-листы, то и на их поддержание требуется больше ресурсов.
    </p>

    <p>
    Поэтому мое мнение таково: если хватает ресурсов, то можно иметь описание тестовых прецедентов, если нет - нужно обходиться чек-листами. Они, по крайней мере, позволят систематизировать тестирование. Я в фирме ввел как правило &ldquo;имение как минимум чек-листов&rdquo;.
    </p>
    </blockquote>

    <ul class="org-ul">
    <li>Насколько сотрудники вовлечены чтобы понять тест-кейсы?</li>

    <li>Насколько сложный продукт?</li>

    <li>Придется ли в будушем воспроизводить эти действия? Или это на один раз?</li>

    <li>Универсальность чек-листов сможет покрыть другой функционал? Или это плохая практика?</li>
    </ul></li>
    </ul>


    <ul class="org-ul">
    <li><p>
    Как ты понимаешь что достаточно тест кейсов и чек листов?
    </p>

    <p>
    Чтобы понять, достаточно ли тест-кейсов и чек-листов для проведения тестирования, необходимо учесть несколько факторов:
    </p>

    <ul class="org-ul">
    <li>Покрытие функциональности: Проверьте, что все основные функциональные требования системы покрываются соответствующими тест-кейсами и чек-листами. Если важные функции не покрыты, это может быть признаком недостаточного количества тестов.</li>

    <li>Покрытие различных сценариев: Убедитесь, что тест-кейсы и чек-листы учитывают различные сценарии использования системы. Рассмотрите разные варианты ввода данных, комбинации функций и возможные пути выполнения операций. Если все сценарии не учтены, может потребоваться больше тестов.</li>

    <li>Распределение ошибок: Проанализируйте результаты предыдущих тестов, чтобы определить, в каких областях системы обнаруживались наибольшее количество ошибок. Если в определенных областях системы было много проблем, может потребоваться создать дополнительные тест-кейсы для улучшения покрытия.</li>

    <li>Временные ограничения: Учтите ограничения по времени и ресурсам, которыми вы располагаете для проведения тестирования. Если у вас есть ограниченное время для тестирования, вы можете потребовать более точечных и фокусированных тест-кейсов.</li>
    </ul></li>
    </ul>

    <p>
    В конечном итоге, достаточность тест-кейсов и чек-листов - это субъективное мнение, основанное на конкретных требованиях, характеристиках и ограничениях проекта. Важно найти баланс между достаточностью тестов и доступными ресурсами.
    </p>


    <ul class="org-ul">
    <li><p>
    Есть ли опыт разработки тест данных
    </p>

    <p>
    Для больших объемов нет.
    </p></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org3a286c8" class="outline-2">
    <h2 id="org3a286c8"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div class="outline-text-2" id="text-2">
    <ul class="org-ul">
    <li>Техники тест дизайна какие знаешь?

    <ol class="org-ol">
    <li><p>
    Классы эквивалентности
    </p>

    <p>
    При любом значении из одного класса эквивалентности поведение системы должно быть одинаковым.
    </p></li>

    <li><p>
    Граничные значения
    </p>

    <p>
    Граница (или граничное значение) - это место где меняется поведение системы.
    </p></li>

    <li><p>
    Предугадывание ошибок
    </p>

    <p>
    Это техника создания гипотез о местах системы на основании документации и знаний о системе.
    Обычно с ее помощью создаются негативные кейсы.
    </p>

    <p>
    Предугадывать можно:
    </p>

    <ul class="org-ul">
    <li>По опыту</li>
    <li>С помощью знаний о работе системы</li>
    <li>С помощью знаний о работе ПО</li>
    <li>По документации</li>
    <li>По статистике (багов, тестов, использования)</li>
    </ul></li>

    <li>Причина-следствие</li>

    <li><p>
    Pairwise Testing
    </p>

    <p>
    Техника, которая проверяет все пары значений для заданных параметров.
    Тоесть каждое значение одного параметра хотябы один раз будет проверено с каждым значенем другого параметра.
    </p></li>

    <li><p>
    Исследовательское тестирование и туры Виттакера
    </p>

    <p>
    Это неформальный метод, при котором тесты проектируются во время их исполнения.
    Мы представляем все приложение как город.
    </p>

    <p>
    Когда применяется:
    </p>

    <ul class="org-ul">
    <li>Нужно обеспечить быструю обратную связь</li>
    <li>Нужно быстро изучить продукт</li>
    <li>Для разнообразия тестирования</li>
    <li>Нужно обнаружить и локализовать дефект</li>
    </ul></li>

    <li><p>
    Таблица принятия решений
    </p>

    <p>
    Способ компактного представления модели со сложной логикой; инструмент для упорядочения
    сложных бизнес требований, которые должны быть реализованы в продукте.
    Это взаимосвязь между множеством условий и действий.
    </p></li>
    </ol></li>

    <li><p>
    Эффективность тест-кейсов
    </p>

    <p>
    Когда переписываешь тест кейсы 10 раз в месяц
    </p>

    <ul class="org-ul">
    <li>Слишком много информации</li>
    <li>Подробные предусловия</li>
    <li>Дубли</li>
    <li>Дополнительные материалы</li>
    <li>Лишние проверки</li>
    </ul></li>

    <li>Как можно уменьшить количество тестов?

    <ul class="org-ul">
    <li>Объеденить позитивные тесты</li>

    <li>Выкинуть дубли</li>

    <li>Проверить функциональность 1 раз, а не 10.</li>
    </ul></li>

    <li><p>
    Составлял ли матрицу покрытия?
    </p>

    <p>
    Карта трассируемости это тестирование требований. На проекте не было времени этим заниматься.
    </p></li>

    <li><p>
    Когда не надо схлопывать тесты?
    </p>

    <p>
    Когда итоговый тест получается слишком сложным для восприятия.
    Или когла смешиваем разные функциональности
    </p></li>

    <li><p>
    Занимался ли тестированием требований/спецификаций?
    </p>

    <p>
    Нет.
    </p></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org144af5a" class="outline-2">
    <h2 id="org144af5a"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div class="outline-text-2" id="text-3">
    <ul class="org-ul">
    <li>Нативные и браузерные приложения в чем отличия?

    <ul class="org-ul">
    <li>Нативные приложения устанавливаются непосредственно на устройство пользователя</li>

    <li>Нативные приложения разрабатываются для конкретной платформы (например, iOS или Android) и могут использовать функциональность и возможности, доступные на этой платформе. Браузерные приложения, с другой стороны, не зависят от конкретной платформы и могут работать на разных устройствах, если они поддерживают стандарты веб-технологий.</li>

    <li>Интерфейс и возможности: Нативные приложения могут использовать все функции и возможности устройства, на котором они запущены, такие как камера, геолокация, доступ к контактам и т. д. Браузерные приложения ограничены функциями и возможностями, предоставляемыми веб-браузером и доступными через JavaScript API.</li>

    <li>Обновления и развертывание: Нативные приложения требуют установки обновлений, которые разработчики должны выпускать и распространять через магазины приложений. Браузерные приложения автоматически обновляются при каждом запуске через сеть, что упрощает процесс развертывания и обновления.</li>

    <li><p>
    Доступность к платформенным функциям: Нативные приложения могут использовать специфические API, доступные на платформе, такие как Apple Pay на IOS или службы уведомлений на Android. Браузерные приложения ограничены функциональностью, предоставляемой веб-браузером и его возможностями расширений.
    </p>

    <p>
    <b>Нативные</b>
    </p>

    <p>
    Плюсы
    </p>

    <ul class="org-ul">
    <li>Наличие гайдлайнов</li>
    <li>Прямое подключение всех фишек ОС</li>
    <li>Работа без интернет</li>
    </ul>

    <p>
    Минусы
    </p>

    <ul class="org-ul">
    <li>Соответствие гайдлайнам</li>
    <li>Дорого</li>
    </ul>

    <p>
    <b>Web</b>
    </p>

    <p>
    Плюсы
    </p>

    <ul class="org-ul">
    <li>Не нужно обновлять</li>
    <li>Не нужно устанавливать</li>
    </ul>

    <p>
    Минусы
    </p>

    <ul class="org-ul">
    <li>Нужен интернет</li>
    <li>Низкая производительность</li>
    <li>Нет доступа к «железу» девайса</li>
    </ul></li>
    </ul></li>

    <li>специфические тестирования мобилок знаешь?

    <ol class="org-ol">
    <li>Тестирование на разных платформах</li>

    <li>Адаптивное тестирование</li>

    <li>Тестирование в разных сетях</li>

    <li>Тестирование поведения в фоновом режиме</li>

    <li>Тестирование использования ресурсов устройства</li>

    <li>Тестирования пользовательского интерфейса (UI)</li>

    <li>Интернационализация и локализация (i18n) (l10n)</li>

    <li>Тестирование удобства использования</li>

    <li>Тестирование производительности</li>

    <li>Тестирование энергопотребления</li>

    <li>Тестирование безопасности</li>

    <li>Тестирование обновления</li>

    <li>Push-нотификации</li>

    <li>Конфигурационное тестирование</li>
    </ol></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orge0284c2" class="outline-2">
    <h2 id="orge0284c2"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div class="outline-text-2" id="text-4">
    <ul class="org-ul">
    <li>Знаешь что такое монолитный бекенд?</li>
    </ul>

    <p>
    Монолитный бэкенд - это архитектурный подход, при котором вся функциональность и логика приложения размещены в одной единственной монолитной системе. В этом подходе весь код выполняется и развертывается как единое целое, включая базу данных, бизнес-логику, интерфейсы программирования (API) и т. д.
    </p>

    <p>
    Монолитный бэкенд имеет следующие особенности:
    </p>

    <ol class="org-ol">
    <li>Одна единица разработки и развертывания: все компоненты связаны вместе и разрабатываются, тестируются и развертываются как единое приложение.</li>
    <li>Менее гибкое масштабирование: потому что все функции приложения находятся в одном монолите, его масштабирование может быть сложным. Если требуется масштабирование, то необходимо масштабировать всю систему, даже если только одна функция нуждается в дополнительных ресурсах.</li>
    <li>Сильная связность компонентов: все компоненты внутри монолитного бэкенда имеют сильную связность друг с другом, и изменение одного компонента может затронуть другие компоненты.</li>
    <li>Однородность: монолит может иметь однородную кодовую базу и среду разработки для всех компонентов.</li>
    </ol>

    <p>
    При монолитной архитектуре одно приложение включает в себя весь функционал.
    </p>

    <p>
    Например есть огромная банковская система.
    В рамках одной системы:
    </p>
    <ul class="org-ul">
    <li>хранится вся информация о клиенте – физ лицах и юр лицах,</li>
    <li>все операции по клиенту, как операционные так и финансовые</li>
    <li>все заявки которые оформляет клиент</li>
    <li>в ней работают все операторы банка, осуществляют звонки, обмен сообщениями в чате и тд и тп.</li>
    </ul>
    <p>
    Если мы «выключим» монолит, мы выключим весь его функционал целиком.
    </p>

    <ul class="org-ul">
    <li><p>
    Опыт работы с тест логами есть? какие знаешь?
    </p>

    <p>
    <b>Kibana</b> предоставляет визуализацию результатов
    </p></li>

    <li>Что можно логировать?

    <ul class="org-ul">
    <li>вызовы методов, тело, параметры, ответ</li>
    <li>ошибки пользовательские и серверные</li>
    <li>запросы в БД</li>
    <li>служебная и вспомогательная информация об изменениях в системе</li>
    </ul></li>

    <li><p>
    Интеграционное тестирование что знаешь?
    </p>

    <p>
    Интеграционное тестирование предназначено для проверки насколько хорошо два или более компонента ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
    </p>

    <p>
    Уровни интеграционного тестирования:
    </p>

    <ul class="org-ul">
    <li><p>
    Компонентный интеграционный уровень (Component Integration testing)
    </p>

    <p>
    Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
    </p></li>

    <li><p>
    Системный интеграционный уровень (System Integration Testing)
    </p>

    <p>
    Проверяется взаимодействие между разными системами после проведения системного тестирования.
    </p></li>
    </ul></li>

    <li><p>
    Какие подходы к тестированию интеграции знаешь? (подход большего взрыва)
    </p>

    <p>
    Подходы к интеграционному тестированию:
    </p>

    <ul class="org-ul">
    <li><p>
    Снизу вверх (Bottom Up Integration)
    </p>

    <p>
    Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения
    </p></li>

    <li><p>
    Сверху вниз (Top Down Integration)
    </p>

    <p>
    Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз. (см. также Top Down Integration)
    </p></li>

    <li><p>
    Большой взрыв (&ldquo;Big Bang&rdquo; Integration)
    </p>

    <p>
    &ldquo;Большой взрыв&rdquo; (Big Bang Integration) - это метод интеграции программного обеспечения, при котором все компоненты или модули системы интегрируются одновременно. В этом подходе все изменения вносятся и тестируются в единой среде, и общая работоспособность системы проверяется в целом.
    </p>

    <p>
    Основные характеристики метода &ldquo;Большой взрыв&rdquo;:
    </p>

    <ul class="org-ul">
    <li><b>Интеграция в конце</b>: Интеграция всех компонентов происходит ближе к концу разработки проекта. Весь код, разработанный различными командами или индивидуальными разработчиками, собирается и интегрируется вместе.</li>

    <li><b>Одновременная интеграция</b>: Все компоненты или модули интегрируются одновременно. Это может создать ситуацию, когда множество изменений вводится в систему одновременно, что может сделать процесс выявления и устранения возможных конфликтов более сложным.</li>

    <li><b>Тестирование в целом</b>: После интеграции производится тестирование системы в ее целом. Это включает в себя проверку общей работоспособности, взаимодействия компонентов и корректности функционирования системы в целом.</li>

    <li><b>Больший риск конфликтов</b>: Поскольку интеграция происходит в конце разработки, есть риск обнаружения серьезных конфликтов и ошибок, которые могли бы быть выявлены и устранены на более ранних этапах.</li>

    <li><b>Менее предсказуемый процесс</b>: Такой метод интеграции может создать более сложный и менее предсказуемый процесс разработки, особенно если существуют неучтенные зависимости или непредвиденные проблемы.</li>
    </ul>

    <p>
    &ldquo;Большой взрыв&rdquo; может быть эффективен для небольших проектов или в ситуациях, где особенности проекта не позволяют использовать более инкрементальные методы интеграции. Однако, такой подход требует внимательного планирования и управления рисками, чтобы успешно интегрировать и протестировать систему.
    </p></li>
    </ul></li>

    <li><p>
    Клиент-серверное взаимодействие как происходит?
    </p>

    <p>
    Клиент-серверное взаимодействие - это модель коммуникации между компьютерами, где один компьютер (клиент) запрашивает ресурсы или услуги у другого компьютера (сервера). Этот процесс происходит по протоколу, который определяет правила и формат обмена данными между клиентом и сервером.
    </p>

    <p>
    Вот общая схема клиент-серверного взаимодействия:
    </p>

    <ol class="org-ol">
    <li>Клиент отправляет запрос на сервер. Клиент может быть программой, приложением или даже другим сервером. Запрос содержит информацию о том, какие ресурсы или услуги требуются.</li>

    <li>Сервер принимает запрос от клиента и анализирует его. Сервер может быть физическим компьютером или виртуальной машиной, которая обрабатывает запросы от клиентов.</li>

    <li>Сервер обрабатывает запрос и генерирует ответ. В зависимости от запроса, сервер может выполнять различные операции, обращаться к базе данных, обрабатывать данные и генерировать результат.</li>

    <li>Сервер отправляет ответ обратно клиенту. Ответ содержит запрошенные ресурсы или информацию, которую клиент ожидал получить.</li>

    <li>Клиент принимает ответ от сервера и обрабатывает его. Клиент может использовать полученные данные для отображения на экране, выполнения дальнейших операций или передачи данных другим компонентам системы.</li>
    </ol>

    <p>
    Важно отметить, что клиент и сервер могут взаимодействовать по различным протоколам, таким как HTTP, FTP, SMTP и т.д. Каждый протокол определяет свои правила и формат обмена данными.
    </p></li>

    <li><p>
    Какая разница между двухзвенной и трехзвенной?
    </p>

    <p>
    Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т.е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса.
    </p>

    <p>
    Такая модель показала свою неэффективность ввиду того, что при активной работе с таблицами БД возникает большая нагрузка на сеть.
    </p>

    <p>
    Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом:
    </p>

    <ol class="org-ol">
    <li>Представление данных — на стороне клиента.</li>

    <li>Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).</li>

    <li>Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.</li>
    </ol></li>

    <li><p>
    Разница между толстым и тонким клиентом?
    </p>

    <ol class="org-ol">
    <li>Толстый клиент (Fat Client):</li>

    <li><b>Локальная обработка:</b>
    <ul class="org-ul">
    <li><b>Определение:</b> Толстый клиент имеет значительную локальную обработку и хранение данных.</li>
    <li><b>Характеристики:</b> Значительная часть бизнес-логики и функциональности находится на клиентской стороне.</li>
    </ul></li>

    <li><b>Графический интерфейс:</b>
    <ul class="org-ul">
    <li><b>Примеры:</b> Нативные приложения, устанавливаемые на устройстве пользователя (например, десктопные приложения).</li>
    </ul></li>

    <li><b>Объем передаваемых данных:</b>
    <ul class="org-ul">
    <li><b>Коммуникация:</b> Обычно взаимодействует с сервером для получения данных, но имеет богатый функциональный интерфейс и часто загружает больший объем данных для локальной обработки.</li>
    </ul></li>

    <li><b>Преимущества:</b>
    <ul class="org-ul">
    <li>Может обеспечивать высокую производительность и отзывчивость, так как множество операций выполняется локально.</li>
    </ul></li>

    <li>Тонкий клиент (Thin Client):</li>

    <li><b>Минимальная локальная обработка:</b>
    <ul class="org-ul">
    <li><b>Определение:</b> Тонкий клиент имеет минимальную локальную обработку и полагается на сервер для большей части обработки и хранения данных.</li>
    <li><b>Характеристики:</b> Минимальный функционал на клиентской стороне, часто только графический интерфейс и минимальная логика.</li>
    </ul></li>

    <li><b>Графический интерфейс:</b>
    <ul class="org-ul">
    <li><b>Примеры:</b> Веб-приложения, которые работают в браузере.</li>
    </ul></li>

    <li><b>Объем передаваемых данных:</b>
    <ul class="org-ul">
    <li><b>Коммуникация:</b> Взаимодействует с сервером для получения данных и обновлений, пересылает минимальные данные для отображения и ввода.</li>
    </ul></li>

    <li><b>Преимущества:</b>
    <ul class="org-ul">
    <li>Легко управлять и обновлять, так как большинство изменений происходит на сервере. Обеспечивает централизованное управление приложениями.</li>
    </ul></li>
    </ol>

    <p>
    Общие соображения:
    </p>

    <ul class="org-ul">
    <li>Выбор между толстым и тонким клиентом зависит от требований проекта, характера приложения и сетевой инфраструктуры.</li>

    <li>Толстый клиент часто приводит к более высоким требованиям к управлению, так как обновления могут быть сложными и требовать установки на каждом устройстве.</li>

    <li>Тонкий клиент может быть более удобным с точки зрения обновлений и поддержки, но может требовать более сильной сетевой инфраструктуры.</li>
    </ul></li>

    <li>Какие протоколы знаешь?

    <ol class="org-ol">
    <li>HTTP (Hypertext Transfer Protocol) - протокол передачи гипертекста, используемый в веб-браузерах и веб-серверах для обмена данными.</li>

    <li>FTP (File Transfer Protocol) - протокол передачи файлов, используемый для обмена файлами между клиентом и сервером.</li>

    <li>SMTP (Simple Mail Transfer Protocol) - протокол передачи электронной почты, используемый для отправки почты от клиента к серверу и между серверами.</li>

    <li>POP3 (Post Office Protocol version 3) - протокол получения электронной почты, используемый для получения почты с сервера на клиентскую программу.</li>

    <li>IMAP (Internet Message Access Protocol) - протокол доступа к электронной почте, позволяющий клиенту получать письма с сервера и управлять ими на сервере.</li>

    <li>DNS (Domain Name System) - протокол системы доменных имен, используемый для преобразования доменных имен в IP-адреса и наоборот.</li>

    <li>TCP/IP (Transmission Control Protocol/Internet Protocol) - набор протоколов, используемых для обмена данными в сети Интернет.</li>

    <li>SSH (Secure Shell) - протокол безопасного удаленного доступа к компьютеру по сети.</li>

    <li>SNMP (Simple Network Management Protocol) - протокол управления сетью, используемый для мониторинга и управления устройствами в сети.</li>

    <li>DHCP (Dynamic Host Configuration Protocol) - протокол динамической настройки сетевых параметров, используемый для автоматической настройки IP-адресов и других сетевых параметров на компьютерах в сети.</li>
    </ol></li>

    <li><p>
    В чем различие методов GET и POST?
    </p>

    <p>
    Основное состоит в способе передачи данных:
    </p>

    <p>
    Метод GET отправляет скрипту всю собранную информацию как часть URL: <a href="http://www.komtet.ru/script.php?login=admin&amp;name=komtet">http://www.komtet.ru/script.php?login=admin&amp;name=komtet</a>
    </p>

    <p>
    Метод POST передает данные таким образом, что пользователь сайта уже не видит передаваемые скрипту данные: <a href="http://www.komtet.ru/script.php">http://www.komtet.ru/script.php</a>
    </p>

    <p>
    Кроме того:
    </p>

    <ul class="org-ul">
    <li>Количество информации, передаваемой методом GET через URL строку ограничено 2048 символами (минус служебная информация браузера);</li>

    <li>Страницу, сгенерированную методом GET, можно добавить в закладки и поделиться ссылкой;</li>

    <li>Sensitive data в таком открытом виде очевидно плохо влияют на безопасность;</li>

    <li>Метод POST в отличие от метода GET позволяет передавать запросу файлы;</li>

    <li>При использовании метода GET существует риск того, что поисковый робот может выполнить тот или иной открытый запрос.</li>

    <li>GET запросы кешируются, POST - нет</li>
    </ul></li>

    <li><p>
    <b>Структура HTTP-запроса и ответа</b>
    </p>

    <p>
    HTTP Запрос:
    </p>

    <ol class="org-ol">
    <li><b>Строка запроса (Request Line):</b>

    <ul class="org-ul">
    <li>Метод запроса (GET, POST, PUT, DELETE и т.д.).</li>
    <li>URI (Uniform Resource Identifier) - путь к ресурсу.</li>
    <li>Версия HTTP (например, HTTP/1.1).</li>
    </ul></li>
    </ol>

    <p>
    Пример:
    <code>GET /index.html HTTP/1.1</code>
    </p>

    <ol class="org-ol">
    <li><p>
    <b>Заголовки (Headers):</b>
    </p>

    <ul class="org-ul">
    <li>Различные метаданные о запросе, такие как <code>Host</code>, <code>User-Agent</code>, <code>Accept</code>, и т.д.</li>
    </ul>

    <p>
    Пример:
    </p>

    <div class="org-src-container">
    <pre class="src src-none">Host: www.example.com
    User-Agent: Chrome/91.0.4472.124
    Accept: text/html,application/xhtml+xml,application/xml;
    </pre>
    </div></li>

    <li><b>Тело запроса (Request Body):</b>

    <ul class="org-ul">
    <li><p>
    Данные, отправляемые с запросом. Обычно используется для POST и PUT запросов.
    </p>

    <p>
    Пример:
    <code>username=johndoe&amp;password=secret</code>
    </p></li>
    </ul></li>
    </ol>

    <p>
    HTTP Ответ:
    </p>

    <ol class="org-ol">
    <li><p>
    <b>Строка состояния (Status Line):</b>
    </p>

    <ul class="org-ul">
    <li>Версия HTTP.</li>
    <li>Код состояния - трехзначный числовой код, обозначающий успешность или ошибку ответа.</li>
    <li>Текстовое описание кода состояния.</li>
    </ul>

    <p>
    Пример:
    <code>HTTP/1.1 200 OK</code>
    </p></li>

    <li><b>Заголовки (Headers):</b>

    <ul class="org-ul">
    <li><p>
    Метаданные ответа, такие как <code>Content-Type</code>, <code>Content-Length</code>, и т.д.
    </p>

    <p>
    Пример:
    </p>
    <div class="org-src-container">
    <pre class="src src-none">Content-Type: text/html; charset=utf-8
    Content-Length: 1234
    </pre>
    </div></li>
    </ul></li>

    <li><b>Тело ответа (Response Body):</b>

    <ul class="org-ul">
    <li><p>
    Данные, возвращаемые сервером. Например, HTML-страница, изображение и т.д.
    </p>

    <p>
    Пример (HTML):
    </p>
    <div class="org-src-container">
    <pre class="src src-html">&lt;<span style="color: #5317ac;">!DOCTYPE</span> html&gt;
    &lt;<span style="color: #721045;">html</span>&gt;
    &lt;<span style="color: #721045;">head</span>&gt;
    &lt;<span style="color: #721045;">title</span>&gt;<span style="font-weight: bold; text-decoration: underline;">Example Page</span>&lt;/<span style="color: #721045;">title</span>&gt;
    &lt;/<span style="color: #721045;">head</span>&gt;
    &lt;<span style="color: #721045;">body</span>&gt;
    &lt;<span style="color: #721045;">h1</span>&gt;<span style="font-weight: bold; text-decoration: underline;">Hello, World!</span>&lt;/<span style="color: #721045;">h1</span>&gt;
    &lt;/<span style="color: #721045;">body</span>&gt;
    &lt;/<span style="color: #721045;">html</span>&gt;
    </pre>
    </div></li>
    </ul></li>
    </ol>

    <p>
    Это общая структура. Некоторые запросы и ответы могут не содержать тела, и в некоторых случаях могут использоваться дополнительные параметры, такие как параметры запроса (в строке запроса) или куки (в заголовках).
    </p></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org411badd" class="outline-2">
    <h2 id="org411badd"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div class="outline-text-2" id="text-5">
    <ul class="org-ul">
    <li><p>
    PATCH и PUT отличия?
    </p>

    <ol class="org-ol">
    <li>Метод PATCH используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.</li>

    <li>Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.</li>
    </ol>

    <p>
    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.
    </p></li>

    <li><p>
    Можно ли создать метод делит который будет создавать?
    </p>

    <p>
    Можно обработать запрос по своему усмотрению.
    </p></li>

    <li><p>
    Что такое SOAP?
    </p>

    <p>
    SOAP – протокол обмена структурированными сообщениями.
    </p>

    <ul class="org-ul">
    <li>Нет специального стиля</li>

    <li>Только один тип запросов</li>

    <li>В body только XML</li>

    <li>SOAP. Протокол используется для обмена произвольными сообщениями в формате XML, а также для вызова процедур. SOAP ограничивает структуры ваших сообщений. Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML.</li>

    <li>SOAP использует WSDL. Он предоставляет поставщикам служб простой способ описания базового формата запросов, передаваемых их системам, независимо от применяемой реализации.</li>

    <li>SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, SMTP, TCP.</li>
    </ul></li>

    <li><p>
    Как бы вы решили какой из REST или SOAP веб сервисов использовать?
    </p>

    <p>
    REST против SOAP можно перефразировать как &ldquo;Простота против Стандарта&rdquo;. В случае REST (простота) у вас будет скорость, расширяемость и поддержка многих форматов. В случае с SOAP у вас будет больше возможностей по безопасности (WS-security) и транзакционная безопасность (ACID).
    </p></li>

    <li><p>
    Что такое WSDL?
    </p>

    <p>
    WSDL (англ. Web Services Description Language) - язык описания веб-сервисов и доступа к ним, основанный на языке XML.
    </p>

    <p>
    Каждый документ WSDL 1.1 можно разбить на следующие логические части:
    </p>

    <ul class="org-ul">
    <li>определение типов данных (types) - определение вида отправляемых и получаемых сервисом XML-сообщений</li>

    <li>элементы данных (message) - сообщения, используемые web-сервисом</li>

    <li>абстрактные операции (portType) - список операций, которые могут быть выполнены с сообщениями</li>

    <li>связывание сервисов (binding) - способ, которым сообщение будет доставлено</li>
    </ul></li>

    <li>В чем отличия REST и SOAP?

    <ul class="org-ul">
    <li>REST поддерживает различные форматы: text, JSON, XML, HTML, YAML;
    SOAP - только XML</li>

    <li>REST работает только по HTTP(S), а SOAP может работать с различными протоколами</li>

    <li>REST может работать с ресурсами. Каждый URL это представление какого-либо ресурса. SOAP работает с операциями, которые реализуют какую-либо бизнес логику с помощью нескольких интерфейсов</li>

    <li>SOAP на основе чтения не может быть помещена в кэш, а REST в этом случае может быть закэширован</li>

    <li>SOAP поддерживает SSL и WS-security, в то время как REST - только SSL</li>

    <li>SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но не один из ACID не совместим с двух фазовым коммитом.</li>
    </ul></li>

    <li>На коленке сделать примитивный JSON</li>
    </ul>

    <div class="org-src-container">
    <pre class="src src-json">{
    <span style="color: #5317ac;">"&#1089;&#1090;&#1088;&#1086;&#1082;&#1072;"</span>: <span style="color: #2544bb;">"&#1055;&#1088;&#1080;&#1084;&#1077;&#1088; JSON"</span>,
    <span style="color: #5317ac;">"&#1094;&#1077;&#1083;&#1086;&#1077; &#1095;&#1080;&#1089;&#1083;&#1086;"</span>: <span style="color: #0000c0;">42</span>,
    <span style="color: #5317ac;">"&#1076;&#1088;&#1086;&#1073;&#1085;&#1086;&#1077; &#1095;&#1080;&#1089;&#1083;&#1086;"</span>: <span style="color: #0000c0;">3.14159</span>,
    <span style="color: #5317ac;">"&#1083;&#1086;&#1075;&#1080;&#1095;&#1077;&#1089;&#1082;&#1086;&#1077; &#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;"</span>: <span style="color: #0000c0;">true</span>,
    <span style="color: #5317ac;">"&#1084;&#1072;&#1089;&#1089;&#1080;&#1074;"</span>: [<span style="color: #0000c0;">1</span>, <span style="color: #0000c0;">2</span>, <span style="color: #0000c0;">3</span>, <span style="color: #0000c0;">4</span>, <span style="color: #0000c0;">5</span>],
    <span style="color: #5317ac;">"&#1086;&#1073;&#1098;&#1077;&#1082;&#1090;"</span>: {
    <span style="color: #5317ac;">"&#1082;&#1083;&#1102;&#1095;1"</span>: <span style="color: #2544bb;">"&#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;1"</span>,
    <span style="color: #5317ac;">"&#1082;&#1083;&#1102;&#1095;2"</span>: <span style="color: #2544bb;">"&#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;2"</span>
    },
    <span style="color: #5317ac;">"&#1085;&#1091;&#1083;&#1077;&#1074;&#1086;&#1077; &#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;"</span>: <span style="color: #0000c0;">null</span>
    }
    </pre>
    </div>

    <ul class="org-ul">
    <li><p>
    Идемпотентность
    </p>

    <p>
    Пример идемпотентного PATCH-запроса: Предположим, у нас есть ресурс &ldquo;пользователь&rdquo; с полями &ldquo;имя&rdquo; и &ldquo;электронная почта&rdquo;. Мы отправляем PATCH-запрос с обновленным значением только для поля &ldquo;имя&rdquo;. Если этот запрос применяется несколько раз, состояние пользователя на сервере не изменится после первого применения, поскольку в данном примере PATCH обновляет значение поля &ldquo;имя&rdquo;. Повторное применение запроса просто повторно обновит поле &ldquo;имя&rdquo; на то же значение. Это случай, когда PATCH настроен на обновление, а не на добавление. В таком случае PATCH идемпотентен.
    </p>

    <p>
    Пример неидемпотентного PATCH-запроса: Предположим, у нас есть ресурс &ldquo;счет&rdquo; с полем &ldquo;баланс&rdquo;. Мы отправляем PATCH-запрос с обновлением значения поля &ldquo;баланс&rdquo; на +10 единиц. Если этот запрос применяется несколько раз, состояние счета на сервере будет изменяться после каждого применения. Каждый запрос увеличивает баланс на 10 единиц, поэтому повторное применение запроса будет иметь различный эффект каждый раз. Это случай, когда PATCH настроен на добавление, а не на обновление. В этом случае PATCH является неидемпотентным, т.к. каждый повторный вызов меняет состояние ресурса (прибавляет +10 к балансу).
    </p>

    <p>
    Идемпотентными методами являются: GET, PUT, DELETE, HEAD и OPTIONS. POST и PATCH не входят в эту группу.
    </p></li>

    <li><p>
    Статусы HTTP
    </p>

    <p>
    Статусы HTTP (HTTP status codes) - это числовые коды, возвращаемые сервером в ответ на запрос клиента к веб-ресурсу. Они предоставляют информацию о результате выполнения запроса. Каждый статус состоит из трех цифр и имеет свое определенное значение.
    </p>

    <ul class="org-ul">
    <li><p>
    Информационные (Informational - 1xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>100 Continue</b></td>
    <td class="org-left">Запрос был успешно принят, и клиент может продолжать выполнение запроса</td>
    </tr>

    <tr>
    <td class="org-left"><b>101 Switching Protocols</b></td>
    <td class="org-left">Сервер согласен на изменение протоколов по запросу клиента</td>
    </tr>

    <tr>
    <td class="org-left"><b>102 Processing</b></td>
    <td class="org-left">Сервер получил запрос и продолжает процессирование (WebDAV)</td>
    </tr>

    <tr>
    <td class="org-left"><b>103 Early Hints</b></td>
    <td class="org-left">Этот статус сообщает клиенту, что сервер намеревается отправить часть ответа, которая может быть использована клиентом для начала предварительного отображения до завершения всего ответа</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Успех (Successful - 2xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>200 OK</b></td>
    <td class="org-left">Запрос успешно выполнен</td>
    </tr>

    <tr>
    <td class="org-left"><b>201 Created</b></td>
    <td class="org-left">Запрос успешно выполнен, и создан новый ресурс</td>
    </tr>

    <tr>
    <td class="org-left"><b>204 No Content</b></td>
    <td class="org-left">Запрос успешно выполнен, но ответ не содержит представления (например, при удалении ресурса)</td>
    </tr>

    <tr>
    <td class="org-left"><b>207 Multi-Status</b></td>
    <td class="org-left">Обработка завершена, но вернулось несколько статусов (WebDAV)</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Перенаправление (Redirection - 3xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>301 Moved Permanently</b></td>
    <td class="org-left">Ресурс перемещен по новому URI, клиент должен использовать новый URI при следующих запросах.</td>
    </tr>

    <tr>
    <td class="org-left"><b>302 Found</b></td>
    <td class="org-left">Ресурс временно перемещен. Клиент должен использовать новый URI, но старый URI также может быть использован временно</td>
    </tr>

    <tr>
    <td class="org-left"><b>304 Not Modified</b></td>
    <td class="org-left">Ресурс не был изменен с момента последнего запроса клиента. Клиент может использовать свою копию ресурса</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Ошибки клиента (Client Error - 4xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>400 Bad Request</b></td>
    <td class="org-left">Некорректный запрос от клиента</td>
    </tr>

    <tr>
    <td class="org-left"><b>401 Unauthorized</b></td>
    <td class="org-left">Требуется аутентификация для доступа к ресурсу</td>
    </tr>

    <tr>
    <td class="org-left"><b>403 Forbidden</b></td>
    <td class="org-left">Клиент не имеет прав доступа к ресурсу</td>
    </tr>

    <tr>
    <td class="org-left"><b>404 Not Found</b></td>
    <td class="org-left">Запрашиваемый ресурс не найден</td>
    </tr>

    <tr>
    <td class="org-left"><b>404 Method Not Allowed</b></td>
    <td class="org-left">Этот статус часто возвращается, когда клиент пытается выполнить запрос с использованием метода HTTP, который не разрешен для данного URL</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Ошибки сервера (Server Error - 5xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>500 Internal Server Error</b></td>
    <td class="org-left">Общая ошибка сервера</td>
    </tr>

    <tr>
    <td class="org-left"><b>501 Not Implemented</b></td>
    <td class="org-left">Функционал, необходимый для выполнения запроса, не поддерживается сервером</td>
    </tr>

    <tr>
    <td class="org-left"><b>503 Service Unavailable</b></td>
    <td class="org-left">Сервер временно не может обрабатывать запросы (например, из-за перегрузки или обслуживания)</td>
    </tr>
    </tbody>
    </table></li>
    </ul></li>
    </ul>
    </div>
    <div id="outline-container-org3b70000" class="outline-3">
    <h3 id="org3b70000"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    <div class="outline-text-3" id="text-5-1">
    <ul class="org-ul">
    <li><p>
    Что такое RabbitMQ?
    </p>

    <blockquote>
    <p>
    RabbitMQ это брокер сообщений, если в двух словах то служит для передачи данных между микросервисами
    </p>
    </blockquote></li>
    </ul>


    <div id="org86d0df8" class="figure">
    <p><img src="scheme.png" alt="scheme.png" />
    </p>
    </div>

    <blockquote>
    <p>
    Производитель (producer) – это компонент (приложение, сервис или другая часть системы), который создает и отправляет сообщения в RabbitMQ.
    </p>

    <p>
    Потребитель (consumer) – это компонент, который подписывается на очередь в RabbitMQ и активно слушает (получает) сообщения из этой очереди.
    </p>
    </blockquote>

    <p>
    Так же как и в <b>Kafka</b>, но отличие состоит в обработке сообщений. Отличие состоит в наличии Exchange (обменник). Сообщение сначала попадает в обменник и дальше на основании ключей попадает в очередь.
    </p>


    <div id="org38bf0de" class="figure">
    <p><img src="rabbit_mq.png" alt="rabbit_mq.png" />
    </p>
    </div>

    <ul class="org-ul">
    <li><p>
    Что такое протокол AMQP?
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left">Прикладной уровень</td>
    <td class="org-left">HTTP WebSocket DNS <b>AMQP</b></td>
    </tr>

    <tr>
    <td class="org-left">Транспортный уровень</td>
    <td class="org-left">TCP UDP</td>
    </tr>

    <tr>
    <td class="org-left">Сетевой уровень</td>
    <td class="org-left">IP ICMP ARP DHCP</td>
    </tr>

    <tr>
    <td class="org-left">Уровень сетевого доступа</td>
    <td class="org-left">Ethernet Wi-Fi</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    По какому принципу организована очерелдь в RabbitMQ?
    </p>

    <p>
    <b>FIFO</b> - First In First Out
    </p></li>

    <li><p>
    Основные типы обменников
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left">default</td>
    <td class="org-left">binding all queues</td>
    <td class="org-left">К нему по умолчанию привязаны все очереди в RabbitMQ</td>
    </tr>

    <tr>
    <td class="org-left">fanout</td>
    <td class="org-left">push to all queues</td>
    <td class="org-left">Сообщения отправляются во все очереди</td>
    </tr>

    <tr>
    <td class="org-left">direct</td>
    <td class="org-left">routing key</td>
    <td class="org-left">Сообщения маршрутизируются с помощью routing key</td>
    </tr>

    <tr>
    <td class="org-left">topic</td>
    <td class="org-left"># *</td>
    <td class="org-left">Поиск происходит по шаблону # или *</td>
    </tr>

    <tr>
    <td class="org-left">headers</td>
    <td class="org-left">routing headers</td>
    <td class="org-left">Маршрутизация с помощью заголовков</td>
    </tr>

    <tr>
    <td class="org-left">deadletter</td>
    <td class="org-left">not responding</td>
    <td class="org-left">Сюда попадают все сообщения которые</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Почему мы привязали один обменник, а по факту отображается два?
    </p>

    <p>
    Дефолтный обменник AMQP, который по-умолчанию привязан ко всем очередям
    </p></li>

    <li>Что такое шина данных?</li>
    </ul>
    </div>
    </div>
    </div>
    <div id="outline-container-org87c72fe" class="outline-2">
    <h2 id="org87c72fe"><span class="section-number-2">6.</span> Базы данных</h2>
    <div class="outline-text-2" id="text-6">
    <ul class="org-ul">
    <li>Какие виды БД?

    <dl class="org-dl">
    <dt>Реляционные базы данных (RDBMS)</dt><dd>Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.</dd>

    <dt>Нереляционные базы данных (NoSQL)</dt><dd>Нереляционные базы данных предоставляют альтернативный подход к хранению данных и могут использовать различные модели, такие как документы, ключ-значение, столбцы или графы. Они часто применяются в случаях, когда требуется гибкость в структуре данных. Примеры включают MongoDB, Cassandra и Redis.</dd>

    <dt>Графовые базы данных</dt><dd>Графовые базы данных разработаны специально для хранения и обработки данных в виде графов. Они обычно используются для анализа связей и сетей. Примером такой базы данных является Neo4j.</dd>

    <dt>Встраиваемые базы данных</dt><dd>Эти базы данных интегрируются непосредственно в приложения и обычно работают локально. Пример - SQLite, который часто используется в мобильных приложениях.</dd>

    <dt>Ключ-значение хранилища (Key-Value Stores)</dt><dd>Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.</dd>
    </dl></li>

    <li>Что такое <code>DML</code> и <code>DDL</code> операторы?

    <dl class="org-dl">
    <dt>DDL операторы</dt><dd><i>Data Definition Language</i> (язык определения данных) Определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. <code>DDL</code> операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры <code>DDL</code> операторов включают <code>CREATE</code>, <code>ALTER</code>, <code>DROP</code>, <code>TRUNCATE</code> и <code>RENAME</code>. <code>DDL</code> операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых <code>DDL</code> операторов. <code>DDL</code> операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных</dd>
    <dt>DML операторы</dt><dd><i>Data Manipulation Language</i> (язык манипулирования данными) используется для манипулирования данными в базе данных. <code>DML</code> операторы используются для вставки, обновления и удаления данных в базе данных. Примерами <code>DML</code> операторов включают <code>SELECT</code>, <code>INSERT</code>, <code>UPDATE</code>, и <code>DELETE</code>. <code>DML</code> операторы выполняются немедленно и могут быть отменены с помощью оператора отката. <code>DML</code> операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных</dd>
    </dl></li>
    </ul>

    <blockquote>
    <p>
    В целом, <code>DDL</code> используется для определения и управления структурой базы данных, в то время как <code>DML</code> используется для манипулирования данными в базе данных. <code>DDL</code> утверждения являются постоянными и не могут быть отменены, в то время как <code>DML</code> утверждения выполняются немедленно и могут быть отменены. <code>DDL</code> утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют <code>DML</code> утверждения.
    </p>
    </blockquote>
    </div>
    </div>
    </div>
    </body>
    </html>
    Binary file removed rabbit_mq.png
    View file
    Binary file not shown.
    Binary file removed scheme.png
    View file
    Binary file not shown.
    19 changes: 0 additions & 19 deletions вопросы_от_кандидата.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,19 +0,0 @@
    #+title: Вопросы от кандидата

    Во-первых, неплохо узнать побольше о компании, куда рассчитываете попасть. И заодно продемонстрировать свой интерес.

    Не стоит слишком усердствовать и спрашивать абсолютно все. Уточните только важные моменты.
    Вот несколько вариантов:

    * Какие технологии и инструменты используются в конкретном проекте?
    * Как часто сотрудники работают сверхурочно?
    * Сколько существующих пользователей у продукта?
    * Какая модель разработки используется в проекте?
    * Как проходят совещания и кто на них ходит?
    * Тестируете ли/Есть ли у вас мобильные приложения?

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

    Допустим, я привык автоматизировать на Python. Или просто прошел по нему курс. А меня на собеседовании спросили про Selenium и про то, как я будут искать элементы на веб-странице. Ни слова про Python я не смог вставить. Тогда можно спросить, какие фреймворки используются на проекте, сколько кода вообще написано и как долго выполняется прогон тестов. И после ответа рассказать, как вы то же самое делаете на Python, только в два раза быстрее.

    В-третьих, нужно подчеркнуть, что для вас важно понимание следуюших шагов. Спросите, что будет дальше. Возможно, еще одно собеседование с заказчиком или с руководителем отдела? Когда будет ответ, что он из себя представляет. Что будет означать тишина через два-три дня? Ведь не все компании присылают отказы, а просто так ждать вам не хотелось бы. В общем, проговорите следующие шаги и даже сроки. У ваших опонентов будет дополнительный повод быстрее принимать по вам решение и меньше шансов, что они забудут о вас.
  7. pingvi revised this gist Nov 13, 2023. 4 changed files with 613 additions and 219 deletions.
    555 changes: 416 additions & 139 deletions q&a.html
    View file
    Original file line number Diff line number Diff line change
    @@ -3,10 +3,10 @@
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
    <head>
    <!-- 2023-11-12 Вс 11:08 -->
    <!-- 2023-11-12 Вс 17:32 -->
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>IBS Interview</title>
    <title>Вопросы на собеседованиях для QA Engineer</title>
    <meta name="author" content="Maxim Rozhkov" />
    <meta name="generator" content="Org Mode" />
    <style>
    @@ -193,41 +193,66 @@
    { background-color: #ffff00; color: #000000; font-weight: bold; }
    .org-svg { }
    </style>
    <style>*{font-family: Iosevka Comfy !important; font-size: 24px;}</style>
    </head>
    <body>
    <div id="content" class="content">
    <h1 class="title">IBS Interview</h1>
    <h1 class="title">Вопросы на собеседованиях для QA Engineer</h1>
    <div id="table-of-contents" role="doc-toc">
    <h2>Table of Contents</h2>
    <div id="text-table-of-contents" role="doc-toc">
    <ul>
    <li><a href="#orgf7e934f">1. Теория тестирования</a></li>
    <li><a href="#orgc482d46">2. Техники тест-дизайна</a></li>
    <li><a href="#orga8eca3d">3. Тестирование мобильных приложений</a></li>
    <li><a href="#org554215e">4. Тестирование бэкенда</a></li>
    <li><a href="#orgfc62544">5. Клиент-серверное взаимодействие</a>
    <li><a href="#orgb6dfa78">1. Теория тестирования</a></li>
    <li><a href="#org3a286c8">2. Техники тест-дизайна</a></li>
    <li><a href="#org144af5a">3. Тестирование мобильных приложений</a></li>
    <li><a href="#orge0284c2">4. Тестирование бэкенда</a></li>
    <li><a href="#org411badd">5. Клиент-серверное взаимодействие</a>
    <ul>
    <li><a href="#org259e3da">5.1. RabbitMQ</a></li>
    <li><a href="#org3b70000">5.1. RabbitMQ</a></li>
    </ul>
    </li>
    <li><a href="#orgcc1dcc3">6. Базы данных</a></li>
    <li><a href="#org87c72fe">6. Базы данных</a></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orgf7e934f" class="outline-2">
    <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div id="outline-container-orgb6dfa78" class="outline-2">
    <h2 id="orgb6dfa78"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div class="outline-text-2" id="text-1">
    <ul class="org-ul">
    <li><p>
    Что такое тестирование?
    <b>7 принципов тестирования</b>
    </p>

    <p>
    Все 7 принципов тестирования:
    </p>

    <ol class="org-ol">
    <li>Тестирование демонстрирует надичие дефектов, а не их отсутствие</li>

    <li>Исчерпывающее тестирование недостижимо</li>

    <li>Заблуждение об отсутствии ошибок</li>

    <li>Раннее тестирование сохраняет время и деньги</li>

    <li>Принцип скопления или кластеризация дефектов</li>

    <li>Тестирование зависит от контекста</li>

    <li>Парадокс пестицида</li>
    </ol></li>

    <li><p>
    <b>Что такое тестирование?</b>
    </p>

    <p>
    Комплекс мероприятий, направленных на проведение проверок на соответствие продукта требованиям, к нему предъявляемым (прямым или косвенным).
    </p></li>

    <li><p>
    Цель тестирования?
    <b>Цель тестирования?</b>
    </p>

    <p>
    @@ -236,51 +261,41 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес

    <li>Что такое верификация и валидация?

    <ul class="org-ul">
    <li>Верификация - процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям</li>
    <dl class="org-dl">
    <dt>Верификация</dt><dd>Процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям</dd>

    <li>Валидация - процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям пользователя</li>
    </ul></li>
    <dt>Валидация</dt><dd>Процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям пользователя</dd>
    </dl></li>

    <li>Виды тестирования

    <ul class="org-ul">
    <li>Функциональное
    Направлено на тестирование всех функций системы, для подтверждения, что каждая функция программы работает в соответствии с документацией</li>
    <dl class="org-dl">
    <dt>Функциональное</dt><dd>Направлено на тестирование всех функций системы, для подтверждения, что каждая функция программы работает в соответствии с документацией</dd>

    <li>Нефункциональное
    Тестирование свойств, которые не относятся к функциональности системы: производительность, безопасность, локализация, удобство использования, установка/удаление</li>
    <dt>Нефункциональное</dt><dd>Тестирование свойств, которые не относятся к функциональности системы: производительность, безопасность, локализация, удобство использования, установка/удаление</dd>

    <li>Связанное с изменениями
    Тестирование после исправления бага, с целью убедиться что внесенные изменения действительно решили проблему
    <dt>Связанное с изменениями</dt><dd>Тестирование после исправления бага, с целью убедиться что внесенные изменения действительно решили проблему

    <ul class="org-ul">
    <li>Регресионное
    Проверка, что недавное изменение кода или данных сломало другие части разрабатываемого приложения</li>
    <dl class="org-dl">
    <dt>Регресионное</dt><dd>Проверка, что недавное изменение кода или данных сломало другие части разрабатываемого приложения</dd>

    <li>Smoke
    Проверка критически важной функциональности</li>
    <dt>Smoke</dt><dd>Проверка критически важной функциональности</dd>

    <li>Sanity
    Проверка только части приложения</li>
    <dt>Sanity</dt><dd>Проверка только части приложения</dd>

    <li>Re-test
    Повторное тестирование конкретного функционала после исправления бага</li>
    </ul></li>
    </ul></li>
    <dt>Re-test</dt><dd>Повторное тестирование конкретного функционала после исправления бага</dd>
    </dl></dd>
    </dl></li>

    <li>Методы тестирования

    <ul class="org-ul">
    <li>Черный ящик
    Тестирование основано на требованиях, при этом нет знаний о внутреннем устройстве системы, работаем только с внешними интерфейсами тестируемой системы</li>
    <dl class="org-dl">
    <dt>Черный ящик</dt><dd>Тестирование основано на требованиях, при этом нет знаний о внутреннем устройстве системы, работаем только с внешними интерфейсами тестируемой системы</dd>

    <li>Белый ящик
    Тестирование, основанное на анализе внутренней структуры компонента или системы. Есть доступ к коду.</li>
    <dt>Белый ящик</dt><dd>Тестирование, основанное на анализе внутренней структуры компонента или системы. Есть доступ к коду.</dd>

    <li>Серый ящик
    Нет четкого определения. Например нет доступа к коду, БД, но есть доступ к API, с помощью чего можем проверить интеграционные тесты, к примеру с помощью Postman</li>
    </ul></li>
    <dt>Серый ящик</dt><dd>Нет четкого определения. Например нет доступа к коду, БД, но есть доступ к API, с помощью чего можем проверить интеграционные тесты, к примеру с помощью Postman</dd>
    </dl></li>

    <li><p>
    Пирамида тестирования
    @@ -293,24 +308,20 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес
    Unit testing
    </p>

    <ul class="org-ul">
    <li>Unit testing
    Тестируется атомарный модуль программы, чаще всего это функция. Таких тестов должно быть больше всего</li>
    <dl class="org-dl">
    <dt>Unit testing</dt><dd>Тестируется атомарный модуль программы, чаще всего это функция. Таких тестов должно быть больше всего</dd>

    <li>Integration testing
    Тестирование интеграции систем и пакетов программ, тестирование интерфейсов с внешними системами</li>
    <dt>Integration testing</dt><dd>Тестирование интеграции систем и пакетов программ, тестирование интерфейсов с внешними системами</dd>

    <li>System testing
    Тестирование всей системы в целом, выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом</li>
    <dt>System testing</dt><dd>Тестирование всей системы в целом, выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом</dd>

    <li>E2E
    Проверить так ли работает программа для конечного клиента, как рассчитывалось изначально. Самый трудозатратный и дорогой, поэтому находится на вершине пирамиды тестирования.</li>
    </ul></li>
    <dt>E2E</dt><dd>Проверить так ли работает программа для конечного клиента, как рассчитывалось изначально. Самый трудозатратный и дорогой, поэтому находится на вершине пирамиды тестирования.</dd>
    </dl></li>

    <li>Аутентификация и авторизация

    <ul class="org-ul">
    <li>Идентификация - процедура распознавания по его личному идентификатору</li>
    <li>Идентификация - xпроцедура распознавания по его личному идентификатору</li>

    <li>Аутентификация - проверят действительно ли вы это вы</li>

    @@ -359,7 +370,7 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес
    </ul></li>

    <li><p>
    что такое дефект / баг?
    Что такое дефект / баг?
    </p>

    <p>
    @@ -445,7 +456,7 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес
    </table></li>

    <li><p>
    отличия чек-лист и тест-кейс?
    Отличия чек-лист и тест-кейс?
    </p>

    <p>
    @@ -494,7 +505,7 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес
    </ul></li>

    <li><p>
    при каких условиях будешь писать чек-лист, а при каких тест-кейс?
    При каких условиях будешь писать чек-лист, а при каких тест-кейс?
    </p>

    <p>
    @@ -520,19 +531,19 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес

    <li>Универсальность чек-листов сможет покрыть другой функционал? Или это плохая практика?</li>
    </ul></li>
    </ul>

    <li>как ты понимаешь что достаточно тест кейсов и чек листов?

    <ul class="org-ul">
    <li>Когда уже нет новых идей для тестов</li>
    <li><p>
    Закончилось время на тестирование
    Как ты понимаешь что достаточно тест кейсов и чек листов?
    </p>

    <p>
    Чтобы понять, достаточно ли тест-кейсов и чек-листов для проведения тестирования, необходимо учесть несколько факторов:
    </p></li>
    </p>

    <ul class="org-ul">
    <li>Покрытие функциональности: Проверьте, что все основные функциональные требования системы покрываются соответствующими тест-кейсами и чек-листами. Если важные функции не покрыты, это может быть признаком недостаточного количества тестов.</li>

    <li>Покрытие различных сценариев: Убедитесь, что тест-кейсы и чек-листы учитывают различные сценарии использования системы. Рассмотрите разные варианты ввода данных, комбинации функций и возможные пути выполнения операций. Если все сценарии не учтены, может потребоваться больше тестов.</li>
    @@ -550,7 +561,7 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес

    <ul class="org-ul">
    <li><p>
    есть ли опыт разработки тест данных
    Есть ли опыт разработки тест данных
    </p>

    <p>
    @@ -559,11 +570,11 @@ <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тес
    </ul>
    </div>
    </div>
    <div id="outline-container-orgc482d46" class="outline-2">
    <h2 id="orgc482d46"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div id="outline-container-org3a286c8" class="outline-2">
    <h2 id="org3a286c8"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div class="outline-text-2" id="text-2">
    <ul class="org-ul">
    <li>техники тест дизайна какие знаешь?
    <li>Техники тест дизайна какие знаешь?

    <ol class="org-ol">
    <li><p>
    @@ -646,7 +657,7 @@ <h2 id="orgc482d46"><span class="section-number-2">2.</span> Техники те
    </ol></li>

    <li><p>
    эффективность тест-кейсов
    Эффективность тест-кейсов
    </p>

    <p>
    @@ -661,7 +672,7 @@ <h2 id="orgc482d46"><span class="section-number-2">2.</span> Техники те
    <li>Лишние проверки</li>
    </ul></li>

    <li>как можно уменьшить количество тестов?
    <li>Как можно уменьшить количество тестов?

    <ul class="org-ul">
    <li>Объеденить позитивные тесты</li>
    @@ -672,15 +683,15 @@ <h2 id="orgc482d46"><span class="section-number-2">2.</span> Техники те
    </ul></li>

    <li><p>
    составлял ли матрицу покрытия?
    Составлял ли матрицу покрытия?
    </p>

    <p>
    Карта трассируемости это тестирование требований. На проекте не было времени этим заниматься.
    </p></li>

    <li><p>
    когда не надо схлопывать тесты?
    Когда не надо схлопывать тесты?
    </p>

    <p>
    @@ -689,7 +700,7 @@ <h2 id="orgc482d46"><span class="section-number-2">2.</span> Техники те
    </p></li>

    <li><p>
    занимался ли тестированием требований/спецификаций?
    Занимался ли тестированием требований/спецификаций?
    </p>

    <p>
    @@ -698,11 +709,11 @@ <h2 id="orgc482d46"><span class="section-number-2">2.</span> Техники те
    </ul>
    </div>
    </div>
    <div id="outline-container-orga8eca3d" class="outline-2">
    <h2 id="orga8eca3d"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div id="outline-container-org144af5a" class="outline-2">
    <h2 id="org144af5a"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div class="outline-text-2" id="text-3">
    <ul class="org-ul">
    <li>нативные и браузерные приложения в чем отличия?
    <li>Нативные и браузерные приложения в чем отличия?

    <ul class="org-ul">
    <li>Нативные приложения устанавливаются непосредственно на устройство пользователя</li>
    @@ -798,11 +809,11 @@ <h2 id="orga8eca3d"><span class="section-number-2">3.</span> Тестирова
    </ul>
    </div>
    </div>
    <div id="outline-container-org554215e" class="outline-2">
    <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div id="outline-container-orge0284c2" class="outline-2">
    <h2 id="orge0284c2"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div class="outline-text-2" id="text-4">
    <ul class="org-ul">
    <li>знаешь что такое монолитный бекенд?</li>
    <li>Знаешь что такое монолитный бекенд?</li>
    </ul>

    <p>
    @@ -840,14 +851,14 @@ <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирова

    <ul class="org-ul">
    <li><p>
    опыт работы с тест логами есть? какие знаешь?
    Опыт работы с тест логами есть? какие знаешь?
    </p>

    <p>
    <b>Kibana</b> предоставляет визуализацию результатов
    </p></li>

    <li>что можно логировать?
    <li>Что можно логировать?

    <ul class="org-ul">
    <li>вызовы методов, тело, параметры, ответ</li>
    @@ -857,7 +868,7 @@ <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирова
    </ul></li>

    <li><p>
    интеграционное тестирование что знаешь?
    Интеграционное тестирование что знаешь?
    </p>

    <p>
    @@ -887,7 +898,7 @@ <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирова
    </ul></li>

    <li><p>
    какие подходы к тестированию интеграции знаешь? (подход большего взрыва)
    Какие подходы к тестированию интеграции знаешь? (подход большего взрыва)
    </p>

    <p>
    @@ -941,7 +952,7 @@ <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирова
    </ul></li>

    <li><p>
    клиент-серверное взаимодействие как происходит?
    Клиент-серверное взаимодействие как происходит?
    </p>

    <p>
    @@ -969,7 +980,7 @@ <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирова
    </p></li>

    <li><p>
    какая разница между двухзвенной и трехзвенной?
    Какая разница между двухзвенной и трехзвенной?
    </p>

    <p>
    @@ -1056,7 +1067,7 @@ <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирова
    <li>Тонкий клиент может быть более удобным с точки зрения обновлений и поддержки, но может требовать более сильной сетевой инфраструктуры.</li>
    </ul></li>

    <li>какие протоколы знаешь?
    <li>Какие протоколы знаешь?

    <ol class="org-ol">
    <li>HTTP (Hypertext Transfer Protocol) - протокол передачи гипертекста, используемый в веб-браузерах и веб-серверах для обмена данными.</li>
    @@ -1113,63 +1124,160 @@ <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирова

    <li>GET запросы кешируются, POST - нет</li>
    </ul></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orgfc62544" class="outline-2">
    <h2 id="orgfc62544"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div class="outline-text-2" id="text-5">
    <ul class="org-ul">

    <li><p>
    PATCH и PUT отличия?
    <b>Структура HTTP-запроса и ответа</b>
    </p>

    <p>
    HTTP Запрос:
    </p>

    <ol class="org-ol">
    <li>Метод PATCH используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.</li>
    <li><b>Строка запроса (Request Line):</b>

    <li>Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.</li>
    <ul class="org-ul">
    <li>Метод запроса (GET, POST, PUT, DELETE и т.д.).</li>
    <li>URI (Uniform Resource Identifier) - путь к ресурсу.</li>
    <li>Версия HTTP (например, HTTP/1.1).</li>
    </ul></li>
    </ol>

    <p>
    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.
    </p></li>
    Пример:
    <code>GET /index.html HTTP/1.1</code>
    </p>

    <ol class="org-ol">
    <li><p>
    можно ли создать метод делит который будет создавать?
    <b>Заголовки (Headers):</b>
    </p>

    <ul class="org-ul">
    <li>Различные метаданные о запросе, такие как <code>Host</code>, <code>User-Agent</code>, <code>Accept</code>, и т.д.</li>
    </ul>

    <p>
    Можно.
    </p></li>
    Пример:
    </p>

    <div class="org-src-container">
    <pre class="src src-none">Host: www.example.com
    User-Agent: Chrome/91.0.4472.124
    Accept: text/html,application/xhtml+xml,application/xml;
    </pre>
    </div></li>

    <li><b>Тело запроса (Request Body):</b>

    <ul class="org-ul">
    <li><p>
    есть ли опыт работы с девтулс?
    Данные, отправляемые с запросом. Обычно используется для POST и PUT запросов.
    </p>

    <p>
    Есть.
    Пример:
    <code>username=johndoe&amp;password=secret</code>
    </p></li>
    </ul></li>
    </ol>

    <li>какие основные вкладки использовал ?
    <p>
    HTTP Ответ:
    </p>

    <ol class="org-ol">
    <li><p>
    <b>Строка состояния (Status Line):</b>
    </p>

    <ul class="org-ul">
    <li>Elements</li>
    <li>Версия HTTP.</li>
    <li>Код состояния - трехзначный числовой код, обозначающий успешность или ошибку ответа.</li>
    <li>Текстовое описание кода состояния.</li>
    </ul>

    <li>Console</li>
    <p>
    Пример:
    <code>HTTP/1.1 200 OK</code>
    </p></li>

    <li>Sources</li>
    <li><b>Заголовки (Headers):</b>

    <li>Network</li>
    <ul class="org-ul">
    <li><p>
    Метаданные ответа, такие как <code>Content-Type</code>, <code>Content-Length</code>, и т.д.
    </p>

    <p>
    Пример:
    </p>
    <div class="org-src-container">
    <pre class="src src-none">Content-Type: text/html; charset=utf-8
    Content-Length: 1234
    </pre>
    </div></li>
    </ul></li>

    <li>Application (Cookie, Local Storage, Session storage)</li>
    <li><b>Тело ответа (Response Body):</b>

    <li>Performance (детально)</li>
    <ul class="org-ul">
    <li><p>
    Данные, возвращаемые сервером. Например, HTML-страница, изображение и т.д.
    </p>

    <li>Lighthouse (отчет)</li>
    <p>
    Пример (HTML):
    </p>
    <div class="org-src-container">
    <pre class="src src-html">&lt;<span style="color: #5317ac;">!DOCTYPE</span> html&gt;
    &lt;<span style="color: #721045;">html</span>&gt;
    &lt;<span style="color: #721045;">head</span>&gt;
    &lt;<span style="color: #721045;">title</span>&gt;<span style="font-weight: bold; text-decoration: underline;">Example Page</span>&lt;/<span style="color: #721045;">title</span>&gt;
    &lt;/<span style="color: #721045;">head</span>&gt;
    &lt;<span style="color: #721045;">body</span>&gt;
    &lt;<span style="color: #721045;">h1</span>&gt;<span style="font-weight: bold; text-decoration: underline;">Hello, World!</span>&lt;/<span style="color: #721045;">h1</span>&gt;
    &lt;/<span style="color: #721045;">body</span>&gt;
    &lt;/<span style="color: #721045;">html</span>&gt;
    </pre>
    </div></li>
    </ul></li>
    </ol>

    <p>
    Это общая структура. Некоторые запросы и ответы могут не содержать тела, и в некоторых случаях могут использоваться дополнительные параметры, такие как параметры запроса (в строке запроса) или куки (в заголовках).
    </p></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org411badd" class="outline-2">
    <h2 id="org411badd"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div class="outline-text-2" id="text-5">
    <ul class="org-ul">
    <li><p>
    PATCH и PUT отличия?
    </p>

    <ol class="org-ol">
    <li>Метод PATCH используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.</li>

    <li>Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.</li>
    </ol>

    <p>
    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.
    </p></li>

    <li><p>
    Можно ли создать метод делит который будет создавать?
    </p>

    <p>
    Можно обработать запрос по своему усмотрению.
    </p></li>

    <li><p>
    что такое соап?
    Что такое SOAP?
    </p>

    <p>
    @@ -1191,15 +1299,15 @@ <h2 id="orgfc62544"><span class="section-number-2">5.</span> Клиент-сер
    </ul></li>

    <li><p>
    как бы вы решили какой из REST или SOAP веб сервисов использовать?
    Как бы вы решили какой из REST или SOAP веб сервисов использовать?
    </p>

    <p>
    REST против SOAP можно перефразировать как &ldquo;Простота против Стандарта&rdquo;. В случае REST (простота) у вас будет скорость, расширяемость и поддержка многих форматов. В случае с SOAP у вас будет больше возможностей по безопасности (WS-security) и транзакционная безопасность (ACID).
    </p></li>

    <li><p>
    что такое WSDL?
    Что такое WSDL?
    </p>

    <p>
    @@ -1220,7 +1328,7 @@ <h2 id="orgfc62544"><span class="section-number-2">5.</span> Клиент-сер
    <li>связывание сервисов (binding) - способ, которым сообщение будет доставлено</li>
    </ul></li>

    <li>в чем отличия REST и SOAP?
    <li>В чем отличия REST и SOAP?

    <ul class="org-ul">
    <li>REST поддерживает различные форматы: text, JSON, XML, HTML, YAML;
    @@ -1237,7 +1345,7 @@ <h2 id="orgfc62544"><span class="section-number-2">5.</span> Клиент-сер
    <li>SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но не один из ACID не совместим с двух фазовым коммитом.</li>
    </ul></li>

    <li>на коленке сделать примитивный джейсон</li>
    <li>На коленке сделать примитивный JSON</li>
    </ul>

    <div class="org-src-container">
    @@ -1272,10 +1380,190 @@ <h2 id="orgfc62544"><span class="section-number-2">5.</span> Клиент-сер
    <p>
    Идемпотентными методами являются: GET, PUT, DELETE, HEAD и OPTIONS. POST и PATCH не входят в эту группу.
    </p></li>

    <li><p>
    Статусы HTTP
    </p>

    <p>
    Статусы HTTP (HTTP status codes) - это числовые коды, возвращаемые сервером в ответ на запрос клиента к веб-ресурсу. Они предоставляют информацию о результате выполнения запроса. Каждый статус состоит из трех цифр и имеет свое определенное значение.
    </p>

    <ul class="org-ul">
    <li><p>
    Информационные (Informational - 1xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>100 Continue</b></td>
    <td class="org-left">Запрос был успешно принят, и клиент может продолжать выполнение запроса</td>
    </tr>

    <tr>
    <td class="org-left"><b>101 Switching Protocols</b></td>
    <td class="org-left">Сервер согласен на изменение протоколов по запросу клиента</td>
    </tr>

    <tr>
    <td class="org-left"><b>102 Processing</b></td>
    <td class="org-left">Сервер получил запрос и продолжает процессирование (WebDAV)</td>
    </tr>

    <tr>
    <td class="org-left"><b>103 Early Hints</b></td>
    <td class="org-left">Этот статус сообщает клиенту, что сервер намеревается отправить часть ответа, которая может быть использована клиентом для начала предварительного отображения до завершения всего ответа</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Успех (Successful - 2xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>200 OK</b></td>
    <td class="org-left">Запрос успешно выполнен</td>
    </tr>

    <tr>
    <td class="org-left"><b>201 Created</b></td>
    <td class="org-left">Запрос успешно выполнен, и создан новый ресурс</td>
    </tr>

    <tr>
    <td class="org-left"><b>204 No Content</b></td>
    <td class="org-left">Запрос успешно выполнен, но ответ не содержит представления (например, при удалении ресурса)</td>
    </tr>

    <tr>
    <td class="org-left"><b>207 Multi-Status</b></td>
    <td class="org-left">Обработка завершена, но вернулось несколько статусов (WebDAV)</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Перенаправление (Redirection - 3xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>301 Moved Permanently</b></td>
    <td class="org-left">Ресурс перемещен по новому URI, клиент должен использовать новый URI при следующих запросах.</td>
    </tr>

    <tr>
    <td class="org-left"><b>302 Found</b></td>
    <td class="org-left">Ресурс временно перемещен. Клиент должен использовать новый URI, но старый URI также может быть использован временно</td>
    </tr>

    <tr>
    <td class="org-left"><b>304 Not Modified</b></td>
    <td class="org-left">Ресурс не был изменен с момента последнего запроса клиента. Клиент может использовать свою копию ресурса</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Ошибки клиента (Client Error - 4xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>400 Bad Request</b></td>
    <td class="org-left">Некорректный запрос от клиента</td>
    </tr>

    <tr>
    <td class="org-left"><b>401 Unauthorized</b></td>
    <td class="org-left">Требуется аутентификация для доступа к ресурсу</td>
    </tr>

    <tr>
    <td class="org-left"><b>403 Forbidden</b></td>
    <td class="org-left">Клиент не имеет прав доступа к ресурсу</td>
    </tr>

    <tr>
    <td class="org-left"><b>404 Not Found</b></td>
    <td class="org-left">Запрашиваемый ресурс не найден</td>
    </tr>

    <tr>
    <td class="org-left"><b>404 Method Not Allowed</b></td>
    <td class="org-left">Этот статус часто возвращается, когда клиент пытается выполнить запрос с использованием метода HTTP, который не разрешен для данного URL</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    Ошибки сервера (Server Error - 5xx):
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left"><b>500 Internal Server Error</b></td>
    <td class="org-left">Общая ошибка сервера</td>
    </tr>

    <tr>
    <td class="org-left"><b>501 Not Implemented</b></td>
    <td class="org-left">Функционал, необходимый для выполнения запроса, не поддерживается сервером</td>
    </tr>

    <tr>
    <td class="org-left"><b>503 Service Unavailable</b></td>
    <td class="org-left">Сервер временно не может обрабатывать запросы (например, из-за перегрузки или обслуживания)</td>
    </tr>
    </tbody>
    </table></li>
    </ul></li>
    </ul>
    </div>
    <div id="outline-container-org259e3da" class="outline-3">
    <h3 id="org259e3da"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    <div id="outline-container-org3b70000" class="outline-3">
    <h3 id="org3b70000"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    <div class="outline-text-3" id="text-5-1">
    <ul class="org-ul">
    <li><p>
    @@ -1286,11 +1574,14 @@ <h3 id="org259e3da"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    <p>
    RabbitMQ это брокер сообщений, если в двух словах то служит для передачи данных между микросервисами
    </p>
    </blockquote>
    </blockquote></li>
    </ul>

    <p>
    Producer  Message  Exchange  Queue  Consumer

    <div id="org86d0df8" class="figure">
    <p><img src="scheme.png" alt="scheme.png" />
    </p>
    </div>

    <blockquote>
    <p>
    @@ -1306,23 +1597,13 @@ <h3 id="org259e3da"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    Так же как и в <b>Kafka</b>, но отличие состоит в обработке сообщений. Отличие состоит в наличии Exchange (обменник). Сообщение сначала попадает в обменник и дальше на основании ключей попадает в очередь.
    </p>

    <p>
    Producer<sub>1</sub> 󰁃 Queue<sub>1</sub> 󰁔 Consumer<sub>1</sub>
    </p>

    <p>
    󰁜
    <div id="org38bf0de" class="figure">
    <p><img src="rabbit_mq.png" alt="rabbit_mq.png" />
    </p>
    </div>

    <p>
    Producer<sub>2</sub> 󰁔 Exchange 󰁔 Queue<sub>2</sub> 󰁔 Consumer<sub>2</sub>
    </p>

    <p>
    󰁃
    Producer<sub>3</sub> 󰁜 Queue<sub>3</sub> 󰁔 Consumer<sub>3</sub>
    </p></li>

    <ul class="org-ul">
    <li><p>
    Что такое протокол AMQP?
    </p>
    @@ -1432,8 +1713,8 @@ <h3 id="org259e3da"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    </div>
    </div>
    </div>
    <div id="outline-container-orgcc1dcc3" class="outline-2">
    <h2 id="orgcc1dcc3"><span class="section-number-2">6.</span> Базы данных</h2>
    <div id="outline-container-org87c72fe" class="outline-2">
    <h2 id="org87c72fe"><span class="section-number-2">6.</span> Базы данных</h2>
    <div class="outline-text-2" id="text-6">
    <ul class="org-ul">
    <li>Какие виды БД?
    @@ -1466,9 +1747,5 @@ <h2 id="orgcc1dcc3"><span class="section-number-2">6.</span> Базы данны
    </div>
    </div>
    </div>
    <div id="postamble" class="status">
    <p class="author">Author: Maxim Rozhkov</p>
    <p class="date">Created: 2023-11-12 Вс 11:08</p>
    </div>
    </body>
    </html>
    277 changes: 197 additions & 80 deletions q&a.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,53 +1,71 @@
    #+title: IBS Interview
    #+TITLE: Вопросы на собеседованиях для QA Engineer

    ** Теория тестирования

    + Что такое тестирование?
    + *7 принципов тестирования*

    Все 7 принципов тестирования:

    1. Тестирование демонстрирует надичие дефектов, а не их отсутствие

    2. Исчерпывающее тестирование недостижимо

    3. Заблуждение об отсутствии ошибок

    4. Раннее тестирование сохраняет время и деньги

    5. Принцип скопления или кластеризация дефектов

    6. Тестирование зависит от контекста

    7. Парадокс пестицида

    + *Что такое тестирование?*

    Комплекс мероприятий, направленных на проведение проверок на соответствие продукта требованиям, к нему предъявляемым (прямым или косвенным).

    + Цель тестирования?
    + *Цель тестирования?*

    Донесение релевантной информации о продукте команде для принятия верных решений.

    + Что такое верификация и валидация?

    * Верификация - процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям
    * Верификация :: Процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям

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

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

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

    * Нефункциональное
    * Нефункциональное ::
    Тестирование свойств, которые не относятся к функциональности системы: производительность, безопасность, локализация, удобство использования, установка/удаление

    * Связанное с изменениями
    * Связанное с изменениями ::
    Тестирование после исправления бага, с целью убедиться что внесенные изменения действительно решили проблему

    - Регресионное
    - Регресионное ::
    Проверка, что недавное изменение кода или данных сломало другие части разрабатываемого приложения

    - Smoke
    - Smoke ::
    Проверка критически важной функциональности

    - Sanity
    - Sanity ::
    Проверка только части приложения

    - Re-test
    - Re-test ::
    Повторное тестирование конкретного функционала после исправления бага

    + Методы тестирования

    * Черный ящик
    * Черный ящик ::
    Тестирование основано на требованиях, при этом нет знаний о внутреннем устройстве системы, работаем только с внешними интерфейсами тестируемой системы

    * Белый ящик
    * Белый ящик ::
    Тестирование, основанное на анализе внутренней структуры компонента или системы. Есть доступ к коду.

    * Серый ящик
    * Серый ящик ::
    Нет четкого определения. Например нет доступа к коду, БД, но есть доступ к API, с помощью чего можем проверить интеграционные тесты, к примеру с помощью Postman

    + Пирамида тестирования
    @@ -57,21 +75,21 @@
    Integration testing
    Unit testing

    * Unit testing
    * Unit testing ::
    Тестируется атомарный модуль программы, чаще всего это функция. Таких тестов должно быть больше всего

    * Integration testing
    * Integration testing ::
    Тестирование интеграции систем и пакетов программ, тестирование интерфейсов с внешними системами

    * System testing
    * System testing ::
    Тестирование всей системы в целом, выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом

    * E2E
    * E2E ::
    Проверить так ли работает программа для конечного клиента, как рассчитывалось изначально. Самый трудозатратный и дорогой, поэтому находится на вершине пирамиды тестирования.

    + Аутентификация и авторизация

    * Идентификация - процедура распознавания по его личному идентификатору
    * Идентификация - xпроцедура распознавания по его личному идентификатору

    * Аутентификация - проверят действительно ли вы это вы

    @@ -108,7 +126,7 @@
    5. Тестирование (ре-тест)
    6. Закрытие (При устранении бага, баг закрывается, либо отправляется на доработку)

    + что такое дефект / баг?
    + Что такое дефект / баг?

    Дефект — это отклонение от исходной потребности в выводе, тогда как ошибка — это ошибка программирования.

    @@ -134,7 +152,7 @@
    | Причины возникновения | Отсутствующий код, неправильное кодирование или дополнительное кодирование. | Кодовая или логическая ошибка и неправильный ввод. |
    | Предотвращени | Мы используем фундаментальные и точные подходы к разработке программного обеспечения. | Использование фундаментальных и точных подходов к разработке программного обеспечения. |

    + отличия чек-лист и тест-кейс?
    + Отличия чек-лист и тест-кейс?

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

    @@ -163,15 +181,15 @@
    - Цель чек-листа – не пропустить ни одной важной детали в процессе тестирования.
    - Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.

    + при каких условиях будешь писать чек-лист, а при каких тест-кейс?
    + При каких условиях будешь писать чек-лист, а при каких тест-кейс?

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

    #+BEGIN_QUOTE
    #+BEGIN_QUOTE
    Как утверждает Алексей Баранцев "... простейший чек-лист -- это список тест-кейсов." Я с ним согласен. Т.е. чек-лист лишь перечисление тестовых прецедентов, которые могут быть описаны, а могут и не быть. Так вот... тестовые прецеденты должны постоянно поддерживаться в актуальном состоянии. А поскольку тестовые прецеденты более детальны, чем чек-листы, то и на их поддержание требуется больше ресурсов.

    Поэтому мое мнение таково: если хватает ресурсов, то можно иметь описание тестовых прецедентов, если нет - нужно обходиться чек-листами. Они, по крайней мере, позволят систематизировать тестирование. Я в фирме ввел как правило "имение как минимум чек-листов".
    #+END_QUOTE
    #+END_QUOTE

    - Насколько сотрудники вовлечены чтобы понять тест-кейсы?

    @@ -181,10 +199,8 @@

    - Универсальность чек-листов сможет покрыть другой функционал? Или это плохая практика?

    + как ты понимаешь что достаточно тест кейсов и чек листов?

    * Когда уже нет новых идей для тестов
    * Закончилось время на тестирование
    + Как ты понимаешь что достаточно тест кейсов и чек листов?

    Чтобы понять, достаточно ли тест-кейсов и чек-листов для проведения тестирования, необходимо учесть несколько факторов:

    @@ -199,13 +215,13 @@
    В конечном итоге, достаточность тест-кейсов и чек-листов - это субъективное мнение, основанное на конкретных требованиях, характеристиках и ограничениях проекта. Важно найти баланс между достаточностью тестов и доступными ресурсами.


    + есть ли опыт разработки тест данных
    + Есть ли опыт разработки тест данных

    Для больших объемов нет.

    ** Техники тест-дизайна

    + техники тест дизайна какие знаешь?
    + Техники тест дизайна какие знаешь?

    1. Классы эквивалентности

    @@ -215,7 +231,7 @@

    Граница (или граничное значение) - это место где меняется поведение системы.

    1. Предугадывание ошибок
    3. Предугадывание ошибок

    Это техника создания гипотез о местах системы на основании документации и знаний о системе.
    Обычно с ее помощью создаются негативные кейсы.
    @@ -228,14 +244,14 @@
    * По документации
    * По статистике (багов, тестов, использования)

    2. Причина-следствие
    4. Причина-следствие

    3. Pairwise Testing
    5. Pairwise Testing

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

    4. Исследовательское тестирование и туры Виттакера
    6. Исследовательское тестирование и туры Виттакера

    Это неформальный метод, при котором тесты проектируются во время их исполнения.
    Мы представляем все приложение как город.
    @@ -247,13 +263,13 @@
    * Для разнообразия тестирования
    * Нужно обнаружить и локализовать дефект

    5. Таблица принятия решений
    7. Таблица принятия решений

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

    + эффективность тест-кейсов
    + Эффективность тест-кейсов

    Когда переписываешь тест кейсы 10 раз в месяц

    @@ -263,30 +279,30 @@
    * Дополнительные материалы
    * Лишние проверки

    + как можно уменьшить количество тестов?
    + Как можно уменьшить количество тестов?

    * Объеденить позитивные тесты

    * Выкинуть дубли

    * Проверить функциональность 1 раз, а не 10.

    + составлял ли матрицу покрытия?
    + Составлял ли матрицу покрытия?

    Карта трассируемости это тестирование требований. На проекте не было времени этим заниматься.

    + когда не надо схлопывать тесты?
    + Когда не надо схлопывать тесты?

    Когда итоговый тест получается слишком сложным для восприятия.
    Или когла смешиваем разные функциональности

    + занимался ли тестированием требований/спецификаций?
    + Занимался ли тестированием требований/спецификаций?

    Нет.

    ** Тестирование мобильных приложений

    + нативные и браузерные приложения в чем отличия?
    + Нативные и браузерные приложения в чем отличия?

    * Нативные приложения устанавливаются непосредственно на устройство пользователя

    @@ -356,7 +372,7 @@

    ** Тестирование бэкенда

    + знаешь что такое монолитный бекенд?
    + Знаешь что такое монолитный бекенд?

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

    @@ -377,18 +393,18 @@
    - в ней работают все операторы банка, осуществляют звонки, обмен сообщениями в чате и тд и тп.
    Если мы «выключим» монолит, мы выключим весь его функционал целиком.

    + опыт работы с тест логами есть? какие знаешь?
    + Опыт работы с тест логами есть? какие знаешь?

    *Kibana* предоставляет визуализацию результатов

    + что можно логировать?
    + Что можно логировать?

    * вызовы методов, тело, параметры, ответ
    * ошибки пользовательские и серверные
    * запросы в БД
    * служебная и вспомогательная информация об изменениях в системе

    + интеграционное тестирование что знаешь?
    + Интеграционное тестирование что знаешь?

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

    @@ -402,7 +418,7 @@

    Проверяется взаимодействие между разными системами после проведения системного тестирования.

    + какие подходы к тестированию интеграции знаешь? (подход большего взрыва)
    + Какие подходы к тестированию интеграции знаешь? (подход большего взрыва)

    Подходы к интеграционному тестированию:

    @@ -432,7 +448,7 @@

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

    + клиент-серверное взаимодействие как происходит?
    + Клиент-серверное взаимодействие как происходит?

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

    @@ -450,7 +466,7 @@

    Важно отметить, что клиент и сервер могут взаимодействовать по различным протоколам, таким как HTTP, FTP, SMTP и т.д. Каждый протокол определяет свои правила и формат обмена данными.

    + какая разница между двухзвенной и трехзвенной?
    + Какая разница между двухзвенной и трехзвенной?

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

    @@ -504,7 +520,7 @@

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

    + какие протоколы знаешь?
    + Какие протоколы знаешь?

    1. HTTP (Hypertext Transfer Protocol) - протокол передачи гипертекста, используемый в веб-браузерах и веб-серверах для обмена данными.

    @@ -548,41 +564,93 @@

    - GET запросы кешируются, POST - нет

    ** Клиент-серверное взаимодействие
    + *Структура HTTP-запроса и ответа*

    + PATCH и PUT отличия?
    HTTP Запрос:

    1. Метод PATCH используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.
    1. *Строка запроса (Request Line):*

    2. Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.
    - Метод запроса (GET, POST, PUT, DELETE и т.д.).
    - URI (Uniform Resource Identifier) - путь к ресурсу.
    - Версия HTTP (например, HTTP/1.1).

    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.
    Пример:
    ~GET /index.html HTTP/1.1~

    2. *Заголовки (Headers):*

    - Различные метаданные о запросе, такие как ~Host~, ~User-Agent~, ~Accept~, и т.д.

    Пример:

    #+BEGIN_SRC none
    Host: www.example.com
    User-Agent: Chrome/91.0.4472.124
    Accept: text/html,application/xhtml+xml,application/xml;
    #+END_SRC

    3. *Тело запроса (Request Body):*

    + можно ли создать метод делит который будет создавать?
    - Данные, отправляемые с запросом. Обычно используется для POST и PUT запросов.

    Можно.
    Пример:
    ~username=johndoe&password=secret~

    + есть ли опыт работы с девтулс?
    HTTP Ответ:

    Есть.
    1. *Строка состояния (Status Line):*

    + какие основные вкладки использовал ?
    - Версия HTTP.
    - Код состояния - трехзначный числовой код, обозначающий успешность или ошибку ответа.
    - Текстовое описание кода состояния.

    - Elements
    Пример:
    ~HTTP/1.1 200 OK~

    - Console
    2. *Заголовки (Headers):*

    - Sources
    - Метаданные ответа, такие как ~Content-Type~, ~Content-Length~, и т.д.

    - Network
    Пример:
    #+BEGIN_SRC none
    Content-Type: text/html; charset=utf-8
    Content-Length: 1234
    #+END_SRC

    - Application (Cookie, Local Storage, Session storage)
    3. *Тело ответа (Response Body):*

    - Performance (детально)
    - Данные, возвращаемые сервером. Например, HTML-страница, изображение и т.д.

    - Lighthouse (отчет)
    Пример (HTML):
    #+BEGIN_SRC html
    <!DOCTYPE html>
    <html>
    <head>
    <title>Example Page</title>
    </head>
    <body>
    <h1>Hello, World!</h1>
    </body>
    </html>
    #+END_SRC

    + что такое соап?
    Это общая структура. Некоторые запросы и ответы могут не содержать тела, и в некоторых случаях могут использоваться дополнительные параметры, такие как параметры запроса (в строке запроса) или куки (в заголовках).

    ** Клиент-серверное взаимодействие

    + PATCH и PUT отличия?

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

    2. Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.

    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.

    + Можно ли создать метод делит который будет создавать?

    Можно обработать запрос по своему усмотрению.

    + Что такое SOAP?

    SOAP – протокол обмена структурированными сообщениями.

    @@ -598,11 +666,11 @@

    * SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, SMTP, TCP.

    + как бы вы решили какой из REST или SOAP веб сервисов использовать?
    + Как бы вы решили какой из REST или SOAP веб сервисов использовать?

    REST против SOAP можно перефразировать как "Простота против Стандарта". В случае REST (простота) у вас будет скорость, расширяемость и поддержка многих форматов. В случае с SOAP у вас будет больше возможностей по безопасности (WS-security) и транзакционная безопасность (ACID).

    + что такое WSDL?
    + Что такое WSDL?

    WSDL (англ. Web Services Description Language) - язык описания веб-сервисов и доступа к ним, основанный на языке XML.

    @@ -616,7 +684,7 @@

    * связывание сервисов (binding) - способ, которым сообщение будет доставлено

    + в чем отличия REST и SOAP?
    + В чем отличия REST и SOAP?

    - REST поддерживает различные форматы: text, JSON, XML, HTML, YAML;
    SOAP - только XML
    @@ -631,7 +699,7 @@

    - SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но не один из ACID не совместим с двух фазовым коммитом.

    + на коленке сделать примитивный джейсон
    + На коленке сделать примитивный JSON

    #+BEGIN_SRC json
    {
    @@ -656,6 +724,44 @@

    Идемпотентными методами являются: GET, PUT, DELETE, HEAD и OPTIONS. POST и PATCH не входят в эту группу.

    + Статусы HTTP

    Статусы HTTP (HTTP status codes) - это числовые коды, возвращаемые сервером в ответ на запрос клиента к веб-ресурсу. Они предоставляют информацию о результате выполнения запроса. Каждый статус состоит из трех цифр и имеет свое определенное значение.

    - Информационные (Informational - 1xx):

    | *100 Continue* | Запрос был успешно принят, и клиент может продолжать выполнение запроса |
    | *101 Switching Protocols* | Сервер согласен на изменение протоколов по запросу клиента |
    | *102 Processing* | Сервер получил запрос и продолжает процессирование (WebDAV) |
    | *103 Early Hints* | Этот статус сообщает клиенту, что сервер намеревается отправить часть ответа, которая может быть использована клиентом для начала предварительного отображения до завершения всего ответа |

    - Успех (Successful - 2xx):

    | *200 OK* | Запрос успешно выполнен |
    | *201 Created* | Запрос успешно выполнен, и создан новый ресурс |
    | *204 No Content* | Запрос успешно выполнен, но ответ не содержит представления (например, при удалении ресурса) |
    | *207 Multi-Status* | Обработка завершена, но вернулось несколько статусов (WebDAV) |

    - Перенаправление (Redirection - 3xx):

    | *301 Moved Permanently* | Ресурс перемещен по новому URI, клиент должен использовать новый URI при следующих запросах. |
    | *302 Found* | Ресурс временно перемещен. Клиент должен использовать новый URI, но старый URI также может быть использован временно |
    | *304 Not Modified* | Ресурс не был изменен с момента последнего запроса клиента. Клиент может использовать свою копию ресурса |

    - Ошибки клиента (Client Error - 4xx):

    | *400 Bad Request* | Некорректный запрос от клиента |
    | *401 Unauthorized* | Требуется аутентификация для доступа к ресурсу |
    | *403 Forbidden* | Клиент не имеет прав доступа к ресурсу |
    | *404 Not Found* | Запрашиваемый ресурс не найден |
    | *404 Method Not Allowed* | Этот статус часто возвращается, когда клиент пытается выполнить запрос с использованием метода HTTP, который не разрешен для данного URL |

    - Ошибки сервера (Server Error - 5xx):

    | *500 Internal Server Error* | Общая ошибка сервера |
    | *501 Not Implemented* | Функционал, необходимый для выполнения запроса, не поддерживается сервером |
    | *503 Service Unavailable* | Сервер временно не может обрабатывать запросы (например, из-за перегрузки или обслуживания) |

    *** RabbitMQ

    + Что такое RabbitMQ?
    @@ -664,7 +770,11 @@
    RabbitMQ это брокер сообщений, если в двух словах то служит для передачи данных между микросервисами
    #+end_quote

    Producer  Message  Exchange  Queue  Consumer
    #+BEGIN_SRC ditaa :file scheme.png
    /----------\ /---------\ /----------\ /-------\ /----------\
    | Producer |---| Message |--->| Exchange |--->| Queue |--->| Consumer |
    \----------/ \---------/ \----------/ \-------/ \----------/
    #+END_SRC

    #+begin_quote
    Производитель (producer) – это компонент (приложение, сервис или другая часть системы), который создает и отправляет сообщения в RabbitMQ.
    @@ -674,14 +784,21 @@

    Так же как и в *Kafka*, но отличие состоит в обработке сообщений. Отличие состоит в наличии Exchange (обменник). Сообщение сначала попадает в обменник и дальше на основании ключей попадает в очередь.

    Producer_1 󰁃 Queue_1 󰁔 Consumer_1

    󰁜

    Producer_2 󰁔 Exchange 󰁔 Queue_2 󰁔 Consumer_2

    󰁃
    Producer_3 󰁜 Queue_3 󰁔 Consumer_3
    #+BEGIN_SRC ditaa :file rabbit_mq.png
    /------------\ /---------\ /------------\
    | Producer_1 | | Queue_1 |----------->| Consumer_1 |
    \------------/ \---------/ \------------/
    | |
    +------------->/----------\------------+
    /------------\ | cBLU | /---------\ /------------\
    | Producer_2 |------>| Exchange |------>| Queue_2 |----------->| Consumer_2 |
    \------------/ | | \---------/ \------------/
    +------------->\----------/------------+
    | |
    /------------\ /---------\ /------------\
    | Producer_3 | | Queue_3 |----------->| Consumer_3 |
    \------------/ \---------/ \------------/
    #+END_SRC

    + Что такое протокол AMQP?

    Binary file added rabbit_mq.png
    View file
    Loading
    Sorry, something went wrong. Reload?
    Sorry, we cannot display this file.
    Sorry, this file is invalid so it cannot be displayed.
    Binary file added scheme.png
    View file
    Loading
    Sorry, something went wrong. Reload?
    Sorry, we cannot display this file.
    Sorry, this file is invalid so it cannot be displayed.
  8. abcwalk revised this gist Nov 12, 2023. 3 changed files with 122 additions and 164 deletions.
    2 changes: 2 additions & 0 deletions .gitignore
    View file
    Original file line number Diff line number Diff line change
    @@ -4,3 +4,5 @@
    tmp/

    *.html
    *.md
    *.tmp
    141 changes: 56 additions & 85 deletions q&a.html
    View file
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
    <head>
    <!-- 2023-11-11 Сб 18:30 -->
    <!-- 2023-11-12 Вс 11:08 -->
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>IBS Interview</title>
    @@ -201,21 +201,21 @@ <h1 class="title">IBS Interview</h1>
    <h2>Table of Contents</h2>
    <div id="text-table-of-contents" role="doc-toc">
    <ul>
    <li><a href="#org2a2f7b5">1. Теория тестирования</a></li>
    <li><a href="#orgc8660d0">2. Техники тест-дизайна</a></li>
    <li><a href="#orgcaa43d2">3. Тестирование мобильных приложений</a></li>
    <li><a href="#orgc84c707">4. Тестирование бэкенда</a></li>
    <li><a href="#orgce2241b">5. Клиент-серверное взаимодействие</a>
    <li><a href="#orgf7e934f">1. Теория тестирования</a></li>
    <li><a href="#orgc482d46">2. Техники тест-дизайна</a></li>
    <li><a href="#orga8eca3d">3. Тестирование мобильных приложений</a></li>
    <li><a href="#org554215e">4. Тестирование бэкенда</a></li>
    <li><a href="#orgfc62544">5. Клиент-серверное взаимодействие</a>
    <ul>
    <li><a href="#org2c30c87">5.1. RabbitMQ</a></li>
    <li><a href="#org259e3da">5.1. RabbitMQ</a></li>
    </ul>
    </li>
    <li><a href="#org30a477f">6. Базы данных</a></li>
    <li><a href="#orgcc1dcc3">6. Базы данных</a></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org2a2f7b5" class="outline-2">
    <h2 id="org2a2f7b5"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div id="outline-container-orgf7e934f" class="outline-2">
    <h2 id="orgf7e934f"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div class="outline-text-2" id="text-1">
    <ul class="org-ul">
    <li><p>
    @@ -559,8 +559,8 @@ <h2 id="org2a2f7b5"><span class="section-number-2">1.</span> Теория тес
    </ul>
    </div>
    </div>
    <div id="outline-container-orgc8660d0" class="outline-2">
    <h2 id="orgc8660d0"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div id="outline-container-orgc482d46" class="outline-2">
    <h2 id="orgc482d46"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div class="outline-text-2" id="text-2">
    <ul class="org-ul">
    <li>техники тест дизайна какие знаешь?
    @@ -698,8 +698,8 @@ <h2 id="orgc8660d0"><span class="section-number-2">2.</span> Техники те
    </ul>
    </div>
    </div>
    <div id="outline-container-orgcaa43d2" class="outline-2">
    <h2 id="orgcaa43d2"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div id="outline-container-orga8eca3d" class="outline-2">
    <h2 id="orga8eca3d"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div class="outline-text-2" id="text-3">
    <ul class="org-ul">
    <li>нативные и браузерные приложения в чем отличия?
    @@ -798,8 +798,8 @@ <h2 id="orgcaa43d2"><span class="section-number-2">3.</span> Тестирова
    </ul>
    </div>
    </div>
    <div id="outline-container-orgc84c707" class="outline-2">
    <h2 id="orgc84c707"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div id="outline-container-org554215e" class="outline-2">
    <h2 id="org554215e"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div class="outline-text-2" id="text-4">
    <ul class="org-ul">
    <li>знаешь что такое монолитный бекенд?</li>
    @@ -923,7 +923,7 @@ <h2 id="orgc84c707"><span class="section-number-2">4.</span> Тестирова
    Основные характеристики метода &ldquo;Большой взрыв&rdquo;:
    </p>

    <ol class="org-ol">
    <ul class="org-ul">
    <li><b>Интеграция в конце</b>: Интеграция всех компонентов происходит ближе к концу разработки проекта. Весь код, разработанный различными командами или индивидуальными разработчиками, собирается и интегрируется вместе.</li>

    <li><b>Одновременная интеграция</b>: Все компоненты или модули интегрируются одновременно. Это может создать ситуацию, когда множество изменений вводится в систему одновременно, что может сделать процесс выявления и устранения возможных конфликтов более сложным.</li>
    @@ -933,7 +933,7 @@ <h2 id="orgc84c707"><span class="section-number-2">4.</span> Тестирова
    <li><b>Больший риск конфликтов</b>: Поскольку интеграция происходит в конце разработки, есть риск обнаружения серьезных конфликтов и ошибок, которые могли бы быть выявлены и устранены на более ранних этапах.</li>

    <li><b>Менее предсказуемый процесс</b>: Такой метод интеграции может создать более сложный и менее предсказуемый процесс разработки, особенно если существуют неучтенные зависимости или непредвиденные проблемы.</li>
    </ol>
    </ul>

    <p>
    &ldquo;Большой взрыв&rdquo; может быть эффективен для небольших проектов или в ситуациях, где особенности проекта не позволяют использовать более инкрементальные методы интеграции. Однако, такой подход требует внимательного планирования и управления рисками, чтобы успешно интегрировать и протестировать систему.
    @@ -993,7 +993,7 @@ <h2 id="orgc84c707"><span class="section-number-2">4.</span> Тестирова
    </ol></li>

    <li><p>
    разница между толстым и тонким клиентом?
    Разница между толстым и тонким клиентом?
    </p>

    <ol class="org-ol">
    @@ -1116,18 +1116,18 @@ <h2 id="orgc84c707"><span class="section-number-2">4.</span> Тестирова
    </ul>
    </div>
    </div>
    <div id="outline-container-orgce2241b" class="outline-2">
    <h2 id="orgce2241b"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div id="outline-container-orgfc62544" class="outline-2">
    <h2 id="orgfc62544"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div class="outline-text-2" id="text-5">
    <ul class="org-ul">
    <li><p>
    патч и пут отличия?
    PATCH и PUT отличия?
    </p>

    <ol class="org-ol">
    <li>Метод PATCH (патч) используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.</li>
    <li>Метод PATCH используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.</li>

    <li>Метод PUT (пут) используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.</li>
    <li>Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.</li>
    </ol>

    <p>
    @@ -1257,14 +1257,6 @@ <h2 id="orgce2241b"><span class="section-number-2">5.</span> Клиент-сер
    </div>

    <ul class="org-ul">
    <li><p>
    работал со сваггерами?
    </p>

    <p>
    Работал.
    </p></li>

    <li><p>
    Идемпотентность
    </p>
    @@ -1282,8 +1274,8 @@ <h2 id="orgce2241b"><span class="section-number-2">5.</span> Клиент-сер
    </p></li>
    </ul>
    </div>
    <div id="outline-container-org2c30c87" class="outline-3">
    <h3 id="org2c30c87"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    <div id="outline-container-org259e3da" class="outline-3">
    <h3 id="org259e3da"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    <div class="outline-text-3" id="text-5-1">
    <ul class="org-ul">
    <li><p>
    @@ -1316,8 +1308,17 @@ <h3 id="org2c30c87"><span class="section-number-3">5.1.</span> RabbitMQ</h3>

    <p>
    Producer<sub>1</sub> 󰁃 Queue<sub>1</sub> 󰁔 Consumer<sub>1</sub>
    󰁜
    </p>

    <p>
    󰁜
    </p>

    <p>
    Producer<sub>2</sub> 󰁔 Exchange 󰁔 Queue<sub>2</sub> 󰁔 Consumer<sub>2</sub>
    </p>

    <p>
    󰁃
    Producer<sub>3</sub> 󰁜 Queue<sub>3</sub> 󰁔 Consumer<sub>3</sub>
    </p></li>
    @@ -1419,7 +1420,7 @@ <h3 id="org2c30c87"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    </table></li>

    <li><p>
    *Почему мы привязали один обменник, а по факту отображается два?
    Почему мы привязали один обменник, а по факту отображается два?
    </p>

    <p>
    @@ -1431,73 +1432,43 @@ <h3 id="org2c30c87"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    </div>
    </div>
    </div>
    <div id="outline-container-org30a477f" class="outline-2">
    <h2 id="org30a477f"><span class="section-number-2">6.</span> Базы данных</h2>
    <div id="outline-container-orgcc1dcc3" class="outline-2">
    <h2 id="orgcc1dcc3"><span class="section-number-2">6.</span> Базы данных</h2>
    <div class="outline-text-2" id="text-6">
    <ul class="org-ul">
    <li><p>
    какие бд знаешь? расскажи про них
    </p>
    <li>Какие виды БД?

    <p>
    Реляционные базы данных (RDBMS): Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.
    </p>
    <dl class="org-dl">
    <dt>Реляционные базы данных (RDBMS)</dt><dd>Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.</dd>

    <p>
    Нереляционные базы данных (NoSQL): Нереляционные базы данных предоставляют альтернативный подход к хранению данных и могут использовать различные модели, такие как документы, ключ-значение, столбцы или графы. Они часто применяются в случаях, когда требуется гибкость в структуре данных. Примеры включают MongoDB, Cassandra и Redis.
    </p>
    <dt>Нереляционные базы данных (NoSQL)</dt><dd>Нереляционные базы данных предоставляют альтернативный подход к хранению данных и могут использовать различные модели, такие как документы, ключ-значение, столбцы или графы. Они часто применяются в случаях, когда требуется гибкость в структуре данных. Примеры включают MongoDB, Cassandra и Redis.</dd>

    <p>
    Графовые базы данных: Графовые базы данных разработаны специально для хранения и обработки данных в виде графов. Они обычно используются для анализа связей и сетей. Примером такой базы данных является Neo4j.
    </p>
    <dt>Графовые базы данных</dt><dd>Графовые базы данных разработаны специально для хранения и обработки данных в виде графов. Они обычно используются для анализа связей и сетей. Примером такой базы данных является Neo4j.</dd>

    <p>
    Встраиваемые базы данных: Эти базы данных интегрируются непосредственно в приложения и обычно работают локально. Пример - SQLite, который часто используется в мобильных приложениях.
    </p>
    <dt>Встраиваемые базы данных</dt><dd>Эти базы данных интегрируются непосредственно в приложения и обычно работают локально. Пример - SQLite, который часто используется в мобильных приложениях.</dd>

    <p>
    Ключ-значение хранилища (Key-Value Stores): Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.
    </p></li>
    <dt>Ключ-значение хранилища (Key-Value Stores)</dt><dd>Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.</dd>
    </dl></li>

    <li><p>
    есть использования дестим ?
    </p>
    <li>Что такое <code>DML</code> и <code>DDL</code> операторы?

    <p>
    ???
    </p></li>

    <li>какой оператор отвечает за сортировку ?</li>
    <dl class="org-dl">
    <dt>DDL операторы</dt><dd><i>Data Definition Language</i> (язык определения данных) Определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. <code>DDL</code> операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры <code>DDL</code> операторов включают <code>CREATE</code>, <code>ALTER</code>, <code>DROP</code>, <code>TRUNCATE</code> и <code>RENAME</code>. <code>DDL</code> операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых <code>DDL</code> операторов. <code>DDL</code> операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных</dd>
    <dt>DML операторы</dt><dd><i>Data Manipulation Language</i> (язык манипулирования данными) используется для манипулирования данными в базе данных. <code>DML</code> операторы используются для вставки, обновления и удаления данных в базе данных. Примерами <code>DML</code> операторов включают <code>SELECT</code>, <code>INSERT</code>, <code>UPDATE</code>, и <code>DELETE</code>. <code>DML</code> операторы выполняются немедленно и могут быть отменены с помощью оператора отката. <code>DML</code> операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных</dd>
    </dl></li>
    </ul>

    <div class="org-src-container">
    <pre class="src src-sql"> <span style="color: #5317ac;">GROUP</span> <span style="color: #5317ac;">BY</span>
    </pre>
    </div>

    <ul class="org-ul">
    <li><p>
    дмл операторы
    </p>

    <p>
    DDL &ldquo;Data Definition Language&rdquo; (язык определения данных), определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. DDL операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры DDL операторов включают CREATE, ALTER, DROP, TRUNCATE и RENAME. DDL операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых DDL операторов. DDL операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных.
    </p>

    <blockquote>
    <p>
    DML &ldquo;Data Manipulation Language&rdquo; (язык манипулирования данными) используется для манипулирования данными в базе данных. DML операторы используются для вставки, обновления и удаления данных в базе данных. Примерами DML операторов включают SELECT, INSERT, UPDATE, и DELETE. DML операторы выполняются немедленно и могут быть отменены с помощью оператора отката. DML операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных.
    В целом, <code>DDL</code> используется для определения и управления структурой базы данных, в то время как <code>DML</code> используется для манипулирования данными в базе данных. <code>DDL</code> утверждения являются постоянными и не могут быть отменены, в то время как <code>DML</code> утверждения выполняются немедленно и могут быть отменены. <code>DDL</code> утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют <code>DML</code> утверждения.
    </p>

    <p>
    В целом, DDL используется для определения и управления структурой базы данных, в то время как DML используется для манипулирования данными в базе данных. DDL утверждения являются постоянными и не могут быть отменены, в то время как DML утверждения выполняются немедленно и могут быть отменены. DDL утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют DML утверждения.
    </p></li>
    </ul>
    </blockquote>
    </div>
    </div>
    </div>
    <div id="postamble" class="status">
    <p class="author">Author: Maxim Rozhkov</p>
    <p class="date">Created: 2023-11-11 Сб 18:30</p>
    <p class="date">Created: 2023-11-12 Вс 11:08</p>
    </div>
    </body>
    </html>
    143 changes: 64 additions & 79 deletions q&a.org
    View file
    Original file line number Diff line number Diff line change
    @@ -420,15 +420,15 @@

    Основные характеристики метода "Большой взрыв":

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

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

    3. *Тестирование в целом*: После интеграции производится тестирование системы в ее целом. Это включает в себя проверку общей работоспособности, взаимодействия компонентов и корректности функционирования системы в целом.
    * *Тестирование в целом*: После интеграции производится тестирование системы в ее целом. Это включает в себя проверку общей работоспособности, взаимодействия компонентов и корректности функционирования системы в целом.

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

    5. *Менее предсказуемый процесс*: Такой метод интеграции может создать более сложный и менее предсказуемый процесс разработки, особенно если существуют неучтенные зависимости или непредвиденные проблемы.
    * *Менее предсказуемый процесс*: Такой метод интеграции может создать более сложный и менее предсказуемый процесс разработки, особенно если существуют неучтенные зависимости или непредвиденные проблемы.

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

    @@ -458,73 +458,73 @@

    Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом:

    1. Представление данных — на стороне клиента.
    1. Представление данных — на стороне клиента.

    2. Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).
    2. Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).

    3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.
    3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

    + разница между толстым и тонким клиентом?
    + Разница между толстым и тонким клиентом?

    1. Толстый клиент (Fat Client):
    1. Толстый клиент (Fat Client):

    - *Локальная обработка:*
    - *Определение:* Толстый клиент имеет значительную локальную обработку и хранение данных.
    - *Характеристики:* Значительная часть бизнес-логики и функциональности находится на клиентской стороне.
    2. *Локальная обработка:*
    - *Определение:* Толстый клиент имеет значительную локальную обработку и хранение данных.
    - *Характеристики:* Значительная часть бизнес-логики и функциональности находится на клиентской стороне.

    - *Графический интерфейс:*
    - *Примеры:* Нативные приложения, устанавливаемые на устройстве пользователя (например, десктопные приложения).
    3. *Графический интерфейс:*
    - *Примеры:* Нативные приложения, устанавливаемые на устройстве пользователя (например, десктопные приложения).

    - *Объем передаваемых данных:*
    - *Коммуникация:* Обычно взаимодействует с сервером для получения данных, но имеет богатый функциональный интерфейс и часто загружает больший объем данных для локальной обработки.
    4. *Объем передаваемых данных:*
    - *Коммуникация:* Обычно взаимодействует с сервером для получения данных, но имеет богатый функциональный интерфейс и часто загружает больший объем данных для локальной обработки.

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

    2. Тонкий клиент (Thin Client):
    6. Тонкий клиент (Thin Client):

    - *Минимальная локальная обработка:*
    - *Определение:* Тонкий клиент имеет минимальную локальную обработку и полагается на сервер для большей части обработки и хранения данных.
    - *Характеристики:* Минимальный функционал на клиентской стороне, часто только графический интерфейс и минимальная логика.
    7. *Минимальная локальная обработка:*
    - *Определение:* Тонкий клиент имеет минимальную локальную обработку и полагается на сервер для большей части обработки и хранения данных.
    - *Характеристики:* Минимальный функционал на клиентской стороне, часто только графический интерфейс и минимальная логика.

    - *Графический интерфейс:*
    - *Примеры:* Веб-приложения, которые работают в браузере.
    8. *Графический интерфейс:*
    - *Примеры:* Веб-приложения, которые работают в браузере.

    - *Объем передаваемых данных:*
    - *Коммуникация:* Взаимодействует с сервером для получения данных и обновлений, пересылает минимальные данные для отображения и ввода.
    9. *Объем передаваемых данных:*
    - *Коммуникация:* Взаимодействует с сервером для получения данных и обновлений, пересылает минимальные данные для отображения и ввода.

    - *Преимущества:*
    10. *Преимущества:*
    - Легко управлять и обновлять, так как большинство изменений происходит на сервере. Обеспечивает централизованное управление приложениями.

    Общие соображения:
    Общие соображения:

    - Выбор между толстым и тонким клиентом зависит от требований проекта, характера приложения и сетевой инфраструктуры.
    - Выбор между толстым и тонким клиентом зависит от требований проекта, характера приложения и сетевой инфраструктуры.

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

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

    + какие протоколы знаешь?

    1. HTTP (Hypertext Transfer Protocol) - протокол передачи гипертекста, используемый в веб-браузерах и веб-серверах для обмена данными.
    1. HTTP (Hypertext Transfer Protocol) - протокол передачи гипертекста, используемый в веб-браузерах и веб-серверах для обмена данными.

    2. FTP (File Transfer Protocol) - протокол передачи файлов, используемый для обмена файлами между клиентом и сервером.
    2. FTP (File Transfer Protocol) - протокол передачи файлов, используемый для обмена файлами между клиентом и сервером.

    3. SMTP (Simple Mail Transfer Protocol) - протокол передачи электронной почты, используемый для отправки почты от клиента к серверу и между серверами.
    3. SMTP (Simple Mail Transfer Protocol) - протокол передачи электронной почты, используемый для отправки почты от клиента к серверу и между серверами.

    4. POP3 (Post Office Protocol version 3) - протокол получения электронной почты, используемый для получения почты с сервера на клиентскую программу.
    4. POP3 (Post Office Protocol version 3) - протокол получения электронной почты, используемый для получения почты с сервера на клиентскую программу.

    5. IMAP (Internet Message Access Protocol) - протокол доступа к электронной почте, позволяющий клиенту получать письма с сервера и управлять ими на сервере.
    5. IMAP (Internet Message Access Protocol) - протокол доступа к электронной почте, позволяющий клиенту получать письма с сервера и управлять ими на сервере.

    6. DNS (Domain Name System) - протокол системы доменных имен, используемый для преобразования доменных имен в IP-адреса и наоборот.
    6. DNS (Domain Name System) - протокол системы доменных имен, используемый для преобразования доменных имен в IP-адреса и наоборот.

    7. TCP/IP (Transmission Control Protocol/Internet Protocol) - набор протоколов, используемых для обмена данными в сети Интернет.
    7. TCP/IP (Transmission Control Protocol/Internet Protocol) - набор протоколов, используемых для обмена данными в сети Интернет.

    8. SSH (Secure Shell) - протокол безопасного удаленного доступа к компьютеру по сети.
    8. SSH (Secure Shell) - протокол безопасного удаленного доступа к компьютеру по сети.

    9. SNMP (Simple Network Management Protocol) - протокол управления сетью, используемый для мониторинга и управления устройствами в сети.
    9. SNMP (Simple Network Management Protocol) - протокол управления сетью, используемый для мониторинга и управления устройствами в сети.

    10. DHCP (Dynamic Host Configuration Protocol) - протокол динамической настройки сетевых параметров, используемый для автоматической настройки IP-адресов и других сетевых параметров на компьютерах в сети.
    10. DHCP (Dynamic Host Configuration Protocol) - протокол динамической настройки сетевых параметров, используемый для автоматической настройки IP-адресов и других сетевых параметров на компьютерах в сети.

    + В чем различие методов GET и POST?

    @@ -550,11 +550,11 @@

    ** Клиент-серверное взаимодействие

    + патч и пут отличия?
    + PATCH и PUT отличия?

    1. Метод PATCH (патч) используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.
    1. Метод PATCH используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.

    2. Метод PUT (пут) используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.
    2. Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.

    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.

    @@ -648,10 +648,6 @@
    }
    #+END_SRC

    + работал со сваггерами?

    Работал.

    + Идемпотентность

    Пример идемпотентного PATCH-запроса: Предположим, у нас есть ресурс "пользователь" с полями "имя" и "электронная почта". Мы отправляем PATCH-запрос с обновленным значением только для поля "имя". Если этот запрос применяется несколько раз, состояние пользователя на сервере не изменится после первого применения, поскольку в данном примере PATCH обновляет значение поля "имя". Повторное применение запроса просто повторно обновит поле "имя" на то же значение. Это случай, когда PATCH настроен на обновление, а не на добавление. В таком случае PATCH идемпотентен.
    @@ -679,17 +675,20 @@
    Так же как и в *Kafka*, но отличие состоит в обработке сообщений. Отличие состоит в наличии Exchange (обменник). Сообщение сначала попадает в обменник и дальше на основании ключей попадает в очередь.

    Producer_1 󰁃 Queue_1 󰁔 Consumer_1

    󰁜

    Producer_2 󰁔 Exchange 󰁔 Queue_2 󰁔 Consumer_2

    󰁃
    Producer_3 󰁜 Queue_3 󰁔 Consumer_3

    + Что такое протокол AMQP?

    | Прикладной уровень | HTTP WebSocket DNS *AMQP* |
    | Транспортный уровень | TCP UDP |
    | Сетевой уровень | IP ICMP ARP DHCP |
    | Уровень сетевого доступа | Ethernet Wi-Fi |
    | Транспортный уровень | TCP UDP |
    | Сетевой уровень | IP ICMP ARP DHCP |
    | Уровень сетевого доступа | Ethernet Wi-Fi |

    + По какому принципу организована очерелдь в RabbitMQ?

    @@ -704,45 +703,31 @@
    | headers | routing headers | Маршрутизация с помощью заголовков |
    | deadletter | not responding | Сюда попадают все сообщения которые |

    + *Почему мы привязали один обменник, а по факту отображается два?
    + Почему мы привязали один обменник, а по факту отображается два?

    Дефолтный обменник AMQP, который по-умолчанию привязан ко всем очередям

    + Что такое шина данных?






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

    + какие бд знаешь? расскажи про них

    Реляционные базы данных (RDBMS): Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.

    Нереляционные базы данных (NoSQL): Нереляционные базы данных предоставляют альтернативный подход к хранению данных и могут использовать различные модели, такие как документы, ключ-значение, столбцы или графы. Они часто применяются в случаях, когда требуется гибкость в структуре данных. Примеры включают MongoDB, Cassandra и Redis.
    + Какие виды БД?

    Графовые базы данных: Графовые базы данных разработаны специально для хранения и обработки данных в виде графов. Они обычно используются для анализа связей и сетей. Примером такой базы данных является Neo4j.
    * Реляционные базы данных (RDBMS) :: Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.

    Встраиваемые базы данных: Эти базы данных интегрируются непосредственно в приложения и обычно работают локально. Пример - SQLite, который часто используется в мобильных приложениях.
    * Нереляционные базы данных (NoSQL) :: Нереляционные базы данных предоставляют альтернативный подход к хранению данных и могут использовать различные модели, такие как документы, ключ-значение, столбцы или графы. Они часто применяются в случаях, когда требуется гибкость в структуре данных. Примеры включают MongoDB, Cassandra и Redis.

    Ключ-значение хранилища (Key-Value Stores): Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.
    * Графовые базы данных :: Графовые базы данных разработаны специально для хранения и обработки данных в виде графов. Они обычно используются для анализа связей и сетей. Примером такой базы данных является Neo4j.

    + есть использования дестим ?

    ???

    + какой оператор отвечает за сортировку ?

    #+BEGIN_SRC sql :exports code
    GROUP BY
    #+END_SRC
    * Встраиваемые базы данных :: Эти базы данных интегрируются непосредственно в приложения и обычно работают локально. Пример - SQLite, который часто используется в мобильных приложениях.

    + дмл операторы
    * Ключ-значение хранилища (Key-Value Stores) :: Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.

    DDL "Data Definition Language" (язык определения данных), определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. DDL операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры DDL операторов включают CREATE, ALTER, DROP, TRUNCATE и RENAME. DDL операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых DDL операторов. DDL операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных.
    + Что такое ~DML~ и ~DDL~ операторы?

    DML "Data Manipulation Language" (язык манипулирования данными) используется для манипулирования данными в базе данных. DML операторы используются для вставки, обновления и удаления данных в базе данных. Примерами DML операторов включают SELECT, INSERT, UPDATE, и DELETE. DML операторы выполняются немедленно и могут быть отменены с помощью оператора отката. DML операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных.
    * DDL операторы :: /Data Definition Language/ (язык определения данных) Определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. ~DDL~ операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры ~DDL~ операторов включают ~CREATE~, ~ALTER~, ~DROP~, ~TRUNCATE~ и ~RENAME~. ~DDL~ операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых ~DDL~ операторов. ~DDL~ операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных
    * DML операторы :: /Data Manipulation Language/ (язык манипулирования данными) используется для манипулирования данными в базе данных. ~DML~ операторы используются для вставки, обновления и удаления данных в базе данных. Примерами ~DML~ операторов включают ~SELECT~, ~INSERT~, ~UPDATE~, и ~DELETE~. ~DML~ операторы выполняются немедленно и могут быть отменены с помощью оператора отката. ~DML~ операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных

    В целом, DDL используется для определения и управления структурой базы данных, в то время как DML используется для манипулирования данными в базе данных. DDL утверждения являются постоянными и не могут быть отменены, в то время как DML утверждения выполняются немедленно и могут быть отменены. DDL утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют DML утверждения.
    #+begin_quote
    В целом, ~DDL~ используется для определения и управления структурой базы данных, в то время как ~DML~ используется для манипулирования данными в базе данных. ~DDL~ утверждения являются постоянными и не могут быть отменены, в то время как ~DML~ утверждения выполняются немедленно и могут быть отменены. ~DDL~ утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют ~DML~ утверждения.
    #+end_quote
  9. abcwalk revised this gist Nov 11, 2023. 4 changed files with 456 additions and 42 deletions.
    6 changes: 6 additions & 0 deletions .gitignore
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,6 @@
    .DS_Store
    .idea
    *.log
    tmp/

    *.html
    312 changes: 284 additions & 28 deletions IBS_interview.html → q&a.html
    View file
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
    <head>
    <!-- 2023-11-10 Пт 13:37 -->
    <!-- 2023-11-11 Сб 18:30 -->
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>IBS Interview</title>
    @@ -201,19 +201,128 @@ <h1 class="title">IBS Interview</h1>
    <h2>Table of Contents</h2>
    <div id="text-table-of-contents" role="doc-toc">
    <ul>
    <li><a href="#orge6bfdd4">1. Теория тестирования</a></li>
    <li><a href="#orga2637a3">2. Техники тест-дизайна</a></li>
    <li><a href="#org462a908">3. Тестирование мобильных приложений</a></li>
    <li><a href="#org82f1c65">4. Тестирование бэкенда</a></li>
    <li><a href="#orgc4aaae4">5. Клиент-серверное взаимодействие</a></li>
    <li><a href="#org6d15cae">6. Базы данных</a></li>
    <li><a href="#org2a2f7b5">1. Теория тестирования</a></li>
    <li><a href="#orgc8660d0">2. Техники тест-дизайна</a></li>
    <li><a href="#orgcaa43d2">3. Тестирование мобильных приложений</a></li>
    <li><a href="#orgc84c707">4. Тестирование бэкенда</a></li>
    <li><a href="#orgce2241b">5. Клиент-серверное взаимодействие</a>
    <ul>
    <li><a href="#org2c30c87">5.1. RabbitMQ</a></li>
    </ul>
    </li>
    <li><a href="#org30a477f">6. Базы данных</a></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orge6bfdd4" class="outline-2">
    <h2 id="orge6bfdd4"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div id="outline-container-org2a2f7b5" class="outline-2">
    <h2 id="org2a2f7b5"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div class="outline-text-2" id="text-1">
    <ul class="org-ul">
    <li><p>
    Что такое тестирование?
    </p>

    <p>
    Комплекс мероприятий, направленных на проведение проверок на соответствие продукта требованиям, к нему предъявляемым (прямым или косвенным).
    </p></li>

    <li><p>
    Цель тестирования?
    </p>

    <p>
    Донесение релевантной информации о продукте команде для принятия верных решений.
    </p></li>

    <li>Что такое верификация и валидация?

    <ul class="org-ul">
    <li>Верификация - процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям</li>

    <li>Валидация - процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям пользователя</li>
    </ul></li>

    <li>Виды тестирования

    <ul class="org-ul">
    <li>Функциональное
    Направлено на тестирование всех функций системы, для подтверждения, что каждая функция программы работает в соответствии с документацией</li>

    <li>Нефункциональное
    Тестирование свойств, которые не относятся к функциональности системы: производительность, безопасность, локализация, удобство использования, установка/удаление</li>

    <li>Связанное с изменениями
    Тестирование после исправления бага, с целью убедиться что внесенные изменения действительно решили проблему

    <ul class="org-ul">
    <li>Регресионное
    Проверка, что недавное изменение кода или данных сломало другие части разрабатываемого приложения</li>

    <li>Smoke
    Проверка критически важной функциональности</li>

    <li>Sanity
    Проверка только части приложения</li>

    <li>Re-test
    Повторное тестирование конкретного функционала после исправления бага</li>
    </ul></li>
    </ul></li>

    <li>Методы тестирования

    <ul class="org-ul">
    <li>Черный ящик
    Тестирование основано на требованиях, при этом нет знаний о внутреннем устройстве системы, работаем только с внешними интерфейсами тестируемой системы</li>

    <li>Белый ящик
    Тестирование, основанное на анализе внутренней структуры компонента или системы. Есть доступ к коду.</li>

    <li>Серый ящик
    Нет четкого определения. Например нет доступа к коду, БД, но есть доступ к API, с помощью чего можем проверить интеграционные тесты, к примеру с помощью Postman</li>
    </ul></li>

    <li><p>
    Пирамида тестирования
    </p>

    <p>
    e2e
    System testing
    Integration testing
    Unit testing
    </p>

    <ul class="org-ul">
    <li>Unit testing
    Тестируется атомарный модуль программы, чаще всего это функция. Таких тестов должно быть больше всего</li>

    <li>Integration testing
    Тестирование интеграции систем и пакетов программ, тестирование интерфейсов с внешними системами</li>

    <li>System testing
    Тестирование всей системы в целом, выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом</li>

    <li>E2E
    Проверить так ли работает программа для конечного клиента, как рассчитывалось изначально. Самый трудозатратный и дорогой, поэтому находится на вершине пирамиды тестирования.</li>
    </ul></li>

    <li>Аутентификация и авторизация

    <ul class="org-ul">
    <li>Идентификация - процедура распознавания по его личному идентификатору</li>

    <li>Аутентификация - проверят действительно ли вы это вы</li>

    <li>Авторизация - Это предоставление прав пользователю к какому-то ресурсу

    <ul class="org-ul">
    <li>Веб-токен JSON (JWT - JSON web token) - это открытый стандарт для безопасной передачи данных между сторонами, а пользователи авторизуются с помощью пары открытый/закрытый ключ</li>

    <li>OAuth позволяет API аутентифицировать и получать доступ к запрошенной системе или ресурсу</li>
    </ul></li>
    </ul></li>

    <li><p>
    Как устроен жизненный цикл дефекта?
    </p>
    @@ -227,7 +336,7 @@ <h2 id="orge6bfdd4"><span class="section-number-2">1.</span> Теория тес

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

    <li>Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как невоспроизводимый.</li>
    <li>Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как не воспроизводимый.</li>

    <li>Анализ/Приоретизация: Разработчик анализирует и исследует дефект, чтобы понять его причину и дать рекомендации по его устранению.</li>

    @@ -264,16 +373,18 @@ <h2 id="orge6bfdd4"><span class="section-number-2">1.</span> Теория тес
    <ul class="org-ul">
    <li>Ошибка — это ошибка кода в программе, которая приводит к неожиданным результатам, а дефект — это недостаток в функциональности или дизайне программы.</li>
    <li>Ошибка может быть исправлена, не влияя на общую производительность программы, тогда как дефект требует более серьезной переработки.</li>
    <li>Ошибку исправить легче, чем дефект, поскольку это специфическая проблема кодирования, тогда как дефект может быть более сложным и трудным для выявления.</li>
    </ul>
    <li><p>
    Ошибку исправить легче, чем дефект, поскольку это специфическая проблема кодирования, тогда как дефект может быть более сложным и трудным для выявления.
    </p>

    <p>
    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечени
    </p>

    <p>
    В двух словах, это любое действие или результат, производимый программным обеспечением или системой, для которого оно не предназначено.
    </p>
    </p></li>
    </ul>

    <p>
    Дефект — это ошибка, обнаруженная после запуска приложения. Это относится к различным проблемам с программными продуктами, например, к их внешнему поведению или внутренним функциям.
    @@ -448,8 +559,8 @@ <h2 id="orge6bfdd4"><span class="section-number-2">1.</span> Теория тес
    </ul>
    </div>
    </div>
    <div id="outline-container-orga2637a3" class="outline-2">
    <h2 id="orga2637a3"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div id="outline-container-orgc8660d0" class="outline-2">
    <h2 id="orgc8660d0"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div class="outline-text-2" id="text-2">
    <ul class="org-ul">
    <li>техники тест дизайна какие знаешь?
    @@ -533,10 +644,7 @@ <h2 id="orga2637a3"><span class="section-number-2">2.</span> Техники те
    Это взаимосвязь между множеством условий и действий.
    </p></li>
    </ol></li>
    </ul>


    <ul class="org-ul">
    <li><p>
    эффективность тест-кейсов
    </p>
    @@ -590,8 +698,8 @@ <h2 id="orga2637a3"><span class="section-number-2">2.</span> Техники те
    </ul>
    </div>
    </div>
    <div id="outline-container-org462a908" class="outline-2">
    <h2 id="org462a908"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div id="outline-container-orgcaa43d2" class="outline-2">
    <h2 id="orgcaa43d2"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div class="outline-text-2" id="text-3">
    <ul class="org-ul">
    <li>нативные и браузерные приложения в чем отличия?
    @@ -690,8 +798,8 @@ <h2 id="org462a908"><span class="section-number-2">3.</span> Тестирова
    </ul>
    </div>
    </div>
    <div id="outline-container-org82f1c65" class="outline-2">
    <h2 id="org82f1c65"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div id="outline-container-orgc84c707" class="outline-2">
    <h2 id="orgc84c707"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div class="outline-text-2" id="text-4">
    <ul class="org-ul">
    <li>знаешь что такое монолитный бекенд?</li>
    @@ -1008,8 +1116,8 @@ <h2 id="org82f1c65"><span class="section-number-2">4.</span> Тестирова
    </ul>
    </div>
    </div>
    <div id="outline-container-orgc4aaae4" class="outline-2">
    <h2 id="orgc4aaae4"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div id="outline-container-orgce2241b" class="outline-2">
    <h2 id="orgce2241b"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div class="outline-text-2" id="text-5">
    <ul class="org-ul">
    <li><p>
    @@ -1158,7 +1266,7 @@ <h2 id="orgc4aaae4"><span class="section-number-2">5.</span> Клиент-сер
    </p></li>

    <li><p>
    идемпотентность
    Идемпотентность
    </p>

    <p>
    @@ -1174,9 +1282,157 @@ <h2 id="orgc4aaae4"><span class="section-number-2">5.</span> Клиент-сер
    </p></li>
    </ul>
    </div>
    <div id="outline-container-org2c30c87" class="outline-3">
    <h3 id="org2c30c87"><span class="section-number-3">5.1.</span> RabbitMQ</h3>
    <div class="outline-text-3" id="text-5-1">
    <ul class="org-ul">
    <li><p>
    Что такое RabbitMQ?
    </p>

    <blockquote>
    <p>
    RabbitMQ это брокер сообщений, если в двух словах то служит для передачи данных между микросервисами
    </p>
    </blockquote>

    <p>
    Producer  Message  Exchange  Queue  Consumer
    </p>

    <blockquote>
    <p>
    Производитель (producer) – это компонент (приложение, сервис или другая часть системы), который создает и отправляет сообщения в RabbitMQ.
    </p>

    <p>
    Потребитель (consumer) – это компонент, который подписывается на очередь в RabbitMQ и активно слушает (получает) сообщения из этой очереди.
    </p>
    </blockquote>

    <p>
    Так же как и в <b>Kafka</b>, но отличие состоит в обработке сообщений. Отличие состоит в наличии Exchange (обменник). Сообщение сначала попадает в обменник и дальше на основании ключей попадает в очередь.
    </p>

    <p>
    Producer<sub>1</sub> 󰁃 Queue<sub>1</sub> 󰁔 Consumer<sub>1</sub>
    󰁜
    Producer<sub>2</sub> 󰁔 Exchange 󰁔 Queue<sub>2</sub> 󰁔 Consumer<sub>2</sub>
    󰁃
    Producer<sub>3</sub> 󰁜 Queue<sub>3</sub> 󰁔 Consumer<sub>3</sub>
    </p></li>

    <li><p>
    Что такое протокол AMQP?
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left">Прикладной уровень</td>
    <td class="org-left">HTTP WebSocket DNS <b>AMQP</b></td>
    </tr>

    <tr>
    <td class="org-left">Транспортный уровень</td>
    <td class="org-left">TCP UDP</td>
    </tr>

    <tr>
    <td class="org-left">Сетевой уровень</td>
    <td class="org-left">IP ICMP ARP DHCP</td>
    </tr>

    <tr>
    <td class="org-left">Уровень сетевого доступа</td>
    <td class="org-left">Ethernet Wi-Fi</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    По какому принципу организована очерелдь в RabbitMQ?
    </p>

    <p>
    <b>FIFO</b> - First In First Out
    </p></li>

    <li><p>
    Основные типы обменников
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <tbody>
    <tr>
    <td class="org-left">default</td>
    <td class="org-left">binding all queues</td>
    <td class="org-left">К нему по умолчанию привязаны все очереди в RabbitMQ</td>
    </tr>

    <tr>
    <td class="org-left">fanout</td>
    <td class="org-left">push to all queues</td>
    <td class="org-left">Сообщения отправляются во все очереди</td>
    </tr>

    <tr>
    <td class="org-left">direct</td>
    <td class="org-left">routing key</td>
    <td class="org-left">Сообщения маршрутизируются с помощью routing key</td>
    </tr>

    <tr>
    <td class="org-left">topic</td>
    <td class="org-left"># *</td>
    <td class="org-left">Поиск происходит по шаблону # или *</td>
    </tr>

    <tr>
    <td class="org-left">headers</td>
    <td class="org-left">routing headers</td>
    <td class="org-left">Маршрутизация с помощью заголовков</td>
    </tr>

    <tr>
    <td class="org-left">deadletter</td>
    <td class="org-left">not responding</td>
    <td class="org-left">Сюда попадают все сообщения которые</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    *Почему мы привязали один обменник, а по факту отображается два?
    </p>

    <p>
    Дефолтный обменник AMQP, который по-умолчанию привязан ко всем очередям
    </p></li>

    <li>Что такое шина данных?</li>
    </ul>
    </div>
    </div>
    </div>
    <div id="outline-container-org6d15cae" class="outline-2">
    <h2 id="org6d15cae"><span class="section-number-2">6.</span> Базы данных</h2>
    <div id="outline-container-org30a477f" class="outline-2">
    <h2 id="org30a477f"><span class="section-number-2">6.</span> Базы данных</h2>
    <div class="outline-text-2" id="text-6">
    <ul class="org-ul">
    <li><p>
    @@ -1241,7 +1497,7 @@ <h2 id="org6d15cae"><span class="section-number-2">6.</span> Базы данны
    </div>
    <div id="postamble" class="status">
    <p class="author">Author: Maxim Rozhkov</p>
    <p class="date">Created: 2023-11-10 Пт 13:37</p>
    <p class="date">Created: 2023-11-11 Сб 18:30</p>
    </div>
    </body>
    </html>
    161 changes: 147 additions & 14 deletions IBS_interview.org → q&a.org
    View file
    Original file line number Diff line number Diff line change
    @@ -2,6 +2,85 @@

    ** Теория тестирования

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

    Комплекс мероприятий, направленных на проведение проверок на соответствие продукта требованиям, к нему предъявляемым (прямым или косвенным).

    + Цель тестирования?

    Донесение релевантной информации о продукте команде для принятия верных решений.

    + Что такое верификация и валидация?

    * Верификация - процесс оценки конечного продукта, чтобы проверить, соответствует ли он требованиям

    * Валидация - процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям пользователя

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

    * Функциональное
    Направлено на тестирование всех функций системы, для подтверждения, что каждая функция программы работает в соответствии с документацией

    * Нефункциональное
    Тестирование свойств, которые не относятся к функциональности системы: производительность, безопасность, локализация, удобство использования, установка/удаление

    * Связанное с изменениями
    Тестирование после исправления бага, с целью убедиться что внесенные изменения действительно решили проблему

    - Регресионное
    Проверка, что недавное изменение кода или данных сломало другие части разрабатываемого приложения

    - Smoke
    Проверка критически важной функциональности

    - Sanity
    Проверка только части приложения

    - Re-test
    Повторное тестирование конкретного функционала после исправления бага

    + Методы тестирования

    * Черный ящик
    Тестирование основано на требованиях, при этом нет знаний о внутреннем устройстве системы, работаем только с внешними интерфейсами тестируемой системы

    * Белый ящик
    Тестирование, основанное на анализе внутренней структуры компонента или системы. Есть доступ к коду.

    * Серый ящик
    Нет четкого определения. Например нет доступа к коду, БД, но есть доступ к API, с помощью чего можем проверить интеграционные тесты, к примеру с помощью Postman

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

    e2e
    System testing
    Integration testing
    Unit testing

    * Unit testing
    Тестируется атомарный модуль программы, чаще всего это функция. Таких тестов должно быть больше всего

    * Integration testing
    Тестирование интеграции систем и пакетов программ, тестирование интерфейсов с внешними системами

    * System testing
    Тестирование всей системы в целом, выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом

    * E2E
    Проверить так ли работает программа для конечного клиента, как рассчитывалось изначально. Самый трудозатратный и дорогой, поэтому находится на вершине пирамиды тестирования.

    + Аутентификация и авторизация

    * Идентификация - процедура распознавания по его личному идентификатору

    * Аутентификация - проверят действительно ли вы это вы

    * Авторизация - Это предоставление прав пользователю к какому-то ресурсу

    - Веб-токен JSON (JWT - JSON web token) - это открытый стандарт для безопасной передачи данных между сторонами, а пользователи авторизуются с помощью пары открытый/закрытый ключ

    - OAuth позволяет API аутентифицировать и получать доступ к запрошенной системе или ресурсу

    + Как устроен жизненный цикл дефекта?

    Жизненный цикл дефекта - это последовательность этапов, которые проходит дефект от его обнаружения до закрытия. Хотя конкретные этапы могут немного отличаться в различных организациях или проектах, обычно жизненный цикл дефекта включает следующие этапы:
    @@ -10,7 +89,7 @@

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

    * Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как невоспроизводимый.
    * Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как не воспроизводимый.

    * Анализ/Приоретизация: Разработчик анализирует и исследует дефект, чтобы понять его причину и дать рекомендации по его устранению.

    @@ -39,21 +118,21 @@
    * Ошибка может быть исправлена, не влияя на общую производительность программы, тогда как дефект требует более серьезной переработки.
    * Ошибку исправить легче, чем дефект, поскольку это специфическая проблема кодирования, тогда как дефект может быть более сложным и трудным для выявления.

    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечени
    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечени

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

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

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

    | Параметры сравнения | Ошибка | Дефект |
    |-----------------------+---------------------------------------------------------------------------------------+--------------------------------------------------------------|
    | Определение | Баги — это проблемы, обнаруженные в процессе тестирования. | Методологии оперативной разработки и регулярная оцxенка кода. |
    | Был воспитан | Инженеры-испытатели. | Тестеры. |
    | Тип | Логические, алгоритмические и ресурсные ошибки. | Критические, основные, второстепенные и тривиальные. |
    | Причины возникновения | Отсутствующий код, неправильное кодирование или дополнительное кодирование. | Кодовая или логическая ошибка и неправильный ввод. |
    | Предотвращени | Мы используем фундаментальные и точные подходы к разработке программного обеспечения. | Использование фундаментальных и точных подходов к разработке программного обеспечения. |
    | Параметры сравнения | Ошибка | Дефект |
    |-----------------------+---------------------------------------------------------------------------------------+--------------------------------------------------------------|
    | Определение | Баги — это проблемы, обнаруженные в процессе тестирования. | Методологии оперативной разработки и регулярная оцxенка кода. |
    | Был воспитан | Инженеры-испытатели. | Тестеры. |
    | Тип | Логические, алгоритмические и ресурсные ошибки. | Критические, основные, второстепенные и тривиальные. |
    | Причины возникновения | Отсутствующий код, неправильное кодирование или дополнительное кодирование. | Кодовая или логическая ошибка и неправильный ввод. |
    | Предотвращени | Мы используем фундаментальные и точные подходы к разработке программного обеспечения. | Использование фундаментальных и точных подходов к разработке программного обеспечения. |

    + отличия чек-лист и тест-кейс?

    @@ -174,7 +253,6 @@
    сложных бизнес требований, которые должны быть реализованы в продукте.
    Это взаимосвязь между множеством условий и действий.


    + эффективность тест-кейсов

    Когда переписываешь тест кейсы 10 раз в месяц
    @@ -574,14 +652,69 @@

    Работал.

    + идемпотентность
    + Идемпотентность

    Пример идемпотентного PATCH-запроса: Предположим, у нас есть ресурс "пользователь" с полями "имя" и "электронная почта". Мы отправляем PATCH-запрос с обновленным значением только для поля "имя". Если этот запрос применяется несколько раз, состояние пользователя на сервере не изменится после первого применения, поскольку в данном примере PATCH обновляет значение поля "имя". Повторное применение запроса просто повторно обновит поле "имя" на то же значение. Это случай, когда PATCH настроен на обновление, а не на добавление. В таком случае PATCH идемпотентен.

    Пример неидемпотентного PATCH-запроса: Предположим, у нас есть ресурс "счет" с полем "баланс". Мы отправляем PATCH-запрос с обновлением значения поля "баланс" на +10 единиц. Если этот запрос применяется несколько раз, состояние счета на сервере будет изменяться после каждого применения. Каждый запрос увеличивает баланс на 10 единиц, поэтому повторное применение запроса будет иметь различный эффект каждый раз. Это случай, когда PATCH настроен на добавление, а не на обновление. В этом случае PATCH является неидемпотентным, т.к. каждый повторный вызов меняет состояние ресурса (прибавляет +10 к балансу).

    Идемпотентными методами являются: GET, PUT, DELETE, HEAD и OPTIONS. POST и PATCH не входят в эту группу.

    *** RabbitMQ

    + Что такое RabbitMQ?

    #+begin_quote
    RabbitMQ это брокер сообщений, если в двух словах то служит для передачи данных между микросервисами
    #+end_quote

    Producer  Message  Exchange  Queue  Consumer

    #+begin_quote
    Производитель (producer) – это компонент (приложение, сервис или другая часть системы), который создает и отправляет сообщения в RabbitMQ.

    Потребитель (consumer) – это компонент, который подписывается на очередь в RabbitMQ и активно слушает (получает) сообщения из этой очереди.
    #+end_quote

    Так же как и в *Kafka*, но отличие состоит в обработке сообщений. Отличие состоит в наличии Exchange (обменник). Сообщение сначала попадает в обменник и дальше на основании ключей попадает в очередь.

    Producer_1 󰁃 Queue_1 󰁔 Consumer_1
    󰁜
    Producer_2 󰁔 Exchange 󰁔 Queue_2 󰁔 Consumer_2
    󰁃
    Producer_3 󰁜 Queue_3 󰁔 Consumer_3

    + Что такое протокол AMQP?

    | Прикладной уровень | HTTP WebSocket DNS *AMQP* |
    | Транспортный уровень | TCP UDP |
    | Сетевой уровень | IP ICMP ARP DHCP |
    | Уровень сетевого доступа | Ethernet Wi-Fi |

    + По какому принципу организована очерелдь в RabbitMQ?

    *FIFO* - First In First Out

    + Основные типы обменников

    | default | binding all queues | К нему по умолчанию привязаны все очереди в RabbitMQ |
    | fanout | push to all queues | Сообщения отправляются во все очереди |
    | direct | routing key | Сообщения маршрутизируются с помощью routing key |
    | topic | # * | Поиск происходит по шаблону # или * |
    | headers | routing headers | Маршрутизация с помощью заголовков |
    | deadletter | not responding | Сюда попадают все сообщения которые |

    + *Почему мы привязали один обменник, а по факту отображается два?

    Дефолтный обменник AMQP, который по-умолчанию привязан ко всем очередям

    + Что такое шина данных?






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

    + какие бд знаешь? расскажи про них
    19 changes: 19 additions & 0 deletions вопросы_от_кандидата.org
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,19 @@
    #+title: Вопросы от кандидата

    Во-первых, неплохо узнать побольше о компании, куда рассчитываете попасть. И заодно продемонстрировать свой интерес.

    Не стоит слишком усердствовать и спрашивать абсолютно все. Уточните только важные моменты.
    Вот несколько вариантов:

    * Какие технологии и инструменты используются в конкретном проекте?
    * Как часто сотрудники работают сверхурочно?
    * Сколько существующих пользователей у продукта?
    * Какая модель разработки используется в проекте?
    * Как проходят совещания и кто на них ходит?
    * Тестируете ли/Есть ли у вас мобильные приложения?

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

    Допустим, я привык автоматизировать на Python. Или просто прошел по нему курс. А меня на собеседовании спросили про Selenium и про то, как я будут искать элементы на веб-странице. Ни слова про Python я не смог вставить. Тогда можно спросить, какие фреймворки используются на проекте, сколько кода вообще написано и как долго выполняется прогон тестов. И после ответа рассказать, как вы то же самое делаете на Python, только в два раза быстрее.

    В-третьих, нужно подчеркнуть, что для вас важно понимание следуюших шагов. Спросите, что будет дальше. Возможно, еще одно собеседование с заказчиком или с руководителем отдела? Когда будет ответ, что он из себя представляет. Что будет означать тишина через два-три дня? Ведь не все компании присылают отказы, а просто так ждать вам не хотелось бы. В общем, проговорите следующие шаги и даже сроки. У ваших опонентов будет дополнительный повод быстрее принимать по вам решение и меньше шансов, что они забудут о вас.
  10. abcwalk revised this gist Nov 10, 2023. 2 changed files with 1247 additions and 2 deletions.
    1,247 changes: 1,247 additions & 0 deletions IBS_interview.html
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,1247 @@
    <?xml version="1.0" encoding="utf-8"?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
    <head>
    <!-- 2023-11-10 Пт 13:37 -->
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>IBS Interview</title>
    <meta name="author" content="Maxim Rozhkov" />
    <meta name="generator" content="Org Mode" />
    <style>
    #content { max-width: 60em; margin: auto; }
    .title { text-align: center;
    margin-bottom: .2em; }
    .subtitle { text-align: center;
    font-size: medium;
    font-weight: bold;
    margin-top:0; }
    .todo { font-family: monospace; color: red; }
    .done { font-family: monospace; color: green; }
    .priority { font-family: monospace; color: orange; }
    .tag { background-color: #eee; font-family: monospace;
    padding: 2px; font-size: 80%; font-weight: normal; }
    .timestamp { color: #bebebe; }
    .timestamp-kwd { color: #5f9ea0; }
    .org-right { margin-left: auto; margin-right: 0px; text-align: right; }
    .org-left { margin-left: 0px; margin-right: auto; text-align: left; }
    .org-center { margin-left: auto; margin-right: auto; text-align: center; }
    .underline { text-decoration: underline; }
    #postamble p, #preamble p { font-size: 90%; margin: .2em; }
    p.verse { margin-left: 3%; }
    pre {
    border: 1px solid #e6e6e6;
    border-radius: 3px;
    background-color: #f2f2f2;
    padding: 8pt;
    font-family: monospace;
    overflow: auto;
    margin: 1.2em;
    }
    pre.src {
    position: relative;
    overflow: auto;
    }
    pre.src:before {
    display: none;
    position: absolute;
    top: -8px;
    right: 12px;
    padding: 3px;
    color: #555;
    background-color: #f2f2f299;
    }
    pre.src:hover:before { display: inline; margin-top: 14px;}
    /* Languages per Org manual */
    pre.src-asymptote:before { content: 'Asymptote'; }
    pre.src-awk:before { content: 'Awk'; }
    pre.src-authinfo::before { content: 'Authinfo'; }
    pre.src-C:before { content: 'C'; }
    /* pre.src-C++ doesn't work in CSS */
    pre.src-clojure:before { content: 'Clojure'; }
    pre.src-css:before { content: 'CSS'; }
    pre.src-D:before { content: 'D'; }
    pre.src-ditaa:before { content: 'ditaa'; }
    pre.src-dot:before { content: 'Graphviz'; }
    pre.src-calc:before { content: 'Emacs Calc'; }
    pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
    pre.src-fortran:before { content: 'Fortran'; }
    pre.src-gnuplot:before { content: 'gnuplot'; }
    pre.src-haskell:before { content: 'Haskell'; }
    pre.src-hledger:before { content: 'hledger'; }
    pre.src-java:before { content: 'Java'; }
    pre.src-js:before { content: 'Javascript'; }
    pre.src-latex:before { content: 'LaTeX'; }
    pre.src-ledger:before { content: 'Ledger'; }
    pre.src-lisp:before { content: 'Lisp'; }
    pre.src-lilypond:before { content: 'Lilypond'; }
    pre.src-lua:before { content: 'Lua'; }
    pre.src-matlab:before { content: 'MATLAB'; }
    pre.src-mscgen:before { content: 'Mscgen'; }
    pre.src-ocaml:before { content: 'Objective Caml'; }
    pre.src-octave:before { content: 'Octave'; }
    pre.src-org:before { content: 'Org mode'; }
    pre.src-oz:before { content: 'OZ'; }
    pre.src-plantuml:before { content: 'Plantuml'; }
    pre.src-processing:before { content: 'Processing.js'; }
    pre.src-python:before { content: 'Python'; }
    pre.src-R:before { content: 'R'; }
    pre.src-ruby:before { content: 'Ruby'; }
    pre.src-sass:before { content: 'Sass'; }
    pre.src-scheme:before { content: 'Scheme'; }
    pre.src-screen:before { content: 'Gnu Screen'; }
    pre.src-sed:before { content: 'Sed'; }
    pre.src-sh:before { content: 'shell'; }
    pre.src-sql:before { content: 'SQL'; }
    pre.src-sqlite:before { content: 'SQLite'; }
    /* additional languages in org.el's org-babel-load-languages alist */
    pre.src-forth:before { content: 'Forth'; }
    pre.src-io:before { content: 'IO'; }
    pre.src-J:before { content: 'J'; }
    pre.src-makefile:before { content: 'Makefile'; }
    pre.src-maxima:before { content: 'Maxima'; }
    pre.src-perl:before { content: 'Perl'; }
    pre.src-picolisp:before { content: 'Pico Lisp'; }
    pre.src-scala:before { content: 'Scala'; }
    pre.src-shell:before { content: 'Shell Script'; }
    pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
    /* additional language identifiers per "defun org-babel-execute"
    in ob-*.el */
    pre.src-cpp:before { content: 'C++'; }
    pre.src-abc:before { content: 'ABC'; }
    pre.src-coq:before { content: 'Coq'; }
    pre.src-groovy:before { content: 'Groovy'; }
    /* additional language identifiers from org-babel-shell-names in
    ob-shell.el: ob-shell is the only babel language using a lambda to put
    the execution function name together. */
    pre.src-bash:before { content: 'bash'; }
    pre.src-csh:before { content: 'csh'; }
    pre.src-ash:before { content: 'ash'; }
    pre.src-dash:before { content: 'dash'; }
    pre.src-ksh:before { content: 'ksh'; }
    pre.src-mksh:before { content: 'mksh'; }
    pre.src-posh:before { content: 'posh'; }
    /* Additional Emacs modes also supported by the LaTeX listings package */
    pre.src-ada:before { content: 'Ada'; }
    pre.src-asm:before { content: 'Assembler'; }
    pre.src-caml:before { content: 'Caml'; }
    pre.src-delphi:before { content: 'Delphi'; }
    pre.src-html:before { content: 'HTML'; }
    pre.src-idl:before { content: 'IDL'; }
    pre.src-mercury:before { content: 'Mercury'; }
    pre.src-metapost:before { content: 'MetaPost'; }
    pre.src-modula-2:before { content: 'Modula-2'; }
    pre.src-pascal:before { content: 'Pascal'; }
    pre.src-ps:before { content: 'PostScript'; }
    pre.src-prolog:before { content: 'Prolog'; }
    pre.src-simula:before { content: 'Simula'; }
    pre.src-tcl:before { content: 'tcl'; }
    pre.src-tex:before { content: 'TeX'; }
    pre.src-plain-tex:before { content: 'Plain TeX'; }
    pre.src-verilog:before { content: 'Verilog'; }
    pre.src-vhdl:before { content: 'VHDL'; }
    pre.src-xml:before { content: 'XML'; }
    pre.src-nxml:before { content: 'XML'; }
    /* add a generic configuration mode; LaTeX export needs an additional
    (add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
    pre.src-conf:before { content: 'Configuration File'; }

    table { border-collapse:collapse; }
    caption.t-above { caption-side: top; }
    caption.t-bottom { caption-side: bottom; }
    td, th { vertical-align:top; }
    th.org-right { text-align: center; }
    th.org-left { text-align: center; }
    th.org-center { text-align: center; }
    td.org-right { text-align: right; }
    td.org-left { text-align: left; }
    td.org-center { text-align: center; }
    dt { font-weight: bold; }
    .footpara { display: inline; }
    .footdef { margin-bottom: 1em; }
    .figure { padding: 1em; }
    .figure p { text-align: center; }
    .equation-container {
    display: table;
    text-align: center;
    width: 100%;
    }
    .equation {
    vertical-align: middle;
    }
    .equation-label {
    display: table-cell;
    text-align: right;
    vertical-align: middle;
    }
    .inlinetask {
    padding: 10px;
    border: 2px solid gray;
    margin: 10px;
    background: #ffffcc;
    }
    #org-div-home-and-up
    { text-align: right; font-size: 70%; white-space: nowrap; }
    textarea { overflow-x: auto; }
    .linenr { font-size: smaller }
    .code-highlighted { background-color: #ffff00; }
    .org-info-js_info-navigation { border-style: none; }
    #org-info-js_console-label
    { font-size: 10px; font-weight: bold; white-space: nowrap; }
    .org-info-js_search-highlight
    { background-color: #ffff00; color: #000000; font-weight: bold; }
    .org-svg { }
    </style>
    </head>
    <body>
    <div id="content" class="content">
    <h1 class="title">IBS Interview</h1>
    <div id="table-of-contents" role="doc-toc">
    <h2>Table of Contents</h2>
    <div id="text-table-of-contents" role="doc-toc">
    <ul>
    <li><a href="#orge6bfdd4">1. Теория тестирования</a></li>
    <li><a href="#orga2637a3">2. Техники тест-дизайна</a></li>
    <li><a href="#org462a908">3. Тестирование мобильных приложений</a></li>
    <li><a href="#org82f1c65">4. Тестирование бэкенда</a></li>
    <li><a href="#orgc4aaae4">5. Клиент-серверное взаимодействие</a></li>
    <li><a href="#org6d15cae">6. Базы данных</a></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orge6bfdd4" class="outline-2">
    <h2 id="orge6bfdd4"><span class="section-number-2">1.</span> Теория тестирования</h2>
    <div class="outline-text-2" id="text-1">
    <ul class="org-ul">
    <li><p>
    Как устроен жизненный цикл дефекта?
    </p>

    <p>
    Жизненный цикл дефекта - это последовательность этапов, которые проходит дефект от его обнаружения до закрытия. Хотя конкретные этапы могут немного отличаться в различных организациях или проектах, обычно жизненный цикл дефекта включает следующие этапы:
    </p>

    <ul class="org-ul">
    <li>Обнаружение и Локализация: Дефект может быть обнаружен тестировщиком, пользователем или автоматическим инструментом.</li>

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

    <li>Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как невоспроизводимый.</li>

    <li>Анализ/Приоретизация: Разработчик анализирует и исследует дефект, чтобы понять его причину и дать рекомендации по его устранению.</li>

    <li>Устранение: Разработчик исправляет дефект, внося соответствующие изменения в код.</li>

    <li>Тестирование: Исправленный дефект проходит тестирование, чтобы убедиться, что проблема была успешно устранена и не вызвала новых проблем.</li>

    <li>Проверка: Дефект проверяется и подтверждается тестировщиком или другим ответственным лицом.</li>

    <li>Закрытие: Если дефект был успешно исправлен и прошел проверку, он будет закрыт. Если дефект является невоспроизводимым или не может быть исправлен, он может быть помечен как &ldquo;не устранимый&rdquo; и не будет закрыт.

    <ol class="org-ol">
    <li>Баг обнаружен и локализован</li>
    <li>Создание баг-репорта</li>
    <li>Анализ/Приоритезация бага</li>
    <li>Устранения бага</li>
    <li>Тестирование (ре-тест)</li>
    <li>Закрытие (При устранении бага, баг закрывается, либо отправляется на доработку)</li>
    </ol></li>
    </ul></li>

    <li><p>
    что такое дефект / баг?
    </p>

    <p>
    Дефект — это отклонение от исходной потребности в выводе, тогда как ошибка — это ошибка программирования.
    </p>

    <p>
    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечения.
    </p>

    <ul class="org-ul">
    <li>Ошибка — это ошибка кода в программе, которая приводит к неожиданным результатам, а дефект — это недостаток в функциональности или дизайне программы.</li>
    <li>Ошибка может быть исправлена, не влияя на общую производительность программы, тогда как дефект требует более серьезной переработки.</li>
    <li>Ошибку исправить легче, чем дефект, поскольку это специфическая проблема кодирования, тогда как дефект может быть более сложным и трудным для выявления.</li>
    </ul>

    <p>
    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечени
    </p>

    <p>
    В двух словах, это любое действие или результат, производимый программным обеспечением или системой, для которого оно не предназначено.
    </p>

    <p>
    Дефект — это ошибка, обнаруженная после запуска приложения. Это относится к различным проблемам с программными продуктами, например, к их внешнему поведению или внутренним функциям.
    </p>

    <p>
    Другими словами, в контексте тестирования Дефект — это расхождение между прогнозируемыми и фактическими результатами. Это когда критерии клиента не выполняются.
    </p>

    <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


    <colgroup>
    <col class="org-left" />

    <col class="org-left" />

    <col class="org-left" />
    </colgroup>
    <thead>
    <tr>
    <th scope="col" class="org-left">Параметры сравнения</th>
    <th scope="col" class="org-left">Ошибка</th>
    <th scope="col" class="org-left">Дефект</th>
    </tr>
    </thead>
    <tbody>
    <tr>
    <td class="org-left">Определение</td>
    <td class="org-left">Баги — это проблемы, обнаруженные в процессе тестирования.</td>
    <td class="org-left">Методологии оперативной разработки и регулярная оцxенка кода.</td>
    </tr>

    <tr>
    <td class="org-left">Был воспитан</td>
    <td class="org-left">Инженеры-испытатели.</td>
    <td class="org-left">Тестеры.</td>
    </tr>

    <tr>
    <td class="org-left">Тип</td>
    <td class="org-left">Логические, алгоритмические и ресурсные ошибки.</td>
    <td class="org-left">Критические, основные, второстепенные и тривиальные.</td>
    </tr>

    <tr>
    <td class="org-left">Причины возникновения</td>
    <td class="org-left">Отсутствующий код, неправильное кодирование или дополнительное кодирование.</td>
    <td class="org-left">Кодовая или логическая ошибка и неправильный ввод.</td>
    </tr>

    <tr>
    <td class="org-left">Предотвращени</td>
    <td class="org-left">Мы используем фундаментальные и точные подходы к разработке программного обеспечения.</td>
    <td class="org-left">Использование фундаментальных и точных подходов к разработке программного обеспечения.</td>
    </tr>
    </tbody>
    </table></li>

    <li><p>
    отличия чек-лист и тест-кейс?
    </p>

    <p>
    Чек-лист — это список проверок, которые помогают тестировщику протестировать приложение или отдельные функции. Основная цель чеклиста состоит в том, чтобы вы не забыли проверить всё, что планировали (нетривиальное поведение приложения или сложная проверка, результат которой важно отметить уже сейчас, чтобы не забыть)
    </p>

    <ol class="org-ol">
    <li><b>Назначение</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Это документ, который содержит описание шагов, которые тестировщик должен выполнить, и ожидаемых результатов для проверки определенной функциональности или сценария.</li>
    <li><b>Чек-лист</b>: Это список пунктов или шагов, который помогает проверить выполнение определенных задач, процедур или критериев, но не обязательно предоставляет подробное описание ожидаемых результатов.</li>
    </ul></li>

    <li><b>Детализация</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Обычно более детализирован и содержит шаги тестирования, входные данные, ожидаемые результаты, и иногда дополнительные сведения о тестовых условиях и предварительных требованиях.</li>
    <li><b>Чек-лист</b>: Может быть менее подробным и ориентирован на быструю проверку выполнения задачи или соответствия критериям без необходимости подробного описания каждого шага.</li>
    </ul></li>

    <li><b>Применение</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Обычно используется для более формализованных и структурированных тестирований, таких как регрессионное тестирование, интеграционное тестирование и т. д.</li>
    <li><b>Чек-лист</b>: Часто используется для поверхностных проверок, быстрой оценки выполнения стандартов или проверки соответствия простым критериям.</li>
    </ul></li>

    <li><b>Структура</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Структурирован в виде документа, который включает в себя разделы для описания шагов, входных данных, ожидаемых результатов и другой информации.</li>
    <li><b>Чек-лист</b>: Может быть простым списком пунктов без строгой структуры.</li>
    </ul></li>

    <li><b>Управление изменениями</b>:
    <ul class="org-ul">
    <li><b>Тест-кейс</b>: Обычно поддерживает лучше управление изменениями, поскольку любые изменения в функциональности могут быть обновлены в соответствующих тест-кейсах.</li>
    <li><b>Чек-лист</b>: Может быть менее удобным для управления изменениями, так как он может представлять собой простой список без подробных описаний.</li>
    </ul></li>
    </ol>

    <p>
    Оба инструмента могут быть полезными в зависимости от контекста и целей тестирования. Тест-кейсы обычно используются для более формализованных тестов, в то время как чек-листы могут быть удобными для быстрых поверхностных проверок.
    </p>

    <ul class="org-ul">
    <li>Цель чек-листа – не пропустить ни одной важной детали в процессе тестирования.</li>
    <li>Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.</li>
    </ul></li>

    <li><p>
    при каких условиях будешь писать чек-лист, а при каких тест-кейс?
    </p>

    <p>
    Чек-листы подходят, если система не очень сложная, а тестированием занимаются специалисты, вовлечённые в продукт. Если система многокомпонентная, проверки требуют сложных условий, а тестировать продукт будут менее вовлечённые в него люди, лучше потратить время на тест-кейсы.
    </p>

    <blockquote>
    <p>
    Как утверждает Алексей Баранцев &ldquo;&#x2026; простейший чек-лист &#x2013; это список тест-кейсов.&rdquo; Я с ним согласен. Т.е. чек-лист лишь перечисление тестовых прецедентов, которые могут быть описаны, а могут и не быть. Так вот&#x2026; тестовые прецеденты должны постоянно поддерживаться в актуальном состоянии. А поскольку тестовые прецеденты более детальны, чем чек-листы, то и на их поддержание требуется больше ресурсов.
    </p>

    <p>
    Поэтому мое мнение таково: если хватает ресурсов, то можно иметь описание тестовых прецедентов, если нет - нужно обходиться чек-листами. Они, по крайней мере, позволят систематизировать тестирование. Я в фирме ввел как правило &ldquo;имение как минимум чек-листов&rdquo;.
    </p>
    </blockquote>

    <ul class="org-ul">
    <li>Насколько сотрудники вовлечены чтобы понять тест-кейсы?</li>

    <li>Насколько сложный продукт?</li>

    <li>Придется ли в будушем воспроизводить эти действия? Или это на один раз?</li>

    <li>Универсальность чек-листов сможет покрыть другой функционал? Или это плохая практика?</li>
    </ul></li>

    <li>как ты понимаешь что достаточно тест кейсов и чек листов?

    <ul class="org-ul">
    <li>Когда уже нет новых идей для тестов</li>
    <li><p>
    Закончилось время на тестирование
    </p>

    <p>
    Чтобы понять, достаточно ли тест-кейсов и чек-листов для проведения тестирования, необходимо учесть несколько факторов:
    </p></li>

    <li>Покрытие функциональности: Проверьте, что все основные функциональные требования системы покрываются соответствующими тест-кейсами и чек-листами. Если важные функции не покрыты, это может быть признаком недостаточного количества тестов.</li>

    <li>Покрытие различных сценариев: Убедитесь, что тест-кейсы и чек-листы учитывают различные сценарии использования системы. Рассмотрите разные варианты ввода данных, комбинации функций и возможные пути выполнения операций. Если все сценарии не учтены, может потребоваться больше тестов.</li>

    <li>Распределение ошибок: Проанализируйте результаты предыдущих тестов, чтобы определить, в каких областях системы обнаруживались наибольшее количество ошибок. Если в определенных областях системы было много проблем, может потребоваться создать дополнительные тест-кейсы для улучшения покрытия.</li>

    <li>Временные ограничения: Учтите ограничения по времени и ресурсам, которыми вы располагаете для проведения тестирования. Если у вас есть ограниченное время для тестирования, вы можете потребовать более точечных и фокусированных тест-кейсов.</li>
    </ul></li>
    </ul>

    <p>
    В конечном итоге, достаточность тест-кейсов и чек-листов - это субъективное мнение, основанное на конкретных требованиях, характеристиках и ограничениях проекта. Важно найти баланс между достаточностью тестов и доступными ресурсами.
    </p>


    <ul class="org-ul">
    <li><p>
    есть ли опыт разработки тест данных
    </p>

    <p>
    Для больших объемов нет.
    </p></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orga2637a3" class="outline-2">
    <h2 id="orga2637a3"><span class="section-number-2">2.</span> Техники тест-дизайна</h2>
    <div class="outline-text-2" id="text-2">
    <ul class="org-ul">
    <li>техники тест дизайна какие знаешь?

    <ol class="org-ol">
    <li><p>
    Классы эквивалентности
    </p>

    <p>
    При любом значении из одного класса эквивалентности поведение системы должно быть одинаковым.
    </p></li>

    <li><p>
    Граничные значения
    </p>

    <p>
    Граница (или граничное значение) - это место где меняется поведение системы.
    </p></li>

    <li><p>
    Предугадывание ошибок
    </p>

    <p>
    Это техника создания гипотез о местах системы на основании документации и знаний о системе.
    Обычно с ее помощью создаются негативные кейсы.
    </p>

    <p>
    Предугадывать можно:
    </p>

    <ul class="org-ul">
    <li>По опыту</li>
    <li>С помощью знаний о работе системы</li>
    <li>С помощью знаний о работе ПО</li>
    <li>По документации</li>
    <li>По статистике (багов, тестов, использования)</li>
    </ul></li>

    <li>Причина-следствие</li>

    <li><p>
    Pairwise Testing
    </p>

    <p>
    Техника, которая проверяет все пары значений для заданных параметров.
    Тоесть каждое значение одного параметра хотябы один раз будет проверено с каждым значенем другого параметра.
    </p></li>

    <li><p>
    Исследовательское тестирование и туры Виттакера
    </p>

    <p>
    Это неформальный метод, при котором тесты проектируются во время их исполнения.
    Мы представляем все приложение как город.
    </p>

    <p>
    Когда применяется:
    </p>

    <ul class="org-ul">
    <li>Нужно обеспечить быструю обратную связь</li>
    <li>Нужно быстро изучить продукт</li>
    <li>Для разнообразия тестирования</li>
    <li>Нужно обнаружить и локализовать дефект</li>
    </ul></li>

    <li><p>
    Таблица принятия решений
    </p>

    <p>
    Способ компактного представления модели со сложной логикой; инструмент для упорядочения
    сложных бизнес требований, которые должны быть реализованы в продукте.
    Это взаимосвязь между множеством условий и действий.
    </p></li>
    </ol></li>
    </ul>


    <ul class="org-ul">
    <li><p>
    эффективность тест-кейсов
    </p>

    <p>
    Когда переписываешь тест кейсы 10 раз в месяц
    </p>

    <ul class="org-ul">
    <li>Слишком много информации</li>
    <li>Подробные предусловия</li>
    <li>Дубли</li>
    <li>Дополнительные материалы</li>
    <li>Лишние проверки</li>
    </ul></li>

    <li>как можно уменьшить количество тестов?

    <ul class="org-ul">
    <li>Объеденить позитивные тесты</li>

    <li>Выкинуть дубли</li>

    <li>Проверить функциональность 1 раз, а не 10.</li>
    </ul></li>

    <li><p>
    составлял ли матрицу покрытия?
    </p>

    <p>
    Карта трассируемости это тестирование требований. На проекте не было времени этим заниматься.
    </p></li>

    <li><p>
    когда не надо схлопывать тесты?
    </p>

    <p>
    Когда итоговый тест получается слишком сложным для восприятия.
    Или когла смешиваем разные функциональности
    </p></li>

    <li><p>
    занимался ли тестированием требований/спецификаций?
    </p>

    <p>
    Нет.
    </p></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org462a908" class="outline-2">
    <h2 id="org462a908"><span class="section-number-2">3.</span> Тестирование мобильных приложений</h2>
    <div class="outline-text-2" id="text-3">
    <ul class="org-ul">
    <li>нативные и браузерные приложения в чем отличия?

    <ul class="org-ul">
    <li>Нативные приложения устанавливаются непосредственно на устройство пользователя</li>

    <li>Нативные приложения разрабатываются для конкретной платформы (например, iOS или Android) и могут использовать функциональность и возможности, доступные на этой платформе. Браузерные приложения, с другой стороны, не зависят от конкретной платформы и могут работать на разных устройствах, если они поддерживают стандарты веб-технологий.</li>

    <li>Интерфейс и возможности: Нативные приложения могут использовать все функции и возможности устройства, на котором они запущены, такие как камера, геолокация, доступ к контактам и т. д. Браузерные приложения ограничены функциями и возможностями, предоставляемыми веб-браузером и доступными через JavaScript API.</li>

    <li>Обновления и развертывание: Нативные приложения требуют установки обновлений, которые разработчики должны выпускать и распространять через магазины приложений. Браузерные приложения автоматически обновляются при каждом запуске через сеть, что упрощает процесс развертывания и обновления.</li>

    <li><p>
    Доступность к платформенным функциям: Нативные приложения могут использовать специфические API, доступные на платформе, такие как Apple Pay на IOS или службы уведомлений на Android. Браузерные приложения ограничены функциональностью, предоставляемой веб-браузером и его возможностями расширений.
    </p>

    <p>
    <b>Нативные</b>
    </p>

    <p>
    Плюсы
    </p>

    <ul class="org-ul">
    <li>Наличие гайдлайнов</li>
    <li>Прямое подключение всех фишек ОС</li>
    <li>Работа без интернет</li>
    </ul>

    <p>
    Минусы
    </p>

    <ul class="org-ul">
    <li>Соответствие гайдлайнам</li>
    <li>Дорого</li>
    </ul>

    <p>
    <b>Web</b>
    </p>

    <p>
    Плюсы
    </p>

    <ul class="org-ul">
    <li>Не нужно обновлять</li>
    <li>Не нужно устанавливать</li>
    </ul>

    <p>
    Минусы
    </p>

    <ul class="org-ul">
    <li>Нужен интернет</li>
    <li>Низкая производительность</li>
    <li>Нет доступа к «железу» девайса</li>
    </ul></li>
    </ul></li>

    <li>специфические тестирования мобилок знаешь?

    <ol class="org-ol">
    <li>Тестирование на разных платформах</li>

    <li>Адаптивное тестирование</li>

    <li>Тестирование в разных сетях</li>

    <li>Тестирование поведения в фоновом режиме</li>

    <li>Тестирование использования ресурсов устройства</li>

    <li>Тестирования пользовательского интерфейса (UI)</li>

    <li>Интернационализация и локализация (i18n) (l10n)</li>

    <li>Тестирование удобства использования</li>

    <li>Тестирование производительности</li>

    <li>Тестирование энергопотребления</li>

    <li>Тестирование безопасности</li>

    <li>Тестирование обновления</li>

    <li>Push-нотификации</li>

    <li>Конфигурационное тестирование</li>
    </ol></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org82f1c65" class="outline-2">
    <h2 id="org82f1c65"><span class="section-number-2">4.</span> Тестирование бэкенда</h2>
    <div class="outline-text-2" id="text-4">
    <ul class="org-ul">
    <li>знаешь что такое монолитный бекенд?</li>
    </ul>

    <p>
    Монолитный бэкенд - это архитектурный подход, при котором вся функциональность и логика приложения размещены в одной единственной монолитной системе. В этом подходе весь код выполняется и развертывается как единое целое, включая базу данных, бизнес-логику, интерфейсы программирования (API) и т. д.
    </p>

    <p>
    Монолитный бэкенд имеет следующие особенности:
    </p>

    <ol class="org-ol">
    <li>Одна единица разработки и развертывания: все компоненты связаны вместе и разрабатываются, тестируются и развертываются как единое приложение.</li>
    <li>Менее гибкое масштабирование: потому что все функции приложения находятся в одном монолите, его масштабирование может быть сложным. Если требуется масштабирование, то необходимо масштабировать всю систему, даже если только одна функция нуждается в дополнительных ресурсах.</li>
    <li>Сильная связность компонентов: все компоненты внутри монолитного бэкенда имеют сильную связность друг с другом, и изменение одного компонента может затронуть другие компоненты.</li>
    <li>Однородность: монолит может иметь однородную кодовую базу и среду разработки для всех компонентов.</li>
    </ol>

    <p>
    При монолитной архитектуре одно приложение включает в себя весь функционал.
    </p>

    <p>
    Например есть огромная банковская система.
    В рамках одной системы:
    </p>
    <ul class="org-ul">
    <li>хранится вся информация о клиенте – физ лицах и юр лицах,</li>
    <li>все операции по клиенту, как операционные так и финансовые</li>
    <li>все заявки которые оформляет клиент</li>
    <li>в ней работают все операторы банка, осуществляют звонки, обмен сообщениями в чате и тд и тп.</li>
    </ul>
    <p>
    Если мы «выключим» монолит, мы выключим весь его функционал целиком.
    </p>

    <ul class="org-ul">
    <li><p>
    опыт работы с тест логами есть? какие знаешь?
    </p>

    <p>
    <b>Kibana</b> предоставляет визуализацию результатов
    </p></li>

    <li>что можно логировать?

    <ul class="org-ul">
    <li>вызовы методов, тело, параметры, ответ</li>
    <li>ошибки пользовательские и серверные</li>
    <li>запросы в БД</li>
    <li>служебная и вспомогательная информация об изменениях в системе</li>
    </ul></li>

    <li><p>
    интеграционное тестирование что знаешь?
    </p>

    <p>
    Интеграционное тестирование предназначено для проверки насколько хорошо два или более компонента ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
    </p>

    <p>
    Уровни интеграционного тестирования:
    </p>

    <ul class="org-ul">
    <li><p>
    Компонентный интеграционный уровень (Component Integration testing)
    </p>

    <p>
    Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
    </p></li>

    <li><p>
    Системный интеграционный уровень (System Integration Testing)
    </p>

    <p>
    Проверяется взаимодействие между разными системами после проведения системного тестирования.
    </p></li>
    </ul></li>

    <li><p>
    какие подходы к тестированию интеграции знаешь? (подход большего взрыва)
    </p>

    <p>
    Подходы к интеграционному тестированию:
    </p>

    <ul class="org-ul">
    <li><p>
    Снизу вверх (Bottom Up Integration)
    </p>

    <p>
    Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения
    </p></li>

    <li><p>
    Сверху вниз (Top Down Integration)
    </p>

    <p>
    Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз. (см. также Top Down Integration)
    </p></li>

    <li><p>
    Большой взрыв (&ldquo;Big Bang&rdquo; Integration)
    </p>

    <p>
    &ldquo;Большой взрыв&rdquo; (Big Bang Integration) - это метод интеграции программного обеспечения, при котором все компоненты или модули системы интегрируются одновременно. В этом подходе все изменения вносятся и тестируются в единой среде, и общая работоспособность системы проверяется в целом.
    </p>

    <p>
    Основные характеристики метода &ldquo;Большой взрыв&rdquo;:
    </p>

    <ol class="org-ol">
    <li><b>Интеграция в конце</b>: Интеграция всех компонентов происходит ближе к концу разработки проекта. Весь код, разработанный различными командами или индивидуальными разработчиками, собирается и интегрируется вместе.</li>

    <li><b>Одновременная интеграция</b>: Все компоненты или модули интегрируются одновременно. Это может создать ситуацию, когда множество изменений вводится в систему одновременно, что может сделать процесс выявления и устранения возможных конфликтов более сложным.</li>

    <li><b>Тестирование в целом</b>: После интеграции производится тестирование системы в ее целом. Это включает в себя проверку общей работоспособности, взаимодействия компонентов и корректности функционирования системы в целом.</li>

    <li><b>Больший риск конфликтов</b>: Поскольку интеграция происходит в конце разработки, есть риск обнаружения серьезных конфликтов и ошибок, которые могли бы быть выявлены и устранены на более ранних этапах.</li>

    <li><b>Менее предсказуемый процесс</b>: Такой метод интеграции может создать более сложный и менее предсказуемый процесс разработки, особенно если существуют неучтенные зависимости или непредвиденные проблемы.</li>
    </ol>

    <p>
    &ldquo;Большой взрыв&rdquo; может быть эффективен для небольших проектов или в ситуациях, где особенности проекта не позволяют использовать более инкрементальные методы интеграции. Однако, такой подход требует внимательного планирования и управления рисками, чтобы успешно интегрировать и протестировать систему.
    </p></li>
    </ul></li>

    <li><p>
    клиент-серверное взаимодействие как происходит?
    </p>

    <p>
    Клиент-серверное взаимодействие - это модель коммуникации между компьютерами, где один компьютер (клиент) запрашивает ресурсы или услуги у другого компьютера (сервера). Этот процесс происходит по протоколу, который определяет правила и формат обмена данными между клиентом и сервером.
    </p>

    <p>
    Вот общая схема клиент-серверного взаимодействия:
    </p>

    <ol class="org-ol">
    <li>Клиент отправляет запрос на сервер. Клиент может быть программой, приложением или даже другим сервером. Запрос содержит информацию о том, какие ресурсы или услуги требуются.</li>

    <li>Сервер принимает запрос от клиента и анализирует его. Сервер может быть физическим компьютером или виртуальной машиной, которая обрабатывает запросы от клиентов.</li>

    <li>Сервер обрабатывает запрос и генерирует ответ. В зависимости от запроса, сервер может выполнять различные операции, обращаться к базе данных, обрабатывать данные и генерировать результат.</li>

    <li>Сервер отправляет ответ обратно клиенту. Ответ содержит запрошенные ресурсы или информацию, которую клиент ожидал получить.</li>

    <li>Клиент принимает ответ от сервера и обрабатывает его. Клиент может использовать полученные данные для отображения на экране, выполнения дальнейших операций или передачи данных другим компонентам системы.</li>
    </ol>

    <p>
    Важно отметить, что клиент и сервер могут взаимодействовать по различным протоколам, таким как HTTP, FTP, SMTP и т.д. Каждый протокол определяет свои правила и формат обмена данными.
    </p></li>

    <li><p>
    какая разница между двухзвенной и трехзвенной?
    </p>

    <p>
    Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т.е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса.
    </p>

    <p>
    Такая модель показала свою неэффективность ввиду того, что при активной работе с таблицами БД возникает большая нагрузка на сеть.
    </p>

    <p>
    Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом:
    </p>

    <ol class="org-ol">
    <li>Представление данных — на стороне клиента.</li>

    <li>Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).</li>

    <li>Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.</li>
    </ol></li>

    <li><p>
    разница между толстым и тонким клиентом?
    </p>

    <ol class="org-ol">
    <li>Толстый клиент (Fat Client):</li>

    <li><b>Локальная обработка:</b>
    <ul class="org-ul">
    <li><b>Определение:</b> Толстый клиент имеет значительную локальную обработку и хранение данных.</li>
    <li><b>Характеристики:</b> Значительная часть бизнес-логики и функциональности находится на клиентской стороне.</li>
    </ul></li>

    <li><b>Графический интерфейс:</b>
    <ul class="org-ul">
    <li><b>Примеры:</b> Нативные приложения, устанавливаемые на устройстве пользователя (например, десктопные приложения).</li>
    </ul></li>

    <li><b>Объем передаваемых данных:</b>
    <ul class="org-ul">
    <li><b>Коммуникация:</b> Обычно взаимодействует с сервером для получения данных, но имеет богатый функциональный интерфейс и часто загружает больший объем данных для локальной обработки.</li>
    </ul></li>

    <li><b>Преимущества:</b>
    <ul class="org-ul">
    <li>Может обеспечивать высокую производительность и отзывчивость, так как множество операций выполняется локально.</li>
    </ul></li>

    <li>Тонкий клиент (Thin Client):</li>

    <li><b>Минимальная локальная обработка:</b>
    <ul class="org-ul">
    <li><b>Определение:</b> Тонкий клиент имеет минимальную локальную обработку и полагается на сервер для большей части обработки и хранения данных.</li>
    <li><b>Характеристики:</b> Минимальный функционал на клиентской стороне, часто только графический интерфейс и минимальная логика.</li>
    </ul></li>

    <li><b>Графический интерфейс:</b>
    <ul class="org-ul">
    <li><b>Примеры:</b> Веб-приложения, которые работают в браузере.</li>
    </ul></li>

    <li><b>Объем передаваемых данных:</b>
    <ul class="org-ul">
    <li><b>Коммуникация:</b> Взаимодействует с сервером для получения данных и обновлений, пересылает минимальные данные для отображения и ввода.</li>
    </ul></li>

    <li><b>Преимущества:</b>
    <ul class="org-ul">
    <li>Легко управлять и обновлять, так как большинство изменений происходит на сервере. Обеспечивает централизованное управление приложениями.</li>
    </ul></li>
    </ol>

    <p>
    Общие соображения:
    </p>

    <ul class="org-ul">
    <li>Выбор между толстым и тонким клиентом зависит от требований проекта, характера приложения и сетевой инфраструктуры.</li>

    <li>Толстый клиент часто приводит к более высоким требованиям к управлению, так как обновления могут быть сложными и требовать установки на каждом устройстве.</li>

    <li>Тонкий клиент может быть более удобным с точки зрения обновлений и поддержки, но может требовать более сильной сетевой инфраструктуры.</li>
    </ul></li>

    <li>какие протоколы знаешь?

    <ol class="org-ol">
    <li>HTTP (Hypertext Transfer Protocol) - протокол передачи гипертекста, используемый в веб-браузерах и веб-серверах для обмена данными.</li>

    <li>FTP (File Transfer Protocol) - протокол передачи файлов, используемый для обмена файлами между клиентом и сервером.</li>

    <li>SMTP (Simple Mail Transfer Protocol) - протокол передачи электронной почты, используемый для отправки почты от клиента к серверу и между серверами.</li>

    <li>POP3 (Post Office Protocol version 3) - протокол получения электронной почты, используемый для получения почты с сервера на клиентскую программу.</li>

    <li>IMAP (Internet Message Access Protocol) - протокол доступа к электронной почте, позволяющий клиенту получать письма с сервера и управлять ими на сервере.</li>

    <li>DNS (Domain Name System) - протокол системы доменных имен, используемый для преобразования доменных имен в IP-адреса и наоборот.</li>

    <li>TCP/IP (Transmission Control Protocol/Internet Protocol) - набор протоколов, используемых для обмена данными в сети Интернет.</li>

    <li>SSH (Secure Shell) - протокол безопасного удаленного доступа к компьютеру по сети.</li>

    <li>SNMP (Simple Network Management Protocol) - протокол управления сетью, используемый для мониторинга и управления устройствами в сети.</li>

    <li>DHCP (Dynamic Host Configuration Protocol) - протокол динамической настройки сетевых параметров, используемый для автоматической настройки IP-адресов и других сетевых параметров на компьютерах в сети.</li>
    </ol></li>

    <li><p>
    В чем различие методов GET и POST?
    </p>

    <p>
    Основное состоит в способе передачи данных:
    </p>

    <p>
    Метод GET отправляет скрипту всю собранную информацию как часть URL: <a href="http://www.komtet.ru/script.php?login=admin&amp;name=komtet">http://www.komtet.ru/script.php?login=admin&amp;name=komtet</a>
    </p>

    <p>
    Метод POST передает данные таким образом, что пользователь сайта уже не видит передаваемые скрипту данные: <a href="http://www.komtet.ru/script.php">http://www.komtet.ru/script.php</a>
    </p>

    <p>
    Кроме того:
    </p>

    <ul class="org-ul">
    <li>Количество информации, передаваемой методом GET через URL строку ограничено 2048 символами (минус служебная информация браузера);</li>

    <li>Страницу, сгенерированную методом GET, можно добавить в закладки и поделиться ссылкой;</li>

    <li>Sensitive data в таком открытом виде очевидно плохо влияют на безопасность;</li>

    <li>Метод POST в отличие от метода GET позволяет передавать запросу файлы;</li>

    <li>При использовании метода GET существует риск того, что поисковый робот может выполнить тот или иной открытый запрос.</li>

    <li>GET запросы кешируются, POST - нет</li>
    </ul></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-orgc4aaae4" class="outline-2">
    <h2 id="orgc4aaae4"><span class="section-number-2">5.</span> Клиент-серверное взаимодействие</h2>
    <div class="outline-text-2" id="text-5">
    <ul class="org-ul">
    <li><p>
    патч и пут отличия?
    </p>

    <ol class="org-ol">
    <li>Метод PATCH (патч) используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.</li>

    <li>Метод PUT (пут) используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.</li>
    </ol>

    <p>
    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.
    </p></li>

    <li><p>
    можно ли создать метод делит который будет создавать?
    </p>

    <p>
    Можно.
    </p></li>

    <li><p>
    есть ли опыт работы с девтулс?
    </p>

    <p>
    Есть.
    </p></li>

    <li>какие основные вкладки использовал ?

    <ul class="org-ul">
    <li>Elements</li>

    <li>Console</li>

    <li>Sources</li>

    <li>Network</li>

    <li>Application (Cookie, Local Storage, Session storage)</li>

    <li>Performance (детально)</li>

    <li>Lighthouse (отчет)</li>
    </ul></li>

    <li><p>
    что такое соап?
    </p>

    <p>
    SOAP – протокол обмена структурированными сообщениями.
    </p>

    <ul class="org-ul">
    <li>Нет специального стиля</li>

    <li>Только один тип запросов</li>

    <li>В body только XML</li>

    <li>SOAP. Протокол используется для обмена произвольными сообщениями в формате XML, а также для вызова процедур. SOAP ограничивает структуры ваших сообщений. Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML.</li>

    <li>SOAP использует WSDL. Он предоставляет поставщикам служб простой способ описания базового формата запросов, передаваемых их системам, независимо от применяемой реализации.</li>

    <li>SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, SMTP, TCP.</li>
    </ul></li>

    <li><p>
    как бы вы решили какой из REST или SOAP веб сервисов использовать?
    </p>

    <p>
    REST против SOAP можно перефразировать как &ldquo;Простота против Стандарта&rdquo;. В случае REST (простота) у вас будет скорость, расширяемость и поддержка многих форматов. В случае с SOAP у вас будет больше возможностей по безопасности (WS-security) и транзакционная безопасность (ACID).
    </p></li>

    <li><p>
    что такое WSDL?
    </p>

    <p>
    WSDL (англ. Web Services Description Language) - язык описания веб-сервисов и доступа к ним, основанный на языке XML.
    </p>

    <p>
    Каждый документ WSDL 1.1 можно разбить на следующие логические части:
    </p>

    <ul class="org-ul">
    <li>определение типов данных (types) - определение вида отправляемых и получаемых сервисом XML-сообщений</li>

    <li>элементы данных (message) - сообщения, используемые web-сервисом</li>

    <li>абстрактные операции (portType) - список операций, которые могут быть выполнены с сообщениями</li>

    <li>связывание сервисов (binding) - способ, которым сообщение будет доставлено</li>
    </ul></li>

    <li>в чем отличия REST и SOAP?

    <ul class="org-ul">
    <li>REST поддерживает различные форматы: text, JSON, XML, HTML, YAML;
    SOAP - только XML</li>

    <li>REST работает только по HTTP(S), а SOAP может работать с различными протоколами</li>

    <li>REST может работать с ресурсами. Каждый URL это представление какого-либо ресурса. SOAP работает с операциями, которые реализуют какую-либо бизнес логику с помощью нескольких интерфейсов</li>

    <li>SOAP на основе чтения не может быть помещена в кэш, а REST в этом случае может быть закэширован</li>

    <li>SOAP поддерживает SSL и WS-security, в то время как REST - только SSL</li>

    <li>SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но не один из ACID не совместим с двух фазовым коммитом.</li>
    </ul></li>

    <li>на коленке сделать примитивный джейсон</li>
    </ul>

    <div class="org-src-container">
    <pre class="src src-json">{
    <span style="color: #5317ac;">"&#1089;&#1090;&#1088;&#1086;&#1082;&#1072;"</span>: <span style="color: #2544bb;">"&#1055;&#1088;&#1080;&#1084;&#1077;&#1088; JSON"</span>,
    <span style="color: #5317ac;">"&#1094;&#1077;&#1083;&#1086;&#1077; &#1095;&#1080;&#1089;&#1083;&#1086;"</span>: <span style="color: #0000c0;">42</span>,
    <span style="color: #5317ac;">"&#1076;&#1088;&#1086;&#1073;&#1085;&#1086;&#1077; &#1095;&#1080;&#1089;&#1083;&#1086;"</span>: <span style="color: #0000c0;">3.14159</span>,
    <span style="color: #5317ac;">"&#1083;&#1086;&#1075;&#1080;&#1095;&#1077;&#1089;&#1082;&#1086;&#1077; &#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;"</span>: <span style="color: #0000c0;">true</span>,
    <span style="color: #5317ac;">"&#1084;&#1072;&#1089;&#1089;&#1080;&#1074;"</span>: [<span style="color: #0000c0;">1</span>, <span style="color: #0000c0;">2</span>, <span style="color: #0000c0;">3</span>, <span style="color: #0000c0;">4</span>, <span style="color: #0000c0;">5</span>],
    <span style="color: #5317ac;">"&#1086;&#1073;&#1098;&#1077;&#1082;&#1090;"</span>: {
    <span style="color: #5317ac;">"&#1082;&#1083;&#1102;&#1095;1"</span>: <span style="color: #2544bb;">"&#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;1"</span>,
    <span style="color: #5317ac;">"&#1082;&#1083;&#1102;&#1095;2"</span>: <span style="color: #2544bb;">"&#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;2"</span>
    },
    <span style="color: #5317ac;">"&#1085;&#1091;&#1083;&#1077;&#1074;&#1086;&#1077; &#1079;&#1085;&#1072;&#1095;&#1077;&#1085;&#1080;&#1077;"</span>: <span style="color: #0000c0;">null</span>
    }
    </pre>
    </div>

    <ul class="org-ul">
    <li><p>
    работал со сваггерами?
    </p>

    <p>
    Работал.
    </p></li>

    <li><p>
    идемпотентность
    </p>

    <p>
    Пример идемпотентного PATCH-запроса: Предположим, у нас есть ресурс &ldquo;пользователь&rdquo; с полями &ldquo;имя&rdquo; и &ldquo;электронная почта&rdquo;. Мы отправляем PATCH-запрос с обновленным значением только для поля &ldquo;имя&rdquo;. Если этот запрос применяется несколько раз, состояние пользователя на сервере не изменится после первого применения, поскольку в данном примере PATCH обновляет значение поля &ldquo;имя&rdquo;. Повторное применение запроса просто повторно обновит поле &ldquo;имя&rdquo; на то же значение. Это случай, когда PATCH настроен на обновление, а не на добавление. В таком случае PATCH идемпотентен.
    </p>

    <p>
    Пример неидемпотентного PATCH-запроса: Предположим, у нас есть ресурс &ldquo;счет&rdquo; с полем &ldquo;баланс&rdquo;. Мы отправляем PATCH-запрос с обновлением значения поля &ldquo;баланс&rdquo; на +10 единиц. Если этот запрос применяется несколько раз, состояние счета на сервере будет изменяться после каждого применения. Каждый запрос увеличивает баланс на 10 единиц, поэтому повторное применение запроса будет иметь различный эффект каждый раз. Это случай, когда PATCH настроен на добавление, а не на обновление. В этом случае PATCH является неидемпотентным, т.к. каждый повторный вызов меняет состояние ресурса (прибавляет +10 к балансу).
    </p>

    <p>
    Идемпотентными методами являются: GET, PUT, DELETE, HEAD и OPTIONS. POST и PATCH не входят в эту группу.
    </p></li>
    </ul>
    </div>
    </div>
    <div id="outline-container-org6d15cae" class="outline-2">
    <h2 id="org6d15cae"><span class="section-number-2">6.</span> Базы данных</h2>
    <div class="outline-text-2" id="text-6">
    <ul class="org-ul">
    <li><p>
    какие бд знаешь? расскажи про них
    </p>

    <p>
    Реляционные базы данных (RDBMS): Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.
    </p>

    <p>
    Нереляционные базы данных (NoSQL): Нереляционные базы данных предоставляют альтернативный подход к хранению данных и могут использовать различные модели, такие как документы, ключ-значение, столбцы или графы. Они часто применяются в случаях, когда требуется гибкость в структуре данных. Примеры включают MongoDB, Cassandra и Redis.
    </p>

    <p>
    Графовые базы данных: Графовые базы данных разработаны специально для хранения и обработки данных в виде графов. Они обычно используются для анализа связей и сетей. Примером такой базы данных является Neo4j.
    </p>

    <p>
    Встраиваемые базы данных: Эти базы данных интегрируются непосредственно в приложения и обычно работают локально. Пример - SQLite, который часто используется в мобильных приложениях.
    </p>

    <p>
    Ключ-значение хранилища (Key-Value Stores): Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.
    </p></li>

    <li><p>
    есть использования дестим ?
    </p>

    <p>
    ???
    </p></li>

    <li>какой оператор отвечает за сортировку ?</li>
    </ul>

    <div class="org-src-container">
    <pre class="src src-sql"> <span style="color: #5317ac;">GROUP</span> <span style="color: #5317ac;">BY</span>
    </pre>
    </div>

    <ul class="org-ul">
    <li><p>
    дмл операторы
    </p>

    <p>
    DDL &ldquo;Data Definition Language&rdquo; (язык определения данных), определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. DDL операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры DDL операторов включают CREATE, ALTER, DROP, TRUNCATE и RENAME. DDL операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых DDL операторов. DDL операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных.
    </p>

    <p>
    DML &ldquo;Data Manipulation Language&rdquo; (язык манипулирования данными) используется для манипулирования данными в базе данных. DML операторы используются для вставки, обновления и удаления данных в базе данных. Примерами DML операторов включают SELECT, INSERT, UPDATE, и DELETE. DML операторы выполняются немедленно и могут быть отменены с помощью оператора отката. DML операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных.
    </p>

    <p>
    В целом, DDL используется для определения и управления структурой базы данных, в то время как DML используется для манипулирования данными в базе данных. DDL утверждения являются постоянными и не могут быть отменены, в то время как DML утверждения выполняются немедленно и могут быть отменены. DDL утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют DML утверждения.
    </p></li>
    </ul>
    </div>
    </div>
    </div>
    <div id="postamble" class="status">
    <p class="author">Author: Maxim Rozhkov</p>
    <p class="date">Created: 2023-11-10 Пт 13:37</p>
    </div>
    </body>
    </html>
    2 changes: 0 additions & 2 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,5 @@
    #+title: IBS Interview

    #+TOC: headlines 2

    ** Теория тестирования

    + Как устроен жизненный цикл дефекта?
  11. abcwalk revised this gist Nov 10, 2023. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    #+title: IBS Interview

    #+TOC: headlines 1
    #+TOC: headlines 2

    ** Теория тестирования

  12. abcwalk revised this gist Nov 10, 2023. 1 changed file with 98 additions and 18 deletions.
    116 changes: 98 additions & 18 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,8 +1,10 @@
    #+title: IBS Interview

    #+TOC: headlines 1

    ** Теория тестирования

    + как устроен жизненный цикл дефекта?
    + Как устроен жизненный цикл дефекта?

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

    @@ -49,7 +51,7 @@

    | Параметры сравнения | Ошибка | Дефект |
    |-----------------------+---------------------------------------------------------------------------------------+--------------------------------------------------------------|
    | Определение | Баги — это проблемы, обнаруженные в процессе тестирования. | Методологии оперативной разработки и регулярная оценка кода. |
    | Определение | Баги — это проблемы, обнаруженные в процессе тестирования. | Методологии оперативной разработки и регулярная оцxенка кода. |
    | Был воспитан | Инженеры-испытатели. | Тестеры. |
    | Тип | Логические, алгоритмические и ресурсные ошибки. | Критические, основные, второстепенные и тривиальные. |
    | Причины возникновения | Отсутствующий код, неправильное кодирование или дополнительное кодирование. | Кодовая или логическая ошибка и неправильный ввод. |
    @@ -136,7 +138,6 @@

    Граница (или граничное значение) - это место где меняется поведение системы.


    1. Предугадывание ошибок

    Это техника создания гипотез о местах системы на основании документации и знаний о системе.
    @@ -219,7 +220,7 @@

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

    * Доступность к платформенным функциям: Нативные приложения могут использовать специфические API, доступные на платформе, такие как Apple Pay на iOS или службы уведомлений на Android. Браузерные приложения ограничены функциональностью, предоставляемой веб-браузером и его возможностями расширений.
    * Доступность к платформенным функциям: Нативные приложения могут использовать специфические API, доступные на платформе, такие как Apple Pay на IOS или службы уведомлений на Android. Браузерные приложения ограничены функциональностью, предоставляемой веб-браузером и его возможностями расширений.

    *Нативные*

    @@ -291,6 +292,7 @@
    4. Однородность: монолит может иметь однородную кодовую базу и среду разработки для всех компонентов.

    При монолитной архитектуре одно приложение включает в себя весь функционал.

    Например есть огромная банковская система.
    В рамках одной системы:
    - хранится вся информация о клиенте – физ лицах и юр лицах,
    @@ -300,6 +302,7 @@
    Если мы «выключим» монолит, мы выключим весь его функционал целиком.

    + опыт работы с тест логами есть? какие знаешь?

    *Kibana* предоставляет визуализацию результатов

    + что можно логировать?
    @@ -329,19 +332,29 @@

    * Снизу вверх (Bottom Up Integration)

    Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения (см. также Integration testing - Bottom Up)
    Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения

    * Сверху вниз (Top Down Integration)

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

    * Большой взрыв ("Big Bang" Integration)

    #+begin_quote
    Вид подхода к интеграционному тестированию, при котором элементы программного или аппаратного обеспечения, или и то и другое, собираются в компонент или в целую систему сразу, а не по этапам
    #+end_quote
    "Большой взрыв" (Big Bang Integration) - это метод интеграции программного обеспечения, при котором все компоненты или модули системы интегрируются одновременно. В этом подходе все изменения вносятся и тестируются в единой среде, и общая работоспособность системы проверяется в целом.

    Основные характеристики метода "Большой взрыв":

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

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

    3. *Тестирование в целом*: После интеграции производится тестирование системы в ее целом. Это включает в себя проверку общей работоспособности, взаимодействия компонентов и корректности функционирования системы в целом.

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

    5. *Менее предсказуемый процесс*: Такой метод интеграции может создать более сложный и менее предсказуемый процесс разработки, особенно если существуют неучтенные зависимости или непредвиденные проблемы.

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

    + клиент-серверное взаимодействие как происходит?

    @@ -361,7 +374,7 @@

    Важно отметить, что клиент и сервер могут взаимодействовать по различным протоколам, таким как HTTP, FTP, SMTP и т.д. Каждый протокол определяет свои правила и формат обмена данными.

    + какая разница между двухзвенной и трехзвенной ?
    + какая разница между двухзвенной и трехзвенной?

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

    @@ -375,11 +388,45 @@

    3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

    + разница между толстым и тонким клиентом?
    + разница между толстым и тонким клиентом?

    1. Толстый клиент (Fat Client):

    - *Локальная обработка:*
    - *Определение:* Толстый клиент имеет значительную локальную обработку и хранение данных.
    - *Характеристики:* Значительная часть бизнес-логики и функциональности находится на клиентской стороне.

    - *Графический интерфейс:*
    - *Примеры:* Нативные приложения, устанавливаемые на устройстве пользователя (например, десктопные приложения).

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

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

    2. Тонкий клиент (Thin Client):

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

    - *Графический интерфейс:*
    - *Примеры:* Веб-приложения, которые работают в браузере.

    - *Объем передаваемых данных:*
    - *Коммуникация:* Взаимодействует с сервером для получения данных и обновлений, пересылает минимальные данные для отображения и ввода.

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

    Тонкий клиент, толстый сервер – не только данные, но и логика их обработки и бизнес-данные хранятся на сервере.
    Общие соображения:

    - Выбор между толстым и тонким клиентом зависит от требований проекта, характера приложения и сетевой инфраструктуры.

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

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

    + какие протоколы знаешь?

    @@ -429,11 +476,11 @@

    + патч и пут отличия?

    1. Метод PATCH (патч) используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.
    1. Метод PATCH (патч) используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.

    2. Метод PUT (пут) используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.
    2. Метод PUT (пут) используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.

    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.
    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.

    + можно ли создать метод делит который будет создавать?

    @@ -475,6 +522,39 @@

    * SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, SMTP, TCP.

    + как бы вы решили какой из REST или SOAP веб сервисов использовать?

    REST против SOAP можно перефразировать как "Простота против Стандарта". В случае REST (простота) у вас будет скорость, расширяемость и поддержка многих форматов. В случае с SOAP у вас будет больше возможностей по безопасности (WS-security) и транзакционная безопасность (ACID).

    + что такое WSDL?

    WSDL (англ. Web Services Description Language) - язык описания веб-сервисов и доступа к ним, основанный на языке XML.

    Каждый документ WSDL 1.1 можно разбить на следующие логические части:

    * определение типов данных (types) - определение вида отправляемых и получаемых сервисом XML-сообщений

    * элементы данных (message) - сообщения, используемые web-сервисом

    * абстрактные операции (portType) - список операций, которые могут быть выполнены с сообщениями

    * связывание сервисов (binding) - способ, которым сообщение будет доставлено

    + в чем отличия REST и SOAP?

    - REST поддерживает различные форматы: text, JSON, XML, HTML, YAML;
    SOAP - только XML

    - REST работает только по HTTP(S), а SOAP может работать с различными протоколами

    - REST может работать с ресурсами. Каждый URL это представление какого-либо ресурса. SOAP работает с операциями, которые реализуют какую-либо бизнес логику с помощью нескольких интерфейсов

    - SOAP на основе чтения не может быть помещена в кэш, а REST в этом случае может быть закэширован

    - SOAP поддерживает SSL и WS-security, в то время как REST - только SSL

    - SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но не один из ACID не совместим с двух фазовым коммитом.

    + на коленке сделать примитивный джейсон

    #+BEGIN_SRC json
    @@ -530,8 +610,8 @@

    + дмл операторы

    DDL определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. DDL операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры DDL операторов включают CREATE, ALTER, DROP, TRUNCATE и RENAME. DDL операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых DDL операторов. DDL операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных.
    DDL "Data Definition Language" (язык определения данных), определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. DDL операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры DDL операторов включают CREATE, ALTER, DROP, TRUNCATE и RENAME. DDL операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых DDL операторов. DDL операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных.

    DML используется для манипулирования данными в базе данных. DML операторы используются для вставки, обновления и удаления данных в базе данных. Примерами DML операторов включают SELECT, INSERT, UPDATE, и DELETE. DML операторы выполняются немедленно и могут быть отменены с помощью оператора отката. DML операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных.
    DML "Data Manipulation Language" (язык манипулирования данными) используется для манипулирования данными в базе данных. DML операторы используются для вставки, обновления и удаления данных в базе данных. Примерами DML операторов включают SELECT, INSERT, UPDATE, и DELETE. DML операторы выполняются немедленно и могут быть отменены с помощью оператора отката. DML операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных.

    В целом, DDL используется для определения и управления структурой базы данных, в то время как DML используется для манипулирования данными в базе данных. DDL утверждения являются постоянными и не могут быть отменены, в то время как DML утверждения выполняются немедленно и могут быть отменены. DDL утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют DML утверждения.
  13. abcwalk revised this gist Nov 10, 2023. 1 changed file with 20 additions and 4 deletions.
    24 changes: 20 additions & 4 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -31,13 +31,29 @@

    + что такое дефект / баг?

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

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

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

    В общем, оба термина используются для обозначения проблем в программном обеспечении, которые требуют внимания и исправления. Независимо от использования термина, цель заключается в том, чтобы выявлять и устранять недочеты для обеспечения качественного программного продукта.
    Термин «ошибка» часто используется для обозначения проблемы, когда программное обеспечение ведет себя не так, как предполагалось или ожидалось. Дефект — это проблема, влияющая на производительность, удобство использования или надежность программного обеспечения. Дефект может быть связан с проблемой дизайна программного обеспечени

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

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

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

    | Параметры сравнения | Ошибка | Дефект |
    |-----------------------+---------------------------------------------------------------------------------------+--------------------------------------------------------------|
    | Определение | Баги — это проблемы, обнаруженные в процессе тестирования. | Методологии оперативной разработки и регулярная оценка кода. |
    | Был воспитан | Инженеры-испытатели. | Тестеры. |
    | Тип | Логические, алгоритмические и ресурсные ошибки. | Критические, основные, второстепенные и тривиальные. |
    | Причины возникновения | Отсутствующий код, неправильное кодирование или дополнительное кодирование. | Кодовая или логическая ошибка и неправильный ввод. |
    | Предотвращени | Мы используем фундаментальные и точные подходы к разработке программного обеспечения. | Использование фундаментальных и точных подходов к разработке программного обеспечения. |

    + отличия чек-лист и тест-кейс?

  14. abcwalk revised this gist Nov 10, 2023. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -31,11 +31,11 @@

    + что такое дефект / баг?

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

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

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

    В общем, оба термина используются для обозначения проблем в программном обеспечении, которые требуют внимания и исправления. Независимо от использования термина, цель заключается в том, чтобы выявлять и устранять недочеты для обеспечения качественного программного продукта.

  15. abcwalk revised this gist Nov 10, 2023. 1 changed file with 4 additions and 8 deletions.
    12 changes: 4 additions & 8 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -31,17 +31,13 @@

    + что такое дефект / баг?

    - *Баг (Bug)*:
    Простыми словами, термины "баг" и "дефект" часто используются взаимозаменяемо, и между ними нет строгого различия. Однако в некоторых контекстах и организациях разработки программного обеспечения они могут иметь небольшие отличия:

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

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

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

    В целом, можно сказать, что баг является частью дефекта. Баг относится к конкретному несоответствию или неисправности, тогда как дефект может относиться к более широкому кругу проблем. Тем не менее, в реальной практике использования терминов "баг" и "дефект" часто встречаются в качестве синонимов, и разницу между ними можно считать несущественной.
    В общем, оба термина используются для обозначения проблем в программном обеспечении, которые требуют внимания и исправления. Независимо от использования термина, цель заключается в том, чтобы выявлять и устранять недочеты для обеспечения качественного программного продукта.

    + отличия чек-лист и тест-кейс?

  16. abcwalk revised this gist Nov 10, 2023. 1 changed file with 24 additions and 10 deletions.
    34 changes: 24 additions & 10 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -33,29 +33,44 @@

    - *Баг (Bug)*:

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

    - *Дефект (Defect)*:

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

    В целом, можно сказать, что баг является частью дефекта. Баг относится к конкретному несоответствию или неисправности, тогда как дефект может относиться к более широкому кругу проблем. Тем не менее, в реальной практике использования терминов "баг" и "дефект" часто встречаются в качестве синонимов, и разницу между ними можно считать несущественной.

    + отличия чек-лист и тест-кейс
    + отличия чек-лист и тест-кейс?

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

    Цель чек-листа – не пропустить ни одной важной детали в процессе тестирования.
    1. *Назначение*:
    - *Тест-кейс*: Это документ, который содержит описание шагов, которые тестировщик должен выполнить, и ожидаемых результатов для проверки определенной функциональности или сценария.
    - *Чек-лист*: Это список пунктов или шагов, который помогает проверить выполнение определенных задач, процедур или критериев, но не обязательно предоставляет подробное описание ожидаемых результатов.

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

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

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

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

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

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

    + при каких условиях будешь писать чек-лист, а при каких тест-кейс?

    @@ -95,8 +110,7 @@

    + есть ли опыт разработки тест данных

    Для боьших объемов нет.

    Для больших объемов нет.

    ** Техники тест-дизайна

  17. abcwalk revised this gist Nov 10, 2023. 1 changed file with 8 additions and 6 deletions.
    14 changes: 8 additions & 6 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -31,13 +31,15 @@

    + что такое дефект / баг?

    1. **Баг (Bug)**:
    - Обычно термин "баг" используется для обозначения ошибки, дефекта или неисправности в программном обеспечении, которое ведет к некорректному или нежелательному поведению программы.
    - Баг часто связан с техническими аспектами кода, такими как ошибка в программировании, неправильное использование API, несоответствие спецификациям и т. д.
    - *Баг (Bug)*:

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

    - *Дефект (Defect)*:

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

    В целом, можно сказать, что баг является частью дефекта. Баг относится к конкретному несоответствию или неисправности, тогда как дефект может относиться к более широкому кругу проблем. Тем не менее, в реальной практике использования терминов "баг" и "дефект" часто встречаются в качестве синонимов, и разницу между ними можно считать несущественной.

  18. abcwalk revised this gist Nov 10, 2023. 1 changed file with 14 additions and 36 deletions.
    50 changes: 14 additions & 36 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@

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

    * Обнаружение: Дефект может быть обнаружен тестировщиком, пользователем или автоматическим инструментом.
    * Обнаружение и Локализация: Дефект может быть обнаружен тестировщиком, пользователем или автоматическим инструментом.

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

    @@ -22,47 +22,25 @@

    * Закрытие: Если дефект был успешно исправлен и прошел проверку, он будет закрыт. Если дефект является невоспроизводимым или не может быть исправлен, он может быть помечен как "не устранимый" и не будет закрыт.

    + что такое дефект / баг?

    Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! И когда пользователь натыкается на ошибочный код, происходит сбой.

    * Дефект

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

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

    Ошибка (error, mistake) — действие человека, приводящее к некорректным результатам.

    Сбой (interruption) или отказ (failure) — отклонение поведения системы от ожидаемого.
    Сбой — самоустраняющийся или однократный отказ, устраняемый незначительным вмешательством.
    Отказ — событие, заключающееся в нарушении работоспособного состояния приложения.
    1. Баг обнаружен и локализован
    2. Создание баг-репорта
    3. Анализ/Приоритезация бага
    4. Устранения бага
    5. Тестирование (ре-тест)
    6. Закрытие (При устранении бага, баг закрывается, либо отправляется на доработку)

    Таким образом, разработчик может совершить ошибку, написав неверный код. При выполнении функций приложения эта ошибка приводит к дефекту, который должен обнаружить тестировщик. Дефект может быть причиной сбоя или отказа.

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

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

    Любой дефект, обнаруженный в приложении или системе, должен быть задокументирован и передан разработчику либо другому ответственному специалисту для ознакомления и исправления. Документ, с помощью которого о дефекте становится известно миру или отдельному специалисту, называется отчётом о дефекте. Есть несколько определений этого понятия.

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

    Отчёт о дефекте — документ, описывающий и приоритизирующий обнаруженный дефект, а также содействующий его устранению.
    + что такое дефект / баг?

    Баг (bug): Этот термин обычно используется для обозначения ошибки или неисправности в программном обеспечении, которая приводит к неправильной работе или несоответствию ожиданиям. Баги обычно связаны с проблемами и недостатками в коде, логике приложения или его функциональности.
    1. **Баг (Bug)**:
    - Обычно термин "баг" используется для обозначения ошибки, дефекта или неисправности в программном обеспечении, которое ведет к некорректному или нежелательному поведению программы.
    - Баг часто связан с техническими аспектами кода, такими как ошибка в программировании, неправильное использование API, несоответствие спецификациям и т. д.

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

    В целом, можно сказать, что баг является частью дефекта. Баг относится к конкретному несоответствию или неисправности, тогда как дефект может относиться к более широкому кругу проблем. Тем не менее, в реальной практике использования терминов "баг" и "дефект" часто встречаются в качестве синонимов, и разницу между ними можно считать несущественной.

    1. Баг обнаружен
    2. Баг локализован
    3. Создание баг-репорта
    4. Реализация устранения бага
    5. После устранения бага, баг отправляется в тетирование: при устранении бага, баг закрывается, либо отправляется на доработку.
    Если баг не удается устранить или он не воспроизводится то он помечается соответствующим статусом.

    + отличия чек-лист и тест-кейс

    Чек-лист — это список проверок, которые помогают тестировщику протестировать приложение или отдельные функции. Основная цель чеклиста состоит в том, чтобы вы не забыли проверить всё, что планировали (нетривиальное поведение приложения или сложная проверка, результат которой важно отметить уже сейчас, чтобы не забыть)
  19. abcwalk revised this gist Nov 9, 2023. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    #+title: Ibs Interview
    #+title: IBS Interview

    ** Теория тестирования

  20. abcwalk revised this gist Nov 9, 2023. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -518,7 +518,9 @@

    + какой оператор отвечает за сортировку ?

    src_sql[:exports code]{GROUP BY}
    #+BEGIN_SRC sql :exports code
    GROUP BY
    #+END_SRC

    + дмл операторы

  21. abcwalk revised this gist Nov 9, 2023. 2 changed files with 0 additions and 177 deletions.
    62 changes: 0 additions & 62 deletions org-basics.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,62 +0,0 @@
    #+title: Org Mode Basics In Doom Emacs
    #+description: An org document to demonstrate org mode on video.
    #+author: Maxim Rozhkov

    * A new headline
    ** Level 2 headline
    *** Level 3 headline
    **** Level 4 headline
    ***** Level 5 headline
    ****** Level 6 headline
    ******* Level 7 headline
    * New Level headline
    M-x org-toggle-heading
    M-x org-toggle-item
    + Unordered list item one
    + Unordered list item two
    - Dash instead of +


    1. Ordered list item one.
    2. Ordered list item two.
    3.
    4.
    5.

    Snippets
    #!/usr/bin/env bash
    Thu Nov 9 15:03:27 2023
    * TODO
    ** TODO example one
    ** PROJ example two
    ** LOOP
    ** STRT
    ** WAIT
    ** HOLD
    ** IDEA
    ** DONE
    ** KILL
    ** [ ]
    ** [-]
    ** [?]
    ** [X]
    ** OKAY
    ** YES
    ** NO
    SCHEDULED: <2023-11-09 Чт 21:00-23:00>
    * Checkboxes: - [ ] [2/3] [66%]
    - [X] task 1
    - [ ] task 2
    - [X] C-c C-c
    * Tables

    | Name | Age | Phone |
    |-------------+----------------+-------|
    | Alonzo | Monzo | Gonzo |
    | okay | let'go | write |
    | someeeeeeee | looooonngggggg | cell |


    | Another | Table |
    |---------+-------|
    | | |
    115 changes: 0 additions & 115 deletions q&a.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,115 +0,0 @@
    # Список вопросов с ответами для собеседования по Java

    ## Типы данных, переменные, операторы, циклы, массивы

    > 1. Сколько ключевых слов зарезервировано языком, что это за слова, какие из них не используются?
    50, два из них не используются: const, goto;

    Для запоминания это:
    - Примитивы (byte, short, int, long, char, float, double, boolean)
    - Циклы и ветвления (if, else, switch, case, default, while, do, break, continue, for)
    - Исключения (try, catch, finally, throw, throws)
    - Области видимости (private, protected, public)
    - Объявление \ Импорт (import, package, class, interface, extends, implements, static, final, void, abstract, native)
    - Создание \ Возврат \ Вызов (new, return, this, super)
    - Многопоточность (synchronized, volatile)
    instanceof, enum, assert, transient, strictfp, const, goto

    > 2. Из каких символов может состоять имя переменной (корректный идентификатор)?
    Имя или идентификатор переменной — это последовательность из строчных и заглавных латинских букв, цифр, а также символов `$` и `_`. Имя переменной **может начинаться с любого из перечисленных символов, кроме цифры**.

    Технически возможно начать имя переменной также с `$` или `_`, однако это запрещено соглашением по оформлению кода в Java (Java Code Conventions). Кроме того, символ доллара `$`, по соглашению, никогда не используется вообще. В соответствии с соглашением имя переменной должно начинаться именно с маленькой буквы (с заглавной буквы начинаются имена классов). Пробелы при именовании переменных не допускаются.

    > 3. Что значит слово `инициализация`?
    **Инициализация** (от англ. _initialization_, инициирование) — создание, активация, подготовка к работе, определение параметров. Приведение программы или устройства в состояние готовности к использованию. С точки зрения Java — выделение памяти под объект, например при создании MyClass myClass = new MyClass(). Таким образом будет выделена память под объект myClass (он будет инициализирован). Без инициализации (new MyClass()) запись MyClass myClass; просто резервирует имя (объявляется переменная myClass типа MyClass).

    > 4. На какие основные группы можно поделить типы данных?
    > 5. Какие примитивные типы вы знаете?
    В языке программирования Java типы данных можно разделить на несколько основных групп:

    1. **Примитивные типы данных (Primitive Data Types)**:
    - `int`: Целые числа.
    - `double`: Числа с плавающей точкой двойной точности.
    - `float`: Числа с плавающей точкой одинарной точности.
    - `char`: Одиночные символы (UTF-16 кодировка).
    - `boolean`: Логические значения (истина или ложь).
    - `byte`: Байты (целые числа от -128 до 127).
    - `short`: Короткие целые числа.
    - `long`: Длинные целые числа.

    2. **Ссылочные типы данных (Reference Data Types)**:
    - `class`: Определенные пользователем классы.
    - `interface`: Интерфейсы.
    - `array`: Массивы.
    - `enum`: Перечисления.
    - `String`: Строки (особый класс для работы со строками).

    3. **Обобщенные типы (Generic Types)**: Включают параметризованные классы и методы для обобщенного программирования.

    4. **Массивы (Arrays)**: Массивы могут быть использованы для хранения элементов одного типа данных.

    5. **Пользовательские типы данных (User-Defined Data Types)**: Эти типы данных создаются пользователями и включают в себя классы и интерфейсы, которые они определяют в своих программах.

    6. **Типы данных для работы с потоками (Stream Types)**: В Java есть типы данных, связанные с работой с потоками данных, такие как `InputStream` и `OutputStream`, используемые для чтения и записи данных.

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

    > 6. Что вы знаете о преобразовании примитивных типов данных, есть ли потеря данных, можно ли преобразовать логический тип?
    Преобразование может быть неявным и явным (приведение типов). Неявное преобразование может выполняться если:

    1. типы совместимы (например — оба целочисленные)
    2. размер «принимающего» типа больше чем у того, который преобразуется (так называемое «преобразование с расширением»)

    ```java
    int a = 123454;
    double b = a; //неявное преобразование - преобразование с расширением
    ```

    Явное преобразование имеет `вид переменная_нового_типа = (новый_тип) имя переменной;`

    ```java
    int a;
    byte b = (byte) a; //b будет остатком от деления a на диапазон byte, может быть потеря данных
    ```

    Примеры:
    ```java
    public static void typeConverterExample() {
    long a = 100L;
    double b = 300.0;
    Object ab = a + b;
    System.out.println(ab.getClass().getName() + " value: " + ab); //java.lang.Double value: 400.0

    double c = 1000.05;
    long d = 1000;
    Object cd = c+d;
    System.out.println(cd.getClass().getName() +" value: " + cd);//java.lang.Double value: 2000.05
    }

    public static void typeNarrowing() {
    int a0 = 64;
    int a = 257;
    int a2 = 126;
    int a3 = 129;
    byte b0 = (byte) a0;
    byte b = (byte) a;
    byte b2 = (byte) a2;
    byte b3 = (byte) a3;
    System.out.println(b0+ " " + b + " " + b2 + " " + b3); //64 1 126 -127

    double c = 56.9876;
    int d = (int) c;
    System.out.println(d); //56

    long e = 1000L;
    float f = (float) e;
    System.out.println(f); //1000.0
    }
    ```

    TEST
  22. abcwalk revised this gist Nov 9, 2023. 1 changed file with 449 additions and 13 deletions.
    462 changes: 449 additions & 13 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -1,30 +1,30 @@
    #+title: Ibs Interview

    ** Теория тестирования

    + как устроен жизненный цикл дефекта?

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

    1. Обнаружение: Дефект может быть обнаружен тестировщиком, пользователем или автоматическим инструментом.

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

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

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

    5. Устранение: Разработчик исправляет дефект, внося соответствующие изменения в код.
    * Анализ/Приоретизация: Разработчик анализирует и исследует дефект, чтобы понять его причину и дать рекомендации по его устранению.

    6. Тестирование: Исправленный дефект проходит тестирование, чтобы убедиться, что проблема была успешно устранена и не вызвала новых проблем.
    * Устранение: Разработчик исправляет дефект, внося соответствующие изменения в код.

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

    8. Закрытие: Если дефект был успешно исправлен и прошел проверку, он будет закрыт. Если дефект является невоспроизводимым или не может быть исправлен, он может быть помечен как "не устранимый" и не будет закрыт.
    * Проверка: Дефект проверяется и подтверждается тестировщиком или другим ответственным лицом.

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

    + что такое дефект / баг?

    Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! И когда пользователь натыкается на ошибочный код, происходит сбой.
    Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! И когда пользователь натыкается на ошибочный код, происходит сбой.

    * Дефект

    @@ -56,38 +56,474 @@

    В целом, можно сказать, что баг является частью дефекта. Баг относится к конкретному несоответствию или неисправности, тогда как дефект может относиться к более широкому кругу проблем. Тем не менее, в реальной практике использования терминов "баг" и "дефект" часто встречаются в качестве синонимов, и разницу между ними можно считать несущественной.

    1. Баг обнаружен
    2. Баг локализован
    3. Создание баг-репорта
    4. Реализация устранения бага
    5. После устранения бага, баг отправляется в тетирование: при устранении бага, баг закрывается, либо отправляется на доработку.
    Если баг не удается устранить или он не воспроизводится то он помечается соответствующим статусом.

    + отличия чек-лист и тест-кейс

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

    Цель чек-листа – не пропустить ни одной важной детали в процессе тестирования.

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

    В тест-кейсе содержится подробное описание шагов и действий, которые тестировщик должен выполнить для тестирования какой-то одной части функционала, критерии прохождения тестов.

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

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

    + при каких условиях будешь писать чек-лист, а при каких тест-кейс?
    + как ты понимаешь что достаточно тест кейсов и чек листов

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

    #+BEGIN_QUOTE
    Как утверждает Алексей Баранцев "... простейший чек-лист -- это список тест-кейсов." Я с ним согласен. Т.е. чек-лист лишь перечисление тестовых прецедентов, которые могут быть описаны, а могут и не быть. Так вот... тестовые прецеденты должны постоянно поддерживаться в актуальном состоянии. А поскольку тестовые прецеденты более детальны, чем чек-листы, то и на их поддержание требуется больше ресурсов.

    Поэтому мое мнение таково: если хватает ресурсов, то можно иметь описание тестовых прецедентов, если нет - нужно обходиться чек-листами. Они, по крайней мере, позволят систематизировать тестирование. Я в фирме ввел как правило "имение как минимум чек-листов".
    #+END_QUOTE

    - Насколько сотрудники вовлечены чтобы понять тест-кейсы?

    - Насколько сложный продукт?

    - Придется ли в будушем воспроизводить эти действия? Или это на один раз?

    - Универсальность чек-листов сможет покрыть другой функционал? Или это плохая практика?

    + как ты понимаешь что достаточно тест кейсов и чек листов?

    * Когда уже нет новых идей для тестов
    * Закончилось время на тестирование

    Чтобы понять, достаточно ли тест-кейсов и чек-листов для проведения тестирования, необходимо учесть несколько факторов:

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

    * Покрытие различных сценариев: Убедитесь, что тест-кейсы и чек-листы учитывают различные сценарии использования системы. Рассмотрите разные варианты ввода данных, комбинации функций и возможные пути выполнения операций. Если все сценарии не учтены, может потребоваться больше тестов.

    * Распределение ошибок: Проанализируйте результаты предыдущих тестов, чтобы определить, в каких областях системы обнаруживались наибольшее количество ошибок. Если в определенных областях системы было много проблем, может потребоваться создать дополнительные тест-кейсы для улучшения покрытия.

    * Временные ограничения: Учтите ограничения по времени и ресурсам, которыми вы располагаете для проведения тестирования. Если у вас есть ограниченное время для тестирования, вы можете потребовать более точечных и фокусированных тест-кейсов.

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


    + есть ли опыт разработки тест данных

    Для боьших объемов нет.


    ** Техники тест-дизайна

    + техники тест дизайна какие знаешь?

    1. Классы эквивалентности

    При любом значении из одного класса эквивалентности поведение системы должно быть одинаковым.

    2. Граничные значения

    Граница (или граничное значение) - это место где меняется поведение системы.


    1. Предугадывание ошибок

    Это техника создания гипотез о местах системы на основании документации и знаний о системе.
    Обычно с ее помощью создаются негативные кейсы.

    Предугадывать можно:

    * По опыту
    * С помощью знаний о работе системы
    * С помощью знаний о работе ПО
    * По документации
    * По статистике (багов, тестов, использования)

    2. Причина-следствие

    3. Pairwise Testing

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

    4. Исследовательское тестирование и туры Виттакера

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

    Когда применяется:

    * Нужно обеспечить быструю обратную связь
    * Нужно быстро изучить продукт
    * Для разнообразия тестирования
    * Нужно обнаружить и локализовать дефект

    5. Таблица принятия решений

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


    + эффективность тест-кейсов

    Когда переписываешь тест кейсы 10 раз в месяц

    * Слишком много информации
    * Подробные предусловия
    * Дубли
    * Дополнительные материалы
    * Лишние проверки

    + как можно уменьшить количество тестов?

    * Объеденить позитивные тесты

    * Выкинуть дубли

    * Проверить функциональность 1 раз, а не 10.

    + составлял ли матрицу покрытия?

    Карта трассируемости это тестирование требований. На проекте не было времени этим заниматься.

    + когда не надо схлопывать тесты?

    Когда итоговый тест получается слишком сложным для восприятия.
    Или когла смешиваем разные функциональности

    + занимался ли тестированием требований/спецификаций?

    Нет.

    ** Тестирование мобильных приложений

    + нативные и браузерные приложения в чем отличия?

    * Нативные приложения устанавливаются непосредственно на устройство пользователя

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

    * Интерфейс и возможности: Нативные приложения могут использовать все функции и возможности устройства, на котором они запущены, такие как камера, геолокация, доступ к контактам и т. д. Браузерные приложения ограничены функциями и возможностями, предоставляемыми веб-браузером и доступными через JavaScript API.

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

    * Доступность к платформенным функциям: Нативные приложения могут использовать специфические API, доступные на платформе, такие как Apple Pay на iOS или службы уведомлений на Android. Браузерные приложения ограничены функциональностью, предоставляемой веб-браузером и его возможностями расширений.

    *Нативные*

    Плюсы

    * Наличие гайдлайнов
    * Прямое подключение всех фишек ОС
    * Работа без интернет

    Минусы

    * Соответствие гайдлайнам
    * Дорого

    *Web*

    Плюсы

    * Не нужно обновлять
    * Не нужно устанавливать

    Минусы

    * Нужен интернет
    * Низкая производительность
    * Нет доступа к «железу» девайса

    + специфические тестирования мобилок знаешь?

    1. Тестирование на разных платформах

    2. Адаптивное тестирование

    3. Тестирование в разных сетях

    4. Тестирование поведения в фоновом режиме

    5. Тестирование использования ресурсов устройства

    6. Тестирования пользовательского интерфейса (UI)

    7. Интернационализация и локализация (i18n) (l10n)

    8. Тестирование удобства использования

    9. Тестирование производительности

    10. Тестирование энергопотребления

    11. Тестирование безопасности

    12. Тестирование обновления

    13. Push-нотификации

    14. Конфигурационное тестирование

    ** Тестирование бэкенда

    + знаешь что такое монолитный бекенд?

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

    Монолитный бэкенд имеет следующие особенности:

    1. Одна единица разработки и развертывания: все компоненты связаны вместе и разрабатываются, тестируются и развертываются как единое приложение.
    2. Менее гибкое масштабирование: потому что все функции приложения находятся в одном монолите, его масштабирование может быть сложным. Если требуется масштабирование, то необходимо масштабировать всю систему, даже если только одна функция нуждается в дополнительных ресурсах.
    3. Сильная связность компонентов: все компоненты внутри монолитного бэкенда имеют сильную связность друг с другом, и изменение одного компонента может затронуть другие компоненты.
    4. Однородность: монолит может иметь однородную кодовую базу и среду разработки для всех компонентов.

    При монолитной архитектуре одно приложение включает в себя весь функционал.
    Например есть огромная банковская система.
    В рамках одной системы:
    - хранится вся информация о клиенте – физ лицах и юр лицах,
    - все операции по клиенту, как операционные так и финансовые
    - все заявки которые оформляет клиент
    - в ней работают все операторы банка, осуществляют звонки, обмен сообщениями в чате и тд и тп.
    Если мы «выключим» монолит, мы выключим весь его функционал целиком.

    + опыт работы с тест логами есть? какие знаешь?
    *Kibana* предоставляет визуализацию результатов

    + что можно логировать?

    * вызовы методов, тело, параметры, ответ
    * ошибки пользовательские и серверные
    * запросы в БД
    * служебная и вспомогательная информация об изменениях в системе

    + интеграционное тестирование что знаешь?

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

    Уровни интеграционного тестирования:

    * Компонентный интеграционный уровень (Component Integration testing)

    Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

    * Системный интеграционный уровень (System Integration Testing)

    Проверяется взаимодействие между разными системами после проведения системного тестирования.

    + какие подходы к тестированию интеграции знаешь? (подход большего взрыва)

    + клиентсерверное взаимодействие как происходит?
    Подходы к интеграционному тестированию:

    * Снизу вверх (Bottom Up Integration)

    Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения (см. также Integration testing - Bottom Up)

    * Сверху вниз (Top Down Integration)

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

    * Большой взрыв ("Big Bang" Integration)

    #+begin_quote
    Вид подхода к интеграционному тестированию, при котором элементы программного или аппаратного обеспечения, или и то и другое, собираются в компонент или в целую систему сразу, а не по этапам
    #+end_quote

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

    + клиент-серверное взаимодействие как происходит?

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

    Вот общая схема клиент-серверного взаимодействия:

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

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

    3. Сервер обрабатывает запрос и генерирует ответ. В зависимости от запроса, сервер может выполнять различные операции, обращаться к базе данных, обрабатывать данные и генерировать результат.

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

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

    Важно отметить, что клиент и сервер могут взаимодействовать по различным протоколам, таким как HTTP, FTP, SMTP и т.д. Каждый протокол определяет свои правила и формат обмена данными.

    + какая разница между двухзвенной и трехзвенной ?

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

    Такая модель показала свою неэффективность ввиду того, что при активной работе с таблицами БД возникает большая нагрузка на сеть.

    Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом:

    1. Представление данных — на стороне клиента.

    2. Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).

    3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

    + разница между толстым и тонким клиентом?

    Толстый клиент, тонкий сервер – общие данные хранятся на сервере, а логика их обработки и бизнес-данные хранятся на клиентской машине.

    Тонкий клиент, толстый сервер – не только данные, но и логика их обработки и бизнес-данные хранятся на сервере.

    + какие протоколы знаешь?

    1. HTTP (Hypertext Transfer Protocol) - протокол передачи гипертекста, используемый в веб-браузерах и веб-серверах для обмена данными.

    2. FTP (File Transfer Protocol) - протокол передачи файлов, используемый для обмена файлами между клиентом и сервером.

    3. SMTP (Simple Mail Transfer Protocol) - протокол передачи электронной почты, используемый для отправки почты от клиента к серверу и между серверами.

    4. POP3 (Post Office Protocol version 3) - протокол получения электронной почты, используемый для получения почты с сервера на клиентскую программу.

    5. IMAP (Internet Message Access Protocol) - протокол доступа к электронной почте, позволяющий клиенту получать письма с сервера и управлять ими на сервере.

    6. DNS (Domain Name System) - протокол системы доменных имен, используемый для преобразования доменных имен в IP-адреса и наоборот.

    7. TCP/IP (Transmission Control Protocol/Internet Protocol) - набор протоколов, используемых для обмена данными в сети Интернет.

    8. SSH (Secure Shell) - протокол безопасного удаленного доступа к компьютеру по сети.

    9. SNMP (Simple Network Management Protocol) - протокол управления сетью, используемый для мониторинга и управления устройствами в сети.

    10. DHCP (Dynamic Host Configuration Protocol) - протокол динамической настройки сетевых параметров, используемый для автоматической настройки IP-адресов и других сетевых параметров на компьютерах в сети.

    + В чем различие методов GET и POST?

    Основное состоит в способе передачи данных:

    Метод GET отправляет скрипту всю собранную информацию как часть URL: http://www.komtet.ru/script.php?login=admin&name=komtet

    Метод POST передает данные таким образом, что пользователь сайта уже не видит передаваемые скрипту данные: http://www.komtet.ru/script.php

    Кроме того:

    - Количество информации, передаваемой методом GET через URL строку ограничено 2048 символами (минус служебная информация браузера);

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

    - Sensitive data в таком открытом виде очевидно плохо влияют на безопасность;

    - Метод POST в отличие от метода GET позволяет передавать запросу файлы;

    - При использовании метода GET существует риск того, что поисковый робот может выполнить тот или иной открытый запрос.

    - GET запросы кешируются, POST - нет

    ** Клиент-серверное взаимодействие

    + патч и пут отличия?

    1. Метод PATCH (патч) используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.

    2. Метод PUT (пут) используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.

    Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.

    + можно ли создать метод делит который будет создавать?

    Можно.

    + есть ли опыт работы с девтулс?

    Есть.

    + какие основные вкладки использовал ?

    - Elements

    - Console

    - Sources

    - Network

    - Application (Cookie, Local Storage, Session storage)

    - Performance (детально)

    - Lighthouse (отчет)

    + что такое соап?

    SOAP – протокол обмена структурированными сообщениями.

    * Нет специального стиля

    * Только один тип запросов

    * В body только XML

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

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

    * SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, SMTP, TCP.

    + на коленке сделать примитивный джейсон

    #+BEGIN_SRC json
    {
    "строка": "Пример JSON",
    "целое число": 42,
    "дробное число": 3.14159,
    "логическое значение": true,
    "массив": [1, 2, 3, 4, 5],
    "объект": {
    "ключ1": "значение1",
    "ключ2": "значение2"
    },
    "нулевое значение": null
    }
    #+END_SRC

    + работал со сваггерами?

    Работал.

    + идемпотентность

    Пример идемпотентного PATCH-запроса: Предположим, у нас есть ресурс "пользователь" с полями "имя" и "электронная почта". Мы отправляем PATCH-запрос с обновленным значением только для поля "имя". Если этот запрос применяется несколько раз, состояние пользователя на сервере не изменится после первого применения, поскольку в данном примере PATCH обновляет значение поля "имя". Повторное применение запроса просто повторно обновит поле "имя" на то же значение. Это случай, когда PATCH настроен на обновление, а не на добавление. В таком случае PATCH идемпотентен.

    Пример неидемпотентного PATCH-запроса: Предположим, у нас есть ресурс "счет" с полем "баланс". Мы отправляем PATCH-запрос с обновлением значения поля "баланс" на +10 единиц. Если этот запрос применяется несколько раз, состояние счета на сервере будет изменяться после каждого применения. Каждый запрос увеличивает баланс на 10 единиц, поэтому повторное применение запроса будет иметь различный эффект каждый раз. Это случай, когда PATCH настроен на добавление, а не на обновление. В этом случае PATCH является неидемпотентным, т.к. каждый повторный вызов меняет состояние ресурса (прибавляет +10 к балансу).

    Идемпотентными методами являются: GET, PUT, DELETE, HEAD и OPTIONS. POST и PATCH не входят в эту группу.

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

    + какие бд знаешь? расскажи про них

    Реляционные базы данных (RDBMS): Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.

    Нереляционные базы данных (NoSQL): Нереляционные базы данных предоставляют альтернативный подход к хранению данных и могут использовать различные модели, такие как документы, ключ-значение, столбцы или графы. Они часто применяются в случаях, когда требуется гибкость в структуре данных. Примеры включают MongoDB, Cassandra и Redis.

    Графовые базы данных: Графовые базы данных разработаны специально для хранения и обработки данных в виде графов. Они обычно используются для анализа связей и сетей. Примером такой базы данных является Neo4j.

    Встраиваемые базы данных: Эти базы данных интегрируются непосредственно в приложения и обычно работают локально. Пример - SQLite, который часто используется в мобильных приложениях.

    Ключ-значение хранилища (Key-Value Stores): Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.

    + есть использования дестим ?

    ???

    + какой оператор отвечает за сортировку ?

    src_sql[:exports code]{GROUP BY}

    + дмл операторы

    DDL определяет структуру базы данных и ее объекты, такие как таблицы, представления, индексы и процедуры. DDL операторы используются для создания, изменения и удаления объектов базы данных, включая таблицы, представления, индексы и хранимые процедуры. Примеры DDL операторов включают CREATE, ALTER, DROP, TRUNCATE и RENAME. DDL операторы выполняются немедленно и являются постоянными, то есть после создания, изменения или удаления объекта изменение невозможно отменить. Поэтому важно быть осторожным и убедиться, что у вас есть резервная копия базы данных перед выполнением любых DDL операторов. DDL операторы обычно выполняются администратором базы данных или разработчиком с соответствующими привилегиями и разрешениями на изменение структуры базы данных.

    DML используется для манипулирования данными в базе данных. DML операторы используются для вставки, обновления и удаления данных в базе данных. Примерами DML операторов включают SELECT, INSERT, UPDATE, и DELETE. DML операторы выполняются немедленно и могут быть отменены с помощью оператора отката. DML операторы обычно выполняются конечными пользователями, например, приложениями или системами, взаимодействующими с базой данных для получения, обновления или удаления данных.

    В целом, DDL используется для определения и управления структурой базы данных, в то время как DML используется для манипулирования данными в базе данных. DDL утверждения являются постоянными и не могут быть отменены, в то время как DML утверждения выполняются немедленно и могут быть отменены. DDL утверждения выполняются уполномоченным персоналом, в то время как конечные пользователи выполняют DML утверждения.
  23. abcwalk revised this gist Nov 9, 2023. 2 changed files with 155 additions and 0 deletions.
    93 changes: 93 additions & 0 deletions IBS_interview.org
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,93 @@
    #+title: Ibs Interview

    + как устроен жизненный цикл дефекта?

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

    1. Обнаружение: Дефект может быть обнаружен тестировщиком, пользователем или автоматическим инструментом.

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

    3. Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как невоспроизводимый.

    4. Анализ/Приоретизация: Разработчик анализирует и исследует дефект, чтобы понять его причину и дать рекомендации по его устранению.

    5. Устранение: Разработчик исправляет дефект, внося соответствующие изменения в код.

    6. Тестирование: Исправленный дефект проходит тестирование, чтобы убедиться, что проблема была успешно устранена и не вызвала новых проблем.

    7. Проверка: Дефект проверяется и подтверждается тестировщиком или другим ответственным лицом.

    8. Закрытие: Если дефект был успешно исправлен и прошел проверку, он будет закрыт. Если дефект является невоспроизводимым или не может быть исправлен, он может быть помечен как "не устранимый" и не будет закрыт.

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

    + что такое дефект / баг?

    Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! И когда пользователь натыкается на ошибочный код, происходит сбой.

    * Дефект

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

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

    Ошибка (error, mistake) — действие человека, приводящее к некорректным результатам.

    Сбой (interruption) или отказ (failure) — отклонение поведения системы от ожидаемого.
    Сбой — самоустраняющийся или однократный отказ, устраняемый незначительным вмешательством.
    Отказ — событие, заключающееся в нарушении работоспособного состояния приложения.

    Таким образом, разработчик может совершить ошибку, написав неверный код. При выполнении функций приложения эта ошибка приводит к дефекту, который должен обнаружить тестировщик. Дефект может быть причиной сбоя или отказа.

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

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

    Любой дефект, обнаруженный в приложении или системе, должен быть задокументирован и передан разработчику либо другому ответственному специалисту для ознакомления и исправления. Документ, с помощью которого о дефекте становится известно миру или отдельному специалисту, называется отчётом о дефекте. Есть несколько определений этого понятия.

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

    Отчёт о дефекте — документ, описывающий и приоритизирующий обнаруженный дефект, а также содействующий его устранению.

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

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

    В целом, можно сказать, что баг является частью дефекта. Баг относится к конкретному несоответствию или неисправности, тогда как дефект может относиться к более широкому кругу проблем. Тем не менее, в реальной практике использования терминов "баг" и "дефект" часто встречаются в качестве синонимов, и разницу между ними можно считать несущественной.

    + отличия чек-лист и тест-кейс
    + при каких условиях будешь писать чек-лист, а при каких тест-кейс?
    + как ты понимаешь что достаточно тест кейсов и чек листов
    + есть ли опыт разработки тест данных
    + техники тест дизайна какие знаешь?
    + составлял ли матрицу покрытия?
    + занимался ли тестированием требований/спецификаций?

    + нативные и браузерные приложения в чем отличия?
    + специфические тестирования мобилок знаешь?
    + знаешь что такое монолитный бекенд?

    + опыт работы с тест логами есть? какие знаешь?
    *Kibana* предоставляет визуализацию результатов

    + интеграционное тестирование что знаешь?
    + какие подходы к тестированию интеграции знаешь? (подход большего взрыва)

    + клиентсерверное взаимодействие как происходит?
    + какая разница между двухзвенной и трехзвенной ?
    + разница между толстым и тонким клиентом?
    + какие протоколы знаешь?

    + патч и пут отличия?
    + можно ли создать метод делит который будет создавать?
    + есть ли опыт работы с девтулс?
    + какие основные вкладки использовал ?
    + что такое соап?
    + на коленке сделать примитивный джейсон
    + работал со сваггерами?

    + какие бд знаешь? расскажи про них
    + есть использования дестим ?
    + какой оператор отвечает за сортировку ?
    + дмл операторы
    62 changes: 62 additions & 0 deletions org-basics.org
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,62 @@
    #+title: Org Mode Basics In Doom Emacs
    #+description: An org document to demonstrate org mode on video.
    #+author: Maxim Rozhkov

    * A new headline
    ** Level 2 headline
    *** Level 3 headline
    **** Level 4 headline
    ***** Level 5 headline
    ****** Level 6 headline
    ******* Level 7 headline
    * New Level headline
    M-x org-toggle-heading
    M-x org-toggle-item
    + Unordered list item one
    + Unordered list item two
    - Dash instead of +


    1. Ordered list item one.
    2. Ordered list item two.
    3.
    4.
    5.

    Snippets
    #!/usr/bin/env bash
    Thu Nov 9 15:03:27 2023
    * TODO
    ** TODO example one
    ** PROJ example two
    ** LOOP
    ** STRT
    ** WAIT
    ** HOLD
    ** IDEA
    ** DONE
    ** KILL
    ** [ ]
    ** [-]
    ** [?]
    ** [X]
    ** OKAY
    ** YES
    ** NO
    SCHEDULED: <2023-11-09 Чт 21:00-23:00>
    * Checkboxes: - [ ] [2/3] [66%]
    - [X] task 1
    - [ ] task 2
    - [X] C-c C-c
    * Tables

    | Name | Age | Phone |
    |-------------+----------------+-------|
    | Alonzo | Monzo | Gonzo |
    | okay | let'go | write |
    | someeeeeeee | looooonngggggg | cell |


    | Another | Table |
    |---------+-------|
    | | |
  24. abcwalk revised this gist Nov 5, 2023. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions q&a.md
    View file
    Original file line number Diff line number Diff line change
    @@ -112,3 +112,4 @@ public static void typeConverterExample() {
    }
    ```

    TEST
  25. abcwalk created this gist Nov 5, 2023.
    114 changes: 114 additions & 0 deletions q&a.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,114 @@
    # Список вопросов с ответами для собеседования по Java

    ## Типы данных, переменные, операторы, циклы, массивы

    > 1. Сколько ключевых слов зарезервировано языком, что это за слова, какие из них не используются?
    50, два из них не используются: const, goto;

    Для запоминания это:
    - Примитивы (byte, short, int, long, char, float, double, boolean)
    - Циклы и ветвления (if, else, switch, case, default, while, do, break, continue, for)
    - Исключения (try, catch, finally, throw, throws)
    - Области видимости (private, protected, public)
    - Объявление \ Импорт (import, package, class, interface, extends, implements, static, final, void, abstract, native)
    - Создание \ Возврат \ Вызов (new, return, this, super)
    - Многопоточность (synchronized, volatile)
    instanceof, enum, assert, transient, strictfp, const, goto

    > 2. Из каких символов может состоять имя переменной (корректный идентификатор)?
    Имя или идентификатор переменной — это последовательность из строчных и заглавных латинских букв, цифр, а также символов `$` и `_`. Имя переменной **может начинаться с любого из перечисленных символов, кроме цифры**.

    Технически возможно начать имя переменной также с `$` или `_`, однако это запрещено соглашением по оформлению кода в Java (Java Code Conventions). Кроме того, символ доллара `$`, по соглашению, никогда не используется вообще. В соответствии с соглашением имя переменной должно начинаться именно с маленькой буквы (с заглавной буквы начинаются имена классов). Пробелы при именовании переменных не допускаются.

    > 3. Что значит слово `инициализация`?
    **Инициализация** (от англ. _initialization_, инициирование) — создание, активация, подготовка к работе, определение параметров. Приведение программы или устройства в состояние готовности к использованию. С точки зрения Java — выделение памяти под объект, например при создании MyClass myClass = new MyClass(). Таким образом будет выделена память под объект myClass (он будет инициализирован). Без инициализации (new MyClass()) запись MyClass myClass; просто резервирует имя (объявляется переменная myClass типа MyClass).

    > 4. На какие основные группы можно поделить типы данных?
    > 5. Какие примитивные типы вы знаете?
    В языке программирования Java типы данных можно разделить на несколько основных групп:

    1. **Примитивные типы данных (Primitive Data Types)**:
    - `int`: Целые числа.
    - `double`: Числа с плавающей точкой двойной точности.
    - `float`: Числа с плавающей точкой одинарной точности.
    - `char`: Одиночные символы (UTF-16 кодировка).
    - `boolean`: Логические значения (истина или ложь).
    - `byte`: Байты (целые числа от -128 до 127).
    - `short`: Короткие целые числа.
    - `long`: Длинные целые числа.

    2. **Ссылочные типы данных (Reference Data Types)**:
    - `class`: Определенные пользователем классы.
    - `interface`: Интерфейсы.
    - `array`: Массивы.
    - `enum`: Перечисления.
    - `String`: Строки (особый класс для работы со строками).

    3. **Обобщенные типы (Generic Types)**: Включают параметризованные классы и методы для обобщенного программирования.

    4. **Массивы (Arrays)**: Массивы могут быть использованы для хранения элементов одного типа данных.

    5. **Пользовательские типы данных (User-Defined Data Types)**: Эти типы данных создаются пользователями и включают в себя классы и интерфейсы, которые они определяют в своих программах.

    6. **Типы данных для работы с потоками (Stream Types)**: В Java есть типы данных, связанные с работой с потоками данных, такие как `InputStream` и `OutputStream`, используемые для чтения и записи данных.

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

    > 6. Что вы знаете о преобразовании примитивных типов данных, есть ли потеря данных, можно ли преобразовать логический тип?
    Преобразование может быть неявным и явным (приведение типов). Неявное преобразование может выполняться если:

    1. типы совместимы (например — оба целочисленные)
    2. размер «принимающего» типа больше чем у того, который преобразуется (так называемое «преобразование с расширением»)

    ```java
    int a = 123454;
    double b = a; //неявное преобразование - преобразование с расширением
    ```

    Явное преобразование имеет `вид переменная_нового_типа = (новый_тип) имя переменной;`

    ```java
    int a;
    byte b = (byte) a; //b будет остатком от деления a на диапазон byte, может быть потеря данных
    ```

    Примеры:
    ```java
    public static void typeConverterExample() {
    long a = 100L;
    double b = 300.0;
    Object ab = a + b;
    System.out.println(ab.getClass().getName() + " value: " + ab); //java.lang.Double value: 400.0

    double c = 1000.05;
    long d = 1000;
    Object cd = c+d;
    System.out.println(cd.getClass().getName() +" value: " + cd);//java.lang.Double value: 2000.05
    }

    public static void typeNarrowing() {
    int a0 = 64;
    int a = 257;
    int a2 = 126;
    int a3 = 129;
    byte b0 = (byte) a0;
    byte b = (byte) a;
    byte b2 = (byte) a2;
    byte b3 = (byte) a3;
    System.out.println(b0+ " " + b + " " + b2 + " " + b3); //64 1 126 -127

    double c = 56.9876;
    int d = (int) c;
    System.out.println(d); //56

    long e = 1000L;
    float f = (float) e;
    System.out.println(f); //1000.0
    }
    ```