Реферат: По истории информатики на тему

Санкт Петербургский государственный университет информационных технологий механики и оптики

Реферат

По истории информатики на тему

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

Санкт-Петербург

200 9 г

Оглавление

Введение. 3

Понятие тестирования. 4

Эволюция тестирования. 6

Виды тестирование, используемые в настоящее время. 8

Автоматизированное тестирование. 12

Перспективы развития тестирования. 16

Заключение. 18

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

Введение

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

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

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

Тестировать можно все:

· работу программы

· качество ее кода и понятность комментариев

· быстродействие

· устойчивость под большой нагрузкой

· расход ресурсов (памяти, диска, потери этих ресурсов)

· взаимодействие с другими программами

· стабильность работы

· возможность работы на других платформах

· удобство интерфейса

· документацию к программе (смысловые и грамматические ошибки, понятность и полноту)

· работу через сеть, работу аппаратного обеспечения и т.п.

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

Как правило, на фазе тестирования осуществляется и исправление идентифицированных ошибок, включающее:

• локализацию ошибок

• нахождение причин ошибок

• корректировку программы.

Тестирование разделяют на статическое и динамическое:

· Статическое тестирование выявляет неверные конструкции или неверные отношения объектов программы (ошибки формального задания) формальными методами анализа без выполнения тестируемой программы.

· Динамическое тестирование осуществляет выявление ошибок на выполняющейся программе.

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

Тестирование решает несколько основных задач:

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

· Подтверждает, что приложение способно выполняться во всех заявленных режимах и на всех поддерживаемых ОС или Web-браузерах корректно;

· Гарантирует, что хранимые и обрабатываемые данные надежно защищены от постороннего доступа и "взлома";

· Определяет, какая максимальная нагрузка на сервер, локальную сеть, БД может быть корректно обработана приложением;

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

Эволюция тестирования

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

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

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

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

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

Виды тестирование, используемые в настоящее время

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

· Модульное тестирование.

· Интеграционное тестирование.

· Системное тестирование.

Модульное тестирование

· Модульное тестирование - это тестирование программы на уровне отдельно взятых модулей, функций или классов.

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

· Модульное тестирование проводится по принципу "белого ящика“

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

Обнаруживаемые ошибки

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

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

Интеграционное тестирование

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

Системное тестирование

• Основная задача системного тестирования - выявление дефектов, связанных с работой системы в целом:

· неверное использование ресурсов системы

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

· несовместимость с окружением

· непредусмотренные сценарии использования

· отсутствующая или неверная функциональность

· неудобство в применении и тому подобное.

• Системное тестирование производится над проектом в целом с помощью метода «черного ящика».

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

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

При тестировании белого ящика разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing ), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени.

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

Различают следующие виды тестирования:

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

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

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

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

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

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

Автоматизированное тестирование

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

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

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

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

Создание тестов. Имеется в виду предварительная автогенерация: на основе кода - для unit-тестов, на основе функциональных требований - для ручных тестов, генерация по принципу record’n’play и т.п.

Анализ покрытия / трассировка. Выполняется для оценки покрытия кода, требований или некоторого объема функциональности теми или иными типами тестов, созданных на предыдущем этапе.

Выполнение тестов. Запуск тестовых скриптов и анализ полученных результатов.

Цели автоматизированного тестирования:

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

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

Конфигурационное тестирование – выполнение одних и тех же тестов в разных условиях. То есть когда один или несколько компонентов архитектуры системы требуется проверить в разном окружении, обычно заявленном в изначальных требованиях. Например: поддержка СУБД от разных производителей, работа в разных клиентских браузерах, использование в нескольких ОС и т.п. То есть некий аналог регрессионного тестирования, но в рамках одной версии системы. Кроме средств контроля за выполнением работ, в данном случае, нелишней бывает возможность автоматического сравнения полученных результатов выполнения сценариев в разных конфигурациях.

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

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

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

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

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

Тестирование GUI (пользовательского интерфейса) – то, о чём обычно идёт больше всего разговоров. И что далеко не всегда удается успешно внедрить. Обычно применяется на уровне системного тестирования для поиска регрессионной зависимости.

Автоматизированное тестирование всегда имеет как плюсы:

• Большее покрытие кода;
• Тест не будет пропущен;
• Тесты содержит одни и те же шаги;

так и минусы:

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

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

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

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

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

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

1. Автоматизация может применяться в большинстве процессов и на всех уровнях тестирования.
2. Ручное и автоматизированное тестирование – это взаимодополняющие технологии.
3. Автоматизированное тестирование подразумевает участие человека.
4. Автоматизированное тестирование требует дополнительных инвестиций, но позволяет повысить качество продукта.
5. Автоматизированное тестирование – это разработка (программирование).
6. Автоматизированное тестирование гарантирует детерминированную проверку функциональности.
7. Сопровождение автоматизированных тестов требует больших дополнительных расходов при активном изменении тестируемой системы.

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

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

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

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

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

Заключение

Статистика:

• Объем мирового рынка тестирования программного обеспечения – 13 миллиардов долларов (по статистике International Data Corporation - IDC)
• Объем рынка внешнего (outsource) тестирования – порядка 6.1 миллиарда долларов (по статистике Dataquest)
• Объем рынка инструментов для автоматизированного тестирования – порядка 1.2 миллиардов долларов, и возрастает ежегодно на 14.9% (по статистике IDC)
• Разработка программного продукта составляет до 40% среднестатистического бюджета программного продукта, его тестирование составляет порядка 40% бюджета разработки (по статистике LogiGear)
• Объем рынка оффшорного тестирования и поддержки программного обеспечения превышает 3.4 миллиарда долларов (по статистике IDC)

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

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

1. С. Канер, Д. Фолк, Е. Нгуен. Тестирование программного обеспечения. — К.: Диасофт, 2000. — 544 с.

2. Г. Майерс. Искусство тестирования программ. — М.: «Финансы и статистика», 1982. — 176 с.

3. Р. Калбертсон, К. Браун, Г. Кобб. Быстрое тестипрование. – М.: Издательский дом «Вильямс», 2002. – 384 с.

4. Hung Q. Nguyen, Bob Johnson, Michael Hackett. Testing Applications on the Web. 2001. – 402 с.

5. http://software-testing.ru/ Портал специалистов по тестированию и обеспечению качества ПО.

6. http://www.softwaretestinghelp.com

7. http://www.idc.com Российский сайт компании International Data Corporation