Что такое валидация тестирование
Верификация VS Валидация. В чём разница?
У многих начинающих и не только тестировщиков возникают сложности с понятиями верификация и валидация. В этой статье мы расставим все точки над «и» и разберём как можно подробнее эти понятия.
Начнём с определений:
Верификация (Verification) — Доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены.
Валидация (Validation) — Доказанное объективными результатами исследования подтверждение того, что требования для ожидаемого конкретного использования приложения были выполнены.
Пока не очень понятно в чём конкретно разница.
Давайте на минуту отвлечёмся и разберём ещё 2 понятия:
Статическое тестирование (Static testing) — Тестирование артефактов разработки программного обеспечения, таких как требования, дизайн, программный код, проектной и сопроводительной документации, проводимое без исполнения этих артефактов. Например, с помощью рецензирования или статического анализа.
Динамическое тестирование (Dynamic testing) — Тестирование, проводимое во время выполнения программного обеспечения, компонента или системы.
А теперь вернёмся к верификации и валидации.
Верификация = статическое тестирование
Валидация = динамическое тестирование
Разберём пару примеров:
Надеюсь, что теперь стало проще и понятнее 🙂
Валидация и верификация требований к системе
Очень часто путают два понятия валидация и верификация. Кроме того, часто путают валидацию требований к системе с валидацией самой системы. Я предлагаю разобраться в этом вопросе.
В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.
Пусть у нас есть проектируемый функциональный объект. Пусть этот объект рассматривается нами как часть конструкции другого функционального Объекта. Пусть есть описание конструкции Объекта, такое, что в нем присутствует описание объекта. В таком описании объект имеет описание как целого, то есть, описаны его интерфейсы взаимодействия с другими объектами в рамках конструкции Объекта. Пусть дано описание объекта как конструкции. Пусть есть информационный объект, содержащий требования к оформлению описания объекта как конструкции. Пусть есть свод знаний, который содержит правила вывода, на основании которых из описания объекта как целого получается описание объекта как конструкции. Свод знаний – это то, чему учат конструкторов в институтах – много, очень много знаний. Они позволяют на основе знанию об объекте спроектировать его конструкцию.
Итак, можно начинать. Мы можем утверждать, что если правильно описан объект как целое, если свод знаний верен, и если правила вывода были соблюдены, то полученное описание конструкции объекта, будет верным. То есть, на основе этого описания будет построен функциональный объект, соответствующий реальным условиям эксплуатации. Какие могут возникнуть риски:
1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.
2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.
3. Неверный свод знаний. Нас учили приоритету массы над остальными параметрами, а оказалось, что надо было наращивать скорость.
4. Неправильное применение правил вывода к описанию объекта. Логические ошибки, что-то пропущено в требованиях к конструкции объекта, нарушена трассировка требований.
5. Неполная запись полученных выводов о конструкции системы. Все учли, все рассчитали, но забыли написать.
6. Созданная система не соответствует описанию.
Понятно, что все артефакты проекта появляются, как правило, в завершенном своем виде только к концу проекта и то не всегда. Но, если предположить, что разработка водопадная, то риски такие, как я описал. Проверка каждого риска – это определенная операция, которой можно дать название. Если кому интересно, можно попытаться придумать и озвучить эти термины.
Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.
Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация — это в том числе проверка описания на непротиворечивость, полноту и понятность.
Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.
Валидация — что это простыми словами? Чем отличается валидация от верификации? + ПРАКТИЧЕСКИЙ СОВЕТ
Здравствуйте, дорогие читатели! Добро пожаловать на блог!
Валидация — что это простыми словами? Чем отличается валидация от верификации? Ответы на эти вопросы — в статье.
Многие слова «валидация» и «верификация» считают синонимами. Но это не так. Разница есть, но она очень тонкая. Давайте разбираться.
Валидация и верификация — что это простыми словами?
Справедливости ради надо сказать, что в разных областях деятельности (в банках, в платежных системах, в интернете), в разных отраслях производства эти термины используются по-разному. Я решила привести здесь определение валидации и верификации из стандарта ISO 9000.
Мы видим, что определения совпадают в значительной части, но не полностью. Однако, несмотря на такое большое совпадение валидация и верификация — это разные действия.
Чтобы проще было понять, что такое валидация, давайте сначала разберемся, чем валидация отличается от верификации.
Чем отличается валидация от верификации?
Итак, что такое верификация? Более детально можете узнать из этой статьи, но здесь скажем коротко, что слово «верификация» происходит от английского слова «verification» — проверка. А слово «валидация» происходит от английского «validation» — придание законной силы.
Примеры валидации и верификации в разных сферах.
Без примеров трудно понять отличия валидации и верификации. Приведем несколько примеров из разных областей.
Пример из области медицины
Скажем, разработали новое лекарство. Провели многочисленные тесты для ПРОВЕРКИ, что лекарство лечит такую-то болезнь. Здесь речь идет о ВЕРИФИКАЦИИ (о проверке соответствия лекарства его предназначению). Но Вы знаете, что на самом деле лекарство подходит не всем. Чтобы начать лечение Вам нужна ВАЛИДАЦИЯ врача. Только врач может ПОДТВЕРДИТЬ, что это лекарство подойдет КОНКРЕТНО Вам.
ВЕРИФИКАЦИЯ — это тестирование лекарства с целью ПРОВЕРКИ на соответствие его предназначению. А ВАЛИДАЦИЯ — это ПОДТВЕРЖДЕНИЕ врача, что лекарство подойдет КОНКРЕТНОМУ больному.
Пример из области производства
Предположим завод по производству велосипедов принял заказ на партию велосипедов. Так вот, ВЕРИФИКАЦИЮ (ПРОВЕРКУ) на соответствие требованиям заказчика выполняет сам завод-производитель. А вот ВАЛИДАЦИЮ (ТЕСТИРОВАНИЕ, ПРОВЕРКУ) на соответствие своим требованиям будут выполнять представители самого заказчика.
Пример из области IT
Аналогичный пример можно привести из области IT. Компания — разработчик программного обеспечения получила заказ на разработку какого-то софта. Программа, которая была создана, прошла тестирование. Результатом тестирования является ВЕРИФИКАЦИЯ на стороне компании, выполняющей заказ, что программа полностью соответствует тех заданию заказчика. А вот ВАЛИДАЦИЮ будет выполнять сам заказчик, когда установит программное обеспечение и протестирует его.
Пример из сферы интернета
Социальная сеть Твиттер проводит ВЕРИФИКАЦИЮ аккаунтов знаменитостей, чтобы участники сети точно знали, что посты публикуются действительно этой знаменитостью. В результате верификации в аккаунте знаменитости появляется синий значок с галочкой.
Еще пример. Для того, чтобы стать продавцом на Амазоне, Вам необходимо пройти ВЕРИФИКАЦИЮ личности. Также необходимо пройти верификацию при регистрации аккаунтов во всех платежных системах (Вебмани, Яндекс.Деньги, Киви и т.д.)
Пример из законодательной области
Инициативный депутат решил улучшить жизнь и придумал прогрессивный Закон. Законотворческие органы выполнят ПРОВЕРКУ нового Закона на соответствие другим Законам и международному праву и ВЕРИФИЦИРУЮТ его. Но Закон вступит в силу не сразу, а только через месяц — после его ВАЛИДАЦИИ (придания законной силы) высшим органом законодательной власти. За этот месяц можно отозвать Закон, выявив вред для каких-то КОНКРЕТНЫХ слоев населения.
Например, соц сеть Твиттер верифицирует аккаунты знаменитостей для того, чтобы пользователи были уверены, что сообщения действительно публикует эта знаменитость или её официальный представитель. В аккаунте пользователя Твиттере, который прошел такую верификацию, ставится синий значок с галочкой.
Теперь можно сделать общий вывод, что верификация (проверка) встречается чаще, чем валидация. Валидация (подтверждение для конкретного случая) нужна не всегда.
Практический совет
Вы спросите, для чего нужно разбираться в этих терминах? Скажу, что есть и практическая польза. Главная цель верификации и валидации — безопасность, чтобы Ваши банковские карты и аккаунты были защищены. Однако, пользуясь тем, что многие не разбираются в этих терминах, злоумышленники для похищения личных данных часто применяют такой способ, как сообщение с просьбой верифицировать или валидировать вашу банковскую карту, аккаунт и т.д..
Практический совет: При появлении окна с просьбой верификации или валидации Ваших данных проверьте в адресной строке данные сайта, нет ли пропущенных или лишних символов. Либо попробуйте зайти в эту программу с другого устройства и если такого сообщения не появляется, значит Ваш компьютер надо лечить от опасных вирусов.
Резюме
Надеюсь, статья, оказалась полезной для Вас и Вы теперь знаете ответы на вопросы: Валидация — что это простыми словами? Чем отличается валидация от верификации?
Вот по традиции порция полезного видео. В котором Жак Фреско учит мыслить нестандартно, не так, как все. ЭТИ НЕСКОЛЬКО МИНУТ БУДУТ ТОЧНО ПОТРАЧЕНЫ НЕ ЗРЯ!
Желаю всем новых идей и много сил для их реализации!
Эссе о валидации данных
Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Как выполнять валидацию данных?
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (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) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса: