Alex Compass

Подготовка к собесу

2024-03-29T10:16:23.940Z

ОСНОВНЫЕ ВИДЫ ТЕСТИРОВАНИЯ ПО

Все классификации тестирования:

Классификация по запуску кода на исполнение:

Статическое тестирование
Динамическое тестирование

Классификация по доступу к коду и архитектуре:

Тестирование белого ящика
Тестирование серого ящика
Тестирование чёрного ящика

Классификация по уровню детализации приложения (Пирамида тестирования):

Модульное тестирование или юнит-тестирование (англ. unit testing)
Интеграционное тестирование (Integration testing)
Системное тестирование (System testing)
Приёмочное тестирование (acceptance test):
А) Пользовательское приемное тестирование
Б) Эксплуатационное
В) На соответствие контракту

Классификация по принципам работы с приложением

Позитивное тестирование
Негативное тестирование

Классификация по целям тестирования

Функциональное тестирование
Нефункциональное тестирование

Функциональное тестирование

Smoke test
Тестирование критического пути
Расширенное тестирование

Нефункциональное тестирование

Тестирование доступности
Тестирование локализации и интернетизации
Тестирование безопасности
Проверка удобства
Нагрузочное тестирование
Стресс-тестирование
Тестирование стабильности
Инсталляционное тестирование

Классификация по цели тестирования

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

Классификация по запуску кода на исполнение:

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

Классификация по доступу к коду и архитектуре:

Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

Классификация по уровню детализации приложения (Пирамида тестирования):

Модульное тестирование или юнит-тестирование (англ. unit testing) — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
Модульное тестирование производят сами разработчики, не тестировщики.
Интеграционное тестирование (Integration testing) — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
Взаимодействие компонентов, модулей и иных систем между собой. Тестирование части системы, состоящей из 2-х и более модулей.
Системное тестирование (System testing) — тестирование взаимодействия между всеми компонентами системы или разных систем между собой или тестирование интерфейсов, между которыми взаимодействует система. Полная проверка приложения, всех модулей, можно ли пройти весь бизнес путь.
Приёмочное тестирование (acceptance test) — тестирование на сдаче приемки всего программного продукта или его части Заказчику
А) Пользовательское приемное тестирование (User Acceptance Testing) – перед релизом собирается группа конечных пользователей, тестируется основной функционал, при наличии дефектов-устраняются.
Б) Эксплуатационное (Operational acceptance testing) – производится пользователем или администратором в среде, которая имитирует реальные условия эксплуатации ПО, производится тестирование резервного копирования, аварийное восстановление системы, безопасность ПО.
В) На соответствие контракту – на соответствие гостов, нормативных актов и т.д

Классификация по принципам работы с приложением

Позитивное тестирование — тестирование, при котором используются только корректные данные.
Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.

Классификация по целям тестирования

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

Функциональное тестирование

