Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

QA > QA Русов > Flashcards

QA Русов 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
Q

Пирамида тестирования и подход к выбору тестов на каждом уровне

A
  1. Unit - 60%. dev
  2. Component - 10% (microservice). dev
  3. Integration - 10%. dev
  4. API - 10%. qa auto (black box)
  5. E2E - 5%. qa auto
  6. UI - 5%. qa
  • Сначала функции\методы\классы
  • Затем интеграция модулей между собой
  • Затем тестирование API чёрным ящиком
  • Затем сквозные тесты - минимум и не должны всё покрывать
  • Затем ручные UI тесты
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Что такое test harness?

A

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.

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

В чем разница между bug leakage и bug release?

A

Bug leakage: когда протестированный продукт выпущен на рынок, и пользователь нашёл баг. Подразумевается, что этот баг прошел мимо внимания QA-команды в процессе тестирования.

Bug release: новая версия продукта выпущена на рынок, и в ней есть баг, известный команде, и его предполагается пофиксить в следующей версии. Обычно это баги с низким приоритетом; их принято указывать в примечаниях к релизу, то есть наличие бага не скрывается от конечных пользователей.

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

Что такое fuzz-тестирование?

A

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

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

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

A

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

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

Что такое dev-box тестирование?

A

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

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

Отличия тест-плана и тестовой стратегии

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

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

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

Критерии начала и завершения тестирования. Примеры

A

Entry criteria:

  1. Выход билда для тестирования
  2. 100% требований и мокапов утверждены и проверены

Exit criteria:

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

Понятия чек-лист и тест-кейс

A
  • Чек-лист - список проверок с результатами
  • Тест-кейс - пошаговый сценарий с детальным описанием ожидаемого результата для каждого шага и приоритетом
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Какие методы эстимации вы знаете? Эстимация по трем точкам

A
  1. Декомпозиция + по тест кейсам
  2. По трём точкам
  3. На основе опыта
  4. Пальцем в небо
  5. Метод процентного распределения
    ___
    - Декомпозиция + By Test Cases
    • Декомпозиция
      • Модули → Фичи → Таски
      • Требование → Проверка → Количество
        • 30 кейсов
    • Рассчитываются средние затраты на один тест-кейс
      • Написание одного кейса
        • 10 минут
      • Время на выполнение кейса
        • 10 минут
      • Умножение на общее количество тестов
        • 301010=300мин
    • Определение количества возможных дефектов и работу над одним дефектом
      • Сколько дефектов мы можейм найти → предположение на основании предыдущего опыта
        • 30/5=6 (20% дефектов)
      • Время на оформление баг-репорта → аналогично одному тест-кейсу
        • 6*10=60 минут
      • Время на ретест (50% на первый ретест, 50% на второй ретест)
        • 6210=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:
        • Анализ требований
        • Написание тестовой документации
        • Тестирование
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Что такое матрица трассировки?

A

Матрица покрытия требований кейсами

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

Метрики

A
  • Дефекты
    Общее количество найденных багов
    Общее количество неисправленных багов на проде
    Баги в разрезе приоритета/серьезности
    Баги в разрезе модуля. На основании этого можно посчитать плотность дефектов в отдельном модуле: баги в модуле/общее количество дефектов
    Непотвержденные дефекты: число дефектов в статусе FAD/общее количество дефектов
    Повторно открытые дефекты: повторно открытые баги/общее число дефектов
  • Кейсы
    Общее количество написанных кейсов
    Общее количество автотестов
    Процент автоматизированных смоук-кейсов от общего числа
    Процент автоматизированных регрессионных кейсов от общего числа
    Процент автоматизированных кейсов с высоким приоритетом от общего числа
    Процент покрытия требований манульными тестами: общее число кейсов/общее число требований
  • Оценка трудозатрат
    Общее количество времени на регрессионное тестирование
    Количество времени, затраченное на регрессионное тестирование с учетом автоматизации
    Количество времени затраченного на смоук
    Количество времени, затраченное на смоук тестирование с учетом автоматизации
    Точность эстимации = оценочное время/фактическое время. Полученный коээфициент можно учитывать для будущих эстимаций
  • Дополнительные метрики
    Оценка качества кода разработчика = дефекты в коде разработчика/общее количество дефектов
    Удовлетворенность пользователей: опросы, оценки в маркетах
  • ВАЖНО
    1. ВСЕ МЕТРИКИ ДОЛЖНЫ БЫТЬ СОГЛАСОВАНЫ ДО ИХ ПРИМЕНЕНИЯ
    2. ОСНОВНЫЕ ИЗ НИХ ДОЛЖНЫ ПОПАДАТЬ В ОТЧЕТ ПО РЕЗУЛЬТАТАМ ТЕСТИРОВАНИЯ И ПРЕЗЕНТОВАТЬСЯ КОМАНДЕ
    3. ОБЯЗАТЕЛЬНОЕ ОТСЛЕЖИВАНИЕ В ДИНАМИКЕ, ВСЕ МЕТРИКИ ПРОСЧИТЫВАЮТСЯ КАЖДУЮ ИТЕРАЦИЮ И АНАЛИЗИРУЮТСЯ
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

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

