Фундаментальная теория Flashcards

Question

Этапы SDLC и их описание.

Answer 1

Анализ и сбор требований: на этом этапе происходит определение и сбор требований к программному продукту. Проводится исследование, выявляются потребности пользователей и определяются функциональные и нефункциональные требования. Проектирование: на этом этапе разрабатывается архитектура и дизайн программного продукта. Определяются компоненты системы, их взаимосвязи и интерфейсы. Разработка: на этом этапе происходит непосредственная реализация программного продукта. Программисты пишут код, создают функциональность и выполняют тестирование единиц кода. Тестирование: на этом этапе проводится тестирование программного продукта с целью выявления ошибок, дефектов и проверки его соответствия требованиям. Включает в себя функциональное тестирование, интеграционное тестирование, системное тестирование и другие виды тестирования. Развёртывание: на этом этапе программный продукт готовится к выпуску и установке на целевой среде. Включает в себя подготовку документации, инсталляцию, настройку и обучение пользователей. Эксплуатация и поддержка: после развёртывания программного продукта происходит его эксплуатация, поддержка и обновление. Ведется мониторинг работы системы, исправление ошибок и добавление новой функциональности.

Answer 2

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

Answer 3

- Проверка готовности ПО к релизу - Проверка ФР к ОР - Проверка соответствия требований и качества данного продукта

Answer 4

Проектная и продуктовая

Answer 5

Это спецификация (описание) того, что должно быть реализовано.

Answer 6

либо заказчик, либо аналитик, либо проджект/продукт менеджер.

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

(Trivial) почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта

Answer 16

Баги, возникающие в реальных условиях эксплуатации

Answer 17

20% функционала имеет 80% багов

Answer 18

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

Answer 19

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

Answer 20

Проверят взаимосвязь компоненты, которую проверяли на модульном уровне, с другой или другими компонентами, а также интеграцию компоненты с системой (проверка работы с ОС, сервисами и службами, базами данных, железом и т.д.). Часто в английских статьях называют service test или API test. В случае с интеграционными тестами редко когда требуется наличие UI, чтобы его проверить. Компоненты ПО или системы взаимодействуют с тестируемым модулем с помощью интерфейсов. Тут начинается участие тестирования. Это проверки API, работы сервисов (проверка логов на сервере, записи в БД) и т.п. Строго говоря на модульном уровне тестирование тоже участвует. Возможно помогает проектировать тесты или во время регресса смотрит за прогоном этих тестов, и если что-то падает, то принимает меры.

Answer 21

Чаще всего называют юнит тестированием. Реже называют модульным тестированием. На этом уровне тестируют атомарные части кода. Это могут быть классы, функции или методы классов. Пример: твоя компания разрабатывает приложение “Калькулятор”, которое умеет складывать и вычитать. Каждая операция это одна функция. Проверка каждой функции, которая не зависит от других, является юнит тестированием. Юнит тесты находят ошибки на фундаментальных уровнях, их легче разрабатывать и поддерживать. Важное преимущество модульных тестов в том, что они быстрые и при изменении кода позволяют быстро провести регресс (убедиться, что новый код не сломал старые части кода). Тест на компонентном уровне: 1. Всегда автоматизируют. 2. Модульных тестов всегда больше, чем тестов с других уровней. 3. Юнит тесты выполняются быстрее всех и требуют меньше ресурсов. 4.Практически всегда компонентные тесты не зависят от других модулей (на то они и юнит тесты) и UI системы. В 99% разработкой модульных тестов занимается разработчик, при нахождении ошибки на этом уровне не создается баг-репортов. Разработчик находит баг, правит, запускает и проверяет (абстрактно говоря это разработка через тестирование) и так по новой, пока тест не будет пройден успешно*. На модульном уровне разработчик (или автотестер) использует метод белого ящика. Он знает что принимает и отдает минимальная единица кода, и как она работает.

Answer 22

Тест (ручной, на высоких уровнях, или автотест, на низких уровнях), должен быть на том же уровне, что и тестируемый объект. Например, модульный тест (проверяющий функции, классы, объекты и т.п.) должен быть на компонентном уровне. Это неправильно, если на приемочном уровне запускается тест, который проверят минимальную единицу кода. Тесты уровнем выше не проверяют логику тестов уровнем/уровнями ниже. Чем выше тесты уровнем, тем они: сложней в реализации, и соответственно, дороже в реализации; важнее для бизнеса и критичней для пользователей; замедляют скорость прохождения тестовых наборов, например, регресса.