Smoke test — тестирование, которое проводится после появления нового билда . Направлено на проверку готовности разработанного продукта к проведению расширенного тестирования и определения общего качества продукта.
Проверяет заявленную бизнес-логику ПО.
Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
Основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при их стандартном использовании.
Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Проверка нестандартного использования продукта (например, вводить не корректные логин и пароль в окне авторизации, работать на многих вкладках одновременно, подгрузка файлов недопустимых размеров или форматов. Максимально загружать нашу систему, проводить множество негативных тестов.

Нефункциональное тестирование

Тестирование доступности - доступно ли людям с ограниченными возможностями.
Пример: Может ли человек, получив голосовое, прослушать его из верхнего динамика.
Тестирование локализации и интернетизации - тестирование с целью проверки адаптации ПО к любой культуре или особенностям языка другой страны.
Пример: Можно ли писать сообщения иероглифами (поддерживает ли кодировку)(локализация) или есть ли функция в мессенджере для оповещения о молитвенном времени (интернационализация).
Тестирование безопасности - тестирование направленное на проверку безопасности конфиденциальных данных и защиту от хакерских атак, вирусов и тд.
Пример: Отправить файл, зараженный вирусом и проверить, пропустит ли его мессенджер. Или встроить в картинку инъекцию.
Проверка удобства - тестирование направленное на удобство пользования и дизайна.
Пример: Проверить, удобно ли будет пользоваться одной рукой, не режет ли глаз цвета, не маленькая ли кнопка отправить и тд.
Нагрузочное тестирование - проводимое тестирование использования в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, и им пользуются 10 человек, отправляя сообщения и допустимые файлы допустимых размеров.
Стресс-тестирование - нагрузка, превышающая норму в несколько раз.
Пример: Сервер мессенджера рассчитан на 10 человек, а им одновременно пользуются 30 человек, активно отправляя сообщения, фото и файлы друг другу.
Тестирование стабильности - тестирование, направленное на продолжительное испытание в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, им пользуются 10 человек в рамках стандартного использования в течении месяца (переписываются, отправляют картинки и тд).
Инсталляционное тестирование - тестирование, направленное на проверку установки, обновления и удаления приложения.
Пример: Скачать приложение, установить его, удалить, установить еще раз и после обновить.

Классификация по цели тестирования

Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.
То есть, как только разработчик выполнил свою часть работы, по созданию новой функциональности, он передает ее на тестирование.
Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.
Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил.
Регрессионное тестирование проводится: - после появления нового билда (новой версии нашего продукта)
- тестирование того функционала в котором часто обнаруживаются дефекты
- плановое тестирование
- того функционала, который часто меняется в ходе разработки

ТЕСТИРОВАНИЕ И QA/QC, ЖИЗНЕННЫЕ ЦИКЛЫ

Баг – это дефект – это отклонение ожидаемого поведения работы программного продукта от фактического.

Что такое тестирование программного обеспечения?

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

Что такое контроль качества и обеспечение качества?

Контроль качества QC (Quality Control) — это тщательное тестирование программы на наличие дефектов, а также проверка того, что программное обеспечение соответствует всем требованиям, выдвинутым заказчиком.

Обеспечение качества QA (Quality assurance) – это подход, который помогает убедиться, что методы, технологии и процессы, используемые для создания качественных результатов, применяются правильно.

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

Принцип 1 — Тестирование демонстрирует наличие дефектов

Принцип 2 — Исчерпывающее тестирование невозможно

Принцип 3 — Раннее тестирование

Принцип 4 — Скопление дефектов

Принцип 5 — Парадокс пестицида

Принцип 6 — Тестирование зависит от контекста

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

Что такое SDLC (Жизненный цикл разработки программного продукта)?

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

Этапы SDLC:

Требования
Проектирование
Разработка
Тестирование
Релиз
Поддержка

Что такое STLC Жизненный цикл тестирования программного продукта?

Жизненный цикл тестирования программного продукта (STLC – Software testing lifecycle) - процесс, направленный на тестирование программного продукта.

Этапы STLC

Анализ требований
Тестовое планирование
Написание тестовых сценариев
Подготовка тестовой среды
Выполнение тестов
Завершающая фаза

ВСЕ О ТЕСТ-ДИЗАЙНЕ

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

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Цели тест-дизайна:

Придумать тесты которые смогли бы обнаружить наиболее серьезные ошибки для ПО
Минимизация количества тестов

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

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

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

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

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

Сценарное тестирования - инструмент, подразумевающий прохождение пути пользователя.

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

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

ДОКУМЕНТАЦИЯ (кейсы, листы, репорты)

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

Чек-лист

Чек-лист- список проверок, в котором мы указываем, что мы будем тестировать, результат и статус проверок.

Чек-лист включает в себя следующие атрибуты:

Проект
Цель проверки
Идентификатор
Требования
Дата проведения
Исполнитель
Среда тестирования
Тип тестов
Название проверок
Результат проверки

Тест-кейс

Тест-кейс – пошаговый сценарий, описывающий как проводится тестирование, и включающий более детализированные проверки (шаги).

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

Обязательные атрибуты тест-кейсов

Название проекта
ID
Требования
Модуль
Название
Приоритет
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Среда тестирования
Шаги-теста
Ожидаемый результат

Тестовый набор

Тестовый набор (Testsuite) – набор тест-кейсов, объединенный по одному модулю или цели проверки.

Включает в себя те же атрибуты, которые и включает в себя тест-кейс.

Баг-репорт

Баг-репорт – это отчет об ошибках

Атрибуты баг-репорта

Проект
Название документа
Ссылка на требования
Цель проверки
Дата проведения
Исполнитель
Среда тестирования
Шаги теста
Ожидаемый результат
Фактический результат
Статус бага
Серьезность бага
Приоритет устранения бага
Прикрепленный файл

Серьезность бага:

Серьезность (severity) – показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

У серьезности могут быть следующие статусы:

Blocker – блокировка, работа ПО невозможна
Critical –критический, приводит наш функционал в нерабочее состояние
Major-серьезные ошибки, которые свидетельствуют об отклонении работы от БЛ или нарушающие работу программы, но не имеют критическое воздействие на ПО
Minor – незначительный дефект не нарушающий функционал нашего приложения, который является несоответствием ожидаемого результата (ошибка дизайна, пример)
Trivial –не имеет влияния на функционал и работу нашей программы, но может быть обнаружен визуально.

Приоритет бага:

Приоритет - показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, team-lead или заказчиком.

P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения.
P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения.

КЛИЕНТ - СЕРВЕРНАЯ АРХИТЕКТУРА

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

2 вида клиент-серверной архитектуры:

С базами данных
Без баз данных

Что включает в себя КСА:

Клиент
Сервер
Базы данных
Промежуточное ПО - драйверы, набор протоколов, язык SQL
Прикладной программный интерфейс (API) - набор функций и подпрограмм, обеспечивающих взаимодействие клиентов и серверов, набор методов, которые можно использовать для доступа функциональности к другой программе

Существует 2 вида клиентов:

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

Плюсы и Минусы Монолитной Архитектуры:

Плюсы:

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

Минусы:

Масштабирование: Затруднено горизонтальное масштабирование из-за требований к целостности данных.
Сложность обновлений: Изменения в большом приложении могут быть сложными и опасными.
Гибкость: Недостаточно гибкая для больших и комплексных проектов.

Плюсы и Минусы Микросервисной Архитектуры:

Плюсы:

Гибкость: Легко масштабировать и обновлять отдельные микросервисы.
Распределенная разработка: Команды могут работать независимо друг от друга на разных сервисах.
Отказоустойчивость: Если один сервис падает, другие могут продолжать работу.

Минусы:

Сложность управления: Необходимо учитывать большое количество сервисов и их взаимодействие.
Сложнее отлаживать: Взаимодействие между микросервисами может быть сложным для отладки.
Затраты на инфраструктуру: Дополнительные расходы на поддержку и развертывание сервисов.

HTTP ПРОТОКОЛЫ

HTTP- «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML.

Протокол – набор правил передачи информации. Мы регламентируем то, как будет передаваться в сети интернет наша информация.

Метод HTTP

GET - запрос для получения статуса, получение какой либо информации от сервера

POST – отправка данных, файлов

PUT – изменение данных

DELETE – удаление данных

Коды состояния запроса

100-е – это информационный код состояния, дает информационные сообщения.

200-е – информируют нас об успешной отработке запроса

300-е – это перенаправление, то есть, к примеру, когда был изменен url и нужно идти на другой.

400-е – обозначают что на стороне клиента есть ошибка.

500-е – это ошибка на стороне сервера.

Передача протокола осуществляется по Модели TCP/IP.

Уровни TCP/IP:

сетевые интерфейсы – передаются физические импульсы (оптоволокно) (протокол Ethernet)
сетевой – происходит передача физических сигналов, основной протокол –IP
транспортный – транспортные взаимодействия в нашей сети:

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

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

SOAP И REST

SOAP (Simple Object Access Protocol) — стандартный протокол. Четко структурирован и задокументирован.

REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети, основанный на методах протокола HTTP.

SOAP

Любое сообщение в протоколе SOAP — это XML документ

REST

REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол.

Управление данными происходит с помощью методов HTTP: GET, POST, PUT, DELETE.

Разница между архитектурным стилем и протоколом в том что к АС не применяются какие-то жесткие правила

REST (Representational State Transfer) и SOAP (Simple Object Access Protocol) - это два различных способа построения архитектуры для веб-сервисов. Вот основные различия между ними:

Принципы дизайна:
REST базируется на принципах архитектуры веб, таких как использование HTTP методов (GET, POST, PUT, DELETE), представление ресурсов через URL
SOAP основывается на строгих стандартах и предполагает использование XML для обмена сообщениями
Формат сообщений:
REST использует различные форматы для обмена данными, такие как JSON, XML, HTML, и другие.
SOAP использует только XML в качестве формата сообщений.
Простота и гибкость:
REST считается более простым и гибким для использования.
SOAP предлагает большую степень стандартизации
Производительность:
REST обычно обеспечивает более высокую производительность благодаря более легковесным форматам данных и возможности кэширования.
SOAP зачастую требует большего объема данных из-за использования XML, что может негативно отразиться на производительности.

Что выбрать SOAP или REST?

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

Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается действиями: чтение, добавление, изменение и удаление данных (те самые наши 4 метода get, post, put, delete ) — смело выбирайте REST. Он наиболее популярен и быстр.

POSTMAN И API

API – интерфейс, который определяет, как одна программа должна взаимодействовать с другой программой.

Типы API:

Локальные API - то, что позволяет компонентам одной системы взаимодействовать между собой (микросервисная архитектура)
Удаленные API - позволяет связывать между собой несколько систем (SOAP и REST).

API появляется раньше GUI поэтому API тестируется раньше.

Как работает API:

Вызов операции (GET, POST, PUT, DELETE)
Входные данные (HTTP Request)
Выходные данные (РЕЕЗ Response)

Способы вызова API:

Вызов функции системой (прямой вызов)
Вызов метода другой системой (прямой вызов)
Вызов метода человеком (прямой вызов)
GUI -> API. (косвенный)

Коллекции в Postman представляют собой группы запросов, скриптов и переменных, организованные вместе для удобного управления и использования

Вот несколько основных целей использования коллекций в Postman:

Организация запросов:

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

Совместная работа:

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

Использование переменных и сред:

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

Управление тестами:

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

Сценарии и потоки работы:

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

МОБИЛЬНОЕ ТЕСТИРОВАНИЕ

Типы мобильных приложений:

Нативными - написаны на родном (с англ. native – родной) для определённой платформы языке программирования.

Web – веб-сайт, адаптированный для нашего мобильного приложения.
Веб-приложение, представляет собой сайт, который адаптирован и оптимизирован под любой смартфон.

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

Тестирование и особенности тестирования мобильных приложений

Зависимости мобильного тестирования:

1. Интернет:

- тип соединения

- изменение типа соединения

- качество соединения

- потеря связи

2.Проверки на прерывание:

- исходящие/входящие вызовы

- всплывающие окна/уведомления

- прерывания при разрядке/подзарядке

- сворачивание/разворачивание приложения

3.Тестирование установки

Установка.

Удаление и переустановка.

Обновление.

4.Работа с функциями телефона:

- GPS

- видео/фото

- размер экрана, разрешение, ориентация

- работа с жестами

- отпечаток пальца, узнавание лица, пароль, графический ключ

- клавиатура

- Bluetooеh

- работа со съемными картами памяти

- нажатие

- комбинации кнопок

- динамики, микрофоны, гнездо для гарнитуры

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

- загрузка оперативной памяти

- зависимость от заряда батареи

- запуск с внутренней памяти/ с накопителя

6. Тестирование на соответствие гайдлайнам и мокапам

ЛОКАЛИЗАЦИЯ БАГА

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

Локализация - это поиск первопричины возникновения ошибки.

Нужно проверить себя еще раз: воспроизвести баг снова при тех же условиях. Если ошибка не повторилась при очередном тестировании, то нужно разобраться, точно ли были соблюдены все действия и шаги воспроизведения, приведшие к этому результату. Для того, чтобы более точно определить условия воспроизведения ошибки, необходимо эту ошибку локализовать.

Чтобы локализовать баг, необходимо собрать максимальное количество информации о его воспроизведении:

Выявить причины возникновения дефекта
Проанализировать возможность влияния найденного дефекта на другие области
Отклонение от ожидаемого результата
Исследовать окружение
Проверить на разных устройствах
Проверить в разных версиях ПО
Проанализировать ресурсы системы

Локализация бага на интеграционном уровне

Локализация бага (дефекта) включает в себя процесс анализа проблемы с целью выявления максимальной детализации причины ее возникновения. Чем больше информации о проблеме собрано, тем быстрее ее решит команда.

DEVTOOLS

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

СНИФФЕРЫ

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

Самые популярные инструменты: Charles и Fiddler.

Charles

При работе в браузере все запросы и ответы будут отображаться в программе.

Можно выбирать запрос и нажать на Focus. И тогда можно отслеживать именно этот запрос. Так же, как и в devtools.

Что можно посмотреть в запросах: header, body, служебную информацию, статус коды, методы (http).

Так же можно с помощью Charles отслеживать трафик с телефона или эмулятора. Для этого в настройках WiFi нужно выбрать сеть, к которой подключен компьютер с Charles на борту и подключится к той же WiFi сети, а так же настроить прокси для этой сети. В прокси нужно вписать ip адрес компьютера. Порт - 8888. Так же на телефоне нужно установить сертификат чтобы перехватывать трафик.

Что можно тестировать в Charles:

Переадресация (Tools - Map Remote). Можно выставить поведение при переадресации. Например, чтобы с сайта google.com происходила переадресация на ya.ru.
Подмена (Tools - Rewrite). Используется чаще всего. Можно подменить запросы, URL, ответы, отдельные параметры, отдельные header.
Подмена ответа сервера в целом (Tools - Map Local). Например, работаем на сайте и загружаем определенную картинку или заказчик что то загрузил на сайт и появилась ошибка. Нужно запросить у заказчика материал и попробовать повторить его путь. Берем эту картинку, добавляем ее в body и смотрим, что происходит. Тогда могут пригодится ответы сервера.
Занижать скорость интернета (Tools - Enable Trottling).
Работа с breakpoint (Proxy - Breakpointing Settings). Можно ставить как для ответа, так и для запроса.

SQL

Первичный и внешний ключи:

Первичный ключ (PRIMARY KEY) - это уникальный идентификатор для каждой строки в таблице. Он используется для определения единственности данных и обеспечения быстрого доступа к ним.
Код: PRIMARY KEY

Внешний ключ (FOREIGN KEY) - это отношение между двумя таблицами, которое устанавливает связь между ними. Внешний ключ используется для ограничения взаимосвязи между таблицами и предотвращения несоответствий данных. Внешний ключ ссылается на первичный ключ другой таблицы.
Код: band_id INTEGER REFERENCES band(band_id)

Типы взаимосвязи таблиц SQL

1. Связь один ко многим (one-to-many): Это тип взаимосвязи, когда одна запись в одной таблице может относиться к нескольким записям в другой таблице.

2. Связь многие ко одному (many-to-one): Это тип взаимосвязи, когда несколько записей в одной таблице могут относиться только к одной записи в другой таблице.

3. Связь один к одному (one-to-one) - это тип взаимосвязи между двумя таблицами в базе данных, когда каждая запись в одной таблице связана с только одной записью в другой таблице.

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

Inner Join и Outer Join

INNER JOIN - способ соединения таблиц, при котором остаются те строки, где значения ключа совпадают в обеих таблицах.

LEFT OUTER JOIN - способ соединения таблиц, при котором возвращаются все строки из левой таблицы и соответствующие строки из правой таблицы. Если в правой таблице нет соответствующих строк, тогда возвращает NULL

FULL OUTER JOIN - способ соединения таблиц, при котором возвращаются строки из обеих таблиц. Если в левой или правой таблице нет соответствующих данных для второй таблицы - тогда подставляется NULL

Основные запросы:

CREATE - Создает новую таблицу, представление таблицы или другой объект в БД

DROP - Удаляет существующую таблицу

SELECT - Извлекает записи из одной или нескольких таблиц

INSERT - Создает записи

UPDATE - Модифицирует записи

DELETE - Удаляет записи

AND - Объединяет условия

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

IN - Выполняет поиск значения в списке значений

LIKE - Сравнивает значение с похожими

NOT - Инвертирует (меняет на противоположное) смысл других логических операторов

OR - Комбинирует условия (одно из условий должно совпадать)

IS NULL - Определяет, является ли значение нулевым

UNIQUE - Определяет уникальность строки

KAFKA, СИНХРОННОЕ И АСИНХРОННОЕ ВЗАИМОДЕЙСТВИЕ

Kafka

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

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

Плюсы Кафки:

Более высокая производительность.
Все сообщения после прочтения не удаляются и могут быть прочитаны консьюмерами повторно. Удаление задается вручную.
Из Кафки нельзя удалить конкретное сообщение (партицию), а только удалить топик целиком.
При перезапуске консьюмера в брокере сохраняется коммит (снимок состояния), и тем самым происходит фиксация и консьюмер продолжает читать.

Синхронное взаимодействие:

Определение: В синхронном взаимодействии одна часть программы ждет завершения другой части программы, прежде чем продолжить свое выполнение.

Асинхронное взаимодействие:

Определение: В асинхронном взаимодействии части программы могут работать параллельно без ожидания завершения друг друга.

Шпаргалка для собеса тестировщика

2024-03-20T21:16:54.106Z

1. Что такое тестирование программного обеспечения?

2. Что такое контроль качества и обеспечение качества?

3. Что такое SDLC (Жизненный цикл разработки программного продукта)?

Этапы SDLC:

Требования
Проектирование
Разработка
Тестирование
Релиз
Поддержка

4. Что такое STLC Жизненный цикл тестирования программного продукта?

Этапы STLC

Анализ требований
Тестовое планирование
Написание тестовых сценариев
Подготовка тестовой среды
Выполнение тестов
Завершающая фаза

5. Что такое тест-кейс?

6. Атрибуты тест-кейсов, что в себя включает тест-кейс?

Название проекта – здесь указывается название проекта, для которого мы пишем сценарии проверки
ID – это уникальный Идентификатор, уникальный номер тест-кейса, в нашей системе, на одном проекте не должно быть 2-х одинаковых тест-кейсов, это необходимо для того чтоб мы могли всегда корректно ссылаться на наш документ, при общении с другими коллегами, указанием в других системах и т.д.
Требования – ссылка на документ, на основании которого составлен данный документ
Модуль – название модуля к которому относится данный функционал
Название - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте
Приоритет - показывает, на сколько важно проведение данного теста
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Тестировщик самостоятельно выставляет данный приоритет, основываясь на своем опыте.
Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
Шаги-теста – самый главный атрибут нашего документа, в котором мы подробно расписываем все шаги прохождения нашего теста
Ожидаемый результат – в данном атрибуте мы указываем, а какой именно результат мы ожидаем получить, после того как мы выполним данный шаг, очень важно писать результат по каждому шагу, а не один для всех шагов. Это позволит любому члену команды повторить данный тест.

7. Что такое тестовый набор?

Тестовый набор (Testsuite) – набор тест-кейсов, объединенный по одному модулю или цели проверки.

8. Атрибуты тестового набора, что в себя включает тестовый набор?

Они дублируют с атрибутами тест-кейсов.

ID тест-кейса
Название проекта
Модуль
Описание теста
Ожидаемый результат
Приоритет - показывает, на сколько важно проведение данного теста:
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Дата проведения теста
Исполнитель
Среда тестирования
Статус

9. Что такое чек-лист?

Чек-лист- список проверок, в котором мы указываем, что мы будем тестировать, результат и статус проверок.

10. Атрибуты чек-листа, что включает в себя чек-лист?

Проект – здесь указывается название проекта, для которого мы пишем сценарии проверки;
Цель проверки - здесь идет название модуля который будет проверять в данном документе;
Идентификатор -это уникальный Идентификатор документа;
Требования - ссылка на документ, на основании которого составлен данный документ;
Дата проведения;
Исполнитель;
Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
Тип тестов;
Название проверок - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте;
Результат проверки

11. Что такое план тестирования?

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

12. Для чего проводится тестирование ПО?

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

13. Принципы тестирования

Принцип 1 — Тестирование демонстрирует наличие дефектов
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
Принцип 2 — Исчерпывающее тестирование невозможно
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
Принцип 3 — Раннее тестирование
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
Принцип 4 — Скопление дефектов
Большая часть дефектов находится в ограниченном количестве модулей.
Принцип 5 — Парадокс пестицида
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Принцип 6 — Тестирование зависит от контекста
Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
Принцип 7 — Заблуждение об отсутствии ошибок
Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

14. В чем разница между верификацией и валидацией?

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

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

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

16. Что такое баг и баг-репорт?

Баг – это дефект – это отклонение ожидаемого поведения работы программного продукта от фактического.

Баг-репорт – это отчет об ошибках.

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

17. Атрибуты баг-репорта

Проект
Название документа
Ссылка на требования
Цель проверки
Дата проведения
Исполнитель
Среда тестирования
Шаги теста
Ожидаемый результат
Фактический результат
Статус бага
Серьезность бага
Приоритет устранения бага
Прикрепленный файл

18. Приоритет устранения и серьезность бага

У серьезности могут быть следующие статусы:

Blocker – блокировка, работа ПО невозможна
Critical –критический, приводит наш функционал в нерабочее состояние, отклонение от БЛ ПО, не реализация функций, потеря пользовательских данных
Major-серьезные ошибки, которые свидетельствуют об отклонении работы от БЛ или нарушающие работу программы, но не имеют критическое воздействие на ПО
Minor – незначительный дефект не нарушающий функционал нашего приложения, который является несоответствием ожидаемого результата (ошибка дизайна, пример)
Trivial –не имеет влияния на функционал и работу нашей программы, но может быть обнаружен визуально.

P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения.
P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Основные виды тестирования ПО

19. Классификация по запуску кода на исполнение:

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

20. Классификация по доступу к коду и архитектуре:

Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

21. Классификация по уровню детализации приложения (Пирамида тестирования):

Модульное тестирование или юнит-тестирование (англ. unit testing) — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
Модульное тестирование производят сами разработчики, не тестировщики.
Интеграционное тестирование (Integration testing) — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
Взаимодействие компонентов, модулей и иных систем между собой. Тестирование части системы, состоящей из 2-х и более модулей.
Системное тестирование (System testing) — тестирование взаимодействия между всеми компонентами системы или разных систем между собой или тестирование интерфейсов, между которыми взаимодействует система. Полная проверка приложения, всех модулей, можно ли пройти весь бизнес путь.
Приёмочное тестирование (acceptance test) — тестирование на сдаче приемки всего программного продукта или его части Заказчику
А) Пользовательское приемное тестирование (User Acceptance Testing) – перед релизом собирается группа конечных пользователей, тестируется основной функционал, при наличии дефектов-устраняются.
Б) Эксплуатационное (Operational acceptance testing) – производится пользователем или администратором в среде, которая имитирует реальные условия эксплуатации ПО, производится тестирование резервного копирования, аварийное восстановление системы, безопасность ПО.
В) На соответствие контракту – на соответствие гостов, нормативных актов и т.д

