Верификация и аттестация ПО. У многих партнеров Banners Broker на главной странице бэк-офиса появилась надпись на красном фоне с сообщением

Верификация и аттестация ПО

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

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

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

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

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

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

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

 

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

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

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

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

· архитектура ПО и требования к компонентам низкого уровня корректно переработаны в удовлетворяющие им исходные тексты программных и информационных модулей;

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

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

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

На выбор эффективных методов верификации и последовательность их применения в наибольшей степени влияют основные характеристики тестируемых объектов:

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

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

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

 

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

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

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

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

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

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

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

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

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

· Проверка того, что программное обеспечение соответствует требованиям на него,

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

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

 

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

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

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

Цель проверяющего (тестовика) — заставить программное обеспечение сбиться. Он доволен, если это ему удается.Если программное изделие правильно ведет себя для солидного набора тестов, нет оснований утверждать, что в нем нет ошибок. Просто неизвестно, когда оно не сработает и можно говорить лишь о некотором уровне уверенности в его правильности.

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

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

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

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

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

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

В некоторых случаях тестирования рекомендуется производить «миниатюризацию» программы, т.е. разумно сокращать объём данных по сравнению с реальным. Например, создать укороченную базу данных. Проверить матрицу 50x50 вручную невозможно. Поэтому в качестве теста может быть использована матрица 5x5. Точно так же, если некоторая подпрограмма работает в цикле 5 раз, она сможет работать и 105 раз. Правда, при миниатюризации программы могут произойти ситуации: либо существующие в программе ошибки в результате упрощающих изменений станут неявными или временно исчезнут, либо появятся новые ошибки.

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

В целом составление тестов — большое искусство, т.к. полностью этот процесс формализации не поддается.

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

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

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

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

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

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

Для ускорения отладки не безразличен порядок пропуска тестов: сначала пропускаются простые тесты...

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

Усложнение тестовых данных должно происходить постепенно.

Процесс тестирования программного обеспечения можно разделить на три этапа:

— проверка в нормальных условиях;

— проверка в экстремальных условиях;

— проверка в исключительных ситуациях.

Каждый из этих трех этапов проверки должен гарантировать получение верных результатов при правильных входных данных и/или выдачу сообщений об ошибках при неправильных входных данных.

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

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

Типичные примеры — очень большие числа, очень малые числа или отсутствие информации.

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

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

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

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

Различают еще так называемые «Альфа»- и «Бета»-тестирования.

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

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

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

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

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

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

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

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