STLC - выполнение теста

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

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

При выполнении теста необходимо учитывать следующие моменты.

На этом этапе команда QA выполняет фактическую проверку AUT на основе подготовленных тестовых примеров и сравнивает пошаговый результат с ожидаемым результатом.
Критериями входа на этот этап является завершение плана тестирования и этапа разработки тестовых случаев, данные тестирования также должны быть готовы.
Перед официальным запуском теста всегда рекомендуется проверка настройки тестовой среды посредством дымового тестирования.
Критерии выхода требуют успешной проверки всех тестовых случаев; Дефекты следует закрыть или отсрочить; должно быть готово выполнение тестового примера и сводный отчет по дефектам.

Действия по выполнению теста

Целью этого этапа является проверка AUT в реальном времени перед переходом к производству / выпуску. Чтобы выйти из этого этапа, команда QA выполняет различные типы тестирования, чтобы гарантировать качество продукта. Наряду с этим отчет о дефектах и повторное тестирование также являются важной деятельностью на этом этапе. Ниже приведены важные действия на этом этапе:

Тестирование системной интеграции

Настоящая проверка продукта / AUT начинается здесь. Тестирование интеграции системы (SIT) - это метод тестирования черного ящика, который оценивает соответствие системы заданным требованиям / подготовленным тестовым примерам.

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

Состояние данных на уровне интеграции
Состояние данных на уровне базы данных
Состояние данных на уровне приложения

Note- При тестировании SIT команда QA пытается найти как можно больше дефектов, чтобы обеспечить качество. Основная задача здесь - найти как можно больше ошибок.

Сообщение о дефектах

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

При выполнении SIT-тестирования команда QA обнаруживает эти типы дефектов, и о них необходимо сообщать соответствующим членам команды. Участники предпринимают дальнейшие действия и устраняют дефекты. Еще одно преимущество отчетности - это упрощение отслеживания статуса дефектов. Существует множество популярных инструментов, таких как ALM, QC, JIRA, Version One, Bugzilla, которые поддерживают создание отчетов и отслеживание дефектов.

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

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

Отображение дефектов

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

Повторное тестирование

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

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

Регрессионное тестирование

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

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

Типы регрессионных тестов

Final Regression Tests- «Окончательное регрессионное тестирование» выполняется для проверки сборки, которая не подвергалась изменениям в течение определенного периода времени. Эта сборка развернута или отправлена клиентам.
Regression Tests - Выполняется обычное регрессионное тестирование, чтобы проверить, НЕ нарушила ли сборка какие-либо другие части приложения из-за недавних изменений кода для исправления дефектов или для улучшения.

Блок-схема деятельности

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