Разработка приложения, реализующего метод Флойда : Курсовая работа (т) по Информационное обеспечение, программирование

Рубрикатор

Информационное обеспечение, программирование

Курсовые работы (т)

Разработка приложения, реализующего метод Флойда

Содержание

Введение

. Общая часть

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

.2 Жизненный цикл прикладной программы

.3 Методология и технология разработки ПП

.4 Тестирование программных средств

.5 Описание прикладной задачи

. Специальная часть

.1 Цели разработки

.2 Расчет математической модели

.3 Описание программы

.3.1 О программе

.3.2 Алгоритм работы программы

.3.3 Входные данные

.3.4 Выходные данные

.4 Тестирование программы

.5 Руководство пользователя

Заключение

Литература

Введение

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

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

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

А теперь? Компьютер есть в каждом третьем доме и настолько любим и привычен, что считается едва ли не членом семьи. Что такое компьютер, знает сейчас каждый (во всяком случае, слышали о компьютерах и видели их все). Но из-за своей обыденности и сравнительной доступности компьютер не стал менее удивительным! Он вобрал в себя все достижения современной цивилизации и постепенно превращается в универсальное устройство, способное с успехом выполнять множество функций.

В деловом мире компьютеры в буквальном смысле совершили революцию.

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

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

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

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

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

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

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

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

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

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

1. Общая часть

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

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

аппаратная часть компьютеров и сетей ЭВМ.

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

·драйверы устройств - это программы, предназначенные для управления устройствами компьютера;

·оболочки ОС предназначены для обеспечения "диалога" пользователя с ОС;

·служебные или сервисные программы (от англ. to serve - обслуживать) - это установленные дополнительно программы, предназначенные для:

·диагностики работоспособности компьютера;

·защиты от вирусов;

·обслуживания дисков;

·архивации данных и т.д.

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

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

Программное обеспечение вычислительных сетей включает три основных "слоя":

·общее программное обеспечение, образуемое базовым ПО отдельных ЭВМ, входящих в состав сети;

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

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

-технология разработки программ;

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

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

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

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

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

·повышение производительности труда программистов при написании и контроле программ;

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

·создание программ коллективом разработчиков;

·окончание создания программ в заданный срок.

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

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

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

Первым языком программирования, в котором были предложены принципы объектной ориентированности, была Симула. В момент своего появления (в 1967 году), этот язык программирования предложил поистине революционные идеи: объекты, классы, виртуальные методы и др., однако это всё не было воспринято современниками как нечто грандиозное. Тем не менее, большинство концепций были развиты Аланом Кэйем и Дэном Ингаллсом в языке Smalltalk. Именно он стал первым широко распространённым объектно-ориентированным языком программирования.

В настоящее время количество прикладных языков программирования (список языков), реализующих объектно-ориентированную парадигму, является наибольшим по отношению к другим парадигмам. В области системного программирования до сих пор применяется парадигма процедурного программирования, и общепринятым языком программирования является язык C. Хотя при взаимодействии системного и прикладного уровней операционных систем заметное влияние стали оказывать языки объектно-ориентированного программирования. Например, одной из наиболее распространенных библиотек мультиплатформенного программирования является объектно-ориентированная библиотека Qt, написанная на языке C++.

Операционная система. Состав и назначение.

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

Однопрограммный режим.

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

Многозадачный режим.

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

Назначение операционной системы.

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

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

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

Системы программирования.

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

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

На данный момент существует десятки систем программирования:

·Microsoft Visual Basic.

Microsoft Visual Basic - средство разработки программного обеспечения, разрабатываемое корпорацией Microsoft и включающее язык программирования и среду разработки. Язык Visual Basic унаследовал дух, стиль и отчасти синтаксис своего предка - языка Бейсик, у которого есть немало диалектов. В то же время Visual Basic сочетает в себе процедуры и элементы объектно-ориентированных и компонентно-ориентированных языков программирования. Среда разработки VB включает инструменты для визуального конструирования пользовательского интерфейса.Basic считается хорошим средством быстрой разработки прототипов программы, для разработки приложений баз данных и вообще для компонентного способа создания программ, работающих под управлением операционных систем семейства Microsoft Windows.

Первое признание серьёзными разработчиками Visual Basic получил после выхода версии 3 - VB3. Окончательное признание как полноценного средства программирования для Windows - при выходе версии 5 - VB5. Версию VB6, входящую в состав Microsoft Visual Studio 6.0, стала по-настоящему зрелым и функционально богатым продуктом. Visual Basic .NET не позволяет программировать по-старому, ибо, по сути, является совершенно другим языком, таким же, как и любой другой язык программирования для платформы.NET. Индивидуальность языка, так же как и его преимущества (простота, скромность создания программ, лёгкость использования готовых компонент) при использовании в среде.NET не имеют такого значения, как раньше - всё сосредоточено на возможностях самой системы.NET, на её библиотеке классов. Поэтому сегодня нужно говорить о классическом Visual Basic, его диалектах Visual Basic for Applications (VBA) и Visual Basic Scripting Edition (VBScript) и о языке для платформы (4, 467) .NET - Visual Basic .NET.

Основные разновидности Visual Basic:

. Классический Visual Basic (версии 5-6).Этот язык очень сильно привязан к своей среде разработки и к операционной системе Windows, являясь исключительно инструментом написания Windows-приложений. Привязка к среде заключается в том, что существует большое количество средств, предназначенных для помощи и удобства программирования: встроенный отладчик, просмотр переменных и структур данных на лету, окно отладки, всплывающая подсказка при наборе текста программы (Intellisense). Все эти преимущества делают бесполезным и даже невозможным использование Visual Basic вне среды разработки, например в обычном текстовом редакторе.

2. Visual Basic for Applications (VBA) Это средство программирования, практически ничем не отличающееся от классического Visual Basic, которое предназначено для написания макросов и других прикладных программ для конкретных приложений.

. Visual Basic Scripting Edition (VBScript).Скриптовый язык, являющийся несколько усечённой версией обычного Visual Basic. Используется в основном для автоматизации администрирования систем Windows, а также для создания страниц ASP и сценариев для Internet Explorer.

·Turbo Pascal.

Turbo Pascal - Интегрированная среда разработки программного обеспечения для платформ DOS и Windows 3.x и язык программирования в этой среде, диалект языка Паскаль от фирмы Borland.

Товарный знак Borland Pascal был зарезервирован для дорогих вариантов поставки (с бо?льшим количеством библиотек и исходным кодом стандартной библиотеки), оригинальная дешёвая и широко известная версия продавалась как Turbo Pascal. Название Borland Pascal также используется в более широком смысле - как неофициальное название версии языка Паскаль от фирмы Borland. (1, 4). Turbo Pascal - это среда разработки для языка программирования Паскаль. Используемый в Turbo Pascal диалект базировался на более раннем UCSD Pascal, получившем распространение, в первую очередь, на компьютерах серии Apple.Компилирующая компонента Turbo Pascal была основана на компиляторе Blue Label Pascal, первоначально созданном в 1981 году Андерсом Хейлсбергом для операционной системы NasSys микрокомпьютера Nascom. Позднее он был переписан как Compass Pascal для операционной системы CP/M, затем как Turbo Pascal для DOS и CP/M. Одна из версий Turbo Pascal была доступна под Apple Macintosh примерно с 1986 года, но её разработка прекратилась примерно в 1992 году (5, 134).

В 1982 году Филипп Кан приобрёл компилятор у Андерса Хейлсберга и перебрался из Парижа в Калифорнию, где основал компанию Borland.

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

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

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

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

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

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

С начала 1990-х TP/BP используется в университетах для изучения фундаментальных концепций программирования.

