Понятие о программном обеспечении

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Объект курсовой работы – программные системы;

Предмет работы – процесс тестирования программного обеспечения.

Главной целью исследования является рассмотрение основных видов тестирования ПО, описание основных его методик.

В соответствии с целью исследования выделим такие задачи:

– охарактеризовать основные понятия о программных средствах;

– рассмотреть архитектуру программных систем;

– рассмотреть основы теории тестирования ПО;

• описать основные подходы и ограничения тестирования;
• на практике рассмотреть последовательность тестирования конкретного ПО выбранным методом.

Курсовая работа выполняется с использованием различных теоретических аксиом, которые раскрывают основные характеристики тестирования ПО.

Рассмотренная проблема описана огромным количеством программистов, проектировщиков ПО, ученых.

1. ТЕОРЕТИЧЕСКИЕ ПОНЯТИЯ О ПРОГРАММНОМ ОБЕСПЕЧЕНИИ

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

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

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

Меняя при этом разное программное обеспечение ПК, можно превращать его работу в рабочее место специалиста:

– конструктора;

– дизайнера;

– ученого;

– бухгалтера;

– финансиста;

– агронома.[3]

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

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

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

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

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

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

Рассмотрим разные понятия, которые связываются с ПО ПК.

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

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

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

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

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

Обычным примером для такого приложения является непосредственно текстовый процессор Word.

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

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

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

Главным понятием, которое применяется в сфере технологий программирования, считается термин «интерфейс».

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

Для ИС особенно важными являются:[3]

– аппаратные интерфейсы – специальные интерфейсы для разных аппаратных устройств (рисунок 1);

Рисунок 1 – Образец аппаратного интерфейса и его структура

– программные интерфейсы применяются для ПО (рисунок 2);

Рисунок 2 – Пример схемы программного интерфейса

– интерфейс для пользователя в программных системах (рисунок 3).[5]

Рисунок 3 – Классы пользовательских интерфейсов

Если программная система имеет:

– один программный интерфейс;

– одни механизмы обработки информации;

– один интерфейс для любого пользователя, то она является интегрированной.

Обычным примером такой интегрированной ПС считают офисную прикладную систему Office.

1.2. Архитектура программных систем

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

В такие архитектуры часто включаются:[8]

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

– соединение выбранных составных частей структуры, поведения в масштабнейших системах;

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

Пример обычной архитектуры программ показан ниже на рисунке 4:[11]

Рисунок 4 – Пример архитектуры ПО

Рассмотрим далее самые характерные особенности для нынешнего программного обеспечения.[18]

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

Известны виды серверов:[20]

– сервер электронной почты;

– Web-сервер;

– сервер ПО;

– сервер БД;

– файл-сервер и др.

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

В нынешних условиях абсолютное большинство их разрабатывается на платформе под названием «.NET», но некоторые программисты создают Интернет-приложения и на ЯП C.

Для использования современного подхода в Интернет-программировании применяются ЯП динамических типов, например:

– JavaScript;

– Ruby;

– Python;

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

Интернет-приложения подразделены на серверные или клиентские.

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

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

Интегрированные программные продукты также могут разрабатывать при помощи различных языков программирования.[2]

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

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

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

В первой части исследования рассматривается понятие программного обеспечения, описаны его основные виды, дана характеристика понятия программных систем, приведены их примеры и особенности.

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

2.1. Определение тестирования ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– модульное;

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

– системное;

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

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

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

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

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

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

– "дымовое";

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

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

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

Самой главной целью данного тестирования надежности (или же стабильности) является возможность применить проверку работоспособности систем при их длительном тестировании на номинальных нагрузках производительности. [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]

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

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

Проектируя код, программисты постоянно запускают его и получают представление о том, как именно он работает, а это помогает им принимать правильные решения.[13]

Два упомянутых правила определяют порядок этапов при программировании на практике:

1. Красный – создать небольшой тест, что не работает, и даже не компилируется.[17]
2. Зеленый – заставить тест работать так, как можно быстрее.
3. Рефакторинг – удаление из написанного кода любое дублирование.

Определенно также существуют задачи, что невозможно решить только с помощью тестов.

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

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

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

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

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

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

Когда условия выполняются, то говорят, что тесты пройдены. Прохождение теста подтверждает также поведение, предполагаемое программистом.

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

Модульные тесты на практике покрывают нетривиальные и критические участки кода.

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

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

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

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

Отметим, что к тестам применяются аналогичные требования стандартов кодирования, что к основному коду.

3.2.Цикл практической разработки через тестирование

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

Рисунок 6 – Блок-схема тестирования

Приведенная последовательность действий базируется на книге К. Бека [4]

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

3.3. Описание преимуществ практического применения разработки ПО с помощью тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

При исследовании были выполнены такие задачи:

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

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

– рассмотрены основы теории тестирования ПО;

• описаны основные методики и ограничения тестирования;
• на практике рассмотрена последовательность тестирования конкретного ПО выбранным методом.

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Агальцов В.П. Тестирование ПО. В 2-х томах. Т.1. / В.П. Агальцов.– М.: ИД ФОРУМ,НИЦ ИНФРА-М,2017.–352 c.
2. Агальцов В.П. Тестирование ПО. В 2-х томах. Т.2..–М.: ИД ФОРУМ,НИЦ ИНФРА-М, 2017.–272 c.
3. Бейзер. Б. Тестирование черного ящика. Технологии функционального тестирования ПО и систем. СПб: Питер, 2014. – 318 с, ил.
4. Бек К. Экстремальное программирование. – СПб.: Питер, 2015. – 224 с., ил.
5. Вигерс К. Разработка требований к программному обеспечению / Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2014. —576с.: ил.
6. Виноградова М.С. Математические методы хранения данных. – М.: МГТУ им. Н.Э. Баумана, 2015. – 125 с.
7. Глухих М.И., Ицыксон В.М. Программная инженерия. Обеспечение качества программных средств методами статического анализа. Учебное пособие. СПб: Изд-во Политехн. ун-та. 2017, 150 с.
8. Голицына О.Л. Тестистрирование. Практикум / О.Л. Голицына, Н.В. Максимов, И.И. Попов. – М.: ФОРУМ: ИНФРА-М, 2017. – 452 с.
9. Голицына О.Л. Тестистрирование БД: Учебное пособие/О.Л.Голицына. - М.:Форум, 2015.– 400 c.
10. Гущин А.Н. Безопасность тестирвоания. М.-Берлин: Директ-Медиа, 2015. – 311 с.
11. Диго С.М. Программные системы. Проектирование и создание. – УМК: ЕАОИ, 2015. – 171 с.
12. Калбертсон Р, Браун К., Кобб Г. Быстрое тестирование: Пер. с англ.. – М.: Издательский дом «Вильямс», 2014.– 384 с.: ил.
13. Коберн А. Современные методы описания функциональных требований к системам. М: Издательство «Лори», 2015. 263 с.: ил.
14. Макарова Н.В. Информатика: Учебник для вузов / Н.В. Макарова, В.Б. Волков. – СПб.: Питер, 2015. – 576 с.
15. Мезенцев К.Н. Автоматизированные информационные системы: учебник для студ. учреждений сред.проф. образования - 4-е изд., стер. - М.: Издательский центр "Академия", 2017. - 176 с.
16. Парников П.А. Тесты ПО и работа с ними. М.: Наука.–2015.–200 с.
17. Савин Роман Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах. М.: Наука.–2017.–324 с.
18. Тамре Л. Введение в тестирование программного обеспечения. СПб: Символ-Плюс, 2015. – 332 с., ил.
19. Фаулер М. Рефакторинг. Улучшение существующего кода. – Пер СПб: Символ-Плюс, 2017. – 432 с., ил.. с англ. –
20. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2015. – 496 с.: ил.