Тестирование белого ящика

Тестирование удобства использования

A) Нагрузочное тестирование

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

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

Тестирование программного обеспечения

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

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

I) По объекту тестирования :

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

б) Стресс-тестирование

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

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

4) Тестирование интерфейса пользователя

5) Тестирование безопасности

6) Тестирование локализации

7) Тестирование совместимости

II) По знанию системы :

1) Тестирование чёрного ящика

(тестируется объект, внутреннее устройство которого неизвестно)

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

III) По степени автоматизированности :

1) Ручное тестирование

2) Автоматизированное тестирование

3) Полуавтоматизированное тестирование

IV) По степени изолированности компонентов :

1) Компонентное (модульное) тестирование

2) Интеграционное тестирование

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

V) По времени проведения тестирования :

1) Альфа тестирование – закрытый процесс тестирования программы штатными разработчиками или тестировщиками. Альфа продукт чаще всего завершен только на 50%, присутствует программный код, но отсутствие значительная часть оформления.

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

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

Санкт-Петербургский

Государственный Электротехнический Университет

Кафедра МОЭВМ

по дисциплине

“Процесс разработки программных изделий”

“Верификация ПО”

Санкт-Петербург

Цель верификации………………………………………………………………… стр. 3

Вводные замечания……………………………………………………………….. стр. 3

Специальные и общие целевые задачи………………………………………….. стр. 4

Ожидаемая практика по целевым задачам……………………………………… стр. 4

SG1 Подготовка к верификации………………………………………………..... стр. 4

SG2 Проведение экспертиз (экспертного оценивания)………………………… стр. 7

SG3 Осуществление верификации……………………………………………..... стр. 9

Приложение 1. Обзор средств автоматизации процесса верификации……….. стр. 11

Приложение 2. Основные современные подходы к верификации…………….. стр. 12

Список использованной литературы…………………………………………….. стр. 14

Интегрированнаяя модель совершенства и зрелости

Верификация (Уровень зрелости 3)

Цель

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

1. Водные замечания

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

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

определение соответствия высокоуровневых требований требованиям к системе;

учет высокоуровневых требований в архитектуре системы;

соблюдение архитектуры и требований к ней в исходном коде;

определение соответствия исполняемого кода требованиям к системе;

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

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

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

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

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

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

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

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

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

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

осмотр

сквозной структурный контроль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование - процесс выполнения программы с целью обнаружения ошибки.

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

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

Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.

Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.

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

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

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

Верификация и валидация (verification and validation - V& V) предназначены для анализа, проверки правильности выполнения и соответствия ПО спецификациям и требованиям заказчика. Данные методы проверки правильности программ и систем соответственно означают:

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

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

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

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

Верификации и валидации подвергаются:

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

Иными словами, основными систематическими методами правильности программ являются:

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

Стандарты ISO/IEC 3918-99 и 12207 включают в себя процессы верификации и валидации. Для них определены цели, задачи и действия по проверке правильности создаваемого продукта (включая рабочие, промежуточные продукты) на этапах ЖЦ и соответствия его требованиям.

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

Эти процессы взаимосвязанные и определяются одним термином - «верификация и валидация» (V&V 7).

При верификации осуществляется:

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

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

Идея создания международного проекта по формальной верификации была предложена Т. Хоаром, она обсуждалась на симпозиуме по верифицированному ПО в феврале 2005 г. в Калифорнии. Затем в октябре этого же года на конференции IFIP в Цюрихе был принят международный проект сроком на 15 лег но разработке «целостного автоматизированного набора инструментов для проверки корректности ПС».

В нем сформулированы следующие основные задачи:

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

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

Многие формальные методы доказательства и верификации специфицированных программ прошли практическую апробацию. Проделана большая работа международного комитета ISO/IEC в рамках стандарта ISO/ IEC 12207:2002 по стандартизации процессов верификации и валидации ПО. Проверка корректности формальными методами разных объектов программирования является перспективной.

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

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

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

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