Разработка методики комплексного тестирования Open Source приложений

1.7 Функциональное тестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 2 Таблица различий между корректирующим и прогрессивным регрессионным тестированием

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

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

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

- наличие плана тестирования;

- объёмтеста;

- распределение времени;

- разработка информации;

- время завершения;

- частота.

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

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

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

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

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

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

1.10 Постановка задачи

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

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

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

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

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

2. Экспериментальная часть

2.1 Платформа IBMWatson

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

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

Платформа IBMWatson состоит из четырёх основных компонент:

- IBMInfoSphereBigInsights (программное обеспечение для хранения и обработки неструктурированной и частично структурированной информации);

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

- IBMInfoSphereStreams (программное обеспечение для обработки потоковой информации);

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

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

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

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

- высокая масштабируемость;

- отказоустойчивость;

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

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

- высокая доступность и управление неструктурированными потоковыми данными;

- непрерывный анализ данных на высоких скоростях;

- адаптация к возможным изменениям типов данных.

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

2.2 Стек лабораторных работ

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

Таблица 3 Стек лабораторных работ

№	Наименованиелабораторной работы	Проприетарное решение IBM Watson	OpenSource решение
1	Работа с неструктурированными данными в распределенной файловой системе	ApacheHadoop	Не требуется, так как ApacheHadoop - ПО с открытым исходным кодом
2	Управление процессами обработки неструктурированных данных	IBM InfoSphereBigInsights	Cloudera (ApacheHue)
3	Анализ структурированных и неструктурированных данных	IBM InfoSphereBigInsights (BigSheets toolkit)	Cloudera (Apache Hue, Apache Hive)
4	Управление большими данными	IBM InfoSphereBigInsights (BigSheets toolkit), IBM Big SQL	Cloudera (ApacheHive)
5	Структурирование данных с помощью специализированных языков обработки текстовой информации	IBM Data Studio AQL (Annotation Query Language)	ApacheFlume
6	Анализ потоковой информации с использованием специализированных языков обработки потоков данных	IBM InfoSphere Streams, SPL (Streams Processing Language)	ApacheKafka, SparkStreaming
7	Управление обработкой потоковых данных	IBM InfoSphere Streams	ApacheKafka, SparkStreaming
8	Исследование текстовой информации	IBM InfoSphereDataExplorer	ApacheNutch
9	Анализ структурированных и неструктурированных данных	IBM Content Analytics with Enterprise Search, IBM SPSS Modeler, IBM Content Analytics Studio	ApacheSolr
10	Выявление скрытых связей на основе анализа текстов	IBM i2 Text Chart IBM i2 iBase IBM i2 Analyst's Notebook	Cloudera (Data Warehouse), Apache Spark

Как видно из таблицы, искать и разрабатывать приложение с открытым исходным кодом для лабораторной работы №1 не требуется, так как используемый инструмент в платформе IBMWatson уже является OpenSourceрешением. На данный момент, разработаны и интегрированы командой разработчиков в программно-аппаратную среду только лабораторные работы №2, №3, №4 и №6, выполненные с помощью инструментов с открытым исходным кодом и функционально подобные проприетарным инструментам платформы IBMWatson.

2.3 План тестирования

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

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

2) объём работ (в данном разделе присутствует информация о функциях, которые будут тестироваться);

3) критерии качества и приёмки (в данном разделе содержатся критерии, оценивающие качество продукта, а также условия завершения процесса тестирования);

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

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

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

7) тестовая документация (в данном разделе содержится информация о документах, которые присутствуют при проведении тестирования);

8) стратегия проведения тестирования (в данном разделе содержится информация об уровнях и видах тестирования, которые применяются в процессе тестирования ПО, а также об методах тестирования);

9) график тестирования (в данном разделе присутствует информация о сроках проведения процесса тестирования).

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

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

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

2.3.1 План тестирования лабораторной работы №2

При тестировании лабораторной работы №2 на OpenSourceинструментах, прежде всего необходимо составить план проведения процесса данного тестирования. Тест план представлен в таблице 4.

Таблица 4 План тестирования лабораторной работы №2

