Файл: Отладка и тестирование программ: основные подходы и ограничения (Модульное тестирование).pdf

ВВЕДЕНИЕ

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

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

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

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

Объектом исследования является организация процесса тестирования.

Предметом исследования является тестирование программ. Целью работы является анализ видов тестирования.

Для реализации поставленной цели необходимо решение следующих задач:

1. Дать основные понятия тестированию и отладки.

2. Рассмотреть уровни тестирования.

3. Охарактеризовать процесс тестирования 4. Разработать программу.

5. Провести анализ литературы по избранной теме.

Основные авторы, в научных работах которых рассматривалась проблема исследования: П.В. Котляров, В. Н. Цыганенко и др.

Глава 1. Автоматизация регрессионного тестирования

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

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

Нефункциональные тесты.

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

Функциональные требования включают в себя:

Функциональную пригодность.

Точность.

Способность к взаимодействию.

Соответствие стандартам и правилам.

Защищённость.

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

стрессовое тестирование.

тестирование стабильности или надежности.

объемное тестирование.

Тестирование установки.

Тестирования для удобства пользования. Тестирование на отказ и восстановление.

Конфигурационное тестирование. Также существуют виды тестирования, которые связаны с изменениями.

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

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

Регрессионное тестирование.

Дымовое тестирование.

Тестирование сборки.

Санитарное тестирование (проверка согласованности или исправности).Тестирование безопасности. Это тестирование используется для проверки безопасности системы, выявление рисков, которые связаны с обеспечением целостного подхода к защите приложения, также от несанкционированного доступа, вируса, атаки взломщиков [8].

Основные принципы безопасности программного обеспечения. Стратегия безопасности базируется на трех принципах:

Целостность.

Доступность.

Конфиденциальность.

Для определения целостности существует два основных понятия:

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

Доступность. Это требование о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть.

Конфиденциальность.

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

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

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

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

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

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

определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций);исследование производительности на высоких, предельных, стрессовых нагрузках.

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

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

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

Объемное тестирование.

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

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

Тестирование стабильности.

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

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

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

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

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

Регрессионное тестирование.

Это тестирование рекомендуется проводить после исправления программы, а именно исправление бага, объединение кода, интеграция на другую операционную систему.

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

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

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

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

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

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

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

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

Потерю данных после установки более новой версии программы.

Невозможность отката до предыдущей версии.

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