1.2 Краткое описание системы W-NMS - LMS
реклама
Федеральное государственное автономное образовательное учреждение высшего профессионального образования Национальный исследовательский университет Высшая школа экономики НИУ ВШЭ-Нижний Новгород Факультет информатики, математики и компьютерных наук Выпускная квалификационная работа на тему Разработка приложения для автоматизированного тестирования системы мониторинга и поддержки сети UMTS Студент группы 11 ПМИ Маркова Ольга Оценка за работу____________ Руководитель: Егоров Е.Е. к.т.н., доцент кафедры Мера ___________ Нижний Новгород 2015 Содержание 1. Введение и постановка задачи 3 1.1. Краткое описание UMTS-сети 5 1.2. Краткое описание системы W-NMS 7 1.3. Описание конфигурационной подсистемы 7 1.4. Постановка задачи 8 2. Техническое задание 10 2.1. Наименование и область применения 10 2.2. Назначение разработки 10 2.3. Технические требования к программе 10 3. Анализ технического задания 15 3.1. Выбор прикладных средств 15 3.2. Выбор языка программирования 15 4. Описание прикладных средств для решения поставленной задачи 17 4.1. Краткое описание языка TCL 17 4.2. Краткое описание языка WICL 17 5. Проектирование и разработка системы 18 5.1. Общий алгоритм работы тестовой процедуры 18 5.2. Общий алгоритм работы тестового сценария 19 5.3. Общий алгоритм работы тестовой кампании 22 5.4. Реализация тестовых процедур 23 5.5. Организация взаимодействия с системой WAT Engine 24 5.6. Организация запуска программы 28 2 6. Описание программы 29 6.1. Структура каталогов и файловый состав программы 29 6.2. Описание работы приложения 30 6.3. Инструментальные средства компиляции и компоновки 33 7. Руководство пользователя и программиста 35 7.1. Описание графического интерфейса пользователя 35 7.2. Запуск тестов терминально 39 7.3. Добавление тестовых процедур, тестовых сценариев и тестовых кампаний 40 8. Анализ результатов работы системы тестирования 41 9. Заключение 44 Список литературы 45 3 1. ВВЕДЕНИЕ И ПОСТАНОВКА ЗАДАЧИ Тестирование — один из важнейших этапов разработки программного обеспечения, направленная на обнаружение неисправностей с целью повышения качества продукта. По статистике, около 40% от всего времени разработки ПО затрачивается на мероприятия по тестированию. Процесс тестирования нацелен на нахождение и устранение ошибок (дефектов) во время разработки ПО, а также на то, чтобы проверить продукт на соответствие функциональным возможностям и требованиям по качеству, предъявляемым к нему. Процесс тестирования связан с определеным рядом проблем: Тестирование требует затрат большого количества времени и человеческих ресурсов в связи с множеством требований, предъявляемых к надежности и качеству продукта. Поскольку программный продукт постоянно развивается, расширяет функционал, необходимо постоянное тестирование этого функционала. Жесткие временные рамки, а так же желание разработчика вывести продукт на рынок за короткий срок отрицательно сказывается на качестве ручного тестирования, так как ручное тестирование связано с трудоемкостью и отнимает много времени. Процесс тестирования зачастую монотонен и однообразен, что способствует низкой мотивации инженеров по тестированию. Правильное распределение материальных и человеческих ресурсов является наиважнейшей проблемой процесса разработки в целом и процесса тестирования в частности. Внедрение автоматизированного тестирования в процесс разработки способствует решению данной проблемы, помогая сократить время тестирования и, как следствие, снизить затраты. 4 1.1 Краткое описание UMTS-сети UMTS (Universal Mobile Communications System) – универсальная мобильная телекоммуникационная система, разработанная Европейским институтом по стандартизации в области коммуникаций (European Telecommunications Standards Institute, ETSI)1. В качестве способа передачи данных через воздушное пространство использует технологию W-CDMA – Wideband Code Division Multiple Access, основным принципом которой является использование широкополосного множественного доступа с кодовым разделением каналов. UMTS-система сконструирована из комбинации двух основных подсистем: Рисунок 1.1 – Архитектура UMTS-сети Access network – сеть доступа – предоставляет средства передачи данных между UE и базовой сети и включает в себя следующее оборудование: - UE – User Equipment – точка доступа пользователя к системе UMTS (например, мобильный телефон); UMTS [Электронный ресурс] / Википедия – свободная энциклопедия. – URL: https://ru.wikipedia.org/wiki/UMTS (Дата обращения: 03.03.2015). 1 5 - BTS – Base Transceiver Station – базовая телефонная станция, осуществляет маршрутизацию данных контроллеру, распределение и контроль за нагрузкой каналов; - Node B – логическая часть BTS; - RNC – Radio Network Controller – контроллер управления радиосетью, отвечает за управление базовыми станциями, мягкий хэндовер и выделение радиоресурсов. Core network – базовая сеть – ядро сетей сотовой связи, осуществляет управление сетями доступа, предоставляет средства для коммутации пакетов и коммутации каналов: - TRAU - Transcoder/ Rate Adapter Unit – блок транскодирования и адаптации скоростей, осуществляет конвертирование голосовых пакетов в формат ISDN 64 kbps; - MSC – Mobile Switching Center – центр коммутации мобильной связи, координирует вызовы подсистемы базовых станций и внешних сетей, выполняет жесткий хэндовер, айтентификацию абонентов; - VLR – Visitor Location Register – гостевой регистр местоположения, предназначен для хранения данных всех абонентов, зарегистрированных в данной сети; - HLR – Home Location Register – домашний регистр местоположения, представляет собой базу данных, хранящую наиболее полную информацию об абонентах (идентификаторы, подключенные услуги, текущее местоположение и т.д.); - AuC – Authentification Center – центр аутентификации абонентов, хранит данные, необходимые для аутентификации абонентов; - SGSN – Serving GPRS Support Node – узел обслуживания абонентов GPRS, управляет GPRS сессиями абонентов, передает данные между RNC и GGSN; - GGSN – Gateway GPRS Support Node – узел доступа к внешней сети, обеспечивает доступ к внешний ip-сетям. 6 1.2 Краткое описание системы W-NMS Система W-NMS (Wireless Network Management System) была разработана одним из заказчиков компании МЕРА и предназначается для управления UTRAN (UMTS Terrestrial Radio Access Network) частью UMTSсети. А именно, для организации центрального управления над следующим основным оборудованием, произведенным корпорацией-заказчиком: RNC, BTS, OneBTS и WCEPlatform (Wireless Cloud Element). Система W-NMS устанавливается на платформы фирмы Sun Microsystems. Операции, осуществляемые с помощью W-NMS, относятся к следующим основным функциональным областям: Configuration Management (CM) – конфигурирование параметров объектов UTRAN сети UMTS; Fault Management (FM) – управление сбоями – данная функциональная область предоставляет информацию о всех существующих и возникших на данный момент неисправностях; Performance Management (PM) – управление производительностью – предоставление оператору сети информации о производительности отдельных объектов и сети в целом; Security Management – управление безопасностью сети. 1.3 Описание конфигурационной подсистемы CM – конфигурационная подсистема, которая обеспечивает следующую функциональность: онлайн конфигурирование – изменение значений аттрибутов, создание и удаление подобъектов посредством импорта xml-файлов; оффлайн конфигурирование – создание и удаление объектов сети; загрузка программного обеспечения на объекты сети; резервное копирование и восстановление данных объекта; установка и разрыв соединения между сервером и реальным объектом. 7 1.4 Постановка задачи Поскольку конфигурационная подсистема является одной из важнейших составляющих системы W-NMS, так как позволяет управлять всей функциональностью объектов подсети UTRAN, то необходимо, чтобы данная подсистема работала без сбоев и ошибок. Последствия от сбоев связанных с неправильно сконфигурированной UTRAN-подсетью могут привести к значительным финансовым потерям поставщиков услуг UMTS и значительным затратам на устранение неисправностей в данной подсистеме. Задача по контролю корректного функционирования данной подсистемы может быть решена с помощью создания автоматизированной системы тестирования этой подсистемы. Наличие данного программного обеспечения в вышеупомянутой подсистеме позволит искать, анализировать и устранять ошибки в CMподсистеме W-NMS на различных этапах создания и эксплуатации конфигурационной подсистемы. Система тестирования должна выполнять следующие операции: проверять функциональность CM-подсистемы; обнаруживать ошибки в работе CM-подсистемы; анализировать ошибки и указывать на возможные причины данных ошибок. Система тестирования должна обеспечивать проверку основной функциональности CM-подсистемы и быть расчитанной для запуска тестов на любой из следующих стадий тестирования: Sanity- стадия, на которой проводится минимальный набор тестов для проверки основной функциональности CM-подсистемы для каждой поддерживаемой версии W-NMS. Это тесты на возможность создания и удаления объектов сети; проверка на корректность архитектуры объектов и т.д. 8 Functional- стадия, на которой выполняется проверка полной функциональности исследуемой подсистемы. Regression – повторение некоторых тестов после обнаружения ошибок и ответных изменений, внесенных дизайнерами. Выбираются главные тесты из каждого вышеописанного раздела, т.е. тесты, выявившие наиболее критичные и «необходные» моменты в процессе тестирования ПО. Regression тесты в некоторой степени напоминают Sanity тесты. На этом этапе важно не только внимательно повторно пройти все опасные моменты и подтвердить исправление найденных ранее ошибок, но и убедиться, что в результате модификаций дизайнеров не пострадали другие (ранее работающие правильно) элементы. Система тестирования не должна оказывать влияние на тестируемую подсистему (вносить какие-либо изменения в ее функциональность). Пользователями Системы тестирования являются: в случае тестирования подсистемы после модификации кода – инженер-программист, вносящий изменения в исходный код; в случае периодического тестирования корректного функционирования СМ-подсистемы – инженер-тестер данной подсистемы. Система тестирования должна использовать интерфейс системы WAT Engine и иметь возможность запускаться как с использованием графического интерфейса, так и в терминальном режиме. 9 2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ 2.1 Наименование и область применения Полное наименование программного продукта: «Приложение автоматизированного тестирования системы мониторинга и поддержки сети UMTS». Далее для условного обозначения программного продукта используется сокращение «Система тестирования», хотя следует сразу оговориться, что в данной дипломной работе подробно описывается одна из трех основных частей системы тестирования, предназначенная для проверки конфигурационной части W-NMS. Система тестирования предназначена для применения в операционной среде мобильной телефонии W-NMS (Wireless Network Management System). В частности, Система тестирования используется для тестирования CMподсистемы W-NMS (CM – Configuration Management – подсистема для конфигурирования параметров объектов сети UMTS) на различных этапах создания программного обеспечения. 2.2 Назначение разработки Система тестирования предназначена для поиска, анализа и устранения ошибок в CM-подсистеме W-NMS на различных этапах создания программного обеспечения. 2.3 Технические требования к программе 2.3.1 Требования к структуре Системы тестирования Система тестирования должна состоять из тестовых процедур, тестовых сценариев и кампаний тестов. Тестовая процедура представляет собой некоторые элементарные действия, выполняемые с целью тестирования определенного элемента программного обеспечения. Тестовые процедуры не могут содержать другие тестовые процедуры и тестовые сценарии. 10 Тестовый сценарий представляет собой совокупность тестовых процедур и тестовых сценариев более низкого уровня иерархии. Тестовая кампания является набором нескольких тестовых сценариев, логически объединенных с целью параллельного либо последовательного запуска тестов. Структура Системы тестирования должна быть расширяемой, то есть должна быть возможность добавлять другие тестовые процедуры, тестовые сценарии и кампании тестов. Структура Системы тестирования должна быть конфигурируемой, для чего Система тестирования должна содержать конфигурационный файл, определяющий машины, симулирующие поведение объектов сети (ip-адреса, названия профайлов, данные для авторизации и т.д.). Каждая тестовая процедура и тестовый сценарий должен возвращать один из результатов, описание которых приводится в таблице 2.1. Тестовая кампания должна возвращать совокупность результатов по всем тестам, которые она в себя включает. Таблица 2.1 - Возвращаемые значения Возвращаемое Описание значение PASS Тестовая процедура (сценарий) выполнена. Для тестового сценария это означает, что все вложенные тестовые процедуры и сценарии были выполнены. FAIL Тестовая процедура (сценарий) не выполнена. Необходимо корректирование. UNSUPPORTED Тестовая процедура (сценарий) не может быть выполнена в данный момент (например, у объекта отсутствуют подходящие аттрибуты). UNTESTED Тестовая процедура (сценарий) не была 11 запущена на выполнение, так как начальные условия не были выполнены. Выполнение тестового сценария было UNRESOLVED остановлено оператором. 2.3.2 Требования к функциональным характеристикам Система тестирования при запуске должна настраивать все необходимые переменные среды и возвращать их в исходное состояние по завершении работы. Система тестирования должна обеспечивать взаимодействие с объектами UMTS сети версий UA9.0, LR14.0, LR15.0, поднятых на сервере c установленной W-NMS версий LR14.0 и LR15.0. Более ранние версии программы продолжают поддерживаться, но не тестируются как устаревшие. Система тестирования должна обеспечивать проверку основной функциональности CM-подсистемы для указанных выше версий объектов и быть рассчитанной для запуска регрессионных тестов. Система тестирования должна обеспечивать выполнение следующих этапов тестирования: тестирование архитектуры объектов сети: проверку всего дерева объектов на соответствие с СМ-моделью (проверка наличия всех обязательных компонентов и атрибутов, проверка значений атрибутов на допустимые); тестирование ожидаемых ошибок (Error cases) с целью убедиться, что при попытке ввода неверных входных данных W-NMS отреагирует на них соответствующим образом: обязательно должно быть выдано сообщение об ошибке и процесс обработки приостанавливается, ожидая реакции пользователя на ошибку; 12 данных тестирование изменения состояния и атрибутов объектов сети на WNMS. Тестирование изменения состояния и атрибутов объектов сети на W-NMS помимо стадий, характерных для процесса пересылки нотификаций, должно включать проверку возможности смены того или иного состояния или атрибута, смену состояния или атрибута на новый, сверку нового значения состояния объекта или его атрибута со значением, которое должно быть. В процессе работы Система тестирования должна вырабатывать удобочитаемые отчеты о каждой тестовой процедуре, включающие краткое описание теста (тестовой процедуры) и результат ее выполнения. 2.3.3 Условия эксплуатации Для эксплуатации Системы тестирования требуется один работник, обладающий следующим минимальным наборов навыков и знаний: профессиональные навыки работы в операционной системе Sun Solaris; профессиональные навыки работы с системой мониторинга и поддержци UMTS-сети W-NMS; профессиональные навыки работы с системой функционального и модульного тестирования WAT Engine. 2.3.4 Требования к составу и параметрам технических средств Система тестирования должна нормально функционировать при наличии следующего набора технических средств: сервер SunFire T1000 с установленным программным обеспечением: операционная система Sun Solaris версии 10.0 или более поздней, W-NMS версии LR14.0 или более поздней, система функционального и модульного тестирования WAT Engine, интерпретатор языка TCL версии 8.3 или более поздней, командный интерпретатор bash 13 2.3.5 Требования к информационной и программной совместимости В качестве пользовательского интерфейса Система тестирования должна использовать командный и графический интерфейс системы функционального и модульного тестирования WAT Engine. 14 3. АНАЛИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ 3.1 Выбор прикладных средств Наиболее выгодным вариантом обеспечения удобного пользовательского интерфейса, единого для всех разрабатываемых тестовых наборов, явилось использование программного комплекса «WAT Engine», разработчиком которого, обладающим полными правами на его использование, изменение и распространение, является фирма «Мера НН». Другие решения, такие как приобретение коммерческих продуктов сходного назначения или проведение самостоятельных разработок связано с большими экономическими затратами. 3.2 Выбор языка программирования Эффективность работы над тестовым набором, а также степень выполнения требований к расширяемости системы, описанных в техническом задании, во многом зависят от языка программирования, применяемого для создания тестов. Для реализации тестового набора, описываемого данным документом, в качестве основного был выбран язык TCL, что обусловлено следующими причинами: TCL является интерпретируемым языком, поэтому для выполнения программы, написанной на этом языке компиляция не требуется; Данный язык обладает мощным инструментарием для работы с текстом, что очень важно для реализации данного проекта; TCL уже использовался для написания других тестовых наборов, что позволит сэкономить время при создании основы данной Системы тестирования; 15 В состав программного комплекса «WAT Engine» входит пакет, написанный на языке TCL, поэтому целесообразно будет использовать этот язык в качестве основного для написания данного программного продукта. Кроме языка TCL был так же использован shell для написания скрипта, отвечающего за запуск тестовых сценариев и контроля результатов их работы. Таким образом у оператора будет возможно запускать тестовые сценарии терминально без знания TCL. Так же, для взаимодействия с интерфейсом тестируемого продукта был использован язык wicl – wireless interface command language, командный язык W-NMS. 16 4. ОПИСАНИЕ ПРИКЛАДНЫХ СРЕДСТВ ДЛЯ РЕШЕНИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ Для реализации системы в качестве основного языка программирования был использован язык TCL. 4.1 Краткое описание языка TCL Язык Tcl/Tk обладает многими свойствами обычных процедурных языков и имеет следующие основные особенности: это язык высокого уровня, что значительно упрощает процесс программирования для решения задачи; это интерпретируемый язык, не требующий компиляции или компоновки написанной программы; это расширяемый язык, позволяющий добавлять в него команды, написанные пользователем на языках С или Tcl; Tcl работает на многих распространенных платформах, а так же позволяет автоматически загружать пользовательские библиотеки Tcl. 4.2 Краткое описание языка WICL WICL – Wireless Internet Command Language – командный язык, позволяющий взаимодействовать с большинством объектов сети UMTS. В целом, WICL обеспечивает доступ к большинству операций W-NMS, позволяя: создавать/удалять/изменять/просматривать управляемые объекты сети; загружать xml-файлы; загружать/активировать программное обеспечение для BTS и RNC; выполнять команды по расписанию. WICL команды могут быть вызваны из командной строки, интегрированной в W-NMS GUI, а так же непосредственно из терминала. 17 5. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА СИСТЕМЫ Согласно требованиям технического задания, необходимо разработать такую структурную схему Системы тестирования, которая включала бы в себя некоторую иерархию тестовых кампаний, сценариев и процедур. При этом необходимо учесть, что в состав любого тестового сценария могут входить как другие тестовые сценарии, так и процедуры. В то же время тестовая процедура является элементарным объектом и не может включать в себя другие тестовые процедуры и сценарии. 5.1 Общий алгоритм работы тестовой процедуры Согласно требованиям технического задания любая тестовая процедура должна возвращать вызвавшему ее тестовому сценарию определенное значение, однозначно определяющее результат выполнения тестовой процедуры. Решение о том, какое значение должно быть возвращено тестовому сценарию, принимается самой тестовой процедурой на основе некоторого воздействия на тестируемую величину или характеристику. Кроме того, любая тестовая процедура должна проверять выполнение условий, необходимых для осуществления такого воздействия. К таким условиям можно отнести наличие необходимых переменных среды, правильность значений параметров, передаваемых тестовой процедуре и т. п. Исходя из этих рассуждений, был разработан общий алгоритм работы тестовой процедуры, блок-схема которого изображена на рисунке 5.1. 18 Рисунок 5.1 - Общий алгоритм работы теста 5.2 Общий алгоритм работы тестового сценария Согласно требованиям технического задания, тестовый сценарий может содержать тестовые процедуры и вложенные тестовые сценарии. Кроме того, тестовый сценарий, аналогично тестовой процедуре, должна возвращать вызвавшему ее тестовому сценарию определенное значение, однозначно определяющее результат выполнения тестовой процедуры. Если тестовый сценарий является главным, то результат его выполнения является конечным результатом. Решение о том, каким должно быть возвращаемое значение, принимается самим тестовым сценарием на основе результатов выполнения всех входящих в него сценариев и процедур. Тестовый сценарий должен быть способен определять результат его выполнения на основании результатов выполнения всех тестовых процедур, которые он вызывает. Результат UNRESOLVED является наиболее приоритетным среди всех возможных, при остановке работы теста оператором тестовый сценарий не должен анализировать результаты выполнения тестовых процедур. Следующий по приоритету результат – UNTESTED, при получении этого результата тестовый сценарий прекращает 19 работу. Результаты PASS, FAIL и UNSUPPORTED тестовфй сценарий получает на основе анализа результатов всех выполненных тестовых процедур. Результат UNSUPPORTED может быть получен только в случае, если результат всех вызванных тестовых процедур UNSUPPORTED. Если данное условие не выполнено, тестовый сценарий должен проверить все значение на наличие результатов FAIL. Если найден хотя бы один – результат тестового сценария так же будет FAIL. Иначе результатом выполнения тестового сценария будет PASS. Итак, наличие среди значений, возвращенных вложенными сценариями и процедурами, хотя бы одного результата FAIL, уже говорит о том, что весь сценарий не выполнен. Поэтому логично при обнаружении первого результата FAIL прекращать выполнение сценария и воспринимать данный результат как возвращаемое значение всего пакета. Однако, для тестов, многократно выполняющих одну и ту же процедуру на разных значениях (например, проверка всех возможных значений аттрибутов), целесообразно продолжать выполнение теста, даже при получении результата FAIL, просто переходя на следующую итерацию. Таким образом тестировщик будет иметь возможность определить все случаи, для которых тест не выполнен. Для того, чтобы однозначно определить поведение тестовой процедуры при получении результата FAIL необходимо ввести переменную “doOnError”. Кроме того, любой тестовый сценарий должен проверять выполнение условий, необходимых для запуска всех вложенных тестовых сценариев и процедур. Такими условиями могут быть правильность параметров, переданных тестовому сценарию, наличие необходимых файлов, существование и состояние тестируемых объектов и т. п. Таким образом, на основе приведенных выше рассуждений был разработан общий алгоритм работы тестового сценария, блок-схема которого изображена на рисунке 5.2. Для обозначения возвращаемого значения вложенных тестовых процедур на рисунке используется переменная RET. Для обозначения общего 20 числа тестовых процедур в составе данного тестового сценария используется переменная N. Для обозначения номера текущей тестовой процедуры используется переменная i. Рисунок 5.2 - Общий алгоритм работы тестового сценария Выбор языка программирования для написания тестов зависит от требований, предъявляемых к Системе тестирования. Никаких ограничений в 21 области нет, поэтому тесты могут быть написаны на любом языке программирования и являться как скриптами, так и исполняемыми файлами. Однако, исходя из соображений единообразия с системой WAT Engine, принято решение выполнить основные тесты в виде TCL-скриптов. 5.3 Общий алгоритм работы тестовой кампании В соответствии с техническим заданием тестовая кампания должна представлять собой совокупность тестовых сценариев, запускаемых как параллельно, так и последовательно. Это облегчит работу тестировщика, позволяя сократить время тестирования. Для осуществления последовательного запуска необходима процедура, предотвращающая запуск тестового сценария, пока предыдущий тестовый сценарий (или совокупность тестовых сценариев, запущенных параллельно) не закончил работу. Тестовая кампания не должна предоставлять совокупного результата тестирования. Результат выполнения каждого тестового сценария кампании будет представлен отдельно. Хотя по условиям технического задания тестовые процедуры не могут включать в себя тестовые сценарии, кампании будут использовать специальную процедуру, отвечающую за запуск тестового сценария с заданными аргументами. При возникновении проблем с выполнением тестового сценария (неправильно заданы аргументы, результат тестового сценария UNTESTED), работа всей компании не должна быть остановлена. Таким образом, на основе приведенных выше рассуждений был разработан общий алгоритм работы тестовой кампании, блок-схема которой изображена на рисунке 5.3. Для обозначения общего числа тестовых сценариев, запущенных параллельно, в составе данной тестовой кампании используется переменная m. Для обозначения общего числа тестовых сценариев, запущенных 22 последовательно, в составе данной тестовой кампании используется переменная N. Рис. 5.3 – Общий алгоритм работы тестовой кампании Из рисунка видно, что тестовая кампания может содержать любое количество вложенных тестовых сценариев, запущенных как последовательно, так и параллельно. 5.4 Реализация тестовых процедур Наличие тестовых процедур значительно упрощает процесс разработки Системы тестирования, так как одна и та же тестовая процедура может быть 23 использована в разных тестовых сценариях. Так же наличие процедур позволяет писать тестовые сценарии и кампании, имея только базовые знания Tcl. Тестовые процедуры будут разделены на несколько типов: Preamble procedures – процедуры проверки выполнения начальных условий. CM procedures – процедуры конфигурационного менеджмента. Common procedures – процедуры, которые могут быть использованы в любом тестовом сценарии (контроль выполнения теста – циклы, остановки; получение данных об объекте и т.д.). Campaign procedures – процедуры для написания тестовых кампаний. В состав Системы тестирования входит некоторое множество процедур. Поэтому встает вопрос о том, как программно реализовать данные процедуры. Рассмотрим два технических решения. Первый вариант реализации выглядит следующим образом. Каждая тестовая процедура реализуется в виде отдельного скрипта или исполняемого файла, т.е. фактически в виде отдельной программы. При этом тестовый сценарий, также представленный отдельным файлом, будет вызывать необходимые ему тестовые процедуры. Второй вариант является более оригинальным с конструкторской точки зрения. В этом случае Система тестирования будет содержать несколько файлов, определяющих тестовые процедуры конкретного типа для определенного объекта (RNC, BTS и т.д.). Этот способ реализации позволит уменьшить количество скриптов, упростив работу с ними. 5.5 Организация взаимодействия с системой WAT Engine Согласно требованиям технического задания программа должна использовать интерфейс системы WAT Engine. Для этого необходимо организовать взаимодействие с данной системой. 24 Все тестовые сценарии, процедуры и библиотеки должны быть доступны на сервере. WAT Engine, получив путь к директории с приложением, загружает конфигурационный файл Системы тестирования, а так же загружает все тесты. WAT Engine является интерфейсом между программным продуктом WAT и пользователем, а также связующим звеном между объектами в W-NMS и симулятором, предназначенным для имитации действий реального оборудования. Модель WAT представлена на рисунке 5.4: Рисунок 5.4 Модель WAT Выходные данные, полученные в результате тестирования, должны быть представлены в удобной для пользователя форме, в виде окна с описанием тестов и статусов соответствующих тестов. Как было сказано ранее, статус теста определяется на основании соответствия ожидаемых и действительных результатов. При выполнении тестов вручную, пользователь 25 сам должен принимать решение о статусе теста. На принятое решение, несомненно, влияют совокупностью факторов, таких как: чистота неоднократно выполненного эксперимента (пользователь должен следить, чтобы каждый раз во время выполнения одного и того же теста, условия, входные данные и внешние факторы, влияющие на эксперимент, были одинаковыми); следование заявленной спецификации (необходимо выполнять только четко оговоренные действия для получения желаемого результата; любые отклонения от описанного алгоритма тестирования, либо замена любой из составляющих тестирования, например, исходных данных, может привести к неправильным результатам); опыт человека, проводящего тестирование (анализ полученных выходных данных и вынесение решения во многом зависит от величины накопленных знаний человеком о предметной области тестируемого оборудования или программного продукта). В случае автоматизированного тестирования, это решение принимается программно, т.е. анализ полученных значений производится без участия человека, а значит, целиком исключается субъективность человеческого фактора. Статус теста определяется только посредством запрограммированного сравнения ожидаемых и полученных результатов эксперимента. Одной немаловажной особенностью автоматизации тестирования является автоматическое ведение Журнала событий (log files). Журналы событий должны содержать подробные сведения о выполняемых действиях во время тестирования. Это позволит пользователю не только видеть на экране статус теста, решение о котором принималось программно, но и самому при желании провести анализ проведенного эксперимента по записям в Журнале событий. Таким образом, задачей приложения WAT является корректная обработка командных файлов для выполнения соответствующих тестов, 26 предоставление полной информации о тестировании посредством записей в Журнале событий, а также вынесение итогового статуса для каждого выполненного теста (тестового сценария). Система тестирования должна поддерживать использование графического интерфейса WAT Engine. 5.8 Организация запуска программы Необходимо предусмотреть запуск Системы тестирования с использование графического интерфейса WAT Engine, а так же терминально. Пользователь должен иметь возможность выполнять настройку конфигурации, проводить тестирование на данной конфигурации, просматривать отчетную информацию о выполнении теста, сохраняемую в Лог файлах. 27 6. ОПИСАНИЕ ПРОГРАММЫ 6.1 Структура каталогов и файловый состав программы Структура каталогов программы отвечает требованиям системы функционального и модульного тестирования WAT Engine. В корневом каталоге программы (/WAT/F_TEST/IntTests/) расположены следующие подкаталоги и файлы: campaigns – директория, в которой хранятся файлы тестовых кампаний; CM – директория, предназначенная для хранения тестовых сценариев СМ-подсистемы. Также данная директория содержит следующие подкаталоги: - lib – директория, содержащая файлы с СМ процедурами; - XML – директория, в которой хранятся xml-модели для всех объектов UMTS-сети; config – директория, содержащая конфигурационные shell-скрипты: - userVariables.sh – скрипт, определяющий ip-адреса симуляторов и названия профайлов. Начальные значения всех переменных не заданы, они должны быть определены оператором в процессе тестирования; - setEnvVariables.sh окружения Solaris, – скрипт, определяющий необходимые для работы переменные Системы тестирования; IntTestsReports – директория, в которой хранятся лог-файлы выполненных тестов. Для каждого теста лог-файл представлен двух форматах – txt (полный лог-файл, отражающий все шаги выполнения тестового сценария и всех тестовых процедур) и html (сокращенный лог, содержащий результаты выполнения всех тестовых процедур, вызванных тестовым сценарием). IntTestsResults – директория, содержащая конечный результат каждого выполненного тестового сценария; 28 lib – директория, содержащая common и campaign procedures; tmp – директория, предназначенная для хранения временных файлов (файлов, используемых для выполнения текущего тестового сценария); runCampaign.sh – скрипт для запуска тестовой кампании; runTest.sh – скрипт для запуска тестового сценария. 6.2 Описание работы приложения Схема взаимодействия модулей приложения изображена на рисунке 6.1: Рисунок 6.1- Схема взаимодействия модулей приложения WAT TestRunner представляет собой совокупность двух shell-скриптов – для запуска тестовых кампаний и тестовых сценариев – осуществляющих контроль за выполнением тестов, сбор логов и вывод результатов. Алгоритм работы скрипта runTest.sh, отвечающего за запуск тестовых сценариев, представлен на рисунке 6.2. 29 Рисунок 6.2 – Алгоритм работы скрипта runTest.sh WAT Engine вызывает скрипт для запуска тестов, передавая ему в качестве аргументов имя теста, директорию в которой он расположен и аргументы теста. Скрипт выполняет необходимые проверки (валидность аргументов, существование теста и т.д.), устанавливает переменные 30 окружения и создает новую поддиректорию в директории IntTestsReports, в которой далее будут созданы Журналы событий (Log file – Лог файл). За все время работы приложения, информация о действиях, выполняемых в Системе тестирования, записывается в Журнал событий. Так же скрипт создает временные файлы и поддиректории в tmp директории, необходимые для выполнения теста. TestRunner сохраняет время, когда тест был запущен и pid процесса на сервере. Когда все приготовления выполнены, запускается тестовый сценарий (аргументы, переданные скрипту, передаются сценарию). Как только управление передано тестовому сценарию, TestRunner приостанавливает свою работу, ожидая пока тестовый сценарий не будет выполнен (в данном случае подразумевается получение какого-либо результата выполнения теста). Далее TestRunner проверяет файл *.sum, созданный тестовым сценарием в директории IntTestsResults/testName. В этот файл уже записан суммарный результат выполнения тестового сценария. Результат выполнения перенаправляется в файл с логами. После этого запускается скрипт, генерирующий отчет теста в html формат. На данном этапе скрипт завершает свою работу. Алгоритм работы скрипта runCampaign.sh, отвечающего за запуск тестовых кампаний, представлен на рисунке 6.3. 31 Рис. 6.3 – Алгоритм работы скрипта runCampaign.sh WAT Engine запускает скрипт на выполнение тестовой кампании, в качестве агрумента передавая ему имя тестовой кампании. Скрипт проверяет существование данной кампании, создает необходимую директорию, записывает начальные данные. Когда все приготовления закончены, скрипт запускает тестовую кампанию, которая в свою очередь последовательно либо параллельно выполняет тестовые сценарии. По окончанию работы последнего тестового сценария управление возвращается данному скрипту, который генерирует суммарный отчет по всем запущенным тестовым сценариям. 6.3 Инструментальные средства компиляции и компоновки Для компиляции и отладки главного скрипта программы использовался командный интерпретатор bash. 32 Для компиляции TCL-скриптов интерпретатор языка TCL версии 8.3. 33 программы использовался 7. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ И ПРОГРАММИСТА 7.1 Описание графического интерфейса пользователя 7.1.1 Запуск Системы тестирования Для реализации пользовательского интерфейса программа использует графический интерфейс системы WAT Engine. Для запуска Системы тестирования с использованием графичесого интерфейса WAT Engine необходимо установить WAT в домашний каталог пользователя, а затем создать в WAT Engine новый проект, подключившись к каталогу home_directory/WAT с помощью кнопки Connect: Рисунок 7.1 Создание нового проекта Рисунок 7.2 Подключение Системы тестирования 34 Несколько проектов могут быть подключены к WAT Engine одновременно и работать параллельно. 7.1.2 Настройка конфигурации Подключив новый проект или открыв подключенный ранее пользователю необходимо указать симуляторы объектов (ip-адреса машин и названия профайлов), которые буду тестироваться. Так же существует возможность указать аутентификационные данные доступа на сервер и к симуляторам. Рисунок 7.3 Запуск конфигурационного окна 35 Рисунок 7.4 Определение окружения 7.1.3 Запуск тестового сценария Все тесты отображаются в левом нижнем углу приложения WAT Engine. Двойной щелчок левой кнопкой мыши по выбранному открывает тестовый сценарий. Чтобы запустить тестовый сценарий на выполнение, необходимо щелкнуть по нему правой кнопкой мыши и выбрать опцию “Launch”. 36 Рисунок 7.5 Запуск тестового сценария В появившемся окне необходимо указать аргументы теста (выбрать из доступного списка либо вписать самостоятельно), после чего запустить тестовый сценарий на выполнение в бэкграунде (кнопка “Launch”), либо с просмотром выполняемых действий (кнопка “Launch and Watch Log”). Рисунок 7.6 Аргументы тестового сценария Оператор может наблюдать за выполнением теста в режиме реального времени. Если была выбрана опция “Launch” без просмотра лога, или лог теста был закрыт, у оператора есть возможность переоткрыть лог в любой момент выполнения теста. 37 Рисунок 7.7 Просмотр журнала событий теста в реальном времени После того как тест будет выполнен, оператор может просмотреть журнал событий данного теста в любое время, пока тест не будет удален из базы. 7.1.4 Запуск тестовой кампании Поскольку тестовая кампания, по сути, является набором вызовов тестовых сценариев, перед запуском ее необходимо сконфигурировать, указав каждому тестовому сценарию необходимые аргументы. Открыть тестовую кампанию в WAT Engine можно двойным щелчком мыши. Так же можно внести необходимые правки терминально, с помощью любого текстового редактора (например, vi). Результаты выполнения тестовой кампании представляют собой набор результатов по каждому тестовому сценарию. Их все можно увидеть из окна Tasks наряду с результатами остальных тестовых сценариев. 7.2 Запуск тестов терминально Оператор имеет возможность не пользоваться графическим интерфейсом приложения WAT Engine, запуская тестовые сценарии из консоли сервера. Для этого оператору необходимо перейти в директорию IntTests и запустить скрипт runTest.sh, указав в качестве аргумента имя тестового сценария (например CM/BTS-OpenLink.test), а так же аргументы данного тестового сценария. 38 Оператор так же имеет возможность запустить тестовую кампанию из консоли сервера. В этом случае необходимо запустить скрипт runCampaign.test из той же директории, в качестве аргумента указав имя тестовой кампании. 7.3 Добавление тестовых процедур, тестовых сценариев и тестовых кампаний Структура Системы тестирования является расширяемой, т. е. позволяет добавлять новые тестовые процедуры, сценарии и кампании. Для добавления тестовой процедуры необходимо создать/изменить библиотеку, в которой будут описаны тестовые воздействия, и сохранить ее в каталоге lib программы. Для добавления тестового сценария необходимо сначала определить, какие действия будет выполнять данный сценарий, т. е. какие тестовые процедуры будут входить в его состав. После этого необходимо создать в одном из каталогов, содержащих тестовые сценарии новый файл “*.test” с осмысленным названием и добавить в него строки с вызовами нужных тестовых процедур. Для добавления новой тестовой кампании необходимо campaigns создать новый файл “*.wcamp” и добавить в него вызовы необходимых тестовых сценариев с заданными аргументами. 39 8. АНАЛИЗ РЕЗУЛЬТАТОВ РАБОТЫ СИСТЕМЫ ТЕСТИРОВАНИЯ Разработанные тесты были запущены на последней версии тестируемого программного обеспечения. По окончании тестирования было собрано время работы каждого теста. Также было подсчитано примерное время выполнения тех же действий на тех же данных вручную. Полученные результаты представлены на рисунке 8.1. 192:00:00 168:00:00 144:00:00 120:00:00 96:00:00 72:00:00 Manual Auto 48:00:00 24:00:00 0:00:00 Рисунок 8.1 Время, затрачиваемое на автоматическое и ручное выполнение тестов Хотя для некоторых тестов разница во времени минимальна, такие тесты как SetOnline или CreateDeleteOnline, подразумевающие под собой создание дополнительных файлов и работу с большим количеством компонентов конфигурационной подсистемы, выполнены в несколько раз быстрее. 40 автоматически будут Безусловно, в реальности ручные тесты не занимают столько времени, так как они выполняются не на всем наборе данных, а лишь на нескольких случайно выбранных компонентах, для того чтобы определить что в целом тестируемый механизм работает. Это, в свою очередь, негативно сказывается на тестовом покрытии и, как следствие, на количестве найденных проблем. Для того, чтобы сравнить эффективность ручного и автоматического тестирования, были собраны следующие тестовые метрики: Testing duration – время тестирования Number of defects found – количество найденных дефектов TC – Test Coverage – тестовое покрытие 𝑇𝐶 = 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑒𝑠𝑡 𝑝𝑟𝑒𝑐𝑒𝑑𝑢𝑟𝑒𝑠 ∗ 100% 𝑇𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑒𝑠𝑡 𝑟𝑒𝑞𝑢𝑖𝑟𝑒𝑚𝑒𝑛𝑡𝑠 Percent Automatable – процент автоматизируемых тестов 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑒𝑠𝑡 𝑐𝑎𝑠𝑒𝑠 𝑎𝑢𝑡𝑜𝑚𝑎𝑡𝑎𝑏𝑙𝑒 ∗ 100% 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑜𝑡𝑎𝑙 𝑡𝑒𝑠𝑡 𝑐𝑎𝑠𝑒𝑠 Automation Progress – прогресс автоматизации. 𝑃𝐴 = 𝐴𝑃 = 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑒𝑠𝑡𝑠 𝑎𝑢𝑡𝑜𝑚𝑎𝑡𝑒𝑑 ∗ 100% 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑒𝑠𝑡𝑠 𝑎𝑢𝑡𝑜𝑚𝑎𝑡𝑎𝑏𝑙𝑒 Все метрики были подсчитаны для случаев автоматического и ручного тестирования конфигурационной подсистемы из рассчета что тестирование выполняется одним тестировщиком. Результаты представлены в таблице 8.1: Таблица 8.1 Метрики тестирования Затраченное Найденные проблемы время покрытие Minor Manual 40:00:00 Тестовое 2 Major Critical 4 3 41 25% Процент автоматизируемых тестов 65% Прогресс автоматизации 0% Последовательно: Auto 119:31:47 9 Параллельно: 7 3 90% 43% 70:03:23 Время автоматического тестирования было подсчитано для двух случаев. В первом случае тесты были запущены последовательно (то есть время тестирования всей подсистемы представляет собой сумму длительностей выполнения каждого теста), во втором случае – параллельно, с использованием тестовых кампаний (в данном случае время тестирования равно времени выполнения самого длительного теста). Хотя время автоматического тестирования в два раза превышает ручное выполнение, тестовое покрытие автоматических тестов в четыре раза выше, чем ручных. Как следствие, количество проблем, найденных при автоматическом тестировании, так же превышает количество проблем, обнаруженных вручную. Таким образом, эффективность тестирования в целом увеличивается при внедрении автоматических тестов. Метрики автоматизированного тестирования показывают долю тестов, котрые в принципе могут быть автоматизированы, и процент уже автоматизированных тестов. Исходя из представленных данных можно сделать вывод, что почти половина всех автоматизируемых тестов были автоматизированы за один спринт, что евляется хорошим показателем производительности. Однако стоит заметить, что такие метрики гораздо эффективнее использовать при наличии нескольких спринтов. В общем и целом, анализ результатов тестирования показал эффективность внедрения автоматических тестов в процесс тестирования. Хотя выполнение автотестов занимает почти в два раза больше времени, чем ручные тесты, они позволяют освободить человеческие ревурсы, так как оператору необходимо лишь запустить отдельные тесты или тестовые кампании и по прошествии определенного количества времени получить результаты тестирования. 42 9. ЗАКЛЮЧЕНИЕ В настоящей пояснительной записке к дипломному проекту приведено подробное описание последовательных этапов создания автоматизированной системы. Исходным документом для создания системы является техническое задание. Наиболее значимыми этапами являются анализ технического задания, разработка структурной схемы системы, разработка основных алгоритмов, создание программного обеспечения. Помимо разделов записки, посвященных этапам проектирования, важное место занимают разделы, описывающие особенности разработанного программного продукта. Результатом проделанной работы является приложение автоматизированного тестирования системы мониторинга и поддержки сети UMTS. Система тестирования является специализированным программным обеспечением, предназначенным для поиска и анализа ошибок в CMподсистеме W-NMS – системе мониторинга и поддержки сети UMTS. Система полностью отвечает требованиям технического задания и является эффективным средством автоматизированного тестирования. Система тестирования предназначена для использования на этапах разработки и поддержки программного обеспечения UMTS-сети. Применение данной системы позволит облегчить труд создания тестовых приложений и процесс тестирования программных модулей, а также значительно уменьшить временные затраты на тестирование. Следовательно, настоящий дипломный практическое применение. 43 проект имеет ценное Список литературы 1. Advanced Bash-Scripting Guide [Электронный ресурс] – Режим доступа: (Дата http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html. обращения: 16.03.2014). 2. An Introduction to Software Test Automation [Электронный ресурс] – Режим доступа: http://www.indicthreads.com/1329/an-introduction-to- software-test-automation. (Дата обращения: 26.11.2014). 3. Tcl commands [Электронный ресурс] http://www.tcl.tk/man/tcl8.3/TclCmd/contents.htm. – Режим (Дата доступа: обращения: 06.02.2014). 4. When Should a Test Be Automated? [Электронный ресурс] – Режим доступа: http://www.exampler.com/testing-com/writings/automate.pdf. (Дата обращения: 13.12.2014). 5. UMTS [Электронный ресурс] – Режим доступа: https://ru.wikipedia.org/wiki/UMTS. (Дата обращения: 03.03.2015). 6. Русская документация по Solaris 10. [Электронный ресурс] – Режим доступа: http://www.unixpin.com/wordpress/2008/10/02/solaris10-russian- docs. (Дата обращения: 22.02.2014). 7. Abran, A. Guide to the Software Engineering Body of Knowledge: 2004 version / A. Abran, J. Moore // SWEBOK. – 2004. – 203 pp. – ISBN 0-76952330-7. 8. Dustin, E. Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality / E. Dustin, T. Garrett, B. Gauf. // Addison-Wesley Professional. – 2009. – 340 pp. – ISBN 978-0321580511. 9. Rossmiller, M. Automation Strategy Out of the Garage / M. Rossmiller // Methods & Tools. – 2001. – pp. 2-7. 10.Rothermel, G. Prioritizing test cases for regression testing / G. Rothermel, R. Untch, C. Chu, M. J. Harrold. – IEEE Transactions on Software Engineering. – 2001. – pp. 929 – 948. 44 11. Дастин, Э. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация / Э. Дастин, Д. Рэшка, Д. Пол; пер. с англ. Е. Молодцова, М. Павлов. – М.: ЛОРИ, 2003. – 589 с. – ISBN 5-85582-186-2. 12. Канер, С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений: Пер. с англ. / С. Канер, Д. Фолк, Е. К. Нгуен. – К.: Издательство «ДиаСофт», 2001. – 544 с. – ISBN 966-7393-87-9. 13.Уэлш, Б. Практическое программирование на Tcl и Tk. / Б. Уэлш, К. Джонс, Дж. Хоббс. 4-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2004. – 1136 с.: ил. ISBN 5-8459-0661-X. 45
