разработанный программный пакет не запускается в программно-аппаратной среде.

Меры по предотвращению рисков:

контроль этапов разработки;

контроль этапов тестирования;

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

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

Ресурсы

Аппаратные характеристики:

не менее 150 Гб дискового пространства;

не менее 8 Гб оперативной памяти;

не менее 8-ми исполнительных ядер процессора;

доступ в Интернет.

Программные характеристики:

операционная система на базе Linux (RedHatEnterpriseLinux (версии 6.х или новее), Ubuntu

Ресурсы

(версии 16.04 или новее), Debian(версии 7.х или новее));

конфигурация SSH с «пробросом» Х11.

Тестовая документация

План тестирования, сценарии тестирования, отчёт по проведённому тестированию программного пакета.

Стратегия проведения тестирования

Необходимые уровни тестирования:

интеграционное;

системное;

приёмочное.

Необходимые виды тестирования:

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

функциональное тестирование (функциональное, регрессионное);

нефункциональное тестирование (тестирование надежности).

По времени проведения (бета тестирование).

По виду позитивности сценариев:

позитивные тесты;

негативные тесты.

По степени автоматизации (ручное тестирование).

Метод проведения тестирования: метод «чёрного ящика».

График тестирования

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

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

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

Структуру методики комплексного тестирования OpenSource приложений можно изобразить на схеме. Данная методика представлена на рисунке 8.

Рис. 8. Схема методики комплексного тестирования

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

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

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

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

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

Выводы по экспериментальной части

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

3. Практическая часть

3.1 Проведение тестирования лабораторных работ

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

В лабораторных работах №2, №3 и №4 используется программный продукт с открытым исходным кодом - Cloudera. Данный продукт представляет собой OpenSource приложение, с помощью которого управляются развёрнутые кластеры и их компоненты. Следует отметить, что программный продукт Clouderaфункционально подобен проприетарному инструменту платформы IBMWatson- IBMInfoSphereBigInsights. В данный продукт входят программные пакеты ApacheHue иApacheHive. Программный пакет ApacheHue представляет собой веб-редактор, позволяющий загружать различные данные, работать с ними и визуализировать какую-либо информацию. Программный пакет ApacheHive служит хранилищем данных, в котором можно структурировать данные для проведения дальнейшего их анализа. В лабораторной работе №6 используется аналог инструмента IBMInfoSphereStreams платформы IBMWatson - OpenSource продукт потоковой обработки данных SparkStreamingсистемы ApacheKafka.

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

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

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

Перед началом проведения функциональных тестов следует убедиться, что программыPuTTyи Xmingфункционируют согласно параметрам, указанных в методических указаниях к данной лабораторной работе №2. После успешного ввода логина и пароля, а также подключения к удалённому терминалу, следует запустить веб-браузер с помощью команды:chromium-browser&.При правильном проделанном действии откроется окно браузера. Для тестирования функции запуска веб-консоли Cloudera необходимо ввести в адресной строке браузера следующую команду: http://localhost:7180/. При вводе логина и пароля открывается стартовая страница Cloudera, это представлено на рисунке 9.

Рис. 9. Стартовая страница Cloudera

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

Таблица 8 Пример теста на проверку функциональности элемента

Название теста	Шаги	Ожидаемые результаты
Проверка функциональности кнопки «Configuration»	Пользователь проверяет, заблокирована ли кнопка «Configuration». Пользователь нажимает кнопку «Configuration» и ожидает открытия новой вкладки.	Кнопка «Configuration» не заблокирована. Открылась вкладка Configuration.

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

Для проверки функции работоспособности распределённой файловой системы, необходимо следовать написанным тестовым сценариям, которые проверяют правильность функционирования HDFS. В частности, для проверки загрузки файлов в программный продукт, загрузим текстовый файл формата txt (Приложение 2). Эталонные значения сформируем на основе выходных данных в проприетарном инструменте платформы IBMWatson. Далее, проведём сравнение полученных данных с эталонными.

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

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

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

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

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

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

Перед началом проведения функциональных тестов следует убедиться, что программыPuTTyи Xmingфункционируют согласно параметрам, указанных в методических указаниях к данной лабораторной работе №3. После успешного ввода логина и пароля, а также подключения к удалённому терминалу, запуска веб-браузера и веб-консоли Cloudera, необходимо открыть интерфейс ApacheHive. Процесс открытия интерфейса ApacheHive показан на рисунке 10.



Рис. 10. Процесс открытия интерфейса ApacheHive

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

Таблица 9 Пример функционального теста на проверку отображения таблицы

