Удачным считают тест, который обнаруживает хотя бы одну ошибку.
Существует два принципиально различных подхода к формированию тестов:
1). Структурный – известна структура тестируемого ПО, в том числе его алгоритмы. Тесты строят так, чтобы проверить правильность реализации заданной логики в ходе программы (белый ящик).
2). Функциональный – структура ПО неизвестна. Тесты строят по функциональным спецификациям (черный ящик; подход, управляемый данными).
На ранних стадиях разработки обычно используют ручной контроль. Все проектные решения, принятые на различных этапах, должны анализироваться с точки зрения их правильности и целесообразности, как можно раньше.
Различают статический и динамический подходы к ручному контролю. При статическом подходе анализируют структуру, упрощающую информационные связи программы, ее входные и выходные данные. При динамическом вручную моделируют процесс выполнения программы на заданных исходных данных. Исходными данными для таких проверок являются ТЗ, спецификация, структурная и функциональная схема ПО, схема отдельных компонентов и т.д.. Для более поздних этапов – это алгоритмы, тесты программы и тестовые наборы.
Тестирование (Python)
Основные методы ручного контроля:
1). Инспекции исходного текста,
2). Сквозные просмотры,
3). Проверка за столом,
4). Оценка программ.
Структурное тестирование.
Структурное тестированиеназывают также тестированием по «маршрутам», так как в этом случае тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутамипри этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных.
В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Так, если алгоритм программы включает ветвление, то при одном наборе исходных данных может быть выполнена последовательность операторов, реализующая действия, которые предусматривает одна ветвь, а при втором — другая. Соответственно, для программы будут существовать маршруты, различающиеся выбранным при ветвлении вариантом.
Считают, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам передач управления. Однако нетрудно видеть, что даже в программе среднего уровня сложности число неповторяющихся маршрутов может быть очень велико, и, следовательно, полное или исчерпывающее тестирование маршрутов, как правило, невозможно.
Структурный подход к тестированию имеет ряд недостатков. Так тестовые наборы, построенные по данной стратегии:
• не обнаруживают пропущенных маршрутов;
• не обнаруживают ошибок, зависящих от обрабатываемых данных, например, в операторе if (a — b) < eps — пропуск функции абсолютного значения abs проявится только, если а < b;
• не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию.
Консолидация (сборка) данных из нескольких таблиц в Excel
Формирование тестовых наборов для тестирования маршрутов может осуществляться по нескольким критериям:
• покрытие решений (переходов),
• комбинаторное покрытие условий.
Функциональное тестирование.
Одним из способов проверки программ является тестирование с управлением по данным или по принципу «черного ящика». В этом случае программа рассматривается как «черный ящик», и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствует спецификации.
Для обнаружения всех ошибок в программе, используя управление по данным, необходимо выполнить исчерпывающеетестирование, т. е. тестирование на всех возможных наборах данных. Для тех же программ, где исполнение команды зависит от предшествующих ей событий, необходимо проверить и все возможные последовательности. Очевидно, что проведение исчерпывающего тестирования для подавляющего большинства случаев невозможно. Поэтому обычно выполняют «разумное» или «приемлемое» тестирование, которое ограничивается прогонами программы на небольшом подмножестве всех возможных входных данных. Этот вариант не дает гарантии отсутствия отклонений от спецификаций.
Правильно выбранный тест должен уменьшать, причем более чем, на единицу, число других тестов, которые должны быть разработаны для обеспечения требуемого качества программного обеспечения.
При функциональном тестировании различают следующие методы формирования тестовых наборов:
• анализ граничных значений;
• анализ причинно-следственных связей;
• предположение об ошибке.
Восходящее и нисходящее тестирование
Восходящее тестирование.
Восходящий подход предполагает, что каждый модуль тестируют отдельно на соответствие имеющимся спецификациям на него, затем собирают оттестированные модули в модули более высокой степени интеграции и тестируют их. При этом проверяют межмодульные интерфейсы, используемые для подключения модулей более низкого уровня иерархии. И так далее, пока не будет собран весь программный продукт (рис. 8.1.).
Рис. 8.1. Тестирование программного обеспечения при восходящем подходе: а — автономное тестирование модулей нижнего уровня; б – тестирование следующего уровня.
Такой подход обеспечивает полностью автономное тестирование, для которого просто генерировать тестовые последовательности, которые передаются в модуль напрямую. Однако он имеет и существенные недостатки. Во-первых, при восходящем тестировании так же, как при восходящем проектировании, серьезные ошибки в спецификациях, алгоритмах и интерфейсе могут быть обнаружены только на завершающей стадии работы над проектом. Во-вторых, для того, чтобы тестировать модули необходимо разработать специальные тестирующие программы, которые обеспечивают вызов интересующих нас модулей с необходимыми параметрами. Причем эти тестирующие программы также могут содержать ошибки.
Нисходящее тестирование.
В этом случае автономно тестируется только основной модуль. При его тестировании все вызываемые им модули заменяют модулями, которые в той или иной степени имитируют поведение вызываемых модулей. Такие модули принято называть «заглушками». В отличие от тестирующих программ заглушки очень просты, например, они могут просто фиксировать, что им передано управление.
Часто заглушки просто возвращают какие-либо фиксированные данные. Как только тестирование основного модуля завершено, к нему подключают модули, непосредственно им вызываемые, и необходимые заглушки, а затем проводят их совместное тестирование. Далее последовательно подключают следующие модули, пока не будет собрана вся система (рис. 8.2).
Рис 8.2. Начальные этапы тестирования: а – основного модуля, б – двух модулей.
Основной недостатокнисходящего тестирования — отсутствие автономного тестирования модулей.
Основным достоинством данного метода является ранняя проверка основных решений и качественное многократное тестирование сопряжения модулей в контексте программного обеспечения. При нисходящем тестировании есть возможность согласования с заказчиком внешнего вида (интерфейса) программного обеспечения.
Классификация ошибок
Отладка — это процесс локализации и исправления ошибок, обнаруженных при тестировании программного обеспечения. Локализацией называют процесс определения оператора программы, выполнение которого вызвало нарушение нормального вычислительного процесса. Для исправления ошибки необходимо определить ее причину, т. е. определить оператор или фрагмент, содержащие ошибку. Причины ошибок могут быть как очевидны, так и очень глубоко скрыты.
В соответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 9.1):
синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы;
ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;
ошибки выполнения — ошибки, обнаруженные операционной системой, аппаратными средствами или пользователем при выполнении программы.
Рис. 9.1. Классификация ошибок по этапу обработки программы
Синтаксические ошибки.
Синтаксические ошибки относят к группе самых простых, так как синтаксис языка, как правило, строго формализован, и ошибки сопровождаются развернутым комментарием с указанием ее местоположения. Определение причин таких ошибок, как правило, труда не составляет, и даже при нечетком знании правил языка за несколько прогонов удается удалить все ошибки данного типа.
Следует иметь в виду, что чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок будет обнаруживаться на следующих этапах. В связи с этим говорят о языках программирования с защищенным синтаксисом и с незащищенным синтаксисом. К первым, безусловно, можно отнести Pascal, ко вторым — С со всеми его модификациями.
Ошибки компоновки.
Ошибки компоновки, как следует из названия, связаны с проблемами, обнаруженными при разрешении внешних ссылок. Например, предусмотрено обращение к подпрограмме другого модуля, а при объединении модулей данная подпрограмма не найдена или не стыкуются списки параметров. В большинстве случаев ошибки такого рода также удается быстро локализовать и устранить.
Ошибки выполнения.
К самой непредсказуемой группе относятся ошибки выполнения. Прежде всего они могут иметь разную природу, и соответственно по-разному проявляться. Часть ошибок обнаруживается и документируется операционной системой. Выделяют четыре способа проявления таких ошибок:
• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд,
• появление сообщения об ошибке, обнаруженной операционной системой,
• несовпадение полученных результатов с ожидаемыми.
Причины ошибок выполнения очень разнообразны, а потому и локализация может оказаться крайне сложной. Все возможные причины ошибок можно разделить на следующие группы:
• неверное определение исходных данных,
• накопление погрешностей результатов вычислений.
Неверное определение исходных данных происходит, если возникают любые ошибки при выполнении операций ввода-вывода.
Логические ошибки имеют разную природу. Так они могут следовать из ошибок, допущенных при проектировании, например, при выборе методов, разработке алгоритмов или определении структуры классов, а могут быть непосредственно внесены при кодировании модуля. К последней группе относят:
• ошибки некорректного использования переменных,
• ошибки межмодульного интерфейса,
• другие ошибки кодирования.
Накопление погрешностей результатов числовых вычислений возникает, например, при некорректном отбрасывании дробных цифр чисел, некорректном использовании приближенных методов вычислений, игнорировании ограничения разрядной сетки представления вещественных чисел в ЭВМ и т. п.
Последнее изменение этой страницы: 2018-05-27; просмотров: 254.
stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда.
Источник: stydopedya.ru
ТЕСТИРОВАНИЕ ПРОГРАММЫ
Структурное тестирование программного обеспечения методом «черного» ящика.
Тестирование — процесс выполнения программы с целью обнаружения ошибок. Шаги процесса задаются тестами.
Каждый тест определяет:
1. Свой набор исходных данных и условий для запуска программы;
2. Набор ожидаемых результатов работы программы.
Другое название теста — тестовый вариант. Полную проверку программы гарантирует исчерпывающее тестирование. Оно требует проверить все наборы исходных данных, все варианты их обработки и включает большое количество тестовых вариантов. Увы, но исчерпывающее тестирование во многих случаях остается только мечтой — срабатывают ресурсные ограничения (прежде всего, ограничения по времени).
Хорошим считают тестовый вариант с высокой вероятностью обнаружения еще не раскрытой ошибки. Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку.
Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.
Важен ответ на вопрос: что может тестирование?
1. обнаружение ошибок;
2. демонстрацию соответствия функций программы ее назначению;
3. демонстрацию реализации требований к характеристикам программы;
4. отображение надежности как индикатора качества программы.
А чего не может тестирование? Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов). Важно помнить это (скорее печальное) утверждение при проведении тестирования.
Рассмотрим информационные потоки процесса тестирования. Они показаны на рис. 1.
Рисунок 4.1 – Информационные потоки процесса тестирования
На входе процесса тестирования три потока:
1. Текст программы;
2. Исходные данные для запуска программы;
3. Ожидаемые результаты.
Выполняются тесты, все полученные результаты оцениваются. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами. Когда обнаруживается несовпадение, фиксируется ошибка — начинается отладка. Процесс отладки непредсказуем по времени. На поиск места дефекта и исправление может потребоваться час, день, месяц.
Неопределенность в отладке приводит к большим трудностям в планировании действий.
После сбора и оценивания результатов тестирования начинается отображение качества и надежности ПО. Если регулярно встречаются серьезные ошибки, требующие проектных изменений, то качество и надежность ПО подозрительны, констатируется необходимость усиления тестирования. С другой стороны, если функции ПО реализованы правильно, а обнаруженные ошибки легко исправляются, может быть сделан один из двух выводов:
1. качество и надежность ПО удовлетворительны;
2. тесты не способны обнаруживать серьезные ошибки.
В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).
Результаты, накопленные в ходе тестирования, могут оцениваться и более формальным способом. Для этого используют модели надежности ПО, выполняющие прогноз надежности по реальным данным об интенсивности ошибок.
Существуют 2 принципа тестирования программы:
1. функциональное тестирование (тестирование «черного ящика»);
2. структурное тестирование (тестирование «белого ящика»).
Понятие о структурном программировании.
Структурное тестирование называют также тестированием по «маршрутам», так как в этом случае тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутами при этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных.
В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Так, если алгоритм программы включает ветвление, то при одном наборе исходных данных может быть выполнена последовательность операторов, реализующая действия, которые предусматривает одна ветвь, а при втором — другая. Соответственно, для программы будут существовать маршруты, различающиеся выбранным при ветвлении вариантом.
Считают, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам передач управления. Однако нетрудно видеть, что даже в программе среднего уровня сложности число неповторяющихся маршрутов может быть очень велико, и, следовательно, полное или исчерпывающее тестирование маршрутов, как правило, невозможно.
Структурный подход к тестированию имеет ряд недостатков. Так тестовые наборы, построенные по данной стратегии:
• не обнаруживают пропущенных маршрутов;
• не обнаруживают ошибок, зависящих от обрабатываемых данных;
• не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию.
Для формирования тестов программу представляют в виде графа, вершины которого соответствуют операторам программы, а дуги представляют возможные варианты передачи управления. Ниже приведен текст программы, которая определяет значение х в зависимости от значений параметров процедуры.
Тестовые требования:
1. Проверить, что для графы «Номер» функция записи возвращает правильное значение.
2. Проверить, что программа проверяет тип записываемых данных в графу «Номер».
3. Проверить, что для графы «Фирма» функция записи возвращает правильное значение.
4. Проверить, что для графы «Фамилия» функция записи возвращает правильное значение.
5. Проверить, что для графы «Имя» функция записи возвращает правильное значение.
6. Проверить, что для графы «Отчество» функция записи возвращает правильное значение.
7. Проверить, что для графы «Адрес» функция записи возвращает правильное значение.
8. Проверить, что для графы «Телефон» функция записи возвращает правильное значение.
9. Проверить, что программа проверяет тип записываемых данных в графу «Телефон».
10. Проверить, что при нажатии кнопки «Добавить», функция производит правильные действия, и данные корректно добавляются в таблицу.
11. Проверить, что при нажатии кнопки «Сохранить» функция производит правильные действия.
12. Проверить, что при нажатии кнопки «Удалить» функция очищает выбранную строку таблицы, не затрагивая другие данные.
Таблица 3 – Результаты тестирования.
| № | Входные данные | Ожидаемый результат | Полученный результат | Номер теста | Примечания |
| Корректный ввод | |||||
| двадцать | двадцать | — | Ошибка, вводится неправильный тип данных | ||
| Чемпион | Чемпион | Чемпион | Корректный ввод | ||
| Огурчикова | Огурчикова | Огурчикова | Корректный ввод | ||
| Любовь | Любовь | Любовь | Корректный ввод | ||
| Валентиновна | Валентиновна | Валентиновна | Корректный ввод | ||
| г. Владимир, ул. Тимерязева, д. 123 | г. Владимир, ул. Тимерязева, д. 123 | г. Владимир, ул. Тимерязева, д. 123 | Корректный ввод | ||
| Корректный ввод | |||||
| телефон | телефон | — | Ошибка, вводится неправильный тип данных |
Источник: megaobuchalka.ru
Презентация на тему Составление наборов тестовых данных для структурного тестирования. Стратегия белого ящика
Тестирование по маршрутам При использовании стратегии «белого ящика» тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутами при этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных.
- Главная
- Информатика
- Составление наборов тестовых данных для структурного тестирования. Стратегия белого ящика
Слайды и текст этой презентации
Слайд 1 Практическая работа. Составление наборов тестовых данных для структурного тестирования.
Стратегия «белого ящика»
МДК.05.03
Слайд 2 Тестирование по маршрутам
При использовании стратегии «белого ящика» тестовые
наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутами
при этом понимают последовательности операторов программы, которые выполняются при конкретном
варианте исходных данных.
Слайд 3 Последовательность составления тестов
1. На основе алгоритма (текста)
программы формируется потоковый граф (или граф-схема).
2. Выбирается критерий
тестирования.
3. Подготавливаются тестовые варианты, инициирующие выполнение каждого пути. Каждый
тестовый вариант формируется в следующем виде:
Исходные данные
Ожидаемые результаты
Слайд 4 Потоковый граф
Узлы (вершины) потокового графа соответствуют линейным участкам
программы.
Дуги (ориентированные ребра) потокового графа отображают поток управления
в программе (передачи управления между операторами).
Различают операторные и предикатные
узлы.
Из операторного узла выходит одна дуга, а из предикатного − две дуги.
Предикатные узлы соответствуют простым условиям в программе.
if a OR b then x else у end if.
Слайд 5 Цикломатическая сложность
Число независимых линейных путей в базовом множестве
определяется цикломатической сложностью алгоритма, которая вычисляется одним из способов:
1) Цикломатическая сложность V(G) равна количеству регионов потокового графа; Регион
— замкнутая область, образованная дугами и узлами. Окружающая граф среда рассматривается как дополнительный регион. Например, показанный на предыдущем слайде граф имеет три региона − R1, R2, R3;
2) Цикломатическая сложность определяется по формуле:
V(G) = E-N+2, где Е − количество дуг, N − количество узлов потокового графа;
3) Цикломатическая сложность V(G) = р +1, где р – количество предикатных узлов G.
(Примечание Предлагается выполнять расчет по 2 или 3 способу)
Слайд 6 Пример 1
Цикломатическая сложность алгоритма на рисунке:
1) V(G) =
3 региона;
2) V(G) = 7 дуг — 6
узлов + 2 = 3;
3) V(G) = 2 предикатных
узла + 1 = 3.
Независимые пути:
Путь 1: а — х – end if.
Путь 2: а — b — х – end if.
Путь 3: а — b — y – end if.
Слайд 7 Критерии покрытия
1. Критерий покрытия операторов подразумевает такой подбор
тестов, чтобы каждый оператор программы выполнялся, по крайней мере,
один раз. Это необходимое, но недостаточное условие для приемлемого тестирования.
2. Критерий покрытия решений (переходов) должен иметь такое количество и состав тестов, чтобы результат проверки каждого условия принимал значения «истина» или «ложь», по крайней мере, один раз. Критерий покрытия решений удовлетворяет критерию покрытия операторов, но является более «сильным».
3. Критерий покрытия условий является еще более «сильным» по сравнению с предыдущими. В этом случае формируют некоторое количество тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении были выполнены, по крайней мере, один раз. К этому критерию требуется дополнение, заключающееся в том, что каждой точке входа управление должно быть передано, по крайней мере, один раз.
Согласно покрытию решений/условий тесты должны составляться так, чтобы, по крайней мере, один раз выполнились все возможные результаты каждого условия и все результаты каждого решения, и каждому оператору управление передавалось, по крайней мере, один раз.
4. Критерий «Комбинаторное покрытие условий» требует создания такого множества тестов, чтобы все возможные комбинации результатов условий в каждом решении и все операторы выполнялись, по крайней мере, один раз.
Источник: mypreza.com