Вероятно, разработка Microsoft Pascal была прекращена из-за конкуренции с высоким качеством и небольшой ценой Turbo Pascal. Другая версия гласит, что Borland заключил соглашение с Microsoft на прекращение разработки Turbo BASIC (среды разработки для BASIC, ответвившейся от Turbo Pascal), если Microsoft прекратит разработку Microsoft Pascal. Некоторое время Microsoft выпускал QuickPascal, который был почти 100%-совместим с Turbo Pascal.

В течение нескольких лет Borland улучшал не только среду разработки, но и язык. В версии 5.5 в него были введены передовые возможности объектно-ориентированного программирования. Последней выпущенной версией была версия 7. Borland Pascal 7 включал в себя среду разработки и компиляторы для создания программ под DOS, под DOS с расширителем DOS и Windows 3.x, в то время как Turbo Pascal 7 мог создавать только обычные DOS-программы.

С 1995 года в Borland прекратили разработку Turbo Pascal и предложили в качестве замены среду разработки Delphi. Новая версия языка подверглась изменению (в особенности ООП), и языку вернулось изначальное название, закреплённое разработчиками Apple Object Pascal. Старая объектная модель Turbo Pascal и соответствующий синтаксис поддерживался как устаревший, использование обеих объектных моделей одновременно в одной и той же программе не поддерживается.

Достоинства Turbo Pascal:

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

)Контекстная справочная система, по которой можно изучать язык без обращения к сторонним источникам.

2)Высокая скорость компиляции, высокая скорость выполнения откомпилированных программ.

)Встроенная возможность использовать вставки на языке ассемблера.

Недостатки:

)Компилятор рассчитан на реальный режим DOS, применение которого сходит на нет. Однако в последних версиях компилятора и среды введена поддержка защищённого режима вместе с соответствующим отладчиком (TD).

)В модуле CRT имеется ошибка (некорректный подсчёт количества циклов для функции delay, не рассчитанный на быстрые процессоры, процессоры с переменной частотой и многозадачные среды), из-за которой при запуске программы на компьютерах с тактовой частотой более 200 MHz сразу происходило аварийное завершение с сообщением "Runtime error 200 at…". Существуют разные варианты исправления модуля CRT. В варианте Клауса Хартнегга ошибка 200 не возникает, но длительность Delay на быстрых компьютерах меньше желаемой, и эта проблема по незнанию иногда тоже считается недостатком Turbo Pascal.

·C++ Builder.

C++ Builder - программный продукт, инструмент быстрой разработки приложений (RAD), интегрированная среда программирования (IDE), система, используемая программистами для разработки программного обеспечения на языке C++. C++ Builder объединяет в себе комплекс объектных библиотек (STL, VCL, CLX, MFC и др.), компилятор, отладчик, редактор кода и многие другие компоненты. Цикл разработки аналогичен Delphi. Большинство компонентов, разработанных в Delphi, можно использовать и в C++ Builder без модификации, но, к сожалению, обратное утверждение не верно.++ Builder содержит инструменты, которые при помощи drag-and-drop действительно делают разработку визуальной, упрощает программирование благодаря встроенному WYSIWYG - редактору интерфейса и пр.++ Builder первоначально создавалась только для платформы Microsoft Windows. Поздние версии, содержащие Кроссплатформенную компонентную библиотеку Borland, основанную на Qt, поддерживают и Windows и Linux. (8, 991).

В 2003 Borland выпустила C++ BuilderX (CBX), написанный при помощи той же инфраструктуры, что и JBuilder, который при этом был мало похож на C++ Builder или Delphi. Этот продукт предназначался для разработки больших программ для крупных предприятий, но коммерческого успеха не достиг. В конце 2004 года Borland объявила, что продолжит развитие классического C++ Builder и объединит его со средой разработки Delphi, прекратив, таким образом, разработку C++ BuilderX.

Спустя примерно год после этого объявления, Borland выпустила Borland Developer Studio 2006, который включал в себя Borland C++ Builder 2006, предлагавший улучшенное управление конфигурацией и отладкой. Borland Developer Studio 2006 - единственный полноценный комплект, содержащий Delphi, C++Builder и C#Builder.

В 2007 CodeGear выпустила C++ Builder 2007, в котором реализовала полную поддержку API Microsoft Windows Vista, увеличила полноту соответствия стандарту ANSI C++, увеличила скорость компиляции и сборки до 500 %, включила поддержку MSBuild, архитектур баз данных DBX4 и "VCL для Web", поддеживающий AJAX. Поддержка API Microsoft Windows Vista включила в себя приложения, изначально оформленные в стиле Vista, и естественную поддержку VCL для Aero и Vista Desktop. CodeGear RAD Studio 2007 содержит C++ Builder 2007 и Delphi. Также в 2007 CodeGear "воскресила" марку "Turbo" и выпустила две "Turbo" версии C++ Builder: Turbo C++ Professional и Turbo C++ Explorer (бесплатный), основанных на Borland C++ Builder 2006.

В конце 2008 года компания CodeGear выпустила новую версию RAD Studio, в которую вошли Delphi 2009 и С++ Builder 2009.

Следующая версия, CodeGear C++Builder (кодовое имя "Commodore"), будет обладать поддержкой x86-64 и возможностью создавать нативный x86-64 код.

Таблица 1 - Краткие сведения о версиях продукта

ГодВерсия19971199831999420005200262003X2005200620072007Сентябрь 2008200925 августа 20092010

·Symantec Café.

Язык Java является принципиально новым языком программирования, созданным компанией Sun Microsystems для создания многоплатформных приложений (applications и applets) для страниц "всемирной паутины" сети Internet. Язык Java может быть назван упрощенным вариантом C++, без усложненных конструкций и дополнительных возможностей. Java предлагает широкие возможности объектно-ориентированного программирования и повторного использования кода.Cafe является первой интегрированной средой визуальной разработки для создания приложений (applications и applets) для страниц "всемирной паутины" сети Internet (3, 265).Cafe интегрирует комплект разработчика Java Development Kit компании Sun Microsystems в популярную многооконную среду визуальной разработки, созданную компанией Symantec для создания приложений для Windows 95 и Windows NT. Symantec Cafe предлагает полнофункциональную систему управления проектами, а также мощные инструменты редактирования и просмотра кода, что обеспечивает резкое увеличение эффективности разработки приложений на языке Java для сети Internet. Приложения, созданные с помощью Symantec Cafe могут затем встраиваться в документы HTML и выполняться на различных платформах при использовании Java-соместимых программ просмотра, таких как Netscape Navigator.Cafe позволяет разрабатывать приложения на языке Java, которые могут затем встраиваться в страницы всемирной паутины для обеспечения более высокой функциональности, чем существующие HTML-страницы. Java-компилятор генерирует байткод, который может затем встраиваться в HTML-определения страниц всемирной паутины. Наиболее популярные программы просмотра в сети Internet, такие Netscape Navigator, включают встроенный интерпретатор Java-байткода, позволяющий выполнять Java-приложения на компьютере пользователя во время просмотра страницы Internet, содержащей это Java-приложение.

Это дает возможность включать в Internet страницу программное обеспечение, что предлагать пользователю гораздо более богатые возможности, по сравнению с просто текстом или статической графикой. Например, существует возможность включить новый тип данных и назначить соответствующий ей Java-байткод, предназначенный специально для обработки этого типа информации на клиентской машине. Кроме того, в этом случае Java-приложение запускается на клиентской машине, что позволяет снижать загрузку web-сервера. В результате достигается более высокая функциональность и производительность при просмотре сетей Internet. Cafe позволяет разрабатывать любые виды многоплатформенных приложений (applets and applications). Сокращенное приложение (applets) представляет собой ограниченная версия полнофункционального Java-приложения (applications), предназначенного для работы с web-документами. Например, сокращенное приложение не имеет доступа к файлам на клиентском компьютере. Такой подход предназначен, с одной стороны, для обеспечения целостности созданных Java-приложений при загрузке их из Internet, а с другой - для того, чтобы избежать случайной потери информации на клиентской машине вследствие работы загруженного из Internet приложения. Полнофункциональные Java-приложения более похожи на стандартные программы, за исключением того, что они многоплатформенны и могут запускаться под Windows, Macintosh и Unix. Основные возможности Symantec Café: Cafe выполняет "на лету" грамматический разбор Java-код и создает репозиторий информации о Java-приложениях и Java-библиотеках классов. Это позволяет пользователю наглядно иерархию классов Java-приложения, лучше понять стандартные классы Java и классы Java-приложений. Class Editor позволяет просматривать исходный текст на языке Java, а также просматривать/редактирования методы, данные и классы. Class Editor позволяет разработчику работать с объектно-ориентированными частями Java-программы в противоположность работы с исходными текстами.

