Файл: Отчет по лабораторной работе 9 Поиск и документирование дефектов.docx
Добавлен: 22.11.2023
Просмотров: 64
Скачиваний: 5
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
ФГБОУ ВО «Уфимский университет науки и технологий»
Отчет по лабораторной работе №9
«Поиск и документирование дефектов».
по дисциплине «Технология разработки программного обеспечения».
Выполнили:
Авдеев Егор, МО-223Б
Искандаров Искандер, МО-223Б
Проверила:
Давлиева А.С.
Уфа 2023
Цель работы: протестировать web-приложение и описать найденные дефекты.
Ход работы:
№ | Название дефекта | Важность | Алгоритм воспроизведения | Фактический результат | Ожидаемый результат | Приложение |
1 | Страница регистрации. Поле «Телефон». Не принимает русский номер телефона (санкции). | Average |
| После ввода номера телефона перебрасывает на ошибку «OpenAI's services are not available in your country.» | Завершение регистрации и переход в ЛК. | Рис.1 |
2 | Страница регистрации. Блокирует русский IP-адрес. | Average |
| После ввода пароля сайт автоматически перебрасывает на ошибку «OpenAI's services are not available in your country.» | Переход на ввод номера телефона. | Рис.1 |
3. | Главная страница openai.com. Страница входа в аккаунт. | Minor |
| После нажатия на кнопку перебрасывает на ошибку. | Переход на окно авторизации. | Рис.2 |
4. | chat.openai.com. Кнопка «+ New Chat» | Minor |
| Кнопка не работает, если не написать чат-боту какое-либо сообщение. | Кнопка создаёт новый чат в колонке. | Рис. 3 |
5. | chat.openai.com. Кнопка «Log Out» | Minor |
| После нажатия кнопки перекидывает на страницу с ошибкой. | Переход на страницу авторизации. | Рис.2 |
Рисунок 1
Рисунок 2
Рисунок 3
Вывод: в ходе лабораторной работы нами было протестировано веб приложение, получены навыки описания дефектов.
Контрольные вопросы:
1. Что такое дефект?
Любое отклонение изготовленной продукции от требований, установленных нормативно-технической документацией.
2. Какие характеристики необходимо указать при описании дефекта?
Описание дефекта включает следующие обязательные поля:
1. Headline – название дефекта.
2. Severity – степень критичности (важность дефекта).
3. Description – алгоритм воспроизведения.
4. Result – фактический результат.
5. Expected result – ожидаемый результат.
6. Attachment – прикреплённые файлы (приложение).
3. Что такое Headline/Summary в описании дефекта?
Цель составления заголовка дефекта – предоставить краткую и в тоже время понятную информацию о том, где, что и в результате чего произошло. Характеристиками качественного заголовка являются краткость, информативность, точная идентификация проблемы.
4. На какие три вопроса должен отвечать Headline/Summary?
Заголовок дефекта должен отвечать на три вопроса:
1. Где? В каком месте интерфейса пользователя находится проблема.
2. Что? Что происходит или не происходит согласно спецификации или представлению о нормальной работе программного продукта.
3. Когда (при каких условиях)? В какой момент работы программы или по наступлению какого события проблема проявляется.
5. Что такое Severity в описании дефекта?
Степень критичности (серьезности, важности) показывает степень ущерба, который наносится проекту существованием дефекта.
6. Какие существуют степени Severity? Приведите примеры.
Critical (критический). Пример - неправильный подсчет итоговой суммы при вводе промокода.
Major (значительный). Пример - не работает система e-mail нотификации.
Average (средней значимости). Пример - «уехал» текст за пределы окна, не работает сортировка.
Minor (незначительный). Введены необязательные для заполнения поля, которых нет в спецификации. Грамматические, пунктуационные ошибки..
Enhancement (предложение по улучшению).Добавить кнопку «Наверх» на длинных формах. Увеличить размер шрифта.
7. Что такое Description в описании дефекта?
Description – это четкий алгоритм, в котором приветствуются короткие, понятные фразы и нумерация.
8. Что такое Expected result в описании дефекта?
Expected result (ожидаемый результат). Цель написания Expected result – привести аргументы разработчикам, как именно должно работать приложение. В Expected result должно быть четкое обоснование, почему именно так должно работать приложение.
9. Зачем нужен Attachment при описании дефекта?
Attachment – это прикрепленный к дефекту файл, дополняющий описание: скриншот, файлы, необходимые для воспроизведения дефекта, логи программы, видео ошибки и т.д. Attachment является 6 вспомогательным средством передачи информации о проблеме. Для всех GUI дефектов attachment обязателен.
10. Какие существуют рекомендации по описанию дефектов?
1. Шаги воспроизведения, фактический и ожидаемый результаты должны быть подробно описаны.
2. Дефект должен быть понятно описан (с использованием общеупотребимой лексики, точных названий программных средств).
3. Необходимо давать ссылку на соответствующее требование, к нарушению которого приводит фактический результат работы программного средства.
4. Если существует какая-либо информация, которая поможет быстрее обнаружить или исправить дефект, необходимо сообщить эту информацию.
5. Окружение (ОС, браузер, настройки и т.п.), под которым возникла ошибка, должно быть четко указано.
6. Создавать дефект и описывать его необходимо сразу же, как только он был обнаружен. Откладывание «на потом» приводит к риску забыть о дефекте или и каких-либо деталях его воспроизведения. Несвоевременное создание дефекта не позволяет проектной команде реагировать на ее обнаружение в реальном времени.
7. После описания дефекта необходимо еще раз перечитать его: убедится, что все необходимые поля заполнены, и все написано верно.