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

Содержание:

Введение

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

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

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

1) прикладное программное обеспечение становится большим по объему, так как обрабатывает значительные массивы данных, работает во многих различных направлениях и т.п.;

2) разработанное тестовое программное обеспечение корректно работает для прикладных программных продуктов предыдущих версий, но неэффективно для их современных комбинаций, гак как не учитывает всех особенностей.

Объект курсовой работы - отладка и тестирование программного обеспечения

Предмет исследования – методы отладки и тестирования программ

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

Задачи:

1. Рассмотреть стандарты откладки и тестирования программ
2. Проанализировать методы откладки и тестирования программного обеспечения
3. Изучить Распространенные программные ошибки откладки и тестирования ПО
4. Сделать соответствующие выводы

Глава 1. Стандарты откладки и тестирования программ

1.1 Основные разработчики стандартов в области программной инженерии

Основными разработчиками международных стандартов в области программной инженерии (Software engineering) являются следующие организации:

ISO (International Organization for Standardization) -неправительственная организация с консультативным статусом ООН. Это наиболее представительная и влиятельная организация, разрабатывающая стандарты почти во всех областях деятельности, в том числе и в области программной инженерии. Главная цель - развитие стандартизации и родственных направлений деятельности во всем мире.

Во избежание многочисленных вариаций аббревиатуры, получающейся от перевода International Organization for Standardization на родные языки членов организации, решили использовать аббревиатуру ISO. как сокращенную форму обозначения Международной организации по стандартизации (ISO) во всем мире:

- является всемирной федерацией национальных организаций по стандартизации (комитетов-членов ISO);

- разработка международных стандартов обычно осуществляется техническими комитетами ISO;

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

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

Стандарты ISO являются рекомендательными: в то же время некоторые международные стандарты (например по проблемам здравоохранения, безопасности, охраны окружающей среды) приняты рядом стран в качестве обязательных на территории данной страны.

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

Использование логотипа ISO на каких-либо продуктах или в предприятиях является также незаконным, поскольку дает ощущение "одобрения" данного продукта: а как мы уже говорили. ISO не занимается сертификацией.

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

ACM (Association for Computing Machinery) - название почти никогда не переводится. Можно перевести как Ассоциация по вычислительной технике. Это крупнейшая всемирная научная и образовательная организация, объединяющая более 75000 профессионалов компьютерной науки. Известна также и разработкой образовательных стандартов. Основанная в 1947 г. АСМ ежегодно проводит до 100 международных (научных и практических) конференций, издает несколько десятков научных журналов и присуждает большое количество авторитетных наград за достижения в области компьютерной науки, в т.ч.

А.М. Turing Award, известную как Нобелевская премия информатики. Под эгидой АСМ проводятся ежегодные международные студенческие олимпиады по программированию.

SEI (Software Engineering Institute) - институт Программной Инженерии в университете Карнеги-Меллона - это центр исследования и разработки. находящийся на федеральном финансировании и спонсируемый министерством обороны США. SEI ставит своей основной задачей создание методик для оценки уровня развития внутренних процессов в организации. В качестве подразделения широко известного благодаря разработкам в области вычислительной техники и программного инжиниринга. SEI имеет доступ к самым передовым техническим инновациям. С 1984 года SEI развивает и пропагандирует методики для разработки высококачественного ПО. Первая версия Модели Технологической Зрелости Компании-Разработчика ПО (Capability Maturity Model for Software. SW-CMM) была создана в SEI в 1991 году.

PMI (Project Management Institute) - международный Институт Проектного Менеджмента - Project Management Institute (PMI). основан в 1969 г. в США. Штаб-квартира в Филадельфии (Пенсильвания). Международная общественная организация. объединяющая профессионалов в области проектного менеджмента. PMI объединяет от 100000 до 135000 членов в 125 странах мира.

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

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

РКП предоставляет всеобъемлющее руководство по разработке стандартов для проектного менеджмента (стандарт по управлению проектами РМВОК). PMI стал первой организацией в мире, имеющей программу сертификации специалистов по управлению проектами -Project Management Professional (РМР).

Для обучения проектному менеджменту и подготовки к экзамену РМР созданы Registered Education Provider (R.E.P) - сертифицированный провайдер по образованию - во многих странах мира.

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

PMI выпускает три вида периодических изданий для индивидуальных лиц, занимающиеся проектным менеджментом: ежемесячный журнал PM Network. ежеквартальный журнал Project Management Journal и ежемесячный информационный бюллетень PMI Today. PMI является ведущим мировым издателем литературы и учебных материалов по проектному менеджменту. В онлайновом магазине PMI в настоящее время доступно более 1000 наименований.

IEEE (Institute of Electrical and Electronics Engineers) - Институт инженеров по электронике объединяет почти 400000 технических специалистов из более чем 150 стран. IEEE состоит из ряда профессиональных сообществ, в самое крупное из которых - IEEE Computer Society - входят более 10 0000 человек. Компьютерное сообщество IEEE ежегодно спонсирует около ста пятидесяти научных конференций и симпозиумов, публикует более 20 периодических издании. IEEE Computer Society также широко известно своей деятельностью по стандартизации, которую на сегодняшний день в рамках сообщества осуществляют порядка 200 рабочих групп.

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

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

- СМЛП (Capability Maturity Model Integration for Product and Process Development) — Интегрированная модель оценивания зрелости продуктов и процессов разработки программных средств.

- ISO 19759:2005. SWEBOK. Свод знаний о программной инженерии.

- ISO 15288:2002. Системная инженерия. Процессы жизненного цикла систем.

- ISO 19760:2003. Системная инженерия. Руководство по применению стандарта ISO 15288.

- ISO 12207:1995. (ГОСТ Р - 1999). ИТ. Процессы жизненного цикла программных средств.

- ISO 12207:1995. - ИТ. Процессы жизненного цикла

программных средств. Изменения 1 и 2:2002-2004.

- ISO 15271:1998. (ГОСТ Р - 2002). ИТ. Руководство по применению ISO 12207.

ISO 16326:1999. (ГОСТ P - 2002). ИТ. Руководство по применению ISO 12207 при административном управлении проектами.

ISO 15504 - 1-5: 2003-2006. ИТ. Аттестация процессов. 4.1. Концепция и словарь. 4.2. Подготовка к аттестации. 4.3. Руководство по проведению аттестации. 4.4. Руководство для пользователей по усовершенствованию процессов и определению зрелости процессов. 4.5. Образец модели аттестации процессов.

ГОСТ Р 51904 - 2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию.

ISO 9000:2000. (ГОСТ Р - 2001). Система менеджмента (административного управления) качества. Основы и словарь.

ISO 9001:2000. (ГОСТ Р - 2001 ). Система менеджмента (административного управления) качества. Требования.

ISO 9004:2000. (ГОСТ Р - 2001). Система менеджмента (административного управления) качества. Руководство по улучшению деятельности.

ISO 90003:2004. Руководство по организации применения стандарта ISO 9001:2000 для программных средств.

ISO 10005: 1995. Административное управление качеством. Руководящие указания по программам качества.

ISO 10006: 1997. Руководство по качеству при управлении проектом.

ISO 10007: 1995. Административное управление качеством. Руководящие указания при управлении конфигурацией.

ISO 10011-1-3: 1990. Руководящие положения по проверке систем качества. 4.1. Проверка. 4.2. Квалификационные критерии для инспекторов-аудиторов систем качества. 4.3.

Управление программами проверок.

ISO 12182:1998. (ГОСТ Р-2002). ИТ. Классификация программных средств.

ISO 9126:1991. (ГОСТ - 1993). ИТ. Оценка программного продукта. Характеристики качества и руководство по их применению.

