В программировании проверка исходного кода программы с целью обнаружения ошибок
Аннотация: Лекция посвящена процессу тестирования программного кода. Определяются его задачи и цели, перечисляются основные методы и подходы к тестированию программного кода. Вводится понятие тестового окружения, рассматриваются его компоненты и различные виды окружения. Цель данной лекции: дать представление о процессе тестирования программного кода, его видах. Определить методы построения тестового окружения, необходимого для выполнения тестирования
3.1. Задачи и цели тестирования программного кода
Тестирование программного кода - процесс выполнения программного кода, направленный на выявление существующих в нем дефектов. Под дефектом здесь понимается участок программного кода, выполнение которого при определенных условиях приводит к неожиданному поведению системы (т.е. поведению, не соответствующему требованиям). Неожиданное поведение системы может приводить к сбоям в ее работе и отказам, в этом случае говорят о существенных дефектах программного кода. Некоторые дефекты вызывают незначительные проблемы, не нарушающие процесс функционирования системы, но несколько затрудняющие работу с ней. В этом случае говорят о средних или малозначительных дефектах.
Задача тестирования при таком подходе - определение условий, при которых проявляются дефекты системы, и протоколирование этих условий. В задачи тестирования обычно не входит выявление конкретных дефектных участков программного кода и никогда не входит исправление дефектов - это задача отладки, которая выполняется по результатам тестирования системы.
Цель применения процедуры тестирования программного кода - минимизация количества дефектов (в особенности существенных) в конечном продукте. Тестирование само по себе не может гарантировать полного отсутствия дефектов в программном коде системы. Однако, в сочетании с процессами верификации и валидации, направленными на устранение противоречивости и неполноты проектной документации (в частности - требований на систему), грамотно организованное тестирование дает гарантию того, что система удовлетворяет требованиям и ведет себя в соответствии с ними во всех предусмотренных ситуациях.
При разработке систем повышенной надежности, например, авиационных, гарантии надежности достигаются с помощью четкой организации процесса тестирования, определения его связи с остальными процессами жизненного цикла , введения количественных характеристик, позволяющих оценивать успешность тестирования. При этом чем выше требования к надежности системы (ее уровень критичности), тем более жесткие требования предъявляются.
Таким образом, в первую очередь мы рассматриваем не конкретные результаты тестирования конкретной системы, а общую организацию процесса тестирования, используя подход "хорошо организованный процесс дает качественный результат". Такой подход является общим для многих международных и отраслевых стандартов качества, о которых более подробно будет рассказано в конце данного курса. Качество разрабатываемой системы при таком подходе является следствием организованного процесса разработки и тестирования, а не самостоятельным неуправляемым результатом.
Поскольку современные программные системы имеют весьма значительные размеры, при тестировании их программного кода используется метод функциональной декомпозиции. Система разбивается на отдельные модули (классы, пространства имен и т.п.), имеющие определенную требованиями функциональность и интерфейсы. После этого по отдельности тестируется каждый модуль - выполняется модульное тестирование . Затем происходит сборка отдельных модулей в более крупные конфигурации - выполняется интеграционное тестирование , и наконец, тестируется система в целом - выполняется системное тестирование .
С точки зрения программного кода, модульное, интеграционное и системное тестирование имеют много общего, поэтому пока основное внимание будет уделено модульному тестированию, особенности интеграционного и системного тестирования будут рассмотрены позднее.
В ходе модульного тестирования каждый модуль тестируется как на соответствие требованиям, так и на отсутствие проблемных участков программного кода, которые могут вызвать отказы и сбои в работе системы. Как правило, модули не работают вне системы - они принимают данные от других модулей, перерабатывают их и передают дальше. Для того, чтобы с одной стороны, изолировать модуль от системы и исключить влияние потенциальных ошибок системы, а с другой стороны - обеспечить модуль всеми необходимыми данными, используется тестовое окружение.
Задача тестового окружения - создать среду выполнения для модуля, эмулировать все внешние интерфейсы, к которым обращается модуль . Об особенностях организации тестового окружения пойдет речь далее в данной лекции.
Типичная процедура тестирования состоит в подготовке и выполнении тестовых примеров (также называемых просто тестами). Каждый тестовый пример проверяет одну "ситуацию" в поведении модуля и состоит из списка значений, передаваемых на вход модуля, описания запуска и выполнения переработки данных - тестового сценария и списка значений, которые ожидаются на выходе модуля в случае его корректного поведения. Тестовые сценарии составляются таким образом, чтобы исключить обращения к внутренним данным модуля, все взаимодействие должно происходить только через его внешние интерфейсы.
Выполнение тестового примера поддерживается тестовым окружением, которое включает в себя программную реализацию тестового сценария. Выполнение начинается с передачи модулю входных данных и запуска сценария. Реальные выходные данные , полученные от модуля в результате выполнения сценария, сохраняются и сравниваются с ожидаемыми. В случае их совпадения тест считается пройденным, в противном случае - не пройденным. Каждый не пройденный тест указывает на дефект либо в тестируемом модуле, либо в тестовом окружении, либо в описании теста.
Совокупность описаний тестовых примеров составляет тест-план - основной документ, определяющий процедуру тестирования программного модуля. Тест-план задает не только сами тестовые примеры, но и порядок их следования, который также может быть важен. Структура и особенности тест-планов, а также проблемы, связанные с порядком следования тестовых примеров, будут рассмотрены в следующих лекциях.
При тестировании часто бывает необходимо учитывать не только требования к системе, но и структуру программного кода тестируемого модуля. В этом случае тесты составляются таким образом, чтобы детектировать типичные ошибки программистов, вызванные неверной интерпретацией требований. Применяются проверки граничных условий, проверки классов эквивалентности. Отсутствие в системе возможностей, не заданных требованиями, гарантировано различными оценками покрытия программного кода тестами, т.е. оценками того, какой процент тех или иных языковых конструкций выполнен в результате выполнения всех тестовых примеров. Обо всем этом пойдет речь в завершение рассмотрения процесса тестирования программного кода.
3.2. Методы тестирования
3.2.1. Черный ящик
Основная идея в тестировании системы как черного ящика состоит в том, что все материалы, которые доступны тестировщику, - требования на систему, описывающие ее поведение, и сама система, работать с которой он может, только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, - таким образом, система представляет собой "черный ящик", правильность поведения которого по отношению к требованиям и предстоит проверить.
С точки зрения программного кода черный ящик может представлять с собой набор классов (или модулей) с известными внешними интерфейсами, но недоступными исходными текстами.
Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке соответствия поведения системы требованиям. Кроме того, тестировщик должен проверить работу системы в критических ситуациях - что происходит в случае подачи неверных входных значений. В идеальной ситуации все варианты критических ситуаций должны быть описаны в требованиях на систему и тестировщику остается только придумывать конкретные проверки этих требований. Однако в реальности в результате тестирования обычно выявляется два типа проблем системы.
- Несоответствие поведения системы требованиям
- Неадекватное поведение системы в ситуациях, не предусмотренных требованиями.
Отчеты об обоих типах проблем документируются и передаются разработчикам. При этом проблемы первого типа обычно вызывают изменение программного кода, гораздо реже - изменение требований. Изменение требований в данном случае может потребоваться из-за их противоречивости (несколько разных требований описывают разные модели поведения системы в одной и той же самой ситуации) или некорректности (требования не соответствуют действительности).
Проблемы второго типа однозначно требуют изменения требований ввиду их неполноты - в требованиях явно пропущена ситуация, приводящая к неадекватному поведению системы. При этом под неадекватным поведением может пониматься как полный крах системы, так и вообще любое поведение, не описанное в требованиях.
Тестирование черного ящика называют также тестированием по требованиям, т.к. это единственный источник информации для построения тест-плана.
3.2.2. Стеклянный (белый) ящик
При тестировании системы как стеклянного ящика тестировщик имеет доступ не только к требованиям к системе, ее входам и выходам, но и к ее внутренней структуре - видит ее программный код.
Доступность программного кода расширяет возможности тестировщика тем, что он может видеть соответствие требований участкам программного кода и определять тем самым, на весь ли программный код существуют требования. Программный код, для которого отсутствуют требования, называют кодом, не покрытым требованиями. Такой код является потенциальным источником неадекватного поведения системы. Кроме того, прозрачность системы позволяет углубить анализ ее участков, вызывающих проблемы - часто одна проблема нейтрализует другую, и они никогда не возникают одновременно.
3.2.3. Тестирование моделей
Тестирование моделей находится несколько в стороне от классических методов верификации программного обеспечения. Причина прежде всего в том, что объект тестирования - не сама система, а ее модель, спроектированная формальными средствами. Если оставить в стороне вопросы проверки корректности и применимости самой модели (считается, что ее корректность и соответствие исходной системе могут быть доказаны формальными средствами), то тестировщик получает в свое распоряжение достаточно мощный инструмент анализа общей целостности системы. На модели можно создать такие ситуации, которые невозможно создать в тестовой лаборатории для реальной системы. Работая с моделью программного кода системы, можно анализировать его свойства и такие параметры системы, как оптимальность алгоритмов или ее устойчивость.
Однако тестирование моделей не получило широкого распространения именно из-за трудностей, возникающих при разработке формального описания поведения системы. Одно из немногих исключений - системы связи, алгоритмический и математический аппарат которых достаточно хорошо проработан.
3.2.4. Анализ программного кода (инспекции)
Во многих ситуациях тестирование поведения системы в целом невозможно - отдельные участки программного кода могут никогда не выполняться, при этом они будут покрыты требованиями. Примером таких участков кода могут служить обработчики исключительных ситуаций. Если, например, два модуля передают друг другу числовые значения и функции проверки корректности значений работают в обоих модулях, то функция проверки модуля-приемника никогда не будет активизирована, т.к. все ошибочные значения будут отсечены еще в передатчике.
В этом случае выполняется ручной анализ программного кода на корректность, называемый также просмотрами или инспекциями кода. Если в результате инспекции выявляются проблемные участки, то информация об этом передается разработчикам для исправления наравне с результатами обычных тестов.
3.3. Тестовое окружение
Основной объем тестирования практически любой сложной системы обычно выполняется в автоматическом режиме. Кроме того, тестируемая система обычно разбивается на отдельные модули, каждый из которых тестируется вначале отдельно от других, затем в комплексе.
Это означает, что для выполнения тестирования необходимо создать некоторую среду, которая обеспечит запуск и выполнение тестируемого модуля, передаст ему входные данные , соберет реальные выходные данные , полученные в результате работы системы на заданных входных данных. После этого среда должна сравнить реальные выходные данные с ожидаемыми и на основании данного сравнения сделать вывод о соответствии поведения модуля заданному (Рис 3.1).
Тестовое окружение также может использоваться для отчуждения отдельных модулей системы от всей системы. Разделение модулей системы на ранних этапах тестирования позволяет более точно локализовать проблемы, возникающие в их программном коде. Для поддержки работы модуля в отрыве от системы тестовое окружение должно моделировать поведение всех модулей, к функциям или данным которых обращается тестируемый модуль .
Поскольку тестовое окружение само является программой (причем зачастую реализованной не на том языке программирования, на котором написана система), оно само должно быть протестировано. Целью тестирования тестового окружения является доказательство того, что тестовое окружение никаким образом не искажает выполнение тестируемого модуля и адекватно моделирует поведение системы.
Обращаем Ваше внимание, что в соответствии с Федеральным законом N 273-ФЗ «Об образовании в Российской Федерации» в организациях, осуществляющих образовательную деятельность, организовывается обучение и воспитание обучающихся с ОВЗ как совместно с другими обучающимися, так и в отдельных классах или группах.
Рабочие листы и материалы для учителей и воспитателей
Более 2 500 дидактических материалов для школьного и домашнего обучения
Столичный центр образовательных технологий г. Москва
Получите квалификацию учитель математики за 2 месяца
от 3 170 руб. 1900 руб.
Количество часов 300 ч. / 600 ч.
Успеть записаться со скидкой
Форма обучения дистанционная
- Онлайн
формат - Диплом
гособразца - Помощь в трудоустройстве
311 лекций для учителей,
воспитателей и психологов
Получите свидетельство
о просмотре прямо сейчас!
Вопросы По Горизонтали:
1.Самые популярные антивирусные программы.
4.Набор микросхем, центральный элемент компьютерной платы.
7.Характеристика изображения, либо устройства для его отображения, характеризуется числом точек на единицу изображения.
9.Устройство для перевода изображения с бумажного носителя в цифровой, компьютерный формат.
10.Соединение с удалённым компьютером.
12.Единая информационная структура, состоящая из связанных между собой гипертекстовых документов – страничек – (в сети Internet).
13.Процесс обновления программных продуктов, либо с целью обнаружения ошибок.
15.Место для подключения к компьютеру каких-либо устройств, либо канал доступа из вне.
16.Устройство для вывода сложных и широкоформатных графических объектов.
17.Популярный способ ускорения работы компьютера либо его отдельных плат.
20.Процесс сжатия информации с целью уменьшения её объёма и удобства хранения и транспортировки.
21.Вентилятор, предназначенный для охлаждения процессора или видеокарты.
23.Средства управления и запуска программ в виде движущейся по экрану стрелки, копирующей движения вашей руки при работе с мышью.
27.Аппаратный или программный буфер, накопитель, позволяющий ускорить доступ к наиболее часто используемым данным.
28.Минимальный адресуемый элемент на жестком диске, содержавший в себе несколько секторов.
Вопросы По Вертикали:
2.Процесс упорядочивания структуры текста либо носителя информации.
3.Небольшая вспомогательная программа предназначенная для обслуживания и улучшения работы компьютера, реже для выполнения простейших операций с документами.
5.Значок-картинка на рабочем столе Windows.
6.Частота обновления картинки на экране, смена кадров изображения.
8.Процесс установки программных продуктов, « подключающий » их к операционной системе.
10.Операция преобразования символов одной знаковой системы в знаки другой.
14.В программирование- проверка исходного кода программы с целью обнаружения ошибок.
17.Элемент имени файла, состоящий из трёх (реже четырёх) букв, обозначающий его тип.
18.Специалист по « взлому » зашиты программных продуктов, с целью незаконного доступа к хранящейся в ней информации.
19.Контактная металлическая полоска на разъёме платы для подключения платы.
24.Косая черта, разделяющая различные части сети Internet или дискового адреса файла.
26.Единица скорости передачи данных, обозначающий количество бит переданных в секунду.
Ответы На Кроссворд:
По горизонтали: 1.Полифаг. 4.Чипсет. 7.Разрешение. 9.Сканер. 10.Коннект. 12.Сайт. 13.Апдейт. 15.Порт. 16.Плоттер. 17.Разгон. 20.Архивация. 21.Кулер. 22.Чип. 23.Курсор. 25.Нотбук. 27.Кэш. 28.Кластер.
По вертикали: 2.Форматирование. 3.Утилита. 5.Иконка. 6.Рефреш. 8.Инсталяция. 10.Кодирование. 11.Юзер. 14.Отладка. 17.Расширение. 18.Хакер. 19.Пин. 24.Слэш. 26.Бод.
Обращаем Ваше внимание, что в соответствии с Федеральным законом N 273-ФЗ «Об образовании в Российской Федерации» в организациях, осуществляющих образовательную деятельность, организовывается обучение и воспитание обучающихся с ОВЗ как совместно с другими обучающимися, так и в отдельных классах или группах.
Рабочие листы и материалы для учителей и воспитателей
Более 2 500 дидактических материалов для школьного и домашнего обучения
Столичный центр образовательных технологий г. Москва
Получите квалификацию учитель математики за 2 месяца
от 3 170 руб. 1900 руб.
Количество часов 300 ч. / 600 ч.
Успеть записаться со скидкой
Форма обучения дистанционная
- Онлайн
формат - Диплом
гособразца - Помощь в трудоустройстве
Видеолекции для
профессионалов
- Свидетельства для портфолио
- Вечный доступ за 120 рублей
- 311 видеолекции для каждого
КРОССВОРД № 1
Вопросы по горизонтали:
3. Стартовый сайт, предлагающий пользователю доступ к информационным ресурсам в форме каталогов, новостей и обзоров.
6. Устройство для вывода информации на печать.
8. Важнейшая характеристика машинной памяти.
10. Комплекс операций, производимых над информацией в ЭВМ.
12. Одна из операций ЭВМ.
14. Определенное количество информации, имеющее имя и хранящееся в долговременной памяти.
16. Операция преобразования знаков или групп знаков одной знаковой системы в знаки или группы знаков другой знаковой системы.
17. Последовательность команд, которые выполняет компьютер в процессе обработки данных.
18. В программе представлена именем и служит для обращения к данным определенного типа.
20. Упорядочение записей базы данных по значениям одного из полей.
22. Величина, не изменяющаяся в ходе работы программы.
Вопросы по вертикали:
1. Обеспечивает модуляцию и демодуляцию сигнала при его передаче по телефонным линиям.
2. Двумерный массив точек, упорядоченных в строки и столбцы, который используется создания изображения на экране монитора.
4. Знак алфавита языка программирования.
5. Устройство вывода дисплея.
7. Преобразование непрерывных изображений и звука в набор дискретных значений в форме кодов.
9. Приспособление для крепления и соединения электронных элементов.
11. Является минимальным адресуемым элементом на жестком диске, который содержит несколько секторов.
13. Минимальный участок изображения, цвет которого можно задать независимым образом.
15. Алгоритмический язык высокого уровня.
18. Процесс нахождения в файле необходимой информации.
19. Объект, представляющий собой окно на экране, в котором размещаются управляющие элементы.
21. Название информации, представленной в компьютерной форме и обрабатываемой на компьютере.
23. Разъем на материнской плате компьютера, в который устанавливаются платы контрольных устройств (например, видеоадаптер) и дополнительных устройств.
Ответы на кроссворд:
По горизонтали: 3.Портал. 6.Принтер. 8.Емкость. 10.Обработка. 12.Сцепление. 14.Файл. 16.Кодирование. 17.Программа. 18.Переменная. 20.Сортировка. 22.Константа.
По вертикали: 1.Модем. 2.Растр. 4.Цифра. 5.Экран. 7.Дискретизация. 9.Плата. 11.Кластер. 13.Пиксель. 15.Паскаль. 18.Поиск. 19.Форма. 21.Данное.23.Слот.
КРОССВОРД № 2
Вопросы по горизонтали:
3. Команда, позволяющая повернуть рисунок зеркально.
5. Инструмент для заполнения части рисунка одним цветом.
6. Инструмент, позволяющий взять требуемый цвет прямо с рисунка.
8. Инструмент для создания замкнутых ломаных линий.
9. Признак или свойство характеризующее предмет, в данном случае размеры рисунка.
10. Начертание шрифта на рисунке.
11. Чертежный инструмент, позволяющий соединить две точки прямой линией.
13. Инструмент, создающий эффект разбрызгивания краски.
15. Специальное устройство ввода для рисования на экране.
16. Инструмент для выделения прямоугольных или произвольных фрагментов рисунка.
Вопросы по вертикали:
1.Программа для обработки какой-либо информации.
2.То, что можно изменять при помощи палитры.
4.Инструмент для удаления фрагмента рисунка.
8.Инструмент для увеличения фрагмента рисунка.
12.Название инструмента для работы с частью рисунка.
14.Команда, опрокидывания рисунка на 90.
Ответы на кроссворд:
3.Отражение. 5.Заливка. 6.Пипетка. 8.Многоугольник. 9.Атрибут. 10.Курсив. 11.Линейка. 13.Распылитель. 15.Планшет. 16.Ножницы.
1.Редактор. 2.Цвет. 4.Ластик. 7.Палитра. 8.Масштаб. 12.Выделение. 14.Поворот.
КРОССВОРД № 3
Вопросы по горизонтали:
1. Заранее заданная последовательность четко определенных команд для получения решения задачи.
3. Совокупность команд, задающих последовательность действий процессора с целью получения требующегося результата.
5. Законченное смысловое выражение на языке высокого уровня.
6. Язык, разработанный для реализации операций системы UNIX в начале 70-х годов.
7. Язык, созданный в 1959 году. Цель его создания состояла в организации удобства обработки символьной информации.
10. Память для промежуточного хранения данных, используется для компенсации данных.
12. Программа, предназначенная для перевода операторов языка высокого уровня в машинные команды, выполняемые процессором.
Вопросы по вертикали:
1. Язык, предназначенный для представления в удобной символической форме программы на машинном языке.
2. Программа, преобразующая программу на исходном языке в объектную (в машинных кодах).
3. Часть программы, которая выполняет некоторую четкую определенную операцию над данными, определяемыми параметрами.
4. Относительно независимая часть программы.
8. Язык, который был создан французским ученым А.Кальмеероэ в 1973 году.
9. Язык, разработанный в 1964 году, представляет собой язык программирования.
11. Язык программирования, который появился в начале 1995 года и быстро завоевал титул первой системы визуальной разработки приложений для Windows.
Ответы на кроссворд:
1.Алгоритм. 3.Программа; 5.Оператор.6.Си. 7.Лисп. 10.Буфер. 12.Компилятор.
По вертикали: 1.Ассемблер. 2.Транслятор. 3.Процедура. 4.Модуль. 8.Пролог. 9.Бейсик; 11.Делфи.
КРОССВОРД для 9-10 классов
Вопросы по горизонтали:
2. Префикс, означающий использование компьютера в сети Интернет.
4. Система обмера информацией на определённую тему между абонентами сети.
6. Величина, количество символов (колебаний), посылаемых модемом по телефонной линии за одну секунду.
10. Указатель, ссылка, место, где хранится информация.
11. Небольшая программа, написанная на языке программирования Java.
13. Цифровая камера, присоединяющаяся к компьютеру и передающая вид через Интернет.
14. Возврат не дошедшей до адреса почты.
16. Гипертекстовая связь, позволяющая перейти в другую часть Интернета.
19. Устройство для передачи информации данных по телефонной линии.
Вопросы по вертикали:
1. Система записи и отображения текста. Позволяет связывать тексты разными способами.
3. Указатель ссылки, находящейся на web-странице.
4. Объект, как правило, изображение и, как правило, с гиперссылкой, помещаемый на странице с рекламной информацией.
5. Звуковые, графические и видео файлы, имеющие большой объем информации (предполагают использование различных видов текста).
7. Глобальная компьютерная сеть, объединяющая локальные, региональные и корпоративные.
9. Web-страница для общения в Интернете.
20. Стартовый сайт, предлагающий пользователю доступ к тематически подобранным информационным ресурсам в форме каталогов, новостей, обзоров, а также к информационным сервисам.
12. Программист, занимающийся взломом программного обеспечения и различных компьютерных систем.
15. Совокупность взаимосвязанных страниц, содержание которых передается на компьютер пользователя автоматически на основе push-технологии.
18. Компьютер, обслуживающий подключенные к нему компьютеры, ориентированный на связь и передачу информации клиентурной станции.
Ответы на кроссворд:
По горизонтали: 2.Кибер. 4.Телеконференция. 6.Бод. 10.Адрес. 11.Аплет. 13.Вебкамера. 14.Рикошет. 16.Ссылка. 19.Модем.
По вертикали: 1.Гипертекст. 2.Гиперссылка. 4.Баннер. 5.Мультимедиа. 7.Интернет. 8. Чат. 9.Браузер. 20.Портал. 12.Хакер. 15.Канал. 17.Спам.18.Сервер.
Системы и средства анализа исходного кода для выявления проблем безопасности
Выбор средств защиты
Поиск
Мнение
Описание и назначение
Сканеры исходного кода выявляют ошибки в исходном коде, допущенные при разработке программ, которые могут использоваться злоумышленниками в качестве уязвимостей и взлома информационной системы.
Анализ исходного кода необходим, чтобы выявить возможные уязвимости в программном обеспечении, проверить код приложения на наличие бэкдоров и программных закладок, которые могут в дальнейшем использоваться злоумышленниками для получения несанкционированного доступа в систему. Еще одной причиной анализа исходного кода является необходимость его проверки на наличие ошибок, которые могут привести к сбоям в работе, потере критичных данных или нарушению существующих в организации бизнес-процессов.
Существуют несколько типов сканеров исходного кода, которые делятся в зависимости от того, какие приложения и программы необходимо подвергать анализу:
- Веб-приложения и веб-сервисы. В данном случае анализаторы кода необходимо использовать для снижения рисков эксплуатации уязвимостей на сайтах.
- Встраиваемые модули приложений. Анализаторы кода этого типа предназначены для проверки исходного кода компонентов, встраиваемых в основное программное обеспечение. Это актуально в случае, когда организация заказывает разработку дополнительной функциональности уже используемого приложения, например CRM-систем или SAP.
- Приложений, которые не связаны с бизнес-приложениями и сайтами. Здесь подразумеваются отдельные программные продукты. Такой тип анализаторов подходит для защищенной разработки программ.
Несмотря на подобное разделение, большинство анализаторов относится к смешанному типу, которые могут применяться в различных сферах и предоставляют широкий спектр возможностей.
Сканеры исходного кода кода могут применять два основных механизма, которые могут предоставляться совместно:
- Статический анализ, или SAST (Static Application Security Testing), когда анализ выполняется без запуска программного обеспечения.
- Динамический анализ, или DAST (Dynamic Application Security Testing), когда анализ кода выполняется в процессе его выполнения.
На вход анализатора кода поступает массив данных (исходный код и все зависимые модули), а после проверки средства анализа кода предоставляют подробный отчет о найденных ошибках и уязвимостях. Некоторые анализаторы кода способны самостоятельно исправлять ошибки, но стоит учитывать, что данная функция может работать не совсем корректно. В связи с этим опытным разработчикам необходимо контролировать данный процесс.
Принцип работы любых анализаторов кода связан с базами данных, которые они используют в процессе анализа. Это может быть база уязвимостей, поставляемая разработчиками средств для анализа кода. У них также могут быть собственные базы ошибок, допускаемых при программировании. В различных странах существуют государственные базы данных, которые используют анализаторы кода. Они могут применяться как встроенные средства анализа либо в качестве отдельных механизмов. Наравне с указанными базами существует и третий тип, подразумевающий проверку требований стандартов, рекомендаций и лучших практик.
Цель функционального тестирования - обнаружение несоответствий между реальным поведением реализованных функций и ожидаемым поведением в соответствии со спецификацией и исходными требованиями. Функциональные тесты должны охватывать все реализованные функции с учетом наиболее вероятных типов ошибок. Тестовые сценарии, объединяющие отдельные тесты, ориентированы на проверку качества решения функциональных задач.
Функциональные тесты создаются по внешним спецификациям функций, проектной информации и по тексту на ЯП, относятся к функциональным его характеристикам и применяются на этапе комплексного тестирования и испытаний для определения полноты реализации функциональных задач и их соответствия исходным требованиям.
В задачи функционального тестирования входят:
- идентификация множества функциональных требований;
- идентификация внешних функций и построение последовательностей функций в соответствии с их использованием в ПС;- идентификация множества входных данных каждой функции и определение областей их изменения;
- построение тестовых наборов и сценариев тестирования функций;
- выявление и представление всех функциональных требований с помощью тестовых наборов и проведение тестирования ошибок в программе и при взаимодействии со средой.
Тесты, создаваемые по проектной информации, связаны со структурами данных, алгоритмами, интерфейсами между отдельными компонентами и применяются для тестирования компонентов и их интерфейсов. Основная цель - обеспечение полноты и согласованности реализованных функций и интерфейсов между ними.
Комбинированный метод "черного ящика" и "прозрачного ящика" основан на разбиении входной области функции на подобласти обнаружения ошибок. Подобласть содержит однородные элементы, которые все обрабатываются корректно либо некорректно. Для тестирования подобласти производится выполнение программы на одном из элементов этой области.
Предпосылки функционального тестирования :
- корректное оформление требований и ограничений к качеству ПО;
- корректное описание модели функционирования ПО в среде эксплуатации у заказчика;
- адекватность модели ПО заданному классу.
7.3. Инфраструктура процесса тестирования ПС
Под инфраструктурой процесса тестирования понимается:
- выделение объектов тестирования;
- проведение классификации ошибок для рассматриваемого класса тестируемых программ;
- подготовка тестов, их выполнение и поиск разного рода ошибок и отказов в компонентах и в системе в целом;
- служба проведения и управление процессом тестирования;
- анализ результатов тестирования.
Объекты тестирования - компоненты, группы компонентов, подсистемы и система. Для каждого из них формируется стратегия проведения тестирования. Если объект тестирования относится к "белому ящику" или "черному ящику", состав компонентов которого неизвестный, то тестирование проводится посредством ввода внего входных тестовых данных для получения выходных данных. Стратегическая цель тестирования состоит в том, чтобы убедиться, что каждый рассматриваемый входной набор данных соответствует ожидаемым выходным выходных данным. При таком подходе к тестированию не требуется знания внутренней структуры и логики объекта тестирования.
Проектировщик тестов должен заглянуть внутрь "черного ящика" и исследовать детали процессов обработки данных, вопросы обеспечения защиты и восстановления данных, а также интерфейсы с другими программами и системами. Это способствует подготовке тестовых данных для проведения тестирования.
Для некоторых типов объектов группа тестирования не может сгенерировать представительное множество тестовых наборов, которые демонстрировали бы функциональную правильность работы компоненты при всех возможных наборах тестов.
Поэтому предпочтительным является метод "белого ящика", при котором можно использовать структуру объекта для организации тестирования по различным ветвям. Например, можно выполнить тестовые наборы, которые проходят через все операторы или все контрольные точки компонента для того, чтобы убедиться в правильности их работы.
7.3.1. Методы поиска ошибок в программах
Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.
Ошибка (error) - состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны ( flaw ) в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению.
Дефект (fault) в программе - следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может быть обнаружен дефект или сбой.
Отказ (failure) - это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования [7.6, 7.11]. Отказ может быть результатом следующих причин:
- ошибочная спецификация или пропущенное требование, означающее, что спецификация точно не отражает того, что предполагал пользователь;
- спецификация может содержать требование, которое невозможно выполнить на данной аппаратуре и программном обеспечении;
- проект программы может содержать ошибки (например, база данных спроектирована без средств защиты от несанкционированного доступа пользователя, а требуется защита);
- программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или он реализован не полностью.
Таким образом, отказы, как правило, являются результатами одной или более ошибок в программе, а также наличия разного рода дефектов.
Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:
- непреднамеренное отклонение разработчиков от рабочих стандартов или планов реализации;
- спецификации функциональных и интерфейсных требований выполнены без соблюдения стандартов разработки, что приводит к нарушению функционирования программ;
- организации процесса разработки - несовершенная или недостаточное управление руководителем проекта ресурсами (человеческими, техническими, программными и т.д.) и вопросами тестирования и интеграции элементов проекта.
Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.
Процесс разработки требований. При определении исходной концепции системы и исходных требований к системе возникают ошибки аналитиков при спецификации верхнего уровня системы и построении концептуальной модели предметной области.
Характерными ошибками этого процесса являются:
- неадекватность спецификации требований конечным пользователям;- некорректность спецификации взаимодействия ПО со средой функционирования или с пользователями;
- несоответствие требований заказчика к отдельным и общим свойствам ПО;
- некорректность описания функциональных характеристик;
- необеспеченность инструментальными средствами всех аспектов реализации требований заказчика и др.
Процесс проектирования.Ошибки при проектировании компонентов могут возникать при описании алгоритмов, логики управления, структур данных, интерфейсов, логики моделирования потоков данных, форматов ввода-вывода и др. В основе этих ошибок лежат дефекты спецификаций аналитиков и недоработки проектировщиков. К ним относятся ошибки, связанные:
- с определением интерфейса пользователя со средой;
- с описанием функций (неадекватность целей и задач компонентов, которые обнаруживаются при проверке комплекса компонентов);
- с определением процесса обработки информации и взаимодействия между процессами (результат некорректного определения взаимосвязей компонентов и процессов);
- с некорректным заданием данных и их структур при описании отдельных компонентов и ПС в целом;
- с некорректным описанием алгоритмов модулей;
- с определением условий возникновения возможных ошибок в программе;
- с нарушением принятых для проекта стандартов и технологий.
Этап кодирования.На данном этапе возникают ошибки, которые являются результатом дефектов проектирования, ошибок программистов и менеджеров в процессе разработки и отладки системы. Причиной ошибок являются:
- бесконтрольность значений входных параметров, индексов массивов, параметров циклов, выходных результатов, деления на 0 и др.;
- неправильная обработка нерегулярных ситуаций при анализе кодов возврата от вызываемых подпрограмм, функций и др.;
- нарушение стандартов кодирования (плохие комментарии, нерациональное выделение модулей и компонент и др.);
- использование одного имени для обозначения разных объектов или разных имен одного объекта, плохая мнемоника имен;- несогласованное внесение изменений в программу разными разработчиками и др.
Процесс тестирования.На этом процессе ошибки допускаются программистами и тестировщиками при выполнении технологии сборки и тестирования, выбора тестовых наборов и сценариев тестирования и др. Отказы в программном обеспечении, вызванные такого рода ошибками, должны выявляться, устраняться и не отражаться на статистике ошибок компонент и программного обеспечения в целом.
Процесс сопровождения.На процессе сопровождения обнаруживаются ошибки, причиной которых являются недоработки и дефекты эксплуатационной документации, недостаточные показатели модифицируемости и удобочитаемости, а также некомпетентность лиц, ответственных за сопровождение и/или усовершенствование ПО. В зависимости от сущности вносимых изменений на этом этапе могут возникать практически любые ошибки, аналогичные ранее перечисленным ошибкам на предыдущих этапах.
Все ошибки, которые возникают в программах, принято подразделять на следующие классы [7.12]:
- логические и функциональные ошибки;
- ошибки вычислений и времени выполнения;
- ошибки вводавывода и манипулирования данными;
- ошибки интерфейсов;
- ошибки объема данных и др.
Логические ошибки являются причиной нарушения логики алгоритма, внутренней несогласованности переменных и операторов, а также правил программирования. Функциональные ошибки - следствие неправильно определенных функций, нарушения порядка их применения или отсутствия полноты их реализации и т.д.
Ошибки вычислений возникают по причине неточности исходных данных и реализованных формул, погрешностей методов, неправильного применения операций вычислений или операндов. Ошибки времени выполнения связаны с необеспечением требуемой скорости обработки запросов или времени восстановления программы.
Ошибки ввода-вывода и манипулирования данными являются следствием некачественной подготовки данных для выполнения программы, сбоев при занесении их в базы данных или при выборке из нее.
Ошибки интерфейса относятся к ошибкам взаимосвязи отдельных элементов друг с другом, что проявляется при передаче данных между ними, а также при взаимодействии со средой функционирования.
Ошибки объема относятся к данным и являются следствием того, что реализованные методы доступа и размеры баз данных не удовлетворяют реальным объемам информации системы или интенсивности их обработки.
Приведенные основные классы ошибок свойственны разным типам компонентов ПО и проявляются они в программах по разному. Так, при работе с БД возникают ошибки представления и манипулирования данными, логические ошибки в задании прикладных процедур обработки данных и др. В программах вычислительного характера преобладают ошибки вычислений, а в программах управления и обработки - логические и функциональные ошибки. В ПО, которое состоит из множества разноплановых программ, реализующих разные функции, могут содержаться ошибки разных типов. Ошибки интерфейсов и нарушение объема характерны для любого типа систем.
Анализ типов ошибок в программах является необходимым условием создания планов тестирования и методов тестирования для обеспечения правильности ПО.
На современном этапе развития средств поддержки разработки ПО ( CASE-технологии , объектно-ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.
Связь ошибки с отказом.Наличие ошибки в программе, как правило, приводит к отказу ПО при его функционировании. Для анализа причинно-следственных связей "ошибкаотказ" выполняются следующие действия:
- идентификация изъянов в технологиях проектирования и программирования;
- взаимосвязь изъянов процесса проектирования и допускаемых человеком ошибок;
- классификация отказов, изъянов и возможных ошибок, а также дефектов на каждом этапе разработки;- сопоставление ошибок человека, допускаемых на определенном процессе разработки, и дефектов в объекте, как следствий ошибок спецификации проекта, моделей программ;
- проверка и защита от ошибок на всех этапах ЖЦ, а также обнаружение дефектов на каждом этапе разработки;
- сопоставление дефектов и отказов в ПО для разработки системы взаимосвязей и методики локализации, сбора и анализа информации об отказах и дефектах;
- разработка подходов к процессам документирования и испытания ПО.
Конечная цель причинно-следственных связей "ошибкаотказ" заключается в определении методов и средств тестирования и обнаружения ошибок определенных классов, а также критериев завершения тестирования на множестве наборов данных; в определении путей совершенствования организации процесса разработки, тестирования и сопровождения ПО.
Приведем следующую классификацию типов отказов:
- аппаратный, при котором общесистемное ПО не работоспособно;
- информационный, вызванный ошибками во входных данных и передаче данных по каналам связи, а также при сбое устройств ввода (следствие аппаратных отказов);
- эргономический, вызванный ошибками оператора при его взаимодействии с машиной (этот отказ - вторичный отказ, может привести к информационному или функциональному отказам);
- программный, при наличии ошибок в компонентах и др.
Некоторые ошибки могут быть следствием недоработок при определении требований, проекта, генерации выходного кода или документации. С другой стороны, они порождаются в процессе разработки программы или при разработке интерфейсов отдельных элементов программы (нарушение порядка параметров, меньше или больше параметров и т.п.).
Источники ошибок.Ошибки могут быть порождены в процессе разработки проекта, компонентов, кода и документации. Как правило, они обнаруживаются при выполнении или сопровождении программного обеспечения в самых неожиданных и разных ее точках.
Некоторые ошибки в программе могут быть следствием недоработок при определении требований, проекта, генерации кода или документации. С другой стороны, ошибки порождаются в процессе разработки программы или интерфейсов ее элементов (например, при нарушении порядка задания параметров связи - меньше или больше, чем требуется и т.п.).
Причиной появления ошибок - непонимание требований заказчика; неточная спецификация требований в документах проекта и др. Это приводит к тому, что реализуются некоторые функции системы, которые будут работать не так, как предлагает заказчик. В связи с этим проводится совместное обсуждение заказчиком и разработчиком некоторых деталей требований для их уточнения.
Команда разработчиков системы может также изменить синтаксис и семантику описания системы. Однако некоторые ошибки могут быть не обнаружены (например, неправильно заданы индексы или значения переменных этих операторов).
Читайте также: