Тестирование программного обеспечения
 Скачать 361.79 Kb.
|
|
Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «ТВЕРСКОЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» Математический факультет Кафедра компьютерной безопасности и математических методов управления КУРСОВАЯ РАБОТА по дисциплине “Методы программирования” на тему Тестирование программного обеспечения Выполнила: студентка 35 группы математического факультета специальность Компьютерная безопасность Кушнер Кристина Александровна Проверила: доцент кафедры КБиММУ Цирулева Валентина Михайловна Тверь, 2013 г. Тестирование ПО. Неразрешимость проблемы тестирования. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование (TDD). Непрерывная интеграция. Покрытие кода тестами. Содержание 1. Вступление. .1 Общие понятия. .2 Основные определения. . Тестирование ПО. .1 Классификация видов тестирования. .2 Функциональное тестирование и тестирование качества. . Виды и уровни тестирования. .1 Виды тестирования. .2 Уровни тестирования. . Стратегии восходящего и нисходящего тестирования. .1 Восходящее тестирование. .2 Нисходящее тестирование. .3 Технология восходящего и нисходящего тестирования. . Методы "белого" и "черного" ящика. .1 Метод «белого ящика». .2 Метод «черного ящика». .3 Метод «серого ящика». . Автоматизированное и ручное тестирование. .1 Автоматизированное тестирование. .2 Ручное тестирование. . Разработка через тестирование (TDD). .1 Основные понятия TDD. .2 Требования. 7.3 Цикл разработки через тестирование. .4 Запуск всех тестов: убедиться, что новые тесты не проходят. .5 Запуск всех тестов: убедиться, что все тесты проходят. .6 Рефакторинг 7.7 Стиль разработки. .8 Преимущества. .9 Слабые места. . Непрерывная интеграция. .1 Понятие непрерывной интеграции. 8.2 Требования к проекту. 8.3 Организация. 6 8.4 Сборка по расписанию. 8.5 Преимущества. .6 Недостатки. 8.7 Средства непрерывной интеграции. 9. Покрытие кода тестами. .1 Покрытие кода. .2 Практическое применение. Литература. Приложение 1. Приложение 2. 1. Введение .1 Общие понятия История тестирования программного обеспечения отражает эволюцию разработки самого программного обеспечения. В течение длительного времени разработка программного обеспечения уделяла основное внимание крупномасштабным научным программам, а также программам министерства обороны, связанным с системами корпоративных баз данных, которые проектировались на базе универсальной ЭВМ или миникомпьютера. Тестовые сценарии записывались на бумагу. С их помощью проверялись целевые потоки управления, вычисления сложных алгоритмов и манипулирование данными. Окончательный набор тестовых процедур мог эффективно протестировать всю систему полностью. Тестирование обычно начиналось лишь после завершения плана-графика проекта и выполнялось тем же персоналом. «Тестирование - процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет.» Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение антонима слова «тестирование». Люди с некоторым опытом программирования уже, вероятно, понимает, что невозможно продемонстрировать отсутствие ошибок в программе. Поэтому определение описывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым успехом, то такое определение логически некорректно. Правильное определение тестирования таково: Тестирование - процесс выполнения программы с намерением найти ошибки. Невозможно гарантировать отсутствие ошибок в нетривиальной программе; в лучшем случае можно попытаться показать наличие ошибок. Если программа правильно ведет себя для солидного набора тестов, нет основании утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что не известно, когда эта программа не работает. Конечно, если есть причины считать данный набор тестов способным с большой вероятностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, устанавливаемом этими тестами. Большинство людей, поставив цель (например, показать, что ошибок нет), ориентируется в своей деятельности на достижение этой цели. Тестировщик подсознательно не позволит себе действовать против цели, т. е. подготовить тест, который выявил бы одну из оставшихся в программе ошибок. Поскольку мы все признаем, что совершенство в проектировании и кодировании любой программы недостижимо и поэтому каждая программа содержит некоторое количество ошибок, самым плодотворным применением тестирования будет найти некоторые из них. Если мы хотим добиться этого и избежать психологического барьера, мешающего нам действовать против поставленной цели, наша цель должна состоять в том, чтобы найти как можно больше ошибок. Появление персональных компьютеров способствовало стандартизации этой отрасли, поскольку приложения стали изначально создаваться для работы с общей операционной системой. Внедрение персональных компьютеров открыло новую эру и привело к быстрому и бурному росту коммерческих разработок. Коммерческие приложения жестко боролись за первенство и выживание. Пользователи компьютеров принимали выжившее программное обеспечение как стандарты defacto. Пакетная обработка заменялась системами, работающими в реальном времени. Тестирование систем реального времени потребовало другого подхода к проектированию тестирования из-за того, что рабочие потоки могли вызываться в любом порядке. Эта особенность привела к появлению огромного количества процедур тестирования, способных поддержать бесконечное число перестановок и сочетаний. Сформулируем основополагающий вывод: · Если ваша цель - показать отсутствие ошибок, то вы их найдете не слишком много. · Если же ваша цель - показать наличие ошибок, вы найдете значительную их часть. Причиной многих несчастий разработчиков являются программные ошибки, из-за которых на их многострадальные головы сваливаются и давно просроченные проекты, и бессонные ночи. Ошибки могут сделать жизнь разработчиков действительно несчастной, потому что, достаточно нескольким ошибкам вкрасться в их программы, как заказчики прекращают этими программами пользоваться, а сами они могут потерять работу. Надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности - с самого начала не допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Роль тестирования состоит как раз в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе. Попытки с помощью тестирования достичь надежности плохо спроектированной программы совершенно бесплодны. Долгое время ошибки рассматривали как простые неприятности. Ничто не может быть дальше от истины. Всем программистам известны компании, которые закрылись только потому, что выпускали программные продукты, совершенно непригодные к использованию из-за обилия ошибок. В связи со всеобщей компьютеризацией, все шире и шире захватывающей такие важные области, как управление системами жизнеобеспечения, медицинские приборы и сверхдорогую компьютерную аппаратуру, над ошибками больше нельзя просто посмеиваться или рассматривать их как нечто имеющее значение только на этапах разработки. Тестирование оказывается довольно необычным процессом (вот почему оно и считается трудным), так как этот процесс разрушительный. Ведь цель проверяющего (тестировщика) - заставить программу сбиться. Он доволен, если это ему удается; если же программа на его тесте не сбивается, он не удовлетворен. Еще одна причина, по которой трудно говорить о тестировании - это тот факт, что о нем известно очень немногое. Если сегодня мы располагаем 5% тех знании о проектировании и собственно программировании (кодировании), которые будут у нас к 2000 г., то о тестировании нам известно менее 1%. 1.2 Основные определения Хотя в тестировании можно выделить несколько различных процессов, такие термины, как тестирование, отладка, доказательство, контроль и испытание, часто используются как синонимы и, к сожалению, для разных людей имеют разный смысл. Хотя стандартных, общепринятых определений этих терминов нет, попытка сформулировать их была предпринята на симпозиуме по тестированию программ. Классификацию различных форм тестирования я начну с того, что дам эти определения, слегка дополнив и расширив их список. Тестирование (testing), как мы уже выяснили,-процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки. Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию - взгляд во многом ошибочный. Контроль (verification) - попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде. Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде. Аттестация (certification) - авторитетное подтверждение правильности программы, аналогичное аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом. Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки. Эти два вида деятельности связаны - результаты тестирования являются исходными данными для отладки. Тестирование модуля, или автономное тестирование (module testing, unit testing) - контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство. Тестирование сопряжении (integration testing) - контроль сопряжении между частями системы (модулями, компонентами, подсистемами). Тестирование внешних функций (external function testing) - контроль внешнего поведения системы, определенного внешними спецификациями. Комплексное тестирование (system testing) - контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной. Тестирование приемлемости (acceptance testing) - проверка соответствия программы требованиям пользователя. Тестирование настройки (installation testing) - проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы. 2. Тестирование ПО .1 Классификация видов тестирования Тестирование ПО - это процесс его исследования с целью получения информации о качестве. Целью тестирования является выявление дефектов в ПО. С помощью тестирования нельзя доказать отсутствие дефектов и корректность функционирования анализируемой программы. Тестирование сложных программных продуктов является творческим процессом, не сводящимся к следованию строгим и четким процедурам. Тестирование программного обеспечения охватывает целый ряд видов деятельности, весьма аналогичный последовательности процессов разработки программного обеспечения. Сюда входят постановка задачи для теста, проектирование, написание тестов, тестирование тестов и, наконец, выполнение тестов и изучение результатов тестирования. Решающую роль играет проектирование теста. Состав и содержание документации, сопутствующей процессу тестирования, определяется зарубежным стандартом IEEE 829-2008 Standard for Software Test Documentation. Существует несколько оснований, по которым принято производить классификацию видов тестирования. . По объекту тестирования · Функциональное тестирование (functional testing) · Нагрузочное тестирование (performance/load/stress testing) · Тестирование удобства использования (usability testing) · Тестирование интерфейса пользователя (UI testing) · Тестирование безопасности (security testing) · Тестирование локализации (localization testing) · Тестирование совместимости (compatibility testing) . По знаниям о тестируемой системе · Тестирование методом «черного ящика» (black box) · Тестирование методом «белого ящика» (white box) · Тестирование методом «серого ящика» (grey box) . По уровню автоматизации · Ручное тестирование (manual testing) · Автоматизированное тестирование (automated testing) . По степени изолированности · Модульное тестирование (unit testing) · Интеграционное тестирование (integration testing) · Системное тестирование (system testing) . По уровню готовности · Альфа-тестирование (alpha testing) · Бета-тестирование (beta testing) · Приемосдаточные испытания (acceptance testing) .2 Функциональное тестирование и тестирование качества Функциональное тестирование проводится для проверки выполнения системой функциональных требований. Нагрузочное тестирование проводится для анализа работы системы при различных уровнях нагрузки (большие объемы данных или количество пользователей). С помощью нагрузочного тестирования можно экспериментально определить требования к ресурсам, масштабируемость и надежность созданной системы. С точки зрения заказчика системы, нагрузочное тестирование является одним из способов проверки работы системы в условиях, приближенных к реальным. Основными показателями производительности информационной системы, измеряемыми в ходе нагрузочного тестирования, являются: · Время отклика (время выполнения операции) · Число операций, выполняемых в единицу времени (например, transactions per second, TPS). Основным результатом нагрузочного тестирования являются измерения производительности информационной системы, которые могут быть использованы для локализации узких мест и последующей оптимизации. В процессе нагрузочного тестирования может быть построена «кривая деградации» - график, показывающий зависимость производительности системы (например, в единицах времени отклика) от рабочей нагрузки (например, от числа виртуальных пользователей). Стрессовое (stress) тестирование проводится в условиях недостаточных системных ресурсов и позволяет оценить уровень надежности работы системы под нагрузкой. Тестирование удобства использования имеет целью оценить приемлемость пользовательского интерфейса приложения (время, затраченное на достижение цели, полученный результат, легкость доступа к нужной информации, интерпретация ответов системы и т.д.) Чтобы охватить все аспекты удобства использования, наряду со специалистами по обеспечению качества в этом виде тестирования могут принимать участие специалисты по маркетингу и психологи, а также будущие пользователи системы. В процессе тестирования пользователям под руководством модератора предлагается решить с использованием системы ряд задач. Для последующего анализа результатов тестирования необходима четкая фиксация всех происходящих событий : использование клавиатуры и мыши, выражение лица респондента, переходы между экранами, речь модератора и респондента. Тестирование интерфейса пользователя (UI testing) предполагает проверку соответствия ПО требованиям к графическому интерфейсу пользователя. Различают следующие виды тестирования графического интерфейса пользователя: · Тестирование на соответствие стандартам графических интерфейсов; · Тестирование с различными разрешениями экрана; · Тестирование локализованных версий: проверка длины названий элементов интерфейса и т.п.; · Тестирование графического интерфейса пользователя на различных целевых устройствах (для мобильных приложений, возможно с использованием эмуляторов). В ходе тестирование безопасности (security testing) проводится оценка уязвимости системы по отношению к атакам. Тестирование безопасности проверяет фактическую реакцию защитных механизмов, встроенных в систему, на попытки их взлома и обхода. В ходе тестирования безопасности испытатель играет роль потенциального нарушителя и пытается проверить следующие аспекты безопасности системы: · Тестирование механизмов контроля доступа - помогает обнаружить дефекты, в результате которых пользователи могут получать несанкционированный доступ к объектам и функциям приложения; · Тестирование авторизации пользователей - выявляет дефекты, связанные с авторизацией отдельных пользователей и г8рупп пользователей и с проверкой их подлинности; |