ISO 14598-1-6:1998-2000. Оценивание программного продукта.

4.1. Общий обзор. 4.2. Планирование и управление. 4.3. Процессы для разработчиков. 4.4. Процессы для покупателей.

4.5. Процессы для оценщиков. 4.6. Документирование и оценивание модулей.

ISO 9126-1-4: 2002. ИТ. ТО. Качество программных средств:

4.1. Модель качества. 4.2. Внешние метрики. 4. 3. Внутренние метрики. 4.4. Метрики качества в использовании.

ISO 25000:2005 ТО. - Руководство для применения новой серии стандартов по качеству программных средств на базе обобщения стандартов ISO 9126:1-4: 2002 и ISO 14598:1-6:1998-2000.

ISO 15939: 2002 - Процесс измерения программных средств.

IEC 61508:1-6: 1998-2000. Функциональная безопасность электрических / электронных и программируемых электронных систем. 4асть 3. Требования к программному обеспечению. 4асть 6. Руководство по применению стандартов IEC 61508-2 и IEC 61508-3.

ISO 15408 -1-3. 1999. (ГОСТ Р - 2002). Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. 4.1. Введение и общая модель.

РД 50-34.698-90. Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.

ГОСТ Р 51901-2002. Управление надежностью. Анализ риска технологических систем.

DO-178 В-1995. Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения.

ISO 14102:1995. Оценка и выбор CASE- средств.

ISO 14471:1995. Руководство по адаптации CASE- средств.

ISO 14143: 1-5: 1998 - 2004. ИТ. Измерение программных средств. Измерение функционального размера. 4.1. 1998.

Определение концепции. 4.2. 2002. Оценивание соответствия методов измерения размера программных средств стандарту ISO 14143:1:1998. 4.3. 2003. Верификация методов измерения функционального размера. 4.4. 2002. Эталонная модель. 4.5. 2004. Определение функциональных доменов для использования при измерении функционального размера.

ISO 20926:2003. Руководство по практическому методу измерения функционального размера программных средств.

ISO 20968:2002. Руководство по расчетам на основе анализа функциональных точек - Марк II.

Глава 2. Анализ методов откладки и тестирования программного обеспечения

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

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

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

Существуют два основных метода тестирования: метод «черного ящика» и метод «белого ящика» [1].

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

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

В таблице 1 проведено сравнение вышеописанных методов тестирования программного обеспечения.

Таблица 1

Критерии	White Box	Black Box
Уровни	Модульное тестирова­ние	Системное тестирование
	Интеграционное тести­рование	Приемочные испытания
Тест выполняется	Разработчиком	Тестировщиком
Знание программирова­ния	Требуется	Не нужно
Основа тестирования	Исходный код и струк­тура программы	Спецификация, требова­ния

Существует еще третий метод тестирования, называемый «серым ящиком» (gray-box testing). Стратегия данного вида тестирования предполагает комбинацию методов «черного» и «белого ящика», подразумевающую возможность частичного знания структуры приложения, однако само тестирование происходит по методу «черного ящика».

Рассмотренные методы включают в себя уровни тестирования, определяющие, над чем будет выполняться тест: над отдельным модулем, группой модулей или системой в целом [3].

Модульное тестирование (Unit Testing) - самый первый уровень тестирования, который проводится на самых ранних этапах разработки, по методу «белого ящика». Суть модульного тестирования заключается в тестировании на наличие ошибок, отдельных частей программы, не способных функционировать по отдельности. В совокупности такие модули дают готовое работоспособное приложение. Для проведения модульных тестов требуется точное знание структуры и каждого компонента программы. Такая проверка является более сложной и преимущественно производится программистами, разрабатывающими приложение.

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

