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

Обновлено: 04.07.2024

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

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

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

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

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

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

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

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

7.3. Инфраструктура процесса тестирования ПС

Под инфраструктурой процесса тестирования понимается:

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

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

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

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

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

7.3.1. Методы поиска ошибок в программах

Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.

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

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

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

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

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

Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

Характерными ошибками этого процесса являются:

  • неадекватность спецификации требований конечным пользователям;- некорректность спецификации взаимодействия ПО со средой функционирования или с пользователями;
  • несоответствие требований заказчика к отдельным и общим свойствам ПО;
  • некорректность описания функциональных характеристик;
  • необеспеченность инструментальными средствами всех аспектов реализации требований заказчика и др.

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

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

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

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

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

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

Все ошибки, которые возникают в программах, принято подразделять на следующие классы [7.12]:

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

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

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

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

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

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

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

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

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

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

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

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

Приведем следующую классификацию типов отказов:

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

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

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

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

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

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


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

  • Тестирование
  • Отладка
  • Верификация
Вопрос 2

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

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

Основные задачи тестировщика

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

Система методов отбора и создания тестов для тестового набора

Вопрос 5
  • Отладка
  • Испытание
  • Контроль
  • Настройка
Вопрос 6
  • тестирование программного кода на этапе разработки программного обеспечения
  • поиск ошибок при выполнении программ в тестовой или моделируемой среде
  • попытка найти ошибки при выполнении программы в реальной среде
Вопрос 7
  • тестирование программного кода на этапе разработки программного обеспечения
  • поиск ошибок при выполнении программ в тестовой или моделируемой среде
  • попытка найти ошибки при выполнении программы в реальной среде
Вопрос 8
  • тестирование программного кода на этапе разработки программного обеспечения
  • поиск ошибок при выполнении программ в тестовой или моделируемой среде
  • попытка найти ошибки при выполнении программы в реальной среде
Вопрос 9

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

  • План тестирования
  • Тест-дизайн
  • Тест-кейс
  • Баг-репорт
Вопрос 10

процесс тестирования ПО, на котором проектируются и создаются тест-кейсы в соответствии с определенными ранее критериями качества и целями тестиро­вания.

  • Тест-дизайн
  • План тестирования
  • Тест-кейс
  • Баг-репорт
Вопрос 11

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

  • Тест-кейс
  • Тест-дизайн
  • План тестирования
  • Баг-репорт
Вопрос 12

Тест-кейсы подразделяют по ожидаемому результату на:

  • позитивные и негативные
  • правильные и неправильные
  • первичные и вторичные
  • положительные и отрицательные
Вопрос 13

Каждый кейс-комплект содержит общую информацию о тести­ровании:

  • название проекта
  • номер версии
  • имя тестера
  • даты тестирования
  • номер тестирования
  • название теста
  • количество тестов
Вопрос 14

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

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

В соответствии с этапом обработки, на котором появляются ошибки, различают:

  • синтаксические ошибки
  • ошибки компоновки
  • ошибки выполнения
  • глобальная ошибка
Вопрос 16

ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы

Презентация на тему: " Тестирование программных средств Тема 11. Тестирование – процесс выполнения программы с намерением найти ошибки Цель проверяющего (тестовика) заставить." — Транскрипт:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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