Файл: отладка и тестирование программного обеспечения.pdf

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

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

2.2 Некоторые аспекты отладки программного обеспечения

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

Как известно, при создании типового программного проекта около 50% общего времени и более 50% общей стоимости расходуется на тестирование и отладку' разрабатываемой системы [1]. Можно говорить о том, что отладка программного обеспечения является отдельной специализированной областью знаний, приобретающей особое значение с увеличением влияния информационных технологий на все сферы современной жизни. Очевидно, что при активном развитии информационных технологий и повышении значимости надежности и качества программного обеспечения (ПО) можно говорить о формировании такой квалификации, как тестировщик, и о необходимости подготовки соответствующих кадров.

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

Итак, тестирование - это процесс исполнения программы на тестовом множестве с целью обнаружения ошибок [1-3]. Естественно, необходимо рассмотреть возможность создания тестов, обнаруживающие все ошибки программы. Однако в общем случае невозможно обнаружить все ошибки программы, т.е. тест для любой программы будет обязательно неполным. Поэтому задача тестирования сводится к обнаружению максимально возможного числа ошибок. Исходя из этого, наибольшее внимание при тестировании программ уделяется созданию эффективных тестов. Реальные бизнес-процессы требуют введения ограничений на время отладки, стоимость и т.п., поэтому важным вопросом тестирования становится вопрос о выборе стратегии тестирования. Как правило, выделяются две основные стратегии: тестирование программы как «черного ящика» и тестирование программы как «белого ящика» [1]. Тесты, строящиеся на основе «белого ящика», позволяют анализировать структуру программы и, следовательно, позволяют обеспечить построение полного множества тестов. Рассмотрим более подробно стратегию белого ящика.

Тестирование по принципу белого ящика характеризуется степенью, в какой тесты выполняют или покрывают логику (исходный текст) программы [1, 2]. Отметим, что в данном случае речь идет о программах, написанных на процедурных (императивных) языках программирования, т.к., например, для тестирования систем искусственного интеллекта традиционные критерии практически не работают [4]. Исчерпывающее тестирование по принципу белого ящика предполагает выполнения каждого пути в программе, но поскольку в программе с циклами выполнение каждого пути обычно нереализуемо, то тестирование всех путей часто рассматривается как неэффективное. Часто рассматривают критерий покрытия операторов, требующий выполнение каждого оператора хотя бы один раз. Этот критерий является необходимым, но не достаточным критерием построения полного множества тестов.

Тестируемая программа

Предположим, что на рисунке представлена небольшая программа, которая должна быть протестирована. Эквивалентная программа, написанная на Java, имеет вид

Можно выполнить каждый оператор, записав единственный тест, который реализует путь 1-2-3-4-5. Т.е. в точке, а должны быть установлены значения

Значения переменных в точках тестирования

Покажем на данном примере слабые стороны данного критерия. Например, пусть первое решение записано как или, а не как и. При тестировании по данному критерию эта ошибка не будет обнаружена. Пусть второе решение записано в программе как Х>0; эта ошибка также не будет обнаружена. Кроме того, существует путь, в котором X не изменяется (путь abd). Если здесь ошибка, то и она не будет обнаружена.

Рассмотрим следующий фрагмент программы:

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

Более сильный критерий покрытия логики программы известен как критерий покрытия решений, или покрытия ветвей. Согласно данному критерию должно быть записано достаточное число тестов, такое, что каждое решение на этих тестах примет значение истина и ложь по крайне мере один раз. Иными словами каждое направление перехода должно быть реализовано, по крайней мере, один раз. Примерами операторов перехода или решений являются операторы switch, do-while,if-else.

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

Программа не имеет решений

Программа или подпрограмма имеет несколько точек входа.

Операторы внутри ON-единиц; выполнение каждого направления перехода не обязательно будет вызывать выполнение всех ON единиц.

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

В программе, представленной на рисунке, покрытие решений может быть выполнено двумя тестами, покрывающими либо пути асе и abd, либо пути acd и abe.

Покрытие решений - более сильный критерий, чем покрытие операторов, но и он имеет свои недостатки.

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

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

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

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

специализированного обучающего программного обеспечения, которое должно гарантировать наглядное представление и моделирование процесса тестирования логики программы. Обучающее программное обеспечение позволит студентам лучше понять использование критериев тестового покрытия, научит создавать максимально эффективные входные тестовые наборы, для обнаружения ошибок в программе и как следствие улучшать надежность и качество программного продукта. Разрабатываемое программное обеспечение представляет собой настольное приложение, использующее программную модель Windows Presentation Foundation (WPF) и написанное на языке С#. В процессе обучения студент учится проводить тестирование небольших программ, написанных на языках С, С#, Java. Особенностью является то, что объем тестируемого кода не должен превышать 100 строк для построения наглядной графической модели. Обучающийся сможет визуально проанализировать покрытие тестами всех ветвей программы, а это, в свою очередь, поможет определить те критические точки программы, в которых вероятность возникновения ошибки наиболее высока.

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

Глава 3. Распространенные программные ошибки

К распространенным ошибкам в программах можно отнести следующие группы ошибок:

- ошибки пользовательского интерфейса;

- обработка ошибок;

- ошибки, связанные с граничными условиями;

- ошибки вычислений;

- начальное и последующие состояния;

- ошибки управления потоком;

- ошибки обработки или интерпретации данных;

- ситуации гонок;

- повышенные нагрузки;

- аппаратное обеспечение;

- контроль версий и идентификаторов;

- ошибка выявлена и забыта.

Рассмотрим подробно некоторые из этих групп.

3.1 Ошибки пользовательского интерфейса

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