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

Отладка и тестирование программ

Содержание:

ВВЕДЕНИЕ

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

Актуальность курсовой работы обусловлена тем, что в современном мире с растущими потребностями рынка программного обеспечения (далее ПО) растёт и его качество. Прежде чем программа попадёт к конечному пользователю она подвергается тщательному тестированию и отладке и этот процесс крайне важен, и на него выделяются значительные временные и финансовые ресурсы (около 45% бюджета проекта). Именно отладка и тестирование позволяют определить качество программного продукта и поэтому это крайне важный этап разработки.

Цели работы:

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

Задачи курсовой работы:

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

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

В качестве базы было выбрано учебное пособие «Технология разработки прикладного программного обеспечения» авторами которого являются: Соловьев С.В., Цой Р.И., Гринкруг Л.С. Издательство: Академия Естествознания. В данном пособии содержится общая характеристика тестирования и отладки программного обеспечения, также принципы формирования тестов и сборки модулей программы в единую, корректно работающую систему. Достаточно подробно рассмотрены основные этапы и методологии тестирования, особенности построения тестовых наборов. Содержание глав иллюстрируется таблицами, рисунками, примерами.

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

ГЛАВА 1.

Понятие тестирования и отладки

1.1. Отладка и тестирование

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

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

Отладка в себя включает:

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

Из этих трёх перечисленных видов работ самым дорогостоящим и трудозатратным процессом является тестирование. Затраты на него приближаются к 45% общих трат на проект.

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

Результаты психологических исследований показывают, что если перед человеком ставится невыполнимая задача, то он работает хуже. Например, если предложить кому-то решить кроссворд в воскресном номере «Нью-Йорк Таймс» за 15 минут, то через 10 минут не будет достигнут значительный успех; ведь понятно, что это невыполнимая задача. Если же на решение отводится четыре часа, то через 10 минут результат окажется лучше [6]. Иными словами, определение тестирования как процесса обнаружения ошибок переводит его в разряд решаемых задач и таким образом преодолевается психологическая трудность.

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

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

1.2. Особенности тестирования

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

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

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

Обобщая опыт тестировщиков можно выделить несколько правил проведения тестирования.

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

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

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

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

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

е) Тест должен содержать два компонента:

описание входных данных
описание точного и корректного результата соответствующего набору входных данных

Необходимость этого подчеркивал логик Копи в работе[2]: «Проблема может быть охарактеризована как факт или группа фактов, которые не имеют приемлемого объяснения, которые кажутся необычными или которые не удается подогнать под наши представления или предположения. Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов»

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

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

Отладка (debugging) не представляет собой разновидность тестирования. Пусть понятия «тестирование» и «отладка» нередко применяются в качестве синонимов, несмотря на это под ними подразумеваются различные процессы.

Тестирование (testing) – исполнения программы или ее части для того,

что бы обнаружить ошибки.

Испытание (validation) – поиск ошибок, путём выполнения программы в заданной реальной среде.

Контроль (verification) – поиск ошибок, путём выполнения программы в моделируемой, тестовой среде.

Аттестация (certification) – Достоверное доказательство корректности программы. Во время процесса аттестации происходит сравнение с предопределённым ранее стандартом.

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

Тестирование – это деятельность, направленная на обнаружение ошибок.

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

Тестирование модуля, или автономное тестирование (module testing, unit testing) – контроль отдельного программного модуля, обычно в изолированной среде (изолированно от всех остальных модулей).

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

Тестирование сопряжений (integration testing) – контроль сопряжений между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing) – контроль внешнего поведения, определенного внешними спецификациями.

Комплексное тестирование (system testing) – контроль и/или испытание системы по отношению к исходным целям.

Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной среде.

Тестирование приемлемости (acceptance testing) – проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) – проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

Отношения между этими типами тестов и процессами проектирования показаны в приложении А (стр. 47).

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

1.4. Экономика тестирования

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

Итог первой главы

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

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

ГЛАВА 2.

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

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

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

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

тестирование по отношению к спецификациям (не заботясь о тексте программы)
тестирование по отношению к тексту программы (не заботясь о спецификациях)

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

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

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

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

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

2.2. Интеграция модулей

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

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

2.3. Методы тестирования

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

а) статический

б) детерминированный

в) стохастический

г) в реальном масштабе времени

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

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

