Верификация и тестирование программных средств.



Авторы специализируются на тестах по любым дисциплинам! Средний балл по тестам 4,6.
 
Любые вопросы по дистанционному обучению. Тесты, письменные работы, сессия под ключ.
 
Известный интернет сайт, помощь по любым учебным вопросам - от теста до дипломной работы. Личный менеджер.
 
Крупная биржа студенческих работ. Закажи напрямую у преподавателя. Низкие цены, стена заказов.
 
Биржа студенческих работ. Потребуется самостоятельная выгрузка работ.
 

 План лекции

  1. Основные понятия верификации.
  2. Задачи тестирования.
  3. Принципы организации тестирования.
  4. Методы тестирования.
  5. Инструментальные средства тестирования.
  6. Валидация программных средств.

Литература.

  1. Смирнов А.А. Прикладное программное обеспечение. Учебное пособие. М.:МЭСИ, 2011.
  2. Липаев В.В. Программная инженерия. Методологические основы. Учебник. М.: ТЕИС, 2006.
  3. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. М.: СИНТЕГ, 2001
  4. Котляров В.П., Коликова Т.В. Основы тестирования программного обеспечения: Учебное пособие. М.: БИНОМ, 2006
  5. ISO 12207:1995. Процессы жизненного цикла программных средств.
  6. ГОСТ Р ИСО/МЭК 15408 («Общие критерии»)
  7. DO-178B «Software Considerations in Airborne Systems and Equipment Certification» («Оценки программного обеспечения для сертификации бортовых авиационных систем и оборудования»)

 

 

1. Основные понятия верификации.

Под верификацией понимается процесс определения, в какой степени программные средства выполняют наложенные на них требования. Функции, выполняемые верификацией, определены в стандарте “ISO 12207” (SoftWare LifeCycle Processes. Процессы жизненного цикла программных средств).

В соответствии с требованиями стандарта  “ISO 12207” процессы верификации программного средства включают в себя следующие задачи:

Первая задача верификации «Проверка контракта». При проверке контракта необходимо удостовериться в следующем:

Во-первых, в том, что поставщик имеет возможность удовлетворить требования контракта;

Во-вторых, в том, что требования непротиворечивы и покрывают все нужды пользователя;

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

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

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

Вторая задача верификации «Проверка процесса проектирования». При проверке процесса проектирования необходимо удостовериться в следующем:

Во-первых, в том, что требования проектного планирования адекватны и скоординированы во времени;

Во-вторых, в том, что процессы, выбранные для проекта, адекватны, реализуемы, выполняются, как запланировано и соответствуют контракту;

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

В-четвертых, в том, что проект укомплектован ресурсами, и персонал обучен, как требуется по контракту.

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

Во-первых, в том, что требования системы непротиворечивы, выполнимы и проверяемы;

Во-вторых, в том, что требования системы распределены между компонентами аппаратных средств, компонентами программного средства  и ручными операциями согласно критериям проекта;

В-третьих, в том, что требования к программному средству последовательны, выполнимы, тестируемы и точно отражают требования системы;

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

Четвертая задача верификации «Проверка проекта». При проверке проекта необходимо удостовериться в следующем:

Во-первых, в том, что проект корректен и не противоречит исходным требованиям контракта;

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

В-третьих, в том, что выбранный проект полностью исходит от требований;

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

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

Во-первых, в том, что текст программы удовлетворяет проекту и требованиям, тестируем, корректен и соответствует стандартам программирования;

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

В-третьих, в том, что программа исходит из проекта и требований контракта;

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

Шестая задача верификации «Проверка интеграции». При проверке интеграции необходимо удостовериться в следующем:

Во-первых, в том, что компоненты программного средства и элементы каждого компонента программного средства полностью и правильно интегрированы в комплекс программ;

Во-вторых, в том, что компоненты аппаратных средств, компоненты программного средства и ручные операции полностью и правильно интегрированы в информационную систему;

В-третьих, в том, что интеграционные задачи выполнены согласно интеграционному плану.

Седьмая задача верификации «Проверка документации». При проверке документации необходимо удостовериться в следующем:

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

Во-вторых, в том, что подготовка документации выполнена своевременно;

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

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

2. Задачи тестирования.

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

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

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

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

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

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

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

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

Разработка тестов должна соответствовать международным и российским стандартам. Можно выделить следующие стандарты:

Стандарт ISO 12119 (Пакеты программ. Требования к качеству и тестирование”). Данный стандарт содержит раздел, который кратко определяет порядок тестирования программного продукта на соответствие данного программного продукта требованиям к качеству. Данные указания охватывают как тестирование для характеристик, присущих всем аналогичным продуктам, так и тестирование для особых характеристик, декларированных в описании данного программного продукта.

ГОСТ Р ИСО/МЭК 15408 («Общие критерии»). Данный стандарт в отношении тестирования вводит понятия «Покрытие» и «Глубина». Покрытие показывает полноту охвата тестами (т.е. покрытие тестами) функциональных возможностей объекта оценки. Глубина характеризует уровень детализации тестирования.

В стандарте ANSI/IEEE 1008 (“Тестирование программных модулей и компонентов ПС”) рассмотрена методика отладки отдельных модулей и небольших групп программ. Целями данного стандарта являются создание единого подхода к тестированию компонентов программного средства, который может быть использован на практике в качестве основы для получения эффективных ПС, а также описание концепций и допущений, принимаемых при тестировании.

3. Принципы организации тестирования.

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

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

Принцип проектирования тестирования. Данный принцип требует рассмотрения вопросов тестирования на всех этапах проектирования программного обеспечения.

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

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

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

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

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

Можно выделить два вида тестирования:

Во-первых, структурное тестирование;

Во-вторых, функциональное тестирование.

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

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

Во-первых, метод «покрытия операторов» (Statement Coverage – SC). Данный метод, основан на критерии, который предполагает выполнение каждого оператора программы, хотя бы один раз.

Во-вторых, метод «покрытия условий» (Decision Coverage – DC). Данный метод, основан на критерии, который предполагает запись числа тестов, достаточного для того, чтобы результаты каждого условия в решении выполнялись по крайней мере один раз.

В-третьих, метод «комбинаторного покрытия условий» (Modified Condition/Decision Coverage – MC/DC). Данный метод, основан на критерии, который требует создание такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись по крайней мере один раз.

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

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

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

Можно выделить следующие методы функционального тестирования:

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

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

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

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

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

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

Следует отметить следующие особенности функционального тестирования:

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

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

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

5. Инструментальные средства тестирования.

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

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

Можно выделить следующие инструментальные средства программной среды тестирования:

Во-первых, «организатор тестов», который управляет выполнением тестов.

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

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

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

В-пятых, «генератор отчетов тестирования», который формирует отчеты по тестам.

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

В-седьмых, «имитатор», который моделирует выполнение программы.

6. Валидация программных средств.

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

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

Во-первых, обнаружение и устранение ошибок на как можно более ранней стадии жизненного цикла ПС;

Во-вторых, снижение риска, связанного с проектом, затрат и действий, связанных с планированием разработки;

В-третьих, повышение качества и надежности ПС;

В-четвертых, улучшение обозримости организации проведения работ в процессе создания ПС;

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