QA > QA Русов > Flashcards

QA Русов Flashcards

(109 cards)

Study These Flashcards
1
Q

Самый приоритетный вид тестирования и объяснить почему так считаешь

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

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

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

В каких случаях используются чеклисты, а в каких - тест-кейсы

A
  1. Простота
  2. Длительность
  3. Стабильность требований
  4. Размер команды
  • Чек-лист
    • Для простых проектов
    • Для простой функциональности
    • Для коротких проектов
    • При нестабильных требованиях
  • Тест-кейсы
    • Сложные проекты
    • Сложная бизнес логика
    • Нужна детальная проверка функциональности
    • Для долгих проектов
    • При большом количестве тестировщиков
    • При “текучке” тестировщиков - для стабильности
    • При стабильных требованиях
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Когда следует заканчивать тестирование

A

При выполнении критериев завершения тестирования. Пример:

  1. Выполнение более 80 % запланированных на итерацию тест-кейсов
  2. Исправлено 100% критических багов
  3. Автоматизированно 80% регрессионных тест-кейсов
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Какие причины приводят к багам в ПО

A
  1. Ошибки в коде
  2. Ошибки в ТЗ
  3. Непроработанные требования
  4. Несовместимость с другим ПО или с железом
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Приведите пример end-to-end теста для интернет магазина

A
  1. Регистрация
  2. Логин
  3. Найти товар
  4. Добавить в корзину
  5. Оплатить
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

В каком случае тестирование может доказать отсутствие дефектов

A

Невозможно доказать отсутствие дефектов

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Какие тесты надо автоматизировать

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

SDLC

A

Software development life cycle:
1. Инициация (идея)
1. Сбор требований
1. Дизайн
1. Разработка
1. Тестирование
1. Ввод в эксплуатацию
1. Вывод из эксплуатации

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

QC

A

Quality Control (контроль качества)

  1. Планирование тестирования
  2. Выполнение тестирования
  3. Анализ результатов
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

QA

A

Quality Assurance (Обеспечение качества)

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

К задачам обеспечения качества относятся:

  1. проверка технических характеристик и требований к ПО;
  2. оценка рисков;
  3. планирование задач для улучшения качества продукции;
  4. подготовка документации, тестового окружения и данных;
  5. тестирование;
  6. анализ результатов тестирования, а также составление отчетов и других документов.

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Разница между тестированием, QC и QA

A
  1. Тестирование - рутинные операции составления кейсов и проверок
  2. QC - процесс планирования и анализа качества + тестирования
  3. QA - введение, поддержание и улучшение процессов для обеспечения определенного уровня качества

Тестирование и QC работают с продуктом. QA - работает с процессами
Можно различать:
- Джун это тестировщик
- Миддл это QC специалист
- Сеньер\лид - QA специалист

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Цели тестирования

A
  1. Проверка на соответствие требованиям
  2. Уверенность в качестве продукта
  3. Обнаружение и предотвращение ошибок
  4. Предоставление ответственным лицам информации о качестве для принятия решений
  5. Снижение стоимости разработки (теоретически)

___
1. Оценка рабочих продуктов (требования, пользовательские истории, проектирование и код)
2. Все ли указанные требования выполнены
3. Завершен ли объект и работает, как ожидают пользователи и заинтересованные лица
4. Создание уверенности в уровне качества объекта тестирования
5. Предотвращение и обнаружение отказов и дефектов
6. Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения
7. Снижения уровня риска ненадлежащего качества програмнного обеспечения
8. Соблюдение договорных, правовых или нормативных требований, или стандартов и/или проверка соответствия объекта тестирования им

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

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

A
  1. Тестирование показывает наличие дефектов, но не их отсутствие
  2. Полноценное тестирование невозможно
  3. Чем раньше найден баг - тем дешевле его исправить
  4. Большинство дефектов скапливается в небольшой сфере
  5. Парадокс пестицида - прогон одних и тех же тестов ведет к тому, что новые баги не находятся
  6. Тестирование зависит от контекста (веб\игры\медицина\авиа\космос и т.д.)
  7. Заблуждение об отсутствии ошибок
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Как бороться с парадоксом пестицида?

A
  1. Набор тестов, тестовых данных и подходов нужно постоянно пересматривать и улучшать
  2. Обновлять тесты и тестовые данные после исправления уже найденных дефектов
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Разница между l10n и i18n

A
  • l10n - Тестирование локализации
  • i18n - Тестировании интернационализации
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Разница между ad-hoc и exploratory testing

A

ad-hoc - свободное неструктурированное тестирование

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Примеры нефункционального тестирования

A
  1. Нагрузочное
  2. Безопасность
  3. Локализация
  4. Интернационализация
  5. UX
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Виды требований