1.ProjectExpress, "Wizard"-подобный инструмент, позволяющий быстро создавать проекты вокруг набора Java-программ и использовать преимущества Cafe с минимальными затратами.

2.AppExpress, "Wizard"-подобный инструмент, помогающий начать работу разработчикам, не знакомым с языком Java. AppExpress автоматически

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

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

.Cafe включает полностью интегрированный комплект разработчика Java Development Kit (JDK) компании Sun, с графической поддержкой опций и параметров Java-компилятора, интерпретатора и отладчика. Кроме того, Cafe поддерживает управление вложенными проектами, а также возможность построения Java-приложений, как сокращенных, так и полнофункциональных, непосредственно из среды разработчика.

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

Для создания Java приложения необходимо запустить AppExpress из меню "Tools", указать тип приложения в поле "Java Applet", определить каталог для создания приложения и нажать кнопку "Finish". Это все, что необходимо сделать. Проект приложения на языке Java автоматически загрузится средой Cafe.

Чтобы построить и запустить Java-приложение, нужно выбрать команду "Run" из меню "Project". Cafe попросит подтвердить необходимость построения проекта. Выберите "Yes" и Java приложение будет построено. Созданное приложение доступно для расширения и модификации.имеет удобный "Wizard"-подобный инструмент ProjectExpress, позволяющий легко создавать новые проекты. Cafe позволяет просто и быстро импортировать уже существующий Java-код или проект в Cafe с минимальными затратами. Используя ProjectExpress, можно определить тип проекта Java или С/C++, затем добавить указание на файлы с исходным текстом и проект автоматически будет создан и загружен в Cafe.поддерживает вложенную организацию проектов, что значительно сокращает затраты времени на организацию и управление созданием приложений для Internet. Cafe Project Manager может управлять проектами с различными опциями и вершинами без необходимости загрузки или выгрузки того или иного проекта.

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

Входящая в Cafe программа просмотра классов Class Editor позволяет быстро проектировать и перемещаться по исходному коду Java-приложения за счет мощных встроенных инструментов навигации. Class Editor позволяет отказаться от работы с индивидуальными индивидуальными классами Java и работать напрямую с определениями и членами классов Java.Editor позволяет быстро перемещаться к любому участку кода Java приложения. Достаточно ввести или указать нужное имя класса и/или члена, и в соответствующем окне появится его исходный код. Этот же метод действует при определении принадлежности того или иного класса или метода. Class Editor позволяет также быстро создавать новые классы и добавлять Новые члены классов.предлагает разработчикам профессиональный редактор, поддерживающий выделение цветом синтаксических конструкций и ключевых слов. Кроме того, редактор включает макроязык для расширения возможностей редактирования и может перемещаться к любому участку описания Java-кода в Java-приложении или Java-классах.

·Php (Personal Home Page).

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

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

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

Истоки PHP лежат в старом продукте, имевшем название PHP/FI. PHP/FI был создан Расмусом Лердорфом в 1995 году и представлял собой набор Perl-скриптов для ведения статистики посещений его резюме. Развитие web еще только начиналось, никаких специальных средств для решения этих задач не было, и к автору хлынул поток сообщений с вопросами. Лердорф начал бесплатно раздавать свой инструментарий, названный "Personal Homepages Tools" (PHP) - ("Инструменты для персональных домашних страниц"). Очень скоро потребовалась большая функциональность и Расмус пишет новую, намного более обширную версию на C, работающую с базами данных и позволяющую пользователям разрабатывать простейшие web-приложения.

Расмус Лердорф решил выложить исходный код PHP/FI на всеобщее обозрение, исправление ошибок и дополнение./FI (Personal Home Page / Forms Interpreter - Персональная Домашняя страница / Интерпретатор Форм) включал в себя базовую функциональность сегодняшнего PHP. Он имел переменные в стиле Perl, автоматическую интерпретацию форм и возможность встраиваться в html-код. Собственно синтаксис языка имел много общего с Perl, хотя и был намного проще и ограниченнее.

В 1997 выходит PHP/FI 2.0. Вторая версия C-имплементации обозначила группу пользователей: несколько тысяч людей по всему миру, с примерно 50,000 доменами, что составляло около 1% всего числа доменов Интернета. Несмотря на то, что разработкой занималось уже несколько людей, PHP/FI 2.0 все еще оставался крупным проектом одного человека.

Официально PHP/FI 2.0 вышел только в ноябре 1997 года, после проведения большей части своей жизни в бета-версиях. Вскоре после выхода его заменили альфа-версии PHP 3.0..3.0 была первой версией, напоминающей PHP, каким мы знаем его сегодня. В 1997 году Энди Гутманс (Andi Gutmans) и Зив Сураски (Zeev Suraski) переписали код с начала: разработчики сочли PHP/FI 2.0 не пригодным для разработки приложения электронной коммерции, над которым они работали для проекта Университета. Для совместной работы над PHP 3.0 с помощью базы разработчиков PHP/FI 2.0 Энди, Расмус и Зив решили объединиться и объявить PHP 3.0 официальным преемником PHP/FI, разработка же PHP/FI была практически полностью прекращена.

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

Абсолютно новый язык программирования получил новое имя. Разработчики отказались от дополнения о персональном использовании, которое имелось в аббревиатуре PHP/FI. Язык был назван просто 'PHP' - аббревиатура, содержащая рекурсивный акроним: 'PHP: Hypertext Preprocessor' (PHP: Препроцессор Гипертекста).

Первая статья о PHP была опубликована в чешском варианте 'Computerworld' весной 1998 и освещала PHP 3.0. Как и в случае с книгами, эта была первая в серии статья из множества посвященных PHP и опубликованных в различных известных журналах.

К концу 1998, PHP использовался десятками тысяч пользователей. Сотни тысяч web-сайтов сообщали о том, что они работают с использованием языка. В то время PHP 3.0 был установлен приблизительно на 10% серверах Интернета!3.0 был официально выпущен в июне 1998 года после 9 месяцев публичного тестирования..

К зиме 1998 года, практически сразу после официального выхода PHP 3.0, Энди Гутманс и Зив Сураски начали переработку ядра PHP. В задачи входило увеличение производительности сложных приложений и улучшение модульности базиса кода PHP. Расширения дали PHP 3.0 возможность успешно работать с набором баз данных и поддерживать большое количество различных API и протоколов, но PHP 3.0 не имел качественной поддержки модулей и приложения работали не эффективно.

Новый движок, названный 'Zend Engine' (от имен создателей: Zeev и Andi), успешно справлялся с поставленными задачами и впервые был представлен в середине 1999 года. PHP 4.0, основанный на этом движке и принесший с собой набор дополнительных функций, официально вышел в мае 2000 года, почти через два года после выхода своего предшественника PHP 3.0. В дополнение к улучшению производительности, PHP 4.0 имел еще несколько ключевых нововведений, таких как поддержка сессий, буферизация вывода, более безопасные способы обработки вводимой пользователем информации и несколько новых языковых конструкций.

Сегодня PHP используется сотнями тысяч разработчиков. Миллионы (!) сайтов сообщают о работе с PHP. Эти, а также многие другие факты, позволяют с уверенностью сказать, что PHP является одним из самых популярных языков web-программирования!

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

