Содержание:

Введение

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

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

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

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

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

1. Сущность тестирования и отладки.

1.1 Описание процесса тестирования и его истории.

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

На протяжении десятилетий развития разработки ПО к вопросам тестирования и обеспечения качества подходили очень и очень по-разному. Можно выделить несколько основных «эпох тестирования».

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

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

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

Итак, ещё раз самое важное, что тестирование «приобрело» в 70-е годы:

тестирование позволяет удостовериться, что программа соответствует требованиям;

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

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

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

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

В нулевые годы нынешнего века развитие тестирования продолжалось в контексте поиска всё новых и новых путей, методологий, техник и подходов к обес-печению качества. Серьёзное влияние на понимание тестирования оказало появ-ление гибких методологий разработки и таких подходов, как «разработка под управ-лением тестированием9 (test-driven development10, TDD)». Автоматизация тестирования уже воспринималась как обычная неотъемлемая часть большинства проек-тов, а также стали популярны идеи о том, что во главу процесса тестирования сле-дует ставить не соответствие программы требованиям, а её способность предоста-вить конечному пользователю возможность эффективно решать свои задачи.^[1]

1.2 Тестирование программного обеспечения и его цели .

Прежде чем приступить к обсуждению процесса разработки программного обеспече­ния, дадим определения ряда основных терминов и понятий. По логике вещей лучше всего начать с определения, что собой представляет тестирование программного обеспечения. Тестирование программного обеспечения (software testing)— это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов. Несмотря на всю простоту этого определения, в нем содержатся пункты, которые требуют дальнейших пояснений. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование суть плановая, упорядоченная деятельность. Этот момент очень важен, если мы заинтересованы в быстрой разработке, ибо хорошо продуманный, систематический подход быстрее приводит к обнаружению про­граммных ошибок, чем плохо спланированное тестирование, к тому же проводимое в спешке. Согласно этому определению, тестирование предусматривает "анализ" или "экс­плуатацию" программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тести­рованием (static testing). Статическое тестирование предусматривает проверку про­граммных кодов, сквозной контроль и проверку программы без запуска па машине, т.е. проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусмат­ривающая эксплуатацию программного продукта, носит название динамического тес­тирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок. Последний пункт определения, требующий дополнительных пояснений — это по­нятие дефекта (bug). Говоря простыми словами, программная ошибка— ни что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически получен­ных результатов. Дефект может возникнуть на стадии кодирования, на стадии фор­мулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных. Дефектом может быть также что-то другое, что не соответствует ожиданиям заказчика и что может быть, а может и не быть определено в спецификации программного продукта.

Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Цели тестирования:

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

1.3 Виды и направления тестирования.

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

Итак, тестирование можно классифицировать:

• По запуску кода на исполнение:
  • • Статическое тестирование — без запуска.
    • Динамическое тестирование — с запуском.
• По доступу к коду и архитектуре приложения:
  • • Метод белого ящика — доступ к коду есть
    • Метод чёрного ящика — доступа к коду нет
    • Метод серого ящика — к части кода доступ есть, к части — нет
• По степени автоматизации:
  • • Ручное тестирование — тест кейсы выполняет человек.
    • Автоматизированное тестирование — тест кейсы частично или полностью выполняет специальное инструментальное средство.
• По уровню детализации приложения (по уровню тестирования):
  • • Модульное (компонентное) тестирование — проверяются отдельные небольшие части приложения
    • Интеграционное тестирование — проверяется взаимодействие между несколькими частями приложения.
    • Системное тестирование — приложение проверяется как единое целое.
• По (убыванию) степени важности тестируемых функций (по уровню функционального тестирования):
  • • Дымовое тестирование — проверка самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной саму идею использования приложения.
    • Тестирование критического пути — проверка функциональности, используемой типичными пользователями в типичной повседневной деятельности.
    • Расширенное тестирование — проверка всей (остальной) функциональности, заявленной в требованиях.
    • По принципам работы с приложением:
    • Позитивное тестирование — все действия с приложением выполняются строго по инструкции без недопустимых действий, некорректных данных и т.д. Можно образно сказать, что приложение исследуется в «тепличных условиях».
    • Негативное тестирование — в работе с приложением выполняются (некорректные) операции и используются данные, потенциально приводящие к ошибкам (классика жанра — деление на ноль).^[2]

