Преподаватель который помогает студентам и школьникам в учёбе.

Отладка и тестирование программ: основные подходы и ограничения

Содержание:

ВВЕДЕНИЕ

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

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

В силу этого обстоятельства к специалистам по тестированию современного программного обеспечения предъявляются следующие основные требования:

1. Необходимо тестировать быстро, соблюдая жесткие сроки поставки программных продуктов;

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

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

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

Для достижения поставленной цели необходимо:

1. Изучить понятие и стадии тестирования;

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

Рассмотрение первого вопроса – изучение понятия и стадии тестирования будет производиться в первой главе курсовой работы. Для этого будут произведены следующие действия: рассмотрен наращиваемый подход в тестировании; рассмотреть стадии тестирования.

Изучение второго вопроса – рассмотрение вопросов тестирования и отладки программного обеспечения будет производиться во второй главе курсовой работы. Для этого будут произведены следующие действия: изучена стратегия тестирования; рассмотрены виды тестирования; рассмотрена отладка программного обеспечения.

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

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

1. Понятие и стадии тестирования

1.1 Наращиваемый подход в тестировании

Как правило, встречаются следующие трудности: большое и сложное приложение; ограниченная осведомленность о приложении или же ее полное отсутствие; неадекватная пользовательская документация; слабые знания о тестировании программного обеспечения; нет доступа к справке или руководству по тестированию программного обеспечения; нереальные сроки завершения тестирования [14].

Для эффективной работы тестер программного обеспечения должен:

1. Знать метод тестирования программного обеспечения;

2. Знать тестируемое приложение;

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

Чтобы уложиться в эти сроки, тестирование приложения целесообразно разделить на восемь последовательных стадий. На первых стадиях путем оценки точности результатов определяется, работает ли приложение в нормальных условиях. На последних стадиях предпринята попытка вывести систему из строя [4].

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

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

Если времени для проведения тестирования достаточно, то целесообразно распланировать задачи тестирования следующим образом [10]:

1. Спроектировать тесты, используя методы, описанные в последующих главах;

2. Создать подходящую для проведения теста среду тестирования;

3. Оценить, приобрести и установить инструменты автоматического тестирования;

4. Написать соответствующую документацию, связанную с тестированием.

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

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

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

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

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

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

Главная задача изучения заключается в том, чтобы максимально раскрыть все сведения о приложении, используя его функции. Когда тестер будет создавать тест на основании собственных наблюдений в ходе изучения текущего исследования, он применит метод исследовательского тестирования [1].

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

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

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

В зависимости от приложения можно выделить несколько источников определения ожидаемых результирующих данных [17]:

Специалист или авторитетное лицо проекта, знающий все о его работе.

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

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

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

В некоторых приложениях авторитетное лицо проекта также определяет допустимый предел погрешности. Например, конкретные результаты вычислений могут изменяться за счет округлений чисел [5].

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

Создание среды тестирования состоит из нескольких этапов [15]:

Установка приложения.

Программирование и установка инструментов для автоматизации процесса тестирования.

Настройка специальных файлов и занесение данных для тестирования.

Создание соответствующих утилит для поддержки связи с приложением.

Приобретение корректного аппаратного обеспечения и оборудования.

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

Третья стадия тестирования представляет собой анализ тенденций. Это не обязательная стадия, которая полезна лишь в процессе выполнения некоторых важных условий. Анализ тенденций необходим в случае поверхностного знакомства с приложением, а также в случае, когда сложно вычислить ожидаемый результат, либо имеется предположение относительно диапазона ожидаемых результатов [2].

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

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

Результатом инвентаризации является таблица контрольных проверок элементов. Если изолировать влияние каждого отдельного элемента из инвентарного списка, то можно узнать, правильно ли обрабатывает его приложение [17].

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

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

Причины возникновения проблем могут быть различными. Среди них можно выделить следующие [18]:

Пропущенные требования.

Двусмысленные или непонятные требования.

Требования, которые не сообщили тестеру.

Неверное определение ожидаемых результатов.

Возникновение проблемы в ходе проведения теста.

Дефект в программном обеспечении.

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

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

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

Индивидуальная обработка каждого отдельного файла.