A
  • Бизнес
  • Пользовательские
  • Функциональные
  • Нефункциональные
    ___
  • Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль).
  • Пользовательские требования (user requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя).
  • Функциональные требования (functional requirements) описывают поведение системы, т.е. ее действия (вычисления, преобразования, проверки, обработку и т.д.).
  • Нефункциональные требования (non-functional requirements) описывают свойства системы (удобство использования, безопасность, надежность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Неявные требования

A

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

  • Законы, регламенты, инструкции
  • Список задач, существующие тесты и баг-репорты
  • Руководство пользователя
  • Реклама продукта
  • Интервью с командой и заказчиками
  • Чаты и email-переписка
  • Прототип, дизайн-макет
  • Конкурентный анализ, личный опыт

Это далеко не весь перечень, подробнее https://software-testing.ru/library/around-testing/requirements/3567-requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Алгоритм работы с требованиями со стороны тестировщика

A

Идеальный процесс

  1. Требования создают бизнес-аналитики или владельцы продукта. Обычно они содержат в себе дизайнерские макеты.
  2. Требования попадают к тестировщику, которыйпроверяет их на соответствие свойствам качественных требований. Дополнительно в Scrum есть BacklogRefinement, где требования обсуждаются и уточняются командой на отдельном собрании.
  3. В случае обнаружениянеточностей, требования отправляются бизнес-аналитику на доработку, например, оставляется комментарий в системе.
  4. Пункты 2-3 повторяются до тех пор, пока не будут устранены несоответствия. Параллельно требования могут изучать другие участники команды: разработчики, дизайнеры
  5. После того как требования согласованы, они берутся в разработку, а тестировщики создают тестовую документацию для дальнейших проверок. Важно: тест-кейсы и чек-листы создаются до того, как функциональность из требования будет разработана. Вспоминаем Shift Left Testing и раннее тестирование.
  6. Вносить изменения в требования после начала спринтане рекомендуется и по-хорошему должно быть запрещено.

Неидеальный процесс

  1. Анализ требований не всегда осуществляется до этапа разработки, и уточнения могут вноситься уже во время нее
  2. Тестовая документация может создаватьсяуже после разработки функциональности
  3. Требования могут вообще не документироваться и быть на проекте в неявном виде
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Характеристики хороших требований

A
  1. Завершенность
  2. Атомарность
  3. Непротиворечивость
  4. Недвусмысленность
  5. Выполнимость
  6. Обязательность, нужность и актуальность
  7. Прослеживаемость
  8. Модифицируемость
  9. Проранжированность по важности, стабильности, срочности
  10. Корректность и Проверяемость

Завершенность (completeness)

Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно».

Примеры:

  1. Пароли должны храниться в зашифрованном виде
  2. Экспорт осуществляется в форматы PDF, PNG и т.д.
  3. Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»)

Атомарность, единичность (atomicity)

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

Примеры:

  1. Кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя
  2. Если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату
  3. Когда пользователь входит в систему, ему должно отображаться приветствие; когда пользователь вошёл в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание

Непротиворечивость, последовательность (consistency)

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

Примеры:

  1. После успешного входа в систему пользователя, не имеющего права входить в систему…
  2. “712.a Кнопка “Close” всегда должна быть красной” и “36452.x Кнопка “Close” всегда должна быть синей” - противоречия в разных требованиях
  3. “В случае, если разрешение окна составляет менее 800x600…” — разрешение есть у экрана, у окна есть размер

Недвусмысленность (unambiguousness, clearness)

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

Примеры:

  1. «Доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений» - что такое ФС?
  2. «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» - некоторые вещи опущены, так как автор считает их очевидными

Выполнимость (feasibility)

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

Примеры:

  1. Анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора - технически невыполнимо на данный момент
  2. Система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты - нельзя реализовать
  3. «озолочение» (gold plating) — требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей

Обязательность, нужность (obligatoriness) и актуальность (up-to-date).

Если требование необязательное, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть неактуальные требования

Примеры:

  1. Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет.
  2. Требованию выставлены неверные значения приоритета по критериям важности и/или срочности.
  3. Требование устарело, но не было переработано или удалено.

Прослеживаемость (traceability)

Прослеживаемость бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability). Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirements management tool) и/или матрицы прослеживаемости (traceability matrix). Типичные проблемы с прослеживаемостью:

Примеры:

  1. Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрёстных ссылок.
  2. При разработке требований не были использованы инструменты и техники управления требованиями.
  3. Набор требований неполный, носит обрывочный характер с явными «пробелами».

Модифицируемость (modifiability)

Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований.

Примеры:

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

Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority)

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

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

Корректность (correctness) и проверяемость (verifiability)

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

Источник:Святослав Куликов “Тестирование ПО. Базовый курс.”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Модели разработки. Отличия, преимущества и недостатки

Важно детально изучить, но позже

A

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

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

  1. Водопад
  2. V-образная
  3. Итерационная инкрементальная
  4. Спиральная
  5. Гибкая
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Scrum. Артефакты, события, роли

