ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 56
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИфедеральное государственное бюджетное образовательное учреждение высшего образования
«Тольяттинский государственный университет»
Институт математики, физики и информационных технологий
| (наименование института полностью) |
| |
| (Наименование учебного структурного подразделения) |
| 09.03.03 Прикладная информатика |
| (код и наименование направления подготовки / специальности) |
| Разработка программного обеспечения |
| (направленность (профиль) / специализация) |
Практическое задание № 6
по учебному курсу «Тестирование ПО»
(наименование учебного курса)
Вариант ____
| Обучающегося | А.Н. Тихонова | |
| | (И.О. Фамилия) | |
| Группа | ПИбд – 2006в | |
| | | |
| Преподаватель | Д.Г. Токарев | |
| | (И.О. Фамилия) | |
Тольятти 2023
Практическое задание 6
Модуль 3. Виды тестирования
Тема 3.1. Классификации видов тестирования ПО
Задание.
Дайте определения видам тестирования ПО и укажите назначение. Заполните табл. 6.1.
Таблица 6.1
Виды тестирования ПО
| Вид тестирования | Определение вида тестирования | Когда используют |
| Functional Testing | – это вид тестирования, направленный на проверку корректности работы функциональности приложения (корректность реализации функциональных требований). | На всех уровнях тестирования. Функциональное тестирование проводится для проверки критически важных для бизнеса функций, функциональности и удобство использования. Функциональное тестирование гарантирует, что функции программного обеспечения и функциональные возможности ведут себя так, как ожидалось, без каких-либо сбоев. В основном проверяется все приложение на спецификации, упомянутые в документе Спецификация требований к программному обеспечению. |
| Safety Testing | – это тестирование программного продукта с целью определить его безопасность (безопасность – способность программного продукта при использовании оговоренным образом оставаться в рамках приемлемого риска причинения вреда здоровью, бизнесу, программам, собственности или окружающей среде. | при проектировании, разработке, использовании и обслуживании программных систем и их интеграции с аппаратными системами, критически важными для безопасности, в производственной среде. |
| Security Testing | – это тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям, права на доступ к которым у злоумышленника нет | Для проверки способности продукта устоять от уязвимостей и атак. Даже проведя полный цикл тестирования безопасности, нельзя быть на 100% уверенным, что система по-настоящему обезопасена. Но можно быть уверенным в том, что процент несанкционированных проникновений, краж информации и потерь данных будет в разы меньше, чем у тех, кто не проводил тестирования безопасности. |
| Compatibility Testing | – это тестирование, направленное на проверку способности приложения работать в указанном окружении. | Когда необходимо проверить/измерить степень того, насколько удовлетворительно элемент тестирования может функционировать параллельно с другими независимыми продуктами в общей среде (сосуществование) и, по мере необходимости, обменивается информацией с другими системами или компонентами (функциональная совместимость) |
| GUI Testing | – это тестирование, направленное для проверки графического пользовательского интерфейса приложения, чтобы убедиться, что все функциональные возможности работают так, как ожидается. | Чтобы полностью определить эффективность и общую удобство использования пользовательского интерфейса приложения, его необходимо проверить. Тестирование позволяет определить, насколько простым или трудным является использование пользовательского интерфейса для максимально широкой аудитории. |
| Usability Testing | – это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. | Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке - тестирование белого ящика (white box testing). Тестирование удобства пользования может производиться на разных уровнях разработки программного обеспечения: модульном, интеграционном, системном и приемочном. |
| Accessibility Testing | – это тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными возможностями (слабым зрением и т.д.). | Убедиться в том, что продукт удобен в использовании людям с различными видами ограничений, инвалидности или особенностями восприятия. Как правило адаптируют приложения, которые часто использует широкий круг лиц, в том числе и люди с ограниченными возможностями. |
| Internationalization Testing | – это тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей. | Этот вид тестирования не подразумевает проверки качества соответствующей адаптации (этим занимается тестирование локализации), оно сфокусировано именно на проверке возможности такой адаптации. При проверке мультиязычного интерфейс приложения или сайта на наличие ошибок перевода, правильности почтовых адресов, имени и фамилии, валют, формата даты и времени, и пр. |
| Performance Testing | – это тестирование, направленное на исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке. | Следует проводить, перед запуском продукта, во избежание потери большого количества пользователей и дополнительных средств на дальнейшее исправление ошибок. Чтобы избежать рисков приложения, необходимо проверить ряд факторов. |
| Stress Testing | – это тестирование, направленное на исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень, или в ситуациях недоступности значительной части необходимых приложению ресурсов. | Стресс-тестирование особенно необходимо для «критически важного» ПО, однако также используется и для остального ПО. Стрессовое тестирование выполняется самым первым, если нет отдельного Capacity тестирования, хотя по факту это все равно будет Capacity, т.к. нагрузка берется «с потолка». Обязательно проводится, если планируется расширение пользовательской базы. |
| Negative Testing | – это тестирование, направленное на исследование работы приложения в ситуациях, когда с ним выполняются (некорректные) операции и/или используются данные, потенциально приводящие к ошибкам (классика жанра — деление на ноль). | Чем более ранняя стадия разработки продукта, тем больше времени уделяется негативному тестированию. Если же имеем дело с давно функционирующим продуктом, без добавления новых фич, то негативное тестирование не будет особенно эффективным. |
| Black Box Testing | – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство. | Методика обычно применяется при системном и приемочном тестировании. Также используют при функциональном тестирование; интеграционном тестирование; стресс-тестирование; юзабилити-тестирование; beta – тестирование. |
| Automated Testing | – это набор техник, подходов и инструментальных средств, позволяющий исключить человека из выполнения некоторых задач в процессе тестирования. | Автоматизация больше используется во время крупных проектов, чем во время небольших. Тесты можно автоматизировать, если система устойчива, и требования к тестируемым областям не меняются часто. |
| Unit/Component Testing | – это тестирование, направленное на проверку отдельных небольших частей приложения, которые (как правило) можно исследовать изолированно от других подобных частей | Обычно компонентное (модульное) тестирование проводится, вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов |
| Integration Testing | – это тестирование, направленное на проверку взаимодействия между несколькими частями приложения (каждая из которых, в свою очередь, проверена отдельно на стадии модульного тестирования). | Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию. используется при запуске программных модулей, разработанных отдельными командами или специалистами. Для бесшовного запуска модули объединяются и тестируются в группе. Это позволяет избежать ошибок, возникающих из-за разного кода и логики, а также выявить некорректное сохранение данных при переносе из одного модуля в другой и проблемы с синхронизацией при сборке. |
Рекомендации по выполнению задания
Заполнить табл. 6.1, опираясь на текст к учебнику и изучив рекомендуемую литературу.
P.s. За Толкунова приношу свои извинения ((((((