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

Лабораторная работа №1 Головков И.Е.

.docx
Скачиваний:
3
Добавлен:
26.06.2024
Размер:
39.99 Кб
Скачать

БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ

ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ»

(НИУ «БелГУ»)

ИНСТИТУТ ИНЖЕНЕРНЫХ И ЦИФРОВЫХ ТЕХНОЛОГИЙ

Кафедра информационных и робототехнических систем

Отчет по лабораторной работе № 1 по дисциплине «Верификация и тестирование информационных систем»

Вариант № 6

Тема работы «Составление, анализ и тестирование требований к программному обеспечению»

студента очного отделения

3 курса 12002108 группы

Головкова Игоря Евгеньевича

Проверил:

ст. пр. Смышляев Артем Геннадьевич

БЕЛГОРОД, 2023

Ход работы

Цель работы: научиться составлять и тестировать требования к

программному продукту на трех уровнях: бизнес-требования,

пользовательские требования, функциональные требования.

Задание: разработать трехуровневый набор требований (бизнес-

требования, пользовательские требования, функциональные требования) для

RESTful веб-сервиса и консольного клиентского приложения приема-

передачи и обработки структурированных данных заданной тематики

(согласно варианту, см. ниже), построенных с помощью Spring Framework.

Вариант 6. Тема «Микросхемы».

Файл со структурированными данными содержит строки со следующим набором полей:

а) название,

б) тип корпуса,

в) напряжение питания,

г) цена.

Клиент должен выполнять следующие виды обработки данных:

а) вывод на экран списка записей, упорядоченного по названию, по типу корпуса или по цене;

б) замена в списке одного типа корпуса на другой (заданный), с дальнейшим выводом результирующего списка;

в) определение количества записей с напряжением питания более 5В;

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

Исходя из требований, объекты класса микросхем будут иметь следующие поля (атрибуты):

  • id – идентификатор, целочисленный тип данных;

  • name - название, строковый (символьный) тип данных;

  • frameType - тип корпуса, строковый (символьный) тип данных;

  • voltage – напряжение, тип данных - число с плавающей точкой;

  • price – цена, целочисленный типа данных.

В Java описанный класс может быть представлен так:

public class Microchip { private Long id; private String name; private String frameType; private Double voltage; private Integer price; }

Структурно JSON-файл будет представлять собой упорядоченный набор значений (список), содержащий поля объекта и их значения в формате ключ-значение, который в Java может быть считан и преобразован в объект класса ArrayList, параметризованный вышеописанным классом Microchip.

Пример JSON-файла, содержащего две записи о микросхемах, может быть представлен так:

[ { "id": 1, "name": "microchip1", "frameType": "frame1", "voltage": 1.1, "price": 1111 }, { "id": 2, "name": " microchip2", "frameType": "frame2", "voltage": 2.2, "price": 2222 }

]

Для отправки HTTP-запросов будут использоваться URL-адреса формата «http://{{domain_name}}/api/...», где domain_name – доменное имя, которое при работе на локальном компьютере может иметь значение localhost:8080 (где 8080 может также быть заменено другим незанятым портом). Далее для краткости постоянная часть URL-адреса «http://{{domain_name}}/api» будет заменена обозначением {{hostapi}}.

Таблица 1 – Сформулированные требования

тр.

Наименование

требования

Результат

трассировки

Полнота

Непротиворечивость

Выполнимость

Однозначность

Трассируемость

Проверяемость

Корректность

Бизнес-требования

1.1

Веб-сервис: обеспечивать приём, обработку и передачу данных JSON-файла

2.5, 2.7, 3.1-3.9

+

+

+

+

+

+

+

1.2

Веб-сервис: поддержка HTTP-протокола и использование GET, POST и др. запросов

2.5, 2.7, 3.1-3.9

+

+

+

+

+

+

+

1.3

Веб-сервис: использует разработанную структуру URI всех запросов

3.1-3.9

+

+

+

+

+

+

+

1.4

Клиент: обработка данных и вывод результатов в консоль

2.9, 3.10-3.13

+

+

+

+

+

+

+

1.5

Клиент: формирование и передача веб-сервису HTTP-запросов

2.1-2.4, 3.10-3.19

+

+

+

+

+

+

+

Пользовательские требования

2.1

Клиент: обеспечивает пользователю возможность добавления в JSON-файл новых данных

1.1, 3.14, 3.15

+

+

+

+

+

+

+

2.2

Клиент: обеспечивает пользователю возможность просмотра в консоли данных JSON-файла

1.1, 1.4, 3.10-3.13

+

+

+

+

+

+

+

2.3

Клиент: обеспечивает пользователю возможность частичного удаления данных JSON-файла

1.1, 3.18, 3.19

+

+

+

+

+

+

+

2.4

Клиент: обеспечивает пользователю возможность изменения данных о микросхемах, хранящихся в JSON-файле

1.1, 3.16, 3.17

+

+

+

+

+

+

+

2.5

Веб-сервис: передаёт клиенту упорядоченные по выбранным свойствам объектов (микросхем) или неупорядоченные данные

1.1, 1.4, 3.1-3.4

+

+

+

+

+

+

+

2.6

Клиент: обеспечивает пользователю возможность замены значения корпуса микросхемы в списке и вывод результирующего списка

1.1, 1.4, 3.7

+

+

+

+

+

+

+

2.7

Веб-сервис: определяет (подсчитывает) количество записей о микросхемах с напряжением питания более 5 вольт и передаёт их клиенту

1.1, 1.2, 3.3

+

+

+

+

+

+

+

2.8

Клиент: вывод записей о микросхемах с напряжением питания более 5

1.1, 1.4, 3.12

+

+

+

+

+

+

+

2.9

Клиент: возможность отправки веб-сервису данных с использованием HTTP-протокола их непосредственным вводом в командной строке или с помощью выбора и отправки файла с данными

1.1, 1.5, 3.10-19

+

+

+

+

+

+

+

Функциональные требования

3.1

Веб-сервис: при GET-запросе по адресу {{hostapi }}/?sortBy={fieldname}, где sortBy={fieldname} - параметр запроса, содержащий название поля объекта, по которому требуется произвести сортировку, получает записи из JSON-файла, сортирует и отправляет их клиенту с кодом ответа:

  • 200 (OK), если записи получены успешно;

  • 204 (No content), если список записей пуст;

  • 400 (Bad request), если значение параметра записано неверно.

1.1, 1.2, 1.3, 2.5

+

+

+

+

+

+

+

3.2

Веб-сервис: при GET-запросе {{hostapi}}/ получает неупорядоченные записи из JSON-файла и отправляет их клиенту с кодом ответа:

  • 200 (OK), если записи получены успешно;

  • 204 (No content), если список записей пуст.

1.1, 1.2, 1.3, 2.5

+

+

+

+

+

+

+

3.3

Веб-сервис: при GET-запросе {{hostapi}}/volt?volt={n}, где ?volt={n} - параметр запроса, содержащий значение нижнего порога напряжения микросхемы {n}, по которому требуется произвести фильтрацию, получает неупорядоченные записи из JSON-файла, фильтрует их, подсчитывает количество и отправляет его клиенту с кодом ответа:

  • 200 (OK) – данные получены успешно.

1.1, 1.2, 1.3, 2.7, 2.5

+

+

+

+

+

+

+

3.4

Веб-сервис: при GET-запросе {{hostapi}}/{id}, где {id} - id требуемой записи о микросхеме, получает из JSON-файла неупорядоченные записи, фильтрует их, оставляя одну, у которой id равен введённому, и отправляет её клиенту с кодом ответа:

  • 200 (OK), если записи получены успешно;

  • 404 (Not found), если микросхема с введённым id не найдена.

1.1, 1.2, 1.3, 2.5

+

+

+

+

+

+

+

3.5

Веб-сервис: при POST-запросе {{hostapi}}/ получает от клиента список новых записей, присваивает им идентификаторы, добавляет их в JSON-файл, и передаёт код ответа:

  • 201 (Created) – записи успешно добавлены.

1.1, 1.2, 1.3

+

+

+

+

+

+

+

3.6

Веб-сервис: при PUT-запросе {{hostapi}}/?formerFrameType={a}&newFrameType={b}, где /?formerFrameType ={a}&newFrameType={b} - параметры запроса, содержащие старое {a} и новое {b} название типов корпуса, получает из JSON-файла неупорядоченные записи, фильтрует их по подходящему значению {a} поля frameType, заменяет значение {a} на {b} и отправляет их клиенту вместе с кодом ответа:

  • 200 (OK), если данные в записи заменены успешно;

  • 204 (No content), если список изменённых записей пуст.

1.1, 1.2, 1.3, 2.5, 2.6

+

+

+

+

+

+

+

3.7

Веб-сервис: при DELETE-запросе {{hostapi}}/{id}, где {id} - id требуемой записи о микросхеме, получает из файла JSON неупорядоченные записи, фильтрует их, оставляя одну, у которой id равен введённому, удаляет её и отправляет клиенту код ответа:

  • 204 (No content), если микросхема удалена.

  • 404 (Not found), если микросхема с введённым id не найдена.

