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

Отладка и тестирование программ: основные подходы и ограничения(Виды тестирования)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Предметом исследования является тестирование программ. Целью работы является анализ видов тестирования.

Для реализации поставленной цели необходимо решение следующих задач:

1. Дать основные понятия тестированию и отладки.

2. Рассмотреть уровни тестирования.

3. Охарактеризовать процесс тестирования 4. Разработать программу.

5. Провести анализ литературы по избранной теме.

Основные авторы, в научных работах которых рассматривалась проблема исследования: П.В. Котляров, В. Н. Цыганенко и др.

Глава 1. Автоматизация регрессионного тестирования

1.1.Виды тестирования

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

Нефункциональные тесты.

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

Функциональные требования включают в себя:

Функциональную пригодность.

Точность.

Способность к взаимодействию.

Соответствие стандартам и правилам.

Защищённость.

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

стрессовое тестирование.

тестирование стабильности или надежности.

объемное тестирование.

Тестирование установки.

Тестирования для удобства пользования. Тестирование на отказ и восстановление.

Конфигурационное тестирование. Также существуют виды тестирования, которые связаны с изменениями.

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

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

Регрессионное тестирование.

Дымовое тестирование.

Тестирование сборки.

Санитарное тестирование (проверка согласованности или исправности).Тестирование безопасности. Это тестирование используется для проверки безопасности системы, выявление рисков, которые связаны с обеспечением целостного подхода к защите приложения, также от несанкционированного доступа, вируса, атаки взломщиков [8].

Основные принципы безопасности программного обеспечения. Стратегия безопасности базируется на трех принципах:

Целостность.

Доступность.

Конфиденциальность.

Для определения целостности существует два основных понятия:

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

Доступность. Это требование о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть.

Конфиденциальность.

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

Тестирование взаимодействия. Взаимодействие различных системе, сервисов и приложений друг с другом приобрело значительную актуальность при развитии сетевых технологий и интернета. Любые связанные с этим проблемы могут привести к паданию авторитета компании, вследствие чего произойдут финансовые потери. Эта является одной из самых главных стадий и необходимо подходить к тестированию со всей серьезностью [9].

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

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

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

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

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

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

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

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

Объемное тестирование.

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

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

Тестирование стабильности.

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

Дымовое тестирование, также называется Smoke Test, это минимальный набор тестов, который выявляет явные ошибки. Такой тест выполняется самим программистом и если программа не проходит этот тест, то дальнейшее, более глубокое тестирование уже не имеет смысла. Одним из примеров, является ошибка инсталляции, когда программа не устанавливается, то тестирование не стоит дальше продолжать.

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

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

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

Регрессионное тестирование.

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

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

Значительное сокращение количества дефектов в системе к моменту выпуска программы осуществляется за счет регулярного проведения регрессионного тестирования. Деградация качества системе при росте функциональности полностью исключается.

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

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

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

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

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

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

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

Невозможность отката до предыдущей версии.

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

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

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

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

1.2. Организация процесса тестирования

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

Проверка кода.

Тестирование высокого уровня.

Тестирование низкого уровня.

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

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

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

1.3.Качество программного обеспечения

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

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

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

Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью: - В одном требовании, фактически, содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя»: здесь в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах). - Требование допускает разночтение в силу грамматических особенностей языка (например: «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату»: здесь описаны три разных случая, и это требование стоит разбить на три отдельных требования во избежание путаницы).

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

Типичные проблемы с непротиворечивостью: - Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…»: а как пользователь вошёл в систему, если не имел такого права?). - Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей»: так всё же красной или синей?). - Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…»: разрешение есть у экрана, у окна есть размер). Недвусмысленность (unambiguousness, clearness).

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

Требование атомарно в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью: - Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объёмов данных»: насколько «больших»?)

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

- Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности. Выполнимость (feasibility). Требование технологически выполнимо и может быть реализовано в рамках бюджета и сроков разработки проекта.