22. Классификация по принципам работы с приложением

Позитивное тестирование — тестирование, при котором используются только корректные данные.
Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.

23. Классификация по целям тестирования

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

24. Функциональное тестирование

Smoke test — тестирование, которое проводится после появления нового билда . Направлено на проверку готовности разработанного продукта к проведению расширенного тестирования и определения общего качества продукта.
Проверяет заявленную бизнес-логику ПО.
Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
Основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при их стандартном использовании.
Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Проверка нестандартного использования продукта (например, вводить не корректные логин и пароль в окне авторизации, работать на многих вкладках одновременно, подгрузка файлов недопустимых размеров или форматов. Максимально загружать нашу систему, проводить множество негативных тестов.

25. Нефункциональное тестирование

Тестирование доступности - доступно ли людям с ограниченными возможностями.
Пример: Может ли человек, получив голосовое, прослушать его из верхнего динамика.
Тестирование локализации и интернетизации - тестирование с целью проверки адаптации ПО к любой культуре или особенностям языка другой страны.
Пример: Можно ли писать сообщения иероглифами (поддерживает ли кодировку)(локализация) или есть ли функция в мессенджере для оповещения о молитвенном времени (интернационализация).
Тестирование безопасности - тестирование направленное на проверку безопасности конфиденциальных данных и защиту от хакерских атак, вирусов и тд.
Пример: Отправить файл, зараженный вирусом и проверить, пропустит ли его мессенджер. Или встроить в картинку инъекцию.
Проверка удобства - тестирование направленное на удобство пользования и дизайна.
Пример: Проверить, удобно ли будет пользоваться одной рукой, не режет ли глаз цвета, не маленькая ли кнопка отправить и тд.
Нагрузочное тестирование - проводимое тестирование использования в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, и им пользуются 10 человек, отправляя сообщения и допустимые файлы допустимых размеров.
Стресс-тестирование - нагрузка, превышающая норму в несколько раз.
Пример: Сервер мессенджера рассчитан на 10 человек, а им одновременно пользуются 30 человек, активно отправляя сообщения, фото и файлы друг другу.
Тестирование стабильности - тестирование, направленное на продолжительное испытание в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, им пользуются 10 человек в рамках стандартного использования в течении месяца (переписываются, отправляют картинки и тд).
Инсталляционное тестирование - тестирование, направленное на проверку установки, обновления и удаления приложения.
Пример: Скачать приложение, установить его, удалить, установить еще раз и после обновить.

25.1. Классификация по цели тестирования

Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.
То есть, как только разработчик выполнил свою часть работы, по созданию новой функциональности, он передает ее на тестирование.
Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.
Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил.
Регрессионное тестирование проводится:
- после появления нового билда (новой версии нашего продукта)
- тестирование того функционала в котором часто обнаруживаются дефекты
- плановое тестирование
- того функционала, который часто меняется в ходе разработки

26. Что такое Тест-дизайн?

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

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

Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, при которой мы разделяем диапазон возможных вводимых значений на группы эквивалентных по своему влиянию на систему значений.
Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на граничных значениях входных данных.
Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

f-строки (очень удобно)

2024-03-07T21:14:08.388Z

Код внутри скобок

Когда вы указываете перед стройкой f python воспринимает её как необычную строку и каждое содержимое фигурных скобок он будет воспринимать как выражение на языке программирования. В фигурных скобках вы можете писать свои какие-либо выражения и никто не запрещает вам воспользоваться математическими операциями.

Вы можете пользоваться всеми возможностями ваших объектов. В нашем случае переменная name является строкой и мы знаем что у каждой строки есть метод lower. Давайте мы применим метод lower делает все буквы строки маленькими.

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

Внутри скобок вы можете также вызвать другие функции. Например, мы можем вызвать функцию abs() от отрицательного числа

Вывод переменных

С обозначением переменных

Начиная с версии Python 3.8 функционал f-строк был дополнен новой возможностью по выводу имён переменных и их значений. Посмотрите как теперь это можно сделать:

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

Формат вывода дробной части числа

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

Ответ простой - форматировать. F-строки поддерживают функционал форматирования. Мы указываем специальным образом после имени переменной сколько символов ожидаем увидеть.

Запись c:.3f говорит, что переменную c нужно представить в вещественном виде (это знак f) и отобразить три символа после запятой. Если у переменной c не хватает символов для трех знаков, проставятся нули. Если символов в избытке, произойдет округление до третьего символа после запятой.

Над целыми числами тоже можно так издеваться)