A

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

  • Типы
    • Промежуточный
      • Недельный
      • Дневной
      • Месячный
      • Версионный (по итерации)
    • Финальный
  • Части отчета
    • Состав команды
    • Сроки
    • Описание процессов тестирования
    • Дополнение к тестовым кейсам
    • Процент пройденных кейсов
    • Критичные баги
    • Результаты регресса
    • Планы (только для промежуточных)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

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

A
  • Тест-дизайн
  • Тест-анализ - анализ того, какие проверки объединяем, каке удаляем
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Что такое эквивалентное разбиение? Описать процесс и правила

A
  • Все входные значения разбиваются на группы, которые дают один и тот же результат
  • Значение не нужно проверять в центре, достаточно граничных значений
  • Есть позитивные и негативные группы
    • Позитивные - входные данные которые можем использовать
    • Негативные - входные данные которые нельзя использовать (например значения меньше 0)
  • Можно мобильные девайсы разбить на эквивалентые категории по характеристикам
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Что такое граничные значения? Описать подходы определения

A
  • Значения на границе класса эквивалентности
  • Проверяется само значение и выход за границу, либо само значение и +1 и -1 от значения (CTFL Syllabus 2018 p.58)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Что такое попарное тестирование? Алгоритмы и инструменты

A
  • Алгоритмы
    • allpairs (стандартный алгоритм
    • Ортогональные массивы (редко используется)
  • Инструменты
    • https://www.pairwise.org/tools.html
    • Самый популярный - PICT от microsoft
    • Простой онлайн вариант - https://pairwise.teremokgames.com/
    • Генератор файлов определенных размеров: https://file.generator.teremokgames.com/
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Что такое таблица принятия решений?

A

Таблицы альтернатив (прим. синоним) – хороший способ записи сложных бизнес-правил, которые должны быть реализованы в системе. В процессе создания таблицы, тестировщик определяет условия (входы) и результирующие действия системы (выходы). Пары условий и действий образуют строки таблицы, при этом условия указываются сверху, а действия – снизу. [ISTQB CTFL Syllabus 2018]

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

Другие техники тест-дизайна и их суть

A
  • Тестирование состояний и переходов
    • Используется очень редко
      1. Переход может осуществлять как пользователь, так и система
      2. Объект может находиться только в одном состоянии одновременно
      3. Объект должен быть один
      4. Данный вид тест дизайна не про GUI, а объекты в БД
  • Причина и следствие
  • Предугадывание ошибок
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

В каких случаях какой тест-дизайн применяется

A
  • Поля ввода - классы эквивалентности и граничные значения
  • Фильтры, сортировка, надстройки - попарное тестирование
  • Сложные бизнес-логики - таблица принятия решений
  • Несколько состояний - диаграмма состояний переходов
45
Q

Что такое клиент-серверная архитектура? Что является клиентом, что сервером? Трехуровневая архитектура

A

Построена на протоколе http. Устроена через взаимодействие поставщиков (сервера) и заказчиков (клиентов).

Клиенты отправляют запросы на сервер, сервер обрабатывает запрос, получает данные из базы данных, выполняет нужные рассчеты\операции и отправляет клиенту

Трехуровневая\трехзвенная архитектура: клиент-сервер-база данных

46
Q

Толстый и тонкий клиент

A
  • Тонкий - почти не выполняет вычислений и бизнес-логики
    • браузер, веб мобильное приложение, тонкий клиент 1С
  • Толстый - обеспечивает расширенную функциональность независимо от сервера
    • толстый клиент 1С, нативное мобильное приложение
47
Q

Монолиты - плюсы

A

Плюсы монолитов:

  • Простота
  • Лёгкость разработки (единая база кода)
  • Производительность
  • Эффективность
  • Доступ к одной БД у всех компонентов
48
Q

Монолиты - минусы

A

Минусы монолитов:

  • Масштабирование
  • Сложность внедрения новых технологий (нужно переписывать все)
  • Громоздкость (развертывание и обслуживание)
49
Q

Микросервисы - плюсы

A

Плюсы микросервисов

  • Масштабируемость
  • Гибкость
  • Технологическое разнообразие и автономия
  • Обособленное тестирование и развертывание
50
Q

Микросервисы - минусы

A

Минусы микросервисов

  • Сложность управления распределенной системой
  • Издержки на координацию процессов (чем больше - тем сложнее поддерживать взаимодействие и согласованность данных)
51
Q

Что происходит после отправки запроса через адресную строку?

A
  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. Браузер обрабатывает полученный ответ и рендерит веб-страницу

https://sonulen.github.io/my_grimoire/2019/url-to-page/

52
Q

В чем отличие IP и MAC адреса?

A
  • IP адрес - уникальный сетевой адрес в компьютерной сети построенный по протоколу IP
    • IPv4 - 32 бит
    • IPv6 - 128 бит
  • Маска подсети - количество единиц в адресе сети
    • 255.255.255.128/25 - subnet mask /25
  • MAC-адрес - адрес физического устройства, т.е. сетевой карты
  • DNS - Domain Name System. Сервер DNS преобразует доменное имя в IP адрес
53
Q

Модель OSI. Уровни. Примеры протоколов

A

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

Модель OSI — это эталонная модель, которая, к сожалению, не нашла широкого применения в реальном мире. Поэтому появилась модель TCP/IP, по которой работает вся наша текущая сеть. Однако, когда два сетевика общаются между собой, они используют более распространенную модель OSI для лучшего понимания.

  1. Физический уровень (кабеля - нули и единицы)
  2. Канальный уровень\ Data link layer (Протокол Ethernet\MAC-адрес\коммутаторы)
  3. Сетевой уровень\Network Layer (IP- протокол, маршрутизаторы)
  4. Транспортный уровень\Transport Layer (TCP, UDP, ICMP)
  5. Сеансовый уровень\Session Layer (управление сеансами)
  6. Уровень представления\Presentation Layer (сжатие, шифрование, HTML, сокеты)
  7. Прикладной уровень\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
Q

Модель TCP/IP

A
  1. Канальный\Network access layer
  2. Межсетевой\Internet layer
  3. Транспортный\Transport layer
  4. Прикладной уровень\Application layer

Модель почти полностью повторяет эталонную OSI со своими особенностями:

  • Первый уровень – канальный. В данной модели он объединяет L1 и L2 уровни модели OSI.
  • Второй уровень – межсетевой. Он идентичен сетевому уровню L3 модели OSI.
  • Третий уровень – транспортный. Он идентичен транспортному уровню L4 модели OSI.
  • Четвертый уровень – прикладной. Он объединяет L5 – L7 уровни модели OSI.
55
Q

Разница UDP и TCP. Если расскажите про QUIC, то будет прекрасно

A

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

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

TCP - протокол с гарантией доставки сообщений. При непоступлении пакета, происходит переотправка (почтовые сервисы)

UDP - протокол без гарантии доставки сообщений. Информация передается потоком (онлайн игры)

Final

56
Q

Версии HTTP

A
  • 0.9
  • 1.0
  • 1.1 - текстовый формат
  • 2.0 - использует бинарный формат, быстрее
  • 3.0
57
Q

HTTP - суть

A

HTTP (HyperText Transfer Protocol) — протокол прикладного уровня передачи данных.

  • изначально — в виде гипертекстовых документов в формате HTML,
  • в настоящее время используется для передачи произвольных данных.

По умолчанию использует 80-й порт

58
Q

HTTPs - суть

A

HTTPs — это расширение для протокола HTTP, которое делает его безопасным.
* Для этого используются специальные криптографические протоколы (TLS), через которые передаются данные.

  • Конфиденциальность
  • Достоверность
  • Идентификация

По умолчанию использует 443 порт

https://howhttps.works/ - добавить инфу про сертификаты

59
Q

SSL сертификат

A

Гарантирует подлинность сайта. Что мы зашли туда, куда собирались зайти.

Выдаётся легитимным центром сертификации.

60
Q

Центр сертификации

A

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

Symantec, Comodo, Let’s Encrypt

Цепочка доверия:
1. Загружается сертификат с сайта после подключения по HTTPs
2. Загружается сертификат которым был подписан сертификат на сайте (промежуточный сертификат)
3. Проверяется сертификат которым был подписан промежуточный сертификат (корневой сертификат)

61
Q

Из чего состоит запрос и ответ? Примеры заголовков

A

Request

  1. Стартовая строка (start line) содержит:
    1. информацию о методе, которое говорит нам о совершаемом действии. Например, GET - получение информации от сервера, POST - загрузка информации на сервер.
    2. Цель запроса, чаще всего это URL.
      1. query параметры - Это параметры ключ=значение, которые располагаются в request line после указания глагола POST или GET. Начинаются с вопроса /login?key=value
      2. path параметры (почти нигде не используются)
    3. Версия HTTP-протокола
    4. Headers (заголовки запроса), которые несут в себе служебную информацию. Например, информация о языке страницы, кодировке, браузере.
  2. Пустая строка (empty line), указывающая, что вся мета информация отправлена.
  3. Тело запроса (body), в которых содержится полезная нагрузка для отправки на сервер. В методе GET тело игнорируется.

Response

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

https://developer.mozilla.org/ru/docs/Web/HTTP/Messages

62
Q

Статус-коды. Знать все группы и несколько примеров. Отличие 401 и 403. 418 код

A
63
Q

HTTP-методы. Различия GET и POST, PUT и PATCH

A
  • GET - запрос информации
  • POST - отправка определенной информации на сервер (данные, изображения и т.д.) для создания или обновления ресурса. Отправка запроса с одними и теми же данными приведет к созданию одного и того же ресурса несколько раз
  • PUT - отправка информации на сервер для создания и обновления конкретного ресурса. Идемпотентный - т.е. вызов этого метода с неизменными данными всегда будет давать один и тот же результат
  • PATCH
64
Q

URL, URI, URN

A
  • 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
Q

Кэш (серверный, клиентский) и куки. Виды. Заголовки. Для чего используются? Как удалить? Где искать?

A

**Кэш (cache) **— промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. [Источник]

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

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

Куки часто используются для:

Управления сеансом (логины, корзины для виртуальных покупок)

Персонализации (пользовательские предпочтения)

Трекинга (отслеживания поведения пользователей)

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

Виды куки:

Сессионные куки (session cookie) - такие cookie удаляются при закрытии клиента, то есть существуют только на протяжении текущего сеанса.
Постоянные куки (permanent cookies) удаляются не с закрытием клиента, а при наступлении определённой даты или после определённого интервала времени.

  • Кэш - временные файлы, которые сохраняются на жетский диск и переиспользуются при открытии страницы, что позволяет их не загружать заново с сервера
  • Куки - временные файлы для хранения персональных данных пользователя: логин, пароль, настройки
66
Q

Пару слов про Local и Session Storage.

A

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
Q

Веб-сайт, веб-приложение, веб-сервис - разница

A

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

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

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

68
Q

Chrome Devtools. Как вызвать? Для чего используется? Знать интерфейс и вкладки. На интервью можно просить шарить экран и показывать уже на открытых инструментах. Может упростить вам жизнь :)

