практические работы. Методические указания к лабораторной работе (1). Федерации федеральное агентство по образованию государственное

• Название: Федерации федеральное агентство по образованию государственное
• Анкор: практические работы
• Дата: 03.09.2022
• Размер: 0.67 Mb.
• Имя файла: Методические указания к лабораторной работе (1).docx
• Тип: Документы; #660107
• страница: 9 из 10

Тестирование и отладка

1. Виды ошибок

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

1.Отсутствие заданий начальных значений переменных. 2.Неверные условия окончания цикла.

3. 
   Неверную индексацию цикла.
   
4. 
   Отсутствие задания условий инициирования цикла. 5.Неправильное указание ветви алгоритма для продолжения процесса
   

решения задачи.

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

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

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

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

−пропуск некоторых операторов.

−отсутствие необходимых данных.

−непредусмотренные данные.

−неверный формат данных.

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

2. Отладка и тестирование

Отладкапрограммного средства (ПС) − это деятельность, направленная на обнаружение и исправление ошибок в программе с использованием процес- сов выполнения его программ.

Тестирование ПС − это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или из- вестны правила поведения этих программ. Указанный набор данных называет- ся тестовым или просто тестом.

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

Отладка=Тестирование+Поискошибок+ Редактирование.

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

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

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

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

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




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

−на каждую используемую функцию или возможность − хотя бы один

тест,

−на каждую область и на каждую границу изменения какой-либо входной

величины − хотя бы один тест,

−на каждую особую (исключительную) ситуацию, указанную в специфи- кациях, − хотя бы один тест.

Во втором случае эта стратегия базируется на принципе: каждая команда

каждой программы ПС должна проработать хотя бы на одном тесте.

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

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

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

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

ТестированиекачестваПС.Целью тестирования является поиск наруше- ний требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования.Ясно лишь, что далеко не каждый примитив качества ПС может быть испытан тестировани- ем. Завершенность ПС проверяется уже при тестировании внешних функций.

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

ТестированиедокументациипоприменениюПС.Целью тестирования яв-

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

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

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

2. Методы тестирования

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

Метод "белогоящика".В этом методе тестовые данные получают путем анализа логики программы.

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

Различают два типа классов эквивалентности:

−правильные (представляющие правильные входные данные);

−неправильные (ошибочные входные данные).

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

−если входное условие описывает область значений, то определяется один правильный класс и два неправильных;

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

−если входное условие описывает ситуацию "должна быть", то определя- ется один правильный и один неправильный классы;

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

Построение тестов включает в себя:

1. 
   Назначение каждому классу эквивалентности уникального номера
   
2. 
   Проектирование новых тестов,каждый из которых покрывает как можно большее количество неоткрытых правильных классов.
   
3. 
   Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов.
   

Данные для тестирования.

1. 
   В качестве некоторых тестовых данных используют экстремальные значения.Например,если целая величина должна находиться в диапа- зоне от a до b, то следует проверить: a-1, a, a+1, b-1, b, b+1.
   
2. 
   Используют специальные значения. К ним относятся: константы, 0, 1,
   

пустая строка, пустой файл, строка из одного символа и т.д.

3. 
   Для циклов, организованных с помощью оператора Do, выбрать значе- ния, при которых цикл выполняется 0, 1 и максимальное число раз.
   

Также методы тестирования можно разделить на:

1. 
   Статическоетестирование– ручная проверка программы за столом.
   
2. 
   Детерминированноетестирование – при различных комбинациях ис- ходных данных.
   
3. 
   Стохастическое–исходные данные выбираются произвольно,на вы- ходе определяется качественное совпадение результатов или пример- ная оценка.
   

3. Отладка

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

Рассмотрим основные заповеди отладки программного средства

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, по- ручайте его самым квалифицированным и одаренным программистам; нежела- тельно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнару- жить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

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

Заповедь 5.Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь6.Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошиб- ки).

В нашей стране различаются два основных вида отладки (включая тести- рование): автономную и комплексную отладку ПС.

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

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

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

тест будет пропускаться.

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

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

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

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

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

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

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

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

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

Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней мере, три следующие ситуа- ции: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла выполняется максимальное число раз. Добавьте недостающие тесты.

Шаг4.Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных дан- ных. Добавьте недостающие тесты.

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