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

Таблица составлена по:[3;4]

модулей и кончается передачей испытанной системы заказчику или же началом коммерческих продаж ПО. Проанализируем основные этапы работы тестировщиков ПС.

Тестирование модулей системы – самая формализованная и автоматизированная часть тестирования.

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

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

• процедур
• блоков
• условий
• циклов
• и так далее

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

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

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

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

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

До того, как начинать тестировать программный комплекс, необходимо, что бы его составные части (функциональные группы модулей или отдельные функции) были уже кропотливо оттестированы.

3.3. Методы сборки модулей в комплекс

Существует два подхода сборки модулей в программный комплекс:

• монолитный
• пошаговый

Пошаговая сборка бывает или восходящей (снизу-вверх) или же нисходящей (сверху-вниз).

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

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

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

В рассматриваемом примере необходимы модули-драйверы для всех модулей, кроме М1, а модули-заглушки необходимы для всех модулей, кроме как М5, М6, М7, M8, M9 (то есть для всех модулей самого низшего уровня).

M1

M2

M3

M4

M5

M6

M7

M8

M9

Рис. 3.1 – Структура программного комплекса из девяти модулей

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

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

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

Данный процесс будет продолжаться до того момента, пока не будет собрать весь комплекс модулей. Существует возможность некого распараллеливания работ и автономного тестирования цепочек модулей М1-М2-М5 (М6), М1-М3-М7, М1-М4-М8 (М9).

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

Во время тестирования снизу-вверх процесс тестирования проходит в таком виде: проходят тестирование модули низшего уровня – модули М5, М6, М7, М8, М9. И для каждого из данных модулей необходим драйвер.

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

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

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

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

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

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

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

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

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

3.4. Тестирование коммерческих пакетов прикладных пакетов программ

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

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

• альфа-тестирование
• бета-тестирование

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

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

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

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

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

Основные понятия

“Лишь та ошибка, что не исправляется.”

Конфуций

Отладка программного средства (ПС) - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка = Тестирование + Поиск ошибок + Редактирование.

Иногда тестирование и отладку считают синонимами.

Отладка программного средства (ПС) - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка = Тестирование + Поиск ошибок + Редактирование.

Иногда тестирование и отладку считают синонимами.

3.5. Принципы и виды отладки программного средства

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

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