45919 (665225), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

программных средств сложно “переключиться” при тестировании созданной ими

продукции.

7

У Майерса сформулированы также основные принципы организации тестирования :

1) необходимой частью каждого теста должно являться описание

ожидаемых результатов работы программы, чтобыможно было быстро выяснить наличие

или отсутствие ошибки в ней ;

2) следует по возможности избегать тестирования программы ее

автором, т.к.кроме уже указанной объективной сложности тестирования для

программистов здесь присутствует и тот фактор, что обнаружение недостатков в

своей деятельностипротиворечит человеческой психологии ( однако отладка

программы эффективнее всего выполняется именно автором программы ) ;

3) по тем же соображениям организация - разработчик

программногообеспечения не должна “единолично ” его тестировать ( должны

существовать организации, специализирующиеся на тестировании программных средств

) ;

4) должны являться правилом доскональное изучение результатов

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

программе ;

5) необходимо тщательно подбирать тест не только для

правильных ( предусмотренных ) входных данных, но и для

неправильных(непредусмотренных) ;

6) при анализе результатов кождого теста необходимо

проверять, не делает ли программа того, что она недолжна делать ;

7) следует сохранять использованные тесты (для повышения

эффективности повторного тестированияпрограммы после ее модификации или

установки у заказчика) ;

8) тестирования не должно планироваться исходя из

предположения, что в программе не будутобнаружены ошибки (в частности, следует

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

9) следует учитывать так называемый “принцип скопления

ошибок” : вероятность наличия не обнаруженныхошибок в некоторой части программы

прямо пропорциональна числу ошибок, уже обнаруженных в этой части;

10) следует всегда помнить , что тестирование -

творческий процесс, а не относиться к немукак к рутинному занятию.

Существует два основных вида тестирования : функциональное и структурное. При

функциональномтестировании программа рассматривается как “черный ящик” (то есть

ее текст не используется). Происходит проверка соответствия поведения программы

ее внешнейспецификации. Возможно ли при этом полное тестирование программы ?

Очевидно , что критерием полнотытестирования в этом случае являлся бы перебор

всех возможных значений входных данных, что невыполнимо .

8

Поскольку исчерпывающее функциональное тестирование невозможно, речь может идти

о разработки методов,позволяющих подбирать тесты не “вслепую”, а с большой

вероятностью обнаружения ошибок в программе.

При структурном тестировании программа рассматривается как “белый ящик” (т.е.

ее текст открыт для пользования ).Происходит проверка логики программы. Полным

тестированием в этом случае будет такое, которое приведет к перебору всех

возможных путей на графе передачуправления программы (ее управляющем графе).

Даже для средних по сложности программ числом таких путей может достигать

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

то и в этом случае исчерпывающее структурное тестирование практически

невозможно, т. к. неясно, как подбиратьтесты , чтобы обеспечить “покрытие” всех

таких путей. Поэтому при структурном тестировании необходимо использовать другие

критерии его полноты, позволяющиедостаточно просто контролировать их выполнение,

но не дающие гарантии полной проверки логики программы.

Но даже если предположить, что удалось достичь полного структурного

тестированиянекоторой программы, в ней тем не менее могут содержаться ошибки,

т.к.

1) программа может не соответствовать своей внешней

спецификации, что в частности,может привести к тому, что в ее управляющем графе

окажутся пропущенными некоторые необходимые пути ;

2) не будут обнаружены ошибки, появление которых зависит от

обрабатываемых данных (т.е. на одних исходныхданных программа работает

правильно, а на других - с ошибкой).

Таким образом, ни структурное, ни функциональное тестирование не может быть

исчерпывающим. Рассмотрим подробнее основные этапы тестирования

программныхкомплексов.

В тестирование многомодульных программных комплексов можно выделить четыре

этапа:

1) тестирование отдельных модулей ;

2) совместное тестирование модулей ;

3) тестирование функций программного комплекса (т.е. поиск

различий между разработанной программой и ее внешней спецификацией ) ;

4) тестирование всего комплекса в целом (т.е. поиск несоответствия

созданного программного продукта сформулированнымранее целям проектирования,

отраженным обычно в техническом задании).

На первых двух этапах используются прежде всего методы структурного

тестирования, т.к.

на последующих этапах тестирования эти методы

использоватьсложнее из-за больших размеров проверяемого программного обеспечения

;

последующие этапы тестирования ориентированы на обнаружение

ошибок различного типа, которые необязательно связаны с логикой программы.

При тестировании как отдельных модулей, так и их комплексов должны быть решены

двезадачи :

1) построение эффективного множества тестов ;

2) выбор способа комбинирования (сборки) модулей при

создании трестируемого варианта программы .

СТРУКТУРНОЕ ТЕСТИРОВАНИЕ .

Поскольку исчерпывающее структурное тестирование невозможно, необходимо выбрать

такиекритерии его полноты, которые допускали бы их простую проверку и облегчали

бы целенаправленный подбор тестов.

Наиболее слабым из критериев полноты структурного тестирования является