Формат вывода целых чисел

Пробелы перед числом (выравнивание)

При помощи f-строк мы можем влиять и на отображение целых чисел.

Запись n:7d говорит, что переменную n нужно представить в виде целого числа (это знак d ) и на отображение всего числа выделить 7 знаков. Если у переменной n не хватает разрядов до семи, то впереди отображения появятся знаки пробелов.

Выравнивание с помощью нулей (добавление в начало нулей)

Можно вместо пробелов добавить незначащие нули, для этого нужно подписать 0 перед количеством разрядов

Разделение разрядов числа (например, вместо 1000000 - 1_000_000)

Можно также влиять на знак разделителя между группами чисел, посмотрите пример ниже

Выравнивание

Существует несколько способов выравнивания переменных в f-строках. Различные варианты выравнивания следует:

< - Выравнивает выражение в фигурных скобках по левому краю. У строк такое поведение по умолчанию

> - Выравнивает выражение в фигурных скобках по правому краю. У чисел такое поведение по умолчанию

^ - Выравнивает выражение в фигурных скобках по центру

Ниже приведен пример использования выравнивания как для чисел, так и для строк.

Символы "|" используются в f-строке, чтобы помочь очертить интервал. Число после «:» указывает на количество символов в ширину.

По умолчанию символом заполнителем является пробел, но можно его заменить на другое значение

