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

Введение

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

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

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

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

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

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

Предмет исследования – виды тестирования, основные подходы и ограничения.

Цель работы – описать этапы процесса разработки, а также подходы к тестированию.

Для достижения данной цели надо будет решить ряд задач:

1. Проанализировать литературу по заданной теме;
2. Описать основные термины;
3. Определить виды тестирования;
4. Описать основные подходы и ограничения.

Глава 1

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

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

Тестирование – это процесс анализа программы с целью обнаружения ошибок.

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

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

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

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

1.2 Этапы тестирования программного обеспечения

Существует несколько этапов стратегии тестирования:

1. Объем тестовых работ путем анализа документов, которые содержат требование к программе.
2. Выбор статических и динамических тестов, связанных со стадиями разработки.
3. Критерии входа и выхода для каждой стадии тестирования.
4. Автоматизация в случае того, если планируется использование какого-либо вида тестовой деятельности.

Объем тестовых работ

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

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

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

Подход к тестированию

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

1. Каскадная модель – это модель процесса разработки программного обеспечения, в котором процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
2. Спиралевидная модель – это модель процесса разработки программного обеспечения, сочетающий в себе как итеративность, так и этапность.
3. Итеративная модель – это модель процесса разработки программного обеспечения, в котором происходит выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.

Возьмем каскадную модель и выясним, какие виды тестирования могут для нее использоваться:

1. Стадия формулирования требований
2. Стадия системного проектирования
3. Стадии тестирования проектов программ, программных кодов.
4. Системные испытания
5. Регрессионное тестирование
6. Подход к тестированию должен отражаться в документах
7. Определение критериев тестирования и точек контроля качества
8. Есть пять критериев, которые могут определяться перед началом системного тестирования:
9. Критерий входа, который показывает, что нужно сделать перед началом тестирования.
10. Критерий выхода, который показывает то, что необходимо для завершения испытаний.
11. Критерий приостановки/возобновления, который показывает нам, что произойдет, если из-за дефектов продолжение тестирования окажется невозможным.
12. Критерий успешного/неудачного теста. Прогоняет каждый тест, который должен давать заранее известные результаты.

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

Стратегии автоматизации

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

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

1.3 Цели и задачи тестирования программного обеспечения

Цели тестирования:

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

Задачи тестирования:

1. Проверить, что система работает в соответствии с определенными временами оклика клиента и сервера.
2. Проверить, что наиболее критические последовательности действий с системой конечного пользователя выполнятся верно.
3. Проверить работу пользовательских интерфейсов.
4. Проверить, что изменения в базах данных не отказывают неблагоприятного влияния на существующие программные модули.
5. При проектировании тестов свести к минимуму переработку тестов при возможных изменениях приложения.
6. Использовать инструменты автоматизированного тестирования там, где это целесообразно.
7. Проводить тестирование таким образом, чтобы не только обнаруживать, но и предупреждать дефекты.
8. При проектировании автоматизированных тестов использовать стандарты разработки таким образом, чтобы создать многократно используемые и сопровождаемые скрипты.

1.4 Комплексное тестирование программного обеспечения

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

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

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

1.5 Восходящее и нисходящее тестирование

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

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

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

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