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

Содержание:

Введение

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

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

Тестированием называют процесс, который даёт гарантии правильности функционирования программы и демонстрирующей отсутствие ошибок в продукте. Необходимо заметить, что такое определение не совсем верно и даже можно сказать неправильно. Человек с опытом разработки программирования знает, что нельзя гарантировать полное отсутствие ошибок, даже поле тестирования. Правильнее будет назвать процесс тестирования и отладки как – один из последних этапов при создании ПО, и он заключается в выполнении программы с целью обнаружения сбоев и ошибок в коде. Взамен гарантий отсутствия ошибок, наиболее правильно будет как минимум продемонстрировать их наличие. Если программное обеспечение проходит все тесты, то это придаёт уверенности в его работоспособности, но это не даёт гарантии в полном отсутствии ошибок. Это показывает, то, что нам на данный момент пока не известно при каких обстоятельствах и где программа может дать сбой. Мы получаем «парадокс тестирования». С одной стороны, тестирование позволяет убедиться, что ПО работает хорошо; а с другой - обнаруживает ошибки в нём, показывая, что ПО работает не совсем корректно. Вторая цель сточки зрения качества является более продуктивной, потому что не позволяет игнорировать недостатки в программном обеспечении.

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

Тема работы: «Тестирование и отладка программного обеспечения». Отладка и тестирование тема очень важная, какой бы язык программирования или платформа ни использовались. Именно на этой стадии разработчики сталкиваются с большинством.

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

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

1. Сущность тестирования и отладки. Методика выявления ошибок/

1.1 Тестирование и его виды

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

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

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

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

Уже в 80-е годы тестирование было дополнено таким понятием, как предупреждение ошибок. Одним из самых эффективных методов предупреждения ошибок является - проектирование тестов. Тогда и поняли необходимость методологии тестирования, а именно, что тестирование программы необходимо осуществлять на всем протяжении разработки, и он должен быть управляемым. При этом проверяется не только спроектированная сборка ПО, но и их код, спецификации, архитектура и сами тесты. Все это позволит обнаруживать проблемы в архитектуре и требованиях и тем самым снизить сроки и средства на разработку ПО. Позже начали появляться первые инструменты для автоматизации тестирования. Так как ЭВМ более надежна и способна выполнить больше тестов, со временем простые методы усложнялись и стали использоваться скриптовые сценарии для автоматического тестирования.

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

В 2000-е годы появляется еще более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий» (BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов цикла разработки для достижения нужного уровня качества, производительности, доступности [9].

1.2 Виды тестирования

В зависимости от нужных целей, виды тестирования программ, можно условно разделить на три группы:

1)Функциональные

2)Нефункциональные

3)Регрессионное

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

Модульное тестирование - это контроль отдельного программного модуля, как правило в изолированной среде.

Интеграционное тестирование - когда отдельные модули объединяются и тестируются в вместе.

Системное тестирование - тестирование программ, выполняемое на полной, интегрированной системе с целью проверки соответствия системы требованиям.

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

Все эти виды тестирования рассматривают внешнее поведение системы и подразделяются на три подвида:

1) функциональное тестирование;

2) тестирование безопасности;

3) тестирование взаимодействия [5].

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

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

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

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

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

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

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

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

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

Если инсталляторов нет, то установка производится самостоятельно согласно инструкциям, либо специальному плану установки; например, в распределенных системах.

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

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

Тестирование на отказ и восстановление анализирует стрессовую устойчивость ПО при непредвиденном отказе оборудования, отказе в работе сетевой инфраструктуры и другие. Проверяются системы отката и восстановления, обеспечивающие целостность и сохранность данных программного обеспечения в случае сбоя в обычной работе программы или её окружения. Данное тестирование необходимо при проектировании веб-приложений, т.к. из-за потери данных можно потерять большое количество клиентов, денег, а главное репутацию продукта. Майерс, Баджетт, Сандлер Искусство тестирования программ, 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 — это может помочь обнаружить найти ошибку в коде. Но многие ошибки связаны с тем, что неточно реализована логика самого алгоритма. Такие дефекты обнаруживаются только во время выполнения контрольных примеров. Так бывает, например, когда не закрыты кавычки или скобки. Если исходный алгоритм реализуется неправильно, то работоспособность приложения может быть даже, и не нарушена, но результаты будут выдаваться неверные или программой будут выполняться неверные действия. Поэтому и обнаруживаются подобные ошибки лишь на этапе отладки.

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

