Тестирование которое осуществляет выявление ошибок только на выполняющейся программе

Аннотация: Основные понятия тестирования. Фазы и этапы тестирования. Типы тестов. Разработка, управляемая тестами (Test Driven Development)

ТЕСТИРОВАНИЕ И ОТЛАДКА

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

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

Процесс отладки включает:

 действия, направленные на выявление ошибок (тестирование);

 диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);

 внесение исправлений в программу с целью устранения ошибок.

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

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

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

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

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

 отсутствие эталона (программы), которому должна соответ­ствовать тестируемая программа;

 высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ни одна из этих крайностей не является хорошей стратегией.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод большого скачка значительно усложняет отладку.

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

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

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

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

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

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

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

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

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

Сравнение методов тестирования

С точки зрения надежности ПО стратегии тестирования можно оценить по семи критериям (табл. 9).

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

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

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

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

Шестой критерий связан с ответом на вопрос: возможно ли проверить любой конкретный путь и любое условие в программе?

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

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

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

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

Третий критерий, необходимость драйверов — вес 1 ввиду доступности общих инструментов тестирования.

Критерий, связанный с параллелизмом работы, имеет вес 1 (он может быть важен по другим причинам, но на надежность сильно не влияет).

Шестой критерий — вес 3.

Седьмой критерий получает вес 2.

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

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

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

Тестирование программных модулей — наиболее форма­лизованный и автоматизированный процесс тестирования.

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

Проверяется корректность структуры модулей и их конструктивных основных компонентов: процедур, циклов, блоков, условий и т.д.

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

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

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

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

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

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

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

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

В качестве примера рассмотрим программный пакет, состоя­щий из девяти модулей (рис. 16).

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

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

Рис. 16. Структура пакета из 9 модулей

Для рассматриваемого примера модули-драйверы нужны для всех модулей, кроме модуля М1, а модули-заглушки нужны для всех модулей, кроме М5, М6, М7, М8, М9 (т.е. модулей самого низ­шего уровня).

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

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

Предположим, что тестируем сверху-вниз. Тогда для модуля М1 нужно разработать три заглушки. Далее подключается модуль М2, для которого нужно предварительно разработать две заглушки, и тес­тируются модули М1-М2. Затем заглушка М5 заменяется модулем М5 и тестируется цепочка М1-М2-М5.

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

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

При тестировании снизу-вверх процесс организуется следую­щим образом: тестируются модули низшего уровня — М5, М6, М7, М8, М9. Для каждого из них нужен драйвер.

Далее параллельно проводится тестирование М5-М2, М6-М2, М7-М3, М8-М4, М9-М4. Затем подключается модуль М1 и проводится комплексное тес­тирование всего пакета.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конфуций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже приведены рекомендации по организации отладки в форме заповедей.

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

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

Заповедь 3. Готовьте тесты, как для правильных, так и для неправильных данных.

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

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

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

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

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

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

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

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

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

 простота подготовки тестов;

 возможность полной реализации плана тестирования модуля.

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

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

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

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

 необходимость специального тестирования сопряжения модулей.

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

 большинство тестов готовится в форме, рассчитанной на пользователя;

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

 отпадает необходимость тестирования сопряжения модулей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными видами испытания программных продуктов (ПП) являются:

 предварительные;

 приемочные;

 эксплуатационные испытания, включая опытную эксплуатацию.

В зависимости от места проведения различают стендовые и полигонные испытания.

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

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

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

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

По степени зависимости испытателей от разработчиков различают зависимые и независимые испытания.

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

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

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

Технологическая схема испытания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование и оценка испытаний

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

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

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

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

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

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

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

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

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

 нахождение всех путей реализации;

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

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

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

N = 1 — n/К,

где n —	количество обнаруженных и устраненных ошибок;
К -	количество экспериментов.

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

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

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

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

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

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

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

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

В качестве критерия завершенности испытания можно принять достижение требуемого (заданного) значения средней наработки на отказ Т₀.

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

 скорость выявления дефектов;

 скорость устранения дефектов;

 удовлетворенность машинным временем.

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

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

Тестирование программного обеспечения является неотъемлемой частью цикла разработки программного обеспечения.

Что такое тестирование программного обеспечения?

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

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

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

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

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

2) Интеграционное тестирование

3) Системное тестирование

4) Приемочные испытания

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

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

Интеграционное тестирование

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

Системное тестирование

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

Приемочные испытания

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

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

Основные тесты

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

 

Тестирование методом черного ящика

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

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

Тестирование методом «Белого ящика», в отличие от «черного ящика», учитывает внутреннее функционирование и логику работы кода. Для выполнения этого теста, тестер должен иметь знания кода, чтобы узнать точную часть кода, имеющую ошибки. Этот тест также известен как White-box, Open-Box или Glass box тестирование.

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

