Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

ЛР5_АИС_МО417_ИбрагимоваРахимоваСтепановаШакиров

.docx
Скачиваний:
9
Добавлен:
28.08.2022
Размер:
243.34 Кб
Скачать

УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

ФАКУЛЬТЕТ ИНФОРМАТИКИ И РОБОТОТЕХНИКИ

КАФЕДРА ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И КИБЕРНЕТИКИ

Отчёт по лабораторной работе №5

«Тестирование программного обеспечения»

по предмету: «Администрирование информационных систем»

Выполнили:

студенты группы МО-417

Ибрагимова К.Б. Рахимова А.М.

Степанова Д.Д. Шакиров А.Р.

Проверил:

Сазонова Е. Ю.

Уфа 2021

Цель работы

Изучение процесса тестирования программного обеспечения.

Задание

  • изучить классификацию видов тестирования, виды рабочей документации.

  • изучить процесс генерации тестов различных видов.

  • изучить планирование, тестирование и отладку приложения.

  • провести отладку и протестировать клиент-серверное приложение.

Проведём отладку, функциональное и интеграционное тестирование клиент-серверного приложения.

Functional testing (функциональное тестирование) – это тестирование, основанное на анализе спецификации, функциональности компонента или системы. Функциональным можно назвать любой вид тестирования, который, согласно требованиям, проверяет правильную работу.

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

Будем тестировать следующие функции приложения, описанные в ТЗ:

  • Регистрация пользователя

  • Авторизация пользователя

  • Получение данных о других пользователях системы

  • Отправка сообщения другому пользователю

  • Получение сообщений от других пользователей системы

  • Заполнение данных о текущем пользователе

  • Обеспечение контроля доступа к данным

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

Существует несколько разновидностей рабочей тестовой документации Check List, Acceptance Sheet, Test Survey, Test Cases. Будем использовать в качестве тестовой документации тест кейсы.

Test Cases (набор тест-кейсов) - набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию.

Выделим преимущества выбранного нами вида тестовой документации:

  • Контроль качества продукта с течением времени и сохранение истории работ по тестированию.

  • Структурированный системный подход к тестированию снижает вероятность пропуска ошибки.

  • Выполнение тестов не требует дополнительного времени на общение с разработчиками и аналитиками, работу с требованиями.

Для написания тест-кейсами воспользуемся электронными таблицами Microsoft Excel. Были написаны 9 тест-кейсов, с описанием требуемых шагов для проверки, ожидаемым результатом и фактическим результатом. Фактический результат описывается в виде статуса:

  • passed — проверено, соответствует ожидаемому результату, работает согласно заявленным требованиям. Комментарий необязателен.

  • failed — поведение системы не соответствует ожидаемым требованиям, найден дефект. Пишется комментарий, желательно указывается ИД бага в багтрекенговой системе.

  • blocked — выполнить проверку невозможно, имеются обстоятельства (дефект, модуль, компонент), которые блокируют дальнейшую проверку. В комментарии указывается причина.

  • skipped — тест пропущен. Возможно, отсутствует необходимый модуль для проверки, который будет не реализован. В комментарии указывается причина пропуска.

  • draft - тест пропущен, либо не начат. Отсутствует объект тестирования, который будет реализован позже. Комментарий не обязателен.

Рисунок 2. Тест-кейсы

Функции разработанного приложения работают корректно, ошибок не выявлено.

Integration (интеграционное) – тестируется взаимодействие между интегрированными компонентами или системами. Целью данного уровня тестирования является выявление дефектов взаимодействия между программными модулями при их интеграции.

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

Рисунок 2. Информация об отправляемом запросе на сервер клиентом

Рисунок 3. Содержимое полученного ответа с сервера

Взаимодействие клиентского и серверного приложений происходит корректно.

Реализуем юнит-тесты для клиентской части клиент-серверного приложения с помощью фреймворка Jest.

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

Рисунок 4. Юнит-тесты

Рисунок 5. Результат запуска юнит-тестов

Вспомогательные функции в компонента профиля работают корректно.

Вывод

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