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

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

Тестирование на отказ и восстановление анализирует стрессовую устойчивость ПО при непредвиденном отказе оборудования, отказе в работе сетевой инфраструктуры и другие. Проверяются системы отката и восстановления, обеспечивающие целостность и сохранность данных программного обеспечения в случае сбоя в обычной работе программы или её окружения. Данное тестирование необходимо при проектировании веб-приложений, т.к. из-за потери данных можно потерять большое количество клиентов, денег, а главное репутацию продукта. Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. -- М.: «Диалектика», 2012. -- 272 с.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Практика отладки и тестирования WEB-приложений в среде PHP

2.1 Отладка и тестирование приложения с помощью XDebug в IDE PhpStorm

Рассмотрим вариант отладки и тестирования приложения с помощью модуля XDebug в наиболее популярной на данный момент IDE для разработки приложений на PHP PhpStorm.

Xdebug — это расширение для PHP (должно быть скомпилировано и установлено в процессе установки PHP) которое представляет разработчику следующий функционал для отладки:

• Трассировки стека — вывод подробного пути, который привел приложение к полученной ошибке, включая параметры, переданные в функции, в порядке позволяющем легко отследить ошибку
• Более приятный вывод var_dump, создающий подсветку кода и структурированный вид вместе с дампом суперглобальных переменных, по аналогии с VarDumper.
• Профайлер для поиска узких мест кода с возможностью визуализированного представления графиков производительности внешними инструментами. В результате получается график похожий на графики из Blackfire.
• Удаленный отладчик, который может быть использован при соединении с Xdebug для запуска и выполнения кода в IDE или браузере построчно через брейк-пойнты.
• “Покрытие кода” которое показывает какая часть кода была выполнена в процессе запроса. Это функция нужна по большей части для юнит-тестов и получения информации о том насколько хорошо ваш код покрыт тестами. [12]

Для работы расширения необходимо установить (зачастую он уже установлен вместе со средой PHP, поэтому упустим момент его установки и рассмотрим только настройки, которые необходимо произвести в файле php.ini. На сервере в упомянутом выше файле (расположение может отличаться в зависимости от вариантов настройки и установки среды PHP) необходимо с помощью текстового редактора внести изменения переменных, а именно:

zend_extension="%путь до php%/ext/php_xdebug.dll" – данная настройка отвечает за автостарт расширения

xdebug.remote_autostart=on

xdebug.remote_enable=on

xdebug.remote_handler="dbgp"

xdebug.remote_host="localhost"

php xdebug.remote_port=9001

xdebug.remote_mode=req

xdebug.idekey="PHPSTORM" – ключ используется для идентификации IDE и по сути может быть любым

Настройка IDE PHPStorm

Будем считать, что первоначальная настройка интерпретатора в IDE уже сделана. В разделе настроек PHP > Servers в выпадающем списке необходимо выбрать пункт Xdebug. Далее настраиваем сам Xdebug в разделе настроек PHP > Debug.

Debug port – необходимо задать порт указанный в php.ini (xdebug_remote_port)

IDE Key – xdebug.idekey

Host – xdebug.remote_host

Port – xdebug.remote_port

[13]

Современные IDE предоставляют широкие возможности поиска по коду, так что полезность функционала форматирования ссылок кажется сомнительной. Существуют всевозможные системы логирования способные обрабатывать ошибки и исключения. Также, трассировка и профилирование функций прекрасно реализованы в Blackfire. Не смотря на все это, форматирование ссылок на файлы лишь одна из функций Xdebug, а использование Blackfire связано с собственными трудностями — установка расширения, настройка горячих клавиш, и оплата сохранения истории трассировок. А использование логгеров требует внимательности, так как добавить их в приложение на поздних этапах не самая простая задача.

Но область использования Xdebug не ограничивается лишь этим. Он всё ещё необходим для правильного модульного тестирования (тестируемые фреймворки зависимы от его отчетов о покрытии кода), далеко не так легко провести отладку через удаленные брейк-пойнты другими средствами, а этот инструмент настолько старый и стабильный, что был отшлифован почти до идеала. [12]

2.2 Применение точек остановки

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