Как называется процесс выполнения программы с намерением найти ошибки - ErrorsMaster.ru

2.2.1 Выбор метода и этапы тестирования

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

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

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

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

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

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

Тестирование ПС
– это процесс выполнения программы на
некотором наборе данных, для которого
заранее известен результат применения
или известно поведение программы.
Указанный набор данных называется
тестом. Таким образом, отладку можно
представить в виде многократного
повторения трёх процессов:

Тестирование в
результате, которого обнаруживаются
ошибки;
Поиск места ошибки
в программе и документации;
Редактирование
программы и документации с целью
устранения ошибок.

Тестирование
программы методом «черного ящика».

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

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

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

Тестирование
программы методом «белого ящика»

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

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

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

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

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

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

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

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

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

подключены,
тесты можно готовить в удобном виде.
Нисходящий подход выгоден также в том
случае, когда есть сомнения относительно
осуществимости программы в целом или
когда в проекте программы могут оказаться
серьезные дефекты. Преимуществом
нисходящего подхода очень часто считают
отсутствие необходимости в драйверах;
вместо драйверов вам просто следует
написать «заглушки». Нисходящий метод
тестирования имеет, к сожалению, некоторые
недостатки. Основным из них является
то, что модуль редко тестируется
досконально сразу после его подключения.
Дело в том, что основательное тестирование
некоторых модулей может потребовать
крайне изощренных заглушек. Программист
часто решает не тратить массу времени
на их программирование, а вместо этого
пишет простые заглушки и проверяет лишь
часть условий в модуле. Второй тонкий
недостаток нисходящего подхода состоит
в том, что он может породить веру в
возможность начать программирование
и тестирование верхнего уровня программы
до того, как вся программа будет полностью
спроектирована. Эта идея на первый
взгляд кажется экономичной, но обычно
дело обстоит совсем наоборот. Большинство
опытных проектировщиков признаёт, что
проектирование программы — процесс
итеративный. Редко первый проект
оказывается совершенным. Нормальный
стиль проектирования структуры программы
предполагает по окончании проектирования
нижних уровней вернуться назад и
подправить верхний уровень, внеся в
него некоторые усовершенствования или
исправляя ошибки, либо иногда даже
выбросить проект и начать все сначала,
потому что разработчик внезапно увидел
лучший подход. Если же головная часть
программы уже запрограммирована и
оттестирована, то возникает серьезное
сопротивление любым улучшениям ее
структуры.

Соседние файлы в предмете Базы данных

#
#
02.05.2014181.76 Кб83База данных — База отдыха.xls
#
#
#
02.05.2014864.26 Кб107База данных — ЖД вокзал.mdb
#
02.05.20141.34 Mб63База данных — Издательство «Научная книга».mdb
#
02.05.2014544.77 Кб55База данных — ИС кафедры.mdb
#

Источник

Заказать ✍️ написание работы

.1 Общие понятия

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

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

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

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

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

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

Сформулируем основополагающий вывод:

· Если ваша цель — показать отсутствие ошибок, то вы их найдете не слишком много.

· Если же ваша цель — показать наличие ошибок, вы найдете значительную их часть.

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

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

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

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

удовлетворен.

Еще одна причина, по которой трудно говорить о тестировании — это тот факт, что о нем известно очень немногое. Если сегодня мы располагаем 5% тех знании о проектировании и собственно программировании (кодировании), которые будут у нас к 2000 г., то о тестировании нам известно менее 1%.

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

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

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

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

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

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

Аттестация (certification) — авторитетное подтверждение правильности программы, аналогичное аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.

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

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

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

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

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

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

2.
Тестирование ПО

.1 Классификация видов тестирования

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

Состав и содержание документации, сопутствующей процессу тестирования, определяется зарубежным стандартом IEEE 829-2008 Standard for Software Test Documentation.

Существует несколько оснований, по которым принято производить классификацию видов тестирования.

. По объекту тестирования

· Функциональное тестирование (functional testing)

· Нагрузочное тестирование (performance/load/stress testing)

· Тестирование удобства использования (usability testing)

· Тестирование интерфейса пользователя (UI testing)

· Тестирование безопасности (security testing)

· Тестирование локализации (localization testing)

· Тестирование совместимости (compatibility testing)

. По знаниям о тестируемой системе

· Тестирование методом «черного ящика» (black box)

· Тестирование методом «белого ящика» (white box)

· Тестирование методом «серого ящика» (grey box)

. По уровню автоматизации

· Ручное тестирование (manual testing)

· Автоматизированное тестирование (automated testing)

. По степени изолированности

· Модульное тестирование (unit testing)

· Интеграционное тестирование (integration testing)

· Системное тестирование (system testing)

. По уровню готовности

· Альфа-тестирование (alpha testing)

· Бета-тестирование (beta testing)

· Приемосдаточные испытания (acceptance testing)

.2 Функциональное тестирование и тестирование качества

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

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

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

· Время отклика (время выполнения операции)

· Число операций, выполняемых в единицу времени (например, transactions per second, TPS).

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

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

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

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

Тестирование интерфейса пользователя (UI testing) предполагает проверку соответствия ПО требованиям к графическому интерфейсу пользователя. Различают следующие виды тестирования графического интерфейса пользователя:

· Тестирование на соответствие стандартам графических интерфейсов;

· Тестирование с различными разрешениями экрана;

· Тестирование локализованных версий: проверка длины названий элементов интерфейса и т.п.;

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

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

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

· Тестирование авторизации пользователей — выявляет дефекты, связанные с авторизацией отдельных пользователей и г8рупп пользователей и с проверкой их подлинности;

· Тестирование процедур проверки корректности ввода — имеет целью выявление ошибок в процедурах проверки данных, поступающих в систему извне;

· Тестирование криптографических механизмов защиты — используется для выявления дефектов, связанных с шифрованием и расшифрованием данных, использованием цифровых подписей и проверкой целостности данных;

· Тестирование правильности обработки ошибок — включает в себя проверку таких аспектов, как вывод на экран фрагментов кода при ощибке, влияние ошибок на работу всего приложения, анализ ошибок в коде их обработки;

· Тестирование на переполнение буфера — выявляет выход за границы буферов при обработке данных;

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

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

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

Тестирование совместимости (compatibility testing) — проверка совместимости системы с различными вариантами программно-аппаратного окружения (операционными системами, различными браузерами, сетевым ПО, СУБД, сторонним ПО, аппаратной платформой).

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

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

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

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

Модульные тесты проверяют, что определенные воздействия на модуль приводят к желаемому результату. Как правило. Модульные тесты создаются с использованием метода «белого ящика». При наличии зависимостей тестируемого модуля от других модулей вместо них используются так называемые mock-объекты, предоставляющие фиктивную реализацию их интерфейсов. С использованием mock-объектов могут быть протестированы такие аспекты функционирования, которые невозможно проверить с использованием реальных зависимых модулей. Существуют специальные библиотеки (например, Moq), упрощающие задачу создания mock-объектов. В работе (Месарош Дж. «Шаблоны тестирования xUnit. Рефакторинг кода тестов») описываются наиболее удачные подходы к организации модульного тестирования.

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

Для большинства популярных языков программирования высокого уровня существуют инструменты и библиотеки модульного тестирования (например, инструменты семейства xUnit: NUnit, JUnit, CppUnit).

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

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

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

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

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

3.2 Уровни тестирования

· Приемочное тестирование (Acceptance/ qualification testing).

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

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

· Установочное тестирование (Installation testing).

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