Обработка одного файла и генерация одного прерывания.

Обработка двух файлов.

Обработка двух файлов и генерация одного прерывания.

Обработка двух файлов и генерация двух прерываний.

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

Шестая стадия тестирования представляет собой граничные оценки. До настоящего времени в тестах использовались типичные сценарии. Следующий этап заключается в исследовании пределов возможностей приложения. Такие пределы определяются данными и могут принимать самые разные формы в зависимости от типа данных. В качестве примера можно привести максимальные и минимальные значения диапазона данных, максимальный и минимальный размер поля, а также максимальный и минимальный размер буфера [13].

Общее правило для тестирования границ заключается в создании трех тестовых примеров для охвата следующих значений [11]:

граничное значение;

граничное значение -1;

граничное значение +1

Седьмая стадия тестирования представляет собой ошибочные данные. На этой стадии тестирования делается попытка выведения приложения из строя путем создания критических условий работы пользователя. Рассмотрим создание тестов нескольких категорий [11]:

Данные не вводятся для того, чтобы отследить поведение приложения.

Данные вводятся в виде неправильных чисел.

Данные имеют формат, который считается недопустимым.

Данные используются в необычной комбинации.

Проверяется нулевое значение.

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

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

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

В некоторых случаях предыдущую стадию тестирования можно исключить и сосредоточиться на том, чтобы вывести систему из строя. У такого подхода есть свои преимущества. Самая лучшая тактика – это анализ риска для определения направления приложения усилий. Необходимо проанализировать риск и узнать, за счет чего система отказывается от работы. Когда тестированием продукта занимается сразу несколько человек, один из них может посвятить все свое время поиску серьезных ошибок [13].

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

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

Оценка рабочих характеристик включает в себя измерение времени на выполнение отдельных операций. Характерные времена изменяются если приложение запускается в загруженной или специализированной системе. Также главным аспектом влияния на рабочие характеристики системы является тестирование напряженности рабочей среды. Этот аспект включает в себя следующие тесты [10]:

Сокращение объема доступной памяти.

Использование доступного дискового пространства.

Параллельный запуск нескольких экземпляров приложения.

Запуск приложения в тот момент, когда система занимается резервированием.

Генерация множества асинхронных и управляемых событиями процессов.

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

Существуют и такие тесты, которые способны полностью прекратить работу приложения путем его повреждения. Таким образом, после тестирования пользователь будет постоянно «выпадать» из приложения. Кроме этого, тестер может использовать тактику отключения питания или кабеля при проверке [20].

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

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

2.1 Стратегия тестирования

Стратегия тестирования, или методы тестирования - это систематические методы, используемые для отбора и/или создания тестов, которые должны быть включены в тестовый комплект. Это могут быть случайные вводы, тест, направленный на проверку моих подозрений, тест, направленный на проверку ваших подозрений, тест, направленный на проверку соответствия требованиям, тест, направленный на проверку искаженности; тесты, который мы выполняли последний раз, тесты, которые отличаются от тестов, которые мы выполняли последний раз [7]. Мы выбираем стратегию, такую, что существуют правила, по которым мы можем определить, удовлетворяет данный тест стратегии или не удовлетворяет. В принципе, стратегия должна быть программируемой [16].

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

Стратегия поведенческого теста основана на технических требованиях. Например: тест всех характеристик, упомянутых в спецификации, выполнение всех грязных тестов, вытекающих из требований. Тестирование, выполняемое с помощью стратегии поведенческого теста, называется поведенческим тестированием. Поведенческое тестирование называется также тестированием черного ящика. Для поведенческого тестирования также используется термин функциональное тестирование. При поведенческом тестировании не обязательно знать, как объект сконструирован [13].

Стратегия структурного теста определяется структурой тестируемого объекта [BASI87, BEIZ90, NTAF88, OSTR96]. Например: выполнение каждого оператора, по меньшей мере, один раз, выполнение каждой ветви, но меньшей мере один раз, тестирование использования всех объектов данных, выполнение каждой команды объектной программы, полученной при компиляции. Тестирование, выполненное с помощью стратегии структурного теста, называется также тестированием прозрачного ящика или тестированием белого ящика. Стратегия структурного теста требует полного доступа к структуре объекта - то есть к исходному коду [1].

