---

ОТЧЕТ ПО РЕЗУЛЬТАТАМ ИЗУЧЕНИЯ ГЛАВЫ 4: «ТЕСТОВЫЕ ДАННЫЕ И СЦЕНАРИИ»
1. КОНСПЕКТ ТЕОРЕТИЧЕСКОЙ ЧАСТИ (Стр. 78–90)
1.1. Основные понятия
 * Тестовый сценарий (Test Case / Тест-кейс): набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия (например, для проверки сценария работы программы или соответствия требованию к ПО).
 * Тестовый оракул (Test Oracle): источник, при помощи которого определяются ожидаемые результаты для сопоставления с реальным поведением системы (ТЗ, руководство пользователя, спецификация, эталонная система или экспертиза специалиста). Исходный программный код тестовым оракулом выступать не может.
 * Тестовое условие (Test Condition): объект или событие в компоненте или системе, которые должны быть проверены одним или несколькими тестовыми наборами (функция, транзакция, свойство, атрибут качества или структурный элемент).
 * Базовая структура сценария:
   * Предусловие (Pre Conditions): перечень действий или критериев, переводящих систему в состояние, пригодное для тестирования.
   * Шаги и ожидаемые результаты (Actions/Results): цепочка действий по изменению состояния системы и критерии верификации корректности ее отклика.
   * Постусловие (Post Conditions): действия, возвращающие систему в исходное состояние после завершения проверки.
 * Тестовые данные (Test Data): данные, существующие в системе (например, в БД) до начала выполнения теста, влияющие на ее поведение или испытывающие влияние с ее стороны.
 * Тестовый набор (Test Suite): группа взаимосвязанных сценариев, объединенных по функциональной области, объекту, целям или типам проверок.
 * Проектирование тестов: включает тест-анализ и тест-дизайн с выбором подходов («черный ящик», на основе спецификаций, структуры или экспертного опыта).
1.2. Жизненный цикл и правила построения тестовых сценариев
 * Состояния тест-кейса:
   * Создан (New): начальный статус после формирования артефакта.
   * Запланирован / Не выполнен (Planned / Not tested): готов к прогону и включен в план итерации.
   * Выполняется (Work in progress): кейс находится в процессе выполнения.
   * Пропущен (Skipped): проверка отменена из-за смены логики или нехватки времени.
   * Провален (Failed): фактический результат хотя бы одного шага не совпал с ожидаемым.
   * Пройден успешно (Passed): все шаги выполнены без расхождений с эталоном.
   * Заблокирован (Blocked): прохождение невозможно из-за блокирующего стороннего дефекта.
   * Закрыт (Closed): работа по кейсу на текущей итерации окончена.
   * Требует доработки (Not ready): статус для переработки кейса при обнаружении неточностей или изменении требований.
 * Требования к оформлению:
   * Заглавие (Title): емкое, информативное и уникальное описание сути проверки.
   * Ожидаемые результаты (Expected Results): однозначное описание поведения системы, исключающее субъективные трактовки (без конструкций «если..., то...»).
   * Шаги (Steps): строгая последовательность пронумерованных действий в безличной форме («открыть», «ввести», «нажать»).
 * Подход Data-driven: объединение схожих проверок с вынесением наборов тестовых данных (различных форматов файлов, граничных значений) в параметры, что сокращает дублирование документации.
 * Уровень детализации: разделение на высокоуровневые описания для опытных специалистов и пошаговые инструкции со ссылками на базу знаний (KB) для новичков.
1.3. Атрибуты тест-кейса и версионность
 * Идентификатор (ID): уникальный индекс с префиксами для быстрой идентификации.
 * Приоритет (Priority): важность и очередность прохождения (A–E, 1–5, High/Medium/Low), определяемая рисками и значимостью требований.
 * Связанное требование (Requirement): обеспечивает вертикальную и горизонтальную прослеживаемость (traceability).
 * Модуль и подмодуль: структурная принадлежность к архитектуре декомпозиции ПО.
 * Время прохождения: плановая оценка трудозатрат.
 * Системы ведения документации: фиксация истории изменений и статистики прогона (в Git или специализированных TMS: TestRail, TestLink).
