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

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

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

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

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

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

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

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

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

1.3 Сущность и методика отладки программ. Виды ошибок

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

Нелогичный пользовательский интерфейс;

Неудовлетворенные ожидания;

Низкая производительность;

Аварийные завершения или разрушение данных.

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

Эта задача существенно усложняется при проектировании интерфейса Web-приложения. Уже не будет конкретных стандартов на пользовательский интерфейс. Необходимо учитывать возможную низкую скорость трафика. Исходя из этого, рекомендацией будет создание пользовательского интерфейса максимально простым. К примеру, простые решения, подобные CNN.com, большинство пользователей оцениваются положительно.^[6]

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

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

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

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

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

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

При уделении достаточного внимания всякого рода деталям можно существенно минимизировать ошибки. Существует достаточно много причин появления этих ошибок, однако из них можно выделить основные моменты. Чаще всего это непонимание требований, которые предъявляются к программному продукту. Примером тому является наполнение приложения ненужными функциями и другими мелочами без надобности. Также причиной могут быть сами разработчики, не имеющие достаточной квалификации. К административным причинам относятся сильно ужатые сроки на разработку продукта. Установленные сроки должны обсуждаться всем коллективом разработчиков, исходя из перечня функций, которые нужно реализовать. При нехватке временного ресурса на качественное выполнение работы целесообразнее просто отказаться от выполнения. Наиболее распространенной причиной возникновения ошибок в программах является недостаточная ориентация на выпуск продукции надлежащего качества. Разработчики должны гордиться своим творением и усердно работать со всеми элементами их продукта, а не только с интересными для них. К примеру, выбирается более простой алгоритм и проводится анализ метода, каким образом провести тесты вместо того, чтобы углубиться в детали алгоритма. Алгоритмы заказчика не интересуют. Он зинтересован в качественном продукте, котрый будет функционировать на приемлемом уровне. Разработчики ПО обязаны нести персональную ответственность, опираться на тщательное планирование, осуществлять надлежащий уровеньконтроль качества и обладать хорошими способностями к общению между собой и с клиеннтами.^[8]

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

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

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

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

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

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

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

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

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

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

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

Что касается системы отслеживания ошибок, так это то, что в ней не только копится информация об ошибках, но к тому же ее очень удобно применять с целью хранения разных заметок и списка заданий на стадии разработки исходного кода. Абсолютное большинство разработчиков хранит списки заданий в телефонах и нужная информация часто теряется среди отладочных и других файлов. По этой причине рекомендуется в системе отслеживания ошибок сохранять свои заметки с той целью, чтобы не тратить время на их поиск и они всегда были под рукой. Большим плюсом системы отслеживания ошибок является то, что полные сведения об ошибках и запросы реализации функций хранятся в одном месте. Уследить за информацией при хранении ее в разных местах – довольно проблематично.