Стратегия гибридного теста является комбинацией поведенческой и структурной стратегий [CLAR76, RICH81]. Поведенческая, структурная и гибридная стратегии не противоречат друг другу, и ни про одну из них нельзя сказать, что она лучше других. Модули и низкоуровневые компоненты часто тестируются с помощью структурной стратегии. Большие компоненты и системы в основном тестируются с помощью поведенческой стратегии. Гибридная стратегия полезна на всех уровнях. Не существует лучшей стратегии, так как полезность стратегии зависит от природы тестируемого объекта, природы ошибок объекта и уровня ваших знаний [5].

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

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

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

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

Отображают трассировочное сообщение и предлагают тестеру продолжить свое тестирование.

Осуществляют упрощенную реализацию недостающих компонентов.

Возвращают постоянное значение или же предлагают тестеру самостоятельно ввести возвращаемое значение.

Имитируют аварийные и исключительные условия [1].

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

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

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

При тестировании системы проводится проверка всего объекта. После того, как программные и аппаратные компоненты будут собраны, подтверждается соответствие исходным требованиям проекта. Если система полностью укомплектована, то тестер сможет оценить практически все ее атрибуты, которые нельзя протестировать на более низких уровнях [10].

Основные категории тестирования системы:

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

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

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

Тестирование установки проводится для того, чтобы полная, частичная, либо обновляемая процедура установки функционировала согласно документации.

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

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

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

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

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

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

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

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

2.3 Отладка программного обеспечения

Отладка программного обеспечения представляет собой процесс, во время которого работа программ корректируется с учетом требуемых характеристик и задач пользователей [7].

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

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

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

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

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

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

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

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

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

Статические методы заключаются в:

Ручной прокрутке программы.

Прокрутке программы с помощью анализатора (компилятора). В данном случае автоматизированный анализ программы проводится без ее выполнения на ЭВМ, поэтому попадает в категорию «статических» [13].

Коллективной проверке программы.

Проверке программы специалистом-технологом для выявления и исправления технологических ошибок.

При проведении различных экспериментов установлено, что при использовании ручных методов проверки удается обнаружить от 30 до 70% алгоритмических ошибок из общего числа всех ошибок программы. Одновременно с этим проводится доработка программы для улучшения ее структуры, логики обработки данных, а также снижения сложности автоматизированного тестирования на ЭВМ [17].

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

К динамическим методам относятся [3]:

1. Тестирование;

2. Поиск ошибок с использованием системных средств;

3. Отладка программы в интерактивном режиме.

Важнейшее правило отладки: не делать следующего выхода на электронно-вычислительной машине, пока не будет разобрана каждая найденная ошибка. Из этого правила существует единственное исключение: если найдены 5-6 ошибок, которые не дают эффекта, то можно сделать новый выход на машину (устранив эти ошибки), чтобы получить эффект в чистом виде (если он есть), поскольку наложение нескольких ошибок иногда может дать самый неожиданный результат [9].

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

ЗАКЛЮЧЕНИЕ

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

Для достижения поставленной цели было необходимо:

1. Изучить понятие и стадии тестирования;

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

Рассмотрение первого вопроса – изучение понятия и стадии тестирования производилось в первой главе курсовой работы. Для этого были произведены следующие действия: рассмотрен наращиваемый подход в тестировании; рассмотреть стадии тестирования.

Если времени для проведения тестирования достаточно, то целесообразно распланировать задачи тестирования следующим образом:

1. Спроектировать тесты, используя методы, описанные в последующих главах;

2. Создать подходящую для проведения теста среду тестирования;

3. Оценить, приобрести и установить инструменты автоматического тестирования;

4. Написать соответствующую документацию, связанную с тестированием.

Изучение второго вопроса – рассмотрение вопросов тестирования и отладки программного обеспечения производилось во второй главе курсовой работы. Для этого были произведены следующие действия: изучена стратегия тестирования; рассмотрены виды тестирования; рассмотрена отладка программного обеспечения.