Типичные проблемы с выполнимостью: - «Озолочение» (gold plating) — требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей (например: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»).

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

Обязательность, нужность (obligation) и актуальность (up-todate). Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность. Типичные проблемы с обязательностью и актуальностью:

- Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет. - Требованию выставлены неверные значения приоритета по критериям важности и/или срочности. - Требование устарело, но не было переработано или удалено. Прослеживаемость (traceability). Прослеживаемость бывает вертикальной и горизонтальной. Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями и/или матрицы прослеживаемости. 1

Типичные проблемы с прослеживаемостью: - Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрёстных ссылок. - При разработке требований не были использованы инструменты и техники управления требованиями. - Набор требований неполный, носит обрывочный характер с явными «пробелами»

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

Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов). Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений.

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

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

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

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

1. Одной из наиболее активно используемых техник анализа требований является просмотр или рецензирование. Данная техника может быть реализована в форме: - беглого просмотра (показ автором своей работы коллеге; самый быстрый, самый дешёвый и наиболее широко используемый вид просмотра); - технического просмотра (выполняется группой специалистов, каждый из которых представляет свою область знаний: просматриваемый продукт не может считаться достаточно качественным, пока хотя бы у одного просматривающего остаются замечания); - формальной инспекцией (структурированный, систематизированный и документируемый подход к анализу документации, для выполнения которого привлекается большое количество специалистов, само выполнение занимает достаточно много времени, и потому этот вариант просмотра используется достаточно редко).

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

Если хоть что-то в требованиях вызывает непонимание или подозрение – задавайте вопросы.

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

4. Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т.д. Графическое представление удобно одновременно своей наглядностью и краткостью (например, UML-диаграмма классов, занимающая один экран, может быть описана несколькими десятками страниц текста).

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

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

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

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

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

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

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

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

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

Известны два метода сборки модулей:

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

Инкрементальный, характеризующийся пошаговым (помодульным) наращиванием комплекса программ с пошаговым тестированием собираемого комплекса. В инкрементальном методе выделяют две стратегии добавления модулей: o "Сверху вниз" и соответствующее ему нисходящее тестирование. o "Снизу вверх" и соответственно восходящее тестирование.

Глава 2. Отладка и тестирование программы

2.1 Тест – модуль

Тест-план Тест-план (test plan) – документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств. К низкоуровневым задачам планирования в тестировании относятся: - оценка объёма и сложности работ; - определение необходимых ресурсов и источников их получения; - определение расписания, сроков и ключевых точек; - оценка рисков и подготовка превентивных контрмер; - распределение обязанностей и ответственности; - согласование работ по тестированию с деятельностью участников проектной команды, занимающихся другими задачами.

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

- Реалистичность (запланированный подход реально выполним).

- Гибкость (качественный тест-план не только является модифицируемым с точки зрения работы с документом, но и построен таким образом, чтобы при возникновении непредвиденных обстоятельств допускать быстрое изменение любой из своих частей без нарушения взаимосвязи с другими частями). - Согласованность с общим проектным планом и иными отдельными планами (например, планом разработки). Тест-план создаётся в начале проекта и дорабатывается по мере необходимости на протяжении всего времени жизни проекта при участии наиболее квалифицированных представителей проектной команды, задействованных в обеспечении качества. Ответственным за создание тестплана, как правило, является ведущий тестировщик («тест-лид»). В общем случае тест-план включает следующие разделы: - Цель (purpose). Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования, но здесь информация подаётся в ещё более сжатом виде и в контексте того, на что следует обращать первостепенное внимание при организации тестирования и повышения качества). - Области, подвергаемые тестированию (features to be tested).

Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. - Области, не подвергаемые тестированию (features not to be tested). Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной области из списка тестируемых могут быть самыми различными — от предельно низкой их важности для заказчика до нехватки времени или иных ресурсов.

