Тестирование программного обеспечения. Уровни тестирования. Методы тестирования. Этапы тестирования. Виды тестирования

 

 

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ

 

Московский государственный университет экономики, статистики и информатики

Тверской филиал

 

 

 

Кафедра Информационных технологий,

Естественнонаучных и математических дисциплин

 

 

Контрольная работа

 

 

по дисциплине: «Программная инженерия»

на тему: «Тестирование программного обеспечения. Уровни тестирования. Методы тестирования. Этапы тестирования. Виды тестирования»

 

 

 

 

Выполнил: студент 1 курса

заочного отделения

группы Тв-ЗНИ-201Э

Кузьмин Валентин Валентинович

Проверила: Александрова Вера Алексеевна

 

 

 

Тверь 2013

Содержание

 

Введение…………………………………………………………………….3

1. Тестирование программного обеспечения……………………...….5
2. Уровни тестирования……………………..…………………………5
3. Методы тестирования…………..…………………………………...8
1. Восходящее тестирования………………..…………………………8
2. Нисходящее тестирование…………………..………………………9
3. Метод большого скачка…………………………..…………………9
4. Метод сандвича…………………………..………………………….9
5. Модифицированный метод сандвича………………………..……10
6. Метод «Белого ящика»………………………. ……………………10
7. Метод «Черного ящика»…………………….. …………………….11
4. Этапы тестирования………………………………………………..13
5. Виды тестирования……..…………………………………………..14

Заключение…………………………………………………………….….18

Список использованной литературы…………………………………….19

 

Введение

 

История тестирования программного обеспечения отражает эволюцию разработки самого программного обеспечения. В течение длительного времени разработка программного обеспечения уделяла основное внимание крупномасштабным научным программам, а также программам министерства обороны, связанным с системами корпоративных баз данных, которые проектировались на базе универсальной ЭВМ или миникомпьютера. Тестовые сценарии записывались на бумагу. С их помощью проверялись целевые потоки управления, вычисления сложных алгоритмов и манипулирование данными. Окончательный набор тестовых процедур мог эффективно протестировать всю систему полностью. Тестирование обычно начиналось лишь после завершения плана–графика проекта и выполнялось тем же персоналом.

Появление персональных компьютеров способствовало стандартизации этой отрасли, поскольку приложения стали изначально создаваться для работы с общей операционной системой. Внедрение персональных компьютеров открыло новую эру и привело к быстрому и бурному росту коммерческих разработок. Коммерческие приложения жестко боролись за первенство и выживание. Пакетная обработка заменялась системами, работающими в реальном времени.

Тестирование систем реального времени потребовало другого подхода к проектированию тестирования из–за того, что рабочие потоки могли вызываться в любом порядке. Эта особенность привела к появлению огромного количества процедур тестирования, способных поддержать бесконечное число перестановок и сочетаний.

Долгое время программные ошибки рассматривали как простые неприятности. В связи со всеобщей компьютеризацией, все шире и шире захватывающей такие важные области, как управление системами жизнеобеспечения, медицинские приборы и сверхдорогую компьютерную аппаратуру, ошибки стало невозможно рассматривать как нечто имеющее значение только на этапах разработки.

 

1. Тестирование программного обеспечения

 

Тестирование программного обеспечения (software testing) – это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.

Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование это плановая, упорядоченная деятельность.

Тестирование предусматривает «анализ» или «эксплуатацию» программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тестированием (static testing). Статическое тестирование предусматривает проверку программных кодов, сквозной контроль и проверку программы без запуска па машине, то есть проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусматривающая эксплуатацию программного продукта, носит название динамического тестирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок.

Важным понятием процесса тестирования является дефект (bug). Дефект – это программная ошибка – изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов. Дефект может возникнуть на стадии кодирования, на стадии формулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных.

Отладка – это процесс выявления источников отказов, то есть ошибок, и внесение в программу соответствующих исправлений для их устранения.

 

2. Уровни тестирования

 

Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет «над чем» производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий. Различают три уровня тестирования: модульное, интеграционное и системное тестирование.

Модульное тестирование (юнит–тестирование). Данный вид тестирования позволяет проверить на корректность отдельные модули исходного кода программы.

Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.

Целью модульного тестирования является изоляция отдельных частей программы для того, чтобы показать, что по отдельности эти части работоспособны.

Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом.

Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев. Кроме того, происходит тестирование каждого из модулей по отдельности. Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях, не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования.

Интеграционное тестирование. В данной фазе тестирования отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определенные в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования.

Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приемным и требованиям надежности. Тестирование этих проектируемых единиц – объединения, множества или группы модулей – выполняется через их интерфейс, с использованием тестирования «черного ящика». Для автоматизации интеграционного тестирования применяются системы непрерывной интеграции (Continuous Integration System, CIS).

Системное тестирование. Это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования черного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.

Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований к системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д. Для минимизации рисков, связанных с особенностями поведения системы в той или иной среде, во время тестирования используется окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.

Выделяют два подхода к системному тестированию:

– на базе требований (для каждого требования пишутся тестовые случаи, проверяющие выполнение данного требования);

– на базе случаев использования.

Подкатегориями системного тестирования являются альфа–тестирование и бета–тестирование.

Альфа–тестирование – имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями. Чаще всего альфа–тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приемочного тестирования. Иногда альфа–тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки.

Бета–тестирование – в некоторых случаях выполняется распространение предварительной версии (иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок.

 

3. Методы тестирования программного обеспечения

 

1. Восходящее тестирование

При восходящем тестировании программа собирается и тестируется снизу вверх. Модули самого нижнего уровня тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания.

Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжении программы.

 

2. Нисходящее тестирование

При нисходящем тестировании программа собирается и тестируется сверху вниз. Изолировано тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соединяются один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули.

 

3. Метод большого скачка

В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу.

Метод большого скачка по сравнению с другими подходами имеет много недостатков и мало достоинств. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными. Он значительно усложняет отладку. Но все же, данный метод не всегда нежелателен. Если программа мала и хорошо спроектирована, он может оказаться приемлемым. Однако для крупных программ метод большого скачка обычно губителен.

 

4. Тестирование методом сандвича