Недавно вышла новая, пятая версия PHP (PHP5). PHP5 использует новую версию "движка" Zend - Zend Engine 2.

В PHP5 объектная модель была значительно переработана. При этом было добавлено много новых возможностей, благодаря которым PHP5 получил некоторые черты таких объектно-ориентированных языков, как C++ и Java.

Изменения коснулись производительности встроенных стандартных функций PHP. По некоторым оценкам, скорость работы стандартных функций в PHP5 увеличилась на 40% и более.

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

Поддержка XML в версии PHP5 стала полной, поддерживаются новые расширения DOM и XML.

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

Архитектура x86.

Ассемблеры для DOS.

Наиболее известными ассемблерами для операционной системы DOS являлись Borland Turbo Assembler (TASM) и Microsoft Macro Assembler (MASM). Также в своё время был популярен простой ассемблер A86.

Изначально они поддерживали лишь 16-битные команды (до появления процессора Intel 80386). Более поздние версии TASM и MASM поддерживают и 32-битные команды, а также все команды, введённые в более современных процессорах, и системы команд, специфических для конкретной архитектуры (такие как, например, MMX, SSE, 3DNow! и т. д.).

Microsoft Windows.

При появлении операционной системы Microsoft Windows появилось расширение TASM, именуемое TASM32, позволившее создавать программы для выполнения в среде Windows. Последняя известная версия Tasm - 5.3, поддерживающая инструкциии MMX, на данный момент включена в Turbo C++ Explorer. Но официально развитие программы полностью остановлено.поддерживает свой продукт под названием Microsoft Macro Assembler. Она продолжает развиваться и по сей день, последние версии включены в наборы DDK. Но версия программы, направленная на создание программ для DOS, не развивается. Кроме того, Стивен Хатчессон создал пакет для программирования на MASM под названием "MASM32".

GNU и GNU/Linux.

В состав операционной системы GNU входит компилятор gcc, включающий в себя ассемблер gas (GNU Assembler), использующий AT&T синтаксис, в отличие от большинства других популярных ассемблеров, которые используют Intel-синтаксис.

Переносимые ассемблеры. Также существует открытый проект ассемблера, версии которого доступны под различные операционные системы, и который позволяет получать объектные файлы для этих систем. Называется этот ассемблер NASM (Netwide Assembler).это переписанная с нуля версия NASM под лицензией BSD (с некоторыми исключенями).(Flat Assembler) - молодой ассемблер под модифицированной для запрета перелицензирования (включая под GNU GPL) BSD?лицензией. Есть версии для KolibriOS, GNU/Linux, MS-DOS и Microsoft Windows, использует Intel-синтаксис и поддерживает инструкции AMD64.

Архитектуры RISC...

На данный момент существуют 2 компилятора производства Atmel (AVRStudio 3 и AVRStudio4). Вторая версия - попытка исправить не очень удачную первую. Так же ассемблер есть в составе WinAVR.

Ассемблирование и компилирование.

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

Язык ассемблера.

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

Содержание языка.

Команды языка ассемблера один в один соответствуют командам процессора и, фактически, представляют собой удобную символьную форму записи (мнемокод) команд и их аргументов. Также язык ассемблера обеспечивает базовые программные абстракции: связывание частей программы и данныx через метки с символьными именами (при ассемблировании[1] для каждой метки высчитывается адрес, после чего каждое вхождение метки заменяется на этот адрес) и директивы[2].

Директивы ассемблера позволяют включать в программу блоки данных (описанные явно или считанные из файла); повторить определённый фрагмент указанное число раз; компилировать фрагмент по условию; задавать адрес исполнения фрагмента, отличный от адреса расположения в памяти [уточнить!]; менять значения меток в процессе компиляции; использовать макроопределения с параметрами и др.

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

Достоинства:

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

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

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

)Последние технологии безопасности, внедряемые в операционные системы, не позволяют делать самомодифицирующегося кода, так как исключают одновременную возможность исполнения инструкций и запись в одном и том же участке памяти (технология W^X в BSD-системах, DEP в Windows).

Недостатки:

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

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

)Непереносимость на другие платформы (кроме двоично совместимых).

Применение.

Напрямую вытекает из достоинств и недостатков.

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

быстродействие (драйверы);

размер кода (загрузочные сектора, программное обеспечение для микроконтроллеров и процессоров с ограниченными ресурсами, вирусы, программные защиты);

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

Связывание ассемблерного кода с другими языками.

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

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

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

Синтаксис.

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

Инструкции.

Общий формат записи инструкций одинаков для обоих стандартов: [метка:] опкод [операнды] [;комментарий], где опкод - непосредственно мнемоника инструкции процессору. К ней могут быть добавлены префиксы (повторения, изменения типа адресации и пр.).

В качестве операндов могут выступать константы, названия регистров, адреса в оперативной памяти и пр. Различия между стандартами Intel и AT&T касаются, в основном, порядка перечисления операндов и их синтаксиса при различных методах адресации.

Используемые мнемоники обычно одинаковы для всех процессоров одной архитектуры или семейства архитектур (среди широко известных - мнемоники процессоров и контроллеров Motorola, ARM, x86). Они описываются в спецификации процессоров. Возможные исключения:

Если ассемблер использует кроссплатформенный AT&T-синтаксис (оригинальные мнемоники приводятся к синтаксису AT&T)

Если изначально существовало два стандарта записи мнемоник (система команд была наследована от процессора другого производителя).

Например, процессор Zilog Z80 наследовал систему команд Intel i8080, расширил ее и поменял мнемоники (и обозначения регистров) на свой лад. Например сменил интеловские mov[4] на ld. Процессоры Motorola Fireball наследовали систему команд Z80, несколько её урезав. Вместе с тем, Motorola официально вернулась к мнемоникам Intel. И в данный момент половина ассемблеров для Fireball работает с интеловскими мнемониками, а половина с мнемониками Zilog.

Директивы.

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

определение данных (констант и переменных);

управление организацией программы в памяти и параметрами выходного файла;

задание режима работы компилятора;

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

макросы.

Пример программы.

Пример программы Hello world для MS-DOS для архитертуры x86 на диалекте TASM:

MODEL TINYSEGMENTCS:CODE, DS:CODE100h:ah,9dx,OFFSET Msg21h20hDB 'Hello World',13,10,'$'

CODE ENDSSTART

Происхождение и критика термина "язык ассемблера".

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

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

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

·Python.

Python - это один из наиболее популярных современных языков программирования. Он пригоден для решения разнообразных задач и предлагает те же возможности, что и другие языки программирования: динамичность, поддержку ООП и кросс-платформенность. Разработку Python начал Гвидо Ван Россум (Guido Van Rossum) еще в середине 1990-х годов, поэтому к настоящему времени удалось избавиться от стандартных "детских" болезней, существенно развить лучшие стороны языка и привлечь множество программистов, использующих Python для реализации своих проектов.

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

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

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

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

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

Архитектура Python.

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

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

К Python это не относится, так как это язык простой, но упрощенный. Дело в том, что Python является языком с более высоким уровнем абстракции, выше, например, чем у Java и C++, и позволяет передать такое же количество информации в меньшем объеме исходного кода.

Также Python является языком общего назначения, поэтому может применяться практически в любой области разработки ПО (standalone, клиент-сервер, Web-приложения) и в любой предметной области. Кроме того, Python легко интегрируется с уже существующими компонентами, что позволяет внедрять Python в уже написанные приложения.

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

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

Среда исполнения Python.

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

В среду исполнения Java дополнительно входит компилятор, так как исходный код необходимо скомпилировать в байт-код для виртуальной Java-машины. В среду исполнения Python входит только интерпретатор, который одновременно является и компилятором, однако компилирует исходный код Python непосредственно в машинный код целевой платформы.

На данный момент существуют три известных реализации среды исполнения для Python: CPython, Jython и Python.NET. Как можно догадаться из названия, первая среда реализована на языке C, вторая на языке Java, а последняя - на платформе.NET.