Стратегия тестирования, или методы тестирования - это систематические методы, используемые для отбора и/или создания тестов, которые должны быть включены в тестовый комплект. Это могут быть случайные вводы, тест, направленный на проверку моих подозрений, тест, направленный на проверку ваших подозрений, тест, направленный на проверку соответствия требованиям, тест, направленный на проверку искаженности; тесты, который мы выполняли последний раз, тесты, которые отличаются от тестов, которые мы выполняли последний раз. Мы выбираем стратегию, такую, что существуют правила, по которым мы можем определить, удовлетворяет данный тест стратегии или не удовлетворяет. В принципе, стратегия должна быть программируемой [20].

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Афонин В.Л., Моделирование систем: учебно-практическое пособие [Текст] / В.Л. Афонин - М.: Интернет-Университет Информационных Технологий (ИНТУИТ), 2016. – 232 с.
Баженова И.Ю., Основы проектирования приложений баз данных [Текст] / И.Ю. Баженова - М.: Интернет-Университет Информационных Технологий (ИНТУИТ), 2016. – 261 с.
Базовые средства программирования на Visual Basic в среде VisualStudio Net. Практикум: Учебное пособие. Гриф МО РФ [Текст] - М.: Инфра-М Форум, 2017. – 288 с.
Голицына О.Л., Основы проектирования баз данных. [Текст]: Учебное пособие / О.Л. Голицына - М.: Форум, 2016. – 416 с.
Дадян Э.Г., Методы, модели, средства хранения и обработки данных [Текст] / Э.Г. Дадян - М.: Инфра-М, 2017. – 268 с.
Даниленко А.В., Безопасность систем электронного документооборота. Технология защиты электронных документов [Текст] / А.В. Даниленко - М.: URSS, 2015. – 232 с.
Джесси Р., Проектирование баз данных [Текст] / Р. Джесси - М.: VSD, 2013.
Долганова О.В., Моделирование бизнес-процессов. Учебник и практикум для академического бакалавриата [Текст] / О.В. Долганова - М.: Издательство: Юрайт, 2016. – 289 с.
Иванова Г.С., Объектно-ориентированное программирование [Текст] / Г.С. Иванова - М.: Московский Государственный Технический Университет (МГТУ) имени Н.Э. Баумана, 2014. – 456 с.
Кагаловский, М.Р. Технология баз данных на персональных ЭВМ [Текст] / М.Р. Кагаловский − М.: Финансы и статистика, 2014. – 224 с.
Казанский А.П., Объектно-ориентированный анализ и программирование на visual basic 2013. Учебник для прикладного бакалавриата [Текст] / А.П. Казанский - М.: Юрайт, 2016. – 290 с.
Казиев В.М., Введение в анализ, синтез и моделирование систем. Учебное пособие [Текст] / В.М. Казиев - М.: Интернет-Университет Информационных Технологий (ИНТУИТ), 2014. – 244 с.
Кириллов В.В., Введение в реляционные базы данных. Учебник (+ CD-ROM) [Текст] / В.В. Кириллов - М.: БХВ-Петербург, 2017. – 464 с.
Козлов В., Системный анализ, оптимизация и принятие решений. Учебное пособие [Текст] / В. Козлов - М.: Проспект, 2016. – 76 с.
Культин Н.Б., Visual Basic. Освой на примерах (+ CD-ROM) [Текст] / Н.Б. Культин - М.: БХВ-Петербург, 2012. – 288 с.
Кумскова И.А., Базы данных. Учебник. Гриф МО РФ [Текст] / И.А. Кумскова - М.: КноРус, 2016. – 400 с.
Лукин С.Н., Visual Basic: самоучитель для начинающих [Текст] / С.Н. Лукин - М.: Диалог-МИФИ, 2012. – 480 с.
Малкин Г.Е., Учимся моделировать в среде Visual Basic [Текст] / Г.Е. Малкин - М.: Нобель Пресс, 2012. – 210 с.
Мартишин С.А., Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench. Учебное пособие. Методы и средства проектирования информационных систем и технологий. Инструментальные средства информационных сетей. Гриф УМО вузов России [Текст] / С.А. Мартишин - М.: Форум, 2017. – 160 с.
Назаров С.В., Архитектура и проектирование программных систем [Текст] / С.В. Назаров - М.: Инфра-М, 2016. – 376 с.