Вопросы на собеседованиях для QA Engineer

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

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

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

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

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

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

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

Есть маленький грех за мной: я отрицаю существование негативных проверок, поскольку:
- их тяжело обосновать перед руководством,
- на них трудно получить время,
- их практически невозможно обосновать экономически перед заказчиком при составлении сметы на тестирование.
Опираясь на концепцию косвенных требований этого делать не надо, т. к. все проверки становятся позитивными, но часть из них – на соответствие прямым требованиям, часть – на соответствие косвенным. И квалификация специалиста как раз и выявляется пониманием косвенных требований для каждого конкретного продукта.
7 принципов тестирования
Все 7 принципов тестирования:
1. Исчерпывающее тестирование недостижимо
2. Кластеризация (скопление) дефектов - небольшое количество модулей ПО содержит большенство дефектов
3. Парадокс пестицида
4. Тестирование показывает наличие ошибок (не найти все ошибки, а сделать так чтобы клиент не нашел ошибки. показать не отсутствие ошибок, а их наличие)
5. Отсутствие ошибок это иллюзию (нужно фокусироваться не только на дефектах, а на продукте в целом)
6. Раннее тестирование (цена дефекта возрастает с каждой стадией производства ПО)
7. Контекст тестирования (подход к тестированию ПО в разных сферах и областях отличается)
Что такое тестирование?
Комплекс мероприятий, направленных на проведение проверок на соответствие продукта требованиям, к нему предъявляемым (прямым или косвенным).
Цель тестирования?
Донесение релевантной информации о продукте команде для принятия верных решений.
Что такое верификация и валидация?

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

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

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

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

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

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

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

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

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

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

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

Smoke-тесты

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

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

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

Regression

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

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

В чем разница между нагрузочным и стресс тестированием?
Нагрузочное - это тестирование в пределах значений нагрузки, которые должна выдерживать система, а стрессовое – это тестирования за ее пределами.
Что такое тест-дизайн?
Тест-дизайн — набор техник, позволяющих с минимальными усилиями расширить тестовое покрытие.
Зачем нужен тест-дизайн?
Основная цель тест-дизайна — структурировать процедуры тестирования, чтобы было легче отслеживать покрытие требований тест-кейсами.

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

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

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

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

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

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

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

E2E
Проверить так ли работает программа для конечного клиента, как рассчитывалось изначально. Самый трудозатратный и дорогой, поэтому находится на вершине пирамиды тестирования.
Аутентификация и авторизация
- Идентификация - xпроцедура распознавания по его личному идентификатору
- Аутентификация - проверят действительно ли вы это вы
- Авторизация - Это предоставление прав пользователю к какому-то ресурсу
  - Веб-токен JSON (JWT - JSON web token) - это открытый стандарт для безопасной передачи данных между сторонами, а пользователи авторизуются с помощью пары открытый/закрытый ключ
  - OAuth позволяет API аутентифицировать и получать доступ к запрошенной системе или ресурсу
Как устроен жизненный цикл дефекта?
Жизненный цикл дефекта - это последовательность этапов, которые проходит дефект от его обнаружения до закрытия. Хотя конкретные этапы могут немного отличаться в различных организациях или проектах, обычно жизненный цикл дефекта включает следующие этапы:
- Обнаружение и Локализация: Дефект может быть обнаружен тестировщиком, пользователем или автоматическим инструментом.
- Документация: Дефект должен быть надлежащим образом задокументирован, чтобы команда разработки могла понять и воспроизвести проблему. Документация может включать информацию о версии продукта, платформе, шагах для воспроизведения, ожидаемых результатов и фактических результатов.
- Воспроизведение: Разработчик должен попытаться воспроизвести дефект в контролируемых условиях. Если дефект не может быть воспроизведен, он может быть помечен как не воспроизводимый.
- Анализ/Приоретизация: Разработчик анализирует и исследует дефект, чтобы понять его причину и дать рекомендации по его устранению.
- Устранение: Разработчик исправляет дефект, внося соответствующие изменения в код.
- Тестирование: Исправленный дефект проходит тестирование, чтобы убедиться, что проблема была успешно устранена и не вызвала новых проблем.
- Проверка: Дефект проверяется и подтверждается тестировщиком или другим ответственным лицом.
- Закрытие: Если дефект был успешно исправлен и прошел проверку, он будет закрыт. Если дефект является невоспроизводимым или не может быть исправлен, он может быть помечен как “не устранимый” и не будет закрыт.
  1. Баг обнаружен и локализован
  2. Создание баг-репорта
  3. Анализ/Приоритезация бага
  4. Устранения бага
  5. Тестирование (ре-тест)
  6. Закрытие (При устранении бага, баг закрывается, либо отправляется на доработку)

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

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

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

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

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

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

