---

Ниже — отчёт по Лабораторной работе № 2 в виде связного текста, построенный на базе Лабораторной работы № 1 (система учёта работ в автомастерской, каскадный ЖЦ).

---

Лабораторная работа № 2

Тестирование на этапах жизненного цикла проекта. Проектирование

Тема: Тестирование на этапах жизненного цикла проекта. Проектирование. Система учёта работ в автомастерской.

Цель: научиться анализировать ЖЦ с точки зрения тестирования на этапе проектирования.

---

Ход работы

Задание 1. Проектные модели системы

В качестве объекта проектирования рассматривается система учёта работ в автомастерской, для которой на этапе планирования была выбрана каскадная модель ЖЦ. На этапе проектирования для этой системы формируются следующие ключевые модели.

Внешний дизайн. Система представляется с точки зрения конечного пользователя — мастера-приёмщика и администратора автомастерской. Интерфейс включает главное окно с вкладкой «Заказы», в которой отображается список заказов с полями: номер заказа, ФИО клиента, марка автомобиля, описание работ, статус, дата создания. Предусмотрены кнопки «Добавить заказ», «Изменить статус», «Удалить заказ», а также панель фильтров по статусу и дате. Отдельная вкладка «Материалы» показывает количество доступных материалов на складе. Внешний дизайн ориентирован на простоту и минимум действий для выполнения типовых операций.

Проектирование программной архитектуры. Система декомпозируется на три подсистемы: подсистема интерфейса (формы и элементы управления), подсистема бизнес-логики (обработка заказов, смена статусов, проверка остатков материалов) и подсистема доступа к данным (работа с базой данных). Между подсистемами определены интерфейсы: интерфейсный модуль передаёт команды пользователя в модуль логики, а тот через модуль доступа к данным выполняет операции чтения и записи. Такая декомпозиция упрощает тестирование каждого модуля отдельно.

Проектирование организации данных. Определяются основные сущности: «Заказ», «Клиент», «Автомобиль», «Работа», «Материал», «Статус». Между ними устанавливаются связи: один клиент может иметь несколько заказов; один заказ включает несколько работ; для выполнения работ расходуются материалы. Описываются потоки данных: ввод данных о заказе → сохранение в БД → выборка для отображения → изменение статуса → обновление записи. Отдельно описываются преобразования данных, например пересчёт остатка материалов после выполнения заказа.

Описания алгоритмов. Для каждой ключевой функции задаются параметры, действия и результат. Например, алгоритм добавления заказа: параметры — данные клиента, автомобиля и перечень работ; действия — проверка корректности введённых данных, создание записи заказа, сохранение в БД; результат — новый заказ со статусом «Новый». Алгоритм изменения статуса: параметры — идентификатор заказа и новый статус; действия — проверка допустимости перехода, обновление записи; результат — заказ с изменённым статусом. Алгоритм удаления заказа: параметры — идентификатор заказа; действия — подтверждение удаления, удаление записи; результат — заказ отсутствует в списке.

Прототипы. Создаётся макет главного окна с вкладками «Заказы» и «Материалы», форма добавления заказа, форма изменения статуса и панель фильтров. Прототип позволяет проверить удобство интерфейса и уточнить требования до начала разработки.

---

Задание 2. Анализ проектных решений

2.1 Новые проектные решения или модификация текущих. В ходе проектирования уточнены и добавлены следующие решения: введена отдельная сущность «Статус» для формализации жизненного цикла заказа; добавлена проверка остатков материалов перед выполнением работ; введены фильтры по вкладке «Заказы» (по статусу и дате); предусмотрено подтверждение удаления заказа для защиты от случайных действий. Эти решения модифицируют первоначальные требования и делают проект более полным.

2.2 Эффективность проекта. Проект отвечает задаче эффективного создания тестируемого продукта: архитектура разделена на независимые подсистемы, что позволяет тестировать интерфейс, логику и доступ к данным отдельно. Чётко описанные алгоритмы и потоки данных упрощают подготовку тестовых сценариев и проверку граничных условий.

2.3 Соответствие требованиям. Все требования, выявленные на этапе планирования, формализованы в проекте: хранение данных о заказах, изменение статуса, добавление и удаление заказов, фильтры по вкладке «Заказы», хранение данных о количестве доступных материалов. Каждое требование отражено в соответствующей модели — внешнем дизайне, архитектуре, модели данных или описании алгоритмов.

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

2.5 Реалистичность проекта. Проект позволяет удовлетворить системные требования и ресурсы: выбранные средства разработки и СУБД соответствуют масштабу задачи, скорость обработки запросов при небольшом объёме данных соответствует ожиданиям пользователей, аппаратные требования минимальны. Выбор каскадной модели оправдан, так как требования зафиксированы и продукт относительно прост.

2.6 Соответствие сопровождению. В проекте описаны ситуации возникновения ошибок: некорректный ввод данных, попытка удалить несуществующий заказ, недостаток материалов на складе, недопустимый переход статуса. Для каждой ситуации предусмотрены сообщения пользователю и записи в журнале. Это упрощает сопровождение и диагностику проблем.

---

Задание 3. Ответы на вопросы

3.1 Что входит в план планирования ПО при тестировании?
В план планирования ПО при тестировании входят: определение целей и задач тестирования; выбор объектов тестирования; определение видов и уровней тестирования (модульное, интеграционное, системное, приёмочное); распределение ролей и ответственности; определение критериев начала и завершения тестирования; выбор инструментов и среды тестирования; оценка рисков; составление графика и оценка трудозатрат; определение порядка документирования результатов.

3.2 Что будет результатом планирования?
Результатом планирования является документ — план тестирования, который содержит цели, объём, стратегию, критерии, расписание, ресурсы и риски тестирования. Также результатом становятся сформированные тестовые сценарии, определённые метрики качества и согласованные с заказчиком критерии приёмки.

---

Задание 4. Отчёт

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