Файл: Отладка и тестирование программ: основные подходы и ограничения (ПОНЯТИЕ ТЕСТИРОВАНИЯ И ОТЛАДКИ).pdf

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

1. Дать основные понятия тестированию и отладки.
2. Рассмотреть уровни тестирования.
3. Охарактеризовать процесс тестирования
4. Разработать программу.
5. Провести анализ литературы по избранной теме.

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

1. ПОНЯТИЕ ТЕСТИРОВАНИЯ И ОТЛАДКИ

1.1. История развития

Раньше тестирование представляло собой довольно примитивный процесс и не справлялось с задачами, которые были на него возложены:

1. Повышения качества за счет покрытия максимальной функциональности продукта.
2. Уменьшение времени тестирования.
3. Снижение денежных затрат на тестирование.

Развитие тестирования происходило в два больших этапа.

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

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

1. Организацию и финансирование тестирования.
2. Определение правильного направления.

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

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

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

В книге Глендфорда Майерса: “Искусство тестирования ПО” приводится следующий пример: ВВС США при разработке программного обеспечения ввели в практику заключение отдельных контрактов с компанией-разработчиком и компанией-тестером. Впоследствии ВВС создала отдельную компанию для проведения тестирования и испытаний программного обеспечения. Такой подход получил высокую оценку и был признан единственно верным при разработке критически важных приложений” [4].

В начале 90-х годов расцветает объектно-ориентированных подход к разработке программного обеспечения. Начинают набирать популярность такие стандарты как ISO и CMM. Разработчики стараются обходиться без независимых тестовых агентств и возлагают надежды на передовые средства разработки и методы управления. Качество программного продукта действительно повышается. Но возникает новая проблема – это высокий темп разработки, быстрые изменения требований к продукту, нехватка ресурсов, сложность систем возрастает многократно. Начинается поиск новых решений, набирается сила глобализации разработки программного обеспечения. Тестирование адаптируется и получает новые формы [2].

1.2. Основные определения

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

Тестирование программного обеспечения (Software Testing) – это проверка на соответствие между ожидаемым поведением программы и реальным. Как правило, осуществляется на конечном наборе тестов. Также тестирование представляет собой контроль качества, который включает:

1. активность по планированию работ (Test Management).
2. проектирование тестов (Test Design).
3. выполнение тестирования (Test Execution).
4. анализ полученных результатов (Test Analysis).

Верификация (Verification) – является процессом оценки системы, а также ее компонентов с целью определения удовлетворения текущего этапа разработки заявленным условиям на первом этапе. Другими словами проверка целей, сроков и задач по разработке проекта с предыдущей фазой [6].

Валидация (Validation) – это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [10].

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

Тест дизайн (Test Design). На этом этапе процесса тестирования программного продукта проектируются и создаются тестовые случаи (кейсы), в соответствии с ранними критериями качества и целями тестирования [17].

Как было сказано ранее, существуют тестовые случаи, иногда их называют тестовый кейс. Что же это такое?

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

Как в любой программе, возникают ошибки и необходимо дать определением этим ошибкам. Как правило, их называют баг или дефект репорт.

Баг/Дефект Репорт (Bug Report) – это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата [22].

Тестовое Покрытие (Test Coverage) – является мерой оценки качества тестирования [15].

Детализация Тест Кейсов (Test Case Specification) – насколько детализировано, описаны тестовые шаги и конечный результат, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию.

Время Прохождения Тест Кейса (Test Case Pass Time) – время, которое затрачивается от начала прохождения шагов тест кейса и до получения результата теста [3].

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

Программные ошибки делятся на следующие виды:

1. Синтаксические ошибки – неверное употребление синтаксических конструкций.
2. Семантические ошибки – нарушение семантики конструкции
3. Логические ошибки – нарушение логики программы, обычно кроются в алгоритмах программы [4].

1.3. Уровни тестирования

Уровни тестирования можно разделить на следующие виды:

1. Модульное
2. Комплексное
3. Системное
4. Приемочное
5. Операционное

Модульное тестирование.

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

Входными требованиями является архитектура компонентов или модель «нижнего уровня» системы Component Design.

Объектом тестирования являются разработанные компоненты.

Комплексное тестирование.

Комплексное тестирование называют иногда сборочным тестированием. На этом уровне тестированию подвергаются объединенные элементы общей системы, наиболее часто некоторая группа элементов. Направлено на проверку взаимодействия компонентов в соответствии с «Архитектурой системы». Тесты проверяют все интерфейсы взаимодействие между компонентами до тех пор, пока все компоненты не будут разработаны, отлажены и проинтегрированы друг с другом в единую систему [13].

Входными требованиями является архитектура системы или модель «верхнего уровня» системы System Design.

Объектом тестирования выступает собранная из компонентов система.

Затем следует системное тестирование. После сборки системы из составляющих компонентов, она тестируется на соответствие «Системным спецификациям».

Проверяется, насколько реализованы ли все функциональные и нефункциональные требования к разрабатываемой системе.

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

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

Приемочное тестирование.

Оно также называют приемо-сдаточное тестирование. Приложение или система тестируется заказчиком, конечными пользователями или соответствующими уполномоченными с целью определения соответствия системы “Требованиям Заказчика” и готовности системы к внедрению. Приемосдаточные испытания оформляют процесс передачи продукта от Разработчика Заказчику [12].

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

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

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

Операционное тестирование.

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