Название теста	Шаги	Ожидаемые результаты
Проверка корректного отображения таблицы news_data	Пользователь нажимает на кнопку «ввод запроса». Пользователь вводит в поле запрос: select * fromnews_data. Пользователь нажимает кнопку «выполнить запрос». Пользователь проверят отображение таблицы news_data.	Открылось поле для ввода запроса к базе данных. Запрос успешно появился в поле. Запрос начинает выполнятся. Запрос выполнился и отобразилась таблица news_data.

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



Рис. 11. Результат выполненного функционального теста

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

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

Название теста	Шаги	Ожидаемые результаты
Проверка преобразования данных таблицы news_data	Пользователь нажимает на кнопку «ввод запроса». Пользовательвводитвполезапрос: selecttags, country, type, subjecthtmlfromnews_data. Пользователь нажимает кнопку «выполнить запрос». Пользователь проверят преобразование данных таблицы news_data.	Открылось поле для ввода запроса к базе данных. Запрос успешно появился в поле. Запрос начинает выполнятся. Запрос выполнился и отобразилась таблица news_data с преобразованными данными.

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

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

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

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

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

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

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

Перед началом проведения функциональных тестов следует убедиться, что программыPuTTyи Xmingфункционируют согласно параметрам, указанных в методических указаниях к данной лабораторной работе №4. После успешного ввода логина и пароля, а также подключения к удалённому терминалу, необходимо проверить работоспособность распределённой файловой системы HDFC не через веб-консоль ApacheHue, а через сам терминал. А также проверить работоспособность функции подключения к данному хранилищу. Для этого выполняются проверки по тестовому сценарию, который описывает проверку работоспособности файловой системы и подключения к хранилищу с помощью нескольких тестов работы с терминалом. Пример одного из тестов, проверяющих настройку окружения, представлен в таблице 11.

Таблица 11 Пример функционального теста на проверку настройки окружения в терминале

Название теста	Шаги	Ожидаемые результаты
Проверка настройки окружения в терминале	Пользователь вводит в терминале команду: sourceenviromsetup.shдля запуска установленного скрипта. Пользователь нажимает кнопку «Enter» на клавиатуре. Пользователь просматривает результат выполнения скрипта enviromsetup.sh. Пользователь вводит в терминале команду: hdfcdfc -ls/. Пользователь нажимает кнопку «Enter» на клавиатуре. Пользователь проверят, что на экране терминала отображается информация.	Терминал позволяет вводить значения, отображаются значения, вводимые пользователем. Скрипт начал выполнятся. Скрипт выполнился, на экране терминала появилась информация результата выполнения скрипта. Терминал позволяет вводить значения, отображаются значения, вводимые пользователем. Терминал начал обрабатывать команду. На экране терминала появилась информация результата выполнения команды.

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

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

Название теста	Шаги	Ожидаемые результаты
Проверка создания базы данных в хранилище ApacheHive	Пользователь вводит в терминале команду: sourcecreatebase.sqlдля запуска установленного скрипта. Пользователь нажимает кнопку «Enter» на клавиатуре. Пользователь просматривает результат выполнения скриптаcreatebase.sql в терминале.	Терминал позволяет вводить значения, отображаются значения, вводимые пользователем. Скрипт начал выполнятся. Скрипт выполнился, на экране терминала появилась информация результата выполнения скрипта.

Содержимое скрипта createbase.sql, используемого для создания базы данных в хранилище ApacheHive, показано рисунке 12.

Рис. 12. Скрипт createbase.sql создания базы данных

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

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

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

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

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

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

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

Перед началом проведения функциональных тестов следует убедиться, что программыPuTTyи Xmingфункционируют согласно параметрам, указанных в методических указаниях к данной лабораторной работе №6. После успешного ввода логина и пароля, а также подключения к удалённому терминалу, следует запустить веб-браузер с помощью команды: chromium-browser&.При правильном проделанном действии откроется окно браузера. Для тестирования функции запуска веб-консоли SparkStreaming необходимо ввести в адресной строке браузера следующую команду: http://localhost:8080/. При вводе логина и пароля открывается стартовая страница SparkStreaming, это представлено на рисунке 13.

Рис. 13. Стартовая страница SparkStreaming

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

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

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

Название теста	Шаги	Ожидаемые результаты
Проверка создания потока структурированных данных	Пользователь вводит в терминале команду: kafka-consolerodstream.shдля запуска установленного скрипта. Пользователь нажимает кнопку «Enter» на клавиатуре. Пользователь просматривает результат выполнения	Терминал позволяет вводить значения, отображаются значения, вводимые пользователем. Скрипт начал выполнятся. Скрипт выполнился, на экране терминала появилась информация результата выполнения скрипта.
Проверка создания потока структурированных данных	скрипта rodstream.sh в терминале.

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

