Файл: Практическая значимость выбранной темы. Разработчикам и компаниям,занимающимся разработкой по, всегда следует стремиться найти все возможные ошибки до того, как программа поступит к заказчику или конечному потребителю. Цель.pdf

Подведем промежуточные итоги. В современном тестировании выделяются два подхода: тестирование «черного ящика» и тестирование «белого ящика». Между ними некоторыми теоретиками выделяется и промежуточный подход –
тестирование «серого ящика», который объединяет достоинства двух названных выше.
1.4 Отладка ошибок. Их виды
Начнем с определения различия между тестированием и отладкой программы
(debugging). Эти термины не означают одно и то же, несмотря на то, что часто используются как синонимы.
Отладка не является разновидностью тестирования. Тестирование ставит задачу определения наличия ошибок [21; 27], в то время как отладка служит для определения местоположения выявленных тестированием ошибок в исходном коде и их устранения [20]. Если цели этих двух этапов разработки программ различны,
то, соответственно, используются различные методика и инструментарий. Важно разделять процесс тестирования и процесс отладки на два различных этапа работы над программой. Важно отметить, что эти два вида деятельности связаны:
результаты тестирования являются исходными данными для отладки.
В настоящее время выделяется несколько способов отладки [6]. Перечислим их:
интерактивная отладка,
командный язык отладки,
трассировка,
самоотладка,
детерминированное воспроизведение выполнения,
отладка аппаратных конфигураций,
отладка производительности.
Отладка происходит проще при пошаговом тестировании. Если есть ошибки в межмодульных интерфейсах, то при монолитном тестировании они могут быть обнаружены лишь после сборки всего продукта. В этот момент локализовать ошибку довольно трудно, поскольку она может находиться в любом модуле. В
случае пошагового тестирования ошибки такого типа в основном связаны с тем модулем, который подключается последним [20].

Планирование тестирования необходимо производить совместно с планированием отладки. При этом в ходе планирования ставится задача продумать разные способы ускорения и оптимизации обоих процессов. Так, на ранних этапах следует подготовить инфраструктуру для написания автоматизированных тестов, которые позволят значительно сэкономить время в будущем, когда одни и те же тесты придется повторять несколько раз.
При планировании и проектировании необходимо встраивать достаточное количество отладочного кода в свои программы, чтобы этот код подсказывал программисту, где возникают ошибки. Этот способ упростит процесс отладки и снизит количество возможных ненайденных ошибок.
По утверждению Д. Роббинса, любая ошибка может быть отнесена к одной из следующих категорий:
нелогичный пользовательский интерфейс;
неудовлетворенные ожидания;
низкая производительность;
аварийные завершения или разрушение данных [24].
Нелогичный пользовательский интерфейс — это разновидность не очень серьезных ошибок, однако может привести к потере потенциальных клиентов и снижению рейтинга вашего продукта. Например, одной из причин популярности операционной системы Windows от Microsoft является как раз – удобный и понятный пользовательский интерфейс во всех ее приложениях.
Чтобы снизить проблему нелогичности при разработке клиентских приложений,
следует придерживаться рекомендаций и стандартов от компании разработчика данной операционной системы. Таким образом пользовательский опыт будет максимально знаком и понятен пользователям клиентского приложения.
В случае проектирования интерфейса Web-приложения, эта задача существенно усложняется. Здесь уже нет конкретных стандартов на пользовательский интерфейс. Самое главное, что надо учитывать при разработке интерфейса для
Web-клиента, — это возможную низкую скорость трафика, поэтому следует создавать пользовательский интерфейс максимально простым и загружать с сервера только необходимые ресурсы чтобы максимально снизить время загрузки и ожидания пользователя. К примеру, простые решения, подобные CNN.com,
нравятся практически всем пользователям. Использование простого набора ссылок выглядит куда лучше и работает быстрее, чем перегруженный различными

