Файл: Тестирование и отладка программного обеспечения..pdf

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

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

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

Есть два основных метода борьбы с подобными ошибками. С одной стороны, необходимо на этапе проектирования установить конкретные требования к производительности программного продукта. Для выявления проблем с производительностью нужно сравнить основные показатели работы приложения под разными нагрузками. Если вдруг происходит потеря производительности допустимый предел, то необходимо принять меры и выяснить – по какой причине это произошло и внести нужные изменения в код. Далее надо убедиться в том, что нагрузка действительно соответствует наиболее близким к реальной жизни сценариям, и делать это нужно на самых ранних этапах проектирования [24].

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

А. Ю. Герасимов предлагает разделять все множество программных ошибок, приводящих к некорректному поведению программы во время исполнения, на следующие классы по видам вредоносного воздействия:

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

Каковы причины появления ошибок? Рассмотрим несколько возможных путей их возникновения.

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

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

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

Т. Н. Лебедева и Л. С. Носова выделили несколько направлений по предотвращению ошибок:

1. «Использование встроенных возможностей системы программирования на этапе разработки программы (дозапись кода, работа с шаблонами, отладка программы и др.).

2. Разработка кода по отраслевым и специальным стандартам программирования.

3. Использование программ для автоматического и автоматизированного тестирования разработанного приложения» [16, с.55].

Принципы тестирования основываются на вопросах психологии. Принципы в основном интуитивно понятны, однако иногда они остаются без должного внимания. Данные позиции перечислены И.В. Степанченко [28].

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

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

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

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

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

6. Тестирование — процесс творческий. Не исключено, что для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования.

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

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

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

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

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

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

Глава 2. ПРАКТИКА ОТЛАДКИ ПРИЛОЖЕНИЙ В СРЕДЕ JAVASCRIPT

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

2.1 Инструментарий поиска и отслеживания ошибок

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

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

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

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

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

Многих проблем при разработке программных продуктов можно избежать, используя в системе управления версиями, так называемые Модульные тесты (unit tests).

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