Практический пример выравнивания

Давайте с вами смоделируем чек покупки. Пример ниже

14.5 Создание запросов в ручную

2024-02-21T16:15:56.723Z

Создаем первый тестовый сценарий

Сымитируем следующую деятельность пользователя:

1. Пользователь открыл Википедию для того, чтобы открыть какую либо статью.

2. Далее ему нужно нажать кнопку поиска либо ввести какие то данные в поле "Искать в Википедии". Но в нашей ситуации он нажал кнопку "Поиск".

3. Перешли на поисковую страницу с полем для запроса и фильтрами.

4. Пользователь вводит в поле поиска слово "Париж" и нажимает кнопку "Найти". Ему выдаются результаты поиска.

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

Мы обозначили тот тестовый сценарий, который мы выполнили.

Теперь запишем по запросам все шаги:

Jmeter - это не браузер, не Selenium. В процессе работы мы не обращаемся к браузеру, а работаем только с конечными точками (с ссылками). А на основании расположения запросов создаем сценарий.

Если запустить тест с 5 пользователями, то нарушается порядок прохождения тестов

13.4 Методика нагрузочного тестирования

2024-02-21T14:55:56.911Z

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

Давайте более подробней пройдемся по каждому пункту:

1. Цели тестирования, их разделяют:

Технические цели – например, тестирование надежности, отказоустойчивости и т.д.

Бизнес цели – к примеру, изменение информационной инфраструктуры или системы, то есть проверка нового ПО и его функционала.

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

3. Стратегия тестирования - он включает в себя описание проводимых испытаний для каждой цели тестирования.

Давайте рассмотрим пример:

Тестирование надежности

Тест надежности выполняется на уровне нагрузки:

1. Нагрузка системы в количестве 70-90 % от уровня найденной максимальной производительности.

2. При повторном тестировании и тестировании нового функционала нагружаем на 100-120% от пиковой производительности нашей системы. Что это значит, мы анализируем нагрузку, которая поступает на наш сервер в течении всей недели, отбираем к примеру день, когда у нас максимальная нагрузка, отбираем час, когда у нас максимальная нагрузка (например это 11 часов дня, в это время у нас самое большое количество пользователей на нашем сайте, они совершают максимальную нагрузку нашего сервера) мы берем либо этот час, либо среднее по всем часам, например, суммируем всю нагрузку с 11-12:00 и делим на 7. Это наш показатель, от которого мы отталкиваемся и нагружаем нашу систему на 100-120%, если система выдерживает данную нагрузку, значит и с остальной она справится.

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

И так по каждой цели тестирования, то есть данный раздел очень объемным.

Мы обязательно должны указать в данном разделе критерии успешного завершения нагрузочного тестирования являются:

1)выполнение всех запланированных тестов

2)получение данных с мониторинга

4. Тестовый стенд

Здесь указывается:

1)архитектура тестового стенда – описание самого стенда, описание смежных систем

2)требования к оборудованию тестового стенда, его характеристики

3)очень важны пункт – сравнение тестового и пользовательского, так как нам очень важно, чтобы они были равны

5. Моделирование нагрузки - описанием процессов, операций, которые проводят пользователи в нашей системе.

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

Так же здесь у нас указывается профиль нагрузки, где у нас идут данные за весь месяц 24 на 7.

6. Описание заглушек и эмуляторов, в которых мы описываем их характеристики и что они выполняют

7. Базы данных

В нем описываются характеристики БД, ее наполнение, то есть количество данных в ней

8. Мониторинг

Мониторинг необходим для сбора характеристик производительности компонент системы. В данном разделе описывается вспомогательное ПО для проведения мониторинга

Как вы уже могли понять данный документ очень Важен и к его составлению необходимо подходить очень тщательно

13.3 Этапы нагрузочного тестирования

2024-02-21T14:36:49.345Z

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

Основные этапы проведения нагрузочного тестирования:

Определение и постановка задач.
Подготовка тестового стенда и средства тестирования.
Подготовка тестового плана (методики НТ).
Настройка тестового стенда и вспомогательного ПО.
Проведение нагрузочных тестов.
Подготовка отчетов и анализ результатов тестирования.

1. Определение и постановка задачи

На данном этапе:

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

2. Подготовка тестового стенда и средств тестирования

На данном этапе:

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

3. Подготовка тестового плана или как его еще называют методики Нагрузочного Тестирования

На данном этапе:

Написание тест-кейсов.
Согласование сроков.
Согласование участников тестирования.
Частота проведения тестов.

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

4. Настройка тестового стенда и вспомогательного ПО

Окончательная настройка нашего стенда, вспомогательного ПО, подготовка эмуляторов и заглушек для нашей системы.

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

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

5. Проведение нагрузочного тестирования

Дымовое тестирование: В первую очередь мы проводим smoke тестирование, то есть прогоняем небольшие тесты, для того чтоб проверить что наша система вообще работает и выполняет свою основную бизнес-логику. Это обязательное условие перед полноценным тестированием, это можно сравнить с разведкой обстановки.
Определение максимальной производительности системы: Определение максимальной производительности, то есть мы хотим узнать предельные способности нашей системы, этот показатель очень важен для нас и будет в дальнейшем использоваться и сравниваться с другими показателями нашей системы.
90% от максимальной производительности системы: Нам необходимо повторно произвести определение максимальной производительности, процентов 90 от предыдущего значения, для того, чтоб убедиться что мы получили верные данные.
Тестирование надежности.

6. Подготовка отчета и анализ результата тестирования

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

13.2 Когда необходимо проводить нагрузочное тестирование

2024-02-21T13:01:07.864Z

Когда проводится нагрузочное тестирование:

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

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

3. Регрессионное тестирование или плановое тестирование - то есть тестирование, которое производится после разработки нового функционала или по плану( у вас есть определённое расписание, когда вы производите нагрузочное тестирование Вашего продукта);

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

5. Смена технологий - когда наша система переходит с одной базы данных на другую, меняется оборудование и мощности. Мы нагружаем нашу систему и смотрим, чтоб она работала в соответствии с требованиями, предъявленными к ней;

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

13.1 Введение в Нагрузочное тестирование. Цели нагрузочного тестирова

2024-02-21T12:44:58.700Z

От любой системы требуется быстро и правильно отвечать на запросы пользователей, то есть выполнять те команды и задачи, которые требует от нее пользователь. Например, выдавать результат поиска на поисковых сайтах, например Яндекс или Google, или отправка сообщения в социальных сетях и т.д.

Для чего нужно нагрузочное тестирование?

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

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

Для чего же необходимо производить нагрузочное тестирование, давайте разберем пример:

Все мы знаем про черную пятницу, это день скидок, когда мы можем купить товар с большой скидкой. Представим, что у нас есть интернет-магазин по продаже электроники, и для него норма производительности, скажем 1000 пользователей, одновременно находящихся на сайте и выполняющие определенные действия -регистрация, поиск товара, оформление товара, покупка.
Наступает черная пятница, и вместо 1000 человек, на нашем сайте одновременно находится 10000 человек, что же произойдет? Норма превышена в 10 раз и в лучшем случае сайт будет работать медленней, часть операций не будет проходить, а в худшем случае наш сервер вовсе выйдет из строя и хозяева данного ресурса понесут большие убытки.

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