· Альфа- и бета-тестирование (Alpha and Beta testing).

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

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

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

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

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

· Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing)

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

Достижение и оценка надежности (Reability achievement and evaluation)

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

· Регрессионное тестирование (Regression testing)

Определение успешности регрессионных тестов (IEEE 610-90 “Standart Glossary of Software Engineering Terminology”) гласит: « повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам». На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии «масштабов» изменений, с достижением которых необходимо проводить регрессионные тесты.

· Тестирование производительности (Perfomance testing)

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

· Нагрузочное тестирование (Stress testing)

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

· Сравнительное тестирование (Back-to-back testing)

Единичный набор тестов, позволяющих сравнить две версии системы.

· Восстановительные тесты (Recovery testing)

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

· Конфигурационное тестирование (Configuration testing)

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

· Тестирование удобства и простоты использования (Usability testing)

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

· Разработка, управляемая тестированием (Test-driven development)

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

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

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

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

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

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

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

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

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

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

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

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

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

Трудно организовать исправление ошибок. Если программу пишут несколько программистов (а именно так и бывает в больших системах), и при этом неизвестно, в каком модуле ошибка, кто же будет ее искать и исправлять? Один программист будет указывать на другого, тот, выяснив, что его код ни при чем, снова обратится к первому, а в результате будет сильно страдать скорость разработки.

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

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

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

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

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

Воспользуйтесь поиском по сайту:

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 22 декабря 2020 года; проверки требуют 9 правок.

Источник

1

Тестирование программных средств Тема 11

2

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

3

Основные определения Тестирование (testing) процесс выполнения программы (или части программы) с целью найти ошибки. Доказательство (proof) попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Контроль (verification) попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

4

Испытание (validation) попытка найти ошибки, выполняя программу в заданной реальной среде. Аттестация (certification) авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом. Отладка (debugging) — не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем на исправление этой ошибки. Эти два вида деятельности связаны результаты тестирования являются исходными данными для отладки.

5

Тестирование модуля, или автономное тестирование (module testing, unit testing) контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает так же математическое доказательство. Тестирование сопряжений (integration testing) контроль сопряжений между частями системы (модулями, компонентами, подсистемами). Тестирование внешних функций (external function testing) контроль внешнего поведения системы, определенного внешними спецификациями. Основные определения

6

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

7

Экономика тестирования Тестирование программы как «черного ящика» ВХОД ВЫХОД Сложности создания исчерпывающего теста: 1) нельзя создать тест, гарантирующий отсутствие ошибок; 2) разработка таких тестов противоречит экономическим требованиям. Тестируется входная информация Тестируется выходная информация

8

Тестирование программы как «белого ящика» Сложности проведения исчерпывающего тестирования маршрутов: 1) Число не повторяющих друг друга маршрутов в программе — астрономическое. 2) Хотя исчерпывающее тестирование маршрутов является полным тестом, и хотя каждый маршрут программы может быть проверен, сама программа будет содержать ошибки. ВХОД ВЫХОД Тестируется внутреннее содержание программы

9

Тестирование программы как «белого ящика» П ричины ошибок: 1) Исчерпывающее тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. 2) Программа может быть неверной в силу того, что пропущены некоторые маршруты. 3) Исчерпывающее тестирование маршрутов не может обнаружить ошибок, появление которых зависит от обрабатываемых данных.

10

Аксиомы (принципы) тестирования 1) Хорош тот тест, для которого высока вероятность обнаружить ошибку. 2) Одна из самых сложных проблем при тестировании — решить, когда нужно его закончить. 3) Не нужно тестировать свою собственную программу. 4) Необходимая часть всякого теста — описание ожидаемых выходных данных (результатов). 5) Избегайте невоспроизводимых тестов, не тестируйте «с лету».

11

6) Готовьте тесты как для правильных, так и для неправильных входных данных. 7) Детально изучите результаты каждого теста. Если число ошибок растет, то растет вероятность обнаружения ошибок. Аксиомы тестирования

12

9) Поручайте тестирование самым способным программистам. 10) Проект системы должен быть таким, чтобы каждый модуль подключался к системе только один раз. 11) Никогда не изменяйте программу, чтобы облегчить ее тестирование. 12) Тестирование, как и всякая другая деятельность, должна начинаться с постановки целей. Аксиомы тестирования

13

Философия тестирования Чтобы ориентироваться в стратегиях проектирования тестов, рассматривают два крайних подхода, находящихся на границах спектра.

14

Тестирование модулей Причины тестирования модулей: 1) Появляется возможность управлять комбинаторикой тестирования, поскольку первоначально внимание концентрируется на небольших модулях программы. 2) Облегчается задача отладки программы, т.е. обнаружение места ошибки и исправление текста программы. 3) Допускается параллелизм, что позволяет одновременно тестировать несколько модулей. Цель тестирования модулей сравнение функций, реализуемых модулем, со спецификациями его функций или интерфейса.

15

Пошаговое тестирование Подходы к комбинированию модулей 1) Пошаговый метод тестирования или сборки. 2) Монолитный метод («большого удара») при тестировании и сборке программы. 12 3

16

Восходящее тестирование Процесс повторяется до тех пор, пока не будет достигнута вершина.

17

Нисходящее тестирование Процесс повторяется до тех пор, пока не будут собраны и проверены все модули.

18

Нисходящее тестирование Достоинства: 1) метод совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций. 2) когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде 3) выгоден, когда есть сомнения относительно осуществимости программы в целом или когда в проекте программы могут оказаться серьезные дефекты. 4) отсутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки».

19

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

20

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

21

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

22

Метод сандвича Метод сандвича сохраняет такое достоинство нисходящего и восходящего подходов, как начало интеграции системы на самом раннем этапе.

23

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

Источник

Содержание:

ВВЕДЕНИЕ

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

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

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

Цель исследования: охарактеризовать процессы тестирования и отладки.

Исходя из цели работы были сформулированы следующие задачи:

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

Данная курсовая работа состоит из двух глав. В первой главе мы определим значение терминов «тестирование», «отладка программ», назовем методы тестирования и опишем процесс тестирования. Будут рассмотрены методы тестирования, даны общие рекомендации по отладке приложений. Помимо этого, мы охарактеризуем различные виды ошибок и способы их выявления. Во второй главе мы коснемся практических моментов на этапах отладки приложения на примере среды разработки приложений JetBrains WebStorm, на языке программирования JavaScript.

Глава 1. СУЩНОСТЬ ТЕСТИРОВАНИЯ И ОТЛАДКИ

Под тестированием понимается процесс выполнения программы с намерением найти ошибки [21; 27]. Но стоит отметить, что тестирование не гарантирует нахождения 100% ошибок и, как следствие, полного отсутствия неисправностей в программе. Иными словами, тестирование показывает, что нам пока неизвестно, в каких случаях программа может дать сбой.

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

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

1.1 История развития тестирования

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

В 50–60-х годах прошлого века процесс тестирования был чрезвычайно формализован, отделен от процесса непосредственной разработки ПО и «математизирован». Фактически тестирование представляло собой скорее отладку программ. Однако существовала концепция «исчерпывающего тестирования (exhaustive testing)». Она состояла в проверке всех возможных путей выполнения кода со всеми возможными входными данными. Но очень скоро разработчики пришли к выводу, что исчерпывающее тестирование невозможно, потому что количество возможных путей и входных данных очень велико, а также при таком подходе сложно найти проблемы в документации [15].