Этот перечень составляется, чтобы у проектной команды и иных заинтересованных лиц было чёткое единое понимание, что тестирование таких-то особенностей приложения не запланировано — такой подход позволяет исключить появление ложных ожиданий и неприятных сюрпризов. - Тестовая стратегия (test strategy) и подходы (test approach). Описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т.д. - Критерии (criteria). Этот раздел включает следующие подразделы:

• Приёмочные критерии, критерии качества (acceptance criteria) — любые объективные показатели качества, которым разрабатываемый продукт должен соответствовать с точки зрения заказчика или пользователя, чтобы считаться готовым к эксплуатации.

• Критерии начала тестирования (entry criteria) — перечень условий, при выполнении которых команда приступает к тестированию. Наличие этого критерия страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

• Критерии приостановки тестирования (suspension criteria) — перечень условий, при выполнении которых тестирование приостанавливается. Наличие этого критерия также страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

• Критерии возобновления тестирования (resumption criteria) — перечень условий, при выполнении которых тестирование возобновляется (как правило, после приостановки).

• Критерии завершения тестирования (exit criteria) — перечень условий, при выполнении которых тестирование завершается. Наличие этого критерия страхует команду как от преждевременного прекращения тестирования, так и от продолжения тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект.

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

• программные ресурсы;

• аппаратные ресурсы;

• человеческие ресурсы;

• временные ресурсы;

• финансовые ресурсы (во многих компаниях финансовые ресурсы могут быть представлены отдельным документом, т.к. являются конфиденциальной информацией). - Расписание (test schedule). Фактически это календарь, в котором указано, что и к какому моменту должно быть сделано. Особое внимание уделяется т.н. «ключевым точкам» (milestones), к моменту наступления которых должен быть получен некий значимый ощутимый результат. - Роли и ответственность (roles and responsibility). Перечень необходимых ролей (например, «ведущий тестировщик», «эксперт по оптимизации производительности») и область ответственности специалистов, выполняющих эти роли. - Оценка рисков (risk evaluation). Перечень рисков, которые с высокой вероятностью могут возникнуть в процессе работы над проектом. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты вы-хода из ситуации. - Документация (documentation).

Перечень используемой тестовой докумен-тации с указанием, кто и когда должен её готовить и кому передавать. - Метрики (metrics). Числовые характеристики показателей качества, которые могут включать описание способов оценки и анализа результата На этот раздел, как правило, формируется множество ссылок из других разделов тест-плана.

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

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

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

Покрытие (coverage) – процентное выражение степени, в которой исследуемый элемент (coverage item) затронут соответствующим набором тест-кейсов. Самыми простыми представителями метрик покрытия можно считать:

- Метрику покрытия требований (требование считается «покрытым», если на него ссылается хотя бы один тест-кейс).

- Метрику плотности покрытия требований (учитывается, сколько тест-кейсов ссылается на несколько требований).

- Метрику покрытия классов эквивалентности (анализируется, сколько классов эквивалентности затронуто тест-кейсами).

- Метрику покрытия граничных условий (анализируется, сколько значений из группы граничных условий затронуто тест-кейсами).

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

2.2. Методика унификации процессов интерпретации программного кода

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

В результате аналитического исследования концепцию модульного программирования можно

сформулировать в виде нескольких понятий и положений.

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

2. Модуль – основа концепции. Каждый модуль в функциональной декомпозиции представляет собой “чёрный ящик” с одним входом и одним выходом.

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

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

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

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

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

Многие современные компьютерные приложения используют модули, написанные на разных языках программирования. И интеграция этих модулей – деликатная операция. В первую очередь требуется наличие договоренностей, чтобы дать возможность программистам обозначить «сторонние» сущности как объекты или функции, а также связанные с ними типы данных. Необходимо обеспечить возможность создания иерархических структур, и правильного передачи данных: ссылок, указателей, если потребуется. Также необходимо перевести то, чем будут часто пользоваться программисты на уровень интерфейсов, вплоть до спецификации ABI (Application Binary Interfaces, Двоичный интерфейс приложения).

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

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

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

Процесс связывания программного кода разных языков программирования имеет явно выраженный комплексный характер и включает ряд основных этапов:

1) разделение обязанностей языковых процессоров на внутренние и внешние;

2) создание механизмов работы с данными: общих переменных, функций, создание механизмов передачи данных: контекст, стек значений, создание объектов, контролирующих процесс разбора кода.

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

1. Рассмотрены существующие средства связывания данных: технология CORBA, инструмент SWIG, язык QtScript, рассмотрены способы хранения абстрактных данных в фреймворке Qt. Рассмотрены объекты типа QVariant, их создание, конвертирование, копирование. Возможность хранения в контейнерах других контейнеров.

2. Рассмотрены основные принципы разделения процесса разбора кода на отдельные этапы, а также особенности каждого этапа.

Универсальный доступ к процессам интерпретации может быть обеспечен путем выделения общих частей программного модуля в отдельный блок – внешний интерфейс – front-end. При разработке программного модуля «Универсальный командный интерпретатор», таким блоком стала библиотека SmMultiScriptFrontEnd.

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

1. Мультиязыковое программирование – формализм, доступный для обозначения и использования “сторонних” объектов других языков, а также инфраструктура для работы с такими объектами. Этот термин вводят Cyrille Comar, Matthew Gingell, Olivier Hainque, Javier Miranda в статье “Multi-Language Programming: The Challenge and Promise of Class-Level Interfacing”[6].

2. Фреймворк Qt - кросплатформенный инструментария разработки ПО на языке программирования C++. Этот фреймворк обладает встроенным интерпретатором JavaScript, который позволяет интегрировать код на данном языке в нативный код на языке C++. Два основных аспекта мультиязыкового программирования – это формализм, доступный для обозначения и использования “сторонних” объектов других языков, а также инфраструктура для работы с такими объектами. Взаимодействие может охватывать различные аспекты, такие как доступ к сторонним данным, представление сторонних типов, вызовы сторонних подпрограмм, обработка сторонних событий, таких как исключения, и повторное использование иерархий классов объектов. В любом случае, взаимодействие всегда подразумевает соглашение между заинтересованными сторонами. Например, вызов подпрограммы будет работать правильно только тогда, когда вызывающий и вызываемый договорились о том, как передаются аргументы (в каком порядке, используя какие вычислительные ресурсы), кто размещает, удаляет ту или иную часть стека, как работает указатель стека, и т.д.

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

В качестве первого примера, Справочное руководство Ada включает в себя полное приложение, посвященное этому вопросу, охватывающее взаимодействие с C, Cobol, Fortran и позволяющее реализовать поддержку других языков.

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

• директива Import, чтобы загрузить объект, определенный на стороннем языке в программу на Ada, таким образом, позволяя подпрограммам, написанным на стороннем языке, быть вызванным из Ada;

• директива Export, чтобы экспортировать объект Ada стороннему языку;

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

• директива Linker Options, чтобы задать параметры системы, необходимые при компоновке программы.

В процесс включается для вызова функции, написанной на C, из Ada, чтобы распечатать числовое значение, находящееся в указанном адресе. Там используется стандартный пакет Interfaces. C для получения доступа к типу в Ada, соответствующему типу int, объявляет подпрограмму Ada для перевода сервисов C, и импортирует сервис с помощью директивы Import. Последняя говорит компилятору, что подпрограмма является внешней с соглашением C и устанавливает, какой символ (имя связи) должен быть использован, чтобы обратиться к ней with Interfaces.C; use__. Проблема связывания программного кода разных языков программирования явно выраженный комплексный характер и включает ряд основных этапов:

• разделение обязанностей языковых процессоров на внутренние и внешние;

