Файл: Отладка и тестирование программ: основные подходы и ограничения (Теоретические аспекты отладки и тестирования ПО).pdf
Добавлен: 28.03.2023
Просмотров: 104
Скачиваний: 2
СОДЕРЖАНИЕ
1. Теория тестирования программного обеспечения
1.1 Критерии качества программного обеспечения
1.2 Методики проведения тестирования программного обеспечения
1.2. Теория отладки программного обеспечения
1.2.1 Виды ошибок в программном обеспечении
1.2.2 Методики отладки программного обеспечения
2. Практические аспекты отладки и тестирования ПО
2.1. Практика тестирования программного обеспечения
2.1.1 Отчеты об ошибках и системы их обработки
2.1.2 Основные инструменты тестировщика
2.1.3 Практические методы тестирования ПО
2.2. Практика отладки программного обеспечения
2.2.1 Инструменты отладки программного обеспечения
На рисунке изображено типичное окно отладчика
2.2.2 Практические методы отладки программного обеспечения
Первый и немаловажный практический метод отладки – это поиск синтаксических ошибок в коде. Времена, когда программист искал в коде отсутствующую точку с запятой несколько часов, давно канули в лету, современные средства отладки и разработки подсвечивают или выделяют такие ошибки автоматически или сообщают о них в окне отладчика при попытке запуска в режиме отладки.
Но не стоит полагаться на компилятор, если он вам ругается на какую-нибудь строку! Внимательно проверьте строки до нее и после, возможно ошибка кроется в них. Например, вы забыли закрыть цикл и все, что идет после его открытия компилятором считается как тело цикла, а закрывающего оператора нет, в этом случае компилятор может ругаться не на отсутствие оператора закрытия цикла, а на повторение переменной, которую вы задали как переменную счетчика цикла с какой-нибудь другой, используемой в коде (например, i).
Практическим методом также является стабилизация ошибки, то есть уменьшение кода программы до тех пор, пока ошибка проявляет себя. Если ошибка пропала, то логично будет предположить, что ее причина крылась в той части кода, который был убран последним.
Определение источника ошибки может занять много времени, если не подходить к нему систематически. Например, если работа осуществляется со списком входных данных и некоторые элементы вызывают ошибку, а некоторые нет – необходимо попытаться сгруппировать их и отсеять в один вид те, что вызывают ошибку. Также необходимо обратить внимание на ту часть кода, которая обрабатывает те или иные входные данные. Что происходит с данными? Чем они связаны? Какой тип данных? Чем похожи? Каков объем данных, их содержание? Ответив на эти вопросы станет намного проще понять причину возникновения ошибки. Составляя гипотезу о возникновении ошибки, необходимо использовать все имеющиеся данные. Если текущая гипотеза проваливается при очередной попытке отладки, необходимо ее улучшить, добавив нюансы новых полученных данных.
Необходимо детализировать тесты, приводящие к ошибке. Если не получается найти источник ошибки, необходимо уточнить уже имеющиеся тесты, внести больше конкретики и, таким образом, ошибку будет найти намного легче.
Хорошим подходом будет проверять код блочным методом, ведь найти ошибку в небольших объемах кода намного проще, чем в крупных интегрированных программах. Для изолированного тестирования фрагментов кода необходимо использовать блочные тесты.
При отладке ошибок важно использовать разные инструменты. В распоряжении разработчиков всегда имеется множество различных программ: интерактивные отладчики, строгие компиляторы, программы проверки памяти, встроенные модули проверки синтаксиса кода и многое другое. Правильный инструмент очень сильно облегчает сложную работу. Например, если ваша программа перезаписывает ячейки памяти в том месте, где не должна этого делать, найти такую проблему аналитическим методом тяжело, но если вы выставите точку прерывания на конкретный адрес в памяти, то при перезаписи памяти по этому адресу вы увидите строку кода, которая за это отвечает.
Воспроизводить ошибку нужно несколькими методами. Воспроизводя дефект программы различными методами, можно точнее определить ее источник. Как только начинает казаться, что причина ошибки ясна, нужно подстраховаться выполнив тест, который не должен вызывать ошибку, но очень похож на те, что вызывали. Если ошибка возникает и в этом случае, значит понимание причины ее возникновения еще не достигнуто и нужно проводить тесты и дальше. Часто причиной ошибки может служить несколько факторов и выявление лишь одного из них дает ложное представление о корне проблемы.
Чтобы точнее определить происхождение ошибки, необходимо вызывать ее разными способами (рисунок взять из книги Совершенный код / Стив Макконнелл 2010. – 534с)
Необходимо генерировать больше данных для диагностики происхождения ошибки, это значительно упростит ее поиск.
Результаты отрицательных тестов – это тоже результаты, ведь зная, что НЕ ВЫЗЫВАЕТ ошибку, остается больше вариантов что ее ВЫЗЫВАЕТ.
Полезной практикой при отладке приложений, это использовать мозговой штурм при поиске источника проблемы. Необходимо за короткий период придумать как можно больше гипотез о ее возникновении, а потом отработать каждую. Часто это сдвигает проблему поиска причины очередной сложной ошибки с мертвой точки.
Хорошо составлять списки подходов, которые стоит попробовать. Часто программисты заходят в тупик, идя по пути, который ни к чему не ведет и не видя других. Список подходов же поможет освежить взгляд и посмотреть на решение проблемы по-другому.
Отличной методикой поиска причин ошибки является сокращения подозрительной области кода. Например, удаляя куски кода, при исчезновении определенной ошибки можно понять в каком месте она была. В данной методике целиком и полностью работает метод «Разделяй и властвуй», подразумевающий разбиение кода на более мелкие составляющие и их отдельное тестирование. Также, код не обязательно удалять, можно задать точки прерывания выполнения программы или его просто временно закомментировать.
С подозрением относитесь к классам и методам, которые содержали дефекты ранее. Чаще всего ошибки проявляются в тех классах и методах, где они уже встречались ранее, нежели в тех, где их никогда не было, так что стоит обратить внимание на методы и классы, которые когда-то уже были ошибочными.
Стоит следить за кодом, который недавно претерпел изменения. Чаще всего, ошибки проявляются в новом, еще неотлаженном коде, стоит внимательно его проверять, если ошибка была обнаружена совсем недавно, после внесения каких-то изменений в программу.
Необходимо расширить подозрительную область кода, если не получается найти дефект в небольшом фрагменте. Скорее всего, ошибка закралась куда-то еще.
Можно выполнять интеграцию инкрементно. Отладка станет значительно проще, если добавлять элементы по одному за раз. Если после добавления нового элемента возникает ошибка, его нужно удалить и протестировать отдельно.
Осуществлять поиск распространенных ошибок – это очень хорошая практика. Для этого можно использовать контрольные списки качества кода.
Если проблема никак не решается и даже нет примерного понимания, откуда она исходит, необходимо обсудить проблему с кем-то еще, возможно, свежий не затёртый взгляд сразу увидит какую-то лазейку к поиску корня проблемы. Если обсудить ни с кем не представляется возможным, отдых от проблемы и временное занятие чем-то другим поможет собраться и с новыми силами подойти к решению вопроса.
ЗАКЛЮЧЕНИЕ
В заключение хочу сказать, что я рассмотрел в данной работе самые разнообразные как теоретические, так и практические особенности тестирования и отладки программного обеспечения и сделал вывод о том, что тема эта очень велика, сложна и постоянно развивается.
В моей работе рассмотрены лишь базовые понятия тестирования и отладки программ, которые дадут направление начинающему программисту как поступать в той или иной ситуации, какие методики существуют для поиска и устранения ошибок, какие инструменты применять в тех или иных случаях, какие подходы наиболее эффективны и при каких условиях.