Методы проверки и тестирования программ и систем

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

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

Каскадная модель (Линейная последовательная модель жизненного цикла ПО)

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

Тестирование ПО с нуля. Виды, типы и уровни тестирования ПО. (Практические примеры от Senior QA)

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

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

Узнайте больше о каскадной модели из предыдущей статьи .

V-Model (Модель верификации и валидации)

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

Виды тестирования. Уроки по тестированию ПО

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

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

• Этап определения требований. Приемочное тестирование относится к этому этапу. Его основная задача состоит в оценке готовности системы к финальному использованию
• Этап, на котором происходит высокоуровневое проектирование, или High-Level Design (HDL). Этот этап относится к системному тестированию и включает оценку соблюдения требований к интегрированным системам
• Фаза детального дизайна (Detailed Design) параллельна фазе интеграционного тестирования, во время которой происходит проверка взаимодействий между различными компонентами системы
• После этапа написания кода начинается другой важный шаг — юнит-тестирование. Очень важно убедиться в том, что поведение отдельных частей и компонентов ПО корректно и соответствует требованиям

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

Инкрементная модель

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

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

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

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

Спиральная модель

Спиральная модель это методология тестирования ПО, которая основана на инкрементном подходе и прототипировании. Она состоит из четырех этапов:

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

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

Читайте подробнее o спиральной модели в предыдущем блог посте .

Agile

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

Узнайте больше об Agile (прим. — статья на английском языке) .

Экстремальное программирование (XP, Extreme Programming)

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

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

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

Scrum

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

• Участие в Scrum планировании
• Поддержка в юнит-тестировании
• Тестирование пользовательских историй
• Сотрудничество с заказчиком и владельцем продукта для определения критериев приемлемости
• Предоставление автоматического тестировании

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

В то же время принципы Agile методологии в Scrum к появлению специфических особенностей:

• Оценка усилий, необходимых для каждой пользовательской истории является обязательной
• Тестировщик должен быть внимательным к требованиям, поскольку они могут постоянно изменяться
• Риск регрессии возрастает вместе с частыми изменениями в коде
• Одновременность планирования и выполнения тестов
• Недопонимание между членами команды в случае если требования заказчика не до конца ясны

Узнайте больше о методологии Scrum из предыдущей статьи .

Заключение

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

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

• Об авторе
• Последние статьи

Источник: xbsoftware.ru

Лекция 8: Методы проверки и тестирования программ и систем

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

Теоретические средства определяют процесс программирования и тестирования программного продукта. К ним относятся методы верификации и доказательства правильности спецификации программ (см. «Формальные спецификации, доказательство и верификация программ» ), метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.) в качестве отдельных характеристик как формализованных элементов теории определения правильности и гарантии свойств конечного ПО . Например, концепция » чистая комната » базируется на формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования как процесса, то это проверка правильности работы программы по заданным описаниям тестов и покрытия данными соответствующих критериев программы [7.1-7.5].

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

При проверке правильности программ и систем рассматриваются процессы верификации, валидации и тестирования ПС, которые регламентированы в стандарте ISO/IEC 12207 [7.7] жизненного цикла ПО . В некоторой зарубежной литературе процессы верификации и тестирования отождествляются. С теоретической точки зрения верификация была рассмотрена в «Формальные спецификации, доказательство и верификация программ» , здесь же будут определены задачи и действия, соответствующих процессов ЖЦ.

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

7.1. Процессы ЖЦ верификация и валидация программ

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

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

Процесс верификации. Цель процесса — убедиться, что каждый программный продукт (и/или сервис) проекта отражает согласованные требования к их реализации. Этот процесс основывается:

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

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

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

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

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

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

На других процессах ЖЦ выполняются дополнительные действия:

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

Таким образом, основные задачи процессов верификации и валидации состоят в том, чтобы проверить и подтвердить, что конечный программный продукт отвечает назначению и удовлетворяет требованиям заказчика. Эти процессы взаимосвязаны и определяются, как правило, одним общим термином » верификация и валидация » или » Verification and Validation » (VV основаны на планировании их как процессов, так и проверки для наиболее критичных элементов проекта: компонент , интерфейсов (программных, технических и информационных), взаимодействий объектов (протоколов и сообщений), передач данных между компонентами и их защиты, а также оставленных тестов и тестовых процедур .

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

7.2. Тестирование программ

Тестирование можно рассматривать, как процесс семантической отладки (проверки) программы, заключающийся в исполнении последовательности различных наборов контрольных тестов, для которых заранее известен результат. Т.е. тестирование предполагает выполнение программы и получение конкретных результатов выполнения тестов [7.1-7.5, 7.11, 7.12].

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

Исторически первым видом тестирования была отладка .

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

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

7.2.1. Статические методы тестирования

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

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

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

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

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

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

7.2.2. Динамические методы тестирования

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

Динамическое тестирование ориентировано на проверку корректности ПС на множестве тестов, прогоняемых по ПС, в целях проверки и сбора данных на этапах ЖЦ и проведения измерения отдельных показателей (число отказов, сбоев) тестирования для оценки характеристик качества, указанных в требованиях, посредством выполнения системы на ЭВМ. Тестирование основывается на систематических, статистических, (вероятностных) и имитационных методах.

Дадим краткую их характеристику.

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

Цель динамического тестирования программ по принципу «черного ящика» — выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.

Методы «черного ящика» обеспечивают:

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

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

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

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

Метод «белого ящика» позволяет исследовать внутреннюю структуру программы, причем обнаружение всех ошибок в программе является критерием исчерпывающего тестирования маршрутов потоков (графа) передач управления, среди которых рассматриваются:

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

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

Тестирование по принципу «белого ящика» ориентировано на проверку прохождения всех путей программ посредством применения путевого и имитационного тестирования.

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

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

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

Источник: intuit.ru

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

Говоря о тестировании методом черного ящика, мы говорим о функциональном тестировании. Функциональное тестирование еще называют поведенческим или тестирование на поведенческом уровне.

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

1. Регрессионное тестирование – это повторное выполнение тестов для проверки того, что изменения, внесенные в программу в результате разработки новой или изменения существующей функциональности, устранения ошибок не повлияли на функциональность, которая не изменилась.
2. Тестирование новой функциональности – в данном виде тестирования акцент делается на тестирование новой функциональности, появившейся в конкретном выпуске программного продукта.
3. Конфигурационное тестирование– проверяется совместимость продукта с различным программным и аппаратным обеспечением.
4. Тестирование совместимости– помогает убедиться в функциональных возможностях и надежности работы продукта.
5. Тестирование удобства эксплуатации– тестирование пользовательского интерфейса проводится в отношении таких моментов как внешний вид, удобство навигации.

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

1. Тестирование прототипа
2. Интеграционное тестирование
3. Тестирование безопасности
4. Тестирование интернационализации
5. Локализационное тестирование
6. Компонентное тестирование
7. Системное тестирование
8. Исследовательское тестирование
9. Тестирование документации
10. Тестирование производительности
11. Нагрузочное тестирование
12. Стрессовое тестирование
13. И т.д. и т.д.

Источник: studfile.net