3 сем / Руденский_3316_ПР3
.docxМинобрнауки России
Санкт-петербургский государственный
Электротехнический университет
«ЛЭТИ» им. В.И. Ульянова (Ленина)
Кафедра вычислительной техники
Отчёт
Практическая работа №3
По дисциплине «Введение в тестирование ПО»
Тема: «Тестирование на основе UML-диаграммы автомата»
Студент гр. 3316 |
|
Руденский И.М. |
Преподаватель |
|
Турнецкая Е.Л. |
Санкт-Петербург
2024
Введение
Цель работы: получение базовых навыков описания вариантов использования (Use Cases, прецедентов) для подготовки тестирования.
Тестирование на основе вариантов использования (Use Case Testing) — это методика тестирования, которая фокусируется на проверке функциональности системы, основанной на её вариантах использования.
Описание техники:
Варианты использования описывают взаимодействие пользователя с системой, включая последовательность действий, которые выполняет пользователь, и реакции системы на них. В основе этой методики лежит тестирование пользовательских сценариев, отражающих реальные бизнес-процессы или действия конечного пользователя.
Назначение:
Проверка функциональности системы: убедиться, что система правильно выполняет бизнес-функции, соответствующие ожиданиям пользователя.
Повышение качества пользовательского опыта: Тестирование реальных сценариев использования помогает обнаружить проблемы, которые могут возникнуть у конечного пользователя.
Идентификация дефектов на уровне взаимодействия: Метод позволяет найти ошибки в логике процессов, связанных с входными данными, состояниями системы и её ответами на действия пользователя.
Обеспечение согласованности требований и реализации: Варианты использования обеспечивают прямую связь между бизнес-требованиями и тестами.
Полная диаграмма вариантов использования
Ход работы
Таблица 1: вариант использования «аутентификация пользователя»
ID Варианта использования: |
Id1 |
||
Наименование варианта использования: |
Аутентификация пользователя |
||
Кем создан: |
|
Кем в последний раз изменен: |
|
Дата создания: |
|
Дата последнего изменения: |
|
Акторы: |
Пользователь: физическое лицо, желающее получить доступ к системе офиса продаж. |
||
Описание: |
Пользователь вводит свои учетные данные (логин и пароль) для получения доступа к функциональности системы. |
||
Предварительные условия: |
Учетная запись пользователя зарегистрирована в системе. У пользователя есть действительные учетные данные. |
||
Постусловие: |
Пользователь успешно вошел в систему, и ему доступны соответствующие функции. |
||
Нормальный ход событий: |
1. Пользователь вводит логин и пароль. 2. Система проверяет введенные данные. 3. Если данные корректны, пользователь получает доступ к системе. |
||
Альтернативный ход событий: |
В случае ошибки ввода система предлагает повторить попытку. После трех неудачных попыток доступ временно блокируется. |
||
Исключения: |
База данных недоступна: пользователь видит сообщение о технических работах. |
||
Содержит: |
|
||
Приоритет: |
Высокий |
||
Частота использования: |
Часто |
||
Бизнес-правила |
|
||
Специальные требования: |
Поддержка шифрования пароля, соответствие требованиям безопасности. |
||
Предпосылки (предположения): |
|
||
Примечания и вопросы: |
|
||
Графическое представление:
|
|||
Таблица 2: вариант использования «оформление заявки на продажу товара»
ID Варианта использования: |
Id2 |
||
Наименование варианта использования: |
Оформление заявки на продажу товара |
||
Кем создан: |
|
Кем в последний раз изменен: |
|
Дата создания: |
|
Дата последнего изменения: |
|
Акторы: |
Менеджер по продажам: сотрудник, который обрабатывает заявки клиентов и оформляет их в системе |
||
Описание: |
Менеджер заполняет заявку на продажу товара, указывая клиента, товар, количество и условия поставки. |
||
Предварительные условия: |
У менеджера есть доступ к системе, клиент и товар зарегистрированы в базе данных. |
||
Постусловие: |
Заявка успешно создана и сохранена в системе. |
||
Нормальный ход событий: |
1. Менеджер выбирает функцию "Оформить заявку". 2. Вводит данные клиента. 3. Указывает товар и его количество. 4. Проверяет доступность товара. 5. Сохраняет заявку в системе. |
||
Альтернативный ход событий: |
Если товара нет в наличии, менеджер предлагает клиенту оформить предварительный заказ. |
||
Исключения: |
Сбой системы: заявка не может быть сохранена, пользователь видит сообщение об ошибке. |
||
Содержит: |
|
||
Приоритет: |
Высокий |
||
Частота использования: |
Часто |
||
Бизнес-правила |
|
||
Специальные требования: |
Валидация введенных данных, проверка доступности товара в режиме реального времени. |
||
Предпосылки (предположения): |
|
||
Примечания и вопросы: |
|
||
Графическое представление:
|
|||
ID Варианта использования: |
Id3 |
||
Наименование варианта использования: |
Печать чека после оплаты |
||
Кем создан: |
|
Кем в последний раз изменен: |
|
Дата создания: |
|
Дата последнего изменения: |
|
Акторы: |
Кассир: сотрудник, выполняющий расчет с клиентом и выдающий подтверждение оплаты. |
||
Описание: |
Кассир формирует и распечатывает чек для клиента после успешной оплаты. |
||
Предварительные условия: |
Система зарегистрировала оплату, принтер подключен и готов к работе. |
||
Постусловие: |
Чек успешно распечатан и выдан клиенту. |
||
Нормальный ход событий: |
1. Кассир завершает процесс оплаты. 2. Система формирует чек. 3. Кассир отправляет чек на печать. 4. Чек распечатывается и выдается клиенту. |
||
Альтернативный ход событий: |
Если чек не распечатался, кассир повторяет попытку печати. |
||
Исключения: |
Принтер недоступен: кассир фиксирует ошибку и предлагает клиенту электронный чек. |
||
Содержит: |
|
||
Приоритет: |
Средний |
||
Частота использования: |
Часто |
||
Бизнес-правила |
|
||
Специальные требования: |
|
||
Предпосылки (предположения): |
|
||
Примечания и вопросы: |
|
||
Графическое представление:
|
|||
Вывод
В рамках выполнения данной работы была изучена и применена техника тестирования на основе UML-диаграммы автомата.
Были изучены принципы построения и интерпретации диаграмм состояний, включая переходы между состояниями, события, вызывающие эти переходы, и действия, выполняемые системой. В процессе работы была выполнена декомпозиция поведения системы и составлены таблицы вариантов использования для каждого из акторов. Это позволило отработать навык перевода диаграмм UML в последовательности действий, применимые в тестировании. Использование диаграммы автомата помогло структурировать тестовые сценарии и охватить как нормальные, так и исключительные ходы событий. Это позволило выработать системный подход к покрытию всех возможных ситуаций в поведении системы.
UML-диаграммы показали себя как мощный инструмент для анализа системы и разработки тестов. Такой подход помогает выявить потенциальные ошибки в логике работы системы ещё на этапе проектирования.
Использованные источники
1. Меженная, М. М. Тестирование, оценка программного обеспечения. Учебно-методическое пособие по дисциплине «Тестирование, оценка программного обеспечения» / М. М. Меженная, Т. В. Гордейчук, М. М. Борисик, О. С. Медведев, И.Ф. Киринович. – Минск: БГУИР, 2016. – 64 с
2. Буч, Г., Рамбо, Дж., Джекобсон, И. Язык UML. Руководство пользователя. Пер. с англ. — М.: Диалектика, 2020.
2. Майерс, Гленфорд Дж. Искусство тестирования программ. Пер. с англ. — М.: Вильямс, 2019.
3. Фаулер, М. UML. Основы. Краткое руководство. Пер. с англ. — СПб.: Символ-Плюс, 2021.