Особенность тестирования программного обеспечения - Курсовая работа

История тестирования и отладки программного обеспечения отражает эволюцию разработки самого программного обеспечения. В течение длительного времени разработка программного обеспечения уделяла основное внимание крупномасштабным научным программам, а также программам министерства обороны, связанным с системами корпоративных баз данных, которые проектировались на базе универсальной ЭВМ или миникомпьютера. Тестирование обычно начиналось лишь после завершения разработки проекта и выполнялось тем же персоналом тех же разработчиков. Появление персональных компьютеров способствовало стандартизации этой отрасли, поскольку приложения стали изначально создаваться для работы с общей операционной системой. Они могут сделать жизнь разработчиков действительно несчастной, потому что, достаточно нескольким ошибкам вкрасться в их программы, как заказчики прекращают пользоваться этими программами, а сами они даже могут потерять работу.Тестирование программы (software testing) - это процесс анализа или эксплуатации программы с целью выявления дефектов. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование - плановая, упорядоченная деятельность. Согласно этому определению, тестирование предусматривает "анализ" или "эксплуатацию" программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программы называется статическим тестированием (static testing).Цели тестирования: Повысить вероятность того, что приложение, предназначенное для тестирования, будет работать правильно при любых обстоятельствах. Повысить вероятность того, что приложение, предназначенное для тестирования, будет соответствовать всем описанным требованиям. Задачи тестирования: Проверить, что система работает в соответствии с определенными временами отклика клиента и сервера.Обнаружив ошибку, транслятор выводит сообщение, указывая на место ошибки в программе и ее характер.Нередко можно услышать, что тестирование - это процесс выполнения программы с целью необнаружения в ней ошибок. Напротив, “неудачным” можно назвать тест, не позволивший выявить ошибку в программе. Поскольку программирование - процесс конструктивный, ясно, что большинству разработчиков программных средств сложно “переключиться” при тестировании созданной ими продукции. 2) следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии (однако отладка программы эффективнее всего выполняется именно автором программы); 4) должны являться правилом доскональное изучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе;Поскольку исчерпывающее структурное тестирование невозможно, необходимо выбрать такие критерии его полноты, которые допускали бы их простую проверку и облегчали бы целенаправленный подбор тестов. Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения (покрытия) каждого оператора программы. Использование критерия покрытия условий может определить подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С1 (например, в программе, использующей конструкцию цикла WHILE х AND y DO... A AND B THEN... требует по критерию покрытия условий двух тестов (например, A=true, B=false и A=false, B=true), при которых может не выполняться оператор, расположенный в then - ветви оператора if. Но с помощью этого инструмента поддержки тестирования можно проверить выполнение только слабейшего из критериев полноты - покрытие всех операторов.Если ошибка обнаружена при тестировании единственного модуля, то очевидно, что она содержится именно в нем - для поиска ее источника не нужно анализировать код всей системы. Благодаря этому тестирование проводится более тщательно и с большей вероятностью выявляет ошибки. тестирование программа интерфейс данные Если он, в свою очередь, вызывает другой модуль, для него нужно написать «заглушку». Получается, что вопрос не столько в том, в каком модуле произошла обнаруженная ошибка, сколько в том, какая из ошибок во всех вовлеченных в процесс модулях привела к полученному результату. Кроме того, ошибка в одном из модулей может блокировать тестирование другого.Отладка программы так или иначе принимает рассмотрение и логическое решение доступной информации о ошибках. Большая часть ошибок может быть узнана посредством тщательного анализа текстов программ и результатов тестирования, не получая дополнительной информации. § Прологи - этот метод основан на тщательном анализе симптомов ОШИБКИ, которые можно показать как неправильные результатов расчета или как сообщение об ошибке. Если компьютер просто «зависает», фрагмент дисплея ОШИБКИ вычисляют и анализируют происхождение последних полученных результатов, постепенно локализуя ошибку.Создать Windows-приложение:

Содержание

Введение

1. Тестирование и отладка программ

1.1 Принципы тестирования и отладка

1.2 Цели и задачи тестирования

1.3 Синтаксическая отладка программы

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

1.5 Структурное тестирование

1.6 Восходящее и нисходящее тестирование

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

2. Практическое задание

Заключение

Перечень использованной литературы

Приложение

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

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

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

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

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

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

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