Файл: Понятие о программном обеспечении.pdf

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

Такая совокупность указанных данных также называется тестом или эе тестовым множеством. [14]

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

1. тестирования, где могут выявленные самые различные ошибки ПО;

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

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

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

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

При тестировании возникает следующие 2 задачи:

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

Получим вторую задачу: [14]

– определять моменты для окончания шагов по отладке программ или их составных частей.

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

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

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

Для этого также необходимо: [10]

– заранее планировать механизм тестирования;

– использовать только одну рациональную стратегию в планировании или проектировании тестов.

Проектирование тестов начинают после завершения этапов с описанием ПО.

Также возможны и самые разные инструменты, а также подходы при выработке разных направлений проектирования, что часто можно размещать между известными подходами черных или белых ящиков. [18]

Процессы выполнения тестирования можно разделить по:

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

– динамическое;

– статическое;

возможности для доступа к коду продукта:

– тестирование типа "черного ящика";

– тестирование типа "белого ящика";

по масштабу тестируемых программ:

– альфа, бета тестирования;

– модульное;

– приемо-сдаточные тестирования;

– системное;

– интеграционное испытание;

– пилотное тестирование.

при выполнении этапа тестирования:

– функциональное;

– загрузочное;

– испытание безопасности;

– "дымовое";

– тестирование комфортности.

Кроме указанных выше инструментов часто применяются и процессы тестирования их надежности.

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

Самой главной целью данного тестирования надежности (или же стабильности) является возможность применить проверку работоспособности систем при их длительном тестировании на номинальных нагрузках производительности. [13]

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

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

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

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

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

Различают окончательные (или финишные) этапы выполнения процесса тестирования:

– базовое тестирование;

– стабилизация программ;

– тестирование программных прототипов;

– эксплуатация программ.

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

2.2. Методологии тестирования программ

2.2.1. Метод Сандвича

Тестирование методом Сандвича имеет прекрасные возможности находить компромиссы для самых основных подходов в процессе тестирования:

– нисходящим;

– восходящим.

В таком методе делаются попытки для применения достоинств 2-х способов.

При применении метода одновременно начинают выполнять нисходящие и восходящие тестирования, собирая ПО с помощью методологии типа «снизу и сверху». [16]

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

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

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

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

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

2.2.2. Методология «белого ящика»

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

Технологии, что реализуются во время выполнения процесса тестирования по указанным принципам "белого ящика", обычно называют статическим тестированием.[9]

Методы тестирования типа «белого ящика» также направляются на проблему выполнения процесса локализации ошибок, которых бывает намного сложнее отыскать (рисунок 5). [5]

Рисунок 5 – Принцип тестирования «белого ящика»

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

Все такие процедуры, что хотя бы повязанные как-то с реализацией тестов, применяют часто управляющую логику:[2]

– Они проверяют практически все основные решения, а именно разные свойства истинности.

– Дают гарантии на независимость методов в исследуемых программных модулях.

– Выполняют циклы по операционным границам с контрольными значениями.

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

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

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

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

– реализация вычислений для тестов;

– функциональности, что могут быть поддержаны другими программными продуктами;

– промежутков в сфере действия информации, обрабатываемой некоторым продуктом.

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

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

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

3. ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ ТЕСТИРОВАНИЯ И ОТЛАДКИ ПО

3.1.Описание разработки ПО через тестирование на практике

Рассмотрим практическое применение разработки ПО через тестирование.

Разработка через тестирование (от англ. test-driven development) – это техника программирования, для которой модульные тесты программы или её фрагментов пишутся до самого завершения программы и, по существу, они управляют её разработкой.

Эта технология является одной из главных практик экстремального программирования.[3]

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

Для такого контекста тест состоит из 2 этапов:

– стимулирование кода;

– проверка результатов работы кода.

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

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

«Чистый код, что работает» – в этой фразе, кроется смысл методики разработки программ через тестирование.

«Чистый код, который работает», – цель, к которой нужно стремиться по таким причинам:

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

В рамках методики чистого кода программисты:[11]