функциями и графическими материалами интерфейс. Подобный перегруженный интерфейс легко может вызывать неудобство или даже отпугивать пользователя
[8].
Одной из наиболее трудноразрешимых ошибок являются неудовлетворенные
ожидания пользователей. Причиной этого обычно является недостаточность исследования реальных потребностей потребителя, т.е. возникает проблема взаимодействия. Подобные ошибки обычно возникают на самых ранних этапах проектирования программы [18].
Сами разработчики не общаются напрямую с заказчиками своих программ, поэтому они сами не изучают потребности и требования пользователей. Поэтому необходимо взаимодействие с заказчиками, чтобы увидеть, что они делают с их программами. Многое прояснится, если понаблюдать за действиями рядового пользователя или заказчика, как используется ваш программный продукт. Кроме того, такой опыт позволит разработчику понять, что, по мнению клиента, требуется от разрабатываемого приложения.
Наибольшее разочарование приносят ошибки, приводящие к снижению
производительности при некорректной обработке данных приложением. Зачастую именно эти ошибки вызваны недостаточным тестированием программного обеспечения. Они могут быть выявлены с запозданием при обработке большого массива данных. Часты случаи, когда, выпуская первую версию недостаточно протестированной программы на рынок, производитель обрекает себя на полный провал. Причем последующие исправленные версии уже не хочет использовать большая часть пользователей, которые обожглись на первой версии приложения.
Есть два основных метода борьбы с подобными ошибками. С одной стороны,
необходимо на этапе проектирования установить конкретные требования к производительности программного продукта. Для выявления проблем с производительностью нужно сравнить основные показатели работы приложения под разными нагрузками. Если вдруг происходит потеря производительности допустимый предел, то необходимо принять меры и выяснить – по какой причине это произошло и внести нужные изменения в код. Далее надо убедиться в том, что нагрузка действительно соответствует наиболее близким к реальной жизни сценариям, и делать это нужно на самых ранних этапах проектирования [24].
Возникновение аварийных завершений и потери данных и утечка памяти — это наиболее распространенные ошибки. Среди таких дефектов встречаются как легко

разрешимые, так и практически неразрешимые ошибки. Недопустимо выпускать на рынок продукт, в коде которого имеются подобные дефекты, даже самых незначительные.
А. Ю. Герасимов предлагает разделять все множество программных ошибок,
приводящих к некорректному поведению программы во время исполнения, на следующие классы по видам вредоносного воздействия:
«ошибки, приводящие к порче пользовательских данных в процессе обработки: целочисленное переполнение, порча данных в оперативной памяти, обращение к неинициализированному блоку памяти, обращение к памяти по неинициализированному или висящему указателю (англ. – dangling pointer), фальсификация данных (англ. - request forgery) и др.;
ошибки, приводящие к неавторизованному доступу к пользовательским данным: получение неавторизованного доступа к базе данных, получение неавторизованного доступа к информации в оперативной или постоянной памяти вычислительного устройства, получение повышенного уровня привилегий доступа к данным и др.; • ошибки, приводящие к исчерпанию системных ресурсов, таких как память на куче, файлы, сокеты и др.;
ошибки, приводящие к аварийному завершению исполнения программы:
доступ к области памяти, не принадлежащей программе, деление на ноль и др.;
ошибки, приводящие к исполнению злонамеренного кода: перехват потока управления злонамеренным кодом, исполнение злонамеренного кода на стороне клиента, внедрение в исполнение команды в командной строке и др.»
[7, с. 15].
Каковы причины появления ошибок? Рассмотрим несколько возможных путей их возникновения.
Во-первых, непонимание разработчиками требований, предъявляемых к программному продукту [24]. Так может происходить, например, когда в приложение вносятся функции без явной необходимости.
Во-вторых, причиной ошибок в коду могут быть разработчики с слабым багажом опыта и знаний.
В-третьих, какие-либо административные причины: слишком сжатые и невозможные для разработки поставленные сроки, отсутствие достаточного времени на отладку и тестирование приложения. Вопрос о приемлемости

поставленных сроков должен обсуждаться всеми разработчиками на основании набора реализуемых функций. В случае излишне сжатых сроков лучше стоит сократить функционал или вовсе отказаться от разработки. Одной из частых причин ошибок в программах является недостаточная вовлеченность и чувство ответственности за результат в команде занимающейся разработкой. Так,
разработчик может постараться сэкономить время и постараться скрыть недобросовестное отношение к написанию кода. Поэтому очень важно, чтобы все в команде разработки осознавали, насколько важен их вклад в то, каким получится итоговый продукт. Производители программного обеспечения, по-настоящему приверженные качеству, должны опираться на тщательное планирование,
персональную ответственность, надлежащий контроль качества и хорошие способности к общению с клиентами и между собой. Только те разработчики,
которые уделяют значительное внимание деталям, будут выпускать продукцию в нужные сроки и отличного качества [29].
Т. Н. Лебедева и Л. С. Носова выделили несколько направлений по предотвращению ошибок:
1. «Использование встроенных возможностей системы программирования на этапе разработки программы (дозапись кода, работа с шаблонами, отладка программы и др.).
2. Разработка кода по отраслевым и специальным стандартам программирования.
3. Использование программ для автоматического и автоматизированного тестирования разработанного приложения» [16, с.55].
Принципы тестирования основываются на вопросах психологии. Принципы в основном интуитивно понятны, однако иногда они остаются без должного внимания. Данные позиции перечислены И.В. Степанченко [28].
1. Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора. Результаты тестирования могут показаться правдоподобными и из-за этого принятыми за правильные. Для минимизации этой проблемы тест должен включать две компоненты: описание входных данных и описание точного и корректного результата, соответствующего набору входных данных.
2. Следует избегать тестирования программы ее автором. Отметим, что данные принцип не исключает полностью тестирование программистом своего кода.

