методические указания к практикуму по мдк 01.02 по специальности 09.05. Методические указания к выполнению лабораторных работ (1). Правила выполнения и проведения практических занятий 5 Критерии оценки практических занятий 5
![]()
|
Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке. Контрольные вопросы: Дайте определение понятия интеграционное тестирование. В чем сущность метода «белого ящика»? В чем сущность метода «черного ящика». Цели интеграционного тестирования. Преимущества «раннего начала» тестирования. Лабораторная работа № 16. Документирование результатов тестирования Цель занятия: составить итоговый отчет о результатах тестирования приложения. Оборудование, технические и программные средства: персональный компьютер, среда программирования Visual Studio 2019. Продолжительность занятия:2 часа. Задание: Провести документирование результатов тестирования программного средства. Составить отчет по лабораторной работе. Теоретические сведения: Итоговый отчет можно разделить на части с соответствующей информацией: Приветствие. Общая информация (Common Information). Тестовое окружение (Test Platform). Рекомендации QA (QA Recommendations). Детализированная информация (Detailed Information). Окончание содержимого. Приветствие Свое письмо с отчетом необходимо начать с приветствия всех адресатов. Если по каким-либо причинам произошла задержка данных отчета, либо не весь запланированный функционал был проверен, то эту информацию необходимо предоставить в начале письма. Следует извиниться за задержку и указать адекватные причины произошедшего. Также в самом начале письма следует указывать, если были какие-то внешние факторы, препятствующие проверке какой-то части функционала. Если во время тестирования не произошло никаких форс-мажорных обстоятельств, то достаточно обычного вежливого приветствия и далее уже переход к следующим пунктам. Общая информация (Common Information) В данной части отчета описывается, какие виды тестов проводились. Зачастую указываются модули, которые тестировались или функционал. Стоит удостовериться, не забыта ли какая-то часть функционала, особенно это актуально, когда нужно собрать итоговый отчет, соединив в себе данные о разных видах тестов и функционале. Тестовое окружение (Test Platform) Как правило, в этой части указываются: Название проекта. Номер сборки. Ссылка на проект (сборку). Необходимо убедиться, что зайдя по этой ссылке вы действительно попадаете на проект или можете установить приложение. При указании данных в этой части отчета нужно быть очень внимательным, т.к. неправильная ссылка на сборку или неверный номер сборки не дают достоверной информации всем заинтересованным людям, а также затрудняют работу человеку, собирающему финальный отчет. Рекомендации QA (QA Recommendations) Данная часть отчета является наиболее важной, т.к. здесь отражается общее состояние сборки. Здесь показывается аналитическая работа тестировщика, его рекомендации по улучшению функционала, наиболее слабые места и наиболее критичные дефекты, динамика изменения качества проекта. В этом разделе должна быть информация о следующем: Указан функционал (часть функционала), который заблокирован для проверки. Даны пояснения почему этот функционал не проверен (указаны наиболее критичные дефекты). Произведен анализ качества проверенного функционала. Следует указать, улучшилось оно или ухудшилось по сравнению с предыдущей версией, какое качество на сегодняшний момент, какие факторы повлияли на выставление именно такого качества сборки. Если качество сборки ухудшилось, то обязательно должны быть указаны регрессионные места. Наиболее нестабильные части функционала следует выделить и указать причину, по которой они таковыми являются. Даны рекомендации по тому функционалу и дефектам, скорейшее исправление которых является наиболее приоритетным. Список наиболее критичных для сборки дефектов, с указанием названия и их критичности. Для отчета уровня Smoke обязательно указать весь нестабильный функционал. Если сборка является релизной или предрелизной, то любое ухудшение качества является критичным и важно об этом сообщить менеджеру как можно раньше. Помимо всего вышеуказанного для релизных и предрелизных сборок в отчете о качестве продукта важно указывать следующее: Дана информация о всех проблемах, характерных сборке. Проведен анализ, насколько оставшиеся проблемы являются критичными для конечного пользователя. Указаны дефекты, которые следует исправить, чтобы качество конечной сборки было выше. Детализированная информация (Detailed Information) В данной части отчета описывается более подробная информация о проверенных частях функционала, устанавливается качество каждой проверенной части функционала(модуля) в отдельности. В зависимости от типа проводимых тестов, эта часть отчета будет отличаться. Smoke При оценке качества функционала на уровне Smoke теста, оно может быть либо Приемлемым, либо Неприемлемым. Качество сборки зависит от нескольких факторов: Если это релизная или предрелизная сборка, то для выставления Приемлемого качества на уровне Smoke не должно быть найдено функциональных дефектов. Наличие нового функционала. Новый функционал, который впервые поставляется на тестирование, не должен содержать дефектов уровня Smoke для выставления Приемлемого качества всей сборки. Чтобы установить сборке Приемлемое качество, не должно быть дефектов уровня Smoke у того функционала, по которому планируется проводить полные тесты. Все наиболее важные части функционала отрабатывают корректно, тогда качество всего функционала на уровне Smoke может быть оценено, как Примлемое. В части о детализированной информации качества сборки следует более подробно описать проблемы, которые были найдены во время теста. DV В этой части отчета указывается качество о проведении валидации дефектов. Здесь должна быть следующая информация: Общее количество всех дефектов, поступивших на проверку. Количество неисправленных дефектов и их процент от общего количества. Список дефектов, которые не были проверены и причины, по которым этого не было сделано. Наглядная таблица с неисправленными дефектами. По вышеуказанным результатам выставляется качество теста. Если процент неисправленных дефектов < 10%, то качество Приемлемое, если > 10%, то качество Неприемлемое. NFT При проведении полного теста нового функционала качество отдельно проверенного функционала может быть: Высокое, Среднее, Низкое. В отчете следует отдельно указывать информацию о качестве каждой части нового функционала. В этой части отчета должна быть следующая информация: Дана общая оценка реализации нового функционала (сгруппированная по качеству). Подробная (детальная) информация о качестве каждой из частей новой функциональности. Проведен анализ каждой из новых функций в отдельности. Даны ясные пояснения о выставлении соответствующего качества. Даны рекомендации по улучшению качества (какие проблемы следует исправить). Показана таблица с новыми функциями (название), их качеством, статусом фуннкции из CQ. AT, MAT, Regression Если проводились тесты указанных уровней, то в первую очередь при написании отчета нужно анализировать динамику изменения качества проверенной функциональности в сравнении с более ранними версиями сборки. Также как и у предыдущего вида тестов, качество этих может быть: Высокое, Среднее, Низкое. Для указанных видов тестов в данной части отчета должна быть описана информация следующего характера: Дана сравнительная характеристика каждой из частей функционала в сравнении с предыдущими версиями сборки. Подробная (детальная) информация о качестве каждой из частей проверенной функциональности. Даны ясные пояснения о выставлении соответствующего качества каждой функции в отдельности. Даны рекомендации по улучшению качества (какие проблемы следует исправить). Окончание содержимого В завершении содержимое отчета должно включать в себя информацию следующего характера: Ссылка на тест-план. Ссылка на документ feature matrix (если таковой имеется). Ссылка на документ со статистикой (если таковой имеется). Общее количество всех новых дефектов. Подпись высылающего отчет. Данные ссылки должны быть корректными, необходимо проверить достоверную ли информацию получает пользователь, открывший ссылку. Следует обращать особое внимание на подпись, удостоверьтесь, что указана именно ваша подпись либо какая-то универсальная для определенного проекта подпись. Выполнение работы: 1. Запустить ранее созданное приложение. 2. Составить итоговый отчет по результатам тестирования приложения. 3. Оформить отчет и защитить лабораторную работу. Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке. Контрольные вопросы: 1. Какая структура итогового отчета о результатах тестирования? 2. Что содержится в разделе Приветствие? 3. Что содержится в разделе Общая информация? 4. Что содержится в разделе Тестовое окружение? 5. Что содержится в разделе Рекомендации QA? 6. Что содержится в разделе Детализированная информация? 7. Что содержится в разделе Окончание содержимого? VI. Учебно-методическое и информационное обеспечение дисциплины Агальцов, В. П. Математические методы в программировании / В.П. Агальцов. - М.: Форум, 2017. - 321 c. Алексеев, В. Е. Графы и алгоритмы. Структуры данных. Модели вычислений / В.Е. Алексеев, В.А. Таланов. - М.: Бином. Лаборатория знаний, Интернет-университет информационных технологий, 2016. - 154 c. Альфред, В. Ахо Компиляторы. Принципы, технологии и инструментарий / Альфред В. Ахо и др. - М.: Вильямс, 2015. - 294 c. Анашкина, Н. В. Технологии и методы программирования / Н.В. Анашкина, Н.Н. Петухова, В.Ю. Смольянинов. - М.: Academia, 2017. - 478 c. Афонин, В. В. Моделирование систем / В.В. Афонин, С.А. Федосин. - М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2016. - 619 c. Бёрд, Ричард Жемчужины проектирования алгоритмов. Функциональный подход / Ричард Бёрд. - М.: ДМК Пресс, 2015. - 410 c. Вендров, А. М. Практикум по проектированию программного обеспечения экономических информационных систем / А.М. Вендров. - М.: Финансы и статистика, 2013. - 417 c. Гагарина, Л. Г. Разработка и эксплуатация автоматизированных информационных систем. Учебное пособие / Л.Г. Гагарина. - М.: Форум, Инфра-М, 2015. - 707 c. Гагарина, Л. Г. Технология разработки программного обеспечения / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. Виснадул. - М.: Форум, Инфра-М, 2018. - 632 c. Голицына, О. Л. Основы проектирования баз данных. Учебное пособие / О.Л. Голицына, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2016. - 582 c. Гончаров, В. А. Методы оптимизации. Учебное пособие / В.А. Гончаров. - М.: Юрайт, 2015. - 110 c. Грекул, В. И. Методические основы управления ИТ-проектами / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. - М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2016. - 357 c. Гусятников, В. Н. Стандартизация и разработка программных систем / В.Н. Гусятников, А.И. Безруков. - М.: Финансы и статистика, Инфра-М, 2017. - 761 c. Емельянова, Н. З. Проектирование информационных систем / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2017. - 456 c. Заботина, Н. Н. Проектирование информационных систем / Н.Н. Заботина. - М.: ИНФРА-М, 2015. - 681 c. Иванова, Г. С. Объектно-ориентированное программирование / Г.С. Иванова, Т.Н. Ничушкина. - М.: МГТУ им. Н. Э. Баумана, 2016. - 596 c. Исаев, Г. Н. Проектирование информационных систем. Учебное пособие / Г.Н. Исаев. - М.: Омега-Л, 2015. - 645 c. Казанский, А. А. Объектно-ориентированное программирование на языке Microsoft Visual C# в среде разработки Microsoft Visual Studio 2008 и .NET Framework. Учебное пособие и практикум. В 3 частях. Часть 3 / А.А. Казанский. - М.: МГСУ, 2017. - 810 c. Лукин, В. В. Технология разработки программного обеспечения. Учебное пособие / В.В. Лукин, В.Н. Лукин, Т.В. Лукин. - М.: Вузовская книга, 2015. - 479 c. Макаровских, Т. А. Документирование программного обеспечения. В помощь техническому писателю. Учебное пособие / Т.А. Макаровских. - М.: Ленанд, 2015. - 469 c. Орлов, С. А. Технологии разработки программного обеспечения / С.А. Орлов, Б.Я. Цилькер. - М.: Питер, 2016. – 746 c. Соколова, В.В. Вычислительная техника и информационные технологии. разработка мобильных приложений. учебное пособие для прикладного бакалавриата / В.В. Соколова. - М.: Юрайт, 2016. - 419 c. Хетагуров, Я. А. Проектирование автоматизированных систем обработки информации и управления (АСОИУ). Учебник / Я.А. Хетагуров. - М.: Бином. Лаборатория знаний, 2015. - 699 c. Хорев, П. Б. Объектно-ориентированное программирование / П.Б. Хорев. - М.: Академия, 2016. - 747 c. Чаусова Практикум По Программированию / Чаусова. - Москва: Гостехиздат, 2016. - 695 c. Черняк, А. А. Математическое программирование. Алгоритмический подход / А.А. Черняк, Ж.А. Черняк, Ю.М. Метельский. - М.: Вышэйшая школа, 2016. - 327 c. Приложение 1 Код страницы авторизации xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:local="clr-namespace:Olesya" mc:Ignorable="d" Title="MainWindow" Height="800" Width="800" Loaded="Window_Loaded" WindowStartupLocation="CenterScreen"> |