Тестирование и отладка программного обеспечения
МГПК (Могилёвский государственный политехнический колледж)
Контрольная
на тему: «Тестирование и отладка программного обеспечения»
по дисциплине: «Тестирование и отладка программного обеспечения»
2021
15.00 BYN
Тестирование и отладка программного обеспечения
Тип работы: Контрольная
Дисциплина: Тестирование и отладка программного обеспечения
Шифр: 10
Работа защищена на оценку "9" без доработок.
Уникальность свыше 40%.
Работа оформлена в соответствии с методическими указаниями учебного заведения.
Количество страниц - 12.
Поделиться
1.Нагрузочное тестирование
2.Виды системного тестирования
3.Разработка плана и проведение тестирования объектно-ориентированных ПС
4.Понятие решения об автоматизации тестирования
Список используемой литературы
1.Нагрузочное тестирование.
Термин нагрузочное тестирование может быть использован в различных значениях в профессиональной среде тестирования ПО. В общем случае он означает практику моделирования ожидаемого использования приложения с помощью эмуляции работы нескольких пользователей одновременно. Таким образом, подобное тестирование больше всего подходит для мультипользовательских систем, чаще - использующих клиент-серверную архитектуру (например, веб-серверов). Однако и другие типы систем ПО могут быть протестированы подобным способом. Например, текстовый или графический редактор можно заставить прочесть очень большой документ; а финансовый пакет - сгенерировать отчёт на основе данных за несколько лет. Наиболее адекватно спроектированный нагрузочный тест даёт более точные результаты.
Основная цель нагрузочного тестирования заключается в том, чтобы, создав определённую ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) и, обычно, использовав идентичное программное и аппаратное обеспечение, наблюдать за показателями производительности системы.
В идеальном случае в качестве критериев успешности нагрузочного тестирования выступают требования к производительности системы, которые формулируются и документируются на стадии разработки функциональных требований к системе до начала программирования основных архитектурных решений. Однако часто бывает так, что такие требования не были четко сформулированы или не были сформулированы вовсе. В этом случае первое нагрузочное тестирование будет являться пробным (exploratory load testing) и основываться на разумных предположениях об ожидаемой нагрузке и потреблении аппаратной части ресурсов.
Одним из оптимальных подходов в использовании нагрузочного тестирования для измерений производительности системы является тестирование на стадии ранней разработки. Нагрузочное тестирование на первых стадиях готовности архитектурного решения с целью определить его состоятельность называется 'Proof-of-Concept' тестированием.
2.Виды системного тестирования.
Принято выделять следующие виды системного тестирования:
• функциональное тестирование;
• тестирование производительности;
• нагрузочное или стрессовое тестирование;
• тестирование конфигурации;
• тестирование безопасности;
• тестирование надежности и восстановления после сбоев;
• тестирование удобства использования.
В ходе системного тестирования проводятся далеко не все из перечисленных видов тестирования – конкретный их набор зависит от тестируемой системы.
Исходной информацией для проведения перечисленных видов тестирования являются два класса требований: функциональные и нефункциональные.
Функциональные требования явно описывают, что система должна делать и какие выполнять преобразования входных значений в выходные. Нефункциональные требования определяют свойства системы, напрямую не связанные с ее функциональностью. Примером таких свойств может служить время отклика на запрос пользователя (например, не более 2 секунд), время бесперебойной работы (например, не менее 10000 часов между двумя сбоями), количество ошибок, которые допускает начинающий пользователь за первую неделю работы (не более 100) и т.п.
Функциональное тестирование. Данный вид тестирования предназначен для доказательства того, что вся система в целом ведет себя в соответствии с ожиданиями пользователя, формализованными в виде системных требований. В ходе данного вида тестирования проверяются все функции системы с точки зрения ее пользователей (как пользователей-людей, так и «пользователей»-других программных систем). Система при функциональном тестировании рассматривается как черный ящик, поэтому в данном случае полезно использовать классы эквивалентности. Критерием полноты тестирования в данном случае будет полнота покрытия тестами системных функциональных требований (или системных тест-требований) и полнота тестирования классов эквивалентности.
3.Разработка плана и проведение тестирования объектно-ориентированных ПС.
Существуют две принципиально различных стратегии выполнения пошагового тестирования:
• нисходящее тестирование;
• восходящее тестирование.
Нисходящее тестирование начинается с головного модуля, в нашем случае с модуля А. Возникают проблемы: как передать тестовые данные в А, ведь ввод и вывод осуществляется в других модулях? Как передать в А несколько тестов?
Решение можно представить в следующем виде:
• написать несколько вариантов заглушек B (для каждого теста);
• написать заглушку B так, чтобы она читала тестовые данные из внешнего файла.
В качестве стратегии подключения модулей можно использовать одну из следующих:
• подключаются наиболее важные с точки зрения тестирования модули;
• подключаются модули, осуществляющие операции ввода/вывода (для того, чтобы обеспечивать тестовыми данными «внутренние» модули.
Нисходящее тестирование имеет ряд недостатков: предположим, что модули I и J уже подключены, и на следующем шаге тестирования заглушка H меняется на реальный модуль H. Как передать тестовые данные в Н? Это нетривиальная задача, потому что между J и Н имеются промежуточные модули и может оказаться невозможным передать тестовые данные, соответствующие разработанным тестам. К тому же достаточно сложно интерпретировать результаты тестирования Н, так как между Н и I также существуют промежуточные модули.
Восходящее тестирование практически полностью противоположно нисходящему тестированию. Начинается с терминальных (не вызывающих другие модули) модулей.
Стратегия подключения новых модулей также должна основываться на степени критичности данного модуля в программе. Восходящее тестирование лишено недостатков нисходящего тестирования, однако имеет свой, главный недостаток: рабочая программа не существует до тех пор, пока не добавлен последний (в нашем случае А) модуль.
Выбор одной их двух представленных стратегий определяется тем, на какие модули (верхнеуровневые или модули нижнего уровня) следует обратить внимание при тестировании в первую очередь.
4.Понятие решения об автоматизации тестирования.
Автоматизированное тестирование программного обеспечения - это процесс проверки программного обеспечения, который включает в себя такие шаги как запуск, инициализация, выполнение, анализ и выдача результата, и выполняет их автоматически посредством специализированных инструментов. Автоматизированное тестирование является аналогом ручного функционального тестирования, но при этом выполняется программой по заданному сценарию (скрипту), а не человеком.
В настоящее время автоматизация рутинного процесса тестирования становится все популярней. Основной целью автоматизации является оптимизация временных и человеческих ресурсов, затрачиваемых на проведение тестирования. Однако не стоит ставить задачу автоматизации всех возможных тестов. Применение автоматизированного тестирования может быть эффективным лишь в некоторых случаях. Поэтому следует тщательно выбирать область применения автоматизации для получения максимальной отдачи от тестирования программного продукта.
Одной из важных задач в тестировании является функциональное регрессионное тестирование, которое проводится для того, чтобы определить работоспособность уже существующего функционала в виду каких-либо исправлений или дополнений.
Данный вид тестирования является довольно объемным и его ресурсоемкость может достигать 90% от общего объема работ, при тестировании новых версий программного продукта. Частичная или полная автоматизация необходимых регрессионных тестов может существенно упростить задачу.
Преимущества автоматизации
Преимущества, которые даёт тестировщику автоматизация тестирования:
• Исключен «человеческий фактор». Существует некоторая гарантия того, что не один тест не будет пропущен при выполнении, и ничего не будет напутано в результатах.
• Скорость выполнения. Автоматизированный скрипт выполняется гораздо быстрее ручного теста, а также предоставляется возможность работы с приложением без использования графического интерфейса.
• Меньшие затраты на поддержку. При уже имеющихся написанных скриптах не требуется такого большого количества времени на их поддержку и анализ результатов, как при проведении того же объема тестирования вручную.
1. Винниченко И. , Автоматизация процессов тестирования / И. Винниченко. - СПб.: питерб 2005. - 203с. - ISBN 5-469-00798-7.
2. Калбертсон Р., Быстрое тестирование. / Р. Калбертсон, К. Браун, Г. Кобб. - М.: Издательский дом "Вильямс", 2003. - 374 с.
3. Котляров, В. П., Основы тестирования программного обеспечения: учебное пособие / В.П. Котляров, Т.В. Коликова. - М.: Интернет-Ун-т Информ. Технологий, 2006. -- 288с. - ISBN 5-94774-406-4.
4. Степанченко И. В., Методы тестирования программного обеспечения: Учеб. пособие / Степанченко И.В. - ВолгГТУ, Волгоград, 2006. - 76 с.
Работа защищена на оценку "9" без доработок.
Уникальность свыше 40%.
Работа оформлена в соответствии с методическими указаниями учебного заведения.
Количество страниц - 12.
Не нашли нужную
готовую работу?
готовую работу?
Оставьте заявку, мы выполним индивидуальный заказ на лучших условиях
Заказ готовой работы
Заполните форму, и мы вышлем вам на e-mail инструкцию для оплаты