Полезное для собеседования
Анализ требований - Тех дизайн - Разработка - Тестирование и отладка - Релиз - Поддержка и обратная связь
Юнит-тестирование - проверка метода, класса, функции
Интеграционное - проверка частей системы объединенных вместе
Регрессия - проверка, что не сломан уже существующий функционал
Системное - проверка всей системы, что все работает как ожидается
Смоук - проверка базового функционала, что он работает
Производительность - проверка, что производительность системы соответствует ожиданиям
Приемочное - проверка соответствия ожиданиям клиента
Стресс - проверка, что приложение работает в нестандартных условиях
Юзабилити - проверка удобства использования продукта
Безопасность - проверка возможности взлома приложения
Анализ требований - Тест-планы и тест-кейсы - Подготовка окружения - Подготовка данных - Выполнение тестов - Завершение тестирования
QC - проверка приложение на соответствие стандартам. поиск багов
QA - процесс предотвращения появления багов посредством улучшения процессов
Верификация - подтверждение того, что ПО создается в соответствии с требованиями
Валидация - подтверждение того, что ПО соответствует ожиданиям и требованиям клиентов
Методика тестирования комбинаций вводов и выводов организованное в табличном виде. Применяется в тестировании черного ящика и помогает в дизайне тест-кейсов
Bug leakage - баг найден на проде
Bug release - баг идет в релиз и команда об этом знает
8. Defect triage - процесс, в котором дефектам присваиваются приоритеты
9. Test harness - коллекция тестовых сценариев и тестовых данных, используемая в юнит— и интеграционном тестировании
Тестирование на отказ — проверка способности приложения/сайта выделять больше ресурсов (например больше памяти и места на сервере) в случае отказа, и выполнять резервное копирование (бекап) критически важных частей.
В приложение подается большой объем рендомных данных. Таким способом иногда удается найти дыры в безопасности и другие проблемы.
12. Цикломатическая сложность = L — N + 2P, где:
L — количество ребер в графе выполнения программы
N — количество узлов (нодов)
P — количество отсоединенных частей в графе
13. Разница между латентным и замаскированным дефектом
Латентный дефект — неидентифицированный дефект в текущем релизе, не обнаруженный из-за того что условия, при которых он проявляется, слишком редкие/специфические.
Замаскированный дефект — существующий в приложении, но не вызывающий проблем, из-за того что он как бы «заслонен» другим, более явным дефектом.
14. Метрика тестирования - количественный показатель прогресса (выполнения) проекта
15. Context-driven-тестирование
Тип тестирования, при котором изменяются и «перенастраиваются» практики и методологии в зависимости от контекста в проекте.
General URL, метод, статус, удаленный адрес сервера
Заголовок запроса путь, схема (https), сжатие, локализация, тип контента (текст, json и формат utf-8), куки, юзер-агент (данные браузера)
Заголовок ответа - от сервера
информация о сервере, время жизни кеша, куки для идентификации пользователя, тип аутентификации
Payload В запросах, которые передают данные, тут отображается JSON с передаваемыми данными
Методы
GET - запрос данных. не имеет тела, но с помощью параметров можно передать значения на сервер (в конце URL-адреса поставить знак «?»)
POST - передача данных на сервер. создает новый элемент на сервере
PUT - обновляет данные в уже созданной сущности
DELETE - запрос на удаление созданной сущности
PATCH - частично изменяет созданную сущность
Все HTTP Methods можно разделить на три большие группы:
- Безопасные — не меняют данные, можно выполнять их в любой последовательности. К ним относятся GET, HEAD и OPTIONS.
- Идемпотентные — при повторном выполнении результаты ожидаемо одинаковые. GET, HEAD, PUT, DELETE, OPTIONS, TRACE.
- Неидемпотентные — при повторном выполнении результаты будут отличаться. POST и PATCH.
17. Trunk Based Development (TBD) - разработка в одной ветке. Весь код по различным задачам мержится в нее
18. Gitflow — это когда новый код передается (мерджится) в develop-ветку, а не main-ветку; main-ветка служит только для сокращенной версии истории проекта.
19. Стратегии релиза/деплоя
- Стандартный релиз/деплой. Обычный релиз софта, софт сразу доступен клиентам.
- Canary-релиз - выдается только части пользователям, если есть риск отказа
- Blue-green релиз. Две версии приложения (новый релиз и старый). Все переходят на новый с возможностью отката
- Dark launch. Новые функции релизятся без предварительного оповещения пользователей. Функции активируются постепенно и по мере необходимости, активацией так называемых feature flags.
20. Flaky-тест - нестабильно воспроизводимый.
Причины flaky-тестов:
- Проблемы с параллельно выполняемыми тестами.
- Зависимость выполнения тестов от порядка их запуска в сьюте.
- Небрежно составленные тесты.
21. Как оптимизировать тесты в CI?
- Разделять большие тесты на мелкие
- Удалять не особенно нужные и просроченные
- Рефакторинг, с удалением “тормозящих” зависимостей
- Параллельное выполнение
22. Какие данные, имеющие отношение к API, можно найти в Web Developer tools?
Заголовок запроса, тело запроса, и кукисы относящиеся к запросу.
23. Что такое раннеры коллекций?
Раннеры (Postman Collection runners) служат для автоматического запуска коллекций на выполнение. Коллекция (группа запросов) может быть запущена с разными наборами данных, что удобно для тестирования.
Он расшифровывается как Created (ресурс создан), когда ресурс успешно создан POST- или GET-запросом
Он расшифровывается как Not Modified (без изменений). Говорит о том, что нет необходимости повторно передавать запрошенные ресурсы.
26. Как в Postman выполнить один и тот же запрос 100 раз?
С помощью раннера Collection Runner.
27. Что выполняется при запуске коллекций в первую очередь?
Так называемые подготовительные скрипты (pre-request scripts).
28. Какие отличительные характеристики тестирования API по сравнению с другими типами?
- без GUI
- тестирование ключевого функционала
- экономия времени (не нужен фронтенд)
29. Какие протоколы применяются при тестировании API?
30. Что верифицируют в процессе тестирования API?
- Корректность передачи данных
- Статус-коды HTTP
- Время отклика (response time)
- Коды ошибок, если API возвращает ошибки
- Авторизацию
- Нефункциональное тестирование, в частности производительность и безопасность
31. Какие применяются методы аутентификации при тестировании API?
- Через сессии/cookies
- Базовая аутентификация
- Дайджест-аутентификация
- OAuth
32. В чем разница между аутентификацией и авторизацией?
Аутентификация — это процесс подтверждения идентичности пользователя;
Авторизация — процесс подтверждения прав на уровень доступа.
Буквально «простой протокол доступа к объектам», протокол обмена структурированными сообщениями на основе XML.
REST — буквально «передача самоописываемого состояния», стиль взаимодействия распределенного приложения в сети. REST API — набор функций для создания и выполнения запросов и получения ответов по HTTP.
35. Что нужно проверять во время тестирования базы данных?
Как правило, проверяются все функциональные возможности, включая проверку размерности полей, ограничения, индексирование, правильность работы хранимых процедур, достоверность данных, целостность данных, триггеры и функции, а также производительность базы данных, правильность добавления и удаления записей.
- Классы эквивалентности
- Граничные значения
- Таблица принятия решений
- Попарное тестирование
- Причина-следствие
- Предугадывание ошибок
37. Принципы тестирования (их 7)
- Тестирование показывает ошибки, а не их отсутствие
- Исчерпывающее тестирование недостижимо
- Раннее тестирование сохраняет время и деньги
- Кластеризация ошибок
- Парадокс пестецида
- Тестирование зависит от контекста
- Заблуждение об отсутствии ошибок
Можно снимать различные метрики, главное, чтобы они помогали в улучшении качества ПО. Например:
- Passed/Failed Test Cases. Используется для оценки отношения удачно пройденных тестов к завершившимся с ошибками. Метрика помогает оценить успешность прохождения тестов.
- Open/Closed Bugs. Формируется из отношения открытых багов к закрытым. Метрика оценивает скорость устранения багов, а также позволяет выявить причины, по которым ошибки остались незакрытыми.
- Reopened/Closed Bugs. Рассчитывает соотношение переоткрытых багов к закрытым. Метрика демонстрирует эффективность закрытия бага разработчиками и поможет выявить причины, по которым исправление ошибок находится на низком уровне.
- Bugs by Severity/Priority. Общее количество багов по серьёзности/приоритету. Метрика показывает качество предоставляемого кода на тестирование.
39. Реляционные и нереляционные БД
Реляционная - данные хранятся в виде таблиц и строк. Используется язык SQL
Нерялционные - данные хранятся в коллекциях документов JSON
40. Первичный ключ - используется в качестве уникального идентификатора для всех записей в таблице. Не может быть NULL и должен быть уникальным
41. Внешний ключ - это атрибут или набор атрибутов, ссылающийся на первичный ключ в какой-нибудь другой таблице. В общем, он используется для связи между двумя таблицами.
HAVING - выборка всех данных и отделение тех из них, которые соответствуют заданным условиям. Используется после GROUP BY.