Пункт плана тестирования	Содержание
Введение в тестирование ПО	Программный пакет, подлежащий тестированию: Cloudera (ApacheHue).
Введение в тестирование ПО	Программный продукт будет использоваться для обучения навыкам владения процессами администрирования системы с помощью веб-консоли для отслеживания и анализа состояний процессов обработки неструктурированных данных. Программный продукт будут использовать студенты образовательных программ, направленных на изучение методов работы с большими данными.
Объём работ	Функции, подлежащие тестированию: запуск веб-консоли Cloudera; работоспособность средств, которые доступны на странице приветствия; администрирование программного пакета (состояние кластера, запуск и остановка встроенных компонентов); работоспособность распределённой файловой системы (создание и удаление каталогов, создание и удаление подкаталогов, загрузка текстовых файлов в распределённую файловую систему HDFS с помощью веб-консоли ApacheHue).
Критерии качества и приёмки	Критерии качества: работоспособность функций программного пакета; функционирование программного пакета в программно-аппаратной среде (окружении). Условия завершения процесса тестирования: работоспособность функций программного пакета является схожей с заменяемой проприетарной технологией платформы IBMWatson; стабильное функционирование программного пакета в программно-аппаратной среде (окружении).
Критические факторы успеха	Критические факторы успеха: отсутствие задержек от команды разработчиков; полноценный доступ в систему отслеживания ошибок; качественное проведение менеджмента процесса разработки и тестирования программного пакета.
Оценка риска	Возможные риски: разработка программного пакета идёт не в срок; тестирование программного пакета идёт не в срок; разработанный программный пакет на инструментах с открытым исходным кодом не повторяет исходную функциональность платформы IBMWatson; разработанный программный пакет не запускается в программно-аппаратной среде.
Оценка риска	Меры по предотвращению рисков: контроль этапов разработки; контроль этапов тестирования; по результатам комплексного тестирования отправить разработанный программный пакет на доработку; по результатам комплексного тестирования отправить разработанный программный пакет на доработку или провести повторный поиск и разработку другого программного продукта с открытым исходным кодом, который повторяет функциональность и работоспособность в окружении проприетарной платформы IBMWatson.
Ресурсы	Аппаратные характеристики: не менее 150 Гб дискового пространства; не менее 8 Гб оперативной памяти; не менее 8-ми исполнительных ядер процессора; доступ в Интернет. Программные характеристики: операционная система на базе Linux (RedHatEnterpriseLinux (версии 6.х или новее), Ubuntu (версии 16.04 или новее), Debian(версии 7.х или новее)); конфигурация SSH с «пробросом» Х11.
Тестовая документация	План тестирования, сценарии тестирования, отчёт по проведённому тестированию программного пакета.
Стратегия проведения тестирования	Необходимые уровни тестирования: интеграционное; системное; приёмочное. Необходимые виды тестирования: По объекту тестирования: функциональное тестирование (функциональное, регрессионное); нефункциональное тестирование (тестирование надежности). По времени проведения (бета тестирование). По виду позитивности сценариев: позитивные тесты; негативные тесты. По степени автоматизации (ручное тестирование). Метод проведения тестирования: метод «чёрного ящика».
График тестирования	Тестирование проводится после разработки программного пакета и его интеграции в программно-аппаратную среду.

2.3.2 План тестирования лабораторной работы №3

При тестировании лабораторной работы №3 на OpenSourceинструментах, также необходимо составить план проведения процесса данного тестирования. Тест план представлен в таблице 5.

Таблица 5 План тестирования лабораторной работы №3