Системное тестирование (System Testing) - это третий уровень тестирования, который происходит по методу «черного ящика». Тестирование выполняется над готовой системой или приложением. Задачей системного тестирования является проверка функциональных и не функциональных требований к приложению. Система на этом уровне проверяется на наличие ошибок и багов в функциональности, безопасности и производительности. Знание структуры программы для проведения системного тестирования не требуется. Для получения наиболее эффективных результатов проверки тестирование производится в условиях, максимально приближенных к тем, в которых программа будет работать после выдачи заказчику.

Приемочное тестирование (Acceptance Testing) - происходит после успешного завершения всех предыдущих уровней. Цель данного этапа тестирования: определение соответствия продукта всем установленным заказчиком требованиям. Приемочное тестирование разделяется на два вида: внутреннее (альфа-тестирование), которое производится командой разработчиков, и внешнее (бета-тестирование), осуществляемое на стороне конечного пользователя или заказчика [4].

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

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

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

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

•ошибки, связанные с нарушением допустимых ограничений на работу ЭВМ;

•ошибки, связанные с невозможностью выполнения арифметических операций.

К ошибкам первого типа относятся: выход данных за допустимые пределы представления чисел в ЭВМ (переполнение разрядной сетки или потеря порядка), нарушение защиты памяти или возникновение неверного кода машинной операции.

Характерным примером ошибок второго типа является несоблюдение условий использования стандартных математических функции, например, попытка возведения в нецелую степень отрицательного числа, логарифмирование отрицательных чисел, вычисление функции ArcSin(X) от аргумента X большего 1. извлечение квадратного корня из отрицательного числа и т.п. К этому же типу ошибок относится и ошибка, связанная с попыткой деления на ноль.

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

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

К таким методам относятся следующие способы:

•аварийная печать:

•печать в узлах;

•слежение;

•прокрутка:

•контроль индексов элементов массивов.

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

Печать в узлах предназначена для получения значений переменных в заранее выбранных местах (узлах) программы.

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

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

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

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

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

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

Для установления конкретного места ошибки используют следующие приемы анализа программы:

•прослеживание по схеме алгоритма:

•обратное отслеживание идентификаторов:

•ручная прокрутка программы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переменная	Значение
А	2
В	3
X	3

Покажем на данном примере слабые стороны данного критерия. Например, пусть первое решение записано как или, а не как и. При тестировании по данному критерию эта ошибка не будет обнаружена. Пусть второе решение записано в программе как Х>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 Ошибки пользовательского интерфейса

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

- функциональность;

- быстрота изучения программы новым пользователем;

- легкость запоминания необходимых приемов работы;

- производительность:

- вероятность возникновения ошибок пользователя:

- удовлетворенность пользователя программой.

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

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

3.2 Функциональность

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

Избыт очная функциональность

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

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

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

Ложное впечатление о наборе функций

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

Неадекватность реализации базовых функций

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

Пропущенная функция

В программе отсутствует описанная в спецификации или очевидно необходимая функция.

Функция должна быть реализована пользователем

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

Программа не делает того, что ожидает от нее пользователь

Например, если программа должна сортировать список имен, едва ли кто-то станет ожидать, что имена будут сортироваться в порядке ASCII. Кроме того, пользователи предположат, что программа не будет учитывать ведущих пробелов и регистра букв. Если же программист хочет убедить, что программа должна работать таким неожиданным образом, он должен отразить это в ее названии и документации, и желательно еще и внести в нее возможность альтернативного способа работы.

3.3 Взаимодействие программы и пользователя

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

Пропущенная информация

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

Отсутствие инструкций на экране

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

Программа рассчитана на то, что у пользователя всегда под рукой печатная документация

Можно ли использовать программу, потеряв руководство? Неопытный пользователь не должен полностью зависеть от печатной документации.

Недокументированные возможности

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

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

Состояния, из которых сложно найти выход

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

Отсутствие курсора

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

Программа не распознает ввод

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

- программа находится в процессе перехода из одного состояния в другое:

- программа игнорирует определенные действия пользователя;

- пользователем дана команда не отображать ввод;

- вводится пароль или другая секретная информация.

Длительное отсутствие активности

Выполняя длительное задание (занимающее более двух секунд), программа должна показывать пользователю, что она работает, а не зациклилась или остановилась. Иначе пользователь не будет знать, нужно ли ему перезапустить компьютер или просто немного подождать. Желательно отображать еще и индикатор, показывающий, какая часть задания выполнена и сколько времени еще осталось.

Невозможность определить, выполнена ли данная программе команда

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

Невозможность определить, что один и тот же документ открыт несколько раз

Программы, позволяющие одновременно открывать несколько документов, должны проверять каждый открываемый документ и сообщать пользователю, если он открывается повторно. Иначе пользователь может запутаться во вносимых в документ изменениях. Кроме того, версии документа должны иметь на экране разные имена. Например, если пользователь дважды открыл файл MyDoc, в одном окне этот файл должен иметь имя My_Doc:l, а в другом - My_Doc:2 (или что-то в этом роде). В качестве альтернативы можно вообще не разрешать дважды открывать один документ.

Неверная или смущающая пользователя информация

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

Простая фактическая ошибка

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

Синтаксические ошибки

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

Неаккуратное упрощение

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

Неудачные метафоры

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

Неточные названия команд и функций

Команда СОХРАНИТЬ не должна использоваться для удаления файла или сортировки его содержимого. Если в русском (английском) языке за словом закрепилось определенное значение, названная этим словом команда должна ему соответствовать.

Несколько названий одной функции

Одна и та же функция не должна иметь в программе несколько названий. Пользователь не должен ломать голову над тем. чем отличаются команды Тень и Наложить тень.

Пестрые цветовые сочетания

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

Использование цветов в качестве смыслового элемента интерфейса

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

Несогласованность со стилем операционной среды

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

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

Заключение

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

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

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

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

Список литературы

1. Керниган Брайан. Практика программирования. М.: Вильямс. 2015, 288 стр.

2. Коликова Т.В.. Котляров В.П. Основы тестирования программного обеспечения. М.. Бином. 2010, 285 стр.

3. Хант Э.. Программист-прагматик. Путь от подмастерья к мастеру. М.: ЛОРИ. 2016. 288 стр.

4. Котляров В.П. Технология программирования. Основы современного тестирования программного обеспечения, разработанного на С#: учеб, пособие / под общ. ред. В.П. Котлярова. СПб: СПбГПУ, 2004.

5. Басок Б.М. Тестирование готового к использованию программного продукта // ИТ-Стандарт. - 2018. - Т. 1. - №1-1(14). - С. 1-7.

6. Гусев Е.В., Стефанцов А.В. Технология разработки надежного программного обеспечения // Наноиндустрия. - 2018. - №S. - С. 167-168.

7. Литвиненко А.М., Сметанин К.А. Генерация тестовых данных с использованием генетических алгоритмов // Вестник Липецкого государственного технического университета. - 2018. - №1. - С. 29-35.

8. Золотухина Е.Б., Макарова Е.А. Обзор методов тестирования программного обеспечения И Аллея науки. 2018. - №6. - С. 10-18.

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

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

11. Котляров В. IL, Коликова Т.В. Основы тестирования программного обеспечения - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006. - 285с.

12. Орлик С. Основы программной инженерии по SWEBOK (Software Engineering Body of Knowledge). Программная инженерия. Тестирование программного обеспечения. Copyright, 2010. - 16с.

13. Блэк Р. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование- М.: Издательство «Лори», 2017. -544с.

14. Долинина О.Н. Отладка нейросетевой экспертной системы для офтальмологии / О.Н. Долинина. А.К. Кузьмин // Вестник СГТУ. 2011. № 4(62). Вып. 4. С. 248-253.

15. Шульга Т.Э. Организационные принципы подготовки IT-специалистов / Т.Э. Шульга // Прикладная информатика. 2009. № 3. С. 49-53.