Министерство науки и высшего образования РФ

Федеральное государственное бюджетное образовательное

учреждение высшего образования

«Уфимский государственный авиационный технический университет»

Факультет информатики и робототехники

Кафедра вычислительной математики и кибернетики

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

Поиск и документирование дефектов

по дисциплине

«Технология разработки программного обеспечения»

Выполнили:

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

Шакиров А. Р.

Проверил:

старший преподаватель

Тугузбаев Гаяз Ахтямович

Уфа 2020

Оглавление

Теоретические сведения 3

1. Описание дефектов 4

2. Ответы на контрольные вопросы 6

Вывод 7

Приложение А 8

Цель:

Протестировать мобильное приложение и описать найденные дефекты.

Задачи:

1. Изучить теоретические сведения.

2. Выполнить практическое задание по лабораторной работе.

3. Оформить отчёт и ответить на контрольные вопросы.

Теоретические сведения

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

Описание каждого дефекта сохраняется в специализированной – багтрэкинговой – системе (например, JIRA, Bugzilla, Mantis, Redmine и др.) или в предварительно созданном в программной среде Microsoft Excel файле.

Описание дефекта включает следующие обязательные поля:

1. Headline – название дефекта.

2. Severity – степень критичности (важность дефекта).

3. Description – алгоритм воспроизведения.

4. Result – фактический результат.

5. Expected result – ожидаемый результат.

6. Attachment – прикреплённые файлы (приложение).

В багтрэкинговых системах для каждого дефекта автоматически генерируется его уникальный номер, в случае использования Microsoft Excel номер дефекту необходимо присваивать вручную.

Требование спецификации, которое нарушает обнаруженный дефект, можно дополнительно вынести в примечание.

Дополнительно в описании дефекта может быть указана Priority – степень срочности исправления дефекта разработчиком.

1. Описание дефектов

Acceptance Sheet – документ, который содержит подробный перечень всех модулей и функций приложения, а также результаты всех тестов данных функций. Как правило, содержит статистику по наиболее важным показателям каждой сборки, определяющим ее качество.

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

При составлении тестовой документации Acceptance Sheet мобильного приложения «Импорт расписания УГАТУ» в процессе проведения тестовых проверок были выявлены дефекты, представленные на рисунке 1.1, их описания, приведенные в таблице 1.1.

Рис.1.1. Acceptance Sheet

Таблица 1.1

Описание дефектов

№	Название дефекта	Важность	Алгоритм воспроизведения	Фактический результат	Ожидаемый результат	Приложение
1	Главный экран: Строка поиска: Отсутствие интернациионализации заглушки строки поиска	Minor	Шаги по воспроизведению: 1. В настройках ОС выбрать язык отличный от русского. 2. Открыть приложение.	Заглушка строки поиска отображается на русском языке.	Заглушка строки поиска отображается на текущем языке системы или на английском языке.	Рисунок А.1
2	Главный экран: Кнопки под списком «Учебные группы»: Отсутствие интернациионализации заголовка кнопок «Импорт» и «Очистить календарь»	Minor	Шаги по воспроизведению: 1. В настройках ОС выбрать язык отличный от русского. 2. Открыть приложение.	Заголовок кнопки отображается на русском языке.	Заголовок кнопки отображается на текущем языке системы или на английском языке.	Рисунок А.1
3	Главный экран: Всплывающее уведомление: Отсутствие интернациионализации текста уведомления	Minor	Шаги по воспроизведению: 1. В настройках ОС выбрать язык отличный от русского. 2. Открыть приложение. 3. Нажать кнопку «Импорт». 4. Дождаться завершения операции.	Текст уведомления отображается на русском языке.	Текст уведомления отображается на текущем языке системы или на английском языке.	Рисунок А.2

2. Ответы на контрольные вопросы

   1. Шакиров Айдар

Ответ на вопрос №5 «Что такое Severity в описании дефекта?»:

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

Таблица 2.1.1

Степени критичности дефектов

№	Severity	Описание	Примеры
1	Critical (критический)	Функциональная ошибка, которая блокирует работу части функционала или всего приложения. Функциональная ошибка, которая нарушает ключевую (с точки зрения конечного пользователя или бизнеса заказчика) функциональность приложения	Заблокирована вкладка (категория меню). Неправильно подсчитывается итоговая сумма при вводе скидочного промокода. Раскрывается конфиденциальная информация.
2	Major (значительный)	Функциональная ошибка, которая нарушает нормальную работу приложения, но не блокирует работу части функционала в целом.	Невозможно загрузить видеофайлы на персональной страничке. Необходимо перезапускать приложение при выполнении типичных сценариев работы.
3	Average (средней значимости)	Не очень важная функциональная ошибка. Критичные дефекты GUI.	Не работает сортировка. «Уехал» текст за пределы окна.
4	Minor (незначительный)	Редко встречающиеся незначительные функциональные дефекты. 90 % дефектов GUI.	Введены необязательные для заполнения поля, которых нет в спецификации. Грамматические, пунктуационные ошибки.
5	Enhancement (предложение по улучшению)	Функциональные предложения, советы по улучшению дизайна (оформления), навигации и др. Такой дефект является необязательным для исправления.	Добавить кнопку «Наверх» на длинных формах. Увеличить размер шрифта.

Вывод

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

Приложение А

Рисунок А.1. Отсутствие интернационализации элементов GUI

Рисунок А.2. Отсутствие интернационализации текста всплывающего уведомления о результате операции