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

ВВЕДЕНИЕ

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

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

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

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

Объект исследования: тестирование и отладка программного обеспечения. Предмет исследования: стратегия тестирования и отладки программного обеспечения.

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

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

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

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

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

1.1 История тестирования программного обеспечения

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

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

В начале 1970-х годов тестирование программного обеспечения обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы программного обеспечения». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования программного обеспечения. Однако в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приёмо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. [5,c.608]

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

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

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

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

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

В 2000-х появилось ещё более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий». Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки программного обеспечения для достижения необходимого уровня качества, производительности, доступности. [10,c.320]

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

Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий две различные цели:

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

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

Тестированием программного обеспечения (software testing) является процесс анализа либо эксплуатации программного обеспечения для выявления дефектов.

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

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

По данному определению процесс тестирования представляет собой эксплуатацию и анализ программы. Тестирование напрямую взаимосвязано с анализированием результативности разработки ПО, которое довольно часто именуют стратегическим тестированием. Тестирование такого рода - это проверка программного кода, и осуществление сквозного контроля, а также проверка программы не запуская ее, то есть проверка за столом, на англ. desk checks). Тестовая деятельность, которой предусмотрен процесс эксплуатации ПО, называется динамическим тестированием, на англ. dynamic testing). Оба вида тестирования дополняют друг друга, что дает возможность провести качественное тестирование и выявить все ошибки [9,c.288-299]

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

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

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

1.3 Этапы, цели и задачи тестирования программного обеспечения

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

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

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

Есть разные подходы по формулировке стратегии тестирования:

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