В 70-х годах фактически родились две фундаментальные идеи тестирования: тестирование сначала рассматривалось как процесс доказательства работоспособности программы в некоторых заданных условиях (positive testing), а затем — строго наоборот: как процесс доказательства неработоспособности программы в некоторых заданных условиях (negative testing). Это внутреннее противоречие не только не исчезло со временем, но и в наши дни многими авторами совершенно справедливо отмечается как две взаимодополняющие цели тестирования [17].

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

Итак, ещё раз самое важное, что тестирование «приобрело» в 70-е годы:

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

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

В 90-х годах произошёл переход от тестирования как такового к более всеобъемлющему процессу, который называется «обеспечение качества» (quality assurance), охватывает весь цикл разработки ПО и затрагивает процессы планирования, проектирования, создания и выполнения тест-кейсов, поддержку имеющихся тест-кейсов и тестовых окружений. Тестирование вышло на качественно новый уровень, который естественным образом привёл к дальнейшему развитию методологий, появлению достаточно мощных инструментов управления процессом тестирования и инструментальных средств автоматизации тестирования, уже вполне похожих на своих нынешних потомков [15].

С переходом в новый век развитие тестирования продолжалось в контексте поиска всё новых и новых путей, методологий, техник и подходов к обеспечению качества. Серьёзное влияние на понимание тестирования оказало появление гибких методологий разработки и таких подходов, как «разработка под управлением тестированием (test-driven development, TDD)» [33]. Автоматизация тестирования уже воспринималась как обычная неотъемлемая часть большинства проектов, а также стали популярны идеи о том, в тестировании наиболее важно не соответствие программы требованиям, а её способность предоставить конечному пользователю возможность эффективно решать свои задачи.

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

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

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

функциональное,
нефункциональное,
связанное с изменениями [20].

Рассмотрим первую группу. Под функциональным тестированием понимается тестирование непосредственно функций и задач продукта. Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом. Эти тесты описываются в спецификациях и основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования: модульном, интеграционном, системном и приемочном [14].

На модульном уровне тестирования проверяется корректная работа одного отдельного модуля внутри себя [15]. Тесты для такого тестирования обычно пишутся самим разработчиком еще до написания основного кода программы. Если код модуля успешно проходит на соответствие всем проверкам, которые были описаны до его написания, он считается завершенным.

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

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

На приемочном уровне тестирования выполняется проверка соответствия разрабатываемой системы требованиям клиента. Таким образом, основная функция приемочного тестирования заключается не в тестировании кода, а в создании именно такой системы, которая требуется клиенту или предприятию [31].

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

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

1. Функциональное тестирование. В рамках этого вида тестирования проверяется соответствие реализованных функций требованиям, техническому заданию, спецификациям, различным другим проектным документам и просто ожиданиям пользователя. Разработчики проверяют каждую из функций приложения и всех их в комплексе, исследуя все сценарии использования [20].

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

3. Тестирование взаимодействия. Функция названного вида тестирования – проверить способность приложения взаимодействовать с одним и более компонентами или системами [18; 20]. Важность применения данного вида тестирования обусловлена развитием сетевых технологий и Интернета. В случае успешного прохождения теста взаимодействия программное обеспечение может быть легко интегрировано с другими системами без каких-либо серьезных модификаций.

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

1. Главная функция тестирования производительности — выявить, насколько система корректна работает при одновременном использовании данного продукта многими пользователями. В ходе тестирования выявляются потери данных пользователей, максимальное количество одновременный пользователей [11].

2. Тестирование установки призвано выполнить проверку, насколько корректно программа устанавливается на рабочую машину пользователя и удаляется с нее [11]. В настоящее время получила установка программ с помощью специальных программных модулей – инсталляторов. Если инсталлятор не предусмотрен, установка производится самостоятельно согласно инструкциям и спецификациям, либо специальному плану установки [18].

3. Тестирование удобства пользования характеризует усилия, необходимые для использования программного продукта, и индивидуальную оценку результатов его использования. Программа признается удобной в использовании тогда, когда обладает следующими свойствами: полезность, эффективность, производительность, осваиваемость, удовлетворенность, доступность [1]. Тестирование удобства может проводить не только тестировщик, но и группа конечных пользователей в тестовых режимах продукта. Это помогает собрать нужную и общую информацию о том, насколько конечным клиентам будет удобно пользоваться продуктом [19].

4. Тестирование на отказ и восстановление выполняет проверку программного продукта на возможность восстановиться после сбоя. В рамках тестирования специалисты занимаются рассмотрением всех возможных вариантов отказа системы и проверяют программу на адекватную реакцию на эти отказы [10]. Тестировщиками проверяются системы отката и восстановления, обеспечивающие целостность и сохранность данных ПО в случае сбоя в нормальной работе программы или окружения. Данное тестирование необходимо при проектировании продуктов, так как следствием потери данных является уход клиентов и снижение репутации компании [18].

5. Конфигурационное тестирование производит проверку работоспособности программы в разных конфигурациях системы, платформах, средах, устройствах и т.д. Цель тестирования — определить набор конфигураций, которые будут достаточны для работы системы на конкретном устройстве [10]. В качестве самого популярного примера такого тестирования можно назвать минимальные и подходящие системные требования для игр [19].

Последняя группа – тестирование, связанное с изменениями. Его функция – проверить систему после каких-либо внесенных изменений в ней. Это наиболее распространенное на практике тестирование, так как любое внесение изменений в программу может привести к ошибкам, которых не было до изменений [19]. Ф. Брукс в своей книге «Мифический человеко-месяц» писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50 %) влечёт появление новой» [4, с. 70]. Связанные с изменениями виды тестирования применяются внесения необходимых изменений и корректировки в продукт. Программа должна быть заново протестирована, чтобы подтвердить, что ошибка была устранена [8].

Основными видами этого тестирования являются дымовое тестирование, регрессионное тестирование, тестирование сборки, санитарное тестирование.

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

2. Регрессионное тестирование представляет собой полное тестирование продукта [11]. Это тестирование считается самым длительным и трудозатратным. На его этапе обнаруживается большинство багов и несоответствий системы и технического задания. Трудность заключается в том, что при обнаружении бага на финальном этапе тестирования и его устранения необходим повторный цикл тестирования [19].

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

4. Санитарное тестирование применяется при проверке работы конкретной функции или блока. Относится к подмножествам регрессионного тестирования и определяет работоспособность части продукта после изменения. Следует различать дымовое и санитарное тестирование: дымовое тестирование – это больше тестирование основного функционала «вширь», для проверок «вширь», при санитарном же тестировании происходить проверка одной конкретной функции или модуля «вглубь» [19].

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

1.3 Парадигмы тестирования

На современном этапе развития тестирования сформировались две противоположные парадигмы – поведенческое и структурное тестирование [3].

Рассмотрим стратегию поведенческого тестирования. Она основана на технических требованиях к программному обеспечению. Другое название парадигмы — тестирование «черного ящика» (black-box testing). Подход заключается в том, что проведении процедуры тестирования не обязательно знать, как программа сконструирована внутри, известна только информация о его входах и выходах. При этом нет никаких данных о том, как именно программа преобразует входные данные в выходные. В связи с этим парадигма и получила свое название.

В рамках проведения тестирования «черного ящика» в соответствии с требованиями к программному продукту определяется набор тестовых входных данных и предсказывается корректное поведение программы. После этого программа выполняется на подготовленном наборе и результат сравнивается с предсказанным [2].

