Полное тестирование, когда проверяются все возможные последовательности выполнения программы, невозможно. Поэтому тестирование должно базироваться на некотором подмножестве всевозможных тестовых сценариев.
Из опыта тестирования больших программных продуктов вытекает, что необычные комбинации функций иногда могут вызывать ошибки, но наиболее часто используемые функции всегда работают правильно.
Методов тестирования дефектов существует несколько.
Тестирование методом черного ящика заключается в том, что вся система представляется как «черный ящик», поведение которого можно определить только посредством изучения входных и соответствующих выходных данных. Другое название этого метода – функциональное тестирование, так как проводится анализ только выполняемых функций.
Области эквивалентности. Входные данные, принадлежащие одному классу, имеют общие свойства, например это положительные числа. Обычно для всех данных из какого-либо класса поведение программы одинаково (эквивалентно). Один из систематических методов обнаружения дефектов состоит в определении всех областей эквивалентности, обрабатываемых программой. Контрольные тесты разрабатываются так, чтобы входные и выходные данные лежали в пределах этих областей.
Структурное тестирование. Метод структурного тестирования предполагает создание тестов на основе структуры системы и ее реализации. Такой подход иногда называют методом «белого ящика», «прозрачного ящика», «стеклянного ящика», чтобы отличать его от тестирования методом черного ящика. Как правило, структурное тестирование применяется к относительно небольшим программным элементам. При таком подходе испытатель анализирует код и для получения тестовых данных использует знания о структуре компонента. Например, из анализа кода можно определить, сколько контрольных тестов нужно выполнить для того, чтобы в процессе тестирования все операторы выполнились по крайней мере один раз.
Тестирование ветвей. Это метод структурного тестирования, при котором проверяются все независимо выполняемые ветви компонента или программы. Если выполняются все независимые ветви, то и все операторы должны выполняться по крайней мере один раз. Более того, все условные операторы тестируются как с истинными, так и с ложными значениями условий. В ООС тестирование ветвей используется для тестирования методов, ассоциированных с объектами. Количество ветвей в программе обычно пропорционально ее размеру. После интеграции программных модулей в систему, методы структурного тестирования оказываются невыполнимыми. Поэтому методы тестирования ветвей, как правило, используются при тестировании отдельных программных элементов и модулей. При тестировании ветвей не проверяются все возможные комбинации ветвей программы. Не считая самых тривиальных программных компонентов без циклов, подобная полная проверка компонента оказывается нереальной, так как в программах с циклами существует бесконечное число всевозможных комбинаций ветвей. В программе могут быть дефекты, которые проявляются только при определенной комбинации ветвей, даже если все операторы протестированы хотя бы один раз.
После того, как протестированы все отдельные программные компоненты, выполняется сборка системы, в результате чего создается частичная или полная система. Процесс интеграции системы включает сборку и тестирование полученной системы, в ходе которого выявляются проблемы, возникающие при взаимодействии компонентов. Тесты, проверяющие сборку системы, должны создаваться на основе системной спецификации. Тестирование сборки должно начинаться сразу после создания работоспособных версий компонентов системы.
Во время тестирования сборки возникает проблема локализации выявленных ошибок. Между компонентами системы существуют сложные взаимоотношения, и при обнаружении между ними аномальных выходных данных бывает трудно установить источник ошибки. Чтобы облегчить локализацию ошибок, следует использовать пошаговый метод сборки и тестирования системы. Сначала следует создать минимальную конфигурацию системы и протестировать ее. Затем в минимальную конфигурацию нужно добавить новые компоненты и снова протестировать, и так далее до полной сборки системы.
Нисходящее и восходящее тестирование. Методики нисходящего (НТ) и восходящего тестирования (ВТ) отражают разные подходы к системной интеграции. При нисходящей интеграции компоненты высокого уровня интегрируются и тестируются еще до окончания их проектирования и реализации. При восходящей интеграции перед разработкой компонентов более высокого уровня сначала интегрируются и тестируются компоненты нижнего уровня.
НТ является неотъемлемой частью процесса нисходящей разработки систем, при котором сначала разрабатываются компоненты верхнего уровня, а затем компоненты, находящиеся на нижних уровнях иерархии. Программа представляется в виде одного абстрактного компонента с субкомпонентами, являющимися заглушками. Заглушки имеют тот же интерфейс, что и компонент, но с ограниченной функциональностью. После того, как компонент верхнего уровня запрограммирован и протестирован, таким же образом реализуются и тестируются его субкомпоненты. Процесс продолжается до тех пор, пока не будут реализованы компоненты самого нижнего уровня. Затем вся система тестируется целиком.
При ВТ, наоборот, сначала интегрируются и тестируются модули, расположенные на более низких уровнях иерархии. Затем выполняется сборка и тестирование модулей, расположенных выше, и так далее до тех пор, пока не будет протестирован последний модуль. При таком подходе не требуется наличие законченного архитектурного проекта системы, и поэтому он может начинаться на раннем этапе процесса разработки.
Тестирование интерфейсов. Тестирование интерфейсов (ТИ) выполняется в тех случаях, когда модули или подсистемы интегрируются в большие системы. Каждый модуль или подсистема имеет заданный интерфейс, который вызывается другими компонентами системы. Цель ТИ – выявить дефекты, возникающие в системе вследствие ошибок в интерфейсах или вследствие неправильных предположений об интерфейсах.
Данный тип тестирования особенно важен в объектно-ориентированном программировании. Объекты в значительной степени определяются с помощью интерфейсов и могут повторно использоваться в различных комбинациях с разными объектами в разных системах. Во время тестирования отдельных объектов невозможно выявить ошибки интерфейса, так как они являются скорее результатом взаимодействия между объектами, чем изолированного поведения одного объекта.
Между компонентами программы могут быть разные типы интерфейсов и, соответственно, разные типы ошибок интерфейса.
Рис. 3.1. Тестирование интерфейсов
ТИ – сложный процесс, поскольку некоторые ошибки могут проявляться только в необычных условиях. Другая проблема может возникнуть из-за взаимодействий между ошибками в разных программных модулях или объектах. Ошибки в одном объекте можно выявить только тогда, когда поведение другого объекта становится непредсказуемым.
Обычно статические методы тестирования более рентабельны, чем специальное ТИ. В языках со строгим контролем типов ошибки интерфейса помогает обнаруживать компилятор, а в языках со слабым контролем ошибки может выявлять статический анализатор. Кроме того, при инспектировании программ можно сосредоточиться именно на проверке интерфейсов компонентов.
Тестирование с нагрузкой. После полной интеграции системы можно оценить такие интеграционные свойства системы, как производительность и надежность. Чтобы убедиться, что система может работать с заданной нагрузкой, разрабатываются тесты для измерения производительности. Обычно проводят серии тестов с постепенным увеличением нагрузки, пока производительность системы не начнет снижаться.
Тестирование – дорогой и трудоемкий этап разработки программных систем. Поэтому создан широкий спектр инструментальных средств для поддержки процесса тестирования, которые значительно сокращают расходы на него. На рис. 3.2 показаны возможные инструментальные средства тестирования и отношения между ними.
Рис. 3.2. Инструментальные средства тестирования
На этом рисунке:
Организатор тестов управляет выполнением тестов, генератор тестовых данных генерирует тестовые данные для тестируемой программы (выбирает тестовые данные из базы данных или использует шаблоны для генерации случайных данных), оракул генерирует ожидаемые результаты тестов, компаратор файлов сравнивает результаты текущего тестирования с результатами предыдущего тестирования и составляет отчет об обнаруженных различиях, генератор отчетов формирует отчеты по тестам, динамический анализатор добавляет в программу код подсчета количества выполнения каждого оператора, имитатор моделирует выполнение программы.
Верификация и аттестация критических систем имеет много общего с подобными процессами, выполняемыми над любой другой программной системой. Однако природа критических систем (КС) такова, что в дополнение к обычному анализу и тестированию системы необходимы еще процессы доказательства ее надежности. Это требуется по двум причинам. Первая причина – цена отказа КС. В КС стоимость отказа значительно выше, чем в каких-либо других. Поэтому экономически выгоднее вложить большее количество средств в верификацию и аттестацию, чем терпеть убытки от сбоев. Вторая причина – аттестация свойств функциональной надежности. Заказчики КС должны быть уверены в том, что система соответствует определенным показателям функциональной надежности. По этим причинам стоимость верификации и аттестации КС значительно выше, чем для других систем.
Чтобы быть уверенным, что система соответствует требованиям, необходимо измерить ее показатели безотказности, учитывая работу типичного пользователя. Процесс измерения показателей безотказности состоит из четырех этапов: сначала изучаются аналогичные существующие системы (определяется операционный профиль), затем идет подготовка тестовых данных, дальнейший этап – собственно тестирование, последним шагом выполняется вычисление показателей безотказности. Данный метод иногда называют статическим тестированием, цель которого – оценить безотказность системы. Статическое тестирование противоположно тестированию дефектов, проводимому в целях обнаружения ошибок в системе. Однако этот метод не так прост для применения на практике. Трудности возникают по нескольким причинам:
- неопределенность операционного профиля (профили могут неточно отражать реальное использование системы)
- высокая стоимость генерации тестовых данных (если нет возможности автоматической генерации тестовых данных, то создание большого количества тестовых данных требует больших затрат времени и, соответственно, средств)
- статистическая неопределенность в случае высокой безотказности (для точного измерения показателей безотказности необходимо сгенерировать статистически значимое число отказов).
Операционный профиль (ОП) отражает практику использования системы. Он состоит из спецификации классов входных данных и вероятности их появления. Если система ПО инновационная, предвидеть, как она будет использоваться, сложно. Система используется различными группами пользователей с разными ожиданиями, знаниями и опытом. У новых систем нет предыстории использования, и для работы с ними пользователи часто применяют способы, не предусмотренные разработчиками. Еще одна проблема состоит в том, что ОП может меняться в ходе использования системы. Все эти причины часто не позволяют разработать надежный ОП. В подобных ситуациях сложно оценить степень неопределенности в измерении показателей безотказности систем.
Во время аттестации ПО менеджеры должны уделить основное внимание тестированию системы. Так как тестирование – очень дорогой процесс, важно завершить его как можно раньше, причем так, чтобы впоследствии не пришлось тестировать систему повторно. Тестирование завершается, если достигнут необходимый уровень безотказности. Но иногда выясняется, что требующийся уровень безотказности никогда не будет достигнут. В этом случае менеджер должен принять нелегкое решение о переработке некоторых частей системы или о перезаключении договора с заказчиком.
Получение гарантий безопасности системы и аттестация ее безотказности – разные процессы. Безотказность можно определить количественно с помощью различных числовых показателей. Безопасность нельзя достоверно определить количественными способами, следовательно, ее невозможно измерить в ходе тестирования системы.
Поэтому аттестация безопасности определяет уровень надежности системы, который может варьироваться от «очень низкого» до «очень высокого». Здесь требуется профессиональная оценка безопасности. Во многих случаях определение безопасности базируется на опыте организации, разрабатывающей систему. Если в организации уже есть предварительно разработанные надежно функционирующие безопасные системы, то разумно предположить, что в данной организации будут разработаны подобные безопасные системы. С другой стороны, оценка безопасности должна опираться на реальную архитектуру системы, результаты верификации и аттестации, а также на процессы, которые применялись при разработке системы.
Верификация и аттестация систем, критических по обеспечению безопасности, имеет много общего с тестированием любых систем с высокими требованиями надежности. Чтобы обнаружить наибольшее количество ошибок, следует применять всестороннее тестирование, а при оценке безопасности использовать статические методы тестирования. Однако вследствие чрезвычайно низкой частоты отказов, присущих многим КС, с помощью статического тестирования не всегда удается количественно оценить безотказность, так как для этого требуется очень большое число тестов. Эти тесты лишь дают основание считать ту или иную КС безопасной.
При создании КС, важен всесторонний анализ разрабатываемой системы. Имеется пять типов анализа системы, обязательных для КС:
1. Анализ правильности функционирования системы
2. Анализ возможности изменения и понятности системной архитектуры
3. Анализ соответствия алгоритма обработки и структуры данных определенному в спецификации поведению системы
4. Анализ согласованности программного кода, алгоритмов и структур данных.
5. Анализ адекватности тестовых сценариев системным требованиям.
Все доказательства безопасности системы строятся на следующем предположении: количество ошибок в системе, которые приводят к аварийным ситуациям, намного меньше общего числа ошибок в системе. Обеспечение безопасности должно сосредоточиться на выявлении потенциально опасных ошибок. Если оказывается, что эти ошибки не проявляются или проявляются, но не приводят к серьезным последствиям, то система считается надежной. Доказательства правильности программ были предложены в качестве методов верификации ПО более 25 лет назад. Однако эти методы в основном используются только в лабораториях. Практические проблемы построения доказательства правильности ПО настолько сложны, что некоторые организации считают использование данных методов в процессе разработки обычных систем неоправданно дорогим. Но, как отмечалось ранее, для ряда КС экономически выгодно использовать доказательства правильности системы, чем ликвидировать последствия отказов.
Несмотря на то, что для большинства систем разрабатывать доказательства правильности нерентабельно, иногда возникает необходимость разработать доказательства безопасности, демонстрирующие соответствие данной программы требованиям по обеспечению безопасности. При доказательстве безопасности необязательно доказывать соответствие программы спецификации. Необходимо только показать, что выполнение программы не приводит к сбоям с опасными последствиями.
В этой работе были рассмотрены вопросы верификации и аттестации ПО. Было доказано, что это очень сложные шаги в разработке любого продукта, требующие от инженеров внимания, высочайшей квалификации, терпения, а от организации – больших вложений средств. Однако какими бы дорогостоящими не были эти процессы, экономическая выгода от их использования очевидна, ведь система без сбоев не наносит убытков. Следует помнить, что аварийные ситуации – редкие события (особенно в КС), поэтому практически невозможно смоделировать их во время тестирования системы. Было установлено, что требования безопасности никогда не исключают ненадежного поведения системы. Посредством тестирования и других процессов аттестации невозможно полностью доказать соответствие системы требованиям безопасности.
В настоящее время приобретает большое значение оценка защищенности систем, поскольку все чаще системы объединяются посредством сети Интернет. Требования защищенности в некоторых отношениях подобны требованиям безопасности. В частности, они определяют нештатное поведение системы, а не ее «рабочее» поведение. Однако, как правило, невозможно определить это поведение в виде простых ограничений, контролируемых системой.
Конечным пользователям очень сложно проверить защищенность системы. Поэтому в Европе выработаны системы критериев оценки защищенности, которые контролируются специально обученными экспертами. Поставщики готового ПО могут предоставить на рассмотрение свои конечные продукты для оценки и сертификации по различным критериям защищенности.
Верификация и аттестация должны стать обязательными шагами в разработке ПО, пусть даже самого простого. Каждая компания, производящая ПО, должна создать штат сотрудников, которые будут заниматься только верификацией и аттестацией: это инженеры-тестеры, инженеры-испекторы и др. Организации должны учитывать экономическую обстановку на рынке ПО, желания пользователей (уже было отмечено, что требовательность пользователей к ПО растет).
Если соблюдать все эти требования, то, скорее всего, наступит день, когда нас будут окружать системы, работающие без сбоев.
1. Соммервилл И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. – М.: Издат. Дом. «Вильямс», 2002. – 624 с.: ил.
2. А.Г. Гейн, В.Г. Житомирский. Основы информатики и вычислительной техники: проб. Учеб. Для 10-11 кл. сред. шк. – 3-е изд. – М.: Просвещение, 1993. – 254 с.: ил.
3. Ю. Г. Карпов. Теория автоматов. – Спб.: Питер, 2002 – 224 с.: ил.
4. Электронный Архив для инженеров программного обеспечения. http://www.cs.queensu.ca/Software-Engineering/
5. Software Engineering Questions and Answers. http://www.cs.queensu.ca/Software-Engineering/questions.html
6. Ресурсы сервера Института Инженерии Программного Обеспечения Карнеги Меллона (Carnegie Mellon Software Engineering Institute). http://www.sei.cmu.edu/
7. SybaseDevel.Ru – русский портал для разработчиков. http://www.sybasedevel.ru
Страницы: 1, 2, 3, 4
