Файл: Отладка и тестирование программ: основные подходы и ограничения (Методы тестирования).pdf

6. Тестирование программы. На этом этапе, чтобы удостовериться в правильности работы алгоритма, решаются задачи с такими исходными данными, для которых известно достоверное решение, либо используются какие-то косвенные свидетельства. Так в ряде задач существует связь между исходными данными и результатами, например закон сохранения энергии, импульса и т.д^[11].

Отладка программного обеспечения^[12]

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

Отладка не является разновидностью тестирования, хотя слова «отладка» и «тестирование» часто используют как синонимы. Под ними подразумеваются разные виды деятельности:

- тестирование — деятельность, направленная на обнаружение ошибок;

- отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки;

- результаты тестирования являются исходными данными для отладки.

Эти два вида деятельности очень тесно связаны и поэтому они обычно рассматриваются совместно.

В результате отладки программное обеспечение должно соответствовать определенной фиксированной совокупности правил и показателей качества, принимаемой для него за эталонную. То есть: отладка — это этап разработки, на котором устраняются недостатки только что созданного ПО.

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

По оценкам специалистов, в общем, времени разработки программного обеспечения, отладка занимает от 50 % до 90% (зависит от результатов проведения предыдущих этапов).

Отладку можно разделить на синтаксическую и семантическую.

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

В отличие от синтаксической ошибки, семантическая ошибка не формализуема и поэтому она составляет основу отладки.

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

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

2.1 Два важных инструмента в отладке приложений

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

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

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

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

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

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

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

Многих проблем при разработке программных продуктов можно избежать используя в системе управления версиями, так называемых, блочных тестов (unit test). Блочный тест, или тестовое приложение, представляет собой фрагмент кода, управляющей выполнением основной программы. Этот специальный код создается программистами для тестирования «белого ящика» и контролирует выполнение программой основных процедур и операций приложения. Подробное описание блочных тестов. Блочные тесты в системе управления значительно облегчает работу разработчикам, сопровождающим приложение, а также упрощает контрольное тестирование программы и сосредоточить внимание на более важных моментах: производительности, масштабируемости приложения, полному соответствию требований заказчика, т.е. тестирование приемлемости - проверка соответствия программы требованиям пользователя. Использование блочных тестов это хороший показатель профессионализма разработчиков программ.

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

Естественно, что система управления версиями должна соответствовать потребностям разработчика. Если разрабатывает продукт компания с требованиями класса «high-end», с поддержкой нескольких платформ, то, скорее всего, придется применять более дорогую систему или использовать решение с открытым кодом, например, CVS.

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

2.2 Применение точек остановки и модификация локальных переменных

В коде любого созданного приложения обязательно будут ошибки. Если говорить о синтаксических ошибках, которые вызваны неверным вводом команд в редакторе, либо неверной записью идентификаторов и иными неверными действиями программиста, то они почти всегда фиксируются самим компилятором Delphi. Следует постоянно обращать внимание на различные сообщения и предупреждения, выдаваемые при прогоне программы, это может помочь обнаружить найти ошибку в тексте кода. Но многие ошибки связаны с тем, что неточно реализована логика самого алгоритма. Такие дефекты обнаруживаются только во время выполнения контрольных примеров. Так бывает например, когда вместо символа "<" ошибочно введен символ "<=". Если вдруг исходный алгоритм реализуется неправильно, то работоспособность приложения может быть даже, и не нарушено, но результаты будут выдаваться неверные или программой будут выполняться неверные действия. Поэтому и обнаруживаются подобные ошибки лишь на этапе отладки.

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

Из всех инструментов встроенного отладчика наиболее часто используются точки остановки - BreakPoint. После установки точки, приложение будет работать до тех пор, пока не достигнет ее, после чего работа программы будет остановлена и управление переходит к отладчику Delphi. Точки остановки удобнее всего снимать и ставить нажатием горячей клавиши «F5», либо зайти в меню «Debug->Toggle breakpoint», либо другими способами.

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

Возникает вопрос: где ставить эти точки? Однозначного ответа дать нельзя. Они предназначаются лишь для того, чтобы облегчить нам изучение работы программного кода, если нет уверенности в его корректности, или содержащего явную ошибку незаметную при беглом просмотре. Конечно куда проще поставить точку остановки и последовательно выполнить нужные строчки, чем потратить кучу времени на изучение этого же самого кода, пытаясь определить, где же он начал работать неправильно.

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

var

Form1: TForm1;

A: Integer;

B: Integer = 123;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);

begin

Inc(A);

Inc(A);

Inc(A, B);

Inc(A);

Inc(A);

ShowMessage(IntToStr(A));

ShowMessage(IntToHex(A, 8));

end; [4]

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

Получается следующая картина: точка установки стоит на строчке Inc(A). В специальном окне «Local Variables», можно видеть значения всех используемых локальных переменных процедуры создания формы, а также переменной Self, передающейся неявно и всегда присутствующей в методах класса и параметра Sender.