Критерием исчерпывающего входного тестирования является обнаружение всех ошибок в программе. Критерий может быть достигнут, если в качестве тестовых наборов использовать все возможные наборы входных данных. Однако построение исчерпывающего входного теста невозможно. Это объясняется двумя причинами: отсутствует возможность создания теста, гарантирующего отсутствие ошибок; разработка таких тестов противоречит экономическим требованиям [20].

С. В. Бирюков выделяет такие методы поведенческого тестирования, как тестирование потока управления, тестирование потоков данных, тестирование доменов, синтаксическое тестирование, тестирование систем с конечным числом состояний, тестирование циклов [3].

Перейдем к рассмотрению стратегии структурного тестирования. Она определяется структурой исследуемого программного обеспечения. Второе название парадигмы — тестирование «белого ящика» (white-box testing) или тестирование «прозрачного ящика». Как и в предыдущем случае, название происходит из структуры тестирования. В данном случае тестировщик исходит из знания того, как программный продукт сконструирован внутри. Нам известна не только информация о его входах и выходах, но, прежде всего, известен механизм преобразования входных данных в выходные [18].

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

Основные методы структурного тестирования — покрытие операторов программы, покрытие ветвей программы, покрытие условий [3].

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

У данного подхода есть достоинства и недостатки. Одним из главных достоинств данного метода является то, что он включает в себя положительные черты тестирования «белого ящика» и тестирования «черного ящика». К достоинствам подхода можно отнести то, что человек, тестирующий программу, видит программу со стороны «черного ящика», а анализирует данные с позиции тестирования «белого ящика». Изначально при данном методе тестировщик и разработчик работают вместе, что позволяет избежать избыточные наборы тестовых данных, но и увеличивает время для исправления выявленных ошибок. Выделяются и недостатки, такие как отсутствие возможности протестировать все возможные тестовые наборы данных и ограниченность в анализе тестового покрытия, так как доступ к программному коду закрыт [23].

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

1.4 Отладка ошибок. Их виды

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

Отладка не является разновидностью тестирования. Тестирование ставит задачу определения наличия ошибок [21; 27], в то время как отладка служит для определения местоположения выявленных тестированием ошибок в исходном коде и их устранения [20]. Если цели этих двух этапов разработки программ различны, то, соответственно, используются различные методика и инструментарий. Важно разделять процесс тестирования и процесс отладки на два различных этапа работы над программой. Важно отметить, что эти два вида деятельности связаны: результаты тестирования являются исходными данными для отладки.

В настоящее время выделяется несколько способов отладки [6]. Перечислим их:

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

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

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

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

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

нелогичный пользовательский интерфейс;
неудовлетворенные ожидания;
низкая производительность;
аварийные завершения или разрушение данных [24].

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

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

В случае проектирования интерфейса Web-приложения, эта задача существенно усложняется. Здесь уже нет конкретных стандартов на пользовательский интерфейс. Самое главное, что надо учитывать при разработке интерфейса для Web-клиента, — это возможную низкую скорость трафика, поэтому следует создавать пользовательский интерфейс максимально простым и загружать с сервера только необходимые ресурсы чтобы максимально снизить время загрузки и ожидания пользователя. К примеру, простые решения, подобные CNN.com, нравятся практически всем пользователям. Использование простого набора ссылок выглядит куда лучше и работает быстрее, чем перегруженный различными функциями и графическими материалами интерфейс. Подобный перегруженный интерфейс легко может вызывать неудобство или даже отпугивать пользователя [8].

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

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

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

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

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

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

«ошибки, приводящие к порче пользовательских данных в процессе обработки: целочисленное переполнение, порча данных в оперативной памяти, обращение к неинициализированному блоку памяти, обращение к памяти по неинициализированному или висящему указателю (англ. – dangling pointer), фальсификация данных (англ. — request forgery) и др.;
ошибки, приводящие к неавторизованному доступу к пользовательским данным: получение неавторизованного доступа к базе данных, получение неавторизованного доступа к информации в оперативной или постоянной памяти вычислительного устройства, получение повышенного уровня привилегий доступа к данным и др.; • ошибки, приводящие к исчерпанию системных ресурсов, таких как память на куче, файлы, сокеты и др.;
ошибки, приводящие к аварийному завершению исполнения программы: доступ к области памяти, не принадлежащей программе, деление на ноль и др.;
ошибки, приводящие к исполнению злонамеренного кода: перехват потока управления злонамеренным кодом, исполнение злонамеренного кода на стороне клиента, внедрение в исполнение команды в командной строке и др.» [7, с. 15].

Каковы причины появления ошибок? Рассмотрим несколько возможных путей их возникновения.

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

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

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

Т. Н. Лебедева и Л. С. Носова выделили несколько направлений по предотвращению ошибок:

1. «Использование встроенных возможностей системы программирования на этапе разработки программы (дозапись кода, работа с шаблонами, отладка программы и др.).

2. Разработка кода по отраслевым и специальным стандартам программирования.

3. Использование программ для автоматического и автоматизированного тестирования разработанного приложения» [16, с.55].

Принципы тестирования основываются на вопросах психологии. Принципы в основном интуитивно понятны, однако иногда они остаются без должного внимания. Данные позиции перечислены И.В. Степанченко [28].

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

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

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

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

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

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

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

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

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

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

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

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

Глава 2. ПРАКТИКА ОТЛАДКИ ПРИЛОЖЕНИЙ В СРЕДЕ JAVASCRIPT

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

2.1 Инструментарий поиска и отслеживания ошибок

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

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

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

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

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

Многих проблем при разработке программных продуктов можно избежать, используя в системе управления версиями, так называемые Модульные тесты (unit tests).

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

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

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

Система управления версиями должна соответствовать потребностям разработчика. По данным сервиса GitHub, в 2019 году аудитория сервиса достигла 41 млн. уникальных пользователей, а число компаний официально представленных на сервисе достигло 2.9 млн [34]. GitHub — крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Веб-сервис основан на системе контроля версий Git. Данная статистика позволяет утверждать, что на сегодняшний день система контроля версий Git является наиболее распространенным решением для обеспечения контроля версий приложений среди разработчиков и компаний.

2.2 Применение точек остановки и модификация локальных переменных

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

К синтаксическим ошибкам относятся ошибки в написании конструкций языка программирования, неверной записью идентификаторов и иными неверными действиями программиста, которые нарушают строгие правила написания исходного кода на выбранном языке программирования. Такие ошибки препятствуют исполнению программы или делают его невозможным к запуску. Следует постоянно обращать внимание на различные сообщения и предупреждения, выдаваемые интерпретатором при попытке запуске программы. Это может помочь обнаружить найти ошибку в тексте кода. Также существуют среды разработки приложений на языке JavaScript. Например, Microsoft Visual Studio Code^[1] или JetBrains WebStorm^[2]. Данные программы являются комплексными решениями, помогающими разработчику в написании программ. Они включают в себя редактор исходного кода, обеспечивают статический анализ исходного кода создаваемого приложения, предоставляют систему отладки, подсветку и выделение цветом конструкций языка в исходном коде программы и многие другие полезные для разработчиков функции. Для облегчения процесса написания кода Visual Studio Code и WebStorm имеют встроенный упрощенный компилятор языка JavaScript, который используется для статического анализа написанного кода и предупреждения синтаксических ошибок на этапе написания программы. Таким образом, разработчику значительно проще найти синтаксические ошибки еще на этапе написания программы.

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

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

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

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

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

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

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

let a = 1;

let b = 123;

a += 1;

a += b;

a = 1;

a += 1;

console.log(a);

console.log(a.toString(16));