Тестирование программного обеспечения (software testing)- это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.

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

Согласно этому определению, тестирование предусматривает "анализ" или "эксплуатацию" программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тестированием (static testing). Статическое тестирование предусматривает проверку программных кодов, сквозной контроль и проверку программы без запуска па машине, т.е. проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусматривающая эксплуатацию программного продукта, носит название динамического тестирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок.

Последний пункт определения, требующий дополнительных пояснений - это понятие дефекта (bug). Говоря простыми словами, программная ошибка - не что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов. Дефект может возникнуть на стадии кодирования, на стадии формулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных. Дефектом может быть также что-то другое, что не соответствует ожиданиям заказчика и что может быть, а может и не быть определено в спецификации программного продукта. Более подробное описание терминологии дефектов приводится во врезке.

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

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

Функциональные виды тестирования

Нефункциональные виды тестирования

Связанные с изменениями виды тестирования

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

компонентном или модульном (Component/Unit testing)

интеграционном (Integration testing),

системном (System testing)

приемочном (Acceptance testing).

Теперь необходимо огласить список большинства распространенных типов функциональных тестов:

Функциональное тестирование (Functional testing)

Тестирование безопасности (Security and Access Control Testing)

Тестирование взаимодействия (Interoperability Testing)

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

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

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

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

XSS (Cross-Site Scripting) – к примеру тот случай когда злоумышленники могут попытаться украсть ваши куки, перенаправить вас на сайт, где произойдет более серьезная атака, загрузить в память какой-либо вредоносный объект и т.д., всего навсего разместив вредоносный скрипт у вас на сайте;

XSRF / CSRF (Request Forgery) пример когда атакующий добавляет необходимый код в электронное письмо или выкладывает на веб-сайт, таким образом, что при загрузке страницы осуществляется запрос, выполняющий вредоносный код;

Code injections (SQL, PHP, ASP и т.д.) – это тот тип атаки, при котором система позволит выполнить некоторое действие, которое не планировалось разработчиком. Например, при аутентификации пользователя при вводе в поля формы логина и пароля определенных значений;

Server-Side Includes (SSI) Injection – тот случай когда при определнных обстоятельствах становиться возможным выполнение команд на сервере используя дыры в безопасности написанного программного обеспечения .

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

Тестирование взаимодействия (Interoperability Testing) – это вид тестирования которое проверяет способно ли приложение взаимодействовать другими компонентами или системами. Тестирование взаимодействия включает в себя тестирование совместимостии интеграционное тестирование.

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

Все виды тестов которые напавлены на тестирование производительности

нагрузочное тестирование (Performance and Load Testing)

стрессовое тестирование (Stress Testing)

тестирование стабильности или надежности (Stability / Reliability Testing)

объемное тестирование (Volume Testing)

Тестирование установки (Installation testing)

Тестирование удобства пользования (Usability Testing)

Тестирование на отказ и восстановление (Failover and Recovery Testing)

Конфигурационное тестирование (Configuration Testing)

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

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

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

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

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

измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций

может производиться определение количества пользователей, одновременно работающих с приложением

Тестирование установки (Installation testing) – цель этих тестов - проверка успешной установки и настройки, а также возможность обновления или удаления программного обеспечения.В настоящее время очень распрастранен метод установки программного обеспечения с помощи специальных программ(инсталляторов), работа которых сама по себе требует отдельного тестирования,но стоит учесть что в реальных условиях инсталляторов может и не быть , в этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки.

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

Тестирование на отказ и восстановление (Failover and Recovery Testing) : в этом типе тестирования выполняется проверка тестируемого продукта на способность противостоять и успешно восстанавится после возможных сбоев, которые могут возникнуть в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

Конфигурационное тестирование (Configuration Testing) —в этом случае тесты которые направленны на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.).

Связанные с изменениями виды тестирования.

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

Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:

Дымовое тестирование (Smoke Testing)

