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

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

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

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

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

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

Если же уделять достаточно внимания всякого рода деталям, то ошибок можно если не избежать, то минимизировать. Причин появления всех этих ошибок достаточно много, но из них можно выделить основные. Это, во-первых, непонимание разработчиками требований предъявляемых к программному продукту. Так происходит, когда приложение наполняется ненужными функциями и другими мелочами без необходимости. Во-вторых, причиной могут быть невежественные и мало обученные разработчики, которые недостаточно разбираются в операционных системах, технологиях и языках программирования. В-третьих, какие либо административные причины – слишком сжатые и невозможные для разработки поставленные сроки. Вопрос о приемлемости поставленных сроков должен обсуждаться всеми разработчиками на основании набора реализуемых функций. Если для качественной работы не хватает времени, целесообразнее просто отказаться от выполнения заказа. Одной из наиболее распространенных причин ошибок в программах является недостаточное внимание к публикации качественных продуктов. Разработчики должны гордиться своим созданием и опираться на все элементы продукта, а не только те, которые им интересны. Например, вместо того, чтобы смотреть на детали алгоритма, выберите более простой алгоритм и подумайте, как лучше всего его протестировать. В конце концов, клиент интересуется не алгоритмами, а качественным продуктом. Производители программного обеспечения, которые действительно чувствуют приверженность качеству, должны полагаться на тщательное планирование, личную ответственность, надлежащий контроль качества и хорошие навыки общения с клиентами и друг с другом. Многие программисты на разных этапах разработки больших систем, но только тот, кто уделяет значительное внимание деталям, будет выпускать продукцию в нужные сроки и отличного качества.^[7]

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

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

Глава 2. Практика отладки и тестирования приложений на примере среды Delphi.

2.1 Необходимые инструменты для откладки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве примера можно представить листинг, в котором значению переменной присваивается значение равное единице, а затем четыре раза будем прибавлять единицу и после этого прибавим 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;^[9]

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

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