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

Вид материалаПрограмма
Ручной контроль программного обеспечения
Сквозной просмотр
Проверка за столом
Структурное тестирование
Покрытие условий
Комбинаторное покрытие условий
Функциональное тестирование
Анализ граничных значений
Предположение об ошибки
Подобный материал:
1   2   3   4   5   6   7   8

Ручной контроль программного обеспечения


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

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

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

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

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

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

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

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

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

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

Недостатки структурного тестирования
  • не обнаруживают пропущенных маршрутов.
  • не обнаруживают ошибок, зависящих от обрабатываемых данных, например в операторе if (a-b)
  • не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию.

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



Формирование тестовых наборов для тестирования маршрутов осуществляется по следующим основным критериям:
  • покрытие оператор.
  • покрытие условий.
  • комбинаторное покрытие.

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

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

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

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

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

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

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

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

Анализ граничных значений. Граничные значения - это значения на границах классов эквивалентности входных значений или около них. Основное общие правило для применения этого метода: так как большая часть ошибок возникает на границах условий необходимо строить тесты с неправильными входными данными с близкими граничными условиями. Например, если описана область [-1.0, +1,0], то должны быть сгенерированы тесты –1.0, +1.0, -1.001 и +1.001

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

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