После запуска данной программы, в журнале исполнения мы увидим значения 2, и 2. Это совсем иные результаты. Поскольку была допущена ошибка в операторе во время выполнения процедуры увеличения переменной “a” на единицу. Для того чтобы быстро выяснить, где же допущена ошибка установим точку остановки на третьей строке и запустим программу:

Рисунок 1

На рисунке 1 видно, что исполнение программы приостановилось на строке 3. Остановка происходит до исполнения инструкций на строке, поэтому в окне Variables видно текущее значение переменных. На данном этапе все работает как задумано, поэтому используем кнопку Step over F8 и продолжаем выполнение программы. Нажатие данной кнопки исполнит программу ровно на одну строку и снова приостановит выполнение программы. После того как программа достигнет строки 7, можно увидеть, что значение переменной “а” равно 1, хотя ожидается что значение будет равно 127.

Уже сейчас можно понять, что допущена ошибка в операторе присваивания значений переменной на строке 6. Но мы пока не будем изменять исходный код и попробуем воспользоваться инструментом Evaluate expression Alt + F8. Данный инструмент позволяет выполнить любое выражение и как бы встроить его в программу на ту точку, где сейчас остановлено выполнение программы. Важно понимать, что данное действие несет временный характер и не сохраняется после завершения процесса отладки. Мы попробуем остановить исполнение программы на строке 8, вручную установить значение переменной на ожидаемое значение и посмотрим каким будет результат исполнения программы. Интерфейс Evaluate expression представлен на рисунке 2.

Рисунок 2

Теперь выполним программу до конца и посмотрим на результат исполнения. В результате исполнения в журнал были выведены ожидаемые значения 128 и 80. Это позволяет нам убедиться, что мы успешно изменили значение переменной “а” с использованием инструмента Evaluate expression.

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

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

2.3 Пошаговая трассировка приложения

В первой главе исследования мы выявили, что трассировка является одним из способов отладки. Рассмотрим этот способ на практике.

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

Наименование команды	Горячая клавиша	Действие отладчика
«Step Into»	«F7»	отладчик выполнит код текущей строчки кода и остановится на следующей. Если в данной строке происходит вызов функции, то следующей строкой будет первая строка вызываемой процедуры.
«Step Over»	«F8»	аналогично «Step Into», но вход в тело вызываемой функции не происходит.
«Smart step into»	«Shift+F7»	Используется, когда на строке присутствует несколько вызовов функций. Он позволяет выбирать в какую именно функцию мы хотим зайти отладчиком.
“Force step into”	“Shift+Alt+F7”	используется чтобы зайти в код функции, даже если обычный вызов Step into в нее не зашел.
“Step out”	“Shift+F8”	выходит из кода вызванной функции, возвращает инспектор в метод, вызвавший данную функцию.
«Run to Cursor»	«Alt+F9»	отладчик будет выполнять код программы до той строки, на которой сейчас находится курсор
“Force run to cursor”	“Ctrl+Alt+F9”	аналогично команде Force step into, принудительно выполняет команду Run to Cursor.
«Force step over»	«Shift+Alt+F8»	принудительно выполняет команду Step over даже если следующая строка — это вызов метода.
«Drop frame»	по умолчанию нет горячей клавиши	позволяет вернуть исполнение программы на предыдущую инструкцию. Полезно если случайно прошли слишком далеко в исполнении программы. Стоит обратить внимание что эта функция только выводит предыдущее состояние, фактическое состояние программы не меняется.

Таблица 1. Команда трассировки

Вторым по важности инструментом при отладке приложений является окно «Call Stack». Оно содержит описание всех вызовов до возникновения исключения, ошибки или прерывания в точке остановки.

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

1. Необходимо считать тестирование и отладку важным этапом разработки программ.

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

3. Тестирование следует проводить как с верными, так и с заведомо неверными данными.

4. Полезно вести протоколы исполнения тестов. Это позволит подробно изучать результаты тестирования в случае необходимости.

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

Атисков А. Ю., Давидович И. И. Тестирование эргономики пользовательского интерфейса мобильных приложений / А. Ю. Атисков, И. И. Давидович // Научный вестник НГТУ. — 2014. — Том 57, № 4. — С. 119-130.
Бейзер Б. Тестирование «черного ящика». Технология функционального тестирования / Б. Бейзер. — СПб: Питер, 2004. — 318 с.
Бирюков С. В. Анализ стратегий тестирования программного обеспечения [Электронный ресурс] / С. В. Бирюков // Cyberleninka. — URL: https://cyberleninka.ru/article/n/analiz-strategiy-testirovaniya-programmnogo-obespecheniya/viewer (дата обращения: 20.02.20).
Брукс Ф., Чапел Х. Мифический человеко-месяц, или Как создаются программные системы / Ф. Брукс, Х. Чапел. — М.: Символ-Плюс, 2010. — 304 с.
Вишневская Т. И. Тестирование программного обеспечения как учебная дисциплина / Т. И. Вишневская // Образовательные ресурсы и технологии. — 2014. — № 1 (4). — С. 83-88.
Галатенко В. А., Костюхин К. А. Проблемы отладки многопроцессных систем [Электронный ресурс] / В. А. Галатенко, К. А. Костюхин // Cyberleninka. — URL: https://cyberleninka.ru/article/n/problemy-otladki-mnogoprotsessnyh-sistem (дата обращения: 21.02.20).
Герасимов А. Ю. Классификация предупреждения о программных ошибках методом динамического символьного исполнения программ: диссерт. канд. физ.-матем. наук. Институт системного программирования им. В. П. Иванникова / А. Ю. Герасимов. — М., 2019.
Глас Р. Руководство по надежному программированию / Р. Глас. — М.: Финансы и статистика, 2010. — 256 с.
Инюшкина О.Г. Проектирование информационных систем (на примере методов структурного системного анализа): учебное пособие / О.Г. Инюшкина. — Екатеринбург: «Форт-Диалог Исеть», 2014. — 240 с.
Калбертсон Р. Быстрое тестирование / Р. Калбертсон, К. Браун, Г. Кобб. – М.: Вильямс, 2002. — 374 с.
Канер К. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / К. Канер, Д. Фолк, Е. К. Нгуен. – Киев: ДиаСофт, 2001. – 544 с.
Керман М. К. Программирование и отладка в Delphi. Пер. с англ. — М.: Вильямc, 2003. — 672 с.
Коликова Т. В., Котляров В. П. Основы тестирования программного обеспечения / Т. В. Коликова, В. П. Котляров. — М.: Бином, 2010. — 285 с.
Криспин Л, Грегори Д. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд / Л. Криспин, Д. Грегори. — М.: Вильямс, 2010. — 464 с.
Куликов С. С. Тестирование программного обеспечения. Базовый курс / С. С. Куликов. — Минск: Четыре четверти,

2017. — 312 с.