Параметры сравнения	Ошибка	Дефект
Определение	Баги — это проблемы, обнаруженные в процессе тестирования.	Методологии оперативной разработки и регулярная оцxенка кода.
Был воспитан	Инженеры-испытатели.	Тестеры.
Тип	Логические, алгоритмические и ресурсные ошибки.	Критические, основные, второстепенные и тривиальные.
Причины возникновения	Отсутствующий код, неправильное кодирование или дополнительное кодирование.	Кодовая или логическая ошибка и неправильный ввод.
Предотвращени	Мы используем фундаментальные и точные подходы к разработке программного обеспечения.	Использование фундаментальных и точных подходов к разработке программного обеспечения.

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

Тест-кейсы

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

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

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

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

Пример: Название: Тестирование функции входа в систему Описание: Проверка возможности входа в систему с корректными данными пользователя Предусловия: Пользователь зарегистрирован в системе Шаги выполнения:

Открыть страницу входа.
Ввести корректный логин пользователя.
Ввести корректный пароль пользователя.
Нажать кнопку “Войти”.

Ожидаемый результат: Пользователь успешно входит в систему и попадает на главную страницу. Фактический результат: (заполняется после выполнения теста) Статус: (заполняется после выполнения теста, например, “Пройден” или “Не пройден”)

Чек-листы

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

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

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

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

Пример: Чек-лист для тестирования функции входа в систему:

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

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

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

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

Как утверждает Алексей Баранцев “… простейший чек-лист – это список тест-кейсов.” Я с ним согласен. Т.е. чек-лист лишь перечисление тестовых прецедентов, которые могут быть описаны, а могут и не быть. Так вот… тестовые прецеденты должны постоянно поддерживаться в актуальном состоянии. А поскольку тестовые прецеденты более детальны, чем чек-листы, то и на их поддержание требуется больше ресурсов.

Поэтому мое мнение таково: если хватает ресурсов, то можно иметь описание тестовых прецедентов, если нет - нужно обходиться чек-листами. Они, по крайней мере, позволят систематизировать тестирование. Я в фирме ввел как правило “имение как минимум чек-листов”.
- Насколько сотрудники вовлечены чтобы понять тест-кейсы?
- Насколько сложный продукт?
- Придется ли в будушем воспроизводить эти действия? Или это на один раз?
- Универсальность чек-листов сможет покрыть другой функционал? Или это плохая практика?

Как ты понимаешь что достаточно тест кейсов и чек листов?
Чтобы понять, достаточно ли тест-кейсов и чек-листов для проведения тестирования, необходимо учесть несколько факторов:
- Покрытие функциональности: Проверьте, что все основные функциональные требования системы покрываются соответствующими тест-кейсами и чек-листами. Если важные функции не покрыты, это может быть признаком недостаточного количества тестов.
- Покрытие различных сценариев: Убедитесь, что тест-кейсы и чек-листы учитывают различные сценарии использования системы. Рассмотрите разные варианты ввода данных, комбинации функций и возможные пути выполнения операций. Если все сценарии не учтены, может потребоваться больше тестов.
- Распределение ошибок: Проанализируйте результаты предыдущих тестов, чтобы определить, в каких областях системы обнаруживались наибольшее количество ошибок. Если в определенных областях системы было много проблем, может потребоваться создать дополнительные тест-кейсы для улучшения покрытия.
- Временные ограничения: Учтите ограничения по времени и ресурсам, которыми вы располагаете для проведения тестирования. Если у вас есть ограниченное время для тестирования, вы можете потребовать более точечных и фокусированных тест-кейсов.

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