Следует отметить, что количество данных, содержащихся в потоке довольно велико (Приложение 5). Эталонные значения сформируем на основе выходных данных в проприетарном инструменте платформы IBMWatson. Далее, проведём сравнение полученных данных с эталонными.



Рис. 14. Потоки данных SparkStreaming

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

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

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

3.2 Результаты тестирования

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

Приведём сводную информацию по результатам комплексного тестирования. Данная информация представлена в таблице 14.

Таблица 14 Сводная информация результатов тестирования

Параметр	Результат
Количество проверяемых крупных функций, вошедших в планы тестирования, шт	13
Общее количество проверяемых функций, шт	68
Количество подготовленных тестовых данных, Кбайт	632
Количество подготовленных тестов, шт	96
Количество положительных результатов, шт	92
Количество отрицательных результатов, шт	4
Затраченное время на проведение комплексного тестирования, ч	24

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

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

Заключение

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

Решены следующие задачи:

1. Проанализированы и описаны уровни и виды тестирования, которые составляют основу проведения комплексного тестирования методом «чёрного ящика», написана технология проведения тестирования.

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

3. Написаны подробные планы тестирования по лабораторным работам на инструментах с открытым исходным кодом для проверки соответствия функционала по сравнению со старыми. Разработана методика проведения комплексного тестирования. По данной методике проведено комплексное тестирование лабораторных работ, выполненных на OpenSource. По итогам тестирования составлены отчёты и приведена сводная таблица, отражающая информацию по всем полученным результатам. Благодаря методике комплексного тестирования удалось сократить временные затраты на проведение процесса комплексного тестирования на 40%.

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

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

Список использованных источников

1. ISO/IEC/IEEE 29119-2:2013(E) «Software and systems engineering - Software testing - Part 2: Test processes».

2. ISO/IEC/IEEE 29119-4:2015(E) «Software and systems engineering - Software testing - Part 4: Test techniques».

3. Липаев В.В. Тестирование крупных комплексов программ на соответствие требованиям. М.: ИПЦ «Глобус», 2008. - 376 с.

4. Котляров В.П., Основы тестирования программного обеспечения: Учебное пособие / В. П. Котляров, Т. В. Коликова - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006. - 285 с.

5. Labiche Y. et al. Testing levels for object-oriented software //Proceedings of the 22nd international conference on Software engineering. - ACM, 2000. - P. 136-145.

6. Рудакова Г. М., Кожевников Д. О. Разработка метрик сложности кода модуля тестов //Образовательные ресурсы и технологии. - 2017. - №. 2 (19).

7. Лысенко И. А., Смирнов А. А., Мелешко Е. В. Исследование уровней тестирования программного обеспечения инфотелекоммуникационных систем //Наука и Техника. - 2014. - №. 4. - С. 79-81.

8. Ошманов А. Ю., Григорьев Я. Ю., Петрова А. Н. Организация работ по сопровождению информационной системы ВУЗа //Интернет-журнал Науковедение. - 2013. - №. 4 (17).

9. Борисова Т. М., Задача тестирования аппаратных средств защиты информации. (дата обращения: 18.02.2019 г.).

10. Сортов А. А., Хорошилов А. В. Функциональное тестирование Web-приложений на основе технологии UniTesK //Труды Института системного программирования РАН. - 2004. - Т. 8. - №. 1.

11. Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. - Лори, 2003.

12. G.J. Myers, The Art of Software Testing, John Wiley & Sons, New York, 1976.

13. Иванников В.П., Петренко А.К. Модели в разработке и анализе программных систем. - Ломоносовские чтения, 2011.

14. S. Rapps and E.J. Weyuker, “Selecting Software Test Data Using Dataflow Information,” IEEE Trans. Software Eng., Vol. 11, No. 4, Apr. 1985, P. 367-375.

15. J.A. Whittaker and M.G. Thomason, “A Markov Chain Model for Statistical Software Testing,” IEEE Trans. Software Eng., Vol. 20, No. 10, Oct. 1994, P. 812-824.

16. D.K. Peters and D.L. Parnas, “Using Test Oracles Generated from Program Documentation,” IEEE Trans. Software Eng., Vol. 24, No. 3, Mar. 1998, P. 161-173.

17. D. Knuth, “Literate Programming,” The Computer J., Vol. 27, No. 2, May 1984, P. 97-111.

18. G. Rothermel and M.J. Harrold, “A Safe, Efficient Algorithm for Regression Test Selection,” Proc. IEEE Software Maintenance Conf., IEEE Computer Soc. Press, Los Alamitos, Calif., 1993, P. 358-367.