1.4. Метрики тестовых сценариев
 * Test Coverage (Покрытие требований тест-кейсами):
   
   
   где R_{\text{Covered}} — число покрытых тестами требований, а R_{\text{Total}} — общее количество требований в спецификации.
 * Passed/Failed Test Cases (Успешность прохождения):
   
   
   где T_{\text{Success}} — число успешно пройденных сценариев, а T_{\text{Total}} — суммарный объем выполненных проверок. Минимальные проектные пороги: начальная фаза — от 10%, основная — от 40%, финальная — не менее 85%.
 * Not Run Test Cases: общее количество не запущенных в рамках итерации тестов.
2. ОТВЕТЫ НА ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ (Стр. 90)
 * Что такое тестовые сценарии?
   Это тест-кейсы (совокупность набора входных данных, условий выполнения, шагов и ожидаемых результатов), сформированные с целью всесторонней проверки конкретной функциональности или соответствия установленному требованию к ПО.
 * Объясните, что представляют собой тестовые данные.
   Это набор данных, существующих в системе (в базе данных, файлах конфигурации, памяти) к началу выполнения теста, которые непосредственно влияют на логику работы программы или сами модифицируются в процессе теста.
 * Что такое тестовый оракул?
   Источник данных и эталонных правил, позволяющий определить ожидаемый результат для последующего сопоставления с фактическим поведением системы. В роли оракула выступают ТЗ, спецификации, руководства, отраслевые стандарты, стабильные предыдущие сборки или профессиональный опыт, но не сам программный код.
 * Кому полезнее тестовые сценарии — новичкам или профессионалам?
   Новичкам детальные пошаговые тест-кейсы полезнее, так как они служат подробной обучающей инструкцией и исключают риск ошибок из-за незнания системы. Опытным специалистам достаточен высокоуровневый формат (чек-листы), не требующий лишних затрат времени на чтение элементарных шагов.
 * Опишите стандартные атрибуты тест-кейса.
   * Номер (ID): уникальный идентификатор проверки.
   * Название (Title): краткая формулировка сути проверки.
   * Предварительные шаги (Pre-conditions): условия и данные, необходимые до старта.
   * Шаги (Steps): перечень выполняемых действий.
   * Ожидаемый результат (Expected Result): эталонный отклик системы.
 * Назовите все возможные атрибуты тест-кейса. Что они собой представляют?
   * Идентификатор (ID): уникальный номер со смысловым кодовым обозначением.
   * Приоритет (Priority): градация важности и срочности прохождения.
   * Связанное требование (Requirement): ссылка на пункт технического задания.
   * Модуль и подмодуль (Module/Submodule): структурная привязка к компоненту ПО.
   * Планируемое время прохождения: расчетное время выполнения проверки.
   * Предусловия (Pre-conditions): начальное состояние окружения и БД.
   * Шаги (Steps): пошаговый алгоритм выполнения.
   * Ожидаемый результат (Expected Result): нормативное поведение ПО.
   * Постусловия (Post-conditions): действия по очистке и откату изменений.
   * История изменений и прохождений: автор, дата правок, статус (Passed/Failed), фактические трудозатраты и привязанные дефекты.
3. ПРАКТИЧЕСКОЕ ЗАДАНИЕ (Стр. 90–91)
 * Предметная область: Вариант 1.6 — Онлайн-банк.
 * Объект тестирования: Веб-модуль «Личный кабинет клиента: Аутентификация и Переводы».
Разработанные тестовые сценарии (Тест-кейсы)
Тест-кейс TC_BANK_01
 * Модуль / Подмодуль: Авторизация / Форма входа
 * Приоритет: High (Критический)
 * Связанное требование: REQ_AUTH_01 (Аутентификация клиента)
 * Заглавие: Успешный вход в личный кабинет с валидными учетными данными
 * Предусловия: Клиент зарегистрирован в системе (логин: client_ivan, пароль: ValidPass123!).
 * Шаги:
   * Перейти на страницу входа в онлайн-банк.
   * В поле «Логин» ввести client_ivan.
   * В поле «Пароль» ввести ValidPass123!.
   * Нажать кнопку «Войти».
 * Ожидаемый результат: Происходит успешная авторизация; пользователь перенаправляется на главную страницу личного кабинета; отображается баланс счетов.
 * Постусловия: Нажать кнопку «Выйти».