Есть ли опыт разработки тест данных
Для больших объемов нет.

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

Техники тест дизайна какие знаешь?
1. Классы эквивалентности
  При любом значении из одного класса эквивалентности поведение системы должно быть одинаковым.
2. Граничные значения
  Граница (или граничное значение) - это место где меняется поведение системы.
3. Предугадывание ошибок
  Это техника создания гипотез о местах системы на основании документации и знаний о системе. Обычно с ее помощью создаются негативные кейсы.
  
  Предугадывать можно:
  - По опыту
  - С помощью знаний о работе системы
  - С помощью знаний о работе ПО
  - По документации
  - По статистике (багов, тестов, использования)
4. Причина-следствие
5. Pairwise Testing
  Техника, которая проверяет все пары значений для заданных параметров. Тоесть каждое значение одного параметра хотябы один раз будет проверено с каждым значенем другого параметра.
6. Исследовательское тестирование и туры Виттакера
  Это неформальный метод, при котором тесты проектируются во время их исполнения. Мы представляем все приложение как город.
  
  Когда применяется:
  - Нужно обеспечить быструю обратную связь
  - Нужно быстро изучить продукт
  - Для разнообразия тестирования
  - Нужно обнаружить и локализовать дефект
7. Таблица принятия решений
  Способ компактного представления модели со сложной логикой; инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. Это взаимосвязь между множеством условий и действий.
Эффективность тест-кейсов
Когда переписываешь тест кейсы 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. Конфигурационное тестирование
Что такое гайдлайны?
Гайдлайны по мобильному тестированию включают в себя рекомендации и практики, направленные на обеспечение качества мобильных приложений. Вот несколько ключевых аспектов и гайдлайнов, которые могут быть полезными в мобильном тестировании:
1. Покрытие платформ:
  - Тестируйте приложение на разных мобильных платформах (iOS, Android) и версиях устройств. Обратите внимание на особенности каждой платформы.
2. Разнообразие устройств:
  - Уделяйте внимание разнообразию устройств, разрешений экранов и версий операционных систем.
3. Ориентации экрана:
  - Проверяйте приложение в разных ориентациях экрана (портретной и альбомной).
4. Тестирование различных сетевых условий:
  - Имитируйте различные сетевые условия, такие как 3G, 4G, Wi-Fi с низкой пропускной способностью, чтобы проверить, как ваше приложение ведет себя при ограниченной связи.
5. Тестирование на различных разрешениях экрана:
  - Убедитесь, что ваше приложение адаптируется к различным размерам экрана мобильных устройств.
6. Тестирование производительности:
  - Оцените производительность приложения при работе с различными объемами данных и на различных устройствах.
7. Обработка различных языков и региональных настроек:
  - Проверьте, как ваше приложение обрабатывает различные языки и региональные настройки.
8. Тестирование в разных версиях ОС:
  - Убедитесь, что ваше приложение совместимо с различными версиями операционных систем.
9. **Автоматизация тестирования:**
  - Используйте автоматизацию тестирования для повторяемых сценариев и быстрого обнаружения регрессий.
10. Тестирование безопасности:
  - Проверьте безопасность вашего приложения, в том числе защиту данных, обработку паролей и т.д.
11. Тестирование обновлений и установки:
  - Протестируйте процесс обновления и установки приложения на устройствах с предыдущими версиями.