Нагрузочное тестирование

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

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

Цели нагрузочного тестирования

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

2. Выявление проблемных участков или как их еще называют- «узких мест»;

3. Проверка стабильности (в некоторых источниках вы можете встретить название надежности) – длительная нагрузка нашей системы при нормальных условиях 70-80 % от максимума(который указан в требованиях и который должна выдерживать наша система);

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

4. Проверка системы под действием стресс-нагрузки – это тестирование, когда мы нагружаем нашу систему нагрузкой, которая в несколько раз превышает норму. Это как раз тот сценарий с черной пятницей в интернет-магазине, о котором я говорил;

5. Re-test, то есть проверка исправления ошибки - когда мы обнаружили проблемный участок в нашей системе, разработчики его поправили и мы производим повторную проверку;

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

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

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

Работа над ошибками в коммитах

2024-02-19T14:38:52.862Z

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

Например, в выводе команды git log --oneline умещается максимум 7272 первых символа сообщения, поэтому многие правила включают пункт: «Сообщение не должно быть длиннее 7272 символов».

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

Зачем вообще писать сообщения

У каждого коммита в Git есть сообщение — то, что передаётся после параметра -m. Например: git commit -m "Добавить урок про оформление сообщений коммитов".

Сообщения коммитов можно сравнить с надписями на коробках в кладовке. Если надписей нет, то нужную коробку будет сложно найти: придётся заглянуть в каждую, чтобы понять, что там. А если надписи есть, то нужная найдётся сразу.

Как и надпись на коробке, сообщение коммита должно помочь определить, что внутри. Например, надпись на коробке «всякое разное» не очень полезная. Сообщение коммита «небольшие исправления» тоже: непонятно, что было исправлено в таком коммите и зачем.

Есть общие рекомендации по тому, как правильно составить сообщение. Оно должно быть:

относительно коротким, чтобы его было легко прочитать;
информативным.

Вот пример полезного сообщения в репозитории новостного сайта: Исправление опечатки в заголовке главной страницы на хорватском. Такое сообщение даёт много информации:

Исправление опечатки значит, что исправлена ошибка, которая была допущена при наборе. Такое исправление не меняет смысл. То есть, например, главному редактору не нужно перепроверять этот заголовок.
На хорватском говорит о том, что переводчикам на другие языки этот коммит можно смело пропускать.
В заголовке главной страницы указывает, где произошли изменения. Если, например, кто-то зайдёт на сайт и ему не понравится новый заголовок, он легко найдёт по истории (git log) автора этого коммита и спросит у него, почему заголовок теперь такой.

Пример плохого сообщения для того же коммита: Исправлена опечатка. Это сообщение даёт мало информации. В такой коммит придётся «заглядывать» — разбираться, что именно поменялось и зачем.

Стили оформления

Все люди разные и у всех есть предпочтения — в том числе, как формулировать сообщения коммитов. Кто-то использует инфинитивы: Исправить сообщение об ошибке E123, кто-то — глаголы в прошедшем времени: Исправил…, кто-то — существительные: Исправление….

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

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

Например, правила могут быть такие:

длина сообщения от 3030 до 7272 символов;
первое слово — глагол в инфинитиве («исправить», «дополнить», «добавить» и другие);
и так далее.

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

Корпоративный

Во многих компаниях применяется Jira — система для организации проектов и задач. У каждой задачи в Jira есть идентификатор из нескольких заглавных латинских букв и номера. Например, LGS-239 значит, что это 239239-я задача в проекте LGS (сокращение от англ. logistics — «логистика»).

В корпоративном стиле в начале сообщения обычно указывают Jira-ID, а после — текст сообщения.

$ git commit -m "LGS-239: Дополнить список пасхалок новыми числами"

Какие-то команды могут договариваться, с какой части речи начинать сообщение и какой длины оно должно быть, какие-то — нет. Но требование о наличии Jira-ID обычно строгое: оно позволяет автоматически связывать коммиты с задачами и проектами.

Conventional Commits

Стандарт Conventional Commits (англ. «соглашение о коммитах») отличается качественной документацией и подробной проработкой. Он подходит для репозиториев с исходным кодом программ. Использовать его для других типов проектов (например, для перевода книги) было бы неудобно.Conventional Commits предлагает такой формат коммита: <type>: <сообщение>. Первая часть type — это тип изменений. Таких типов достаточно много. Вот два примера:

feat (сокращение от англ. feature) — для новой функциональности;
fix (от англ. «исправить», «устранить») — для исправленных ошибок.

Более подробный список можно увидеть на сайте с описанием этого стиля.

Например, сообщение может быть таким.

git commit -m "feat: добавить подсчёт суммы заказов за неделю"

GitHub-стиль

GitHub можно использовать не только для хранения файлов проекта, но и для ведения списка задач (англ. issue) этого проекта. Если коммит «закрывает» или «решает» какую-то задачу, то в его сообщении удобно указывать ссылку на неё. Для этого в любом месте сообщения нужно указать #<номер задачи>. Например, вот так.

$ git commit -m "Исправить #334, добавить график температуры"

В таком случае GitHub свяжет коммит и задачу.

Как исправить коммит

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

В таком случае можно внести правки в уже сделанный коммит с помощью опции --amend (от англ. amend — «исправить», «дополнить») у команды commit: git commit --amend. Разберём, как она работает.

💡 Важно: опция --amend работает только с последним коммитом (HEAD). Для исправления более ранних коммитов есть другие команды. Мы рассмотрим их в следующих модулях курса.

Подготавливаем репозиторий

Создайте тренировочный репозиторий для отработки команды.

$ mkdir ~/dev/commit-amend-fun
$ cd ~/dev/commit-amend-fun
$ git init
# пропустим вывод git init

Дополнить коммит новыми файлами — `git commit --amend --no-edit`

Представьте, что делаете небольшой сайт и для этого создали файл-страницу main.html, а также файл со стилями common.css.

$ touch main.html 
$ touch common.css 
# дальше отредактировали оба файла

В какой-то момент вы забыли о файле common.css и добавили в коммит только main.html.

$ git add main.html 
$ git commit -m "Добавить главную страницу" 
$ git log --oneline 
777fec3 Добавить главную страницу

Файл common.css так и остался «висеть» в untracked. В этом легко убедиться, если вызвать git status.

Дополните последний коммит забытым файлом common.css с помощью опции --amend.

$ git add common.css 
# добавили файл common.css в список на коммит как обычно 

# но вместо команды commit -m '...' 
# будет: 
$ git commit --amend --no-edit 

$ git log --oneline 
8340eb2 Добавить главную страницу 
# коммит в истории всё ещё один (но у него новый хеш)

С опцией --amend команда commit не создаст новый коммит, а дополнит последний, просто добавив в него файл common.css. При этом хеш последнего коммита изменится, потому что изменился список файлов в коммите.Обратите внимание на опцию --no-edit. Она сообщает команде commit, что сообщение коммита нужно оставить как было.

Точно так же можно добавить не новый файл, а дополнительные изменения в уже добавленном в коммит файле.

# ещё раз отредактировали main.html

$ git add main.html # добавили в список на коммит
$ git commit --amend --no-edit

💡 Что же выбрать: новый коммит или --amend?
В нашем примере вместо изменения последнего коммита можно было также выполнить новый коммит с одним файлом common.css. Кажется, что так проще, но добавить изменения в уже существующий коммит может быть правильнее.
Например, через месяц кто-то захочет просмотреть историю изменений. Намного проще понять, что изменилось, если оба файла находятся в одном коммите. Иначе коммит со второй порцией изменений придётся искать.

Изменить сообщение коммита — `git commit --amend -m "Новое сообщение"`

Может быть и так, что добавлять новые файлы в коммит не нужно, зато понадобилось изменить сообщение.