Тестирование методом серого ящика

Тестирование методом серого ящика или Gray box тестирование, это что-то среднее между White Box и Black Box тестированием, где тестер обладает лишь общими знаниями данного продукта, необходимыми для выполнения теста. Эта проверка осуществляется посредством документации и схемы информационных потоков. Тестирование проводится конечным пользователем, или пользователям, которые представляются как конечные.

Нефункциональные тесты

Тестирование безопасности

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

Стресс-тестирование

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

Тестирование на совместимость

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

Тестирование эффективности

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

Юзабилити-тестирование

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

Тесты в процессе разработки программного обеспечения

Каскадная модель

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

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

• Анализ потребностей
• Тест дизайна
• Тест реализации
• Тестирование, отладка и проверка кода или продукта
• Внедрение и обслуживание

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

Agile Model

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

Rapid Application Development (RAD). Методология быстрой разработки приложений

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

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

Спиральная модель

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

Rational Unified Process (RUP). Рациональный унифицированный процесс

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

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

Читайте также

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

В зависимости от степени доступа к коду системы можно выделить два типа функциональных испытаний:

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

Ключевые преимущества

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

Основные этапы функционального тестирования

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

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

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

Направления функционального тестирования

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

Тестирование безопасности — Оценка уязвимости ПО к различным атакам и попыткам несанкционированного доступа к данным.

Системное тестирование — Проверка соответствия ПО требованиям, заявленным в спецификации

Тестирование мобильных приложений — Выявление дефектов в работе графического интерфейса

Тестирование установки — Тестирование процесса инсталляции/деинсталляции программного обеспечения

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

Интеграционное тестирование — Тестирование взаимодействий между компонентами системы и между несколькими системами.

Smoke-тестирование — Короткий цикл тестов для выявления правильной работы основных функций приложения.

Тестирование документации — Проверка документов на соответствие принятым стандартам, а также соответствие определенным характеристикам

Обеспечение тестового покрытия — Оценка плотности покрытия системы тестами

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

Регрессионное тестирование

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

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

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

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

Ключевые преимущества

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

Основные этапы

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

Интеграционное тестирование

Многие современные ИТ-системы взаимодействуют с другими системами и модулями, поэтому крайне

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

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

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

Ключевые преимущества

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

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

Основные задачи

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

Способы проведения интеграционного тестирования подбираются в зависимости от интеграционных решений.

Этапы

⦁ Разработка тест-плана – руководства к действию для тестировщиков;
⦁ Формирование тестовых данных и создание тест-кейсов;
⦁ Реализация сценариев для запуска тест-кейсов;
⦁ Выполнение тест-кейсов и исправление ошибок;
⦁ Повторение цикла тестирования до успешной интеграции.

Тестирование безопасности

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

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

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

Ключевые преимущества

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

Основные задачи

⦁ Анализ архитектуры и построение  модели угроз и рисков
⦁ Определение критериев защищенности
⦁ Поиск уязвимостей в исходном коде
⦁ Fuzz тестирование
⦁ Тестирование на проникновение
⦁ Тестирование, основанное на рисках
⦁ Проведение нагрузочного тестирования

Этапы

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

Smoke-тестирование

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

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

Ключевые преимущества

⦁ Выявление критичных ошибок в первые несколько часов (минут) после установки
⦁ Снижение рисков вывода некачественного продукта;
⦁ Минимизация рисков при интеграции систем;
⦁ Сокращение затрат на исправление дефектов;
⦁ Ускорение проверки за счет автоматизации.

Основные задачи

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

Системное тестирование

Системное тестирование предназначено для тестирования

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

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

Ключевые преимущества

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

Основные задачи

⦁ Определение подхода к составлению тестовых сценариев
⦁ Создание плана и методики испытаний
⦁ Подготовка тестовых данных
⦁ Проведение тестирования
⦁ Выявление некорректного использования ресурсов

Этапы

⦁ Тестовый план
⦁ Разработка тестов
⦁ Подготовка тестовых данных
⦁ Тестовые прогоны – автоматизированные и обычные
⦁ Составление отчета
⦁ Регрессионое тестирование после исправления ошибок

Тестирование документации

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

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

Ключевые преимущества

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

Тестирование документации включает тестирование нескольких уровней документации:

⦁ Бизнес-требования
⦁ Функциональные требования
⦁ Техническое задание
⦁ Руководства пользователей

Тестирование мобильных приложений

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

Ключевые преимущества

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

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

Обеспечение тестового покрытия

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

Ключевые преимущества

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

Основные задачи

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

Тестирование установки

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

Ключевые преимущества

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

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

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

Тестирование удобства использования

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

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

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

Основные задачи

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

В рамках данной задачи оценивается:

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

Конфигурационное тестирование

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

Ключевые преимущества

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

Основные этапы конфигурационного тестирования

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

Лекция
3:
Основные понятия тестирования

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

Концепция тестирования

Программа – это
аналог формулы в обычной математике.

Формула для функции
f,
полученной суперпозицией функций f₁,
f₂,
… f_n
– выражение, описывающее эту суперпозицию.

f
= f₁*
f₂*
f₃*…
* f_n

Если аналог
f₁,f₂,…
f_n
– операторы языка программирования,
то их формула – программа.

Существует два
метода обоснования истинности
формул:

1. Формальный
   подход или
   доказательство
   применяется, когда из исходных
   формул-аксиом с помощью формальных
   процедур (правил вывода) выводятся
   искомые формулы и утверждения (теоремы).
   Вывод осуществляется путем перехода
   от одних формул к другим по строгим
   правилам, которые позволяют свести
   процедуру перехода от формулы к формуле
   к последовательности текстовых
   подстановок:

2. A**3
   = A*A*A

3. A*A*A
   = A -> R, A*R -> R, A*R -> R

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

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

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

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

Основная терминология

Отладка (debug,
debugging)– процесс
поиска, локализации и исправления ошибок
в программе [IEEE Std.610-12.1990].

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

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

Как правило, на
фазе тестирования
осуществляется и исправление
идентифицированных ошибок, включающее
локализацию ошибок, нахождение причин
ошибок и соответствующую корректировку
программы тестируемого приложения
(Application Under Testing (AUT) или Implementation Under Testing
(IUT)).

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

Пример поиска и исправления ошибки

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

//
Метод вычисляет неотрицательную

//
степень n числа x

static
public double Power(double x, int n)

{

double
z=1;

for
(int i=1;n>=i;i++)

{

z
= z*x;

}

return
z;

}

Пример
2.1. Исходный
текст
метода
Power

double
Power(double x,int n)

{

double
z=1;

int
i;

for(i=1;n>=i;i++)

{

z=z*x;

}

return
z;

}

Пример 2.1.1. Исходный
текст метода Power

Если вызвать метод
Power
с отрицательным значением степени n
Power(2,-1), то
получим некорректный результат — 2.
Исправим метод так, чтобы ошибочное
значение параметра (недопустимое по
спецификации значение) идентифицировалось
специальным сообщением, а возвращаемый
результат был равен 1

//
Метод вычисляет неотрицательную

//
степень n числа x

static
public double PowerNonNeg(double x,

int
n)

{

double
z=1;

if
(n>0)

{

for
(int i=1;n>=i;i++)

{

z
= z*x;

}

}

else
Console.WriteLine(

«Ошибка
! Степень
числа
n» +

»
должна быть больше 0.»);

return
z;

}

Пример 2.2.
Скорректированный исходный текст

double
PowerNonNeg(double x, int n)

{

double
z=1;

int
i;

if
(n>0)

{

for
(i=1;n>=i;i++)

{

z
= z*x;

}

}

else
printf(«Ошибка! Степень числа n должна
быть больше 0.n»);

return
z;

}

Пример 2.2.1.
Скорректированный исходный текст

Если вызвать
скорректированный метод PowerNonNeg(2,-1)
с отрицательным значением параметра
степени, то сообщение об ошибке будет
выдано автоматически.

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

Тестирование
разделяют на статическое и динамическое:

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Введение

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

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

С точки зрения математики тестирование можно рассматривать как интерпретацию некоторой формулы и проверки ее истинности на некоторых множествах. Действительно, программу можно представить в виде формулы f = f1* f2* f3*… * fn, где f1, f 2, … fn — операторы языка программирования, а их суперпозиция — программа.

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

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

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

Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования — Testbed или Testbench.

Основы тестирования

Классы критериев тестирования

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

• Условие критерия тестирования команд (критерий С0) — набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза.
• Условие критерия тестирования ветвей (критерий С1) — набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза.
• Условие критерия тестирования путей (критерий С2) — набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз.

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

Выделяют следующие частные виды функциональных критериев:

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

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

Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.

Метод мутационного тестирования состоит в том, что в разрабатываемую программу P вносят мутации (мелкие ошибки), т.е. искусственно создают программы-мутанты P1, P2… . Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X, Y).

Если на наборе (X, Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X, Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной. Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X, Y) и продолжать тестирование.

Фазы тестирования

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

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

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

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

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

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

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

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

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

Тестовый цикл — это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build.

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

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

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

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

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

Типы тестов

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

Типы тестирования по виду подсистемы или продукта таковы:

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

Типы тестирования по способу выбора входных значений:

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

Test Driven Development

Рассмотрим подход к тестированию, несколько отличающийся от приведенного выше. Разработка через тестирование (Test Driven Development — TDD) — процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

TDD задает следующий порядок этапов программирования:

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

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

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

Итоги

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

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

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

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

Концепция тестирования. Тестирование как способ обеспечения качества информационных систем. Основные понятия тестирования.

Концепция тестирования или Что такое тестирование и откуда оно появилось

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

На протяжении десятилетий развития разработки ПО к вопросам тестирования и обеспечения качества подходили по-разному. Можно выделить несколько основных «эпох тестирования».

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

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

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

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

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

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

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

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

Автоматизация тестирования уже воспринималась как неотъемлемая часть большинства проектов.

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

Для современного этапа развития тестирования характерно следующее:

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

Понятие «Тестирование Информационных систем»

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

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

Программа – это аналог обычной формулы в математике.

Формула для функции f , полученной суперпозицией f1, f2, … fn – выражение, описывающее эту суперпозицию.

f=f1*f2*f3*…*fn

Если аналог f1, f2, … fn — операторы языка программирования, то их формула – программа.

Существует два метода обоснования истинности формул:

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

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

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

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

Отладка(debug, debugging)   – процесс поиска, локализации и исправления ошибок в программе.

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

Тестирование  – это процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта.

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

Тестирование  обеспечивает выявление наличия фактов расхождений с требованиями (ошибок).

Тестирование  разделяют на статическое и динамическое :

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

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

Последовательность действий при тестировании

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

=i;i++) { z = z*x; } return z; } » width=»640″

Пример вычисления степени числа

#include

double Power(int x, int n)

{

int z=1;

int i;

for (i=1;n=i;i++)

{

z = z*x;

}

return z;

}

=0) & (x { printf(«Enter n:»); if(scanf(«%d»,&n)) { if ((n=1) & (n { » width=»640″

void main(void)

{

int x;

int n;

printf(«Enter x:»);

if(scanf(«%d»,&x))

{

if ((x=0) & (x

{

printf(«Enter n:»);

if(scanf(«%d»,&n))

{

if ((n=1) & (n

{

printf(«The power n of x is %fn», Power(x,n));

}

else

{ printf(«Error : n must be in [1..100]n»); } }

else { printf(«Error : Please enter a numeric argumentn»); }

}

else { printf(«Error : x must be in [0..999]n»); }

}

else { printf(«Error : Please enter a numeric argumentn»); }

}

Спецификация программы

• На вход программа принимает два параметра: x — число, n – степень. Результат вычисления выводится на экран.
• Значения числа и степени должны быть целыми.
• Значения числа, возводимого в степень, должны лежать в диапазоне – [0..999].
• Значения степени должны лежать в диапазоне – [1..100].
• Если числа, подаваемые на вход, лежат за пределами указанных диапазонов, то должно выдаваться сообщение об ошибке.

999 (ошибочное) x — не число (ошибочное) 0 n n 100 (ошибочное) n — не число (ошибочное) 1 Анализ тестовых случаев Входные значения: (x = 2, n = 3). Ожидаемый результат: The power n of x is 8. » width=»640″

Разработка тестов

• Определим области эквивалентности входных параметров.
• Для x – числа, возводимого в степень, определим классы возможных значений:
• x
• x 999 (ошибочное)
• x — не число (ошибочное)
• 0
• n
• n 100 (ошибочное)
• n — не число (ошибочное)
• 1

Анализ тестовых случаев

• Входные значения: (x = 2, n = 3). Ожидаемый результат: The power n of x is 8.

• Входные значения: {(x = -1, n = 2),(x = 1000, n = 5)}. Ожидаемый результат: Error : x must be in [0..999].
• Входные значения: {(x = 100, n = 0),(x = 100, n = 200)}. Ожидаемый результат: Error : n must be in [1..100].
• Входные значения: (x =  ADS  
• n = ASD).  Ожидаемый результат: Error : Please enter a numeric argument.
• Проверка на граничные значения:

• Входные значения: (x = 999, n = 1).Ожидаемый результат: The power n of x is 999. Входные значения: (x = 0, n = 100).Ожидаемый результат: The power n of x is 0.
• Входные значения: (x = 999, n = 1).Ожидаемый результат: The power n of x is 999.
• Входные значения: (x = 0, n = 100).Ожидаемый результат: The power n of x is 0.

Выполнение тестовых случаев

• Запустим программу с заданными значениями аргументов.

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

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