в нахождении каких типов ошибок верификация эффективнее чем тестирование

Тестирование, верификация и валидация – различия в понятиях

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

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

Рис. 1 Тестирование, верификация и валидация

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

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

Если посмотреть на эти три процесса с точки зрения вопроса, на который они дают ответ, то тестирование отвечает на вопрос «Как это сделано?» или «Соответсвует ли поведение разработанной программы требованиям?», верификация – «Что сделано?» или «Соответствует ли разработанная система требованиям?», а валидация – «Сделано ли то, что нужно?» или «Соответствует ли разработанная система ожиданиям заказчика?».

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

Ещё один пример типичной верификации: проведение испытания оборудования. Имея определенные требования на руках, мы проводим испытание продукта и фиксируем, соблюдены ли требования. Результат верификации — это ответ на вопрос «Соответствует ли продукт требованиям?».

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

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

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

Таким образом, можно констатировать следующее:

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

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

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

Источник

Валидация и верификация требований к системе

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

В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

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

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

1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.

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

3. Неверный свод знаний. Нас учили приоритету массы над остальными параметрами, а оказалось, что надо было наращивать скорость.

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

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

6. Созданная система не соответствует описанию.

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

Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.

Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация — это в том числе проверка описания на непротиворечивость, полноту и понятность.

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

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

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

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

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

К задачам обеспечения качества относятся:

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

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

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

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

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Градация Приоритета дефекта (Priority):

Тестовые среды

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

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

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

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

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

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

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

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

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

Тест план должен отвечать на следующие вопросы:

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

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

Атрибуты тест кейса:

Источник

Верификация и валидация: что это и в чем разница?

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

Итого

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

ОСТАВЬТЕ ОТВЕТ Отменить ответ

Похожее

Что такое риск-тестирование?

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

Что такое use case? Теория и примеры

Что такое user story и как ее писать?

User Story переводится с английского как «пользовательская история». Это общее описание функций программы, написанное как бы от имени пользователя. В user-story формулируется, чем функционал приложения ценен для заказчика.

В этой статье мы разберем отличия user stories от спецификаций и дадим практические советы по написанию.

Источник

Верификация и тестирование программных средств.

План лекции

Литература.

1. Основные понятия верификации.

Под верификацией понимается процесс определения, в какой степени программные средства выполняют наложенные на них требования. Функции, выполняемые верификацией, определены в стандарте “ISO 12207” (SoftWare LifeCycle Processes. Процессы жизненного цикла программных средств).

В соответствии с требованиями стандарта “ISO 12207” процессы верификации программного средства включают в себя следующие задачи:

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

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

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

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

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

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

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

Во-первых, в том, что требования проектного планирования адекватны и скоординированы во времени;

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

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

В-четвертых, в том, что проект укомплектован ресурсами, и персонал обучен, как требуется по контракту.

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

Во-первых, в том, что требования системы непротиворечивы, выполнимы и проверяемы;

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

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

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

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

Во-первых, в том, что проект корректен и не противоречит исходным требованиям контракта;

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

В-третьих, в том, что выбранный проект полностью исходит от требований;

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

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

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

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

В-третьих, в том, что программа исходит из проекта и требований контракта;

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

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

Во-первых, в том, что компоненты программного средства и элементы каждого компонента программного средства полностью и правильно интегрированы в комплекс программ;

Во-вторых, в том, что компоненты аппаратных средств, компоненты программного средства и ручные операции полностью и правильно интегрированы в информационную систему;

В-третьих, в том, что интеграционные задачи выполнены согласно интеграционному плану.

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

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

Во-вторых, в том, что подготовка документации выполнена своевременно;

В-третьих, в том, что схема управления документами следует определенным плановым процедурам.

Для повышения эффективности затрат при реализации проекта, верификация должна быть выполнена как можно раньше.

2. Задачи тестирования.

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

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

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

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

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

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

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

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

Разработка тестов должна соответствовать международным и российским стандартам. Можно выделить следующие стандарты:

Стандарт ISO 12119 (“ Пакеты программ. Требования к качеству и тестирование”). Данный стандарт содержит раздел, который кратко определяет порядок тестирования программного продукта на соответствие данного программного продукта требованиям к качеству. Данные указания охватывают как тестирование для характеристик, присущих всем аналогичным продуктам, так и тестирование для особых характеристик, декларированных в описании данного программного продукта.

ГОСТ Р ИСО/МЭК 15408 («Общие критерии»). Данный стандарт в отношении тестирования вводит понятия «Покрытие» и «Глубина». Покрытие показывает полноту охвата тестами (т.е. покрытие тестами) функциональных возможностей объекта оценки. Глубина характеризует уровень детализации тестирования.

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

3. Принципы организации тестирования.

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

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

Принцип проектирования тестирования. Данный принцип требует рассмотрения вопросов тестирования на всех этапах проектирования программного обеспечения.

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

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

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

4. Методы тестирования.

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

Можно выделить два вида тестирования:

Во-первых, структурное тестирование;

Во-вторых, функциональное тестирование.

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

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

Во-первых, метод «покрытия операторов» (Statement Coverage – SC). Данный метод, основан на критерии, который предполагает выполнение каждого оператора программы, хотя бы один раз.

Во-вторых, метод «покрытия условий» (Decision Coverage – DC). Данный метод, основан на критерии, который предполагает запись числа тестов, достаточного для того, чтобы результаты каждого условия в решении выполнялись по крайней мере один раз.

В-третьих, метод «комбинаторного покрытия условий» (Modified Condition/Decision Coverage – MC/DC). Данный метод, основан на критерии, который требует создание такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись по крайней мере один раз.

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

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

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

Можно выделить следующие методы функционального тестирования:

Во-первых, метод «эквивалентного разбиения». Разработка тестов методом эквивалентного разбиения осуществляется в два этапа. На первом этапе выполняется выделение классов эквивалентности. На втором этапе выполняется построение тестов. Классы эквивалентности выделяются путем анализа каждого входного условия. За входное условие, как правило, принимается конкретное предложение спецификации.

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

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

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

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

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

Следует отметить следующие особенности функционального тестирования:

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

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

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

5. Инструментальные средства тестирования.

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

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

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

Во-первых, «организатор тестов», который управляет выполнением тестов.

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

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

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

В-пятых, «генератор отчетов тестирования», который формирует отчеты по тестам.

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

В-седьмых, «имитатор», который моделирует выполнение программы.

6. Валидация программных средств.

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

В стандарте ANSI/IEEE 1012 (“Планирование проверки (оценки) и подтверждения достоверности (валидация — аттестация) программных средств”) понятие валидации определено, как систематическое, поэтапное тестирование компонентов разного уровня интеграции в течение всего жизненного цикла программных средств. В стандарте оговорены единые требования, предъявляемые к формату и содержимому методик проверки программного средства и аттестации результатов тестирования. Данный стандарт обеспечивает всестороннюю оценку каждой фазы проекта программного средства и дает возможность гарантировать соблюдение следующих условий:

Во-первых, обнаружение и устранение ошибок на как можно более ранней стадии жизненного цикла ПС;

Во-вторых, снижение риска, связанного с проектом, затрат и действий, связанных с планированием разработки;

В-третьих, повышение качества и надежности ПС;

В-четвертых, улучшение обозримости организации проведения работ в процессе создания ПС;

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

Источник