Тест-кейс TC_BANK_02
 * Модуль / Подмодуль: Авторизация / Форма входа
 * Приоритет: High
 * Связанное требование: REQ_AUTH_02 (Защита от несанкционированного доступа)
 * Заглавие: Попытка входа с неверным паролем
 * Предусловия: Пользователь client_ivan зарегистрирован.
 * Шаги:
   * Открыть форму авторизации.
   * Ввести логин client_ivan.
   * Ввести неверный пароль WrongPass000!.
   * Нажать кнопку «Войти».
 * Ожидаемый результат: Доступ отклоняется; отображается предупреждение красного цвета: «Неверный логин или пароль»; пароль сбрасывается, логин сохраняется.
 * Постусловия: Отсутствуют.
Тест-кейс TC_BANK_03
 * Модуль / Подмодуль: Платежи / Перевод по номеру телефона
 * Приоритет: High
 * Связанное требование: REQ_TRANS_01 (Внутрибанковские переводы)
 * Заглавие: Перевод средств по номеру телефона при достаточном балансе
 * Предусловия: Пользователь авторизован; на счете списания доступно не менее 1 000 руб.; получатель с номером +79991234567 существует.
 * Шаги:
   * Перейти во вкладку «Переводы» \rightarrow «По номеру телефона».
   * В поле «Номер получателя» ввести +79991234567.
   * В поле «Сумма перевода» ввести 500.
   * Нажать кнопку «Перевести».
   * Ввести код подтверждения из SMS (0000) и нажать «Подтвердить».
 * Ожидаемый результат: Выводится сообщение «Перевод успешно выполнен»; формируется электронная квитанция; баланс уменьшается ровно на 500 руб.
 * Постусловия: Отсутствуют.
Тест-кейс TC_BANK_04
 * Модуль / Подмодуль: Платежи / Перевод по номеру телефона
 * Приоритет: Medium
 * Связанное требование: REQ_TRANS_03 (Проверка лимитов и остатка)
 * Заглавие: Оформление перевода на сумму, превышающую остаток на счете
 * Предусловия: Пользователь авторизован; баланс счета составляет 200 руб.
 * Шаги:
   * Открыть форму перевода по номеру телефона.
   * В поле «Номер получателя» ввести +79991234567.
   * В поле «Сумма перевода» указать 1000.
   * Нажать кнопку «Перевести».
 * Ожидаемый результат: Кнопка подтверждения блокируется; под полем суммы появляется текст ошибки: «Недостаточно средств на выбранном счете».
 * Постусловия: Отсутствуют.
Тест-кейс TC_BANK_05
 * Модуль / Подмодуль: Платежи / Валидация полей ввода
 * Приоритет: Low
 * Связанное требование: REQ_TRANS_04 (Контроль минимальной суммы)
 * Заглавие: Ввод нулевой суммы при переводе
 * Предусловия: Открыта форма оформления перевода.
 * Шаги:
   * В поле «Номер получателя» ввести +79991234567.
   * В поле «Сумма перевода» ввести 0.
   * Нажать кнопку «Перевести».
 * Ожидаемый результат: Операция не отправляется на сервер; отображается ошибка валидации: «Минимальная сумма операции — 1 руб.».
 * Постусловия: Отсутствуют.
Результаты тестирования и расчет метрик
Сводка выполнения:
 * Всего требований в спецификации (R_{\text{Total}}): 5
 * Покрыто тест-кейсами (R_{\text{Covered}}): 5
 * Всего запланировано проверок (T_{\text{All}}): 5
 * Выполнено тестов (T_{\text{Total}}): 4
 * Успешно пройдено (T_{\text{Success}}): 3
 * Завершилось ошибкой (T_{\text{Failed}}): 1 (TC_BANK_02 — не отобразилось сообщение об ошибке)
 * Не запускалось (T_{\text{NotRun}}): 1 (TC_BANK_05)
Расчетные формулы:
 * Покрытие требований (Test Coverage):
   
 * Процент успешных тестов (Passed Ratio):
   
 * Не запущенные сценарии (Not Run):