Пункт плана тестирования	Содержание
Введение в тестирование ПО	Программный пакет, подлежащий тестированию: Cloudera (ApacheHue, ApacheHive). Программный продукт будет использоваться для приобретения знаний, навыков и умений в области обработки и анализа больших структурированных и неструктурированных данных, а также построения различных графиков по результатам анализа. Программный продукт будут использовать студенты образовательных программ, направленных на изучение методов работы с большими данными.
Объём работ	Функции, подлежащие тестированию: работа с таблицами ApacheHive (преобразование данных, обработка данных); анализ структурированных и неструктурированных данных; построение графиков в ApacheHue.
Критерии качества и приёмки	Критерии качества: работоспособность функций программного пакета; функционирование программного пакета в программно-аппаратной среде (окружении). Условия завершения процесса тестирования: работоспособность функций программного пакета является схожей с заменяемой проприетарной технологией платформы IBMWatson; стабильное функционирование программного пакета в программно-аппаратной среде (окружении).
Критические факторы успеха	Критические факторы успеха: отсутствие задержек от команды разработчиков; полноценный доступ в систему отслеживания ошибок; качественное проведение менеджмента процесса разработки и тестирования программного пакета.
Оценка риска	Возможные риски: разработка программного пакета идёт не в срок; тестирование программного пакета идёт не в срок;
Оценка риска	разработанный программный пакет на инструментах с открытым исходным кодом не повторяет исходную функциональность платформы IBMWatson; разработанный программный пакет не запускается в программно-аппаратной среде. Меры по предотвращению рисков: контроль этапов разработки; контроль этапов тестирования; по результатам комплексного тестирования отправить разработанный программный пакет на доработку; по результатам комплексного тестирования отправить разработанный программный пакет на доработку или провести повторный поиск и разработку другого программного продукта с открытым исходным кодом, который повторяет функциональность и работоспособность в окружении проприетарной платформы IBMWatson.
Ресурсы	Аппаратные характеристики: не менее 150 Гб дискового пространства; не менее 8 Гб оперативной памяти; не менее 8-ми исполнительных ядер процессора; доступ в Интернет. Программные характеристики: операционная система на базе Linux (RedHatEnterpriseLinux (версии 6.х или новее), Ubuntu (версии 16.04 или новее), Debian (версии 7.х или новее)); конфигурация SSH с «пробросом» Х11.
Тестовая документация	План тестирования, сценарии тестирования, отчёт по проведённому тестированию программного пакета.
Стратегия проведения тестирования	Необходимые уровни тестирования: интеграционное; системное; приёмочное. Необходимые виды тестирования: По объекту тестирования: функциональное тестирование (функциональное, регрессионное); нефункциональное тестирование (тестирование надежности). По времени проведения (бета тестирование). По виду позитивности сценариев: позитивные тесты;
Стратегия проведения тестирования	негативные тесты. По степени автоматизации (ручное тестирование). Метод проведения тестирования: метод «чёрного ящика».
График тестирования	Тестирование проводится после разработки программного пакета и его интеграции в программно-аппаратную среду.

2.3.3 План тестирования лабораторной работы №4

При тестировании лабораторной работы №4 на OpenSourceинструментах, также необходимо составить план проведения процесса данного тестирования. Тест план представлен в таблице 6.

Таблица 6 План тестирования лабораторной работы №4

Пункт плана тестирования	Содержание
Введение в тестирование ПО	Программный пакет, подлежащий тестированию: Cloudera (ApacheHive). Программный продукт будет использоваться для приобретения знаний в области работы с хранилищем ApacheHive, то есть приобретать навыки создания и удаления баз данных, таблиц, а также работы с данными. Программный продукт будут использовать студенты образовательных программ, направленных на изучение методов работы с большими данными.
Объём работ	Функции, подлежащие тестированию: работоспособность распределённой файловой системы из командной строки; работоспособность подключения к серверу хранилища; работоспособность хранилища ApacheHive (создание и удаление баз данных, создание и удаление таблиц, загрузка файлов различных форматов, содержащие неструктурированные или структурированные данные, выгружать структурированные данные в различных форматах).
Критерии качества и приёмки	Критерии качества: работоспособность функций программного пакета; функционирование программного пакета в программно-аппаратной среде (окружении). Условия завершения процесса тестирования: работоспособность функций программного пакета является схожей с заменяемой проприетарной технологией платформы IBMWatson;
Критерии качества и приёмки	стабильное функционирование программного пакета в программно-аппаратной среде (окружении).
Критические факторы успеха	Критические факторы успеха: отсутствие задержек от команды разработчиков; полноценный доступ в систему отслеживания ошибок; качественное проведение менеджмента процесса разработки и тестирования программного пакета.
Оценка риска	Возможные риски: разработка программного пакета идёт не в срок; тестирование программного пакета идёт не в срок; разработанный программный пакет на инструментах с открытым исходным кодом не повторяет исходную функциональность платформы IBMWatson; разработанный программный пакет не запускается в программно-аппаратной среде. Меры по предотвращению рисков: контроль этапов разработки; контроль этапов тестирования; по результатам комплексного тестирования отправить разработанный программный пакет на доработку; по результатам комплексного тестирования отправить разработанный программный пакет на доработку или провести повторный поиск и разработку другого программного продукта с открытым исходным кодом, который повторяет функциональность и работоспособность в окружении проприетарной платформы IBMWatson.
Ресурсы	Аппаратные характеристики: не менее 150 Гб дискового пространства; не менее 8 Гб оперативной памяти; не менее 8-ми исполнительных ядер процессора; доступ в Интернет. Программные характеристики: операционная система на базе Linux (RedHatEnterpriseLinux (версии 6.х или новее), Ubuntu (версии 16.04 или новее), Debian(версии 7.х или новее)); конфигурация SSH с «пробросом» Х11.
Тестовая документация	План тестирования, сценарии тестирования, отчёт по проведённому тестированию программного пакета.
Стратегия проведения тестирования	Необходимые уровни тестирования: интеграционное;
Стратегия проведения тестирования	системное; приёмочное. Необходимые виды тестирования: По объекту тестирования: функциональное тестирование (функциональное, регрессионное); нефункциональное тестирование (тестирование надежности). По времени проведения (бета тестирование). По виду позитивности сценариев: позитивные тесты; негативные тесты. По степени автоматизации (ручное тестирование). Метод проведения тестирования: метод «чёрного ящика».
График тестирования	Тестирование проводится после разработки программного пакета и его интеграции в программно-аппаратную среду.

