The transparent log method for organization of the testing process ofWEB-based information systems.pdf Тестированию приложений в последнее время уделяется очень много внимания.Существует огромное количество литературных источников [1 - 7], где приводятсярекомендации по проведению мероприятий по тестированию и верификации созда-ваемого программного обеспечения (ПО). В некоторых учебных заведениях дажеоткрываются отдельные специальности, которые готовят специалистов в этой об-ласти - тестеров. Однако не существует универсального подхода или достаточнообщих рекомендаций для проведения тестирования - в каждом конкретном случаетестер опирается на конкретное ПО, решающее конкретную задачу.Многократно увеличивается сложность тестирования при создании систем сраспределенной архитектурой - «база данных + сервер приложений + web-интер-фейс». Процесс тестирования этих приложений требует дополнительных затрат на«интеграционное тестирование» (тестирование системного интерфейса) и «сис-темное тестирование» (тестирование интерфейса пользователя). Поэтому разра-ботка новых подходов, облегчающих этот процесс, по-прежнему является акту-альной задачей перед «выходом» информационных систем. В статье предлагаетсяодин из подходов, названный автором «серым журналом», с помощью которого внастоящее время тестируются как отдельные приложения, так и целые подсисте-мы единой интегрированной аналитической информационной системы управле-ния вузом, которая на протяжении нескольких лет разрабатывается в Кемеров-ском государственном университете.1. Краткий анализ основных методов тестированияОбщая идеология тестирования ориентирована на использование двух основ-ных подходов - тестирование в режиме «белого ящика» или «черного ящика». Впервом случае процесс тестирования проводит разработчик системы, используя86 А.М. Гудовисходный код. Во втором - тестируется уже готовое приложение или (его модули)с опорой только на исполняемый код системы. Существует промежуточный под-ход, который использует идеи первых двух - тестирование «серого ящика», гдетестеру частично или полностью предоставлен исходный текст системы, а такжеее исполняемый код. Такой подход позволяет наиболее качественно провести всепроцедуры тестирования ПО.Однако при тестировании реальных приложений для определения и реализа-ции полного набора тестовых примеров может оказаться недостаточно времениили других ресурсов. В такой ситуации нужно определить, какие тесты наиболееважны, а какие функции анализируемого ПО не будут тестироваться.Как правило, тестер в реальных условиях придерживается подхода тестирова-ния в режиме «черного ящика». Далее кратко проанализированы две наиболеераспространенные методики такого тестирования - «метод наращиваемого под-хода» [1 - 4] и «схематический подход» [5]. Обе методики соответствуют функ-циональному тестированию ПО.1 . 1 . М е т о д н а р а щ и в а е м о г о п о д х о д аМетод наращиваемого подхода (подробно изложен в [3]) применяется в томслучае, когда тестер, имея исполняемый код системы, проходит последовательнонесколько стадий тестирования.Изучение приложения и ознакомление с его функциями − это необходимыйэтап обучения. Тестеры создают тесты на ходу, часто находясь под влиянием пре-дыдущих тестов. Этот подход, известный как исследовательское тестирование, −первый этап в процессе принятия решения о том, что будет тестироваться.Недостатки: результаты, выданные приложением, могут повлиять на решениетестера − он может поверить, что полученные результаты верны; когда тестерсталкивается с ошибкой, может оказаться, что для определения верного пути вприложении или предыдущего состояния нет записи последовательности входныхпараметров, действий пользователя и т.д. Это может усложнить воспроизведениеошибки.Базовое тестирование - создание базового тестового примера. Обычно базо-вый тест несложен: он основывается на простейшем пути в приложении, в про-цессе которого используются установки по умолчанию или же другие непосред-ственные входные данные. При заданных входных данных тестер должен опреде-лить результирующие данные (любые наблюдаемые выходные данные или отсут-ствия таковых).Недостатки: отсутствие точного представления о правильных данных; выход-ные данные не могут гарантировать правильность прохождения даже базовоготеста.Анализ тенденций − это необязательная стадия, на которой проводится отсле-живание характера поведения путем изменения значения одной определенной пе-ременной. Даже если результат реальных выходных данных точно не известен,можно оценить, изменяются ли значения выходных данных в ожидаемом направ-лении.Инвентаризация - состоит из определения типов данных, доступных в прило-жении с последующей классификацией состояний, в которых может находитьсякаждый элемент данных. Тестирование позволяет убедиться, что каждое состоя-ние используется по крайней мере один раз. Каждый набор состояний задает ин-вентарный список.Метод «Прозрачной журнализации» для организации процесса тестирования 87Недостатки: после того как разработчики устранят проблему и создадут новуюверсию приложения, тестеры должны повторно провести исходные тесты.Комбинирование элементов инвентарных списков, чтобы можно было опреде-лить, предсказуема ли их совместная работа. Не все инвентарные списки содер-жат простые значения данных или состояния.Недостатки: при определении всех комбинаций получается огромное числотестовых примеров − значительно больше, чем можно было бы выполнить в ра-зумные сроки.Граничные оценки − исследование пределов возможностей приложения. Пре-делы возможностей приложения (или границы) определяются данными. Приме-рами могут служить минимальные и максимальные значения диапазона данных;минимальный и максимальный размер поля и т.д. Общее правило − создать тритестовых примера, чтобы охватить следующие значения: граничное значение;граничное значение -1; граничное значение +1.Ошибочные данные - попытка вывести приложение из строя, создавая усло-вия, в которых обычный пользователь, вероятнее всего, работать не будет. Цельзаключается в проверке приемлемого поведения приложения даже в том случае,если тестовые данные не описывают нормального состояния. При создании тесто-вого примера с ошибочными данными в результате обычно появляется сообщениеоб ошибке. Ожидается, что приложение отловит эти данные и проинформируетпользователя об ошибке.Создание напряжений. На этой стадии тестеры отходят от функций приложе-ния и оценивают условия их реализации в терминах рабочих характеристик и вос-становления системы после неполадок. Даже если система перезагружается, послеперезапуска все должно функционировать корректно.Резюме: Метод наращиваемого подхода (эволюционный подход) - применимкак основа для тестирования любого приложения. Однако метод не учитываетособенности приложения. Метод поддается «автоматизации» на стадии, когда из-вестны необходимые тестовые задания (сценарии тестирования). Труден при про-ведении интеграционного тестирования за счет того, что необходимо «охватить»все возможные комбинации (записи инвентарных списков) входных параметров иполучаемых состояний с «прицелом» на совместное функционирование всех мо-дулей системы. Требует много времени для «всеохватывающего» тестированияприложения.1 . 2 . С х е м а т и ч е с к и й п о д х о дСхематический подход − это метод, который используется для рассмотрениятребований [5]. Требования преобразуются в схемы для того, чтобы перечислитьразличные условия теста. Схематический метод управляет процессами и не зави-сит от содержания системы. Нередко он позволяет обнаружить отсутствующую втребованиях информацию.Каждый элемент в схеме, в конечном счете, будет определять входные состоя-ния для тестового примера. Набор состояний системы может быть трансформиро-ван в набор функций и т.д. Схема, как правило, представляет собой древовиднуюструктуру (граф), в которой между корнем и каждым листом существует одно-значно определяемый путь. Этот путь устанавливает специфический набор вход-ных состояний, которые затем будут использованы для определения тестовогопримера.88 А.М. ГудовСхема содержит узловые точки (или точки ветвления), обозначающие под-сказки, тип значения или входной вариант. Нумерация узла обозначает специфи-ческое входное состояние соответствующего ему предка. Число листьев на дереве(или путей в схеме) дает приблизительное число тестовых примеров, необходи-мых для тестирования всех функций приложения.Создание схемы − итерационный процесс. Последняя версия схемы помогаетокончательно сформулировать тестовые сценарии. Каждый путь в схеме (от корняк листьям) определяет входную комбинацию, которая образует основу для тесто-вого сценария.Процесс тестирования разбивается на последовательные стадии и поддержива-ет различные уровни [6,7]: поэлементное тестирование (затрагивает наименьшиеединицы компиляции какого-либо приложения); тестирование уровня интеграции(заключается в комбинировании отдельных элементов и подтверждении того, чтоони функционируют корректно); тестирование уровней системы (применяется дляцелостных приложений, чаще всего касается поведения пользователя при работе ссистемой). Результаты тестирования записываются в таблицы. На основании этихданных делаются оценки о покрытии тестами структуры приложения.Резюме: Таблицы применяются на протяжении всего процесса тестирования,начиная с поэлементного тестирования и заканчивая тестированием на уровнесистемы. Описание приложения при помощи диаграммы переходов несложнопреобразовать в эквивалентную таблицу состояний, из которой потом легко вы-водятся тестовые сценарии. Для приложений, где используется большое количе-ство комбинаций сложных данных, в таблицах тестов могут быть сделаны ссылкина файлы, которые содержат реальное описание входных данных и исходных ре-зультатов. С помощью таблиц решений можно отслеживать сложные комбинацииусловий и связанные с ними результирующие действия.1 . 3 . Т е с т и р о в а н и е w e b - п р и л о ж е н и йи т е с т и р о в а н и е б а з д а н н ы хПриложения, основанные на технологиях WWW, несут в себе новые проблемыкак для разработки, так и для тестирования [4, 8, 9]. Тесты для web-узла должныбыть ориентированы на предполагаемое поведение узла. Необходимо оцениватьследующие проблемные моменты: функциональные возможности; практичность;навигацию; форму, содержимое страницы. Подробно принципы тестированияweb-приложения изложены в [4].Тестирование баз данных часто является очень важной частью тестированияприложения [10]. При тестировании баз данных требуются всесторонние знаниятестируемого приложения. К ключевым проблемам, возникающим при тестиро-вании баз данных, относятся целостность данных; достоверность данных (подхо-дящая форма при вводе в базы данных); манипуляции с данными и обновления.Общее резюме: Тестирование распределенного приложения довольно слож-ная задача. Если приложение использует многоуровневую архитектуру «клиент -сервер», то описанные выше подходы должны применяться для каждого уровня.Но при этом требуется провести интеграционное тестирование для проверки сис-темных интерфейсов и системное тестирование для проверки внешних интерфей-сов (как правило, интерфейсов пользователя или внешней системы).Обычно для сложных приложений тестирование распадается на инкремен-тальное - тестирование отдельных компонент, отдельных модулей, отдельныхМетод «Прозрачной журнализации» для организации процесса тестирования 89подсистем, отдельных частей приложения; интеграционное − тестирование взаи-модействие всех частей приложения, интерфейса пользователя, интерфейса сис-темы в целом.Общей методики не существует, поскольку нужно использовать «особенно-сти» приложения. Эффективного тестирования невозможно достигнуть, не знаяисходного кода (структуры) всех компонент системы. Особенно задача осложня-ется в том случае, если система разрабатывается отдельными частями или в сис-тему интегрируются «чужие» модули.2. Интеграционное тестирование распределенной системыДля практической демонстрации предлагаемого подхода используем реальнуюинформационную систему, имеющую следующую распределенную архитектуру(рис. 1): клиент через web-браузер обращается к приложению; запрос обрабатыва-ет сервер приложений, при необходимости вставляет данные, получаемые по за-просу с сервера баз данных, формирует выходной HTML-файл; сформированнаястраница отправляется клиенту.Рис. 1. Архитектура распределенной системыНа сервере приложений обработкой данных занимается пакет KemsuWEB,структура которого показана на рис. 2. Основным носителем информации являет-ся XML-файл шаблона будущей страницы с данными. В шаблоне присутствуютспециальные конструкции, предназначенные для расширения возможностей об-работки данных языка XML: вызов процедур или выполнение запросов для полу-чения данных с сервера базы данных; управление логическими инструкциями;обработка локальных переменных и переменных сессии (глобальных для данногосеанса пользователя).Другими словами, сервер приложений разделяет уровни хранения данных, об-работки данных и формирования интерфейса пользователя (рис. 3).90 А.М. ГудовРис. 2. Архитектура пакета KemsuWEBРис. 3. Уровни работы приложенияПроцесс тестирования такого приложения представляет собой сложную зада-чу. Для её решения мало провести инкрементальное тестирование отдельныхкомпонент приложения, интерфейса пользователя, корректности работы запросовк данным и т.д. Необходимо накопить статистику выполнения тестовых сценари-ев и состояний приложения, определить структуру тестируемой системы. Крометого, при выполнении тестовых сценариев желательно иметь возможность быстроизменять структуру приложения и определять ветку структурного графа прило-жения, которую необходимо проверить. Множество значений входных парамет-ров, задаваемых через формы web-интерфейса, также необходимо накапливатьвместе с ответными сообщениями системы.Для проведения тестовых мероприятий предлагается методика «прозрачнойжурнализации», которая ниже будет пояснена на примере тестирования лишь не-большой части системы - компонента авторизации на сервере конференций Кем-ГУ (http://conference.kemsu.ru) (рис. 4).Метод «Прозрачной журнализации» для организации процесса тестирования 91Рис. 4. Пример web-приложения для иллюстрации методики тестированияНа рис. 5 приведен фрагмент исходного кода интерфейса пользователя, реали-зованного в соответствующем XML-файле.Рис. 5. Фрагмент исходного кода, реализующего форму авторизации пользователя92 А_______.М. ГудовПоскольку этот файл имеет текстовый формат и всегда доступен для просмот-ра/редактирования (в рамках доступных привилегий системы защиты), то его ис-пользование дает тестеру ряд преимуществ при ознакомлении и организации гра-фа структуры web-приложения.Для иллюстрации предлагаемой методики используем только часть формы(рис. 4), определяющую поведение системы в двух случаях:- если пользователь впервые зашел на сайт конференции, ему необходимо вве-сти свои регистрационные данные (нажать кнопку «заполнить»);- если пользователь уже имеет личные данные в этой системе, ему необходимовыполнить авторизованный вход для дальнейшей работы (заполнить поля формы«логин» и «пароль», нажать кнопку «войти»).3. Метод прозрачной журнализацииСуть метода заключается в следующем. В исходном XML-файле тестер рас-ставляет специальным образом метки (на рис. 5 они приводятся в квадратныхскобках). Далее при выполнении этого кода метки вместе с фрагментами исход-ного кода и значениями соответствующих переменных помещаются в специаль-ную таблицу - журнал активности. Формат записи в простейшем случае приведенв табл. 1.Т а б л и ц а 1Формат записи журнала активностиИмя модуля(компонента)МеткаузлаМеткаслед. узлаДействие/предикатЗначениепредикатаВозвращаемоезначение КомментарийКаждая запись представляет собой элемент графа структуры тестируемогоприложения. Набор записей полностью отображает таблицу на граф. Фрагментграфа структуры приведен на рис. 6, а соответствующий ему набор записей вжурнале активности - в табл. 2.Рис. 6. Фрагмент графа структуры приложенияМетод «Прозрачной журнализации» для организации процесса тестирования 93Т а б л и ц а 2Фрагмент записей журнала активности для рассматриваемого примера1http://conference.kemsu.ru/conf/reg/index.htm[1] [2]If name="$$Person/ID$$"value="" op="eq"trueЗначениеPerson/ID = null2http://conference.kemsu.ru/conf/reg/index.htm[2] [3] conf/{{conferenceAlias}}/reg/ins_person.htmЗначенияпередавае-мых пара-метровПередачауправленияформе3http://conference.kemsu.ru/conf/reg/index.htm[3]  conf/{{conferenceAlias}}/reg/chk.htmЗначенияпередавае-мых пара-метровЗначениевыходныхпарамет-ровПередачауправленияформе4http://conference.kemsu.ru/conf/reg/index.htm[1] [4]##LAST_NAME####FIRST_NAME####MIDDLE_NAME####ORGANISATION####CITY####COUNTRY##Значенияперемен-ныхОткудавернулисьВывод вXML-файлВ строке таблицы с номером 1 проверяется состояние авторизации пользова-теля (узел с номером 1 на рис. 6). Если значение переменной $$Person/ID$$ неоп-ределенно, то пользователь не прошел регистрацию в системе и ему необходимозаполнить свои данные при помощи специальной формы (узел с номером 4 нарис. 6).Если пользователь получил свои данные для авторизации (логин и пароль),ввел их в соответствующие поля формы и начал процесс авторизации (кнопка«войти» на рис. 4), его параметры передаются в специальный файл «ins_person.htm» (узел с номером 2 на рис. 6), где происходит проверка его учетных данных(узел с номером 3 на рис. 6, строки 2 и 3 в табл. 2). При этом значения передавае-мых параметров и результат процесса авторизации помещаются в столбец 6 табл. 2.Эти данные в последующем могут служить для автоматической генерации тесто-вых сценариев при проведении повторного или более детального тестирования.В случае успешной проверки учетной записи пользователь переходит на свой ра-бочий стол и продолжает работу с системой. Если попытка авторизации прошланеудачно, пользователь остается в пределах текущей формы.Если пользователь начал процесс регистрации в системе (узел с номером 4 нарис. 6) посредством специальной формы, то его параметры могут быть помещены встолбец 5 табл. 2 (переменные #LAST_NAME##, ##FIRST_NAME##, ##MIDDLE_NAME##, ##ORGANISATION##, ##CITY##, ##COUNTRY##) и могут быть ис-пользованы _____для проведения детального тестирования процесса регистрации.После выполнения необходимых тестовых сценариев тестер имеет в своемраспоряжении структуру проверяемой части модуля (компонента) системы, наборзначений передаваемых/принимаемых переменных, набор сообщений системы(помещаются в последнее поле) в случае возникновения проблемных ситуаций.На основании этих данных можно провести анализ покрытия структуры приложе-ния. Анализ покрытия дает возможность оценить эффективность теста (с исполь-94 А.М. Гудовзованием специализированных инструментов тестирования) и провести наблюде-ние за путями выполняемого кода.Журнал активности сохраняется в специальной схеме базы данных, где и про-исходит накопление необходимых статистических данных. Написав несложныйнабор утилит, тестер получает мощный инструментарий для последующего ана-лиза работы приложения.ЗаключениеПредлагаемая методика объединяет на своей основе стратегии интеграционно-го тестирования (тестирование модулей/компонент в едином приложении с ис-пользованием подходов, присущих функциональному тестированию, т.е. методи-ка «серого ящика») и системного тестирования (тестирование внешних интерфей-сов или интерфейсов пользователя).Записи из журнала можно использовать сколько угодно раз. Совокупность за-писей можно конвертировать в любой формат представления, который можно ис-пользовать при других методах автоматизации процесса тестирования, например спомощью сетей Петри.Записи журнала «прозрачны» для различных компонент приложения (на чте-ние/запись).На основании записей из журнала невозможно провести тесты, подтверждаю-щие корректность содержимого web-страницы с точки зрения пользователя. Этонужно сделать другим способом.

Скачать электронную версию публикации