Регрессионное тестирование (Regression Testing)

Тестирование сборки (Build Verification Test)

Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Дымовое тестирование (Smoke Testing) – этот вид тестирования рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции. Вывод о работоспособности основных функций делается на основании результатов поверхностного тестирования наиболее важных модулей приложения на предмет возможности выполнения требуемых задач и наличия быстронаходимых критических и блокирующих дефектов.

Регрессионное тестирование (Regression Testing) - это вид тестирования направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде.

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

Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) - это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.

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

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

Ошибки возникающие во время разработки ПО;

Синтаксические ошибки

Предупреждения (warnings) компилятора

Ошибки времени исполнения(run-time errors)

Семантические ошибки

По степени критичности:

Блокирующие (Ошибки, из-за которых дальнейшая работа с системой становится невозможной.)

Важные;

Обычные;

Малозначимые

По приоритету

FIX IN RELEASE

MUST FIX

FIX IF TIME

NEVER FIX

По времени появления:

Постоянно, при каждом запуске;

Иногда («плавающий» тип);

Только на машине у клиента (зависит от локальных настроек у клиента);

По месту и направлению:

Ошибки пользовательского интерфейса;

Системы обработки ошибок;

Ошибки, связанные с граничными условиями (например, некорректная обработка пустой строки или максимального числового значения);

Ошибки вычислений;

Ошибки управления потоками;

Ошибки обработки или интерпретации данных;

При состоянии гонки;

Повышение нагрузки;

Ошибки контроля версии и идентификаторов;

Ошибки тестирования;

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

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

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

Ошибки времени исполнения

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

n3 = n2 * n2;

В данном случае предполагается, что n3 представляет куб числа n ,в то время как код вычитает четверную степень n . ^[3]

Ошибки времени исполнения - Во время работы приложения могут возникать ошибки, которые называются ошибками времени выполнения (run-time errors) или исключениями (exceptions). В большинстве случаев причинами исключений являются неверные исходные данные .Хорошим примером такой ошибки может служит деление на ноль в приложении.

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

Избыточная функциональность – это ошибка в которой трудно убедить разработчиков( Брукс (Brooks,1975).Основным критерием оценки фунциональности может быть следующий: если редко используемые функции программы усложняют использованием ее базовых возможностей ,значит , уровень функциональности выходит из под контроля.

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

Программа делает не то что ожидает от нее пользователь – например если программа должна сортировать список имен ,едва ли кто-то станет ожидать что имена будут сортировать в порядке ASCII.

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

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

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

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

2.1 Два важных инструмента в процессе тестирования.

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

Система управления версиями

Система регистрации и отслеживании ошибок

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

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

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

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

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

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

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

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

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

После того как данный код будет выполнен фунций возвратит 400 а не 3 как предполагается.

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

Далее необходимо последовательно в окне IDE выбрать пункты меню run => debug ‘test’ .Test в этом случае это имя файла.

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

Для того чтобы выставить нужно нам значение переменной ,в данном случае test2 выбираем в окне Varibles нужную переменную кликаем правой кнопкой мыши и выбираем пункт Set Value ввести необходимое значение и нажать Enter.Далее можно продолжить выполнение программы и она вернет нам нужные значения.

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

Заключение

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

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

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

В заключении себе и другим будущим программистам хочу дать следующие рекомендации:

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

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

Тесты следует готовить и для правильных, так и для неверных данных.

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

Модули должны подключаться к приложению только один раз; замена модулей существенно усложняет тестирование.

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

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

1 Святослав Куликов . Тестирование программного обеспечения. Базовый курс. 2-е издание с 6-8

2 Святослав Куликов . Тестирование программного обеспечения. Базовый курс. 2-е издание c.62 -63

3 Стивен Прата Язык программирования С. Лекции и упражнения с. 68-69.

1. Святослав Куликов . Тестирование программного обеспечения. Базовый курс. 2-е издание с 6-8 ↑

2. Святослав Куликов . Тестирование программного обеспечения. Базовый курс. 2-е издание c.62 -63 ↑

3. Стивен Прата Язык программирования С. Лекции и упражнения с 68-69

   ↑