A
  • F12, Ctrl+Shift+I, View Page Code, Inspect
  • Используется для разработки, тестирования, отладки
  • Вкладки:
    • Elements -HTML
    • Console - информация о фронтовых ошибках и js консоль
    • Sources - файлы и дебаг js
    • Network - запросы
      • XHR - основные запросы
    • Perfomance
    • Security
69
Q

Виды UI

A
  1. CLI - Интерфейс командной строки и текстовый интерфейс (Command Line Interface или CLI)
  2. GUI - Графический интерфейс
  3. Жестовый, голосовой, тактильный, нейронный
70
Q

Виды версток

A
  1. Табличная
  2. Блочная
  3. Семантическая

Подтипы:
* Статическая
* Резиновая
* Гибкая (flexbox)

71
Q

Figma, PixelPerfect - для чего используется?

A
  1. Дизайн интерфейсов
  2. Плагин для figma - проверка соответствия переноса дизайна при переносе в код
72
Q

Названия веб-элементов и веб-форм. Особенности их тестирования

A
  • 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
Q

Что такое API, веб-сервис? Примеры

A
  • API - application programming interface
  • Веб-сервис - программа, которая организовывает взаимодействие между сайтами по протоколам SOAP или REST
74
Q

Что такое SOAP?

A
  • 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