Допустим, хочется заменить сообщение Добавить главную страницу на Добавить главную страницу и стили. Сделать это можно через commit --amend с флагом -m.

$ git commit --amend -m "Добавить главную страницу и стили"
$ git log --oneline
a31fa24 Добавить главную страницу и стили

Хеш коммита снова поменялся, потому что изменились сообщение и время коммита. При этом файлы в коммите остались те же: main.html и common.css.

Как откатиться назад, если «всё сломалось»

На разных этапах работы с Git могут происходить похожие ситуации:

В список на коммит попал лишний файл (например, временный). Нужно «вынуть» его из списка.
Последние несколько коммитов ошибочные: например, сделали не то, что было нужно, или нарушили логику. Хочется «откатить» сразу несколько коммитов, вернуть «как было вчера».
Случайно изменился файл, который вообще не должен был меняться. Например, вы открыли не тот файл в редакторе и начали его исправлять.

В этом уроке рассмотрим такие случаи и научим вас «откатывать» нежелательные изменения.

Выполнить unstage изменений — `git restore --staged <file>`

Допустим, вы создали или изменили какой-то файл и добавили его в список «на коммит» (staging area) с помощью git add, но потом передумали включать его туда. Убрать файл из staging поможет команда git restore --staged <file> (от англ. restore — «восстановить»).

В терминале это будет выглядеть примерно так.

$ touch example.txt # создали ненужный файл
$ git add example.txt # добавили его в staged

$ git status # проверили статус
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   example.txt

$ git restore --staged example.txt
$ git status # проверили статус

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        example.txt

no changes added to commit (use "git add" and/or "git commit -a")
# файл example.txt из staged вернулся обратно в untracked

Вызов git restore --staged example.txt перевёл example.txt из staged обратно в untracked.

Чтобы «сбросить» все файлы из staged обратно в untracked/modified, можно воспользоваться командой git restore --staged .: она сбросит всю текущую папку (.).

«Откатить» коммит — `git reset --hard <commit hash>`

Иногда нужно «откатить» то, что уже было закоммичено, то есть вернуть состояние репозитория к более раннему. Для этого используют команду git reset --hard <commit hash> (от англ. reset — «сброс», «обнуление» и hard — «суровый»).

$ git log --oneline # хеш можно найти в истории
7b972f5 (HEAD -> master) style: добавить комментарии, расставить отступы
b576d89 feat: добавить массив Expenses и цикл для добавления трат # вот сюда и вернёмся
4b58962 refactor: разделить analyzeExpenses() на countSum() и saveExpenses()

$ git reset --hard b576d89
# теперь мы на этом коммите
HEAD is now at b576d89 feat: добавить массив Expenses и цикл для добавления трат

Теперь коммит b576d89 стал последним: вся дальнейшая разработка будет вестись от него. Файл также вернулся к тому состоянию, в котором был в момент этого коммита. А коммит 7b972f5 Git просто удалил. Это можно проверить, снова запросив лог. Он покажет следующее.

$ git log --oneline
b576d89 (HEAD -> master) feat: добавить массив Expenses и цикл для добавления трат
4b58962 refactor: разделить analyzeExpenses() на countSum() и saveExpenses()

Вот так схематично выглядит весь процесс «отката» с помощью git reset --hard <hash>.

«Откатить» изменения, которые не попали ни в staging, ни в коммит, — `git restore <file>`

Может быть так, что вы случайно изменили файл, который не планировали. Теперь он отображается в Changes not staged for commit (modified). Чтобы вернуть всё «как было», можно выполнить команду git restore <file>.

# случайно изменили файл example.txt
$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
          modified:   example.txt

$ git restore example.txt
$ git status
On branch main
nothing to commit, working tree clean

Изменения в файле «откатятся» до последней версии, которая была сохранена через git commit или git add.

Вот о чём мы рассказали:

Команда git restore --staged <file> переведёт файл из staged обратно в modified или untracked.
Команда git reset --hard <commit hash> «откатит» историю до коммита с хешем <hash>. Более поздние коммиты потеряются!
Команда git restore <file> «откатит» изменения в файле до последней сохранённой (в коммите или в staging) версии.

Навигация по коммитам. Статусы файлов

2024-02-18T23:02:43.823Z

Хеш — идентификатор коммита

В процессе работы с Git вам будет часто встречаться понятие «хеш коммита». Эти странные строчки с бессмысленным (на первый взгляд) набором букв и цифр вы могли видеть, когда вызывали команду git log и выводили историю коммитов.

Что такое хеш. Хеширование коммитов

Хеширование (от англ. hash, «рубить», «крошить», «мешанина») — это способ преобразовать набор данных и получить их «отпечаток» (англ. fingerprint).

Информация о коммите — это набор данных: когда был сделан коммит, содержимое файлов в репозитории на момент коммита и ссылка на предыдущий, или родительский (англ. parent), коммит.

Git хеширует (преобразует) информацию о коммите с помощью алгоритма SHA-1 (от англ. Secure Hash Algorithm — «безопасный алгоритм хеширования») и получает для каждого коммита свой уникальный хеш — результат хеширования.

Обычно хеш — это короткая (4040 символов в случае SHA-1) строка, которая состоит из цифр 0—90—9 и латинских букв —A—F (неважно, заглавных или строчных). Она обладает следующими важными свойствами:

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

Чтобы убедиться в этом, можно поэкспериментировать с SHA-1 на этом сайте — попробуйте ввести в поле input (англ. «ввод») разные символы, слова или предложения и понаблюдайте, как меняется хеш в поле output (англ. «вывод»).

Хеш — основной идентификатор коммита

Git хранит таблицу соответствий хеш → информация о коммите. Если вы знаете хеш, вы можете узнать всё остальное: автора и дату коммита и содержимое закоммиченных файлов. Можно сказать, что хеш — основной идентификатор коммита.

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

Все хеши и таблицу хеш → информация о коммите Git сохраняет в служебные файлы. Они находятся в скрытой папке .git в репозитории проекта.

Исследуем лог

В этом уроке рассмотрим подробнее, из каких элементов состоит описание коммита, а также как вывести сокращённый лог (от англ. log — «журнал [записей]»). Сокращённый лог полезен, если нужно быстро найти нужный коммит среди сотни других.

Элементы описания коммита

После вызова git log появляется список коммитов.

Разберём элементы, из которых состоит описание:

строка из цифр и латинских букв после слова commit — это хеш коммита;
Author — имя автора и его электронная почта;
Date — дата и время создания коммита;
в конце находится сообщение коммита.

Получить сокращённый лог — `git log --oneline`

Получить сокращённый лог можно с помощью команды git log с флагом --oneline (англ. «одной строкой»). В терминале появятся только первые несколько символов хеша каждого коммита и их комментарии.

Сокращённый лог полезен, если в репозитории уже много коммитов — например, сотни или тысячи. В этом случае можно быстро найти нужный по описанию.Сокращённый хеш (то есть первые несколько символов полного) можно использовать точно так же, как и полный. Для этого команда git log --oneline автоматически подбирает такую длину сокращённых хешей, чтобы они были уникальными в пределах репозитория и Git всегда мог понять, о каком коммите идёт речь.

HEAD — всему голова

При вызове команды git log вы также могли заметить надпись (HEAD -> master) после хеша одного из коммитов. В этом уроке расскажем, что она означает.

Файл `HEAD`

Файл HEAD (англ. «голова», «головной») — один из служебных файлов папки .git. Он указывает на коммит, который сделан последним (то есть на самый новый).

В этом можно убедиться с помощью терминала. Перейдите в папку .git командой cd. Посмотрите содержимое файла HEAD командой cat.

$ pwd 
# посмотрели, где мы /Users/user/dev/first-project 

$ cd .git/ 
$ ls 
# посмотрели, какие есть файлы 
COMMIT_EDITMSG ORIG_HEAD description index logs/ refs/ 
HEAD config hooks/ info/ objects/ 

$ cat HEAD 
# команда cat показывает содержимое файла 
ref: refs/heads/master # в файле вот такая ссылка