12. Тестирование в различных окружениях:
  - Убедитесь, что ваше приложение работает в различных окружениях, таких как различные версии фреймворков, библиотек, и т.д.
13. Тестирование интеграции:
  - Тестируйте взаимодействие вашего приложения с другими приложениями и сервисами.
14. Анализ обратной связи пользователей:
  - Принимайте во внимание обратную связь пользователей и используйте ее для улучшения качества приложения.
15. Тестирование резервного копирования и восстановления:
  - Проверьте, как приложение обрабатывает резервное копирование и восстановление данных.

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

Знаешь что такое монолитный бекенд?

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

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

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

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

Например есть огромная банковская система. В рамках одной системы:

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

Если мы «выключим» монолит, мы выключим весь его функционал целиком.

Опыт работы с тест логами есть? какие знаешь?
Kibana предоставляет визуализацию результатов
Что можно логировать?
- вызовы методов, тело, параметры, ответ
- ошибки пользовательские и серверные
- запросы в БД
- служебная и вспомогательная информация об изменениях в системе
Интеграционное тестирование что знаешь?
Интеграционное тестирование предназначено для проверки насколько хорошо два или более компонента ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).

Уровни интеграционного тестирования:
- Компонентный интеграционный уровень (Component Integration testing)
  Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
- Системный интеграционный уровень (System Integration Testing)
  Проверяется взаимодействие между разными системами после проведения системного тестирования.
Какие подходы к тестированию интеграции знаешь? (подход большего взрыва)
Подходы к интеграционному тестированию:
- Снизу вверх (Bottom Up Integration)
  Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения
- Сверху вниз (Top Down Integration)
  Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз. (см. также Top Down Integration)
- Большой взрыв (“Big Bang” Integration)
  “Большой взрыв” (Big Bang Integration) - это метод интеграции программного обеспечения, при котором все компоненты или модули системы интегрируются одновременно. В этом подходе все изменения вносятся и тестируются в единой среде, и общая работоспособность системы проверяется в целом.
  
  Основные характеристики метода “Большой взрыв”:
  - Интеграция в конце: Интеграция всех компонентов происходит ближе к концу разработки проекта. Весь код, разработанный различными командами или индивидуальными разработчиками, собирается и интегрируется вместе.
  - Одновременная интеграция: Все компоненты или модули интегрируются одновременно. Это может создать ситуацию, когда множество изменений вводится в систему одновременно, что может сделать процесс выявления и устранения возможных конфликтов более сложным.
  - Тестирование в целом: После интеграции производится тестирование системы в ее целом. Это включает в себя проверку общей работоспособности, взаимодействия компонентов и корректности функционирования системы в целом.
  - Больший риск конфликтов: Поскольку интеграция происходит в конце разработки, есть риск обнаружения серьезных конфликтов и ошибок, которые могли бы быть выявлены и устранены на более ранних этапах.
  - Менее предсказуемый процесс: Такой метод интеграции может создать более сложный и менее предсказуемый процесс разработки, особенно если существуют неучтенные зависимости или непредвиденные проблемы.
  “Большой взрыв” может быть эффективен для небольших проектов или в ситуациях, где особенности проекта не позволяют использовать более инкрементальные методы интеграции. Однако, такой подход требует внимательного планирования и управления рисками, чтобы успешно интегрировать и протестировать систему.
Что такое тестирование API?
Подтип тестирования, нацеленный на программный интерфейс приложений (API). Тестирование API проверяет, соответствует ли API приложения требованиям по функциональности, производительности, безопасности, и другим.
Что верифицируют в процессе тестирования API
- Корректность передачи данных
- Статус-коды HTTP
- Время отклика (response time)
- Коды ошибок, если API возвращает ошибки
- Авторизацию
- Нефункциональное тестирование, в частности производительность и безопасность

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