Из всех инструментов встроенного отладчика наиболее часто используются точки остановки - BreakPoint. После установки точки, приложение будет работать до тех пор, пока не достигнет ее, после чего работа программы будет остановлена и управление переходит к IDE. Точки остановки удобнее всего снимать и ставить нажатием горячей клавиши «Ctrl+8», либо отметить строчку кода слева рядом с панелью нумерации строк.

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

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

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

Заключение

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

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

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

В заключении:

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

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

Тестировать необходимо не только положительные, но и отрицательные результаты.

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

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

См. Приложение 2.

Список использованных источников

1. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика / Глас Р, 2010.
2. Т.А.Жданова, Ю.С. Бузыкова. Основы алгоритмизации и программирования: учеб. пособие / Т.А. Жданова, Ю.С. Бузыкова. – Хабаровск : Изд-во Тихоокеан. гос.ун-та, 2011. –56 с.
3. Коликова Т.В., Котляров В.П. Основы тестирования программного обеспечения / М., Бином, 2010, 285 стр.
4. Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд / М.: «Вильямс», 2010. - 464 с.
5. Майерс, Баджетт, Сандлер Искусство тестирования программ / Майерс.- 3-е. -- М.: «Диалектика», 2012. -- 272 с.
6. Пестриков В. М., Маслобоев А. Н. Delphi на примерах. / Пестриков В. М. СПб.: БХВ-Петербург, 2009. -- 496 с.
7. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. /Синицын С. В.- М.: БИНОМ, 2008. -- 368 с.
8. Стивен Р. Delphi. Готовые алгоритмы / Род Стивене; - 4-е изд. - М.: ДМК Пресс; СПб.: Питер, 2010. - 384 с.
9. Тамре Л. Введение в тестирование программного обеспечения / М., Дрофа, 2009.
10. Белов П.М. Основы алгоритмизации в информационных системах / П. В. Белов.-Учебн. Пособие.- Спб.: СЗТУ, 2003. – 85с.
11. Ховард М., Лебланк Д. Защищенный код / М. Ховард.- Пер. с англ, - 2-е изд., испр. М.: Издательско-торговый дом «Русская Редакция», 2004. - 704 стр.
12. Бруно Скворц . Узнать и полюбить Xdebug / Б. Скворц // Режим доступа: https://habr.com/ru/post/328094/ ( 5. 05. 17)
13. Сивкоф. Отладка с помощью Xdebug и PhpStorm / Sivkoff // Режим доступа: https://habr.com/ru/post/250323/ (11. 02. 15)

Приложение 1

Таблица 1

Наименование команды	Горячая клавиша	Действие отладчика
«Settings/Perfences»	«Ctrl+Alt+S»	Страница настроек отладчика в IDE PhpStrorm
«Run | Toggle Line Breakpoint»	«Ctrl+F8»	Установка точки прерывания на линии кода
«Step Into»	«F7»	Переход отладчика на следующую строку кода
«Step Out»	«Shift+F8»	Выход из режима отладки
«Step Over»	«F8»	Провалиться в вызываемый метод
«Run | Debugging Actions | Resume Program»	«F9»	Выполнение программы до выхода или до следующей точки остановки

Приложение 2

Таблица 2

№ п/п	Понятие	Определение
1	Интеграционное тестирование	тестирование, при котором, отдельные программные модули объединяются и тестируются в группе.
2	Испытание	поиск возможных ошибок, выполняя приложение в заданной реальной среде.
3	Комплексное тестирование	контроль и испытание системы по отношению к исходным целям.
4	Контроль	попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.
5	Отладка	завершающий этап создания программного продукта, который заключается в выполнении программы с целью выявления сбоев и ошибок программного кода, направлен на установление точной природы известной ошибки и ее исправление.
6	Приемочное тестирование	способ проверки и контроля за тем, чтобы работа приложения отвечала функциональным, нефункциональным и другим важным требованиям.
7	Системное тестирование	это тестирование программ, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям.
8	Тестирование	процесс, гарантирующий правильность функционирования программы и показывающий отсутствие ошибок в программном продукте.
9	Тестирование внешних функций	контроль внешнего поведения системы, определенного внешними спецификациями.
10	Тестирование модуля	контроль отдельного программного модуля, обычно в изолированной среде.
11	Тестирование настройки	проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
12	Тестирование приемлемости	проверка соответствия программы требованиям пользователя.