Внутри HEAD — ссылка на служебный файл: refs/heads/master (или refs/heads/main в зависимости от названия ветки). Если заглянуть в этот файл, можно увидеть хеш последнего коммита.

$ cat refs/heads/master # взяли ссылку из файла HEAD
# внутри хеш
e007f5035f113f9abca78fe2149c593959da5eb7

Когда вы делаете коммит, Git обновляет refs/heads/master — записывает в него хеш последнего коммита. Получается, что HEAD тоже обновляется, так как ссылается на refs/heads/master.

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

Статусы файлов в Git

До появления Git системы контроля версий выделяли только два статуса у файлов: «уже закоммичен» и «ещё не закоммичен». Например, в Subversion (самой популярной VCS до эпохи Git) не нужно было выполнять команду — аналог git add, а можно было просто сделать коммит (svn commit). Эта команда по умолчанию добавляла в коммит все новые и изменённые файлы.Такое поведение интуитивно более понятно. Зато Git даёт больше контроля за состоянием файлов. Хотя сначала это может показаться сложным, со временем вы оцените удобство более явного подхода.В этом уроке разберём подробнее, в каких состояниях (или статусах) могут находиться файлы в репозитории. А ещё проследим типичный жизненный цикл файла в Git.

Статусы `untracked`/`tracked`, `staged` и `modified`

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

untracked (англ. «неотслеживаемый»)
Мы говорили, что новые файлы в Git-репозитории помечаются как untracked, то есть неотслеживаемые. Git «видит», что такой файл существует, но не следит за изменениями в нём. У untracked-файла нет предыдущих версий, зафиксированных в коммитах или через команду git add.
staged (англ. «подготовленный»)
После выполнения команды git add файл попадает в staging area (от англ. stage — «сцена», «этап [процесса]» и area — «область»), то есть в список файлов, которые войдут в коммит. В этот момент файл находится в состоянии staged.
tracked (англ. «отслеживаемый»)
Состояние tracked — это противоположность untracked. Оно довольно широкое по смыслу: в него попадают файлы, которые уже были зафиксированы с помощью git commit, а также файлы, которые были добавлены в staging area командой git add. То есть все файлы, в которых Git так или иначе отслеживает изменения.
modified (англ. «изменённый»)
Состояние modified означает, что Git сравнил содержимое файла с последней сохранённой версией и нашёл отличия. Например, файл был закоммичен и после этого изменён.

Про `staged` и `modified`

Команда git add добавляет в staging area только текущее содержимое файла. Если вы, например, сделаете git add file.txt, а затем измените file.txt, то новое содержимое файла не будет находиться в staging.

Git сообщит об этом с помощью статуса modified: файл изменён относительно той версии, которая уже в staging. Чтобы добавить в staging последнюю версию, нужно выполнить git add file.txt ещё раз.

Типичный жизненный цикл файла в Git

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

Файл только что создали. Git ещё не отслеживает содержимое этого файла. Состояние: untracked.
Файл добавили в staging area с помощью git add. Состояние: staged (+ tracked).

Возможно, изменили файл ещё раз. Состояния: staged, modified (+ tracked). Обратите внимание: staged и modified у одного файла, но у разных его версий.
Ещё раз выполнили git add. Состояние: staged (+ tracked).

Сделали коммит с помощью git commit. Состояние: tracked.
Изменили файл. Состояние: modified (+ tracked).
Снова добавили в staging area с помощью git add. Состояния: staged (+ tracked).
Сделали коммит. Состояния: tracked.
Повторили пункты 4−74−7 много-много раз.

Важное:

Статусом untracked помечается файл, о существовании которого Git знает, но не следит за изменениями в нём. Этот статус — противоположность tracked, в который попадают все файлы, отслеживаемые Git.
Файл переходит в статус staged после выполнения git add.
Статус modified означает, что файл был изменён.
Большинство файлов в проектах «шагает» по следующему циклу: «изменён» → «добавлен в список на коммит» → «закоммичен» → «изменён» → и так далее.

Как читать git status

Частая ошибка при использовании Git — закоммитить лишнее или, наоборот, забыть добавить важный файл в коммит. Этого легко избежать, если не забывать проверять статусы файлов с помощью команды git status. Как читать её вывод, покажем в этом уроке.

Какие состояния показывает `git status`

Большинство файлов в типичном проекте будут находиться в состоянии tracked (то есть закоммичены и не изменены после коммита). Вы не увидите это состояние в выводе команды git status — иначе она бы каждый раз выводила список вообще всех файлов проекта.

В итоге git status показывает только следующие состояния файлов:

staged (Changes to be committed в выводе git status);
modified (Changes not staged for commit);
untracked (Untracked files).

Подготавливаем репозиторий

Чтобы попрактиковаться, инициализируйте новый репозиторий ~/dev/git-status-lesson. Создайте в нём файл README.md и закоммитьте его.

$ cd ~/dev 
$ mkdir git-status-lesson 
$ cd git-status-lesson 
$ git init 
# тут Git выведет что-нибудь, но мы это пропустим 
$ touch README.md 
$ git add README.md 
$ git commit -m 'Добавить README' 
~~~~# по традиции первым создадим и закоммитим файл README.md

Типичные варианты вывода `git status`

Рассмотрим четыре примера состояний, в которых может находиться ваш репозиторий.

1. Нет ни staged-, ни modified-, ни untracked-файлов.

Если ничего не менять в git-status-lesson после первого коммита, то в нём не должно быть ни изменённых файлов (modified), ни новых (untracked), ни добавленных в список на коммит (staged). Вызовите команду git status. Её вывод будет примерно таким.

$ git status
On branch master
nothing to commit, working tree clean

Это означает, что в репозитории нет новых или изменённых файлов. Последняя строка nothing to commit, working tree clean буквально переводится как «нечего коммитить, рабочая директория чиста».

Первая строка On branch master сообщает, что текущая ветка — master.

2. Найдены неотслеживаемые файлы.

Создайте в папке ~/dev/git-status-lesson файл fileA.txt. Теперь в репозитории есть новый файл в состоянии untracked. Снова вызовите команду git status. Результат будет таким.

Файл fileA.txt отображается в секции неотслеживаемых файлов — Untracked files. Это значит, что он не был добавлен в репозиторий через git add.

Добавьте fileA.txt в staging area с помощью git add и снова запросите git status.

Теперь fileA.txt находится в секции Changes to be committed (англ. «изменения, которые попадут в коммит»). Если сейчас выполнить коммит, то в репозитории будет зафиксирована текущая версия этого файла. Закоммитьте его.

Вывод команды git status такой же, какой был после первого коммита: «Директория чиста».

3. Найдены изменения, которые не войдут в коммит

Теперь откройте файл fileA.txt и добавьте в него несколько слов — например, Это файл A!. Сохраните fileA.txt и вызовите команду git status. Её результат будет такой.

Файл fileA.txt был изменён, но ещё не добавлен в staging area после этого. Так он оказался в секции Changes not staged for commit (англ. «изменения, которые не подготовлены к коммиту»). Эта секция соответствует статусу modified.Подготовьте правки к коммиту с помощью git add.

Теперь в коммит попадёт уже новая версия файла fileA.txt.

4. Файл добавлен в staging area, но после этого изменён

Вы добавили файл в staging area, но перед самым коммитом вспомнили важную мелочь. Например, вместо одного восклицательного знака в конце строки Это файл A! нужно поставить три.

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

# изменили fileA.txt 

$ git status 
On branch master Changes to be committed: 
(use "git restore --staged <file>..." to unstage) 
modified: fileA.txt 

Changes not staged for commit: 
(use "git add <file>..." to update what will be committed) 
(use "git restore <file>..." to discard changes in working directory) 
modified: fileA.txt

Файл попал и в staged (Changes to be committed), и в modified (Changes not staged for commit). В staging area находится версия файла с одним восклицательным знаком, а в Changes not staged for commit — уже изменённая версия, с тремя.

Чтобы закоммитить самую свежую версию файла, нужно снова выполнить git add перед коммитом.