Однако тестирование является более эффективным, если оно выполняется кем- либо другим.
3. Необходимо досконально изучать результаты применения каждого теста.
Неполное изучение результатов оставляет не выявленными ряд ошибок.
4. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать. Необходимо проверить программу на нежелательные побочные эффекты.
5. Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены. Ошибка вытекает из неверного определения тестирования как процесса демонстрации отсутствия ошибок в программе, корректного функционирования программы.
6. Тестирование — процесс творческий. Не исключено, что для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования.
Подытожим. В рамках данной главы мы рассмотрели историю развития тестирования. Мы проследили развитие тестирования от формализованного процесса, схожего больше с современным понимание отладки, до современного его состояния.
Мы перечислили виды тестирования. В связи с многообразия программ и бизнес- задач классификация тестирования имеет вид сложной разветвленной структуры.
В современной практике выделяется две противоположные парадигмы тестирования – поведенческое и структурное. В основе обоих лежит принцип
«ящика»: подходы различаются в исходной информации, доступной инженеру тестирования при работе с программой.
В ходе работы мы выяснили отличия между процессом тестирования и отладки.
Второе является последующим этапом для тестирования, в ходе которого находится «проблемный» код и исправляется.
Исходя из видов ошибок мы рассмотрели причины их появления и пути снижения количества ошибок в программном коде. Мы пришли к выводу, что для разработки продукта с минимизацией ошибок разработчик должен обладать достаточными знаниями, осознавать требования и иметь необходимые и достаточные для разработки сроки.

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

Эти две системы неразрывно связаны между собой. Система отслеживания ошибок фиксирует все дефекты, требующие изменения исходного кода приложения, а система управления версиями проводит регистрацию всех внесенных изменений.
Необходимо постоянно поддерживать связь между обнаруженными проблемами и изменениями исходных текстов. Это помогает выявить причины и последствия исправления обнаруженных ошибок. Если это не делать, то будут возникать непонимания внесенных ранее изменений кода приложения. Не исключены случаи,
что при разработке более поздней версии программы возникнет проблема с уже написанным ранее исходным кодом и данные системы помогут найти сотрудника,
который внес эти изменения.
Существуют специализированные интегрированные средства, которые позволяют автоматически следить за связью изменений исходных кодов приложения с ошибками. В случае отсутствия такой возможности в системе нужно поддерживать связь вручную. При этом в комментариях указывается номер ошибки и способ ее исправления. При регистрации исправленного модуля в системе управления версиями номер найденной ошибки указывается в соответствующем комментарии.
Система управления версиями существует для контроля над исходным кодом, а также для хранения всего, что непосредственно относится к проекту: разные планы тестирования, автоматизация тестов, различная справочная информация, а также проектная служебная документация. Если нужно, то можно включить сюда и средства для сборки приложений: используемые файлы, динамически присоединяемые библиотеки и компиляторы, т.е. все необходимые средства для воссоздания необходимой версии приложения. Включать надо только то, что может потребоваться другим программистам в будущем для сопровождения программного обеспечения.
Многих проблем при разработке программных продуктов можно избежать,
используя в системе управления версиями, так называемые Модульные тесты (unit tests).
Модульное (компонентное) тестирование направлено на проверку отдельных небольших частей приложения, которые (как правило) можно исследовать изолированно от других подобных частей. При выполнении данного тестирования могут проверяться отдельные функции или методы классов, сами классы,
взаимодействие классов, небольшие библиотеки, отдельные части приложения.
Часто данный вид тестирования реализуется с использованием специальных технологий и инструментальных средств автоматизации тестирования,