Файл: Отладка и тестирование программ: основные подходы и ограничения (Метод черного ящика).pdf

Преимущества:

1. Обнаруживает ошибку в скрытом коде, удаляя лишние строки кода.
2. Максимальный охват достигается при написании тестового сценария [33.].
3. Разработчик тщательно обосновывает причины реализации.

Недостатки:

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

Метод серого ящика

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

Этот метод включает в себя следующие техники:

1. Тестирование ортогональных массивов

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

1. Матричное тестирование

В матричном тестировании указывается отчет о состоянии проекта.

1. Регрессионное тестирование

Если в программное обеспечение вносятся новые изменения, регрессионное тестирование подразумевает выполнение тестовых случаев.

1. Тестирование шаблонов

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

Преимущества:

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

2. При тестировании по этому методу специалист может разработать отличные сценарии тестирования.

3. Беспристрастное тестирование.

Недостатки:

1. Тестовое покрытие в данном случае ограничено, так как доступ к исходному коду невозможен.

2. Многие пути программы остаются непроверенными.

3. Контрольные примеры могут быть избыточными.

Сравнение методов тестирования приведено в таблице ниже.

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

Продолжение таблицы

Наблюдаемость и управляемость логики программного обеспечения

Основные понятия

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

Хотя существуют разные взгляды на наблюдаемость [36., 37.], все они в целом подразумевают способность тестировать различные функции программного обеспечения и наблюдать за результатами, с целью выяснить, соответствуют ли они спецификации программного обеспечения. Различные определения также имеет и управляемость. Грубо говоря, управляемость – это способность воспроизводить определенное поведение при выполнении программного обеспечения. Традиционные методы для достижения наблюдаемости и управляемости включают методы, которые вмешиваются в естественное выполнение программы. Примеры включают в себя использование точек останова, интерактивную отладку и добавление дополнительных операторов вывода. Эти методы часто не подходят (особенно для встроенного программного обеспечения), потому что они вызывают изменения в поведении синхронизации и потреблении ресурсов системы. Следовательно, наблюдаемый результат программного обеспечения создается видоизмененной программой, которая может нарушать правильность работы ПО. Эта программа может также вызвать проблемы с управляемостью. Например, ранее наблюдаемое поведение при выполнении может быть трудно воспроизводимым или невозможно воспроизводимым. Таким образом, в контексте тестирования и отладки программного обеспечения крайне желательно достичь наблюдаемости и управляемости программного обеспечения с наименьшими изменениями в поведении. В частности, во встроенном ПО это свойство действительно имеет решающее значение.

Проблема абстрактной диагностики в терминах наблюдаемости и управляемости программного обеспечения

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

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

Эта задача является примером известной абстрактной проблемы диагностики [38.]. Грубо говоря, в этой задаче дано описание цифровой схемы, значение сигналов ввода/вывода, набор компонентов и предикат, описывающий, какие компоненты могут потенциально работать некорректно. Теперь, если данное отношение ввода/вывода не соответствует описанию системы, цель проблемы состоит в том, чтобы найти минимальное количество неисправных компонентов, которые вызывают несоответствие. Общая проблема диагностики неразрешима, так как она так же сложна, как и решение формул логики первого порядка. Проблема наблюдаемости/управляемости может быть сформулирована как подзадача проблемы диагностики. В такой формулировке цель состоит не в том, чтобы найти, какие компоненты нарушают соответствие отношения ввода/вывода с описанием системы, а в том, чтобы найти минимальное количество компонентов, которые можно использовать для наблюдаемости/управляемости выполнения программного обеспечения при тестировании и отладке. Следуя этому конкретному решению проблемы абстрактной диагностики, сначала демонстрируется, что задача оптимизации является NP-полной, даже если предположить, что длина цепочек зависимостей данных не больше 2. Чтобы справиться с неизбежной экспоненциальной сложностью, необходимо перейти от общей проблемы, где длина цепочек зависимостей данных неизвестна, к целочисленному линейному программированию (ЦЛП). Хотя ЦЛП само по себе является полной NP-проблемой, существуют многочисленные методы и инструменты, которые позволяют решать целочисленные программы с тысячами переменных и ограничений.

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

1. Извлечение данных

Из исходного кода цепочки зависимостей данных извлекаются представляющие интерес переменные для диагностики.

1. Преобразование в ЦЛП

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

1. Решение задачи оптимизации

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

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

Обзор предшествующих достижений и дальнейшие перспективы

Как уже упоминалось ранее, вышеприведенная формулировка проблемы является примером теории абстрактной диагностики [38.]. Теория диагностики широко изучалась во многих контекстах. В работе [39.] Фиджани и Ватан предлагают два метода решения проблемы диагностики. В частности, они представляют собой преобразования из подзадачи проблемы диагностики в ЦЛП и задачу выполнимости. Предложенное ранее преобразование в ЦЛП носит более общий характер, поскольку рассматриваются цепочки зависимостей данных произвольной длины. Более того, авторы не приводят экспериментальные результаты и анализ.