Q

Что такое WSDL?

A
  • WSDL - Web Services Description Language
    • Описывает сообщения, заголовки, сообщения которые свойственны этому веб-сервису (т.е. описывается структура веб-сервиса)
    • Обязателен для SOAP-протокола
76
Q

Что такое XSD?

A
  • XSD - XML Schema Definition
    • Структура XML документа и типы данных которые там могут храниться
77
Q

Что такое REST, RESTful (принципы)?

A

Вот ключевые аспекты RESTful API:

  1. Статусные коды: Используйте стандартные коды (200, 404, 500 и т. д.) для обозначения статуса ответов.
  2. Методы HTTP: Используйте соответствующие методы (GET, POST, PUT, DELETE) для выполнения операций с ресурсами.
  3. Идентификация ресурсов: Ресурсы должны быть доступны по уникальным URL.
  4. Stateless: Каждый запрос должен содержать всю необходимую информацию для его обработки; сервер не должен сохранять состояние между запросами.
  5. Форматы данных: Обычно используются JSON или XML для передачи данных.
  6. Кэширование: Используйте кэширование для улучшения производительности и уменьшения нагрузки на сервер.
  7. Согласованность: Обеспечьте однородность в именовании ресурсов и структуре URL.

_______________________________

  1. Клиент-сервер
  2. Stateless
  3. Единообразие интерфейса
  4. Кэширование
  5. Система слоёв (прокси)
  6. Код по требованию (отправка кода клиенту в теге script)
  7. Client-server architecture. The sender and receiver are independent of each other regarding technology, platforming, programming language, and so on.
  8. Layered. The server can have several intermediaries that work together to complete client requests, but they are invisible to the client.
  9. Uniform interface. The API returns data in a standard format that is complete and fully useable.
  10. Stateless. The API completes every new request independently of previous requests.
  11. Cacheable. All API responses are cacheable.
  12. 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 субограничения:
    1. идентификацию ресурсов,
    2. манипуляцию ресурсами через представления,
    3. «самодостаточные» сообщения и
    4. гипермедиа.
  4. Кэширование - ответы сервера должны помечаться как кэшируемые или некэшируемые.
  5. Система слоёв предполагает наличие большего количества компонентов, чем клиент и сервер. (Прокси например)
  6. Код по требованию — единственное опциональное ограничение, которое предполагает отправку сервером исполняемого кода клиенту. Это то, что происходит в HTML-теге
    <script>. Когда HTML-документ загружается, браузер автоматически выбирает на сервере JavaScript и исполняет его локально.

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

