Тестирование правильности

Процесс тестирования состоит из:

1. тестирование элементов. Цель - индивидуальная проверка каждого модуля. Используется способ тестирования «белого ящика».

2. тестирование интеграции. Цель – тестирование сборки модулей в программную систему(«черный ящик»).

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

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

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

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

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

α- тестирование проводится заказчиком в организации разработчика. Разработчик фик­сирует все выявленные заказчиком ошибки и проблемы использования.

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

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

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

1. предусмотреть средства обработки ошибки, которые тестируют все вводы информа­ции от других элементов системы;

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

3. записать результаты тестов для использования их как доказательства невиновности в случае «указания причины»;

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

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

1. ТЕСТИРОВАНИЕ ВОССТАНОВЛЕНИЯ

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

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

2. ТЕСТИРАНИЕ БЕЗОПАСНОСТИ

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

В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:

• попытки узнать пароль с помощью внешних средств;

• атака системы с помощью специального утилита, анализирующих защиты;

• подавление, ошеломление системы (в надежде, что она откажется обслуживать др. клиентов);

• целенаправленное введение ошибок в надежде проникнуть в систему в ходе восста­новления;

• просмотр несекретных данных в надежде найти ключ для входа в систему.

Конечно, при неограниченном времени и ресурсах хорошее тестирование

безопасности

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

Существует 2 принципа тестирования программы: функциональное и структурное тести­рование.

[При тестировании «белого ящика» известна внутренняя структура программы и иссле­дуются внутренние элементы программы и связи между ними. Объект тестирования - внут­реннее поведение программы. Проверяется корректность построения всех элементов про­граммы и правильность их взаимодействия друг с другом. Такое тестирование характеризу­ется степенью , в какой тесты выполнят или покрывают логику (исходный текст) програм­мы.

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

При тестировании «черного ящика» рассматриваются системные характеристики про­грамм, игнорируется их внутренняя логическая структура. Тестирование «черного ящика» реагирует на многие особенности программных ошибок.]

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

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

НИСХОДЯЩЕЕ ПРОГРАММИРОВАНИЕ [top-down programming]

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

ЗАГЛУШКА [module stub] - фиктивная подпрограмма, имитирующая одну или не­сколько функций временно отсутствующего модуля разрабатываемой программы. Например, заглушка при модульном программировании для того, чтобы можно было проводить компиля­цию, тестирование и отладку незаконченной программы, не дожидаясь, когда некоторые отсут­ствующие в ней модули будут разработаны в надлежащем виде и испытаны. В зависимости от функций заменяемого модуля заглушка может выдавать либо правдоподобный результат (на­пример, значения из таблицы), либо некоторое сообщение (например, фиксирующее вызов от­сутствующей подпрограммы).

ВОСХОДЯЩЕЕ ПРОГРАММИРОВАНИЕ [bottom up programming ].

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