Функциональное тестирование программного обеспечения

Автор работы: Пользователь скрыл имя, 18 Июня 2014 в 10:58, курсовая работа

Описание работы

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

Содержание работы

Введение
3
Глава 1
Функциональное тестирование программного обеспечения
5
1.1 Осоьбенности тестирования черного ящика
5
1.2 Способ разбиения по эквивалентности
7
1.3 Способ анализа граничных значений
10
1.4 Способ диаграмм причин-следствий
15
Заключние
21
Список литературы
23

Файлы: 1 файл

ТОпильская ТРПП Курсовая.doc

— 171.50 Кб (Скачать файл)

 

Содержание

Введение

3

Глава 1

Функциональное тестирование программного обеспечения

5

1.1 Осоьбенности тестирования черного  ящика

5

1.2 Способ разбиения по эквивалентности

7

1.3 Способ анализа граничных  значений

10

1.4 Способ диаграмм причин-следствий

15

Заключние

21

Список литературы

23


 

Введение

Современная программная инженерия (Software Engineering) — молодая и быстро развивающаяся область знаний и практик. Она ориентирована на комплексное решение задач, связанных с разработкой особой разновидности сложных систем — программных систем.

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

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

Впрочем, были времена, когда и другие «кланы» людей относились к «программе-рам» с большим подозрением: им мало платили, унижая материально, не находили для них ласковых слов (а употребляли большей частью ругательные). Где эти люди? И где их прежнее отношение?

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

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

Базис современной программной инженерии образуют следующие составляющие:

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

 

 

 

Глава 1. Функциональное тестирование программного обеспечения

1.1 Особенности тестирования «черного  ящика»

 

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

  • набор, образуемый такими входными данными, которые приводят к аномалиям поведения программы (назовем его IT);
  • набор, образуемый такими выходными данными, которые демонстрируют дефекты программы (назовем его ОТ).

Как показано на рис. 7.1, любой способ тестирования «черного ящика» должен:

  • выявить такие входные данные, которые с высокой вероятностью принадлежат набору IT;
  • сформулировать такие ожидаемые результаты, которые с высокой вероятностью являются элементами набора ОТ.

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

Рис. 1. Тестирование «черного ящика»

 

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

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:

1) некорректных или отсутствующих  функций;

2) ошибок интерфейса;

3) ошибок во внешних структурах  данных или в доступе к внешней базе данных;

4) ошибок характеристик (необходимая  емкость памяти и т. д.);

5) ошибок инициализации и завершения.

Подобные категории ошибок способами «белого ящика» не выявляются.

В отличие от тестирования «белого ящика», которое выполняется на ранней стадии процесса тестирования, тестирование «черного ящика» применяют на поздних стадиях тестирования. При тестировании «черного ящика» пренебрегают управляющей структурой программы. Здесь внимание концентрируется на информационной области определения программной системы.

Техника «черного ящика» ориентирована на решение следующих задач:

  • сокращение необходимого количества тестовых вариантов (из-за проверки не статических, а динамических аспектов системы);
  • выявление классов ошибок, а не отдельных ошибок.

1.2 Способ разбиения по эквивалентности

 

Разбиение по эквивалентности — самый популярный способ тестирования «черного ящика» [3], [14].

В этом способе входная область данных программы делится на классы эквивалентности. Для каждого класса эквивалентности разрабатывается один тестовый вариант.

Класс эквивалентности — набор данных с общими свойствами. Обрабатывая разные элементы класса, программа должна вести себя одинаково. Иначе говоря, при обработке любого набора из класса эквивалентности в программе задействуется один и тот же набор операторов (и связей между ними).

На рис. 7.2 каждый класс эквивалентности показан эллипсом. Здесь выделены входные классы эквивалентности допустимых и недопустимых исходных данных, а также классы результатов.

Классы эквивалентности могут быть определены по спецификации на программу.

Рис. 2. Разбиение по эквивалентности

 

Например, если спецификация задает в качестве допустимых входных величин 5-разрядные целые числа в диапазоне 15 000...70 000, то класс эквивалентности допустимых ИД (исходных данных) включает величины от 15 000 до 70 000, а два класса эквивалентности недопустимых ИД составляют:

  • числа меньшие, чем 15 000;
  • числа большие, чем 70 000.

Класс эквивалентности включает множество значений данных, допустимых или недопустимых по условиям ввода.

Условие ввода может задавать:

1) определенное значение;

2) диапазон значений;

3) множество конкретных величин;

4) булево условие.

Сформулируем правила формирования классов эквивалентности.

1.  Если условие ввода задает диапазон п...т, то определяются один допустимый и два недопустимых класса эквивалентности:

  • V_Class={n.. .т} — допустимый класс эквивалентности;
  • Inv_С1аss1={x|для любого х: х < п} — первый недопустимый класс эквивалентности;
  • Inv_С1аss2={y|для любого у: у > т} — второй недопустимый класс эквивалентности.

2. Если условие ввода задает конкретное значение а, то определяется один допустимый и два недопустимых класса эквивалентности:

  • V_Class={a};
  • Inv_Class1 ={х|для любого х: х < а};
  • Inv_С1аss2={y|для любого у: у > а}.

3. Если условие ввода задает множество значений {а, b, с}, то определяются один допустимый и один недопустимый класс эквивалентности:

  • V_Class={a, b, с};
  • Inv_С1аss={x|для любого х: (х а)&(х b)&(х с)}.

4. Если условие ввода задает булево значение, например true, то определяются один допустимый и один недопустимый класс эквивалентности:

  • V_Class={true};
  • Inv_Class={false}.

После построения классов эквивалентности разрабатываются тестовые варианты. Тестовый вариант выбирается так, чтобы проверить сразу наибольшее количество свойств класса эквивалентности.

 

 

1.3 Способ анализа граничных  значений

 

Как правило, большая часть ошибок происходит на границах области ввода, а не в центре. Анализ граничных значений заключается в получении тестовых вариантов, которые анализируют граничные значения [3], [14], [69]. Данный способ тестирования дополняет способ разбиения по эквивалентности.

Основные отличия анализа граничных значений от разбиения по эквивалентности:

1) тестовые варианты создаются  для проверки только ребер  классов эквивалентности;

2) при создании тестовых вариантов  учитывают не только условия  ввода, но и область вывода.

Сформулируем правила анализа граничных значений.

1. Если условие ввода задает диапазон п...т, то тестовые варианты должны быть построены:

  • для значений п и т;
  • для значений чуть левее п и чуть правее т на числовой оси.

Например, если задан входной диапазон -1,0...+1,0, то создаются тесты для значений - 1,0, +1,0, - 1,001, +1,001.

2. Если условие ввода задает  дискретное множество значений, то создаются тестовые варианты:

  • для проверки минимального и максимального из значений;
  • для значений чуть меньше минимума и чуть больше максимума.

Так, если входной файл может содержать от 1 до 255 записей, то создаются тесты для О, 1, 255, 256 записей.

3. Правила 1 и 2 применяются к условиям  области вывода.

Рассмотрим пример, когда в программе требуется выводить таблицу значений. Количество строк и столбцов в таблице меняется. Задается тестовый вариант для минимального вывода (по объему таблицы), а также тестовый вариант для максимального вывода (по объему таблицы).

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

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

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

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

Предусловия:

1) массив должен быть упорядочен;

2) массив должен иметь не менее  одного элемента;

3) нижняя граница массива (индекс) должна быть меньше или равна  его верхней границе.

Постусловия:

1) если элемент найден, то флаг Result=True, значение I — номер элемента;

2) если элемент не найден, то  флаг Result=False, значение I не определено.

Для формирования классов эквивалентности (и их ребер) надо произвести разбиение области ИД — построить дерево разбиений. Листья дерева разбиений дадут нам искомые классы эквивалентности. Определим стратегию разбиения. На первом уровне будем анализировать выполнимость предусловий, на втором уровне — выполнимость постусловий. На третьем уровне можно анализировать специальные требования, полученные из практики разработчика. В нашем примере мы знаем, что входной массив должен быть упорядочен. Обработка упорядоченных наборов из четного и нечетного количества элементов может выполняться по-разному. Кроме того, принято выделять специальный случай одноэлементного массива. Следовательно, на уровне специальных требований возможны следующие эквивалентные разбиения:

Информация о работе Функциональное тестирование программного обеспечения