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

Лекция 5

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

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

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

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

Дефект (баг, глюк- bug, defect) - любое несоответствие фак5тического и ожидаемого результата (согласно требованиям или здравому смыслу). Это ошибка программиста, дизайнера или ещё кого, кто принимает участие в разработке ПО,

Дефект может возникнуть

• на стадии формулирования требований,

• на стадии проектирования,

• на стадии кодирования,

• из-за некорректной конфигурации,

• из-за некорректных данных,

• и т.д.

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

 

 

Failure ( сбой, причём не обязательно аппаратный) в работе компонента, программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (а defect caused the failure) и существуют такие, которые не приводят. (Сбой — это нарушение нормального функционирования отдельной программы, устройства или компьютера в целом. Внешне это выглядит как появление различных сообщений.)

 

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

 

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

 

Жизненный цикл бага (Bug workflow) – последовательность этапов, которые проходит баг на своём пути с момента его создания до окончательного закрытия.

 

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

 

Приоритет (Priority) – это порядок в котором дефекты должны быть исправлены. Чем выше стоит приоритет, тем скорее нужно исправить дефект, выставляется менеджером, тимлидом или заказчиком. Выделяют 3 уровня приоритета.

1. Высокий (High). Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

2. Средний (Medium). Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

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

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

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

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

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

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

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

 

Тест-кейс (test case) - набор входных данных, условий, ожидаемых результатов. Этот набор разрабатывается для проверки некоторого свойства ПО или поведения ПО.

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

Что надо тестировать?

Что будете тестировать?

Критерии начала тестирования.

Критерии окончания тестирования.

https://habrahabr.ru/post/279535/

 

Билд, релиз (build, realese) - промежуточная и конечная версии ПО.

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

Фактический результат (Actual result) – наблюдаемое или генерируемое поведение компонента или системы во время тестирования.

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

 

Тестовая деятельность

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

 

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

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

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

Две базовых функции тестирования – верификация(verification) и аттестация (validation - валидация).

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

Валидация – гарантия того, что ПО удовлетворяет системным требованиям, т.е. дает гарантию того, что построен требуемый продукт.

Основные тестируемые элементы (примеры важных элементов ПО)

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

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

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

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

Тестирование ПО (software testing) — это процесс анализа или эксплуатации ПО с целью выявления дефектов. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование суть плановая, упорядоченная деятельность.

Персонал

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

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

  Действия на стадии планирования испытаний есть подготовительные этапы для этапов системных и приемочных тестов. На этапе планирования

× определяется стратегия тестирования,

× производится оценка времени для проведения тестовых работ,

× определяется состав и структура испытательной системы (выявление аппаратных и  

программных средств тестирования),

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

Проектирование тестов.

На этапе проектирования и разработки тестов определяются

× цели теста,

× спецификация для ввода каждого теста,

× тестовая конфигурация,

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

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

Проектирование тестов состоит из двух компонентов:

• архитектура тестов,

• подробные планы тестов.

Архитектура тестов упорядочивает тесты по группам, таким как

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

• испытания для определения рабочих характеристик,

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

• и т.д.

Она также описывает структуру и соглашения по именованию хранилища тестов.

Подробные планы тестов описывают

• назначение каждого теста,

• технические средства (ОС, вычислительная платформа)

• данные для выполнения теста,

• ожидаемые результаты каждого теста,

• требование, на подтверждение которого ориентируется данный тест.

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

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

• спроектированы,

• закодированы,

• отлажены

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

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

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

· функциональная проверка,

· испытания для определения рабочих характеристик.

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

· наличие всех функциональных требований технического задания;

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

 Проводят тестирование

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

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

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

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

· по принадлежности к конкретной части проектного решения (сервер, клиент, посредник),

· по используемым технологиям,

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

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

Рисунок 2 - Пример иерархической структуры процесса тестирования программного продукта.

 

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

• нагрузочные испытания,

• тестирование в предельных режимах,

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

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

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

К прочим видам тестирования относят

· тестирование процесса установки или развертывания ПО,

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

· тестирование способности системы к восстановлению нормальной работы после сбоев, вызванных отказами АО или системного ПО.

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

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

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

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

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

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

Сопровождение

Сопровождение обозначает

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

· тестирование расширенных функциональных возможностей,

· выполнение регрессионных тестов на новых версиях ПО.

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

Матрица прослеживаемости требований (requirements traceability matrix) - документ, который отображает каждое требование на промежуточные результаты процесса разработки, такие как компоненты проекта, модули программного обеспечения и результаты тестирования. Она может быть представлена в виде электронной таблицы, таблицы текстового процессора, базы данных или Web-страницы (подробно будет рассмотрена позднее).

 

 

Лекция 5

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

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

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

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

Дефект (баг, глюк- bug, defect) - любое несоответствие фак5тического и ожидаемого результата (согласно требованиям или здравому смыслу). Это ошибка программиста, дизайнера или ещё кого, кто принимает участие в разработке ПО,

Дефект может возникнуть

• на стадии формулирования требований,

• на стадии проектирования,

• на стадии кодирования,

• из-за некорректной конфигурации,

• из-за некорректных данных,

• и т.д.

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

 

 

Failure ( сбой, причём не обязательно аппаратный) в работе компонента, программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (а defect caused the failure) и существуют такие, которые не приводят. (Сбой — это нарушение нормального функционирования отдельной программы, устройства или компьютера в целом. Внешне это выглядит как появление различных сообщений.)

 

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

 

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

 

Жизненный цикл бага (Bug workflow) – последовательность этапов, которые проходит баг на своём пути с момента его создания до окончательного закрытия.

 

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

 

Приоритет (Priority) – это порядок в котором дефекты должны быть исправлены. Чем выше стоит приоритет, тем скорее нужно исправить дефект, выставляется менеджером, тимлидом или заказчиком. Выделяют 3 уровня приоритета.

1. Высокий (High). Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

2. Средний (Medium). Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

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

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

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

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

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

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

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

 

Тест-кейс (test case) - набор входных данных, условий, ожидаемых результатов. Этот набор разрабатывается для проверки некоторого свойства ПО или поведения ПО.

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

Что надо тестировать?

Что будете тестировать?

Критерии начала тестирования.

Критерии окончания тестирования.

https://habrahabr.ru/post/279535/

 

Билд, релиз (build, realese) - промежуточная и конечная версии ПО.

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

Фактический результат (Actual result) – наблюдаемое или генерируемое поведение компонента или системы во время тестирования.

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

 

Тестовая деятельность

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

 

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

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

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

Две базовых функции тестирования – верификация(verification) и аттестация (validation - валидация).

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

Валидация – гарантия того, что ПО удовлетворяет системным требованиям, т.е. дает гарантию того, что построен требуемый продукт.

Основные тестируемые элементы (примеры важных элементов ПО)

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

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

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

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

Тестирование ПО (software testing) — это процесс анализа или эксплуатации ПО с целью выявления дефектов. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование суть плановая, упорядоченная деятельность.

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

 

Функциональное тестирование (Functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

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

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