https://habr.com/ru/companies/hexlet/articles/274675/

78
Q

Разница SOAP и REST. Когда используется?

A
  • REST поддерживает различные форматы (JSON, XML, текст)
    • Работает только по HTTP и HTTPs
    • Может быть закэширован
    • Это архитектурный стиль без жестких правил
  • В SOAP - только XML
    • Может работать с различными протколами
    • Не может быть помещен в кэш
    • Есть WSDL (структура веб-сервиса), а в REST отсутствует
    • Это протокол ограниченный определенными правилами
  • REST или SOAP:
    • Простота против стандартов
    • REST - скорость, расширяемость и поддержка многих форматов. Отсутствие жестких правил
      • Требуются примеры запросов от разработчиков
    • SOAP - больше возможностей по безопасности. Проще тестировать за счет WSDL
      • Медленнее
      • Более ресурсоемкий
      • Разрабатывать дольше
79
Q

Формат XML. Использование и правила синтаксиса

A
80
Q

Формат JSON. Использование и правила синтаксиса

A
81
Q

Написание тестов API

A
  • План
    • Изучение документации
    • Пишем тесты
    • Тестируем
  • Требования\входные данные
    • Параметры\атрибуты сервиса
    • Образцы запросов (предоставляет разработчик)
  • Тест-кейсы
    • Smoke (один запрос на один метод)
    • Critical Path (все валидные)
    • Extended (все невалидные)
  • Специфические тесты
    • Пустые элементы
    • Комментарии
    • Валидность ответов согласно схеме (при наличии)
    • Проверки с обязательными и необязательными атрибутами
    • Проверки с дополнительными и недопустимыми атрибутами
    • Различные типы данных (str вместо Int)
    • Дубликаты атрибутов\элементов
    • Порядок атрибутов\элементов
    • Длины строк\чисел
    • Невалидные данные
  • Что смотреть в ответе
    • Статус код
    • Заголовки
    • Тело ответа
82
Q

Где хранится документация API? Что в ней указывается?

A

Swagger

  1. Ручки
  2. Методы
  3. Структура запроса
  4. Структура ответа
  5. Коды ответа
83
Q

Какие позитивные и негативные проверки можно проводить c API?

A
84
Q

Идентификация, аутентификация, авторизация.

A
85
Q

Что такое bash? Как используется в тестировании? Как включить на Windows?

A

Командная оболочка UNIX

86
Q

Базовые команды bash (создание, изменение, удаление папок и файлов, просмотр содержимого, поиск, вывод в консоль и в файлы, текстовые редакторы, работа с процессами, curl)

A
  • ls - отобразить содержимое директории
    • ls -la
    • la -RA - отобразить содержимое всех директорий
  • pwd - показать имя текущей директории
  • touch - создание файла
  • mkdir - создание папки
  • rm - удаление файлов
  • rm -r - удаление папок с файлами
  • mv - переименование или перемещение файлов\папок
  • cp - копирование файлов\папок
  • cat - вывести содержимое файла в консоль
  • less - отобразить содержимое файла в отдельной “сессии” с перемоткой и поиском
  • vi, vim, nano - текстовые редакторы
  • grep - поиск в файле
    • -i - убрать регистрозависимость
    • -v - исключить выбранное значение из файла
    • -с - отобразить количество упоминаний в файле (-ic - исключив регистрозависимость)
    • -R - поиск в файлах папки
    • cat bash.txt | grep -i text
    • ls | grep file
  • find - поиск файлов в папке
    • find . -name <name>
    • find . -type d <name>
    • find . -name <name> -delete -print - найти и удалить файлы (например *png - все файлы с расширением png)
  • echo “text” > file.txt - вывод текста в файл (с перезаписью файла)
    • echo “text” **>>** file.txt - добавить (append) текст в файл
    • cat file1.txt file2.txt > file3.txt - вывод содержимого двух файлов в один файл
  • ps - отобразить рабочие процессы запущенные в текущей консоли
    • ps -x - отобразить все рабочие процессы
    • ps -u - отобразить детальную информацию о процессах текущего пользователя
    • ps -au - детальная информация о всех процессах текущего пользователя
    • ps -aux - детальная информация о всех процессах всех пользователей
  • top - отображение процессов в реальном времени
  • kill <PID> - остановить процесс по его номеру PID (который можно получить через PS)</PID>
87
Q

ping и curl

