Файл: Отладка и тестирование программ: основные подходы и ограничения (Разработка проекта тестирования программы «Помощник администратора»).pdf

Главный минус такого типа тестировать- необходимость написания особого кода-оболочки, который и вызывает тестируемый модуль. В том случае, если он вызывает не тот модуль, требуется написание заглушки. Заглушка представляет собой имитацию вызываемой функции, которая возвращает данные и ничего более. [16]

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

Хороший набор оболочек и заглушек тоже является эффективным инструментом тестирования.

В противовес такой модели тестирования, согласно стратегии целостного тестирования, для полного интегрирования системы не нужно тщательно тестировать обособленные модули.

Главное достоинство стратегии то, что можно не писать дополнительный код. По этой причине довольно часть предпочтение отдается именно этому методу, ведь лучше провести разработку 1 большого набора тестов и им осуществлять проверку системы. Однако, это в корне неверно и ниже описано по какой причине.

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

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

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

Очевидно, что в процессе разработки происходит ежедневное изменение ПП и нужно снова ее тестировать и так до бесконечности. В свою очередь наличие оболочек и заглушек дает возможность систематизации этого муторного и однообразного труда[18].

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

Обе такие технологии именую инкрементальными.

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

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

ГЛАВА 2. СТРАТЕГИЯ ТЕСТИРОВАНИЯ И ОТЛАДКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Метод Сандвича

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

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

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

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

Модифицированный метод сандвича.

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

2.2 Метод «белого ящика»

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

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

- предоставление гарантии на то, что все независимые пути в модуле проверены минимум единожды;

- осуществляется проверка логических решений относительно ложности и истины.

- исполняет весь комплекс внутри операционных границ и с использованием граничных значений.

- Исследуют структуры внутренних данных с целью проверки их достоверности.[2,c.312]

Тестирование при помощи белого ящика включает в себя стратегию модульного тестирования, при котором тестирование ведется на модульном или функциональном уровне и работы по тестированию направлены на исследование внутреннего устройства модуля. Такое тестирование именуется модульным прозрачного ящика, на англ. clear box, или же, прозрачным, на англ. Translucent. С учетом того, что те сотрудники, которые заняты тестирование, имеют полный доступ к коду, они могут наблюдать за работой программы внутри самой программы. Нередко такое тестирование называется структурным.

На данном этапе идет проверка управляющей логики, которая проявляется еще на модульном уровне. Использование тестовых драйверов нужно для того, чтобы все пути в данном модуле хотя бы 1 раз прошли проверку, а все решения логического порядка удалось рассмотреть при любых условиях, цикл был исполнен при применении верхней и нижней границы, а так же все структуры внутренних данных .были проконтролированы.[4,c.775]

Методы тестирования на основе стратегии белого ящика:

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

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

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

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

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

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

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

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

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

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

- Покрытие решений. Этот метод ориентирован ан то, чтобы в % соотношении определить весь спектр возможных последствий или исходов решений, которые уже подверглись проверке. Такой метод довольно части причисляют к покрытию ветвей и именуют С2. Для его осуществления нужно: чтобы каждая точка входа и выхода в программе была пройдена 1 или более раз, чтобы весь перечень вероятных условий был протестирован 1 или более раз, а так же обязательным является тестировании и использование всего спектра вероятных исходов.