Лебедева Т. Н. Подводные камни при разработке программных решений / Т. Н. Лебедева // Управление в современных системах. — 2017. — № 3(14). — С. 49-56.
Липаев В. В. Программная инженерия: методологические основы : учебник / В. В. Липаев. — М.-Берлин: Директ-Медиа, 2015. — 608 с.
Майерс Г., Баджетт Т., Сандлер К. Искусство тестирования программ, 3-е изд.: Пер. с англ. / Г. Майерс, Т. Баджетт, К. Сандлер. — М.: Вильямс, 2012. — 272 с.
Моисеев Д. А. Методология и процесс ручного тестирования / Д. А. Моисеев // Надежность и качество сложных систем. — 2017. — № 3 (19). — С. 107-112.
Осипенко Н.Б. Основы стандартизации и сертификации программного обеспечения: тестирование программного обеспечения: практ. рук-во для студентов специальности 1–40 01 01 «Программное обеспечение информационных технологий» / Н. Б. Осипенко. — Гомель: ГГУ им. Ф. Скорины, 2014. — 36 с.
Прокин А. А. Современное состояние и основные проблемы интернетторговли в российской федерации / А. А. Прокин, В. А. Богатырская, Е. С. Сергушина, И. С. Листратов // E-Scio. — 2018. — № 3 (18). — С. 36-41.
Прокин А. А. Создание и актуальные проблемы продвижения «трансрегионавтоматика») [Электронный ресурс] / А. А. Прокин, В. А. Богатырская, Е. С. Сергушина, Е. В. Кренделев // Cyberleninka. — URL: https://cyberleninka.ru/article/n/sozdanie-i-aktualnye-problemy-prodvizheniya-sayta-na-primere-sayta-ooo-transregionavtomatika/viewer (дата обращения: 20.02.20).
Прокин А. А., Баландин И. А. Способы тестирования учебных программ [Электронный ресурс] / А. А. Прокин, И. А. Баландин // Cyberleninka. — URL: https://cyberleninka.ru/article/n/sposoby-testirovaniya-uchebnyh-programm/viewer (дата обращения: 20.02.20).
Роббинс Д. Отладка приложений для Microsoft .NET и Microsoft Windows / Д. Роббинс. — М.: «Русская Редакция», 2004. — 736 с.
Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения / С. В. Синицын, Н. Ю. Налютин. — М.: Бином, 2008. — 368 с.
Соловьев С. В., Цой Р. И., Гринкруг Л. С. Тестирование и отладка [Электронный ресурс] / С. В. Соловьев, Р. И. Цой, Л. С. Гринкруг // Научная электронная библиотека. — URL: https://www.monographies.ru/ru/book/section?id=4632 (дата обращения: 23.02.20).
Софронова Н. В. Теория и методика обучения информатике: уч. пособие / Н. В. Софронова. — М.: Высшая школа, 2003. — 186 с.
Степанченко И. В. Методы тестирования программного обеспечения: уч. пособие / И. В. Степанченко. — Волгоград: ВолгГТУ, 2006. — 76 с.
Тамре Л. Введение в тестирование программного обеспечения / Л. Тамре. — М.: Дрофа, 2009. — 368 с.
Ховард М., Лебланк Д. Защищенный код: Пер. с англ, — 2-е изд., испр. / М. Ховард, Д. Лебланк. — М.: Русская Редакция, 2004. — 704 с.
Холл Б. Автоматизация приемочного тестирования с помощью IronRuby [Электронный ресурс] / Б. Холл // Microsoft.docs. — URL: https://docs.microsoft.com/ru-ru/archive/msdn-magazine/2009/march/net-interop-automate-acceptance-testing-with-ironruby (дата обращения: 21.02.20).
Чушкин М. С., Шелехов В. И. Генерация и доказательство условий корректности предикатных программ [Электронный ресурс] / М. С. Чушкин, В. И. Шелехов // Институт систем информатики им. А. П. Ершова СО РАН. — URL: https://www.iis.nsk.su/files/preprints/166.pdf (дата обращения: 21.02.20).
Scott W. A. Introduction to Test Driven Development (TDD) [Электронный ресурс] / W. A. Scott // Agile Data. — URL: http://agiledata.org/essays/tdd.html (дата обращения: 22.02.20).
The State of the Octoverse [Электронный ресурс] // GitHub. — URL: https://octoverse.github.com/ (дата обращения: 19.02.20).

https://code.visualstudio.com/ ↑
https://www.jetbrains.com/webstorm/ ↑

ФИНАНСОВЫЕ РЕСУРСЫ ( Понятие, источники и рост финансовых ресурсов )
47. Понятие и виды источников права.
Теория менджмента. Анализ внешней и внутренней среды организации.
Создание видеоролика: Мир современных гаджетов»
Создание видеоролика: Мир современных гаджетов
Налоговая система РФ и проблемы её совершенствования ( Экономические основы и принципы построения налоговой системы )
Теории происхождения государства
Бухгалтерский баланс организации: порядок составления и аналитические возможности
Построение организационных структур(Теоретические основы организационной структуры)
Гендерные различия проявлений профессионального стресса (Понятие «стресс» и основные теоретические подходы к его изучению)
Разработка проекта информационной системы торговой интернет-фирмы ( ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ О СОЗДАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ )
рименение объектно-ориентированного подхода при проектировании информационной системы ( ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД )

Источник

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

I. ВСТУПЛЕНИЕ.

ОБЩИЕ ПОНЯТИЯ.

Многие организации, занимающиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовложения, знаний о сути тестирования явно не хватает и большинство программных продуктов неприемлемо ненадежно даже после “основательного тестирования”.

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

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

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

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

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

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

ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ.

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

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

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

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

Отладка (debugging) не является разновидностью тестирования. Хотя слова “отладка” и “тестирование” часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.

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

Отношения между этими типами тестов и проектной документацией, на которой основывается тест, показаны на рис.3,

Рис. 2. Спектр подходов к проектированию тестов,

Рис. 3. Процессы тестирования и их связь с процессами проектирования.

II. ОСНОВНАЯ ЧАСТЬ.

ФИЛОСОФИЯ ТЕСТИРОВАНИЯ

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

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

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

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

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

ИНТЕГРАЦИЯ МОДУЛЕЙ.

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

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

ВОСХОДЯЩЕЕ ТЕСТИРОВАНИЕ.

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

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

НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ.

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

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

Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они передаются программе? Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост:

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

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

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

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

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

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

МОДИФИЦИРОВАННЫЙ НИСХОДЯЩИЙ МЕТОД

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

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

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

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

МЕТОД БОЛЬШОГО СКАЧКА.

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

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

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

МЕТОД САНДВИЧА

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

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

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

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

МОДИФИЦИРОВАННЫЙ МЕТОД САНДВИЧА.

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

СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА МЕТОДОВ ТЕСТИРОВАНИЯ.

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

Восходящий

Нисходящий

Модифицированный нисходящий

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

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

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

Сборка

Рано

Поздно

Рано

Время до появления работающего варианта программы

Поздно

Рано

Поздно

Рано

Нужны ли драйверы (новые программы или готовые инструменты) ?

Да

Нет

Да

Частично

Да

Нужны ли заглушки

Нет

Да

Частично

Параллелизм в начале работы

Средний

Слабый

Средний

Высокий

Средний

Высокий

Возможность тестировать отдельные пути

Легко

Трудно

Легко

Трудно

Средне

Легко

Возможность планировать и контролировать последовательность

Легко

Трудно

Легко

Трудно

Рис. 10.7. Количественная оценка подход к сборке.

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

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

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

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

Вес

Восходящий

Нисходящий

Модифицированный нисходящий

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

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

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

Сборка

Рано +

Поздно —

Рано +

Время до появления работающего варианта программы

Поздно —

Рано +

Поздно —

Рано +

Нужны ли драйвера (новые программы u/uли готовые инструменты) ?

Да —

Нет +

Д а —

Да —

Частично

Да —

Нужны заглушки?

Нет +

Да —

Частично

Параллелизм в начале работы

Средний

Слабый-

Средний

Высокий+

Средний

Высокий +

Возможность тестировать отдельные пути

Легко +

Трудно —

Легло +

Легко +

Средне

Легко +

Возможность планировать и контролировать последовательность