2.3.4 План тестирования лабораторной работы №6

При тестировании лабораторной работы №6 на OpenSourceинструментах, также необходимо составить план проведения процесса данного тестирования. Тест план представлен в таблице 7.

Таблица 7 План тестирования лабораторной работы №6

Пункт плана тестирования	Содержание
Введение в тестирование ПО	Программный пакет, подлежащий тестированию: ApacheKafka, SparkStreaming. Программный продукт будет использоваться для обучения навыкам работы с неструктурированными и структурированными данными в реальном времени и осуществления обработки этих данных. Программный продукт будут использовать студенты образовательных программ, направленных на изучение методов работы с большими данными.
Объём работ	Функции, подлежащие тестированию: запусквеб-консолиSpark Streaming; работоспособность основных операторов SparkStreaming; создание потоков данных, управление потоками данных.
Критерии качества и приёмки	Критерии качества: работоспособность функций программного пакета;
Критерии качества и приёмки	функционирование программного пакета в программно-аппаратной среде (окружении). Условия завершения процесса тестирования: работоспособность функций программного пакета является схожей с заменяемой проприетарной технологией платформы IBMWatson; стабильное функционирование программного пакета в программно-аппаратной среде (окружении).
Критические факторы успеха	Критические факторы успеха: отсутствие задержек от команды разработчиков; полноценный доступ в систему отслеживания ошибок; качественное проведение менеджмента процесса разработки и тестирования программного пакета.
Оценка риска	Возможные риски: разработка программного пакета идёт не в срок; тестирование программного пакета идёт не в срок; разработанный программный пакет на инструментах с открытым исходным кодом не повторяет исходную функциональность платформы IBMWatson; ...

Подобные документы

• Автоматизация тестирования крупных приложений

  Подходы и алгоритмы автоматизации тестирования. Анализ специфики работы с локальными и веб-приложениями, внедрение автоматических тестов в процесс контроля качества приложений Global XB, GCube и Thistle. Оптимальный инструмент разработки скриптов.
  
  дипломная работа [1,5 M], добавлен 15.01.2012
  

• Распределенная разработка программного обеспечения

  Понятие и ключевое отличие распределенной разработки программного обеспечения, его достоинства и недостатки. Концептуальное решение и выбор типа разработки. Особенности программного обеспечения с открытым исходным кодом. Идея и развитие Open Source.
  
  курсовая работа [97,7 K], добавлен 14.12.2012
  

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

  Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.
  
  курсовая работа [112,2 K], добавлен 22.03.2015
  

• Open Source программные продукты. On-line инструменты

  Характеристика программных продуктов Open Source: Umbrello - среды UML-моделирования на языке, Rational Rose - средства визуального моделирования объектно-ориентированных информационных систем. Описание и сравнение сайтов по созданию онлайн UML диаграмм.
  
  контрольная работа [1,5 M], добавлен 03.11.2013
  

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

  Экономика тестирования. Режим проверки программы на ошибки в режиме "черного" и "белого ящика". Принципы ее проведения. Философия тестирования. Пошаговая, восходящяя, нисходящяя проверка модулей. Метод "большого скачка". Модифицированный метод сандвича.
  
  презентация [585,4 K], добавлен 19.09.2016
  

• Технология разработки программных продуктов

  Этапы технологического процесса разработки программных продуктов, их жизненный цикл. Общая характеристика языков программирования. Виды ошибок и принципы тестирования программ. Установление прав собственности на продукт посредством лицензий и контрактов.
  
  презентация [1,9 M], добавлен 01.05.2011
  

