Тестирование информационных систем

Тестирование информационных систем

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ОСНОВЫ ТЕСТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Понятие «тестирования информационных систем»

Критерии тестирования

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

ГЛАВА 2. МЕТОДЫ ТЕСТИРОВАНИЯ

Тестирование «белого ящика»

Тестирование «черного ящика»

ГЛАВА 3. ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ. ПРИМЕНЕНИЕ СТАНДАРТА IEEE STD 829 ПРИ ПЛАНИРОВАНИИ И ВЫПОЛНЕНИИ ФУНКЦИОНАЛЬНОГО И НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ВВЕДЕНИЕ

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

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

Современный персональный компьютер имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.

Чрезвычайно актуальными стали следующие проблемы:

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

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

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

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

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

В соответствии с целью были поставлены следующие задачи:

1. проанализировать литературу по теме курсовой работы;
2. рассмотреть и изучить понятие «тестирование программного обеспечения»;
3. выделить виды тестирования программного обеспечения;
4. изучить основные принципы и критерии, предъявляемые к тестированию программного обеспечения;
5. изучить основные методы тестирования программного обеспечения;
6. протестировать на основе изученного материала информационную систему «Учебно-методический ресурс».

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

Первая глава посвящена изучению такого понятия, как «тестирование программного обеспечения».

Вторая глава посвящена изучению методов тестирования, таких как метод «белого ящика» и метод «черного ящика».

В третьей главе рассматривается процесс тестирования фрагмента информационной системы «Учебно-методический ресурс».

ГЛАВА 1. ОСНОВЫ ТЕСТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Виды тестирования.

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

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

Фазы тестирования.

Реализация тестирования делится на три этапа:

1. Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования(testing environment).
2. Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver) с получением протокола тестирования (testlog).
3. Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.

Критерии тестирования.

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

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

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

Классы критериев:

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

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

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

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

• Неэффективность существующих технологий тестирования.

Традиционный подход был тщательно разработан для пакетных и символьно-ориентированных диалоговых Кобол-приложений, но сегодня системы радикально изменились: произошел переход от монолитных программ к фрагментированным модулям на С, С++ и/илиJava. Данный тип разработки увеличивает число компонентов приложения и сложность их взаимодействия, что снижает эффективность тестирования, основанного на коде.

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

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

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

Традиционный подход приводит к выделению половины (а иногда и более) бюджетных средств исключительно на тестирование [2]. Недостаток ресурсов и плана существующих технологий тестирования может сталкиваться с сокращением бюджета и срока разработки, заставляя в худшем случае вообще отказываться от тестирования. Эта ситуация достаточно опасна, если учесть возрастающую роль программного обеспечения в современном бизнесе. Разработчикам нужен новый подход к тестированию, который отвечал бы требованиям сложных приложений и предполагал исправление ошибок как можно раньше. Это дает импульс к преобразованию процесса тестирования: от тестирования по завершении кода, к тестированию на протяжении всего процесса разработки.

• Новый подход к процессу тестирования.

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

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

При новом подходе тестирование должно стать более производительным и эффективным. Точно определенные приемыподдерживают процесс эффективного тестирования путем применения надежных методов и уменьшения дублирования между тестами на разных стадиях. Соответствие условий тестирования специфике его стадий, так же как и фазам разработки, поддерживает высокое качество тестирования тем, что каждое условие проверяется только один раз. Результатом применения стадийной локализации в процессетестирования является V-модель, которая определяет структуру мероприятий верификации, утверждения и тестирования на основе спецификаций. Эта структура организует мероприятия разработки – такие, как формальные проверки, обзоры (reviews) и формальное тестирование.

Как практический подход V-модель была проверена и использовалась более 15-ти лет [3]. Эта методика соотносит стадии разработки с отдельными стадиями тестирования. С ее помощью можно точно определить границы применимости и назначения каждого теста по его соответствующей спецификации. Это помогает избежать неэффективности многих приемов тестирования, включая перекрытие тестовых условий и проведение тех же тестов, но на разных уровнях. V-модель содержит три тестирующих действия: верификацию (verification), проверку на корректность (validation) и собственно тестирование (testing).

1. Верификация.

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

1. Проверка на корректность.

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

1. Тестирование, основанное на спецификациях.

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

Применимость V-модели.

Значимость V-модели была продемонстрирована в проектах, использовавших несколько различных стилей разработки. В случае быстрой разработки (rapid development) V-модель помогает определить процесс проверки корректности, который необходимо выполнять для каждой итерации разработки. В дальнейшем это увеличивает необходимость определения каждой итерации в терминах «тестовых» требований. Для объектной разработки (object development) V-модель обеспечивает основу для организации тестирования на уровнях класса и компонента.

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

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

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

1. Определение критериев входа и выхода.

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

1. Необходимо определить условия теста как можно раньше.

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

1. Управление метриками тестирования.

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

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

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

1. Вовлечение заказчика в процесс разработки.

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

1. Организация команд в рабочие бригады.

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

1. Определение архитектуры тестирования.

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

1. Необходимо эффективно использовать инструменты тестирования.

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

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

Тестирование «белого ящика»

Известна: внутренняя структура программы.

Исследуются: внутренние элементы программы и связи между ними.

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

Тестирование циклов.

Цикл – наиболее распространенная конструкция алгоритмов, используемых в ПО. Тестирование циклов производится по принципу «белого ящика», при проверке циклов основное внимание обращается на правильность конструкций циклов.

Различают 4 типа циклов: простые, вложенные, объединенные, неструктурированные.

Простые циклы.

Для проверки циклов с количеством повторений n может использоваться один из следующих наборов тестов:

• прогон всего цикла;
• только один проход цикла;
• два прохода цикла;
• m проходов циклов, где m<n;
• n-1, n, n+1 проходов цикла.

Вложенные циклы.

С увеличением уровня вложенности циклов количество возможных путей резко возрастает. Это приводит к нереализуемому количеству тестов. Для сокращения количества тестов применяется специальная методика, в которой используются такие понятия, как объемлющий и вложенные циклы.

Шаги тестирования:

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

Объединенные циклы.

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

Неструктурированные циклы.

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

Тестирование информационных систем

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