• создание механизмов работы с данными: общих переменных, функций, создание механизмов передачи данных: контекст, стек значений, создание объектов, контролирующих процесс разбора кода.

В работе проведён анализ существующих инструментов, использующих или описывающих унификацию данных и процессов разбора программного кода. В результате проведённого анализа были получены следующие результаты [6]:

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

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

В процессе разработки и исследований получены следующие научные результаты:

1. Поставлена проблема универсальной интерпретации программного кода.

2. Предложена новая методика для универсальной интерпретации программного кода.

3. Разработан программный модуль «Универсальный командный интерпретатор» (ПМ УКИ).

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ЛИТЕРАТУРЫ

Абросимова, М.А. Информационные технологии в государственном и муниципальном управлении: Учебное пособие / М.А. Абросимова. - М.: КноРус, 2013. - 248 c.
Акперов, И.Г. Информационные технологии в менеджменте: Учебник / И.Г. Акперов, А.В. Сметанин, И.А. Коноплева. - М.: НИЦ ИНФРА-М, 2013. - 400 c.
Атьков, О.Ю. Персональная телемедицина. Телемедицинские и информационные технологии реабилитации и управления здоровьем / О.Ю. Атьков, Ю.Ю. Кудряшов. - М.: Практика, 2015. - 248 c.
Афонин, П.Н. Информационные таможенные технологии: Учебник / П.Н. Афонин. - СПб.: Троицкий мост, 2012. - 352 c.
Альфред В. Ахо. Компиляторы: принципы, технологии и инструментарий, 2-е изд.: Пер. с англ. / Ахо, Альфред В., Лам, Моника С., Сети, Рави, Ульман, Джеффри Д. – М.: ООО “И.Д. Вильямс” 2015. - 1184 с.
Гагарина Л.Г., Киселев Д.В., Федотова Е.Л. Разработка и эксплуатация автоматизированных информационных систем: учеб. пособие / под ред. проф. Л.Г. Гагариной М.: ИД ФОРУМ: ИНФРА-М, 2014, 384 с.
Гамма. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес – СПб., 2010.
Истомин Е.П. Высокоуровневые методы информатики и программирования: Учебник / Е.П. Истомин, В.В. Новиков, М.В. Новикова - СПб. ООО «Андреевский издательский дом» 2006 г. - 228 с.
Э. Таненбаум. Распределенные системы: принципы и парадигмы / Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. - 877 с.
Дж. Хопкрофт Введение в теорию автоматов, языков и вычислений, 2-е изд. /
Хопкрофт, Джон, Э., Мотвани, Раджив, Ульман, Джеффри, Д. - М. Издательский дом «Вильямс», 2002. - 528 с.
Федотова Е.Л. Информационные технологии и системы: учеб. пособие. - М.: ИД ФОРУМ: ИНФРА-М, 2009, 352 с.
Федотова Е.Л., Федотов А.А. Информатика. Курс лекций / Е.Л. Федотова, А.А. Федотов учеб. пособие. - М.: ИД ФОРУМ: ИНФРА-М, 2011, 480 с.
Федотова Е.Л., Портнов Е.М. Прикладные информационные технологии. учеб. пособие. - М.: ИД ФОРУМ: ИНФРА-М, 2013, 365 с. Щипицина, Л.Ю. Информационные технологии в лингвистике: Учебное пособие / Л.Ю. Щипицина. - М.: Флинта, 2015. - 128 c.
Ээльмаа, Ю.В. Информационные технологии на уроках литературы: Пособие для учителей общеобр. учреждений / Ю.В. Ээльмаа, С.В. Федоров. - М.: Просв., 2012. - 176 c.
Ясенев, В.Н. Информационные системы и технологии в экономике: Учебное пособие для студентов вузов / В.Н. Ясенев. - М.: ЮНИТИ-ДАНА, 2012. - 560 c.