Анализ стратегий тестирования программного обеспечения

Секция математического обеспечения и применения ЭВМ

УДК 004.4

С.В. Бирюков АНАЛИЗ СТРАТЕГИЙ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

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

♦ Выявить преимущества и недостатки существующих подходов.

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

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

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

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

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

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

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

Стратегия поведенческого тестирования основана на технических требованиях к программному обеспечению. Такое тестирование называют еще тестированием «черного ящика» (black-box testing). При проведении процедуры тестирования не обязательно знать, как объект (программа) сконструирован внутри. Он как бы представляет собой черный ящик, о котором известна лишь информация о его входах и выходах. При этом нет никаких данных о том, как именно программа преобразует входные данные в выходные. При проведении поведенческого тестирования в соответствии с требованиями к ПО определяется набор тестовых входных данных и предсказывается корректное поведение программы. Затем программа выполняется на подготовленном наборе и результат сравнивается с предсказанным [4].

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

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

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

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

♦ Тесты основаны на спецификации и не зависят от исходного кода. Это избавляет от необходимости изменять тестовый набор при модификации исходного кода.

♦ Удобство автоматизации и регрессионного тестирования на базе тестов, построенных на основе стратегии «черного ящика».

♦ Некоторые возникающие редко ситуации не будут проверены вследствие того, что тесты, как правило, покрывают основную функциональ-

ность.Стратегия структурного тестирования определяется структурой исследуемого программного обеспечения. Такое тестирование называют еще тестированием «белого ящика» (white-box testing) или тестированием «прозрачного ящика». Вся процедура тестирования строится исходя из знания того, как объект (программа) сконструирован внутри. Объект - это прозрачный ящик, о котором известна не только информация о его входах и выходах, но, прежде всего, известен механизм преобразования входных данных в выходные [5].

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

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

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

Основными методами структурного тестирования являются покрытие операторов программы, покрытие ветвей программы, покрытие условий.

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

♦ Минимальная стоимость устранения дефекта. Локализация ошибки внутри конкретного программного модуля не приведет к ее миграции в другие части программы и не потребует затрат на ее поиск и устранение.

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

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

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

♦ Специалист по тестированию обязан четко разбираться в проверяемом коде, что приводит к увеличению расхода ресурсов на тестирование.

♦ Сложность тестирования системы в целом. Обычно тесты могут быть построены только для отдельных модулей системы.Тестирование в реальных условиях, как правило, выполняется непосредственно на месте использования программного продукта самим пользователем либо совместно с представителем заказчика. Такое тестирование заключается в активизации подготовленных заказчиком реальных сценариев использования программы [6]. Как правило, сценарии использования не являются повторением тестового набора, построенного в соответсвии со стратегией «черного ящика». В большинстве случаев реальный сценарий использования представляет собой комбинацию некоторого подмножества тестов «черного ящика».

Среди особенностей тестирования в реальных условиях выделяются:

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

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

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

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

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

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

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Полаженко С. Тестирование программного обеспечения: Актуальность вопросов тестирования безопасности // http://security.software-testing.ru.

2. Тамре Л. Введение в тестирование программного обеспечения. - М.: Вильямс, 2003. -359 с.

3. Липаев В.В. Тестирование программ. - М.: Радио и связь, 1986. - 295 с.

4. Бейзер Б. Тестирование “черного ящика”. Технология функционального тестирования программного обеспечения. - СПб.: Питер, 2004. - 318 с.

5. Myers G. The art of software testing. New York: John Wiley & Sons, 2004. 234 p.

6. BlackR. Managing the software testing process. Redmond: Microsoft press, 1999. 381p.

7. Канер C., Фолк Д., Кек Нгуен Е.. Тестирование программного обеспечения. - Киев: ДиаСофт, 2000. - 544 с.

УДК 681.51

А.Н. Шкурко ПРОБЛЕМЫ РАСПОЗНАВАНИЯ ОБЪЕКТОВ В УСЛОВИЯХ ОТСУТСТВИЯ АПРИОРНОЙ ИНФОРМАЦИИ О РАКУРСЕ СЪЕМКИ С ИСПОЛЬЗОВАНИЕМ МУЛЬТИСПЕКТРАЛЬНЫХ ИЗОБРАЖЕНИЙ

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

При получении мультиспектральных изображений используют различные типы аппаратов: спутниковые кадровые спектрофотометры; кадровые спектрофотометры, устанавливаемые на самолеты и ДПЛА; стационарные лабораторные спектрофотометрические установки.

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

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

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