Статическое тестирование – методология тестирования, проводящаяся без непосредственного использования ЭВМ путём просмотра текста программы после трансляции, путём контроля правил структурного построения программ и обработки данных. Как эталон воспринимаются во-первых, внутренние спецификации, во-вторых, совместный опыт специалистов-тестировщиков. Использование данного подхода является достаточно эффективным. По данным компании IBM, для типичных программ можно найти от 30% до 80% ошибок кодирования и логического проектирования. Благодаря данному подходу можно существенно увеличить эффективность а так же надежность программного обеспечения, а так же следуя этому методу можно раньше обнаружить ошибки, из чего следует уменьшить стоимость их исправления.

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

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

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

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

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

2.3.2. Нисходящее тестирование

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

В ходе применения такого подхода появляются два вопроса:

а) Что необходимо делать в том случае, когда тестируемый модуль требует вызвать модуль, которого в данный момент ещё не существует (модуль более низкого уровня), и как подаются тестируемые данные? Решением данного вопроса будет программирование модулей-заглушек, для имитации функций отсутствующих модулей, которые моделируют функции недостающих модулей. Зачастую написание «заглушки» может оказаться трудоёмкой и непонятной, а фраза «напишите заглушку» часто может ввести в заблуждение. Это происходит потому что заглушка обычно не сводится просто к оператору RETURN, так как вызывающий модуль, как правило, ожидает от неё входных данных. В данных случаях заглушку оснащают фиксированными выходными данными, которые она возвращает каждый раз. Но иногда это может оказаться неприемлемым, поскольку вызывающий модуль может рассчитать, что результат вызова зависит от входных данных. По этой причине в особенных случаях заглушку следует сделать достаточно изощренной, и по сложности приближаясь к модулю, который она пытается моделировать.

б) В какой форме необходимо подготовить тестовые данные и как

передать их программе? Ответ был бы простым, если бы головной модуль хранил в себе все необходимые операции ввода и вывода: тесты пишутся в виде привычных для пользователей внешних данных и подаются в программу с помощью выделенных ей устройств ввода. Но так просто получается редко. Физические операции ввода-вывода в хорошо спроектированных программах исполняются на нижних уровнях структуры, по той причине, что физический ввод-вывод – абстракция достаточно низкого уровня. С целью эффективно решить проблему с экономической стороны, модули в программу добавляются не строго в нисходящей последовательности (сначала все модули одного горизонтального уровня, после все модули следующего уровня), а таким путём, что бы операции физического ввода-вывода начали функционировать как можно быстрее. После того как вы достигните этой цели, нисходящее тестирование получает особое преимущество над другими методами тестирования: последующие тесты приводятся в такой же форме, которая рассчитана на пользователя.

Преимущества нисходящего подхода

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

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

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

Ограничения нисходящего подхода

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

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

2.3.3. Модифицированный нисходящий метод

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

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

2.3.4. Метод большого скачка

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

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

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

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

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

2.3.5. Метод сандвича

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

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

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

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

2.3.6. Модифицированный метод сандвича

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

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

Итог второй главы

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

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

ГЛАВА 3.

Сравнение методов тестирования, отладка программных средств

3.1. Критерии сравнения методов тестирования

Если посмотреть с точки зрения надежности программного обеспечения можно оценить стратегии тестирования по семи критериям:

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

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

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

г) Четвертый критерий – необходимость наличия драйверов для проведения процесса тестирования

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

е) Шестой критерий – это критерий, который связан с таким вопросом: „имеется ли возможность проверить любое условие в системе и любой имеющийся путь?”

ж) Седьмой критерий – охарактеризовывает сложность управления процессом тестирования, планирования.

Сравнение по всем этим критериям показано в таблице 3.1 на странице 24.

3.2. Этапы тестирования

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

Метод		Восход.	Нисход.	Модиф. нисход.	Метод большого скачка	Метод сандвича	Модиф. метод сандвича
Сборка		Рано	Рано	Рано	Поздно	Рано	Рано
Время до созда работающего прототипа программы	ния	Поздно	Рано	Рано	Поздно	Рано	Рано
Необходимы для драйверы	ли	Да	Нет	Да	Да	Частично	Да
Необходимы драйверы	ли	Нет	Да	Да	Да	Частично	Частично
Параллелизм начале работы	в	Средний	Слабый	Средний	Высокий	Средний	Высокий
Возможность тестирования конкретных пут	ей	Легко	Трудно	Легко	Трудно	Средне	Легко
Возможность планирования и контролирования последовательности		Легко	Трудно	Трудно	Легко	Трудно	Трудно

