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

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

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

Следующие пункты должны быть рассмотрены для выполнения теста.

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

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

• Проверка правильности настройки тестовой среды всегда рекомендуется при проведении дымового тестирования до официального входа в тестовый режим.

• Критерии выхода требуют успешной проверки всех тестовых случаев; Дефекты должны быть закрыты или отложены; Выполнение теста и сводный отчет о дефектах должны быть готовы.

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

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

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

Критерии выхода требуют успешной проверки всех тестовых случаев; Дефекты должны быть закрыты или отложены; Выполнение теста и сводный отчет о дефектах должны быть готовы.

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

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

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

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

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

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

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

Отчет о дефектах

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

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

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

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

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

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

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

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

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

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

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

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

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

• Финальные регрессионные тесты — «Финальное регрессионное тестирование» выполняется для проверки сборки, которая не претерпела изменений в течение определенного периода времени. Эта сборка развернута или отправлена ​​клиентам.

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

Финальные регрессионные тесты — «Финальное регрессионное тестирование» выполняется для проверки сборки, которая не претерпела изменений в течение определенного периода времени. Эта сборка развернута или отправлена ​​клиентам.

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

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

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