требование хотябы однократного выполнения (покрытия) каждого оператора

программы.

Более сильным критерием является так называемый критерий С1 : каждая ветвь

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

большинства языков программирования покрытие переходов обеспечивает и

покрытиеоператоров, но , например, для программ на языке ПЛ/1 дополнительно к

покрытию всех ветвей требуется всех дополнительных точек входа в процедуру

(задаваемыхоператорами ENTRY) и всех ON - единиц.

Использование критерия покрытия условий может вызвать подбор тестов,

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

критерия С1 (например, в программе на языке Паскаль, использующей конструкцию

цикла WHILE х AND y DO... , применение критерия покрытия условий требует

проверки обоих вариантов выхода из цикла : NOT x и NOT y ).

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

переходов. Например, конструкция IF A AND BTHEN... требует по критерию покрытия

условий двух тестов (например, A=true, B=false и A=false, B=true ), при

которыхможет не выполняться оператор, расположенный в then - ветви оператора

if.

Практически единственным средством, предоставляемым современными системами

программирования, является возможность определения частоты выполнения

различныхоператоров программы (ее профилизации). Но с помощью этого инструмента

поддержки тестирования можно проверить выполнение только слабейшего из

критериевполноты - покрытие всех операторов.

Правда, с помощью этого же инструмента можно проверить и выполнение критерия С1.

Но дляэтого предварительно текст программы должен быть преобразован таким

образом, чтобы все конструкции условного выбора (IF и CASE

10

или SWITCH ) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае

всеветви алгоритма , не выполнявшиеся на данном тесте будут “видимы” из таблицы

частоты выполнения операторов преобразованной программы.

Актуальной остается задача создания инструментальных средств, позволяющих :

1) накапливать информации о покрытых и непокрытых ветвях для

всех использованных тестов ;

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

участки программы, облегчая выбор следующих тестов;

3) поддерживать более мощные критерии полноты структурного

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

Совместное тестирование модулей.

Известны два подхода к совместному тестированию модулей : пошаговое и монолитное

тестирование.

При монолитном тестировании сначала по отдельности тестируются все модули

программногокомплекса, а затем все они объединяются в рабочую программу для

комплексного тестирования.

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

набору ужепроверенных модулей.

В первом случае для автономного тестирования каждого модуля требуется модуль -

драйвер ( то естьвспомогательный модуль, имитирующий вызов тестируемого модуля)

и один или несколько модулей - заглушек ( то есть вспомогательных модулей,

имитирующихработу модулей, вызываемых из тестируемого). При пошаговом

тестировании модули проверяются не изолированно друг от друга, поэтому требуются

либо толькодрайверы, либо только заглушки.

А

BC D

E F

рис. 1

12

При сравнении пошагового и монолитного тестирования можно отметить следующие

преимущества первогоподхода :

1) меньшая трудоемкость (для примера на рис.1 при монолитном

тестировании требуются 5 драйверов и 5 заглушек; при пошаговом тестировании

требуются или только 5 драйверов - если модули подключаются “снизу вверх ”, -

или только 5 заглушек - если модули подключаются“сверху вниз”) ;

2) более раннее обнаружение ошибок в интерфейсах между

модулями (их сборка начинается раньше,чем при монолитном тестировании ) ;

3) легче отладка, то есть локализация ошибок (они в основном

связаны с последним из подключенных модулей) ;

4) более совершенны результаты тестирования (более

тщательная проверка совместного использованиямодулей).

Есть приемущества и у монолитного тестирования :

1) меньше расход машинного времени (хотя из-за большей

сложности отладки может потребоватьсядополнительная проверка программы и это

приемущество будет сведено на нет) ;

2) предоставляется больше возможностей для организации

параллельной работы на начальном этапетестирования.

В целом более целесообразным является выбор пошагового тестирования. При его

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

восходящая.

Нисходящее тестирование начинается с главного (или верхнего) модуля программы, а

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

уже протестированных. Одна из основных проблем , возникающих при

нисходящемтестировании, - создание заглушек. Это тривиальная задача, т. к. как

правило недостаточно, чтобы в заглушке выполнялся вывод

соответствующегоинформационного сообщенияи и возврат всегда одних и тех же

значений выходных данных.

Другая прблема , которую необходимо решать при нисходящем тестировании, - форма

представления тестов впрограмме, так как, как правило, главный модуль получает

входные данные не непосредственно, а через специальные модули ввода, которые при

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

тестов нужно или иметь несколько разных заглушек, или записать эти тесты в файл

во внешнейпамяти и с помощью заглушки считывать их.

Поскольку после тестирования главного модуля процесс проверки может продолжаться

по-разному,следует придерживаться следующих правил :

а) модули, содержащие операции ввода-вывода, должны подключаться к

тестированию как можно раньше ;

б) критические (т.е. наиболее важные ) для программы в

целом модули также должны тестироваться впервую очередь.

12

Основные достоинства нисходящего тестирования :

Характеристики

Список файлов реферата