Таблица 3.1 – Качественная оценка подходов сборки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В рассматриваемом примере необходимы модули-драйверы для всех модулей, кроме М1, а модули-заглушки необходимы для всех модулей, кроме как М5, М6, М7, 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) между следующими двумя крайними подходами.

Рис. 17. Подходы к проектированию тестов

Источник: [7]

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

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

на каждую используемую функцию или возможность - хотя бы один тест;

на каждую область и на каждую границу изменения какой-либо

входной величины - хотя бы один тест; на каждую особую (исключительную) ситуацию, указанную в спецификациях - хотя бы один тест.

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

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

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

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

3.6. Автономная отладка программного средства

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

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

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

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

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

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

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

К достоинствам нисходящего тестирования относятся следующие его особенности:

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

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

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

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

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

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

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

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

3.7. Комплексная отладка программного средства

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

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

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

Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Далеко не каждый примитив качества ПС может быть испытан тестированием. Завершенность ПС проверяется уже при тестировании внешних функций. На данном этапе тестирование этого примитива качества может быть продолжено, если требуется получить какую-либо вероятностную оценку степени надежности ПС. Однако методика такого тестирования еще требует своей разработки. Могут тестироваться такие примитивы качества, как точность, устойчивость, защищенность, временная эффективность, в какой-то мере эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств. Каждый из этих видов тестирования имеет свою специфику и заслуживает отдельного рассмотрения. Легкость применения ПС (критерий качества, включающий несколько примитивов качества) оценивается при тестировании документации по применению ПС.

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

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

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

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

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

В соответствии с ГОСТ 19.004-80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к использованию по своему назначению.

При отсутствии технического задания (ТЗ) на разработку программного средства (ПС) или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной.

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

Итоги третьей главы

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

Так же были проанализированы главные подходы к проведению отладки программных средств.

ЗАКЛЮЧЕНИЕ

Тестирование и отладка программного обеспечения – крайне важный и ответственный процесс разработки программного обеспечения. Именно от качества проведения тестирования напрямую зависит качество программного продукта и наличие в нём ошибок.

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

Важно понимать, что тестирование 6= отладка. Тестирование – поиск и обнаружение местонахождения ошибок, в то время как отладка занимается устранением этих найденных ошибок. Что бы корректно и эффективно провести поиск и устранение недоработок в коде программного средства, необходимо знать самые базовые вещи, поэтому мы подробно рассмотрели главные понятия и особенности тестирования и отладки программных средств, а так же их сходства и различия и их главное назначение при разработке программного обеспечения в главе 1. на странице 4.

Что бы провести тестирование наиболее эффективно и экономно, нужно знать как правильно спроектировать тест, так же необходимо умения применять главные методологии проведения тестирования, и так же знать их преимущества и недостатки. Именно эти аспекты разобраны в главе 2. на странице 12.

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

7. Соловьев С. В., Цой Р. И., Гринкруг Л. С. Технология разработки прикладного программного обеспечения. — Академия Естествознания, 2011. — Гл. Тестирование и отладка. — ISBN 978-5-91327-158-7.

Boehm B. W. Software Engineering Economics. — 1-е изд. — Prentice Hall, 1981.
Copi I. M., Cohen C., Rodych V. Introduction to Logic. — 15-е изд. — Routledge, 2019.
Myers G. J. Composite/Structured Design. — Van Nostrand Reinhold, 1978. — ISBN 978-0442805845.
Myers G. J. Software Reliability: Principles and Practices. — Wiley, 1976. — ISBN 978-5-91327-158-7.
Software Engineering – Guide to the software engineering body of knowledge (SWEBOK). ISO/IEC TR 19759:2015 / под ред. Т. комитет: ISO/IEC JTC 1/SC 7 Software, systems engineering. — 2-е изд. — 2015. — 336 с.
Гленфорд М., Кори С., Том Б. Искусство тестирования программ. — 3-е изд. — Вильямс, 2012.

ПРИЛОЖЕНИЕ

А.1. Отношения между типами тестов и процессами проектирования

Требования

ели

Внешние с

пецификации

Архитектура программы

а программы

Структур

Внешние спецификации

а модуля

Логик

мный тест

Автоно

пряжения

Тест со

Тест

функций

ксный тест

Компле

емлемости

Тест при

Тест настройки