Среда исполнения CPython обычно называется просто Python, и когда говорят о Python, то чаще всего имеется в виду именно эта реализация. Эта реализация состоит из интерпретатора и модулей расширения, написанных на языке C, и может использоваться на любой платформе, для которой доступен стандартный компилятор C. Кроме того, существуют уже скомпилированные версии среды исполнения для различных операционных систем, включая различные версии OC Windows и различные дистрибутивы Linux. В этой и последующих статьях будет рассматриваться именно CPython, если иное не оговаривается отдельно.

Среда исполнения Jython - это реализация Python для работы с виртуальной Java-машиной (JVM). Поддерживается любая версия JVM, начиная с версии 1.2.2 (текущая версия Java - 1.6). Для работы с Jython требуется установленная Java-машина (среда исполнения Java) и определенное знание языка программирования Java. Уметь писать исходный код на языке Java не обязательно, однако придется иметь дело c JAR-файлами и Java-апплетами, а также документацией в формате JavaDOC.

Какую версию среды выбрать - зависит исключительно от предпочтений программиста, вообще же рекомендуется держать на компьютере и CPython, и Jython, так как они не конфликтуют между собой, а взаимно дополняют друг друга. Среда CPython работает быстрее, так как нет промежуточного уровня в виде JVM; кроме того, обновленные версии Python сначала выпускают именно в виде среды CPython. Однако Jython может использовать любой класс Java в качестве модуля расширения и работать на любой платформе, для которой существует реализация JVM.

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

·Ruby.

Среда исполнения Python.

Сервисные программы.

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

Часто утилиты объединяют в комплексы наиболее популярные комплексы Norton Utilities, PC Tools Deluxe и Mace Utilities.

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

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

Типы драйверов.

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

·драйверы пользовательского уровня - исполняются в пользовательском режиме и предоставляют интерфейс между приложениями и драйверами уровня ядра. К ним относятся драйверы принтеров и драйверы виртуальных устройств;

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

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

)Драйверы высокого уровня. К ним относятся драйверы файловых систем, которые поддерживают файловые системы, например FAT, NTFS, CDFS. Драйверы высокого уровня всегда зависят от драйверов нижних уровней.

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

·функциональные драйверы - управляют конкретным типом устройств. Драйверы шин предоставляют устройства функциональным драйверам через диспетчер PnP;

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

·драйверы нижнего уровня. Контролируют ввод/вывод шины, к которой подключено периферийное устройство. Здесь также существуют разные виды драйверов;

·драйверы шин - управляют логическими или физическими шинами, такими как PCI, USB. Драйверы шин отвечают за распознавание устройств, подключенных напрямую к этим шинам, оповещение диспетчера PnP об этих устройствах и управление параметрами электропитания шины;

·драйверы, не поддерживающие WDM.

Таким образом, системное ПО - это совокупность программных и языковых средств.

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

1.2 Жизненный цикл прикладной программы

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

. Модификация программы за счет изменения модели предметной области.

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

.Анализ задачи.

2.Проектирование.

.Кодирование.

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

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

.Техническое задание.

2.Эскизный, технический проекты, пояснительная записка.

.Распечатка программы и статическое тестирование.

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

5.Тестирования.

Разработка ПО может вестись с использованием лавинообразной (Схема 2) или итеративной (Схема 3) моделей разработки. Лавинообразная модель (модель "водопада") может быть использована для разработки ПО небольшого размера с хорошо определенной алгоритмической базой.

Схема 1-Лавинообразная

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

·планирование;

·реализация;

·проверка;

·оценка.

Схема 2- Итеративная

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

·снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

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

·акцент усилий на наиболее важные и критичные направления проекта;

·непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

·раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

·более равномерная загрузка участников проекта;

·эффективное использование накопленного опыта;

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

1.3 Методология и технология разработки ПП

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

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

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

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

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

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

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

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

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

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

) эволюционная стратегия, когда в начале требования определяются в неполном объеме, но уточняются в ходе разработки версий программного продукта. Линейная последовательность этапов разработки имеет несколько вариантов. Модель водопада (Waterfall Model) - наиболее "старая" модель процесса разработки программного обеспечения. Процесс разработки представляется как последовательность (поток) этапов, фаз (анализа требований, проектирования, реализации, тестирования, интеграции и поддержки). Разработчик переходит от одной стадии к другой строго последовательно, после полного и успешного завершения предыдущей фазы; переходов назад либо вперед или перекрытия фаз не происходит. Системный анализ определяет роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Анализ начинается с определения требований и назначения подмножества этих требований программному элементу. Среди основных решаемых задач планирования проекта программного обеспечения выделяют: объем, сроки и трудозатраты проектных работ, бюджет проекта, состав исполнителей, план-график работ. В процессе анализа требований уточняются функции и характеристики программного средства, требования к пользовательскому и программному интерфейсам. Проектирование программного продукта включает в себя разработку архитектуры построения, состава и назначения модулей, алгоритмов и структуры данных, интерфейсов. Кодирование обеспечивает реализацию проектных решений в выбранной среде программирования. Тестирование - обязательный этап для выявления дефектов программного продукта. Сопровождение - поддержка работоспособности программного продукта у заказчика, внесение изменений в эксплуатируемый программный продукт. Каждая стадия (этап) завершается выпуском полного комплекта документации. Эта модель обладает как достоинствами, так и недостатками. Основная проблема - нарастание риска проекта из-за накапливания ошибок ранних стадий проекта, что не позволяет эффективно выявлять и нивелировать последствия подобных рисков.

Рисунок 1. Этапы разработки ПО для водопадной модели

Модифицированные модели водопада - Agile Software Development, гибкая или "живая" методология разработки, нацелена на минимизацию рисков путем сведения разработки к серии коротких циклов, называемых итерациями, длительностью не более двух недель. Каждая итерация обеспечивает прохождение всех фаз проекта, обеспечивая инкремент (прирост) функциональности. Однако итерация, как правило, недостаточна для выпуска новой версии продукта. По окончании итерации команда разработчиков оценивает и выбирает приоритеты разработки. Основной метрикой данной методологии становится рабочий продукт, а не система письменной документации. Далее была создана модель RAD - Rapid Application Development (быстрая разработка приложений), которая стала основой технологий создания и развертывания программных продуктов. Эта модель предусматривает:

·инструментальную поддержку процесса разработки, минимизацию времени и трудозатрат;

·использование прототипа для уточнения требований заказчика;

·цикличность разработки - каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком;

·постепенное расширение функциональности;

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

·управление проектом создания программного продукта.

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

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

Рисунок 2. Схема выполнения проектных работ по модели RAD

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

Эволюционная стратегия получила свое воплощение в ряде моделей: спиральной, компонентно-ориентированной. Автором спиральной модели является американский ученый Б. Боэм (1988).

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

) планирование - определение целей, вариантов, ограничений;

) анализ риска - анализ вариантов и распознавание (выбор) риска;

) конструирование - разработка продукта следующего уровня;

) оценивание - оценка заказчиком текущих результатов разработки.

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

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

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

2.Разработка архитектуры системы, определяющей концепцию построения программного продукта, открытой для изменений.

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

Рисунок 3. Схема выполнения проектных работ по спиральной модели: 1 - планирование проекта и жизненного цикла; 2 - концепция эксплуатации; 3 - спецификация требований; 4 - проверка требований; 5 - детальный дизайн; 6 - кодирование; 7 - модульное тестирование; 8 - интеграция и тестирование; 9 - приемочное тестирование; 10 - развертывание.

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

1.4 Тестирование программных средств

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

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

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

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

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