19. Липаев В.В. Тестирование компонентов и комплексов программ. - М.: СИНТЕГ, 2010. - 400 с.

20. B. Beizer, Software Testing Techniques, Van Nostrand Reinhold, New York, 1990.

21. J.B. Goodenough and S.L. Gerhart, “Toward a Theory of Test Data Selection,” IEEE Trans. Software Eng., Vol. 2, No. 2, June 1975, P. 156-173.

22. J.D. Musa, “Software Reliability Engineered Testing,” Computer, Vol. 29, No. 11, Nov. 1996, P. 61-68.

23. J.M. Voas, “PIE: A Dynamic Failure-Based Technique,” IEEE Trans. Software Eng., Vol. 18, No. 8, Aug. 1992, P. 717-727.

24. M. Sharma and B. S. Chandra, “Automatic Generation of Test Suites from Decision Table - Theory and Implementation,” in Software Engineering Advances (ICSEA), 2010 Fifth International Conference on, 2010, P. 459 -464.

25. M. R. Keyvanpour, H. Homayouni, and H. Shirazee, “Automatic Software Test Case Generation,” Journal of Software Engineering, vol. 5, no. 3, P. 91-101, Mar. 2011.

26. H. Liu and H. B. Kuan Tan, “Covering code behavior on input validation in functional testing,” Information and Software Technology, vol. 51, no. 2, P. 546-553, Feb. 2009.

27. P. Mitra, S. Chatterjee, and N. Ali, “Graphical analysis of MC/DC using automated software testing,” in Electronics Computer Technology (ICECT), 2011 3rd International Conference on, 2011, vol. 3, P. 145 -149.

28. F. Saglietti, N. Oster, and F. Pinte, “White and grey-box verification and validation approaches for safety- and security-critical software systems,” Information Security Technical Report, vol. 13, 2008, no. 1, P. 10-16.

29. P. Jorgensen, Software testing: a craftman's approach, CRC Press, 2002. P. 359.

30. T. Murnane and K. Reed, “On the effectiveness of mutation analysis as a black box testing technique,” in Software Engineering Conference, 2001. Proceedings. 2001 Australian, 2001, P. 12 - 20.

31. G. Baradhi and N. Mansour, “A Comparative Study of Five Regression Testing Algorithms”, Proceedings of Software Engineering Conference, Australian, 1997, P.174-182.

32. Кутепов И.П. Применение технологии комплексного тестирования приложений // Межвузовская научно-техническая конференция студентов, аспирантов и молодых специалистов им. Е.В. Арменского. Материалы конференции. - М.: МИЭМ НИУ ВШЭ, 2019. - С. 79-80.

33. Шмид А. В., Позин Б. А., Галахов И. В., Агейкин М. А., Александров Д. О., Касимов М. Р., Клемашев Н. И., Ежов Г. А. Новые методы работы с большими данными: победные стратегии управления в бизнес-аналитике: Научно-практический сборник. Под редакцией д.т.н., проф. А. В. Шмида. - М.: ПАЛЬМИР, 2016. - 528 с.

34. Shmid A., Pozin B., Ageykin M. Teaching Big Data Technology Practices in Cloud Environment, in: Smart Education and e-Learning 2016 Issue 59. - Switzerland: Springer International Publishing, 2016. P. 631-639.

35. Петренко А.К., Позин Б.А. Практические и теоретические направления развития автоматизированного тестирования. Труды III Научно-практической конференции «Актуальные проблемы системной и программной инженерии». - М. МЭСИ 2013 г., с.с.138-144.

Приложение 1

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

Рис. 15. Диаграмма Гантта

Приложение 2

Пример части структуры файла для загрузки в лабораторную работу №2 с неструктурированными данными.

Рис. 16. Часть структуры файла для загрузки в лабораторную работу №2

Приложение 3

Пример структуры файлов базы данных для загрузки в лабораторную работу №3.

Рис. 16. Часть структуры базы данных файла blogsdata для загрузки в лабораторную работу №3



Рис. 17. Часть структуры базы данных файла newsdata для загрузки в лабораторную работу №3

Приложение 4

Пример части структуры файла форматов jsonи csv, загружаемые в лабораторную работу №4.

Рис. 18. Часть структуры файла формата json для загрузки в лабораторную работу №4



Рис. 19. Часть структуры файла формата csvдля загрузки в лабораторную работу №4

Приложение 5

Пример части структуры файла, содержащий потоковые данные, выгружаемые из программного пакета SparkStreaming лабораторной работы №6.

Рис. 20. Часть структуры файла потоковых данных из SparkStreaming

Размещено на Allbest.ru

...