Вот общая схема клиент-серверного взаимодействия:
1. Клиент отправляет запрос на сервер. Клиент может быть программой, приложением или даже другим сервером. Запрос содержит информацию о том, какие ресурсы или услуги требуются.
2. Сервер принимает запрос от клиента и анализирует его. Сервер может быть физическим компьютером или виртуальной машиной, которая обрабатывает запросы от клиентов.
3. Сервер обрабатывает запрос и генерирует ответ. В зависимости от запроса, сервер может выполнять различные операции, обращаться к базе данных, обрабатывать данные и генерировать результат.
4. Сервер отправляет ответ обратно клиенту. Ответ содержит запрошенные ресурсы или информацию, которую клиент ожидал получить.
5. Клиент принимает ответ от сервера и обрабатывает его. Клиент может использовать полученные данные для отображения на экране, выполнения дальнейших операций или передачи данных другим компонентам системы.
Важно отметить, что клиент и сервер могут взаимодействовать по различным протоколам, таким как HTTP, FTP, SMTP и т.д. Каждый протокол определяет свои правила и формат обмена данными.
Какая разница между двухзвенной и трехзвенной?
Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т.е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса.

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

Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом:
1. Представление данных — на стороне клиента.
2. Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).
3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.
Разница между толстым и тонким клиентом?
1. Толстый клиент (Fat Client):
2. Локальная обработка:
  - Определение: Толстый клиент имеет значительную локальную обработку и хранение данных.
  - Характеристики: Значительная часть бизнес-логики и функциональности находится на клиентской стороне.
3. Графический интерфейс:
  - Примеры: Нативные приложения, устанавливаемые на устройстве пользователя (например, десктопные приложения).
4. Объем передаваемых данных:
  - Коммуникация: Обычно взаимодействует с сервером для получения данных, но имеет богатый функциональный интерфейс и часто загружает больший объем данных для локальной обработки.
5. Преимущества:
  - Может обеспечивать высокую производительность и отзывчивость, так как множество операций выполняется локально.
6. Тонкий клиент (Thin Client):
7. Минимальная локальная обработка:
  - Определение: Тонкий клиент имеет минимальную локальную обработку и полагается на сервер для большей части обработки и хранения данных.
  - Характеристики: Минимальный функционал на клиентской стороне, часто только графический интерфейс и минимальная логика.
8. Графический интерфейс:
  - Примеры: Веб-приложения, которые работают в браузере.
9. Объем передаваемых данных:
  - Коммуникация: Взаимодействует с сервером для получения данных и обновлений, пересылает минимальные данные для отображения и ввода.
10. Преимущества:
  - Легко управлять и обновлять, так как большинство изменений происходит на сервере. Обеспечивает централизованное управление приложениями.
Общие соображения:
- Выбор между толстым и тонким клиентом зависит от требований проекта, характера приложения и сетевой инфраструктуры.
- Толстый клиент часто приводит к более высоким требованиям к управлению, так как обновления могут быть сложными и требовать установки на каждом устройстве.
- Тонкий клиент может быть более удобным с точки зрения обновлений и поддержки, но может требовать более сильной сетевой инфраструктуры.
Какие протоколы знаешь?
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 - нет
Почему POST запросы не кэшируются, а GET кэширутся?
- GET-запросы обычно используются для получения данных от сервера. Они могут быть кэшированы браузером или прокси-сервером, потому что они обычно предназначены для получения данных и не меняют состояние на сервере или в базе данных. Браузер может сохранять результаты GET-запросов в кэше, чтобы в следующий раз, когда такой же запрос будет отправлен, использовать закэшированные данные вместо повторного обращения к серверу.
- POST-запросы, напротив, обычно используются для отправки данных на сервер для обработки. Они часто используются для изменения состояния на сервере, создания новых записей и т.д. По умолчанию POST-запросы не кэшируются браузерами или прокси-серверами, потому что они могут изменить данные на сервере, и повторное выполнение POST-запроса может привести к неожиданным изменениям состояния на сервере или созданию дублирующихся записей.
  Однако, это поведение может быть изменено с помощью HTTP-заголовков. Например, можно указать, что ответ на POST-запрос может быть кэширован с помощью специальных заголовков Cache-Control или Expires, но это требует аккуратного управления и не используется по умолчанию из-за потенциальной опасности изменения состояния на сервере без необходимости.