• Разработка программы проверки знаний для тестирования студентов по программированию с кодом на языке Delphi

  Проектирование программы в среде Delphi для тестирования знаний студентов по программированию, с выводом оценки по окончанию тестирования. Разработка экранных форм и алгоритма программы. Описание программных модулей. Алгоритм процедуры BitBtn1Click.
  
  курсовая работа [365,0 K], добавлен 18.05.2013
  

• Качество, надежность и тестирование программных средств

  Тестирование как процесс выполнения программы с намерением найти ошибки. Шаги программы при тестировании, его оценка и значение. Роль информационных потоков тестирования, оценивания и отладки. Особенности структурного и функционального тестирования.
  
  презентация [574,8 K], добавлен 22.03.2014
  

• Комплексное тестирование

  Особенности тестирования стрессов, объема, требований к памяти, средств восстановления и защиты, совместимости и настройки. Проведение тестирования удобства обслуживания и психологических факторов. Выполнение комплексного теста ГОСТ Р ИСО/МЭК 12119-2000.
  
  презентация [1,0 M], добавлен 19.09.2016
  

• Автоматизация тестирования программных систем средствами Java технологий

  История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
  
  курсовая работа [309,5 K], добавлен 16.12.2015
  

• Повышение эффективности usability-тестирования пользовательских интерфейсов с использованием метода Eye-tracking

  Основные стандарты usability-тестирования интерфейсов информационных систем. Количественные и качественные методы оценки тестирования. Технология Eye-tracking. Постановка целей и задач для тестирования сайта Налоговой службы Российской Федерации.
  
  дипломная работа [3,3 M], добавлен 11.06.2017
  

• Разработка Linux-приложений

  Знакомство с этапами разработки трёх приложений для системы семейства Linux с использованием языка программирования С++. Анализ особенностей операционной системы Ubuntu 12.10. Характеристика способов тестирования команд с помощью стандартных средств.
  
  контрольная работа [732,1 K], добавлен 06.08.2013
  

• Разработка программы с помощью языка программирования Delphi

  Разработка программы проверки знаний для тестирования студентов по программированию с кодом на языке Delphi. Проектирование визуального интерфейса и словесный алгоритм работы программы. Алгоритмы разработанных процедур и функций, инструкция пользователя.
  
  курсовая работа [506,5 K], добавлен 21.02.2011
  

• Комплекс мобильных приложений по оказанию автомобильной помощи на дорогах

  Обзор существующих приложений в сфере оказания автомобильной помощи. Рассмотрение алгоритмического конструирования комплекса мобильных приложений по оказанию автомобильной помощи на дорогах. Оценка тестирования авторизации в приложении для водителя.
  
  дипломная работа [1,9 M], добавлен 12.02.2018
  

• Платформа как сервис (PAAS)

  Предоставление интегрированной платформы для разработки, тестирования, развертывания и поддержки веб-приложений как услуги, организованной на основе концепции облачных вычислений. Модели работы для разных групп пользователей; виртуализация, безопасность.
  
  презентация [510,7 K], добавлен 21.02.2012
  

• Проектирование процесса тестирования программного обеспечения

  Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем.
  
  курсовая работа [3,0 M], добавлен 19.11.2009
  

• Разработка web-приложения – CMS (система управления контентом) интернет-маркета

  Описание системы управления реляционными базами данных MySQL. Изучение факторов влияющих на пропускную способность в беспроводных сетях. Особенности применения языка Java Script. Методы тестирования web-приложений. Разработка пользовательского интерфейса.
  
  дипломная работа [2,1 M], добавлен 24.06.2015
  

• Разработка и создание программы компьютерного тестирования

  Создание системы компьютерного тестирования для контроля знаний. Проблемы, возникающие при создании тестовой оболочки в среде Ren`Py. Разработка проектных решений по системе и её частям. Структура тестирования, вопросы и ответы тестирующей системы.
  
  дипломная работа [501,6 K], добавлен 12.09.2016
  

• Разработка защищенной системы тестирования с использованием WEB-программирования

  Организация проверки результатов обучения и оценки знаний, использование систем тестирования, основные требования к ним. Создание современной модели WEB-сервиса тестирования знаний; программная реализация; защита от копирования информации и списывания.
  
  курсовая работа [24,1 K], добавлен 11.05.2012
  

• Разработка приложений для работы с базами данных

  Проектирование системы управления базами данных. Особенности реализации в MS SQL. Разработка пользовательского интерфейса. Тестирование и отладка приложения. Руководство пользователя и системного администратора. Анализ и методы разработки приложений.
  
  курсовая работа [867,9 K], добавлен 16.07.2013
  

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