Аттестация и верификация программного обеспечения

Аттестация и верификация программного обеспечения

Понятия аттестации и верификации

Под верификацией и аттестацией понимают процессы проверки-соответствия ПО своей спецификации и ожиданиям заказчиков. Указанные процессы начинаются на этапе анализа требований и завершаются на этапе приемки системы.

В соответствии с ГОСТ Р ИСО/МЭК 12207 — 99 аттестация (validation) — это процесс определения соответствия программного продукта потребностям пользователей. Аттестацию обычно проводят для конечного продукта в условиях, максимально приближенных ктем, в которых будет эксплуатироваться система. При необходимостиаттестация может проводиться на более ранних стадиях.

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

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

В процессе верификации и аттестации используются две основные методики проверки и анализа систем [49]:

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

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

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

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

Преобладающим методом верификации и аттестации на текущий момент является тестирование.

 

 

ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

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

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

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

 

МЕТОДЫ ТЕСТИРОВАНИЯ ПО ЗНАНИЯМ О ПО

Систематические методы тестирования делятся на методы, в которых программа рассматривается как «черный ящик», и методы, в которых программа рассматривается как «белый ящик».

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

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

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

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

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

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

Тестирование «белого ящика» — это технология тестирования, которая применяется на этапе разработки (иногда ее еще называют тестированием «стеклянного ящика»).

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

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

■ полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте;

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

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

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

Тестирование «белого ящика» — часть процесса программирования.

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

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

Покрытие кода

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

• покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована?

• покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована?

• покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы?

• покрытие функций — каждая ли функция программы была выполнена?

• покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены?

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

 

Тестирование «серого ящика»

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

 

Главным минусом Black-box тестирования является то, что тестировщик не знает, какую часть ПО он тестирует. Некоторые существующие пути в программе (о которых нет информации ни в требованиях, ни в документации), могут никогда не быть проверены. Уменьшить количество таких путей можно путем анализа внутреннего устройства программы.

 

Информация о базе данных

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

Например, если вводимая фамилия пользователя записывается в поле типа "строка" длиной 128 символов, мы должны:

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

2) вне зависимости от того, существуют или нет такие фамилии, попробовать ввести строку длиннее 128 символов - программа не должна ломаться (должно показываться внятное сообщение об ошибке)

 

Информация о коде программы

Если мы имеем доступ к коду программы, мы можем

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

б) увидеть, что какие-то вещи тестировать не имеет смысла.

 

 

Модульное тестирование

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

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

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

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

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

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

Модульное тестирование включает в себя:

■ проверку программного кода с использованием некоторого инструментального средства для выявления синтаксических ошибок в программном коде (синтаксическую проверку);

■ проверку кода на соответствие стандартам кодирования (например, соответствия оформления программного кода требованиям организации-разработчика);

■ технический обзор программного кода.

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

Структурное тестирование является одним из видов тестирования «белого ящика». Его главной идеей является правильный выбор тестируемого программного пути.

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

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

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

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

Элементами интеграционного тестирования являются:

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

■ проверка наличия и корректности промежуточных результатов;

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

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

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

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

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

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

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

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

Категории тестов системного тестирования:

■ полнота решения функциональных задач;

■ корректность использования ресурсов (утечка памяти, возврат ресурсов и т.п.);

■ оценка производительности;

■ эффективность защиты от искажения данных и некорректных действий;

■ проверка инсталляции и конфигурации на разных платформах;

■ корректность документации.

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

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

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

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

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

Приемочное тестирование

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

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

Существует еще две разновидности тестирования, отличающиеся друг от друга временем исполнения — альфа-тестирование и бета-тестирование.

Альфа-тестирование

Альфа-тестирование — это реальная работа с программным обеспечением потенциальными пользователями или заказчиками либо имитация реальной работы разработчиками.

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

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

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

Бета-тестирование

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

2. Потребление оперативной памяти, (Мб) — метрика, показывающая количество памяти, использованной приложением. Использованная память делится на несколько категорий:

■ объем виртуального адресного пространства, которое использует процесс. Этот объем подразумевает как использование соответствующего дискового пространства, так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти, принадлежащей другому процессу;

■ объем адресного пространства, занятого процессом и не разделяемого с другими процессами;

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

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

3. Потребление сетевых ресурсов — указывает на пределы производительности системы в целом.

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

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

 

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

 

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

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

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

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

Основные направления применения стресс-тестирования:

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

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

■ исследование узких мест системы или отдельных компонент при диспропорциональных нагрузках;

■ тестирование емкости системы.

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

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

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

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

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

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

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

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

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

РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ

Регрессионное тестирование — тестирование программного обеспечения, направленное на обнаружение ошибок в уже протестированных участках исходного кода.

 

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

Регрессионное тестирование включает:

■ проверку исправления вновь найденного дефекта;

■ проверку того, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова;

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

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

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

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

Можно сформулировать некоторые правила построения библиотеки регрессионных тестов.

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

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

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

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

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

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

 

ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ

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

Тестирование документации охватывает следующие виды документов:

• функциональные спецификации;

• описание графического интерфейса пользователя;

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

В ходе тестирования документации выполняется проверка следующих аспектов:

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

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

• точность (актуальность информации, правильность ссылок и графических элементов);

• структура документа (соответствие порядк