Структура HTTP-запроса и ответа
HTTP Запрос:
1. Строка запроса (Request Line):
  - Метод запроса (GET, POST, PUT, DELETE и т.д.).
  - URI (Uniform Resource Identifier) - путь к ресурсу.
  - Версия HTTP (например, HTTP/1.1).
Пример: GET /index.html HTTP/1.1
1. Заголовки (Headers):
  - Различные метаданные о запросе, такие как Host, User-Agent, Accept, и т.д.
  Пример:
```
Host: www.example.com
User-Agent: Chrome/91.0.4472.124
Accept: text/html,application/xhtml+xml,application/xml;
        
```
2. Тело запроса (Request Body):
  - Данные, отправляемые с запросом. Обычно используется для POST и PUT запросов.
    Пример: username=johndoe&password=secret
HTTP Ответ:
Строка состояния (Status Line):
- Версия HTTP.
- Код состояния - трехзначный числовой код, обозначающий успешность или ошибку ответа.
- Текстовое описание кода состояния.
Пример: HTTP/1.1 200 OK
Заголовки (Headers):
- Метаданные ответа, такие как Content-Type, Content-Length, и т.д.
  Пример:
```
Content-Type: text/html; charset=utf-8
Content-Length: 1234
        
```
Тело ответа (Response Body):
- Данные, возвращаемые сервером. Например, HTML-страница, изображение и т.д.
  Пример (HTML):
```
<!DOCTYPE html>
<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <h1>Hello, World!</h1>
</body>
</html>
        
```
Это общая структура. Некоторые запросы и ответы могут не содержать тела, и в некоторых случаях могут использоваться дополнительные параметры, такие как параметры запроса (в строке запроса) или куки (в заголовках).
Что такое cURL?
Полный запрос.
Что такое кэш и cookie?
Кэш (cache) и cookie - это два различных механизма, используемых веб-браузерами для оптимизации и управления веб-сайтами.
Кэш

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

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

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

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

PATCH и PUT отличия?
1. Метод PATCH используется для частичного обновления ресурса. Он предназначен для отправки только измененных или обновленных данных на сервер. Это позволяет экономить время и ресурсы при обновлении ресурсов, так как нет необходимости отправлять и обрабатывать все данные каждый раз.
2. Метод PUT используется для полного замещения ресурса или создания нового ресурса. При использовании PUT-запроса нужно передавать все данные ресурса целиком. Если такой ресурс уже существует, то он будет заменен новыми данными, если ресурс не существует, то будет создан новый.
Таким образом, основное отличие между патчем и путом заключается в том, что патч используется для частичного обновления ресурса, а пут - для полного обновления или создания нового ресурса.
Можно ли создать метод делит который будет создавать?
Можно обработать запрос по своему усмотрению.
Что такое SOAP?
SOAP – протокол обмена структурированными сообщениями.
- Нет специального стиля
- Только один тип запросов
- В body только XML
- SOAP. Протокол используется для обмена произвольными сообщениями в формате XML, а также для вызова процедур. SOAP ограничивает структуры ваших сообщений. Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML.
- SOAP использует WSDL. Он предоставляет поставщикам служб простой способ описания базового формата запросов, передаваемых их системам, независимо от применяемой реализации.
- 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 (Representational State Transfer) и SOAP (Simple Object Access Protocol) - это два различных подхода к созданию веб-сервисов:
1. **Архитектурный стиль:**
  - REST: Основывается на принципах взаимодействия клиент-сервер, отсутствии состояния (statelessness - сервер не должен хранить состояние между запросами от одного и того же клиента), кэшировании, использовании унифицированных интерфейсов и многоуровневой архитектуре. Он ориентирован на ресурсы и использует HTTP методы (GET, POST, PUT, DELETE) для работы с ними.
  - SOAP: Это протокол, основанный на XML для обмена структурированными и типизированными сообщениями между клиентом и сервером. SOAP ориентирован на использование спецификаций (WSDL - Web Services Description Language) для определения контрактов и на XML для обмена данными.
2. **Формат данных:**
  - REST: Использует различные форматы для представления данных, такие как JSON, XML, HTML и другие. Обычно предпочтителен JSON из-за своей легковесности и удобства в использовании.
  - SOAP: Использует строго типизированные XML-сообщения для обмена данными между клиентом и сервером.
3. **Простота использования:**
  - REST: Обычно считается более простым для понимания и использования, так как использует стандартные HTTP методы и не требует сложной настройки.
  - SOAP: Более мощный и расширяемый, но зачастую более сложный в использовании из-за необходимости в строгих схемах данных и формальных контрактах.
4. **Производительность:**
  - REST: Обычно более производительный благодаря простоте передачи данных, использованию кэширования и меньшему объему данных.
  - SOAP: Имеет больший объем данных из-за XML и может быть менее производительным из-за дополнительных слоев безопасности и типизации.
Выбор между REST и SOAP зависит от требований проекта, уровня сложности, необходимости типизации данных и других специфических потребностей. REST часто предпочтителен для мобильных приложений и веб-сервисов, где важна легковесность и гибкость, в то время как SOAP может быть полезен в средах, где требуются строгие контракты и типизированные данные.
На коленке сделать примитивный JSON

{
  "строка": "Пример JSON",
  "целое число": 42,
  "дробное число": 3.14159,
  "логическое значение": true,
  "массив": [1, 2, 3, 4, 5],
  "объект": {
    "ключ1": "значение1",
    "ключ2": "значение2"
  },
  "нулевое значение": null
}

Идемпотентность
Пример идемпотентного PATCH-запроса: Предположим, у нас есть ресурс “пользователь” с полями “имя” и “электронная почта”. Мы отправляем PATCH-запрос с обновленным значением только для поля “имя”. Если этот запрос применяется несколько раз, состояние пользователя на сервере не изменится после первого применения, поскольку в данном примере PATCH обновляет значение поля “имя”. Повторное применение запроса просто повторно обновит поле “имя” на то же значение. Это случай, когда PATCH настроен на обновление, а не на добавление. В таком случае PATCH идемпотентен.

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

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

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

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

Статусы 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?

RabbitMQ это брокер сообщений, если в двух словах то служит для передачи данных между микросервисами

/----------\   /---------\    /----------\    /-------\    /----------\
| Producer |---| Message |--->| Exchange |--->| Queue |--->| Consumer |
\----------/   \---------/    \----------/    \-------/    \----------/

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

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

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

/------------\                          /---------\            /------------\
| Producer_1 |                          | Queue_1 |----------->| Consumer_1 |
\------------/                          \---------/            \------------/
      |                                      |
      +------------->/----------\------------+
/------------\       |   cBLU   |       /---------\            /------------\
| 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, который по-умолчанию привязан ко всем очередям
Что такое шина данных?

Базы данных

Какие виды БД?

Реляционные базы данных (RDBMS)
Реляционные базы данных используют табличную структуру для хранения данных, где данные организованы в таблицы с рядами и столбцами. Они используют SQL (Structured Query Language) для выполнения операций с данными. Примеры включают MySQL, PostgreSQL и Oracle.

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

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

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

Ключ-значение хранилища (Key-Value Stores)
Они предоставляют простую модель хранения данных в виде ключей и связанных с ними значений. Пример - Redis.
Что такое DML и DDL операторы?

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 утверждения.

Опыт

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