A
  • ping
    • ping -c 3 [google.com](http://google.com) - отправить 3 пакета
    • ping -i 3 google.com - отправлять пакет каждые 3 секунды
  • curl - позволяет отправлять запросы и получать ответы
    • По умолчанию используется метод GET
    • curl -X POST - использовать метод POST
    • curl -X POST https://reqres.in/api/login --data "[email=eve.holt@reqres.in](mailto:email=eve.holt@reqres.in)" --data "password=ci tyslicka"
88
Q

Что такое репозиторий, ветка, коммит, хэш, pull request, code review?

A
  • Репозиторий - центральное хранилище для обработки и отслеживания изменений в файлах и папках
  • Ветка - ответвление от основной части
  • Коммит - снапшот текущего
  • Хэш - хэш сумма, определяющая последний коммит в git репозиторий и являющаяся идентификатором этого коммита. Когда коммитов много — за счёт sha можно ориентироваться в них и проверять какие изменения сделаны в каждом коммите.
  • pull request - запрос на вливание изменений из вашей ветки в основную ветку исходного репозитория
  • code review -
89
Q

Базовые команды (настройка git и github, конфигурация, создание и клонирование репозитория, создание коммита, push и pull, создание веток, переключение по веткам, слияние веток, откат изменений)

A
  1. Настройка ~/.gitconfig
[user]
	name = Sergey
	email = dessummiisluge@gmail.com
  • git status - текущий статус репозитория
  • git fetch - получить информацию об изменениях в репозитории
  • git add <filename> - начать отслеживать файлы
    • git add . - добавить все файлы в текущей папке
  • git commit -m “комментарий” - закоммитить измененеия
    • -a - закоммитить все файлы
  • git pull - стянуть данные с репозитория
  • git push - отправить данные в репозиторий
  • git log - просмотреть все происходившие коммиты (кто, когда, что)
    • git log —author Sergey - отобразить все коммиты пользователя
  • git show <commit_hash> - отобразить содержание коммита
  • git blame <filename> - узнать информацию об авторе сторки в файле
    • git blame <filename> | grep <text>
    • git blame <filename> | grep <author_name>
  • git diff - отобразить какие изменения были внесены в файл
  • git reset HEAD~1 - откатить изменения
  • git merge —abort - сброс изменений при конфликте
  • git checkout <filename> - откатить изменения в файле
    • git checkout . - откатить изменения во всех файлах в текущей папке
  • git stash - добавление изменения во временное хранилище
    • git stash pop - восстановить изменения из хранилища
    • git stash clear - удалить изменения из хранилища

Ветки

  • git branch <name> - создание ветки (работает только после первого коммита)
    • git branch -m <name> <rename> - переименовать ветку
    • Дальше началось дохрена непонятного
  • git branch - посмотреть список веток
  • git checkout <branch_name> - сменить ветку
  • git push -u origin <branch_name> - запушить и создать новую ветку на удаленном репозитории
  • git checkout - - возврат в мастер ветку
  • git merge <branch_name> - смержить ветку в мастер
90
Q

Что такое environment? Виды, что делают на каждом?

A
  1. Development - developers, no client data
  2. Testing - QA engineers, no client data
  3. Staging - QA engineers and\or clients for UAT, limited prod data
  4. Production - used by clients live, full prod data
91
Q

Что такое CI/CD? Описание всего процесса и инструментов, которые могут на них применяться

A
92
Q

Что такое code freeze?

A

is stopping any modification in the code for a certain period of time. It generally takes place at the later stages of SDLC, while the software is being planned for a release. Thus, it is done to limit further changes to the software just before being shipped to the customers.

93
Q

Что такое БД и СУБД (их примеры)?

A
  • База данных - набор сведений хранящихся в упорядоченном виде
  • СУБД - система управления базой данных (создание, редактирование, удаление, безопасность и т.д.)
    • MySql
    • MS SQL
    • Oracle
    • MongoDB
    • Postresql
  • Отличия: БД - объект (просто данные), СУБД - субъект (программа)
94
Q

SQL

A

Structured Query Language

95
Q

Виды БД. Отличия реляционных и нереляционных БД

A
  • Реляционные - SQL, нереляционные - NoSQL
    • SQL - надежные, стабильные, но медленные
    • NoSQL - имеют разный формат хранения данных, скорость высокая, надежность ниже
  • Типы:
    • Реляционные БД (SQL) основаны на таблицах с данными, связанными через общие ключи.
    • Нереляционные БД (известные как NoSQL) структурируют данные не по табличной схеме, а используют форматы, такие как ключ-значение, документы, колонки или графы.
    • Иерархическая - данные хранятся в форме иерархии, элементы связаны только со своими родителями и детьми
    • Сетевая - данные хранятся в форме иерархии, но есть связи между неродителями и недетьми
96
Q

Типы отношений в SQL?

A
  • 1 к 1
  • 1 ко многим
  • Многие к 1
  • Многие ко многим
97
Q

Нормализация. Нормальные формы

A
  • Нормализация
    • 1NF (атомарность) - Первая нормальная форма сводится к трем правилам:Каждая ячейка таблицы может хранить только одно значениеВсе данные в одной колонке могут быть только одного типаКаждая запись в таблице должна однозначно отличаться от других записей
    • 2NF - Вторая нормальная форма включает в себя два требования:Таблица должна быть в первой нормальной формеВсе неключевые атрибуты таблицы должны зависеть от первичного ключа
    • 3NF - Третья нормальная форма включает в себя два пункта:Таблица должна быть во второй нормальной формеВсе колонки в таблице зависят от первичного ключа и не зависят друг от друга
98
Q

Запросы на создание, изменение, удаление таблиц

A
  • Работа с БД:
    • SHOW databases; - показать все БД
    • CREATE database <db_name>; - создать БД
    • DROP database <db_name>; - удалить БД
    • USE <db_name>; - выбрать БД для использования
  • Работа с таблицами:
    • Создание таблицы
      • Нужно задать столбцы
      • Указать тип данных для каждого и макс количество символов
      • Указать id
      • NULL - может быть пустым; NOT NULL - не может быть пустым
      CREATE table courses
      -> (id INT(11) NOT NULL PRIMARY KEY,
      -> faculty VARCHAR(55) NULL,
      -> number INT(2) NULL);
    • SELECT * FROM <table_name>; - отобразить все значения в таблице
    • DESC <table_name>; - отобразить описание таблицы
    • DROP table <table_name>; - удалить таблицу
    • INSERT INTO courses VALUES (val1, val2, val3...);
    • DELETE FROM courses WHERE faculty="gum"; - удалить значение из таблицы
      • DELETE FROM courses - удаляет все значения
    • UPDATE courses SET faculty="gum" WHERE faculty="geo"; - изменение значения
    • ALTER TABLE courses DROP COLUMN id; - удаление столбца
    • ALTER TABLE courses ADD COLUMN id INT AFTER number; - добавление столбца (имя тип данных, после какого столбца добавить)
99
Q

SELECT-запросы. Агрегатные функции. Вложенные подзапросы

A
  • SELECT * FROM <table_name>; - отобразить все значения в таблице
  • SELECT **DISTINCT** number FROM courses; - выбрать все значения без дубликатов
  • SELECT * FROM courses **LIMIT 2**; - ограничить вывод n (в примере 2-мя) строками
  • SELECT number **AS номер** FROM courses; - использовать alias (псевдоним) для названия столбца
  • Cравнения:
    • SELECT faculty, number FROM courses WHERE **faculty = "bio"**;
    • SELECT faculty, number FROM courses WHERE **number > 1**;
  • Логические операции AND\OR:
    • SELECT * FROM courses WHERE number = 1 **AND** faculty = "bio";
  • Поиск похожих значений:
    • _ - обозначает 1 символ
    • % - 0 или множество символов
    • [acs] - или a или c или s на месте одного символа
      • [a-f] - на месте одного символа от a до f
      • [!acf] - на месте одного символа - не эти символы
    • SELECT * FROM courses WHERE faculty **LIKE "%o"**; - с буквой о на конце
  • Диапазон:
    • SELECT * FROM courses WHERE number **BETWEEN 2 AND 4**; - между 2 и 4
    • SELECT * FROM courses WHERE **NOT** number BETWEEN 2 AND 4; - не между 2 и 4
  • Точное значение:
    • SELECT * FROM courses WHERE number IN (1,4); - отобразить только значения 1 и 4
  • Объединение логических функций:
    • SELECT * FROM courses WHERE (faculty = “bio” OR faculty = “math”) AND number = 1;
  • Сортировка ORDER BY:
    • SELECT * FROM courses **ORDER BY faculty**;
    • SELECT * FROM courses **ORDER BY faculty DESC**; - сортировка в обратном порядке
  • Агрегатные функции:
    • SELECT **AVG(number)** FROM courses; - посчитать среднее значение всех значений из столбца
    • AVG - среднее значение
    • SUM - сумма
    • MIN\MAX
    • COUNT - количество заполненных записей

Вложенные подзапросы

`
SELECT fname, lname, gender, id FROM general WHERE age IN (SELECT age FROM general WHERE id > 1 AND age >= 21);
`

100
Q

JOIN-запросы. Inner, Left, Right

A
  • JOIN:
    • SELECT courses.faculty, general.fname, general.lname FROM courses JOIN general ON courses.id = general.id
  • LEFT JOIN - все строки из 1-й таблицы, даже если их нет во 2-й
  • RIGHT JOIN - все строки из 2-й таблицы, даже если их нет в 1-й
101
Q

NULL, UNION, HAVING

A
  • NULL - не пустое значение, это тип данных. Значит, что запись может остаться без значений при создании таблицы
    • SELECT field_name FROM table WHERE field_name IS NULL;
    • SELECT field_name FROM table WHERE field_name IS NOT NULL;
  • UNION - используется для объединения нескольких селектов
    • Каждая таблица из SELECT должна иметь одинаковое количество полей
    • Поля из каждого SELECT должны иметь одинаковые типы данных
    • Поля из каждого SELECT должны иметь одинаковый порядок
    • SELECT field_names FROM table1 **UNION** SELECT field_names FROM table2; - только уникальные значения
    • SELECT field_names FROM table1 **UNION ALL** SELECT field_names FROM table2; - с дублирующими значениями
  • HAVING - заменяет WHERE при использовании агрегатных функций
    • SELECT field_names FROM table WHERE *condition* GROUP BY field_names HAVING *condition* ORDER BY field_name;
    • SELECT rental_id, SUM(amount) FROM sekila.payment WHERE payment_date > '2005' GROUP BY rental_id HAVING SUM(amount) >=10;
102
Q

В каком порядке обрабатываются операторы? SQL

A

https://www.dev-notes.ru/articles/devops/understand-the-sql-execution-order/

103
Q

Для чего БД используются в тестировании?

A
104
Q

Какой запрос лучше сделать до удаления данных? SQL

A
105
Q

Отличие 401 от 403

A

401 - Unauthorized. вы пытаетесь получить доступ к странице, на которую нужно сначала войти, используя действительный ID пользователя и пароль для просмотра.
403 - Forbidden, доступ к запрошенному ресурсу запрещен.

106
Q

Идемпотентность

A

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

Идемпотентные HTTP методы:
1. GET
2. PUT
3. DELETE

107
Q

URL - расшифровка

A

Uniform Resource Locator

108
Q

URI - расшифровка

A

Uniform Resource Identifier

109
Q

URN - расшифровка

A

Uniform Resource Name

QA (29 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions