
- •Содержание
- •Анализ требований
- •1.1 Бизнес требования
- •Системные требования
- •1.2.1 Описание системных требований
- •1.2.2 Блок-схемы алгоритма решения задачи
- •1.2.3 Структурная схема
- •1.2.4 Схема механических элементов
- •1.2.5 Принципиальная схема электрическая
- •2.3 Разработка пользовательского приложения Задание
- •Реализация визуальной составляющей программы с указанием программного кода
- •2.3.1 Реализация окна авторизации
- •2.3.2 Реализация окна управления разгрузкой
- •2.3.3 Реализация окна измерения веса
- •2.3.4 Реализация окна управления разгрузкой сырья
- •Заключение по разделу 2.3
- •3 Контроль качества
- •3.1 План тестирования
- •3.2 Функциональное тестирование автомобилеразгрузчика
- •3.3 Системное тестирование
- •3.4 Регрессионное тестирование
- •3.5 Смоук-тестирование и приемочное тестирование или Приемо-сдаточное испытание (пси)
2.3 Разработка пользовательского приложения Задание
Исходя из выбранной ранее элементной базы, дизайна пользовательского интерфейса, и с учетом разработанной прошивки, необходимо спроектировать и разработать взаимодействие платформы с управляющим устройством по каналу связи (по USB или WIFI).
Реализация визуальной составляющей программы с указанием программного кода
Листинг программного кода представлен в приложении Е.
2.3.1 Реализация окна авторизации
С учетом разработанного ранее дизайна интерфейса, при помощи фреймворка Flutter были созданы оконные интерфейсы программы для взаимодействия пользовательского устройства с платформой. Окно авторизации выглядит следующим образом, представленным на рисунке 2.3.1.1.
Рисунок 2.3.1.1 – Окно авторизации программы.
Программный код для реализации вышеуказанного окна представлен в приложении Е.1 – Е4.
2.3.2 Реализация окна управления разгрузкой
После прохождения авторизации, пользователь попадает на экран управления разгрузкой, представленный на рисунке 2.3.2.1.
Рисунок 2.3.2.1 – Экран управления разгрузкой.
Программный код экрана управления разгрузкой представлен в приложении Е.5 – Е.8.
2.3.3 Реализация окна измерения веса
Из экрана управления разгрузкой пользователь может либо произвести замер веса, либо произвести разгрузку при помощи платформы. Оконный интерфейс при выборе функции измерения веса представлен на рисунке 2.3.3.1.
Рисунок 2.3.3.1 – Оконный интерфейс измерения веса.
Программный код формы опции измерения веса представлен в приложении Е.9 – Е.14.
2.3.4 Реализация окна управления разгрузкой сырья
В том случае, если пользователю необходимо произвести разгрузку сырья, при нажатии соответствующей кнопки он попадает в окно управления разгрузкой, представленное на рисунке 2.3.4.1.
Рисунок 2.3.4.1 – Окно управления разгрузкой сырья.
Программный код указанного выше окна представлен в приложении Е.15 – Е.33.
Заключение по разделу 2.3
Таким образом, при помощи созданного приложения на базе фреймворка Flutter, пользователь может осуществлять взаимодействие с спроектированной платформой для измерения веса либо произведения разгрузки сырья посредством USB соединения.
3 Контроль качества
3.1 План тестирования
Тестирование программного обеспечения – это необходимый процесс в ходе разработки, во время которого выявляются все проблемы в работе ПО. Процесс разработки не может быть полностью реализован без этапа тестирования. Ни один разработчик не может быть застрахован от появления ошибок в его коде. Тестирование бывает разных видов: автоматическое и ручное, функциональное и нефункциональное, с доступом к исходному коду и без него. В любом случае важно придерживаться определенных правил, чтобы продукт был проверен от и до.
Системное тестирование — это вид тестирования программного обеспечения, который выполняет проверку системы в целом. Оно включает в себя интеграцию всех отдельных модулей и компонентов разработанного программного обеспечения, чтобы проверить, работает ли система полноценно, как ожидалось.
Функциональное тестирование ПО - функциональное тестирование проводится для определения, насколько компонент или система соответствуют заданным функциональным требованиям, описанным в спецификациях. Данный вид тестирования может проводиться на всех уровнях тестирования: компонентом, интеграционном, системном и приемочном, т.е. на всех этапах разработки программного обеспечения.
Регрессионное тестирование — это проверка ранее протестированной программы, позволяющая убедиться, что внесенные изменения не повлекли за собой появления дефектов в той части программы, которая не менялась. Данный вид тестирования применяется после правки багов на стороне разработки.
Функциональное тестирование модели - функциональное тестирование модели проводится для проверки корректной реализации физических составляющих модели, описанных в требованиях и спецификациях.
Smoke-тестирование — проверка программного обеспечения на стабильность и наличие явных ошибок. Тест должен подтвердить или опровергнуть правильность выполнения ПО своих основных функций перед его передачей на более глубокое тестирование.
Данная работа содержит именно эти виды тестирования, так как:
Системное тестирование - необходимо для проверки функционирования ПО и модели друг с другом
Функциональное тестирование ПО - для проверки программного обеспечения отдельно от модели
Регрессионное тестирование - для проведения полного цикла проверок перед релизом
Функциональное тестирование модели - для проверки работоспособности модели отдельно от ПО
Smoke-тестирование - для проверки минимально-необходимого функционала перед релизом или приемо-сдаточным испытанием
Для корректной работы нашей программы необходимо протестировать в соответствии с заданными требованиями. Первым шагом тестирования платформы является составление карты тестирования. Карта тестирования для платформы представлена на рисунке 3.1.1.
Рисунок 3.1.1 – Карта тестирования
Вид тестирования |
Планируемые работы |
|
1. Описание тестовых сценариев полного функционала ПО; 2. Прохождение тестовых сценариев на версии ПО; 3. Фиксация деффектов ПО; 4. Повторная проверка исправленных деффектов. |
|
1. Описание тестовых сценариев полного функционала грузовой платформы; 2. Прохождение тестовых сценариев на готовой грузовой платформе; 3. Фиксация деффектов грузовой платформы; 4. Повторная проверка исправленных деффектов. |
|
1. Описание тестовых сценариев взаимодействия грузовой платформы и ПО; 2. Прохождение тестовых сценариев на готовой грузовой платформе и версии ПО; 3. Фиксация деффектов взаимодействия ПО и платформы; 4. Повторная проверка исправленных деффектов. |
|
1. Прохождение тестовых сценариев функционального тестирования ПО, тестирования платформы и интеграционного тестирования; 2. Прохождение тестовых сценариев на готовой грузовой платформе и версии ПО; 3. Фиксация деффектов взаимодействия ПО и платформы; 4. Повторная проверка исправленных деффектов. |
|
1. Составление набора тестовых сценариев для определения основного функционала платформы и ПО; 2. Проведение приемо-сдаточных испытаний по составленному набору тестовых сценариев |
Жизненный цикл дефекта
Тестирование подразумевает под собой поиск ошибок и неточностей системы. После нахождения того или иного дефекта, он проходит различные стадии - жизненный цикл. Жизненный цикл дефекта – это стадии, которые проходит ошибка с начала своего существования и до ее полного разрешения. Чтобы было проще воспринимать, жизненный цикл рисуют схематично, где отображаются все статусы и действия, которые эти статусы и сменяют. На рисунке 3.1.2 представлен жизненный цикл ошибок в методологии нашего проекта.
Рисунок 3.1.2 – Жизненный цикл
Функциональное тестирование ПО
Тестовые сценарии функционального тестирования ПО:
№1 |
|
Вид тестирования: функциональное тестирование ПО |
|
Авторизация |
|
Предусловие: открыта страница авторизации |
|
Сценарий: |
Ожидаемый результат: |
|
Кнопка “присоединиться” стала активной |
|
Открывается главная страница |
№2 |
|
Вид тестирования: тестирование валидации |
|
Поле ID |
|
Предусловие: открыта страница авторизации |
|
Входные данные:
|
|
Сценарий: |
Ожидаемый результат: |
|
Кнопка “присоединиться” неактивна Появляется сообщение “Введите корректный ID” |
№3 |
|
Вид тестирования: функциональное тестирование |
|
Переход по страницам |
|
Предусловие: пользователь авторизован в системе и находится на главной странице |
|
Входные данные:
|
|
Сценарий: |
Ожидаемый результат: |
|
|
№4 |
|
Вид тестирования: функциональное тестирование ПО |
|
Измерение веса |
|
Предусловие: пользователь авторизован в системе и находится на главной странице |
|
Сценарий: |
Ожидаемый результат: |
|
Открылась страница для измерения веса |
|
В поле значения измеренного веса отображается вес груза |
№5 |
|
Вид тестирования: тестирование валидации |
|
Чек-боксы группы “Разгрузочный борт” |
|
Предусловие: пользователь авторизован в системе Измерен вес груза на платформе (вес находится в пределах допустимого) открыта страница разгрузки сырья |
|
Сценарий: |
Ожидаемый результат: |
|
Отмечен произвольный чек-бокс из группы чек-боксов “Разгрузочный борт” Второй чек-бокс не выбран |
|
Чек-бокс отмечен, как выбранный Отметка на чек-боксе из шага 1 пропадает Выбрать два чек-бокса одновременно невозможно |
№6 |
|
Вид тестирования: тестирование валидации |
|
Чек-боксы группы “Угол наклона” |
|
Предусловие: пользователь авторизован в системе Измерен вес груза на платформе (вес находится в пределах допустимого) открыта страница разгрузки сырья |
|
Сценарий: |
Ожидаемый результат: |
|
Отмечен произвольный чек-бокс из группы чек-боксов “Разгрузочный борт” Остальные чек-боксы не выбраны |
|
Чек-бокс отмечен, как выбранный Отметка на чек-боксе из шага 1 пропадает Выбрать два и более чек-бокса одновременно невозможно |
Описание найденных багов:
№1 |
|
При нажатии кнопки “Измерить вес” открывается страница разгрузки сырья |
|
Приоритет |
Высокий |
Предусловие: пользователь авторизован в системе и находится на главной странице |
|
Сценарий: |
Ожидаемый результат: |
|
Открылась страница для измерения веса |
|
Фактический результат: |
|
Открылась страница разгрузки сырья |
№2 |
|
При вводе некорректного ID отсутствует сообщение “Введите корректный ID” |
|
Приоритет |
Средний |
Предусловие: пользователь находится на странице авторизации |
|
Сценарий: |
Ожидаемый результат: |
|
Появляется сообщение “Введите корректный ID” |
|
Фактический результат: |
|
Сообщение не появляется |
На рисунке 3.1.3 представлен отчет по проведению функционального тестирования ПО в системе Allure Report.
Рисунок 3.1.3 – Отчёт функц. Тест.