Легко +

Трудно —

Легко +

Трудно —

Неэффективность

Всего

-1

-3

Рис. 10.8. Взвешенная оценка подходов к сборке.

III. ИСПЫТАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ (АНАЛИЗ).

ЦЕЛЬ И ОСОБЕННОСТИ ИСПЫТАНИИ.

Испытания являются важнейшим элементом управления качеством продукции. В соответствии с ГОСТ 16504—81 под испытанием промышленной продукции понимают экспериментальное определение количественных и/или качественных характеристик объекта испытания как результата воздействия на него; при его функционировании; при моделировании объекта и/или воздействия. Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.

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

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

В соответствии с ГОСТ 19,004—80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к использованию по своему назначению. Но такое требование редко соблюдается на практике. В некоторых случаях, особенно в автоматизированных системах, ТЗ на ПС либо вообще не пишут, либо в них перечисляют лишь функции, которые возлагаются на ПС, без указания требований к другим потребительским свойствам. При отсутствии ТЗ на разработку ПС или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной. Что значит установить соответствие программы заданным требованиям, если эти требования формально не заданы? Какая польза от установления такого соответствия, если эти требования заведомо “усечены” и не отражают основных потребительских свойств программы? Пользователю будет не легче, если программа функционирует плохо, но это в явном виде не противоречит требованиям ТЗ.

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

В зарубежной литературе, в том числе в стандартах на программное обеспечение, понятие “испытание” часто отождествляют с понятием “тестирование”. Например, в Std IEEE 829—1983 “Документация тестов программного обеспечения” (США) дано следующее определение тестирования: “… процесс активного анализа ПО на предмет обнаружения расхождения между реальными и требуемыми нормами ПО (т. е. наличия ошибок в программах) и с целью оценки характеристик элементов ПО”. Данное определение объединяет два приведенных определения термина “испытание” с той лишь разницей, что при принятой (см. определения) концепции поиск и локализация ошибок на являются явно выраженными целями испытания. С учетом высказанных соображений термин “тестирование”, используемый в зарубежной литературе, будем интерпретировать как испытание методом тестирования,

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

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

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

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

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

ТЕХНОЛОГИЧЕСКАЯ СХЕМА ИСПЫТАНИЯ.

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

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

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

ясное представление цели и последовательности испытания;

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

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

четкое, последовательное определение и исполнение плана испытания;

четкое сопоставление имеющихся ресурсов с предполагаемым объемом испытания;

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

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

составление и согласование плана-графика проведения испытания;

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

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

анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС;

проверка и согласование с представителем Заказчика конструкторской документации на ПС, предъявляемой при испытаниях;

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

аттестация специалистов на допуск к проведению испытаний;

приемка испытываемого опытного образца ПС на носителе данных и документации;

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

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

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

На основании изложенного можно определить следующие пять этапов испытания.

1. Обследование проектируемого ПС, анализ проектной документации.

2. Определение наиболее важных подсистем, функций и путей проектируемого ПС, подлежащих испытанию.

3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания.

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

5. Непосредственное проведение испытаний, анализ результатов, принятие решения.

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

/>Рис. 16. Технологическая схема испытания ПС.

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

ПЛАНИРОВАНИЕ И ОЦЕНКА ЗАВЕРШЕННОСТИ ИСПЫТАНИЙ.

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

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

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

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

4) ПС испытывают в реальной среде функционирования;

5) ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде.

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

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

Методика решения задачи планирования испытания включает в себя следующие этапы: нахождение всех путей реализации;

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

Для установления потребности в машинном времени на проведение испытаний необходимо знать среднее значение абсолютной реактивности ПС. Эта характеристика должна быть задана в ТЗ. Если же она не задана, то можно принять />где />— минимальное значение абсолютной реактивности; />— максимальное значение абсолютной реактивности.

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

Рассмотренный метод планирования на этапе автономных статистических испытаний модулей ПИ позволяет значительно уменьшить материальные и временные затраты на испытание программ. Ориентация на тот или иной подход к испытаниям зависит от типа испытываемого ПС.

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

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

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

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

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

Составлению плана проведения испытаний должен предшествовать анализ Т3 на разработку ПС, структурных и функциональных схем, режимов функционирования, зависимостей между модулями программы, планов-графиков разработки и отладки компонентов ПС, результатов контроля их качества на ранних стадиях разработки. В результате этого анализа необходимо разработать и обосновать общую стратегию испытания, а на ее основе—комплекс документов по организации испытаний, который должен содержать ответы на следующие вопросы: 1) задачи испытаний на каждой фазе, последовательность развития фаз; 2) используемые специальные испытательные средства; 3) количество необходимого машинного времени на каждой фазе испытаний; 4) конфигурация общего технического и программного обеспечения; 5) оцениваемые свойства, критерии оценки, способы их получения; 6) процедуры контроля хода испытания; 7) процедуры регистрации, сбора, обработки и обобщения результатов испытания; условия (критерии) начала и завершения каждой фазы испытаний. По каждому из этих вопросов необходимо определить ответственных исполнителей, сроки выполнения работ, вид конечного результата.

В стандарте IEEE 829—1983 (США) большое внимание уделено документированию процесса испытания ПП. Перечень документов, которые разрабатываются и ведутся в соответствии с планом испытания, приведен в разделе “Документирование”,

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

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

При оценке уровня завершенности испытаний ПС и достоверности полученных результатов часто возникают серьезные затруднения. Отметим следующие из них:

1) большинство ПС являются уникальными и либо не имеют аналогов для сравнения характеристик, либо имеют аналоги, характеристики которых неизвестны;

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

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

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

Не всякую ошибку можно быстро идентифицировать, поэтому в стандарте IEEE 829—1983 рекомендовано документировать в виде отчетов тест-инцидент все нестандартные события, происходящие во время испытания и требующие дополнительного анализа. Рекомендуется следующая структура этого отчета: идентификатор отчета тест-инцидент, аннотация, описание инцидента, влияние инцидента на последующий ход испытания. Последние два раздела являются основными. Описание инцидента должно включать следующие элементы: входные данные, ожидаемые и фактические результаты, отклонение от нормы, дата и время испытания, шаг процедуры испытания, среда функционирования, результаты попыток повторения условий эксперимента, испытатели, наблюдатели-регистраторы.

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

Критерий интенсивности обнаружения ошибок. Если считать, что во время одного эксперимента обнаруживается не более одной ошибки и каждая ошибка до начала следующего эксперимента устраняется, то можно предположить, что при благоприятном ходе отладки и испытания кривая зависимости: N = 1 — п/К, где п — количество обнаруженных и устраненных ошибок; К. —. количество экспериментов, будет асимптотически стремиться к единице (кривая 1 на рис. 17). Кривая 2 свидетельствует о неблагополучном ходе процесса.

Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N > 0,95 при обнаружении в последних двухстах экспериментах не более трех несущественных ошибок.

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

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

грамме (под дефектом понимается любая причина неудовлетворенности свойствами программы) описывается показательной функцией времени функционирования />

/> — исходное количество дефектов в программе; /> — общее количество дефектов, которое может проявиться за время эксплуатации ПС; />— средняя наработка на отказ в начале испытаний;

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

Скорость обнаружения и устранения дефектов, измеряемая относительно времени функционирования программы, пропорциональна интенсивности отказов. Коэффициент пропорциональности B=n/m называется коэффициентом уменьшения дефектов.

Количество зарегистрированных отказов т зависит от суммарного времени функционирования программы следующим образом:

Значение средней наработки на отказ также зависит от суммарного времени функционирования:

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

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

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

СТЕНДЫ ОТЛАДКИ И ИСПЫТАНИЯ ПРОГРАММ.

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

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

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

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

Автоматизированный технологический комплекс (АТК) состоит из элементов следующих типов: управляемый технологический агрегат (УТА), автоматизированная система управления технологическим процессом (АСУ ТП), датчики информации (ДИ) о состоянии управляемого процесса. На вход АТК поступает объект обработки (00), на выход—результат обработки (РО). Если прекратить доступ информации в ЭВМ от реальных физических объектов АТК, а вместо нее вводить адекватную ин формацию, имитируемую по КИМИС на инструментальной ЭВМ, то процесс функционирования ПО АСУ ТП будет адекватен реальному. Оператор УТА в принципе может участвовать в обеих режимах.

Программное обеспечение КИМИС в общем случае состоит из следующих подсистем: моделирования, анализа результатов испытания, регистрации событий (документирования), планирования и управления и базы данных (рис. 20). В состав подсистемы моделирования входят: модель заявок на обработку (МЗ), модель объекта обработки (МОО); модели датчиков информации (МДИ); имитатор помех (ИП); модель управляемого технологического агрегата (МТА).

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

В соответствии с заданным приоритетом или случайным образом выбирается 00, принимаемый на обслуживание, из совокупности 00, имитируемой МЗ, и его характеристики. Модели датчиков информации являются информационными моделями конкретных типов датчиков информации, используемых в системе управления АТК. Они имитируют выдачу текущих координат характеризующих состояние технологического процесса. Модель управляемого технологического агрегата (например, прокатного стана) имитирует управляемый технологический процесс (например, прокатки стали) с выдачей соответствующей информации об этом процессе. Имитатор помех в соответствии с заданными вероятностными характеристиками имитирует воздействие случайных факторов на элементы моделируемой системы и управляемый процесс. При этом используется датчик случайных чисел, позволяющий реализовать процедуру “розыгрыш”.

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

Имитируемый поток входной информации подается’ на вход испытываемого ПО АСУ и инициирует его функционирование, результатом которого является поток выходной (управляющей) информации, выдаваемый на УТА или его модель. Образуется замкнутый контур управления, адекватный контуру управления в реальном ДТК.

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

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

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

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

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

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

IV. СЕРТИФИКАЦИЯ ПРОГРАММНЫХ ПРОДУКТОВ.

СТАНДАРТИЗАЦИЯ СИСТЕМ КАЧЕСТВА.

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

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

При разработке ПМК системы УК ПП приняты следующие исходные положения:

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

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

3) за качество разрабатываемой ПП ответственность несет разработчик, поставляемой — поставщик;

4) руководство организации — разработчика несет ответственность за определение политики в области качества и за решения, касающиеся разработки, внедрения и ведения системы качества;

5) управление качеством ПП основывается прежде всего на стимулировании заинтересованности разработчиков и поставщиков в обеспечении высокого качества ПП, повышении профессионализма:

6) для обеспечения требуемого качества ПП управление качеством осуществляется на всех стадиях и этапах жизненного цикла ПП, начиная с самых ранних;

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

управление качеством ПП базируется на контроле качества в процессе разработки;

9) все формализуемые функции, процедуры и операции по управлению качеством в конечном счете должны быть переданы ЭВМ и реализованы на ней в виде инструментальных программ;

10) в идейном (концептуальном) плане инструментальные программы и методики, входящие в состав ПМК, должны представлять единое целое, согласующееся с принятой технологией программирования и являющееся составной частью этой технологии;

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

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

Основными методами стандартизации УК ПП в разрабатывающей организации являются: систематизация и классификация: типизация и унификация; регламентирование.

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

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

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

В США, например, в середине 80-х годов введены в действие следующие стандарты: ANSI/IEEE “Спецификация требований к ПО” (Guide to Software Requirements Specifications); “Планирование управления конфигурацией ПО” (Software Configuration Management Plans); “Документирование тестов ПО” (Software Test Documentation); “Планирование уровня качества ПО” (Software Quality Assurance Plan?). В качестве проектов апробируются и другие стандарты, в том числе “Справочник гарантии качества”, “Классификация отказов, сбоев и ошибок ПО”.

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

В 1987 г. утверждено пять международных стандартов ISO, устанавливающих требования к системам обеспечения качества продукции на предприятиях: “Стандарты по управлению качеством и обеспечению качества. Руководство для выбора и применения” (ISO 9000); “Система качества. Модели обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании” (ISO 900S); “Система качества. Модели обеспечения качества при производстве и монтаже” (ISO 9002); “Система качества. Модели обеспечения качества в процессе контроля и испытания готовой продукции” (ISO 9003); “Управление качеством и элементы системы качества. Основные направления” (ISO 9004).

КЛАССИФИКАЦИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА

Под показателем качества программной продукции в соответствии с ГОСТ 15467—79 следует понимать количественную характеристику одного или нескольких свойств продукции, составляющих ее качество, рассматриваемую применительно к определенным условиям ее создания и эксплуатации. Свойство продукции — это объективная особенность, которая может проявиться при создании или эксплуатации продукции. В определении понятия “Показатель качества” слова “Количественная характеристика” не следует понимать в буквальном смысле. При определении значений показателей качества успешно могут применяться и нечисловые характеристики, хотя в общем случае наличие строго количественных, числовых характеристик предпочтительней.

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

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

По количеству характеризуемых свойств различают единичные и комплексные показатели. Единичные показатели качества характеризуют одно из свойств ПС, комплексный—несколько. Комплексные показатели могут быть групповыми, обобщенными или интегральными.

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

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

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

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

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

ВЫБОР НОМЕНКЛАТУРЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА

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

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

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

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

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

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

выделение групп свойств должно производиться по четко определенным признакам;

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

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

для каждого из выделенных свойств должна существовать возможность выражения их в шкалах “лучше — хуже”, “больше — меньше”;

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

формулировка свойств должна быть однозначной;

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

дерево свойств должно отражать все основные особенности использования н функционирования ПС;

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

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

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

5—крайне важно, чтобы данный показатель имел высокое значение;

4—важно, чтобы данный показатель имел высокое значение;

3—хорошо бы иметь высокое значение данного показателя;

2— в некоторой степени полезно иметь высокое значение данного показателя;

1—при низких значениях данного показателя ощутимых потерь нет,

Около 50 % частных показателей можно определить автоматически с помощью ЭВМ, 25 % —с помощью компаратора. Таким образом, оценка около 75 % показателей может быть формализована. Оценка 20 % показателей может быть произведена только квалифицированным специалистом. Большинство показателей устанавливают путем статического анализа программ и лишь около 5 % — в процессе динамических испытаний (Данные соответствуют положению в этой области в 80-е годы).

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

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

ГРУППЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА

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

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

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

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

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

Экологические показатели и показатели безопасности нехарактерны для ПП, так как программные изделия непосредственно не могут оказывать вредных воздействий ни на окружающую среду, ни на здоровье человека. В принципе, такие воздействия возможны в тех случаях, когда ПИ используют в качестве элементов управляющих объектов, например в АСУ. В этом случае вырабатываемые ЭВМ по определенному алгоритму управляющие воздействия могут вызвать и неблагоприятные экологические последствия, и быть опасными для человека. Но это уже косвенное воздействие через управляющие органы и исполнительные механизмы автоматизированных технологических комплексов (АТК). Они учитываются как соответствующие показатели AT К.

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

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

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

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

Источник