практика. Практическое занятие № 19-20. Практическое занятие 1920 Тема. Отладка и тестирование программного обеспечения
 Скачать 324.99 Kb.
|
|
МДК 01.02 Практическое занятие № 19-20 Тема. Отладка и тестирование программного обеспечения Наименование работы: Системное тестирование. Функциональное тестирование. Цель. Изучить процессы тестирования и отладки программного обеспечения. Приобретаемые умения и навыки: в процессе выполнения заданий в соответствии с инструкционной картой студенты приобретают навыки работы тестирования программного обеспечения и выявление ошибок Норма времени: 2 часа Оснащение рабочего места: ПК, программное обеспечение, методические указания. Особые правила техники безопасности на рабочем месте: проведение вводного инструктажа по ТБ и инструктажа на рабочем месте. Литература: Основные источники 1. Гагарина, Л. Г. Технология разработки программного обеспечения: учебное пособие / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. Сидорова-Виснадул; под ред. Л.Г. Гагариной. — Москва: ФОРУМ : ИНФРА-М, 2021. — 400 с. — (Среднее профессиональное образование). - ISBN 978-5-8199-0812-9. - Текст: электронный. - URL: https://znanium.com/catalog/product/1189951 (дата обращения: 27.05.2021). 2. Маркин, А. В. Программирование на SQL: учебное пособие для среднего профессионального образования / А. В. Маркин. — Москва: Издательство Юрайт, 2021. — 435 с. — (Профессиональное образование). — ISBN 978-5-534-11093-7. — Текст: электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/476040 (дата обращения: 27.05.2021). 3. Немцова, Т. И. Программирование на языке высокого уровня. Программирование на языке Object Pascal: учеб. пособие / Т.И. Немцова, С.Ю. Голова, И.В. Абрамова; под ред. Л.Г. Гагариной. — Москва: ИД «ФОРУМ»: ИНФРА-М, 2018. — 496 с. + Доп. материалы [Электронный ресурс; Режим доступа: https://new.znanium.com]. — (Профессиональное образование). - ISBN 978-5-8199-0753-5. - Текст: электронный. - URL: https://znanium.com/catalog/product/944326 (дата обращения: 27.05.2021). 5. Соколова, В. В. Разработка мобильных приложений: учебное пособие для среднего профессионального образования / В. В. Соколова. — Москва: Издательство Юрайт, 2021. — 175 с. — (Профессиональное образование). — ISBN 978-5-534-10680-0. — Текст:электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/475892 (дата обращения: 27.05.2021). Дополнительные источники 1. Голицына, О. Л. Языки программирования: учебное пособие / О.Л. Голицына, Т.Л. Партыка, И.И. Попов. — 3-е изд., перераб. и доп. — Москва: ФОРУМ: ИНФРА-М, 2021. - 399 с. - (Среднее профессиональное образование). - ISBN 978-5-00091-613-1. - Текст: электронный. - URL: https://znanium.com/catalog/product/1209231 (дата обращения: 27.05.2021). 2. Гуров, В. В. Микропроцессорные системы: учебник / В.В. Гуров. — Москва: ИНФРА-М, 2021. — 336 с. + Доп. материалы [Электронный ресурс]. — (Среднее профессиональное образование). - ISBN 978-5-16-015323-0. - Текст: электронный. - URL: https://znanium.com/catalog/product/1514901 (дата обращения: 27.05.2021). 4. Хорев, П. Б. Объектно-ориентированное программирование с примерами на С#: учебное пособие / П.Б. Хорев. — Москва: ФОРУМ: ИНФРА-М, 2021. — 200 с. — (Среднее профессиональное образование). - ISBN 978-5-00091-713-8. - Текст: электронный. - URL: https://znanium.com/catalog/product/1195623 (дата обращения: 27.05.2021). 5. Чернышев, С. А. Основы программирования на Python: учебное пособие для среднего профессионального образования / С. А. Чернышев. — Москва: Издательство Юрайт, 2021. — 286 с. — (Профессиональное образование). — ISBN 978-5-534-15160-2. — Текст: электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/487638 (дата обращения: 27.05.2021). Интернет-ресурсы 1. Электронная библиотечная система Znanium: сайт.- URL: https://znanium.com/ – Текст: электронный. 2. Электронная библиотечная система Юрайт: сайт. - URL: https://urait.ru/ -Текс: электронный. Ход работы Контрольные вопросы 1. Какие методы тестирования вы знаете? 2. В чем заключаются методы «черного» и «белого» ящика? 3. Что такое тест-кейс? 4. Что такое баг-репорт? Сегодня тестирование – это обязательная часть процесса разработки программного обеспечения (далее – ПО). Это связано с жесткими правилами конкуренции для компаний, производящих программные продукты (ПП). Раньше таких компаний на рынке было мало и пользователи программных продуктов были продвинутыми и заменяли тестеров. Если в программе обнаруживались баги, то пользователь звонил или отправлял письмо в компанию, где ошибку исправляли и по почте отправляли дискетку со свежим релизом. Но начиная с 1990 года согласно статистики продажи персональных компьютеров с каждым годом удваивались. И появилась армия пользователей, которая не готова была что-то тестировать. Если что-то не устроило было проще обменять на другой софт, т.к. число компаний производящих ПО тоже увеличивалось с каждых готом. И у пользователей появился выбор что покупать и чем пользоваться. Таким образом, тестирование ушло внутрь компаний, и появилась профессия тестировщика. Рассмотрим определение, которое записано в SWEBOK. Тестирование ПО – это проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]. Все виды тестирования можно условно разделить на две большие группы: Статическое тестирование (static testing). Динамическое тестирование (dynamic testing). Статическое тестирование – это процесс анализа самой разработки программного обеспечения, т. е. тестирование без запуска программы. К данной группе можно отнести анализ кода. Данный вид тестирования осуществляется в основном программистами. Проводят тестирование артефактов разработки программного обеспечения, таких как требования, дизайн или программный код, проводимое без исполнения этих артефактов. Например, с помощью рецензирования или статического анализа. Статический анализ кода (static code analysis) – это анализ исходного кода, производимый без его исполнения. Динамическое тестирование – это тестовая деятельность, предусматривающая эксплуатацию (запуск) программного продукта. Динамическое тестирование предполагает запуск программы, выполнение всех еe функциональных модулей и сравнение фактического ее поведения с ожидаемым. Статическое тестирование позволяет обнаружить дефекты, которые являются результатом ошибки и привести к сбоям в программном обеспечении. Динамическое тестирование позволяет продемонстрировать непосредственно сбои в программном обеспечении. Существует несколько признаков, по которым принято производить классификацию видов тестирования. По знанию системы выделяют: тестирование «черного ящика» (black box testing); тестирование «белого ящика» (white box testing); тестирование «серого ящика» (grey box testing). Метод чёрного ящика (black box testing, closed box testing) – у тестировщика либо нет доступа к внутренней структуре и коду приложения, либо недостаточно знаний для их понимания, либо он сознательно не обращается к ним в процессе тестирования. Разработка тестов методом черного ящика (black box test design technique) Процедура создания и/или выбора тестовых сценариев, основанная на анализе функциональной или нефункциональной спецификации компонента или системы без знания внутренней структуры. Техники разработки тестов на основе спецификаций, или методе черного ящика: эквивалентное разбиение; анализ граничных значений; тестирование таблицы решений; Эквивалентное разбиение (equivalence partitioning) Разработка тестов методом черного ящика, в которой тестовые сценарии создаются для проверки элементов эквивалентной области. Как правило, тестовые сценарии разрабатываются для покрытия каждой области как минимум один раз. Входные данные для программного обеспечения или системы разбиваются на группы, от которых ожидается сходное поведение, то есть они должны обрабатываться аналогичным образом. Эквивалентные области (или классы) могут быть определены как для валидных, так и для невалидных данных, то есть тех значений, которые должны отвергаться. Эквивалентное разбиение применимо на всех уровнях тестирования. Эквивалентное разбиение может быть использовано с целью покрытия входных и выходных данных. Оно может применяться при ручном вводе данных, при передаче данных через интерфейсы в систему, или при проверке параметров интерфейсов в интеграционном тестировании. Анализ граничных значений (boundary value analysis): Разработка тестов методом черного ящика, при котором тестовые сценарии проектируются на основании граничных значений. Граничное значение (boundary value): Входное значение или выходные данные, которое находится на грани эквивалентной области или на наименьшем расстоянии от обеих сторон грани, например, минимальное или максимальное значение области. Анализ граничных значений может применяться на всех уровнях тестирования Таблица решений (decision table): Таблица, отражающая комбинации входных данных и/или причин с соответствующими выходными данными и/или действиям (следствиям), которая может быть использована для проектирования тестовых сценариев. Таблицы решений – хороший метод для сбора системных требований, содержащих логические условия и документирования внутреннего дизайна системы. Они могут использоваться для записи сложных бизнес-правил, которые должна реализовывать система. Анализируются спецификации и определяются условия и действия системы. Входные условия и действия чаще всего формулируются таким образом, чтобы они могли принимать логические значения «истина» или «ложь». Сильной стороной тестирования таблицы решений является то, что она создает комбинации условий, которые могли бы быть не проверены в ходе тестирования иным способом. Этот метод может быть применен ко всем ситуациям, в которых действие программного продукта зависит от нескольких логических альтернатив. Тест-кейс Тест-кейс можно сравнить с рецептом — это последовательность шагов, которые приводят к какому-то результату. Тест-кейс лучше не делать избыточным. Тестировщики чаще всего хорошо знают свой проект, поэтому досконально писать тест-кейс нет необходимости. Тест-кейс должен быть краткий и понятный, так чтобы другой тестировщик, либо другой специалист в команде смог быстро пройти по нему и проверить, что все происходит так, как нужно. Тест-кейсы можно формировать в последовательный сценарий, чтобы проверить, как игрок пройдет по этому функционалу от начала до конца. Тест-кейсы можно группировать в смысловые блоки. Например, если в игре запускается какой-то ивент, формируется набор тест-кейсов для проверки этого ивента. Тест-кейсы лучше писать по требованиям гейм-дизайнерского документа. Но, если функционал уже готов, а требований тест-кейсов по нему не написано, можно написать уже по факту. Лишним не будет. Составляющие тест-кейса: идентификатор (уникальный номер, по которому вы сможете найти этот тест-кейс и на него сослаться); название сценария (какое-то краткое, но ёмкое); ссылка на требования ГДД; предусловия (опционально, если они требуются для тест-кейса); шаги сценария; ожидаемый результат; фактический результат (опционально). Чек-лист Чек-листы можно сравнить со списком покупок, который мы формируем на проверку. Например, чек-лист на Smoke-тест, чтобы проверить, что игра запускается и весь функционал, который должен в игре отрабатывать отрабатывает, иконка приложения соответствует иконке нашего приложения. Также чек-лист может быть составлен на регрессионное тестирование и даже на тестирование требований. Чек-листы чаще всего составляются без детализации и их можно скомпоновать в наборы и проверять тоже для любого функционала либо нового, либо регрессионного. Чек-листы лучше сразу писать по требованиям (геймдизайнерскому документу) перед стартом тестирования функционала или по итогу. Баг-репорт Баг-репорт оформляется, когда баг уже локализован и его можно повторить. Если баг плавающий, нужно пытаться его повторить или занести в систему, где фиксируются баги, как плавающий баг. Ключевой момент, что баг можно повторить и воспроизвести, только тогда его заносят в систему с багами, где хранятся баг-репорты. Если создать и оформить какой-то баг, и разработчик не сможет его воспроизвести, то тут появится множество вопросов. Поэтому лучше всего сразу проверить на нескольких устройствах, если это возможно и посмотреть на разных операционных системах, на разных разрешениях экрана, то есть максимально локализовать проблему. В баг-репорте обязательно должны быть: Подробное описание проблемы – что, где, когда случилось. Важность дефекта, который указывает тестировщик, а уже приоритет по исправлению этой ошибки указывает менеджер либо команда из разработчиков. Условия воспроизведения – версия игры, версия операционной системы и другие уникальные условия, которые могут помочь разработчику быстро найти баг, устранить и передать задачу на тестинг. Алгоритм воспроизведения – пошаговые предусловия предусловия, которые необходимы для воспроизведения бага. Доказательства – скрины, видео, логи с устройств. ПРАКТИКА 1) Разработать тестовые наборы для функционального тестирования (Примеры документации таблица 1-3) 2)Разработать и провести тестирование программы и представить результаты в виде таблицы. Примечание: Программа должна иметь такие функции как: авторизации, кнопки сохранить, удалить, добавить, поиск, печать документов и т.д. 3)Выработать рекомендации для корректировки тестируемой программы. 4) Обменяться программой с другими студентами. Таблица 1 – Тест кейс  Таблица 2. – Чек лист  Таблица 3 – баг-репорт   Содержание отчета 1. Тема. Цель. 2. Оборудование. 3. Результат выполнения практического задания. 4. Ответы на контрольные вопросы. 5. Вывод. ЗАДАНИЕ ДЛЯ ОТЧЕТА 1. Составьте отчет о проделанной работе, (в отчете минимум 10 скриншотов выполнения действий). Укажите в отчете дату, Практическая работа №, Наименование работы, Цель занятия, кратко опишите порядок выполнения работы, сделайте вывод о приобретенных умениях и навыках. 2. Продемонстрируйте преподавателю приобретенные умения. 3. Ответьте на индивидуальные вопросы преподавателя по выполнению работы |