1.1, 1.2, 1.3

+

+

+

+

+

+

+

3.8

Клиент: для получения всех записей в неупорядоченном виде пользователь запускает jar-файл с параметром запуска “-get_all”, пропускает ввод поля для сортировки, и клиент отправляет веб-сервису GET-запрос по адресу {{hostapi}}/ для получения записей о микросхемах от веб-сервиса, затем получает их и выводит в консоль.

Если список записей пуст, клиент уведомляет об этом.

1.4, 1.5, 2.2

+

+

+

+

+

+

+

3.9

Клиент: для получения всех записей в упорядоченном виде пользователь запускает jar-файл с параметром запуска “-get_all”, вводит поле для сортировки, и клиент отправляет веб-сервису GET-запрос по адресу {{hostapi }}/?sortBy={fieldname} для получения упорядоченных (по названию, по типу корпуса, по напряжению или по цене) записей о микросхемах от веб-сервиса, получает их и выводит в консоль.

Если список записей пуст или поле для сортировки введено некорректно, клиент уведомляет об этом.

1.4, 1.5, 2.2

+

+

+

+

+

+

+

3.10

Клиент: для получения количества записей о микросхемах с нужным напряжением пользователь запускает jar-файл с параметром запуска “-get_volt”, если требуется, то вводит нижний порог значения напряжения, и клиент отправляет GET-запросу веб-сервису по адресу {{hostapi}}/volt?volt={n} для получения количества записей о микросхемах с напряжением питания не менее {n} вольт (по умолчанию равно 5В, иначе равно введённому пользователем значению), получает его и выводит в консоль.

Если полученное число равно 0, клиент уведомляет о том, что следует проверить корректность введённого значения нижнего порога.

1.4, 1.5, 2.2, 2.8

+

+

+

+

+

+

+

3.11

Клиент: для получения записи по id пользователь запускает jar-файл с параметром запуска “-get_id”, вводит нужное значение id, и клиент отправляет GET-запрос веб-сервису по адресу {{hostapi}}/{id} для получения записи о конкретной микросхеме по значению поля id. После получения клиент выводит её в консоль.

Если запись о микросхеме с введённым id не найдена, клиент уведомляет о том, что следует проверить корректность введённого id.

1.4, 1.5, 2.2

+

+

+

+

+

+

+

3.12

Клиент: для добавления в список записей веб-сервиса новой с помощью консоли пользователь запускает jar-файл с параметром запуска “-post_cmd”, вводит значения полей name, frameType, voltage, price, и клиент формирует объект класса Microchip с помощью конструктора с введёнными значениями, отправляет его веб-сервису в POST-запросе по адресу {{hostapi}}/ для добавления веб-сервисом в имеющийся список новой записи о микросхеме.

1.5, 2.1, 2.9

+

+

+

+

+

+

+

3.13

Клиент: для добавления в список записей новых с помощью внешнего файла пользователь запускает jar-файл с параметром запуска “-post_file”, вводит адрес json-файла со списком записей о микросхемах, и клиент считывает из файла данные, формирует из них список объектов класса Microchip и отправляет его веб-сервису в POST-запросе по адресу {{hostapi}}/ для добавления веб-сервисом в имеющийся список новых записей о микросхемах.

1.5, 2.1, 2.9

+

+

+

+

+

+

+

3.14

Клиент: для изменения типа корпуса в имеющемся списке записей пользователь запускает jar-файл с параметром запуска “-put_ft”, вводит текущее и новое (заменяющее) название типа корпуса, и клиент отправляет PUT-запрос с этими названиями типа корпуса веб-сервису по адресу {{hostapi}}/?formerFrameType={a}&newFrameType={b}, получает от веб-сервиса список изменённых записей и выводит их в консоль.

Если список изменённых записей пуст, клиент уведомляет о том, что следует проверить корректность введённого названия типа корпуса.

1.4, 1.5, 2.2, 2.4, 2.6

+

+

+

+

+

+

+

3.15

Клиент: для удаления записи по id пользователь запускает jar-файл с параметром запуска “-del_id”, вводит нужное значение id, клиент отправляет DELETE-запрос по адресу {{hostapi}}/{id} для удаления веб-сервисом записи с введённым id, а затем, выводит сообщение о том, что запись успешно удалена.

Если запись о микросхеме с введённым id не найдена, клиент уведомляет о том, что следует проверить корректность введённого id.

1.5, 2.3

+

+

+

+

+

+

+

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

Соседние файлы в предмете Тестирование программного обеспечения