ТРПО_05_Шакиров_МО-317
.docxМинистерство науки и высшего образования РФ
Федеральное государственное бюджетное образовательное
учреждение высшего образования
«Уфимский государственный авиационный технический университет»
Факультет информатики и робототехники
Кафедра вычислительной математики и кибернетики
Отчет по лабораторной работе №5
Поиск и документирование дефектов
по дисциплине
«Технология разработки программного обеспечения»
Выполнили:
студент группы МО-317
Шакиров А. Р.
Проверил:
старший преподаватель
Тугузбаев Гаяз Ахтямович
Уфа 2020
Оглавление
Теоретические сведения 3
1. Описание дефектов 4
2. Ответы на контрольные вопросы 6
Вывод 7
Приложение А 8
Цель:
Протестировать мобильное приложение и описать найденные дефекты.
Задачи:
Изучить теоретические сведения.
Выполнить практическое задание по лабораторной работе.
Оформить отчёт и ответить на контрольные вопросы.
Теоретические сведения
Дефекты, обнаруженные тестировщиком, должны быть корректно и понятно описаны, чтобы разработчик смог воспроизвести данный дефект и устранить его.
Описание каждого дефекта сохраняется в специализированной – багтрэкинговой – системе (например, JIRA, Bugzilla, Mantis, Redmine и др.) или в предварительно созданном в программной среде Microsoft Excel файле.
Описание дефекта включает следующие обязательные поля:
Headline – название дефекта.
Severity – степень критичности (важность дефекта).
Description – алгоритм воспроизведения.
Result – фактический результат.
Expected result – ожидаемый результат.
Attachment – прикреплённые файлы (приложение).
В багтрэкинговых системах для каждого дефекта автоматически генерируется его уникальный номер, в случае использования Microsoft Excel номер дефекту необходимо присваивать вручную.
Требование спецификации, которое нарушает обнаруженный дефект, можно дополнительно вынести в примечание.
Дополнительно в описании дефекта может быть указана Priority – степень срочности исправления дефекта разработчиком.
Описание дефектов
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 |
Ответы на контрольные вопросы
Шакиров Айдар
Ответ на вопрос №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. Отсутствие интернационализации текста всплывающего уведомления о результате операции