Документ предоставляется как есть, мы не несем ответственности, за правильность представленной в нём информации. Используя информацию для подготовки своей работы необходимо помнить, что текст работы может быть устаревшим, работа может не пройти проверку на заимствования.
Если Вы являетесь автором текста представленного на данной странице и не хотите чтобы он был размешён на нашем сайте напишите об этом перейдя по ссылке: «Правообладателям»
Можно ли скачать документ с работой
Да, скачать документ можно бесплатно, без регистрации перейдя по ссылке:
Лабораторная работа №3
Проектирование тестовых наборов данных
Цель работы: ознакомиться с методами разработки тестов для программ различного функционального назначения.
Применительно к ПО тестирование – это процесс многократного выполнения программы с целью обнаружения ошибок.
Тестирование программ является одной из составных частей более общего понятия – «отладка программ».Если тестирование – это процесс, направленный на выявление ошибок, то целью отладки является локализация и исправление выявленных в процессе тестирования ошибок.
Тестирование НА ПРИМЕРЕ | Тестирую DEVBY
Процесс отладки включает
• действия, направленные на выявление ошибок – тестирование;
• диагностику и локализацию ошибок;
• внесение исправлений в программу с целью устранения ошибок.
Из этих видов работ самым трудоемким и дорогим является тестирование, затраты на которое для типичных ПИ приближаются к 40% общих затрат на разработку.
Методы проектирования тестовых наборов данных
Наиболее эффективным методом тестирования является детерминированное тестирование, при котором известны и контролируются каждая комбинация исходных данных и соответствующие ей результаты исполнения программы [1].
Детерминированное тестирование, или тестирование на определенных входных значениях, основывается на двух подходах: структурное тестирование (СТ) и функциональное тестирование (ФТ).
Структурное тестирование, или тестирование программ как «белого ящика» (стратегия тестирования, управляемого логикой программы), предполагает детальное изучение текста (логики ) программы и построение (подбор) таких входных наборов данных, которые позволили бы при многократном выполнении программы на ЭВМ обеспечить выполнение максимально возможного количества маршрутов, логических ветвлений, циклов и т.д.
Функциональное тестирование, или тестирование программ как «черного ящика» (тестирование по входу–выходу), полностью абстрагируется от логики программы, предполагается, что программа – «черный ящик», а тестовые наборы выбираются на основании анализа входных функциональных спецификаций.
Для успешного и качественного проведения детерминированного тестирования необходимо разработать эффективные тестовые наборы данных.
Понятие «эффективного» тестового набора данных связано с невозможностью «полного» тестирования программы.
Тестирование для дегенератов
В качестве примера рассмотрим фрагмент простого участка программы который представлен графом вида
(рис.1). Каждая вершина графа – это линейный участок программы, заканчивающийся оператором ветвления. Дуги указывают на передачу управления. Граф описывает программу из 10–12 операторов, включая цикл, который выполняется не менее 20 раз.
Если предположить, что выполнение каждой ветви этого участка исключает одновременное выполнение других ветвей, то учитывая количество циклических повторений, число тестов для проверки этого участка будет равно 6*20=120.
Т.К. тестируемые программы состоят из множества подобных или более сложных участков, то исчерпывающее тестирование маршрутов не только не выполнимо, но и невозможно.
Если ввести ограничения на время, стоимость, машинное время и т. п., то основным вопросом детерминированного тестирования становится вопрос о том, какое подмножество всех возможных тестов имеет наибольшую вероятность обнаружения большего количества ошибок.
Подмножество всех возможных тестов, которое обладает этим свойством, называется эффективным.
Для разработки эффективного тестового набора рекомендуется знать методы его построения и придерживаться определенных правил.
При построении тестовых наборов данных по принципу «белого ящика» руководствуются следующими критериями: покрытие операторов, покрытие узлов ветвления, покрытие условий, комбинаторное , покрытие условий. Рассмотрим подробнее каждый из перечисленных критериев.
Покрытие операторов. Этот критерий предполагает выбор такого тестового набора данных, который вызывает выполнение каждого оператора в программе хотя бы один раз. Критерий очень слабый и не достаточен для тестирования.
Покрытие узлов ветвления (покрытие решений). По этому критерию разрабатывается такое количество тестов, чтобы в каждом узле ветвления был обеспечен переход по веткам «истина » и «ложь» хотя бы один раз.
Покрытие условий. Если узел ветвления содержит более одного условия (рис 2), тогда нужно разработать столько тестов, чтобы возможные результаты выполнения каждого условия получались, по крайней мере один раз.
Однако рассмотренные критерии недостаточно чувствительны к ошибкам в логических выражениях.
Комбинаторное покрытие условий. Для обнаружения таких ошибок используют Комбинаторное , покрытие условий. В нашем примере (рис.2) по этому критерию надо покрыть тестами следующие 4 комбинации:
Тесты:
При построении тестов по стратегии «черного ящика» программа рассматривается как «черный ящик», т.е. не известны текст программы и ее логика, а исходной информацией для тестовых наборов служат ее спецификации.
К стратегии «черного ящика» относятся методы:
• эквивалентного разбиения;
• анализ граничных значений;
• функциональных диаграмм.
Метод эквивалентного разбиения. Построение тестов этим методом осуществляется в два этапа: 1)выделение классов эквивалентности; 2)построение тестов.
Классом эквивалентности называется множество входных значений, каждое из которых имеет одинаковую вероятность обнаружения конкретного типа ошибки.
Классы эквивалентности выделяются путем анализа входного условия и разбиением его на две или более групп. Для любого условия существуют правильный (представляющий правильные входные данные программы) и неправильный, т.е. представляющий ошибочные входные значения, классы эквивалентности.
При выделении классов эквивалентности целесообразно придерживаться следующих правил.
1. Если входное условие описывает область значений (например, идентификатор метки может содержать от одного до восьми символов), то определяются один правильный класс эквивалентности (1 2. Если входное условие описывает конечное число конкретных значений и есть основание полагать, что каждое значение программа трактует особо (например, способ передачи информации между городами допустим — –очтовый, телеграфный, телетайпный), то определяются правильный класс эквивалентности для каждого значения и один неправильный класс эквивалентности (например, курьерный).
3. Если входное условие описывает ситуацию «должно быть» (например, «первым символом идентификатора должна быть буква»), то определяются один правильный класс эквивалентности и один неправильный. На основе классов эквивалентности строятся тестовые наборы. Причем для правильных классов эквивалентности нужно стремиться к минимальному числу тестовых наборов, т.е. каждый тест должен покрывать по возможности большее число правильных классов эквивалентности.
Для каждого неправильного класса эквивалентности строится хотя бы один тестовый набор.
– тождество, устанавливает: если а=1, то b=1; если а=0, то и b=0
–
–
– не устанавливает: если а=1, то b=0; если а=0, то b=1
– или устанавливает: если а=1, или b=1, или с=1, то d=1, в противном случае d=0
– и устанавливает: если а=1, и b=1, и с=1, то и d=1, в противном случае d=0
– –
–
Диаграмма снабжается примечаниями, задающими ограничения и описывающими комбинации причин и (или) следствий, которые являются невозможными из-за синтаксических или внешних ограничений.
Используются следующие ограничения:
• Ограничение Е (исключает) устанавливает, что а и b не могут принимать значение 1 одновременно
• Ограничение I (включает) устанавливает, что по крайней мере одна из величин a,b и c не может принимать 0-е значение одновременно
• Ограничение О (одно и только одно) устанавливает, что одна и только одна из величин a или bдолжна быть равна 1
• Ограничение R (требует) устанавливает, что если а=1, то и b=1
• Ограничение М (скрывает) является ограничением для следствий и устанавливает, что если следствие а имеет значение 1, то следствие b должно принять значение 0
По полученной функциональной диаграмме строится таблица решений. Для этого поочередно для каждого следствия, значение которого условно устанавливается в 1, прослеживается обратный путь (по диаграмме) ко всем причинам, связанным с этим следствием, и фиксируется их состояние. Каждый столбец таблицы решений соответствует тесту.
Столбцы решений преобразуются в тесты.
Методом функциональных диаграмм составить тестовый набор для программы, которая осуществляет контроль записей файла, содержащего информацию о студентах института заочной формы обучения (первые две позиции каждой записи могут принимать значения «ЗМ» или «ЗС»), и осуществляет формирование двух файлов по факультетам соответственно ОФЭИ статистика (FM,FC).
В случае ошибки в первой позиции выдается сообщение : «Ошибка в первой позиции», ошибка во второй позиции вызывает сообщение «Ошибка во второй позиции записи».
1. Выделяем причины и следствия и присваиваем им номера.
Причины:
1 – буква «З» в первой позиции;
2 – буква «М» во второй позиции;
3 – буква «С» во второй позиции.
Следствия:
20 – формирование файла FM;
21 – формирование файла FC;
22 – сообщение «ошибка в первой позиции «;
23 – сообщение «ошибка во второй позиции «.
2.Строится функциональная диаграмма, связывающая эти причины и следствия.
Для наглядности графа при построении используются промежуточные вершины 10, 11, 12.
3.Полученный граф снабжается ограничениями: действительно, причины 2 и 3 не могут выполняться одновременно.
4.Строим таблицу решений по графу. Для этого фиксируем в состоянии «1» (истина) поочередно все следствия. Например, следствие 22 будет в состоянии «1» только в том случае, если причина 1, с которой она связана, находится в состоянии «0». Следствие 20 будет в состоянии «1», если промежуточная вершина 10 будет в состоянии «1». Она, в свою очередь, будет находиться в состоянии «1» только в одном случае, когда причина 1 в состоянии «1» и причина 2 в состоянии «1» одновременно, так как связаны логическим И.
Фиксируем в состоянии «1» (истина) следствие 21. Она «тождеством» связана с промежуточной вершиной 11, значит, и 11 находится в состоянии «1». Это возможно в единственном случае, когда причины 1 и 3 находятся в состоянии «1». Вершина, не влияющая на состояние данного следствия (в конкретном случае 2), отмечается в таблице решений черточкой.
Если следствие 23 находится в состоянии «1», то промежуточная вершина 12 должна быть в состоянии «0», т. к. они связаны отношением НЕ. Это возможно в случае , когда обе причины 2 3 находятся в состоянии «0», т. е. во второй позиции стоит буква «М», а не буква «С».
5.Переходим от таблицы решений к тестовым наборам. Каждый столбец решений соответствует одному тесту. Причем «1» означает выполнение соответствующей причины, а «0» – невыполнение. Прочерк в столбце таблицы решений указывает, что эта причина не влияет на значение следствия.
Тестовые наборы
1. АМ….
2. ЗМ…..
3. ЗС……
4. ЗА……
Каждый из рассмотренных методов обеспечивает создание определенного набора тестов, но ни один из них сам по себе не может дать исчерпывающий набор тестов. Поэтому при разработке тестовых наборов следует придерживаться стратегии разумного сочетания всех рассмотренных методов.
1. Построить функциональную диаграмму для анализируемой программы.
2. Спроектировать таблицу решений.
3. Сформировать наборы тестов для анализируемой программы, позволяющие проверить ее функционирование по важнейшим маршрутам.
4. Оформить отчет по лабораторной работе, который должен содержать следующее:
• наименование и цель работы;
• список причин и следствий для анализируемой программы;
• функциональную диаграмму;
• тестовые наборы;
• результаты сравнительного анализа методов тестирования программы по принципу «черного ящика» и с использованием детерминированного подхода.
Вопросы к лабораторной работе №3
1. В чем состоит метод детерминированного тестирования?
2. Как можно применить результаты лабораторных работ №1 и №2 для детерминированного тестирования?
3. Чем принципиально отличаются представления программного продукта как «белого ящика» и «черного ящика»?
4. Какие методы проектирования тестов относятся к методам «черного ящика»?
5. Насколько эффективным, по–вашему, является применение метода функциональных диаграмм для проектирования тестов программы, анализируемой Вами?
Литература
1. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник/В.А.Благодатских, М.А.Енгибарян, Е.А.Ковалевская и др. – М.: Финансы и статистика, 1995. – 288 с.: ил.
Источник: www.sesiya.ru
6.5 Тестирование
Тестирование программ является одной из составных частей более общего понятия – «отладка программ». Под отладкой понимается процесс, позволяющий получить программу, функционирующую с требующимися характеристиками в заданной области изменения входных данных.
Процесс отладки включает (рис. 6.5):
- действия, направленные на выявление ошибок (тестирование);
- диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);
- внесение исправлений в программу с целью устранения ошибок.
Из трех перечисленных видов работ самым трудоемким и дорогим является тестирование, затраты на которое для типичных ППП приближаются к 45% общих затрат на разработку. Программы как объекты тестирования имеют ряд особенностей, которые отличают процесс их тестирования от общепринятого, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПИ являются:
- отсутствие эталона (программы), которому должна соответствовать тестируемая программа;
- высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;
- практическая невозможность создания единой методики тестирования (формализация процесса тестирования) в силу большого разнообразия ПИ по их сложности, функциональному назначению, области использования и т.д.
Тестирование – это процесс многократного выполнения программы с целью выявления ошибок. Целью тестирования является обнаружение максимального числа ошибок. Поэтому тестовый прогон, в результате которого не выявлено ошибок, считается неудачным (неэффективным). Существуют несколько эмпирических правил проведения тестирования программ, обобщающих опыт тестировщиков. 1. Процесс тестирования более эффективен, если проводится не автором программы. Дело в том, что по своей сути тестирование – это процесс деструктивный (разрушительный). Именно этим и объясняется, почему многие считают его трудным. Особенно трудным и малоэффективным он является для самого автора программы, так как после выполнения конструктивной части при проектировании и написания программы, ему трудно перестроиться на деструктивный образ мышления и, создав программу, тут же приступить к пристрастному выявлению в ней ошибок. Поэтому для проведения тестирования создаются специальные группы тестирования (рис. 6.3). Это не означает, что программист не может тестировать свою программу. Речь идет о повышении эффективности тестирования. 2. Необходимой частью тестового набора данных должно являться описание предполагаемых значений результатов тестовых прогонов. Тестирование как процесс многократного выполнения программы проводится на многочисленных входных наборах данных. Чтобы определить правильность полученных в результате очередного тестового прогона данных, необходимо знать ожидаемый результат, иначе правдоподобные результаты тестового прогона могут быть признаны правильными. Таким образом, тестовый набор данных должен включать в себя два компонента: описание входных данных, описание точного и корректного результата, соответствующего набору входных данных. Этот принцип довольно сложно, а в некоторых случаях даже невозможно, реализовать на практике. Сложность его заключается в том, что при тестировании программы (модуля) необходимо для каждого входного набора данных рассчитать вручную ожидаемый результат или найти допустимый интервал изменения выходных данных. Процесс этот очень трудоемкий даже для небольших программ, так как он требует ручных расчетов, следуя логике алгоритма программы. Из рассмотренного принципа, который трудно реализуем, но которого следует придерживаться логически, вытекает следующий. 3. Необходимо досконально изучить результаты применения каждого теста. Из практики видно, что значительная часть всех обнаруженных в конечном итоге ошибок могла быть выявлена в результате самых первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа результатов первых тестовых прогонов. 4. Тесты для неправильных и непредусмотренных входных данных должны разрабатываться также тщательно, как для правильных, предусмотренных. Согласно этому принципу при обработке данных, выходящих за область допустимых значений, в тестируемой программе должна быть предусмотрена диагностика в виде сообщений. Если сообщение о причине невозможности обработки по предложенному алгоритму отсутствует и программа завершается аварийно или ведет себя непредсказуемо, то такая программа не может считаться работоспособной и требует существенной доработки. Тестовые наборы данных из области недопустимых входных значений обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным. 5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать. Это утверждение логически вытекает из предыдущего. Необходимо любую программу проверить на нежелательные побочные эффекты. 6. Следует тщательнее проверять те участки программ, где обнаруживается больше ошибок. Утверждается, что вероятность наличия необнаруженных ошибок в какой-либо части программы пропорциональна числу ошибок, уже обнаруженных в этой части. Дело в том, что те части программы, где при тестировании обнаружено большее число ошибок, либо были слабо проработаны с точки зрения системного анализа, либо разрабатывались программистами более низкой квалификации.
Источник: studfile.net
Презентация, доклад Тестирование программных средств
Вы можете изучить и скачать доклад-презентацию на тему Тестирование программных средств. Презентация на заданную тему содержит 27 слайдов. Для просмотра воспользуйтесь проигрывателем, если материал оказался полезным для Вас — поделитесь им с друзьями с помощью социальных кнопок и добавьте наш сайт презентаций в закладки!
Презентации » Информатика » Тестирование программных средств
>»>