BC/NW 2009; №2 (15):7.1
ОБЕСПЕЧЕНИЕ КАЧЕСТВА СЕТЕВЫХ ПРОГРАММНЫХ
СРЕДСТВ МЕТОДАМИ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ
Позднеев Б.М., Котлячков А.А.
(ГОУ ВПО Московский государственный технологический университет «Станкин» (МГТУ «Станкин»), Россия)
В докладе рассмотрены аспекты обеспечения качества сетевых программных средств на основе применения современных методов и средств автоматизированного тестирования. Высокие требования к качеству сетевых программных средств, тенденция к сокращению сроков их разработки и специфика использования в корпоративных информационных системах, обуславливают необходимость строгого контроля качества на этапах проектирования и разработки. Эффективное применение автоматизированного тестирования позволяет в среднем на 20-30% сократить продолжительность и на 10-15% уменьшить стоимость разработки сетевых программных средств. [1 – 4] При этом существенно повышаются гарантии качества и безопасности продукции, что положительно влияет на её конкурентоспособность.
На основе выполненного анализа обоснована взаимосвязь процессов жизненного цикла программных средств и международных стандартов в области программной инженерии. Проанализированы принципы наследования и влияния качества процессов жизненного цикла на основные характеристики качества сетевых программных средств. Показано доминирующее влияние концептуальной стадии проектирования программных средств на показатели качества, исходя из этого разработаны функциональные и информационные модели, ориентированные на обеспечение качества в жизненном цикле программных средств в соответствии с профилем требований к конечной продукции.
Подробно рассмотрены вопросы применения автоматизированного тестирования в качестве эффективных средств для обеспечения качества сетевых программных средств на этапах проектирования и разработки.
Структурно-функциональное моделирование информационной среды является базой для рационального проектирования процессов и этапов жизненного цикла сетевых программных средств. В соответствии с принципами менеджмента качества (ISO 9000), обеспечение создания сетевых программных средства конкурентоспособного качества может быть представлено в виде структурной схемы (рис 1.)
Обеспечение качества сетевых программных средств методами автоматизированного тестирования
Рис 1. Обеспечение качества сетевых программных средств
Процесс тестирования состоит из основных этапов: анализа требований, разработки тестов, выполнения тестов, документирования (протоколирования результатов), модификации тестов. Следует отметить, что тестирование это многократно повторяемый процесс, где каждой новой итерации соответствует новая тестовая или рабочая версия разрабатываемого программного продукта, содержащая некоторые изменения. Цель каждой итерации – проверка корректности внесенных изменений и работоспособности программного продукта в целом. Под изменением понимается внедренная новая функциональность, модифицированная ранее существующая функциональность или исправленная ошибка.
На практике, процесс тестирования инициируется, когда в службу тестирования передается версия документации, соответствующая текущим изменениям. Модернизация, модификация, внедрение новых программных модулей и исправление ранее найденных ошибок, то есть изменение программного кода приводят к необходимости выполнения новой итерации тестирования. Внедрение новой функциональности требует пересмотра или разработки нового набора тестовых сценариев, а также перепланирования времени выполнения и объема работ в пределах текущей итерации.
На первом этапе необходимо сформировать тестовые данные, которые формируются на основе документации. Требования к СПС необходимы для разработки структуры тестов, контрольного листа и формирования отчета о проделанной работе. Описание функциональности СПС обеспечивает понимание внесенных разработчиками изменений и позволяет создать нетривиальные тестовые случаи. Документация от разработчика позволяет более точно локализовать область тестирования, определить места с наибольшей вероятностью возникновения аномалий.
На втором этапе необходимо разработать новые тесты для проверки новой функциональности, которая появятся в новой версии программы. На основании входных данных разрабатываются тесты для функционального тестирования. При разработке тестов учитываются предыдущий экспертный опыт тестирования, знания структуры и архитектуры объекта тестирования, архив найденных ошибок, знание характерных особенностей работы конкретного разработчика.
На третьем этапе производится функциональное тестирование, реализуемое на основе тестовой сборки новой версии ПС и в соответствии с тестами, разработанными на предыдущем этапе. Выявленные в процессе тестирования ошибки фиксируются и заносятся в систему управления ошибками. В зависимости от сложности исправления, серьезности и критичности, ошибки исправляются на данном этапе или откладываются для дальнейшего планирования разработки. При исправлении найденных на данном этапе ошибок разработчики могут выпускать новые версии ПС. В этом случае тестирование продолжается с новой версией программы. Кроме выполнения заготовленных функциональных тестов, обычно проводится свободное тестирование, целью которого является исследование реакции ПС на не регламентированные действия пользователя. Принимая во внимание факт, что поиск ошибок это процесс практически бесконечный, требуется выбрать наиболее эффективный момент остановки тестирования. Работы по функциональному тестированию могут быть прекращены в момент, либо когда скорость нахождения ошибок существенно снижается, либо отводить на тестирование фиксированный период времени, адекватный количеству внесенных изменений и количеству производственных ресурсов отдела тестирования.
На четвертом этапе выполняется регрессионное тестирование, обеспечивающее полную проверку функциональности ПС предыдущей базовой версии программы. Следует учитывать, что регрессионные тесты не учитывают новую функциональность ПС, которая может повлиять на ожидаемые результаты тестов. Цель регрессионного тестирования - проверить, что изменения не оказали незапланированного влияния на существующую функциональность. Возможно появление ранее исправленных и новых ошибок. В зависимости от сложности исправления, серьезности и критичности, ошибки исправляются на данном этапе или откладываются для дальнейшего планирования разработки. При исправлении найденных на данном этапе ошибок разработчики могут выпускать базовые версии ПС.
На пятом этапе производится модификация регрессионных тестов, учитывающая внесённые в ПС изменения. Это необходимо для выполнения регрессионного тестирования на следующей тестовой итерации. Для обновления регрессионных тестов используются функциональные тесты, при этом каждый функциональный тест обычно является тестовым случаем регрессионного теста.
На шестом этапе подводятся итоги тестирования, на основе которых анализируется кол-во исправленных \ неисправленных, новых ошибок, кол-во удачно \ неудачно внедренных изменений. Составляется отчет о проделанной работе и принимается решение о работоспособности финальной версии ПС.
Модель тестирования позволяет проиллюстрировать процесс
автоматизации тестирования сложного программного средства и выявить его
недостатки. Предварительно следует сказать о некоторых особенностях разработки
СПС:
Высокие требования к характеристикам качества.
Детальное планирование и проектирование.
Высокие эксплуатационные качества.
Время тестирования может существенно превышать время разработки программного продукта.
Больший процент ошибок, которые можно охарактеризовать как критические по методологии RUP.
При автоматизации функционального тестирования используются специализированные программные продукты (тестовые роботы), генерирующие при разработке скриптов тестирования программный код на языке третьего поколения, таких как BASIC, С и т.п. Этот код, входящий в состав скриптов автоматизированного тестирования может быть модифицирован и повторно использован в качестве скриптов автоматизированного тестирования для других приложений в более короткие сроки, чем при разработке новых скриптов. Кроме того, используя приемы программирования, такие как модульность, библиотеки разделяемых функций, использование переменных, передача параметров, условные переходы, циклы, массивы, подпрограммы, можно создать скрипты для выполнения задач по тестированию: тестирование с различными значениями данных, с массивами данных, тестирование характеристик пользовательского интерфейса, нагрузочное тестирование, работа с базой данных. Скрипт может задействовать вызовы прикладного программного интерфейса (API), файлы .dll и повторно используемые библиотеки.
Принцип работы тестового робота заключается в эмуляции действий человека, т.е. фактически роботу под контроль даются устройства ввода (клавиатура, мышь) и загружается программа действий. Функциональное (нагрузочное) автоматизированное тестирование (ФАТ) строится на умении робота различать тестовые объекты. Есть два пути создания ФАТ – запись действий пользователя с помощью встроенного записывающего устройства или написание команд в ручную, оперируя имеющимися в активе объектами и их свойствами. Существует возможность как последовательного выполнения действий, так и создания логических алгоритмов управления действиями. Для взаимодействия с интерфейсом ПС используется система распознавания объектов (кнопок, полей ввода, флагов и т.п.). Возможность распознавания объектов зависит от поддерживаемых роботом технологий (.Net, Java и т.д.) Умение отличать объекты друг от друга и запоминать зависит от способности распознавать свойства объекта (цвет, положение, тип, идентификатор, имя…) Свойства любого объекта можно классифицировать на постоянные и сессионные, уникальные и общие. Программировать робота на тестирование ПС можно, только если он способен опередить постоянные, уникальные свойства тестируемого объекта, то есть такие, которые не меняются со временем (при перезапуске ПС или компьютера) и позволяют однозначно отличить данный объект от других. По причине динамического развития и большого числа технологий разработки ПО часто тестовые роботы не успевают развиваться, чтобы поддерживать новые и модифицирующиеся технологии.
Этапы процесса автоматизации тестирования аналогичны этапам ручного тестирования за небольшим исключением. Регрессионное тестирование, в т.ч. автоматизированные скрипты должны проверять ранее существующую функциональность. Но на каждой новой итерации тестирования, версия тестируемого СПС может содержать изменения в интерфейсе и выполнение скриптов, привязанных к интерфейсу программы, будет нарушено. При появлении изменений интерфейса СПС скрипты требуют дополнительной отладки. Поэтому регрессионное автоматизированное тестирование выполняется с учетом изменений в тестовой версии СПС.
Следует отметить, что время разработки и модификации АТ существенно дольше времени выполнения АТ. Сокращение времени разработки (модификации) АТ позволит существенно уменьшить время, затрачиваемое на тестирование СПС в целом.
Автоматизация
функционального и нагрузочного тестирования позволяет повысить скорость разработки
ПП, снижает затраты ресурсов на самых трудоемких этапах тестирования и в целом
упрощает создание качественного, конкурентоспособного продукта.
Перспективным направлением ускорения разработки ПП является интегрирование инструментов тестирования в среду разработки, что позволяет упростить процесс передачи необходимой технологической информации от разработчиков к тестировщикам, что облегчает реализацию предложенной модели тестирования.
В заключение необходимо отметить, что применение автоматизированного тестирования наиболее актуально для сетевых программных средств, что позволяет с использованием ограниченных технических ресурсов обеспечивать разноплановое нагрузочное тестирование: работу приложения при подключении нескольких пользователей, одновременную работу пользователей, тестирование параллельной обработки информации, тестирование на большом количестве открытых соединений, тестирование многопоточного выполнения приложения, тестирование при ограниченной пропускной способности сети.
Представленные в статье приемы автоматизации функционального и нагрузочного тестирования были апробированы при разработке программных продуктов в процессе модернизации авторизированной поисковой системы московского информационного агентства и ряда других СПС. Анализ результатов проведенной работы показал высокую эффективность автоматизированных тестов при проверке СПС.
Литература
1. Липаев В.В. Процессы и стандарты жизненного цикла сложных программных средств. Справочник. М.: Синтег, 2006. – 276 с.
2. Липаев В.В. Тестирование крупных комплексов программ на соответствие требованиям. Учебник. М.: ИПЦ «Глобус», 2008. – 376 с.
3. Дастин Э., Решка Дж., Пол Дж. Автоматизированное тестирование программного обеспечения. М.: Лори, 2003. – 592 с.
4. Блэк Р. Ключевые процессы тестирования. М.: Лори, 2006. – 544 с.