A
  • Команда
    • Product owner (Замена бизнес аналитика)
      • Управление бэклогом продукта
      • Описание бэклога
    • Development team (3-9 человек)
      • Самоорганизация
      • Кроссфункциональность (каждый может делать и dev и qa и analysis)
      • Единственная роль - разработчик
      • Коллективная ответственность (?)
    • Scrum master (servant leader (?))
      • Функционирование Scrum
      • Обучение и понимание Scrum членами команды
  • События
    • Спринт (2-4 недели) (инкремент)
      • Планирование спринта (Sprint Planning)
      • Ежедневный Scrum (Daily Scrum) (15 минут)
        • Что делал вчера
        • Что будешь делать сегодня
        • Какие есть препятствия для выполнения цели
      • Обзор спринта (Sprint Review)
      • Ретроспектива (Sprint Retrospective)
  • Артефакты
    • Бэклог продукта
    • Уточнение бэклога продукта (могут оцениваться сторипоинтами)
    • Критерии подготовленности (definition of ready)
      • Фокус на уровне бэклога
      • Помогает заказчику создавать хорошо написанные пользовательские истории, которые готовы для разработки
    • Критерии готовности (definition of done)
      • Фокус на уровне спринта или релиза
      • Помогает проверить работу в соответствии со всеми требованиями проекта, а не только продемонстрировать, что функциональности работают
      • Примеры:
        • Написаны unit\integration тесты и они все прошли
        • У нас % критичных багов меньше тутутут
    • Пользовательские истории
      • As a [Role]
      • I can [Functionality]
      • So that [Rationale]
      • Acceptance criteria
    • Покер планирования
      • Стори поинты - не привязка ко времени, а оценка сложности задачи
    • Бэклог спринта
    • Инкремент продукта
  • Метрики
    • Velocity - Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.
      • Позволяет определить максимальное количество сторипоинтов которые можно взять в спринт
    • Capacity - количество рабочих часов всех разработчиков. Учитывается при планировании и рассчете рисков (праздники, кто-то заболел и т.д.)
    • Burndown chart (диаграмма сгорания задач)
    • Cumulative flow diagram
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Пирамида тестирования и подход к выбору тестов на каждом уровне
1. Unit - 60%. dev 2. Component - 10% (microservice). dev 2. Integration - 10%. dev 3. API - 10%. qa auto (black box) 4. E2E - 5%. qa auto 5. UI - 5%. qa * Сначала функции\методы\классы * Затем интеграция модулей между собой * Затем тестирование API чёрным ящиком * Затем сквозные тесты - минимум и не должны всё покрывать * Затем ручные UI тесты
26
Что такое test harness?
Test Harness in Software Testing is a collection of stubs, drivers and other supporting tools required to automate test execution. Test harness executes tests by using a test library and generates test reports. Test harness contains all the information needed to compile and run a test like test cases, target deployment port(TDP), source file under test, stubs, etc.
27
В чем разница между bug leakage и bug release?
*Bug leakage:* когда протестированный продукт выпущен на рынок, и пользователь нашёл баг. Подразумевается, что этот баг прошел мимо внимания QA-команды в процессе тестирования. *Bug release:* новая версия продукта выпущена на рынок, и в ней есть баг, известный команде, и его предполагается пофиксить в следующей версии. Обычно это баги с низким приоритетом; их принято указывать в примечаниях к релизу, то есть наличие бага не скрывается от конечных пользователей.
28
Что такое fuzz-тестирование?
В приложение подается большой объем рандомных данных. Таким способом иногда удается найти дыры в безопасности и другие проблемы.
29
Что такое пилотное тестирование?
(Pilot testing) — своего рода «репетиция» или «прогон» тестов, выполняемый небольшим количеством конечных пользователей, которые оценивают систему и дают фидбек перед этапом финального деплоя.
30
Что такое dev-box тестирование?
Выполняется разработчиком или, реже, тестировщиком на девелоперской системе до передачи в репозиторий. Цель: проверить основные функции приложения на стабильность и готовность к обычному тестированию.
31
Отличия тест-плана и тестовой стратегии
* Стратегия тестирования повествует об общих подходах * План тестирования рассказывает о спецификации ___ * Стратегию тестирования проводит руководитель проекта * План тестирования составляется менеджером или руководителем тестирования и описывает, как тестировать, когда тестировать, кто будет тестировать и что тестировать. ___ * Стратегия тестирования — это набор рекомендаций, которые объясняют дизайн тестирования и определяют, как необходимо проводить тестирование. * План тестирования проекта программного обеспечения можно определить как документ, который определяет объем, цель, подход и акцент на усилиях по тестированию программного обеспечения.
32
Критерии начала и завершения тестирования. Примеры
*Entry criteria:* 1. Выход билда для тестирования 2. 100% требований и мокапов утверждены и проверены *Exit criteria:* 1. Выполнение более 80 % запланированных на итерацию тест-кейсов 2. Исправлено 100% критических багов 3. Автоматизированно 80% регрессионных тест-кейсов
33
Понятия чек-лист и тест-кейс
- Чек-лист - список проверок с результатами - Тест-кейс - пошаговый сценарий с детальным описанием ожидаемого результата для каждого шага и приоритетом
34
Какие методы эстимации вы знаете? Эстимация по трем точкам
1. Декомпозиция + по тест кейсам 2. По трём точкам 2. На основе опыта 2. Пальцем в небо 3. Метод процентного распределения ___ - Декомпозиция + By Test Cases - Декомпозиция - Модули → Фичи → Таски - Требование → Проверка → Количество - 30 кейсов - Рассчитываются средние затраты на один тест-кейс - Написание одного кейса - 10 минут - Время на выполнение кейса - 10 минут - Умножение на общее количество тестов - 30*10*10=300мин - Определение количества возможных дефектов и работу над одним дефектом - Сколько дефектов мы можейм найти → предположение на основании предыдущего опыта - 30/5=6 (20% дефектов) - Время на оформление баг-репорта → аналогично одному тест-кейсу - 6*10=60 минут - Время на ретест (50% на первый ретест, 50% на второй ретест) - 6*2*10=120мин - Риски + дополнительное время - Коммуникация - Изменение тест-кейсов - Подготовка сборки\билдов - Чаще всего это 30% - Сумма - кейсы(написание+выполнение) + дефекты(оформление+ретест) + риски(30%) - 600 + 180 + 234 = 1014 минут = 16.9 часов - Three Point Estimation - 3 временные точки - Оптимистичный: Ничего не помешает работе тестера и он все сделает в срок - Реалистичный: Закладываются риски - Пессимистичный: 1 из тестировщиков заболел - Рассчет (на основе By Test Cases данных) - (Оптимистичный + 4 * Реалистичный + Пессимистичный) / 6 - (13 + 4*17 + 20)/6 = 16.8 часа - Стандартное отклонение: (Пессимистичный - Оптимистичный) / 6 - (20 - 13) / 6 = 1.2 часа - Итого: 16,8 ± 1,2 часов - Based on Development - Testing Working Days - Количество времени на тестирование умножается уменьшающий процент относительно количества тестировщиков на 1-го разработчика - Dev Working Days * 30% - 3 тестера - Dev Working Days * 50% - 2 тестера - Грубая оценка, рекдо используется - На основе опыта - Прошлая итерация дает представление о трудозатратах в будущем - Пальцем в небо - Метод процентного распределения - 20% времени разработки выделяется на тестирование - В это время вписываются по % части STLC: - Анализ требований - Написание тестовой документации - Тестирование
35
Что такое матрица трассировки?
Матрица покрытия требований кейсами
36
Метрики
- Дефекты Общее количество найденных багов Общее количество неисправленных багов на проде Баги в разрезе приоритета/серьезности Баги в разрезе модуля. На основании этого можно посчитать плотность дефектов в отдельном модуле: баги в модуле/общее количество дефектов Непотвержденные дефекты: число дефектов в статусе FAD/общее количество дефектов Повторно открытые дефекты: повторно открытые баги/общее число дефектов - Кейсы Общее количество написанных кейсов Общее количество автотестов Процент автоматизированных смоук-кейсов от общего числа Процент автоматизированных регрессионных кейсов от общего числа Процент автоматизированных кейсов с высоким приоритетом от общего числа Процент покрытия требований манульными тестами: общее число кейсов/общее число требований - Оценка трудозатрат Общее количество времени на регрессионное тестирование Количество времени, затраченное на регрессионное тестирование с учетом автоматизации Количество времени затраченного на смоук Количество времени, затраченное на смоук тестирование с учетом автоматизации Точность эстимации = оценочное время/фактическое время. Полученный коээфициент можно учитывать для будущих эстимаций - Дополнительные метрики Оценка качества кода разработчика = дефекты в коде разработчика/общее количество дефектов Удовлетворенность пользователей: опросы, оценки в маркетах - ВАЖНО 1. ВСЕ МЕТРИКИ ДОЛЖНЫ БЫТЬ СОГЛАСОВАНЫ ДО ИХ ПРИМЕНЕНИЯ 2. ОСНОВНЫЕ ИЗ НИХ ДОЛЖНЫ ПОПАДАТЬ В ОТЧЕТ ПО РЕЗУЛЬТАТАМ ТЕСТИРОВАНИЯ И ПРЕЗЕНТОВАТЬСЯ КОМАНДЕ 3. ОБЯЗАТЕЛЬНОЕ ОТСЛЕЖИВАНИЕ В ДИНАМИКЕ, ВСЕ МЕТРИКИ ПРОСЧИТЫВАЮТСЯ КАЖДУЮ ИТЕРАЦИЮ И АНАЛИЗИРУЮТСЯ
37
Что такое отчет о результатах тестирования? Для чего он нужен?
вид отчета о тестировании, составляемый через регулярные промежутки времени, содержащий данные о ходе тестирования в сравнении с исходным планом, о рисках и альтернативах, требующих принятия решения. [ISTQB Glossary] - Типы - Промежуточный - Недельный - Дневной - Месячный - Версионный (по итерации) - Финальный - Части отчета - Состав команды - Сроки - Описание процессов тестирования - Дополнение к тестовым кейсам - Процент пройденных кейсов - Критичные баги - Результаты регресса - Планы (только для промежуточных)
38
Что такое тест-дизайн и тест-анализ?
- Тест-дизайн - Тест-анализ - анализ того, какие проверки объединяем, каке удаляем
39
Что такое эквивалентное разбиение? Описать процесс и правила
- Все входные значения разбиваются на группы, которые дают один и тот же результат - Значение не нужно проверять в центре, достаточно граничных значений - Есть позитивные и негативные группы - Позитивные - входные данные которые можем использовать - Негативные - входные данные которые нельзя использовать (например значения меньше 0) - Можно мобильные девайсы разбить на эквивалентые категории по характеристикам
40
Что такое граничные значения? Описать подходы определения
- Значения на границе класса эквивалентности - Проверяется само значение и выход за границу, либо само значение и +1 и -1 от значения (CTFL Syllabus 2018 p.58)
41
Что такое попарное тестирование? Алгоритмы и инструменты
- Алгоритмы - allpairs (стандартный алгоритм - Ортогональные массивы (редко используется) - Инструменты - https://www.pairwise.org/tools.html - Самый популярный - PICT от microsoft - Простой онлайн вариант - https://pairwise.teremokgames.com/ - Генератор файлов определенных размеров: https://file.generator.teremokgames.com/
42
Что такое таблица принятия решений?
Таблицы альтернатив (прим. синоним) – хороший способ записи сложных бизнес-правил, которые должны быть реализованы в системе. В процессе создания таблицы, тестировщик определяет условия (входы) и результирующие действия системы (выходы). Пары условий и действий образуют строки таблицы, при этом условия указываются сверху, а действия – снизу. [ISTQB CTFL Syllabus 2018]
43
Другие техники тест-дизайна и их суть
- Тестирование состояний и переходов - Используется очень редко 1. Переход может осуществлять как пользователь, так и система 2. Объект может находиться только в одном состоянии одновременно 3. Объект должен быть один 4. Данный вид тест дизайна не про GUI, а объекты в БД - Причина и следствие - Предугадывание ошибок
44
В каких случаях какой тест-дизайн применяется
- Поля ввода - классы эквивалентности и граничные значения - Фильтры, сортировка, надстройки - попарное тестирование - Сложные бизнес-логики - таблица принятия решений - Несколько состояний - диаграмма состояний переходов
45
Что такое клиент-серверная архитектура? Что является клиентом, что сервером? Трехуровневая архитектура
Построена на протоколе http. Устроена через взаимодействие поставщиков (сервера) и заказчиков (клиентов). Клиенты отправляют запросы на сервер, сервер обрабатывает запрос, получает данные из базы данных, выполняет нужные рассчеты\операции и отправляет клиенту Трехуровневая\трехзвенная архитектура: клиент-сервер-база данных
46
Толстый и тонкий клиент
- Тонкий - почти не выполняет вычислений и бизнес-логики - браузер, веб мобильное приложение, тонкий клиент 1С - Толстый - обеспечивает расширенную функциональность независимо от сервера - толстый клиент 1С, нативное мобильное приложение
47
Монолиты - плюсы
**Плюсы монолитов:** * Простота * Лёгкость разработки (единая база кода) * Производительность * Эффективность * Доступ к одной БД у всех компонентов
48
Монолиты - минусы
**Минусы монолитов:** * Масштабирование * Сложность внедрения новых технологий (нужно переписывать все) * Громоздкость (развертывание и обслуживание)
49
Микросервисы - плюсы
**Плюсы микросервисов** * Масштабируемость * Гибкость * Технологическое разнообразие и автономия * Обособленное тестирование и развертывание
50
Микросервисы - минусы
**Минусы микросервисов** * Сложность управления распределенной системой * Издержки на координацию процессов (чем больше - тем сложнее поддерживать взаимодействие и согласованность данных)
51
Что происходит после отправки запроса через адресную строку?
1. Браузер начинает искать сервер 2. Обращается к серверу DNS для преобразования доменного имени в IP сервера * Сначала ищет в истории подключений * В операционной системе * В кеше роутера 3. Отправляется запрос DNS серверу, который перенаправляет к другим dns серверам для полного доменного имени: `. -> .ru -> vc.ru -> mail.vc.ru` 4. Браузер устанавливает соединение с сервером через протокол TCP (зачастую) через три рукопожатия: * Клиент отправляет запрос на установку соединения - SYN-пакет * Сервер отвечает подтверждением - SYN/ACK-пакет * Клиент отправляет подтверждение - ACK-пакет 5. Браузер отправляет HTTP-запрос, чтобы получить контент сайта 6. Сервер обрабатывает запрос (nginx, apache -> библиотека языка программирования) 7. Сервер отправляет ответ браузеру 8. Браузер обрабатывает полученный ответ и рендерит веб-страницу ## Footnote https://sonulen.github.io/my_grimoire/2019/url-to-page/
52
В чем отличие IP и MAC адреса?
- IP адрес - уникальный сетевой адрес в компьютерной сети построенный по протоколу IP - IPv4 - 32 бит - IPv6 - 128 бит - Маска подсети - количество единиц в адресе сети - 255.255.255.128/25 - subnet mask /25 - MAC-адрес - адрес физического устройства, т.е. сетевой карты - DNS - Domain Name System. Сервер DNS преобразует доменное имя в IP адрес
53
Модель OSI. Уровни. Примеры протоколов
Это эталонная модель, разработанная для описания функций телекоммуникационных или вычислительных систем, необходимых для сетевого взаимодействия. Она разделяет процесс сетевого взаимодействия на семь взаимосвязанных уровней. Каждый уровень выполняет специфические функции и взаимодействует с уровнями непосредственно выше и ниже. **Модель OSI — это эталонная модель, которая, к сожалению, не нашла широкого применения в реальном мире. Поэтому появилась модель TCP/IP, по которой работает вся наша текущая сеть. Однако, когда два сетевика общаются между собой, они используют более распространенную модель OSI для лучшего понимания.** 1. Физический уровень (кабеля - нули и единицы) 1. Канальный уровень\ Data link layer (Протокол Ethernet\MAC-адрес\коммутаторы) 1. Сетевой уровень\Network Layer (IP- протокол, маршрутизаторы) 1. Транспортный уровень\Transport Layer (TCP, UDP, ICMP) 1. Сеансовый уровень\Session Layer (управление сеансами) 1. Уровень представления\Presentation Layer (сжатие, шифрование, HTML, сокеты) 1. Прикладной уровень\Application Layer (HTTP, SMTP, FTP) **Физический уровень L1 (Physical Layer):** это представление информации в виде сигналов, прямо скажем, битов. Задача этого уровня сгенерировать электрический, оптический или радиосигнал, передать его в среду и принять его. К нему относится вся физика: интерфейсы, кабели, антенны, медиаконвертеры (конвертеры среды), репитеры, старые хабы. В общем низкоуровневая это работа. Это первый уровень модели OSI и стека TCP/IP. *Если совсем просто, это нули и единицы, передающиеся в кабелях с помощью электрических сигналов (витая пара) или света (оптоволоконные кабели).* **Канальный уровень L2 (Data Link Layer):** На этом уровне работают коммутаторы. Идентификатор устройства здесь, это MAC-адрес. У каждого узла (компьютер, маршрутизатор, ноутбук, IP-телефон, любой Wi-Fi-клиент) есть этот уникальный адрес, который однозначно определяет устройство в локальной сети. В теории MAC-адреса не должны повторяться вообще, но на практике такое однако случается и в рамках одного широковещательного домена может приводить к сложноотлавливаемым проблемам. Наиболее известным протоколом этого уровня является Ethernet. Данные на этом уровне передаются кусками, каждый из которых называется Ethernet-фрейм (он же Ethernet-кадр, он же PDU канального уровня). Примеры: Ethernet, MAC-адреса, фреймы, коммутаторы. Необходимые для этого уровня понятия: Ethernet, 802.11, MAC/LLC, VLAN, ATN, HDP, Fibre Channel, FrameReplay, HDLC, PPP, Q.921, Token Ring. *Если совсем просто, на этом уровне происходит передача информации в рамках одной локальной подсети с помощью таких устройств, как коммутатор. Эти устройства не обрабатывают данные выше L2 уровня и передают их с помощью определенных алгоритмов.* **Сетевой уровень L3 (Network Layer):** Функции: отвечает за маршрутизацию пакетов данных между узлами сети. Обеспечивает логическую адресацию и определяет пути передачи данных через различные сети. Примеры: IP-адресация, маршрутизаторы, IP-протокол. Необходимые для этого уровня понятия: IP, ARP, IPsec, ICMP, IGMP, OSPF. *Если совсем просто, на этом уровне происходит передача информации между различными локальными сетями с помощью таких устройств, как маршрутизатор. Эти устройства не обрабатывают данные выше L3 уровня и передают их с помощью определенных алгоритмов между разными подсетями.* **Транспортный уровень L4 (Transport Layer):** Функции: обеспечивает надежную передачу данных, контроль ошибок, сегментацию и повторную сборку данных. Гарантирует, что данные передаются без потерь и дубликатов. Примеры: TCP (Transmission Control Protocol), UDP (User Datagram Protocol). Необходимые для этого уровня понятия: TCP, UDP, SCTP, SSL, TLS *Если совсем просто, на этом уровне информация передается по сети с помощью протоколов уровня L4. Например, это могут быть файлы с вашего компьютера или потоковое видео, которое вы смотрите на видео хостинге.* **Сеансовый уровень L5 (Session Layer):** Функции: управляет сеансами связи между приложениями. Обеспечивает установку, поддержание и завершение сеансов, а также синхронизацию и управление обменом данными. Примеры: управление сеансами, контроль диалога. Необходимые для этого уровня понятия: Session establishment in TCP, SIP, RTP, RPC-Named pipes. *Если совсем просто, то осуществляется установление, управление и завершение сеансов связи между приложениями с помощью протоколов.* **Представительный уровень L6 (Presentation Layer):** Функции: отвечает за преобразование данных в формат, подходящий для приложения или сети. Включает задачи по шифрованию, дешифрованию, сжатию и преобразованию данных. Примеры: шифрование, кодирование данных, преобразование форматов. Необходимые для этого уровня понятия: HTML, DOC, JPEG, MP3, AVI, Sockets. *Если совсем просто, происходит шифрование, сжатие и кодирование информации для обеспечения совместимости и безопасности передачи данных между различными системами.* **Прикладной уровень L7 (Application Layer):** Функции: обеспечивает доступ приложений к сетевым услугам. Реализует протоколы, которые поддерживают конечные пользовательские процессы и сетевые приложения. Примеры: HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol). Необходимые для этого уровня понятия: DNS, WWW, HTTP, P2P, EMAIL, POP, SMTP, TELNET, SSH, FTP, TFTP. *Если совсем просто, осуществляется взаимодействие пользователя с приложениями, обеспечивая веб-серфинг, электронную почту и передачу файлов.*
54
Модель TCP/IP
4. Канальный\Network access layer 3. Межсетевой\Internet layer 2. Транспортный\Transport layer 1. Прикладной уровень\Application layer Модель почти полностью повторяет эталонную OSI со своими особенностями: * Первый уровень – канальный. В данной модели он объединяет L1 и L2 уровни модели OSI. * Второй уровень – межсетевой. Он идентичен сетевому уровню L3 модели OSI. * Третий уровень – транспортный. Он идентичен транспортному уровню L4 модели OSI. * Четвертый уровень – прикладной. Он объединяет L5 – L7 уровни модели OSI.
55
Разница UDP и TCP. Если расскажите про QUIC, то будет прекрасно
TCP (Transmission Control Protocol - протокол управления передачей), является надежным протоколом с установлением соединений, позволяющим без ошибок доставлять байтовый поток с одной машины на любую другую машину объединенной сети. Используется для передачи электронных сообщений, отправка файлов. UDP (User Datagram Protocol - протокол пользовательских дейтаграмм), является ненадежным протоколом без установления соединения, не использующим последовательное управление потоком протокола TCP, а предоставляющим свое собственное. Он также широко используется в одноразовых клиент-серверных запросах и приложениях, в которых оперативность важнее гарантии отправки всех данных, например при передаче речи и видео (стриминг, онлайн-игры). TCP - протокол с гарантией доставки сообщений. При непоступлении пакета, происходит переотправка (почтовые сервисы) UDP - протокол без гарантии доставки сообщений. Информация передается потоком (онлайн игры) ## Footnote Final
56
Версии HTTP
- 0.9 - 1.0 - 1.1 - текстовый формат - 2.0 - использует бинарный формат, быстрее - 3.0
57
HTTP - суть
HTTP (HyperText Transfer Protocol) — протокол прикладного уровня передачи данных. * изначально — в виде гипертекстовых документов в формате HTML, * в настоящее время используется для передачи произвольных данных. По умолчанию использует 80-й порт
58
HTTPs - суть
HTTPs — это расширение для протокола HTTP, которое делает его безопасным. * Для этого используются **специальные криптографические протоколы (TLS)**, через которые передаются данные. * Конфиденциальность * Достоверность * Идентификация По умолчанию использует 443 порт ## Footnote https://howhttps.works/ - добавить инфу про сертификаты
59
SSL сертификат
Гарантирует подлинность сайта. Что мы зашли туда, куда собирались зайти. Выдаётся легитимным центром сертификации.
60
Центр сертификации
Сторонняя организация с задачами: 1. Выпуск сертификатов 2. Подтверждение личности обладателя сертификата 3. Предоставление доказательств действительности сертификата Symantec, Comodo, Let's Encrypt **Цепочка доверия:** 1. Загружается сертификат с сайта после подключения по HTTPs 2. Загружается сертификат которым был подписан сертификат на сайте (промежуточный сертификат) 3. Проверяется сертификат которым был подписан промежуточный сертификат (корневой сертификат)
61
Из чего состоит запрос и ответ? Примеры заголовков
**Request** 1. Стартовая строка (start line) содержит: 2. информацию о методе, которое говорит нам о совершаемом действии. Например, GET - получение информации от сервера, POST - загрузка информации на сервер. 1. Цель запроса, чаще всего это URL. 2. query параметры - Это параметры ключ=значение, которые располагаются в request line после указания глагола POST или GET. Начинаются с вопроса `/login?key=value` 3. path параметры (почти нигде не используются) 1. Версия HTTP-протокола 1. Headers (заголовки запроса), которые несут в себе служебную информацию. Например, информация о языке страницы, кодировке, браузере. 1. Пустая строка (empty line), указывающая, что вся мета информация отправлена. 1. Тело запроса (body), в которых содержится полезная нагрузка для отправки на сервер. В методе GET тело игнорируется. **Response** 1. Стартовая строка содержит: 2. версию протокола, 3. статус-код об успешности запроса, 4. пояснение для кода. 1. Headers (заголовки ответа), которые несут в себе служебную информацию. Например, дополнительную информацию о сервере и ответе. 1. Пустая строка (empty line), указывающая, что вся мета информация отправлена. 1. Тело ответа (body), в которых содержится результат отправки полезной нагрузки на сервер. ## Footnote https://developer.mozilla.org/ru/docs/Web/HTTP/Messages
62
Статус-коды. Знать все группы и несколько примеров. Отличие 401 и 403. 418 код
63
HTTP-методы. Различия GET и POST, PUT и PATCH
- GET - запрос информации - POST - отправка определенной информации на сервер (данные, изображения и т.д.) для создания или обновления ресурса. Отправка запроса с одними и теми же данными приведет к созданию одного и того же ресурса несколько раз - PUT - отправка информации на сервер для создания и обновления конкретного ресурса. Идемпотентный - т.е. вызов этого метода с неизменными данными всегда будет давать один и тот же результат - PATCH
64
URL, URI, URN
- URI - Uniform Resource Identifier - URL - Uniform Resource Locator - URN - Uniform Resource Name http://www.webdev.com/accueil/index.html URI - вся ссылка URL - http://www.webdev.com URN - /accueil/index.html
65
Кэш (серверный, клиентский) и куки. Виды. Заголовки. Для чего используются? Как удалить? Где искать?
**Кэш (cache) **— промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. [Источник] Пример: вы используете ресурс с большим количеством картинок. Чтобы каждый раз не загружать данные с сервера, картинки загружаются на ваш компьютер и каждый раз при обращении к ресурсу загружаются с него. **Cookies** - небольшой фрагмент данных, который сервер отправляет браузеру пользователя, который хранится на компьютере пользователя. [Источник] Куки часто используются для: Управления сеансом (логины, корзины для виртуальных покупок) Персонализации (пользовательские предпочтения) Трекинга (отслеживания поведения пользователей) Пример: вы добавили товар в корзину, информация об этом сохранилась в куки. Даже если вы перезагрузите страницу, то данные в корзине не изменятся и будут содержать добавленные товары. **Виды куки:** Сессионные куки (session cookie) - такие cookie удаляются при закрытии клиента, то есть существуют только на протяжении текущего сеанса. Постоянные куки (permanent cookies) удаляются не с закрытием клиента, а при наступлении определённой даты или после определённого интервала времени. - Кэш - временные файлы, которые сохраняются на жетский диск и переиспользуются при открытии страницы, что позволяет их не загружать заново с сервера - Куки - временные файлы для хранения персональных данных пользователя: логин, пароль, настройки
66
Пару слов про Local и Session Storage.
HTML5. Used for saving the website's content or documents for offline use, user preferences, and much more. data survives a page refresh (for sessionStorage) and even a full browser restart (for localStorage) Before HTML5, application data had to be stored in cookies, included in every server request. Web storage is more secure, and large amounts of data can be stored locally, without affecting website performance. Unlike cookies, the storage limit is far larger (at least 5MB) and information is never transferred to the server. Web storage is per origin (per domain and protocol). All pages, from one origin, can store and access the same data.
67
Веб-сайт, веб-приложение, веб-сервис - разница
**Веб-сайт** - это коллекция веб-страниц, содержащих информацию о компании, продукте или услуге, предназначенная для ознакомления пользователей. Веб-сайт статичен и не предоставляет пользовательских интерактивных возможностей. **Веб-приложение** - это интерактивное приложение, доступное через интернет и исполняющееся на стороне клиента (веб-браузере). Веб-приложения позволяют пользователям выполнять различные действия, такие как ввод информации, отправка данных, обработка запросов и просмотр результатов. **Веб-сервис** - это программное обеспечение или приложение, которое предоставляет функциональность через интернет для взаимодействия с другими приложениями или сервисами. Веб-сервисы часто используются для обмена данными между различными системами и приложениями, обеспечивая стандартизированный интерфейс для взаимодействия.
68
Chrome Devtools. Как вызвать? Для чего используется? Знать интерфейс и вкладки. На интервью можно просить шарить экран и показывать уже на открытых инструментах. Может упростить вам жизнь :)
- F12, Ctrl+Shift+I, View Page Code, Inspect - Используется для разработки, тестирования, отладки - Вкладки: - Elements -HTML - Console - информация о фронтовых ошибках и js консоль - Sources - файлы и дебаг js - Network - запросы - XHR - основные запросы - Perfomance - Security
69
Виды UI
1. CLI - Интерфейс командной строки и текстовый интерфейс (Command Line Interface или CLI) 2. GUI - Графический интерфейс 3. Жестовый, голосовой, тактильный, нейронный
70
Виды версток
1. Табличная 2. Блочная 3. Семантическая Подтипы: * Статическая * Резиновая * Гибкая (flexbox)
71
Figma, PixelPerfect - для чего используется?
1. Дизайн интерфейсов 2. Плагин для figma - проверка соответствия переноса дизайна при переносе в код
72
Названия веб-элементов и веб-форм. Особенности их тестирования
- Text Field 1. Обязательность заполнения 2. Валидация на фронте 3. Валидация на бэке 4. Скопировать\вставить работают 5. html тэги не вставляются - Text Area - Link Prefix (http://) - Оставляем пустым - Link - Checkbox - Ничего не выбираем - Обязательные - Несколько выбираем - Все выбираем - Radiobutton - Нельзя выбрать несколько элементов - Multiple selector - Upload File - Загружаем файл - Проверяем форматы файлов - Проверяем допустимый размер - Phone - email - Password - Стандартные проверки полей ввода - Валидация сложности пароля - Captcha - Dropdown - Listbox - Date/time picker
73
Что такое API, веб-сервис? Примеры
- API - application programming interface - Веб-сервис - программа, которая организовывает взаимодействие между сайтами по протоколам SOAP или REST
74
Что такое SOAP?
- SOAP - Simple Object Access Protocol - протокол обмена данными в формате XML SOAP is a protocol that defines rigid communication rules. It has several associated standards that control every aspect of the data exchange. For example, here are some standards SOAP uses: * Web Services Security (WS-Security) specifies security measures like using unique identifiers called tokens * Web Services Addressing (WS-Addressing) requires including routing information as metadata * WS-ReliableMessaging standardizes error handling in SOAP messaging * Web Services Description Language (WSDL) describes the scope and function of SOAP web services When you send a request to a SOAP API, you must wrap your HTTP request in a SOAP envelope. This is a data structure that modifies the underlying HTTP content with SOAP request requirements. Due to the envelope, you can also send requests to SOAP web services with other transport protocols, like TCP or Internet Control Message Protocol (ICMP). However, SOAP APIs and SOAP web services always return XML documents in their responses.
75
Что такое WSDL?
- WSDL - Web Services Description Language - Описывает сообщения, заголовки, сообщения которые свойственны этому веб-сервису (т.е. описывается структура веб-сервиса) - Обязателен для SOAP-протокола
76
Что такое XSD?
- XSD - XML Schema Definition - Структура XML документа и типы данных которые там могут храниться
77
Что такое REST, RESTful (принципы)?
Вот ключевые аспекты RESTful API: 1. Статусные коды: Используйте стандартные коды (200, 404, 500 и т. д.) для обозначения статуса ответов. 1. Методы HTTP: Используйте соответствующие методы (GET, POST, PUT, DELETE) для выполнения операций с ресурсами. 1. Идентификация ресурсов: Ресурсы должны быть доступны по уникальным URL. 1. Stateless: Каждый запрос должен содержать всю необходимую информацию для его обработки; сервер не должен сохранять состояние между запросами. 1. Форматы данных: Обычно используются JSON или XML для передачи данных. 1. Кэширование: Используйте кэширование для улучшения производительности и уменьшения нагрузки на сервер. 1. Согласованность: Обеспечьте однородность в именовании ресурсов и структуре URL. _______________________________ 1. Клиент-сервер 2. Stateless 3. Единообразие интерфейса 4. Кэширование 5. Система слоёв (прокси) 6. Код по требованию (отправка кода клиенту в теге script) 1. Client-server architecture. The sender and receiver are independent of each other regarding technology, platforming, programming language, and so on. 1. Layered. The server can have several intermediaries that work together to complete client requests, but they are invisible to the client. 1. Uniform interface. The API returns data in a standard format that is complete and fully useable. 1. Stateless. The API completes every new request independently of previous requests. 1. Cacheable. All API responses are cacheable. 1. Code on demand. The API response can include a code snippet if required. REST — это аббревиатура от Representational State Transfer («передача состояния представления»). Это согласованный набор архитектурных принципов для создания более масштабируемой и гибкой сети. Эти принципы отвечают на ряд вопросов. Какие у системы компоненты? Как они должны взаимодействовать друг с другом? Как быть уверенным, что можно заменять различные части системы в любое время? Как система может масштабироваться для обслуживания миллиардов пользователей? Рой Филдинг первым использовал термин REST в 2000 году в своей докторской диссертации «Архитектурные стили и дизайн программных сетевых архитектур». **Ограничения Филдинга** *В диссертации Филдинга есть группа архитектурных ограничений, которым должна удовлетворять система, соответствующая требованиям RESTful.* 1. **Клиент-сервер.** RESTful-система должна производить операции в клиент-серверной модели, даже если компонент периодически ведёт себя то как клиент, то как сервер. 2. **Отсутствие состояния**. Когда клиент не взаимодействует с сервером, сервер не имеет представления о его существовании. Сервер также не ведёт учет прошлых запросов. Каждый запрос рассматривается как самостоятельный. 3. **Единообразие интерфейса**. Ограничение гарантирует, что между серверами и клиентами существует общий язык, который позволяет каждой части быть заменяемой или изменяемой, без нарушения целостности системы. Это достигается через 4 субограничения: 4. идентификацию ресурсов, 5. манипуляцию ресурсами через представления, 6. «самодостаточные» сообщения и 7. гипермедиа. 4. **Кэширование** - ответы сервера должны помечаться как кэшируемые или некэшируемые. 5. **Система слоёв** предполагает наличие большего количества компонентов, чем клиент и сервер. (Прокси например) 6. **Код по требованию** — единственное **опциональное** ограничение, которое предполагает отправку сервером исполняемого кода клиенту. Это то, что происходит в HTML-теге `