В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие "оптимизация бизнес-технологий" (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.

Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта. алгоритм интерфейс delphi

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

·по объекту тестирования;

·по знанию системы;

·по степени автоматизированности;

·по степени изолированности компонентов;

·по времени проведения тестирования;

·по признаку позитивности сценариев;

·по степени подготовленности к тестированию.

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

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

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

Системное тестирование - тестируется интегрированная система на её соответствие требованиям.

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

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

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

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

Тестирование "белого ящика" и "чёрного ящика".

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

При тестировании белого ящика (англ. white-box testing, также говорят - прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции - работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

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

По объекту тестирования:

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

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

·функциональная пригодность (англ. suitability);

·точность (англ. accuracy);

·способность к взаимодействию (англ. interoperability);

·соответствие стандартам и правилам (англ. compliance);

·защищённость (англ. security).

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

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

Направления тестирования производительности.

В тестировании производительности различают следующие направления:

·нагрузочное (load);

·стресс (stress);

·тестирование стабильности (endurance or soak or stability);

·конфигурационное (configuration);

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

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

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

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

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

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

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

Определение целей тестирования производительности.

В общих случаях тестирование производительности может служить разным целям:

·c целью демонстрации того, что система удовлетворяет критериям производительности;

·с целью определения производительность какой из двух или нескольких систем лучше;

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

Многие тесты на производительность делаются без попытки осмыслить их реальные цели. Перед началом тестирования всегда должен быть задан бизнес-вопрос: "Какую цель мы преследуем, тестируя производительность?". Ответы на этот вопрос являются частью технико-экономического обоснования (или business case) тестирования. Цели могут различаться в зависимости от технологий, используемых приложением, или его назначения, однако, они всегда включают что-то из нижеследующего:

·параллелизм;

·пропускная способность.

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

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

Время ответа сервера.

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

Время отображения.

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

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

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

Тестирование производительности может проводиться с использованием глобальной сети и даже в географически удаленных местах, если учитывать тот факт, что скорость работы сети Интернет зависит от местоположения. Оно также может проводиться и локально, но в этом случае необходимо настроить сетевые маршрутизаторы таким образом, чтобы появилась задержка, присутствующая во всех публичных сетях. Нагрузка, прилагаемая к системе, должна совпадать с реальным положением дел. Так например, если 50 % пользователей системы для доступа к системе используют сетевой канал шириной 56К, а другая половина использует оптический канал, то компьютеры, создающие тестовую нагрузку на систему должны использовать те же соединения (идеальный вариант) или эмулировать задержки вышеуказанных сетевых соединений, следуя заданным профайлам пользователей.

Типичные вопросы тестирования производительности.

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

·что охватывается тестом производительности? Какие подсистемы, компоненты, интерфейсы и т. д. должны быть протестированы?

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

·как выглядит аппаратная составляющая тестируемой системы? (Необходимо описать все сервера и сетевое оборудование)

·каков сценарий использования каждого компонента системы? (например, 20 % запросов составляет вход в систему, 40 % - поиск, 30 % - выбор элемента, 10 % - выход из системы)

·каков сценарий использования системы? [в одном тесте на производительность могут быть задействованы разные сценарии использования каждого компонента]

·каковы требования ко времени выполнения серии операций серверной части приложения?

Инструментарий.

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

Например:

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

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

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

·приложение;

·база данных;

·сеть;

·обработка на клиентской стороне;

·балансировка нагрузки.

Также следует отметить появление сетевых Business-to-business (B2B) приложений, использующих соглашение об уровне услуг (или SLA, Service Level Agreement). Нарастающая популярность B2B приложений привело к тому, что всё больше приложений переходит на сервис-ориентированную архитектуру, в случае которой обмен информацией происходит без участия веб-браузеров. Примером такого взаимодействия может служить бюро туристических услуг, запрашивающее информацию об определённом авиарейсе между Санкт-Петербургом и Омском, в то время как авиакомпания обязана предоставить ответ в течение 5 секунд. Часто нарушение договора об SLA грозит крупным штрафом.

Мифы тестирования производительности.

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

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

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

Другая часть мифа, касательно небольших изменений в скриптах тоже неправда, так как любые изменения в UI, особенно в сетевом протоколе, приведет к полному переписыванию скриптов с самого начала. Проблема становится более ощутимой в случае использования таких протоколов, как Web Services, Siebel, Citrix, SAP.

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

Нагрузочное тестирование.

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

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

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

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

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

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

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

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

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

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

. Уникальность запросов.

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

. Время отклика системы.

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

В частности это означает, что имея достаточное количество измерений, можно определить вероятность с которой отклик системы на запрос попадёт в тот или иной интервал времени.

. Зависимость времени отклика системы от степени распределённости этой системы.

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

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

. Разброс времени отклика системы.

Из утверждений 1, 2 и 3 можно также заключить, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся запросы, время обработки которых превышает определённые в требованиях максимумы; причем, чем больше суммарное время проведения эксперимента тем выше окажутся новые максимумы.

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

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

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

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

Инструментарий для тестирования производительности.

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

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

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

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

Основные принципы.

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

Необходимость стресс-тестирования диктуется следующими факторами:

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

2.В случае SLA-контракта (соглашения об уровне услуг) стоимость отказа системы в экстремальных условиях может быть очень велика.

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

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

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

Основные направления применения стресс-тестирования:

·общее исследование поведения системы при пиковых нагрузках;

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

·исследование узких мест системы или отдельных компонент при диспропорциональных нагрузках;

·тестирование ёмкости системы.

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

Пропорциональная нагрузка.

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

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

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

Тестирование стабильности или надежности (Stability / Reliability Testing) - один из видов автоматизированного тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.

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

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

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

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

Процесс.

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

Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства - с целью последующего более детального анализа.

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

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

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

.Речь модератора и респондента;

2.Выражение лица респондента (снимается на видеокамеру);

.Изображение экрана компьютера, с которым работает респондент;

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

·перемещение курсора и нажатия на клавиши мыши;

·использование клавиатуры;

·переходы между экранами (браузера или другой программы).

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

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

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

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

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

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

·попытки узнать пароль с помощью внешних средств;

·атака системы с помощью специальных утилит, анализирующих защиты;

·подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);

·целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

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

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

Локализация программного обеспечения.

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

Для локализации в английском языке иногда применяют сокращение "L10n". Где буквы "L" и "n" - начало и окончание слова Localization, а цифра 10 - количество букв между ними.

Тестирование по стратегии чёрного ящика.

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

Понятие "чёрного" ящика.

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

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

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

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

В настоящее время известны два вида "чёрных" ящиков. К первому виду относят любой "чёрный" ящик, который может рассматриваться как автомат, называемый конечным или бесконечным. Поведение таких "чёрных" ящиков известно. Ко второму виду относятся такие "чёрные" ящики, поведение которых может быть наблюдаемо только в эксперименте. В таком случае в явной или неявной форме высказывается гипотеза о предсказуемости поведения "чёрного" ящика в вероятностном смысле. Без предварительной гипотезы невозможно любое обобщение, или, как говорят, невозможно сделать индуктивное заключение на основе экспериментов с "чёрным" ящиком. Для обозначения модели "чёрного" ящика Н. Винером [2] предложено понятие "белого" ящика. "Белый" ящик состоит из известных компонентов, то есть известных X, Y, ?, ?. Его содержимое специально подбирается для реализации той же зависимости выхода от входа, что и у соответствующего "чёрного" ящика. В процессе проводимых исследований и при обобщениях, выдвижении гипотез и установления закономерностей возникает необходимость корректировки организации "белого" ящика и смены моделей. В связи с этим при моделировании исследователь должен обязательно многократно обращаться к схеме отношений "чёрный" - "белый" ящик.

Исследование поведения "черного" ящика.

Рассмотрим, как изучается и исследуется поведение "черного" ящика второго вида. Предположим, что дана некоторая система управления, внутреннее строение которой неизвестно. Система управления имеет входы и выходы .

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

Стратегия тестирования по принципу "Белого ящика".

"Белый ящик" - тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.

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

Техника Белого ящика включает в себя следующие методы тестирования:

·покрытие операторов;

·покрытие решений;

·покрытие условий;

·покрытие решений и условий;

·комбинаторное покрытие условий.

Автоматизированное тестирование.

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

История.

Первые попытки "автоматизации" появились в эпоху операционных систем DOS и CP/M. Тогда она заключалась в выдаче приложению команд через командную строку и анализе результатов. Чуть позднее добавились удаленные вызовы через API для работы по сети. Впервые об автоматизированном тестировании упоминается в книге Фредерика Брукса "Мифический человеко-месяц", где говорится о перспективах использования модульного тестирования. Но по-настоящему автоматизация тестирования стала развиваться только в 1980-х годах.

Подходы.

Существует два основных подхода к автоматизации тестирования: тестирование на уровне кода и тестирование пользовательского интерфейса (в частности, GUI-тестирование). К первому типу относится, в частности, модульное тестирование. Ко второму - имитация действий пользователя с помощью специальных тестовых фреймворков.автоматизация.

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

·утилиты записи и воспроизведения (англ. capture/playback tools) записывают действия тестировщика во время ручного тестирования. Они позволяют выполнять тесты без прямого участия человека в течение продолжительного времени, значительно увеличивая продуктивность и устраняя "тупое" повторение однообразных действий во время ручного тестирования. В то же время, любое малое изменение тестируемого ПО требует перезаписи ручных тестов. Поэтому это первое поколение инструментов не эффективно и не масштабируемо;

·написание сценария (англ. scripting) - форма программирования на языках, специально разработанных для автоматизации тестирования ПО - смягчает многие проблемы инструментов записи и воспроизведения. Но разработкой занимаются программисты высокого уровня, которые работают отдельно от тестировщиков, непосредственно запускающих тесты. К тому же скрипты более всего подходят для тестирования GUI и не могут быть внедренными, пакетными или вообще каким-либо образом объединены в систему. Наконец, изменения в тестируемом ПО требуют сложных изменений в соответствующих скриптах, и поддержка все возрастающей библиотеки тестирующих скриптов становится в конце концов непреодолимой задачей;

·управляемое данными тестирование (англ. Data-driven testing) - методология, которая используется в автоматизации тестирования. Особенностью является то, что тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или базе данных. Роль базы данных могут выполнять ODBC-ресурсы, csv или xls файлы и т. д. Управляемое данными тестирование - это объединение нескольких взаимодействующих тестовых скриптов и их источников данных в фреймворк, используемый в методологии. В этом фреймворке переменные используются как для входных значений, так и для выходных проверочных значений: в тестовом скрипте обычно закодированы навигация по приложению, чтение источников данных, ведение логов тестирования. Таким образом, логика, которая будет выполнена в скрипте, также зависит от данных;

·тестирование по ключевым словам (англ. Keyword-based) автоматизация подразумевает разделение процесса создания кейсов на 2 этапа: этап планирования и этап реализации. В этом случае конечный тест представляет собой не программный код, а описание последовательности действий с их параметрами (например, "завести в базе данных пользователя с логином XXX и паролем YYY"). При этом фреймворк отвечает за непосредственную реализацию ключевых слов (действий), а дизайнеру тестов достаточно иметь представление о всём наборе действий, реализованных во фреймворке. Это даёт возможность создавать тесты людям, не имеющим навыков программирования.

Проблемы.

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

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

Модульное тестирование, или юнит-тестирование (англ. unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Преимущества.

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

Этот тип тестирования обычно выполняется программистами.

Поощрение изменений.

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

Упрощение интеграции.

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

Документирование кода.

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

Отделение интерфейса от реализации.

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

Ограничения.

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

Тестирование программного обеспечения - комбинаторная задача. Например, каждое возможное значение булевской переменной потребует двух тестов: один на вариант TRUE, другой - на вариант FALSE. В результате на каждую строку исходного кода потребуется 3-5 строк тестового кода.

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

Приложения модульного тестирования.

Экстремальное программирование.

Экстремальное программирование предполагает как один из постулатов использование инструментов автоматического модульного тестирования. Этот инструментарий может быть создан либо третьей стороной (например, Boost.Test), либо группой разработчиков данного приложения.

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

Интеграционное тестирование.

Интеграционное тестирование (англ. Integration testing, иногда называется англ. Integration and Testing, аббревиатура англ. I&T) - одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

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

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

Системы непрерывной интеграции.

Для автоматизации интеграционного тестирования применяются системы непрерывной интеграции (англ. Continuous Integration System, CIS). Принцип действия таких систем состоит в следующем:

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

·выполняются необходимые проверки и модульные тесты;

·исходные коды компилируются в готовые выполняемые модули;

·выполняются тесты интеграционного уровня;

·генерируется отчет о тестировании.

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

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

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

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

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

Можно выделить два подхода к системному тестированию:

на базе требований (requirements based)

Для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.

на базе случаев использования (use case based)

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

·модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО;

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

·системное тестирование - тестируется интегрированная система на её соответствие требованиям;

·альфа-тестирование - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО;

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

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

Тестирование программных средств.

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

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

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

Типичный процесс тестирования изображен на рисунке 4.

Рисунок 4

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

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

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

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

В таком случае преобразование называют гомоморфным.

В настоящее время известны два вида "чёрных" ящиков. К первому виду относят любой "чёрный" ящик, который может рассматриваться как автомат, называемый конечным или бесконечным. Поведение таких "чёрных" ящиков известно. Ко второму виду относятся такие "чёрные" ящики, поведение которых может быть наблюдаемо только в эксперименте. В таком случае в явной или неявной форме высказывается гипотеза о предсказуемости поведения "чёрного" ящика в вероятностном смысле. Без предварительной гипотезы невозможно любое обобщение, или, как говорят, невозможно сделать индуктивное заключение на основе экспериментов с "чёрным" ящиком. Для обозначения модели "чёрного" ящика Н. Винером предложено понятие "белого" ящика. "Белый" ящик состоит из известных компонентов, то есть известных X, Y, ?, ?. Его содержимое специально подбирается для реализации той же зависимости выхода от входа, что и у соответствующего "чёрного" ящика. В процессе проводимых исследований и при обобщениях, выдвижении гипотез и установления закономерностей возникает необходимость корректировки организации "белого" ящика и смены моделей. В связи с этим при моделировании исследователь должен обязательно многократно обращаться к схеме отношений "чёрный" - "белый" ящик.

Техника "Белого" ящика включает в себя следующие методы тестирования:

·покрытие операторов;

·покрытие решений;

·покрытие условий;

·покрытие решений и условий;

·комбинаторное покрытие условий.

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

При тестировании "белого" ящика (англ. white-box testing, также говорят - прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции - работоспособны и устойчивы, до определённой степени.

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

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

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

Если "альфа-" и "бета-тестирование" относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование "белого ящика" и "чёрного ящика" имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин "бета-тестирование" может указывать на состояние программы (ближе к выпуску чем "альфа"), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию "белого" ящика, хотя ПО уже "в бете" (стадия), но в этом случае он не является частью "бета-тестирования" (группы/процесса).

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

Оценочное тестирование, которое также называют "тестированием системы в целом", включает следующие виды:

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

·тестирование на предельных объемах - проверка работоспособности программы на максимально больших объемах данных, например, объемах текстов, таблиц, большом количестве файлов и т. п.;

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

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

·тестирование защиты - проверка защиты, например, от несанкционированного доступа к информации;

·тестирование производительности - определение пропускной способности при заданной конфигурации и нагрузке;

·тестирование требований к памяти - определение реальных потребностей в оперативной и внешней памяти;

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

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

·тестирование удобства установки - проверка удобства установки;

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

·тестирование восстановления - проверка восстановления программного обеспечения, например системы, включающей базу данных, после сбоев оборудования и программы;

·тестирование удобства обслуживания - проверка средств обслуживания, включенных в программное обеспечение;

·тестирование документации - тщательная проверка документации, например, если документация содержит примеры, то их все необходимо попробовать;

·тестирование процедуры - проверка ручных процессов, предполагаемых в системе.

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

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

1.5 Описание прикладной задачи

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

Исходной информацией для задачи поиска кратчайших путей является взвешенный граф G = (V, R), содержащий n вершин (|V|= n), в котором каждому ребру графа приписан неотрицательный вес. Граф будем полагать ориентированным, т.е., если из вершины i есть ребро в вершину j, то из этого не следует наличие ребра из j в i. Для поиска минимальных расстояний между всеми парами пунктов назначения Флойд предложил алгоритм. Пусть есть 3 узла I, j и k и заданы расстояния между ними (рис 3). Если выполняется неравенство

dij+djk<dik,

то целесообразно заменить путь i->k путем i->j->k. Такая замена (далее ее будем наз-ть треугольным оператором) выполняется систематически в процессе выполнения алгоритма Флойда.

Рисунок 5

Шаг 0. Определяем начальную матрицу расстояний D0 и матрицу последовательности узлов S0. Диагональные элементы обеих матриц помечаются знаком "_", показывающим, что эти элементы в вычислениях не участвуют. Полагаем k=1.

Основной шаг k. Задаем строку k и столбец k как ведущую строку строку и ведущий столбец. Рассматриваем возможность применения треугольного оператора ко всем элементам dij матрицы Dk-1. Если выполняется неравенство

dij+djk<dik,(i?k,j?k и i?j),

тогда выполняем следующие действия:

.Создаем матрицу Dk путем замены в матрице Dk-1 элемента dij на сумму dik+ djk.

2.Создаем матрицу Sk путем замены в матрице Sk-1 элемента sij на k. Полагаем k=k+1 и повторяем шаг k.

2. Специальная часть

.1 Цели разработки

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

Рисунок 6. Схема маршрута сети районов

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

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

·научиться управлять объектом или процессом при заданных целях и критериях;

·прогнозировать прямые и косвенные последствия реализации;

·заданных способов и форм воздействия;

·обладать наглядным графическим интерфейсом;

·быстро и корректно выполнять расчеты;

·реализовывать данный прикладной метод оптимальным образом;

·легко переносить на различные технологические платформы;

·обеспечивать обработку некорректно введенных данных;

·удовлетворять требованиям простоты, доступности интерфейса.

2.2 Расчет математической модели

Вариант 1

Вариант 2

Вариант 3

2.3 Описание программы

.3.1 О программе

Данная программа написана в системе Delphi Borland Developer Studio 2006 Borland Developer Studio включает Delphi 2006, C++Builder 2006 и C#Builder2006. Delphi 2006 - десятая версия Delphi, флагманской RAD-среды фирмы Borland.

В Delphi 2006 много новых уровней функциональности. В их число входят как высокоуровневые возможности Application Lifecycle Management (ALM), так и низкоуровневые усовершенствования. Borland в новой версии очень старался сделать акцент на производительности и скорости отклика, о чем свидетельствуют вещи, подобные обновленному менеджеру памяти IDE.

Требования к системе:

процессор Intel Pentium III/M 1,4 ГГц или Pentium IV 1,4 ГГц (минимум) (рекомендуется процессор Intel Pentium III/M с частотой выше 1,4 ГГц или Pentium IV с частотой выше 2 ГГц)

Microsoft Windows Server 2003 (SP1), Microsoft Windows‚ XP Professional (SP2), Windows 2000 Professional (SP4), Windows 2000 Server (SP4)

512 МБ ОЗУ (рекомендуется 1 ГБ или больше)

1 ГБ свободного дискового пространства для Delphi for Win32 и Delphi for NET (Без учета пространства, необходимого для дополнительных продуктов сторонних поставщиков).

2.3.2 Алгоритм работы программы

2.3.3 Входные данные

Таблица 2 -Входные данные

ОбозначениеТип данныхКомментарийaArray of integerРасстояние между узламиCheckBox(x)BooleanНачальный узелCheckBox(y)BooleanКонечный узел

2.3.4 Выходные данные

Таблица 3 - Выходные данные

ОбозначениеТип данныхКомментарийbArray of integerКратчайший путь между отмеченными узлами

2.4 Тестирование программы

Тестирование - процесс выполнения программы с целью обнаружения ошибок.

Тестирование обеспечивает:

·обнаружение ошибок;

·демонстрацию соответствия функций программы её назначению;

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

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

Таблица 4 - Тестирование программы

Тестовый наборОжидаемый результатПолученный результатВыводНачальный узел 1 Конечный узел 7 Путь 7->5->6->1 Расстояние 18Путь 7->5->6->1 Расстояние 18Программа работает корректноНачальный узел 1 Конечный узел 4 Путь 4->5->6->1 Расстояние 26Путь 4->5->6-> Расстояние 26Программа работает корректноНачальный узел 1 Конечный узел 5 Путь 5->6->1 Расстояние 26Путь 5->6->1 Расстояние 26Программа работает корректно

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

2.5 Руководство пользователя

Запуск программы осуществляется с помощью файла *.exe. после чего появляется стартовая форма проекта.

Рисунок 7. Стартовая форма

На рисунке изображена форма, которая загружается при старте программы.

Рисунок 8. Расчет

Рисунок 9. Окно "О программе"

Заключение

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

.Изучен математический метод алгоритм Флойда-Уоршела;

2.Составлен алгоритм компьютерной модели решения;

.Создана программа которая:

реализует данный математический метод оптимальным образом;

быстро и корректно выполняет расчеты;

имеет понятный пользователю интерфейс.

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

Литература

1.Архангельский А.Я. Object Pascal в Delphi. - СПб.: Бином, 2012.

2.Браун С. Visual Basic 6.0: Учебный курс. - СПб.: Питер, 2010, - 573 с.

.Васильев А., Андреев А.VBA в Office 2000. - М., 2009.

.Вишневский П. Длинные строки и динамические массивы в Delphi // RSDN Magazine, № 3, 2012.

.Галисеев Г.В. Программирование в среде Delphi 7. Самоучитель. - М.: Издательский дом "Вильямс", 2011.

.Елманова Н., Трепалин С., Тенцер А. - Delphi и технология COM 2010.

.Лялин В.Е Математические модел, 2012.

.Парижский С.М.Delphi. Учимся на примерах. 2011.

.Митчелл К. Керман Программирование и отладка в Delphi: Учебный курс: М.; СПб.; Киев, 2012.

.Фаронов В.В. Delphi 6: Учебный курс. - СПб.: Питер, 2013.

Больше работ по теме:

Разработка программ по созданию базы данных приборов и добавления первой строчки, в которую заносится максимальный элемент каждого столбца
Курсовая работа (т)
Разработка программного модуля для расчета материального баланса процесса горения эстонского сланца
Курсовая работа (т)
Разработка программного обеспечения для обучающей и тестирующей системы "Лексика английского языка"
Курсовая работа (т)
Разработка программного обеспечения для построения статистической модели методом наименьших квадратов
Курсовая работа (т)
Разработка программного приложения "Автоматизация учёта клиентов отдела вневедомственной охраны"
Курсовая работа (т)

Предмет: Информационное обеспечение, программирование

Тип работы: Курсовая работа (т)

Новости образования

Российский государственный социальный университет реорганизует сеть своих филиалов
22 Июля 2016 16:26
Более 70 представителей крупных вузов АСЕАН подтвердили участие в форуме во Владивостоке
22 Июля 2016 12:51
Абызов: публикация первичных статсведений снизит бюрократическую нагрузку на школы
22 Июля 2016 11:53
В Чечне свыше 200 школьников сдали ЕГЭ с результатом свыше 90 баллов - министр
22 Июля 2016 05:36
Замглавы Минобрнауки РФ: задача сократить число людей с высшим образованием не стоит
21 Июля 2016 20:19

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