Основные принципы:
1. Сначала мы тестируем те вещи которые поменялись
2. Сначала мы тестируем базовые функции и потом вспомогательные. Вначале тестируем критичные и популярные функции продукта.
3. Сначача в приоритете работоспособность всего функционала и только потом глубокое исследование, поведение различных функций в различных условиях
4. Тестировать стандартные условия перед гипотетическими
5. Сначала тестируем стандартные угрозы перед экзотическими, тоесть проводим тесты на наиболее вероятные стрессовые и багоопасные ситуации в первую очередь
6. Сначала тестируем те части продукта, которые могут нанести больший вред
7. Сначала тестируем наиболее используемые области продукта, перед невостребованными областями
Если софт не имеет критичных багов то в теории его можно двигать дальше
Тестирование полей и форм
“Дана форма для регистрации. Протестируйте” - вопрос номер один практически на всех собеседованиях на младшую позицию. Он хорош еще и тем, что в зависимости от уровня кандидата будет раскрыт в разной степени. Всегда в первую очередь уточняйте хотя бы какие-то минимальные требования, даже если вначале озвучивают, что требования не формализованы.
- Начальный уровень представляет из себя простые позитивные и негативные кейсы (в основном на валидацию):
  - Обязательные поля отмечены *
  - Обязательные поля заполнены/нет
  - Галочки на соглашениях проставлены/нет
  - Поле password и подтверждение имеет соответствующий тип (в полях формы прописан корректный атрибут TYPE, сообщающий браузеру тип элементов формы.)
  - Проверяется, что пароли одинаковы
  - Имя пользователя валидируется как минимум на длину и спец. символы, остальное по ТЗ
  - Адрес почты валидируется в соответствии со стандартом (наличие символа @, несколько символов @, длины частей до и после @, допустимые символы до и после, наличие пробелов перед адресом и после, корректная доменная часть и т.п.)
  - Поля с ожидаемым числовым вводом и текстовым соответственно проверить позитивными и негативными кейсами по типам данных
- Следующий уровень:
  - Все из предыдущего
  - Кроссбраузерность
  - Понятность формы. Присутствует описание полей или плейсхолдеры
  - Сенситив данные не должны передаваться в URL
  - Проверяем, как форма отображается до сабмита и после
  - Поведение, если нажать сабмит несколько раз подряд
  - Если формы очищаются после сабмита, проверить регистрацию существующего пользователя
  - Проверка глобализации - номер телефона, дата, почтовый индекс, валюта, вертикальное или RTL письмо и т.п. (опционально)
  - Проверка простых инъекций
  - Правильная работа многошаговых форм (Навигация рядом с формой показывает текущий этап и количество оставшихся шагов.)
  - Для полей, предполагающих загрузку файлов, прописан атрибут accept, определяющий тип загружаемых документов
  - Текстовое многострочное поле при вводе объемного сообщения изменяет высоту либо в правой части появляется скроллбар для просмотра всего содержимого
  - Для авторизованного пользователя в поля формы автоматически подставляются все известные о посетителе данные.
  - Форма сохраняется в веб-формах (админ-панели) или SQL-таблицах.
  - Прописан реальный e-mail лица, отвечающего за обработку заявок (если предполагается ОС)
  - Опционально. Пользователь получает уведомление на свой e-mail об успешно полученной заявке и последующих действиях, которые от него требуются.
  - Прописан атрибут autocomplete для полей, поддерживающих это значение
- Extra:
  - Проверяем, отправились ли данные после сабмита
  - Проверяем, добавились ли соответствующие записи в бд
  - Проверка загрузки формы и сабмита при медленном/нестабильном интернет-соединении
  - Корректность cookies/токена и т.п. после сабмита
Что делать если нужно пройти регрессию а времени нет?
Попробовать поговорить с тиммлидом. Спросить у разработчиков какие части приложения подвергались изменениям.

abcwalk/q&a.org

Select an option

No results found