Открытый конкурс 2007/2008 уч. года на лучшую научную работу студентов по естественным, техническим и гуманитарным наукам.

Девиз: Тестирование – способ обеспечения качества!

Тема: Разработка средств тестирования автоматизированной системы обучения.

Раздел 22

2

СОДЕРЖАНИЕ

СОДЕРЖАНИЕ ............................................................................................................................2

Введение.........................................................................................................................................3

1. Обзор имеющихся средств автоматического тестирования. ..................................5

1.1 Базовые технологии автоматизации тестирования................................... 6

1.2. Обзор систем автоматизации тестирования................................................... 10

1.2.1 Rational Robot. ................................................................................................... 10

1.2.2 WinRunner. .......................................................................................................... 12

1.3 Сравнительный анализ систем автоматизации тестирования. ............... 15

2. Проектирование системы.............................................................................................18

2.1. Разработка архитектуры системы....................................................................... 18

2.2 Диаграмма вариантов использования. .............................................................. 24

2.3. Диаграмма деятельности........................................................................................ 31

2.4 Диаграмма классов. ................................................................................................... 32

2.5 Диаграмма последовательности. ......................................................................... 34

2.6 Диаграмма развертывания. .................................................................................... 37

2.7 Диаграмма ER. .............................................................................................................. 39

2.8 Проектные решения процесса тестирования................................................... 40

2.8.1 Механизм встраивания контрольной точки ...................................... 40

2.8.2 Механизм выделения области локализации ошибок....................... 43

2.8.3 Разработка архитектуры организации тестов .............................. 47

2.8.4 Разработка факторов влияющие на оценку обучающего

тестирования ............................................................................................................ 47

2.8.5 Разработка базовых моделей. .................................................................. 50

3. Реализация системы. .....................................................................................................52

3.1 Реализация имитатора поведения. ...................................................................... 52

3.2 Реализация базы данных......................................................................................... 54

3.3 Параметры реализации ............................................................................................ 61

Заключение .................................................................................................................................63

Список литературы ...................................................................................................................64

3

Введение.

В настоящее время учебные планы в российских вузах строятся таким

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

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

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

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

и издательства, с другой стороны, для высококвалифицированных

специалистов стало проблематичным выполнять большой объем работы по

написанию учебников и учебных пособий при отсутствии оплаты этого

труда.

Одним из эффективных средств компенсации недостатка учебной

литературы является формирование программно-информационных ресурсов,

ориентированных на использование в учебном процессе в режиме

интерактивного доступа. Это расширяет спектр знаний, которые может

приобрести студент, но усложняет процесс получения именно того

комплекса знаний, которые преподаватель запланировал с целью

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

дисциплины. В результате, часто получается, что студент «нахватался»

многих сведений, но на экзамене показывает слабую подготовку. Это

связано, прежде всего, с тем, что в ходе познавательной деятельности

студент не имеет достаточно активных контактов с преподавателем.

Контакты с преподавателем обеспечивают корректировку хода процесса и

усиление мотивации работы студента за счет осмысления степени

успешности изучения того или иного материала.

Нехватка общения студента с преподавателем в определенной мере

может быть компенсирована системами автоматизированного обучения ,

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

коллективами разработчиков по всему миру.

Наш вуз не остался в стороне от всеобщей тенденции.

4

Работы по созданию системы автоматизированного обучения ведутся

на протяжении почти 10 лет. Проект называется ТКАСАО, и ориентирован

на реализацию двух основных функциональных возможностей:

формирование преподавателем автоматизированных учебных курсов (АУК)

и организация обучения студентов в соответствии с этими курсами.

В последние годы был проведен реинжиниринг системы с целью

адаптации ее к изменившимся условиям внешней среды,

усовершенствование алгоритмов работы системы и расширение

функциональности, а также разработка решений, позволяющих устранить

или уменьшить воздействие изменений условий эксплуатации, дальнейшее

устаревание. Однако работы по созданию обновленной системы проводились

таким образом, что даже в таком виде система уже способна выполнять ряд

функций систем автоматизированного обучения в том числе важнейшие

функции, связанные с проведением тестов знаний.

Таким образом, вполне реально параллельно с доработкой системы

попытаться осуществить ее внедрение и апробацию в реальных условиях

работы корпоративной сети вуза. Очевидно, что подобное развертывание

системы означает, прежде всего, ее тестирование.

Актуальность данной бакалаврской работы состоит в том, что в условиях

ВУЗа обеспечивать устойчивость функционирования ТКАСАО в условиях

привлечения к ее развитию временных разработчиков, студентов, не

владеющих в полной мере проектными решениями системы, достаточно

сложно и практически невозможно.

Тестирование - неотъемлемая часть процесса разработки любого

современного программного продукта. И чем сложнее продукт, чем больше

стоимость его разработки, тем большую актуальность приобретает

постоянная, от версии к версии, проверка работоспособности всей системы с

учетом новой функциональности и исправленных "багов". Чтобы при этом не

тестировать весь продукт вручную, тестировщики зачастую автоматизируют

наиболее часто повторяющиеся тесты.

5

1. Обзор имеющихся средств автоматического

тестирования.

Чаще всего мы проводим тестирование наших приложений на

соответствие требованиям заказчика (даже если в роли заказчика выступаем

мы сами). Такое тестирование называется приемочным или

функциональным.

Зачастую функциональное тестирование проводится вручную, обычно

для этого выделяют специального человека или несколько, которые обходят

сайт раз за разом и сверяют поведение системы с тем, что прописано в

техническом задании. На такое ручное тестирование уходит очень много

времени, да и качество этого тестирования далеко не идеальное: человек

может что-либо забыть, полениться сделать, пропустить что-то. Один из

самых больших недостатков такого ручного тестирования, что моменты

обнаружения ошибки в поведении системы и локализации этой ошибки

очень удалены друг от друга. Иногда проходит неделя или даже больше

времени, прежде чем ошибка выявляется, и на поиск ее причины и

исправление уходит много времени.

Мы не можем проводить ручное тестирование сколь угодно часто, так

как это требует больших затрат. Мне могут возразить, что у них в компании

есть люди, которые занимаются ручным функциональным тестирование весь

день.

Что ж, вы можете гарантировать, что один и тот же сайт можно

обходить целиком 5-10 раз в день, проверять его до мельчайших деталей?

Если ответ да, то я просто вам сожалею.

Для того чтобы проводить такое тестирование быстро, часто и главное

эффективно, существуют средства для автоматизации функционального

тестирования. Далее мы будем вести речь только об автоматизированном

тестировании, мы покажем, как и при помощи чего можно автоматизировать

этот нелегкий и скучный труд.

6

На сегодняшний день рынок программного обеспечения предлагает

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

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

проверяющие полноту и непротиворечивость требований к программе,

тестирующие сетевое взаимодействие, основную функциональность

приложений методами «чѐрного», «белого» и «серого» ящиков, надѐжность

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

инструменты, позволяющие автоматизировать тестирование удобства

использования графического интерфейса приложения.

Но настоящий момент в среде разработчиков ни один продукт не

используется как стандарт для функционального тестирования web-

приложений

1.1 Базовые технологии автоматизации тестирования.

Исторически первым методом тестирования является так называемый

метод «чѐрного ящика».

Данный метод подходит для тестирования небольших программных модулей

и сложен в использовании при тестировании больших программных систем,

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

приемлемого уровня уверенности в правильности программы.

Качественно новый подход к тестированию был предложен Энтони

Хоаром – метод доказательства корректности программ. Единственным

серьѐзным недостатком данного подхода является чрезвычайная сложность

построения математических моделей для больших программ. После

некоторых попыток применения подхода, от него решено было отказаться.

Позднее были предложены иные методы тестирования, основанные на

анализе исходного кода программ для выявления ошибок. Наиболее

известным является метод «белого ящика», предложенный Филлисом

Франклом и Элайном Веюкером в 1988 году. Недостаток данных методов

7

состоит в том, что тестирование программы производится без наличия

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

использовании данных методов предполагается, что результаты работы

программы на тестах проверит человек. Но инструментальные средства

тестирования с помощью покрытия кода генерируют огромное количество

тестовых наборов, так что проверить результат работы каждого теста

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

выборочной проверки (так называемая N-выборка), основанный на

статистических методах.

Среди программ автоматизированного тестирования существуют

средства записи-воспроизведения

действий человека, осуществляющего тестирование.

Самым распространенным является подход, называемый Capture &

Playback (другие названия – Record & Playback, Capture & Replay). Суть этого

подхода заключается в том, что сценарии тестирования создаются на основе

работы пользователя с тестируемым приложением. Инструмент

перехватывает и записывает действия пользователя, результат каждого

действия также запоминается и служит эталоном для последующих проверок.

При этом в большинстве инструментов, реализующих этот подход,

воздействия (например, нажатие кнопки мыши) связываются не с

координатами текущего положения мыши, а с объектами HTML-интерфейса

(кнопки, поля ввода и т.д.), на которые происходит воздействие, и их

атрибутами. При тестировании инструмент автоматически воспроизводит

ранее записанные действия и сравнивает их результаты с эталонными,

точность сравнения может настраиваться. Можно также добавлять

дополнительные проверки – задавать условия на свойства объектов (цвет,

расположение, размер и т.д.) или на функциональность приложения

(содержимое сообщения и т.д.). Все коммерческие инструменты

тестирования, основанные на этом подходе, хранят записанные действия и

ожидаемый результат в некотором внутреннем представлении, доступ к

8

которому можно получить, используя или распространенный язык

программирования (Java в Solex), или собственный язык инструмента (4Test

в SilkTest от Segue, SQABasic в Rational Robot от IBM, TSL в WinRunner от

Mercury). Кроме элементов интерфейса, инструменты могут оперировать

HTTP-запросами (например, Solex), последовательность которых также

может записываться при работе пользователя, а затем модифицироваться и

воспроизводиться.

Основное достоинство этого подхода – простота освоения. Создавать тесты с

помощью инструментов, реализующих данный подход, могут даже

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

подхода имеется ряд существенных недостатков. Для разработки тестов не

предоставляется никакой автоматизации; фактически, инструмент

записывает процесс ручного тестирования. Если в процессе записи теста

обнаружена ошибка, то в большинстве случаев создать тест для

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

(инструмент должен запомнить правильный результат для проверки). При

изменении тестируемого приложения набор тестов трудно поддерживать в

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

приходится записывать заново.

Этот подход лучше всего использовать для создания прототипа теста,

который впоследствии может служить основой для ручной доработки. Одна

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

приложения на различных данных. Этот подход называется тестированием,

управляемым данными (Data Driven). Основное ограничение – перебираемые

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

проверки, записанные в тестовом сценарии, не подразумевают какой-либо

анализ входных данных, т.е. для каждого варианта поведения нужно

создавать свой сценарий тестирования со своим набором данных. Некоторые

инструменты, реализующие Capture & Playback, предоставляют возможность

9

по перебору данных (например, e-Tester от Empirix); кроме того, над

большинством распространенных инструментов существуют надстройки

(Convergys Auto Tester – надстройка над WinRunner).

Описанные подходы основываются на построении тестов с использованием

тестируемого приложения. В подходе KeywordDriven предпринимается

попытка сделать процесс создания тестов независимым от реализации. Суть

подхода заключается в том, что действия, выполняемые в ходе тестирования,

описываются в виде последовательности ключевых слов из специального

словаря («нажать», «ввести», «проверить» и т.д.). Специальный компонент

тестовой системы переводит эти слова в воздействия на элементы

интерфейса тестируемого приложения. Таким образом, никакого

программирования для создания тестов не нужно. Единственное, что нужно

менять при изменении интерфейса, – это компонент, который отвечает за

перевод слов из «словаря» в последовательность воздействий на приложение.

Комплект тестов может разрабатываться пользователями, не владеющими

навыками программирования, однако для поддержания комплекта в рабочем

состоянии программирование все-таки необходимо. В качестве примера

инструмента, поддерживающего такой подход к разработке тестов, можно

привести Certify от WorkSoft, в котором поддерживается библиотека

функций для работы с каждым компонентом интерфейса (окна, гиперссылки,

поля ввода и т.д.) и предоставляется язык воздействий на эти элементы

(InputText, VerifyValue, VerifyProperty и т.д.).

Основные преимущества этого подхода заключаются в том, что он позволяет

создавать тесты, не дожидаясь окончания разработки приложения,

руководствуясь требованиями и дизайном интерфейса. Созданные тесты

можно использовать как для автоматического выполнения, так и для ручного

тестирования.

Основной недостаток этого подхода – отсутствие автоматизации процесса

разработки тестов. В частности, все тестовые последовательности

10

разрабатываются вручную, что приводит к проблемам, как на стадии

разработки, так и на стадии сопровождения тестового набора. Эти проблемы

особенно остро проявляются при тестировании Web-приложений со

сложным интерфейсом.

1.2. Обзор систем автоматизации тестирования.

Из наиболее доступных инструментов для автоматизированного

тестирования можно выделить следующие:

WinRunner

Robot

Ниже приводится краткий обзор этих систем.

1.2.1 Rational Robot.

Rational Robot - средство, которое позволяет создавать, изменять и

выполнять автоматизированные тесты для интернет-приложений, ERP- и

клиент-серверных приложений. Rational Robot обеспечивает объектную

поддержку для тестирования приложений, созданных с использованием

технологий, спецификаций и инструментария Java, HTML, DHTML, Visual

Basic, PowerBuilder, Oracle Developer/2000, Microsoft Visual Studio и т. д.

Rational Robot является решением для автоматизированного

тестирования, которое позволяет, единожды написав тест, вторично

использовать его на любых платформах. Технология Object Testing,

используемая в Rational Robot, позволяет всесторонне тестировать

приложения, что особенно важно в современных средах разработки, где

производительность разработки ПО с использованием встроенных

компонентов резко возросла. Эти различные библиотеки классов Java,

средств управления ActiveX Control, OLE Control (OCX), Visual Basic Control

11

(VBX), объекты Visual Basic, Win32 Control и т. д. Тестирования всего лишь

графических интерфейсов этих объектов недостаточно. Также важно

протестировать невидимые свойства, например вложенные SQL-запросы и

свойства, контролирующие их поведение.

Rational Robot генерирует сценарии функциональных тестов на языке

SQABasic, который синтаксически подобен обычному Visual Basic. С

помощью SQABasic можно просматривать и редактировать сценарии тестов

прямо во время записи. Rational Robot включает в себя встроенный редактор

и отладчик с режимом анимационного воспроизведения и онлайновой

проверкой синтаксиса скрипта. В любое время можно дополнить сценарии

тестов какими-либо процедурами и логическими условиями. При этом

доступен вызов любой функции из DLL или из API-интерфейса Windows.

Для всеохватывающего тестирования Web-, ERP- и клиент-серверных

приложений необходимо протестировать все компоненты приложения при

различных условиях. Rational Robot предоставляет тестовые сценарии для

меню, списков, буквенно-числовых символов и многих других объектов. Но

можно и самостоятельно определить тестовые сценарии, вызывающие

внешние DLL или файлы исполнения. Rational Robot также предоставляет

специализированные тестовые сценарии для специфических объектов,

например Java Control, ActiveX Control, OCX, VBX, PowerBuilder

DataWindow, специальных объектов Oracle Form, объектов Visual Basic и т. д.

Можно даже "научить" Rational Robot понимать неизвестные объекты и

настраивать его таким образом, что он будет уверенно распознавать их в

процессе тестирования.

Rational Robot позволяет определять многочисленные таймеры для

дополнительной оценки производительности приложения. Rational Robot

автоматически вносит информацию с результатами всех тестов в

масштабируемый встроенный репозитарий Rational Repository. Инструмент

Test Log Viewer служит для облегчения визуального анализа результатов и

отображает их результаты тестирования различными цветами. Простой

выбор данных позволит перейти непосредственно на соответствующую

12

исполняемую строку в тестовом скрипте, ускоряя при этом анализ

результатов.

Rational Robot обеспечивает возможностью тестирования приложений,

созданных в различных интегрированных средах разработки:

HTML и DHTML;

Java-среды разработки (Sun JDK, Symantec Visual Cafe, Microsoft J++);

Oracle Developer/2000;

SAP R/3;

среды разработки VisualBasic-приложений;

PeopleTools;

PowerBuilder;

Microsoft Visual Studio .NET.

В состав Rational Robot входит Rational TestManager, средство, позволяющее

централизованно контролировать и управлять процессами

автоматизированного тестирования информационных систем, как

функционального, так и нагрузочного, включая вопросы его планирования и

подготовки.

1.2.2 WinRunner.

WinRunner представляет собой интегрированную среду разработчика

автоматических тестов - здесь можно писать сами тесты на языке TSL

(Testing Script Language) и, естественно, запускать их. Это достаточно

простой, не типизированный язык, в основе которого лежит популярный

язык программирования С. При этом, кроме уже упоминавшейся

возможности автоматической генерации скрипта в режиме записи,

существует набор различных специфических для тестирования средств.

Например можно в интерактивном режиме (с помощью "мастера") добавлять

в скрипт так называемые "чек-пойнты" (checkpoints). Создавая чек-пойнт, мы

автоматически вставляем в скрипт вызов соответствующей функции, которая

13

при последующих запусках скрипта будет сравнивать состояние конкретного

окна (или отдельного элемента интерфейса) с заранее заданным. Под

состоянием подразумевается набор свойств элементов интерфейса - таких,

как активность или неактивность, выбранный элемент (для списков) и так

далее. Задать такое состояние можно как раз в момент создания чек-пойнта.

Текущее состояние элементов интерфейса принимается за "эталон",

информация о нем заносится в файл специального формата, который можно

тут же, на ходу, отредактировать.

WinRunner - Чек-пойнт для одного свойста объекта

WinRunner - Чек-пойнт для множества объектов

14

WinRunner идентифицирует объекты в приложении, основываясь на

некотором наборе их свойств - например, для кнопки это будет текст на ней.

Все эти свойства он хранит в специальном файле - так называемой карте

объектов (GUI map), а обращение к объектам из скрипта происходит по

имени. При изменении свойств объекта в приложении (например, поменялся

заголовок окна) вам нужно будет исправить описание этого окна в карте, а

скрипт останется неизменным.

WinRunner - Карта объектов

Редактор в WinRunner поддерживает раскрашивание конструкций

языка в соответствии с выбранными настройками, в вашем распоряжении

также возможности отладки и просмотра значений переменных в процессе

работы скрипта.

WinRunner, наверное, более легок в освоении для тестировщиков, у

которых или вообще нет опыта программирования, или чьи программистские

навыки ограничиваются знанием одного из процедурно-ориентированных

языков. Быстрому изучению также способствует обилие (по сравнению с

SilkTest) различных "мастеров" (wizards)

15

1.3 Сравнительный анализ систем автоматизации

тестирования.

Перечисленные инструменты применяются для автоматизированного

тестирования, в том числе при тестировании GUI. В своей статье [3] Рэй

Робинсон приводит сравнительную таблицу (см. таб. 1) этих инструментов

по способности удовлетворять заданные потребности пользователя. При этом

рассматриваются различные свойства этих инструментов:

Запись и проигрывание тестов

Возможности Web-тестирования

Возможности базы тестов и функции для работы с ней

Объектное представление

Сравнение рисунков

Обработка ошибочных ситуаций

Сравнение свойств объектов

Возможности расширения языка

И т.п.

(по 5-бальной шкале, наивысшая оценка - 1)

WinRunner Robot

Тестирование объектов 1 1

Поддержка 1 2

Легкость использования 2 1

Цена 3 2

Возможности интеграции 1 1

Поддержка сред разработки 1 2

Возможности расширения языка 2 1

Сравнение свойств объектов 2 1

Карта объектов 1 4

Обработка ошибочных ситуаций 2 2

Сравнение рисунков 1 1

Объектное представление 1 1

Функции для работы с базой тестов 2 1

Использование базы тестов 1 1

16

Возможности Веб -тестирования 1 2

Запись и проигрывание тестов 2 1

Таблица 1.

Кроме самых распространѐнных, имеется много других инструментов для

автоматического прогона тестов, созданных вручную. Но эти инструменты

не предоставляют возможности автоматической генерации тестов (исключая

процесс записи теста).

В основе всех этих инструментов лежат средства формального описания

тестов (разного рода скриптовые языки). Тесты пишутся вручную. Данный

подход имеет существенные недостатки:

Один из них состоит, как и при полностью ручном подходе, в

недостаточной систематичности.

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

организации регрессионного тестирования. При изменении

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

(редактирования) большого количества тестов. То есть, например,

система изменилась в одном месте – а тесты приходится

модифицировать в несравненно большем количестве мест. Причѐм

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

вызываемых функций, которые также можно изменять в одном месте,

то другие (например, изменение в логике программы) так просто не

решаются.

Кроме того, остаѐтся проблема дублирования одних и тех же

действий (написание одного и того же тестового кода) при совершении

одного и того же события из разных состояний. Такой метод сменил

ручной прогон тестов на ручное написание самих тестов для

дальнейшего автоматического прогона, но само их написание по-

прежнему остаѐтся трудоѐмким занятием.

17

18

2. Проектирование системы.

2.1. Разработка архитектуры системы.

На архитектуру системы тестирования ТКАСАО оказывает влияние

целый ряд обстоятельств, некоторые из которых характерны для

тестирования программного обеспечения в целом, другие же являются

специфичными именно для ТКАСАО как клиент-серверного Internet/Intranet

приложения, имеющей распределенный характер.

Система тестирования является в некотором смысле вторичной по

отношению к тестируемой системе. Разработка тестов и проектирование

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

зависимости от той информации об исследуемой системе, которой мы

располагаем до проведения экспериментов. В нашем случае эта информация

ограничена документацией, представленной диссертациями Колесникова и

Постниковой, а также знаниями об общей организации подобных систем.

Достоверно нам известно лишь то, что, и как мы должны подать на вход

тестируемой системы, чтобы получить желаемый результат. Таким образом,

мы имеем дело с тестированием методом «черного ящика», и проектируемая

нами система может лишь воздействовать на входы ТКАСАО посредством

специальным образом подобранных входных данных, получать ответ и

предоставлять возможность обработки полученных результатов.

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

тестовых данных не только в качестве некоторого сценария для прогона того

или иного теста, но и непосредственное их участие на этапе анализа

полученных результатов.

Другим немаловажным обстоятельством, повлиявшим на такое

решение, явился распределенный характер ТКАСАО как клиент-серверного

Internet/Intranet приложения. С расположением различных компонентов

тестируемой системы на различных узлах компьютерной сети резко

возрастает вероятность невозможности завершить получение данных от

19

системы, что может привести к значительным временным задержкам при

выполнении всего комплекса тестов из-за многократных повторных прогонов

некоторых из них. Вынесение же обработки результатов тестирования в

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

нежелательной зависимости. Во-первых, сокращается время отработки

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

сокращается время использования сети, а значит, уменьшается риск сбоя по

рассмотренным причинам. Во-вторых, даже если сбой произойдет, и

сохранить все результаты не удастся, тест может быть признан пройденным,

так как для такого решения может хватить тех данных, которые уже были

получены и сохранены. Наконец, обработку результатов можно вести

параллельно с выполнением тестов, что позволит сократить общие

временные затраты на тестирование.

При всем при этом следует отметить, что подсистемы автоматизации

выполнения тестов и обработки результатов оказываются тесно связаны

между собой через блок сохранения результатов. Собственно сохранение

осуществляет первая подсистема, а вторая для успешной работы должна

обладать исчерпывающей информацией о месте расположения и формате

сохраненных данных. Все это предъявляет существенные требования к

интерфейсу между рассмотренными подсистемами.

Следует также отметить еще один специфичный для нашей системы

тестирования компонент – подсистему автоматизированного формирования

тестовых данных. Дело в том, что для того, чтобы полученные результаты

соответствовали параметрам работы ТКАСАО в реальных условиях,

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

значительных объемов и при этом удовлетворять определенным требованиям

(в соответствии с целями тестирования). По всей видимости, полностью

ручной набор тестов их разработчику осуществить вообще невозможно, так

как объемы перерабатываемой информации слишком велики. Особенно это

касается тестирования релевантности, так как при этом для отобранных

тестов (а это десятки тысяч файлов) необходимо указать степень

20

релевантности их тому или иному запросу, чтобы в дальнейшем правильно

сформировать эталонные множества документов. Да и сами воздействия не

могут непосредственно подаваться на вход ТКАСАО: во-первых, необходимо

преобразовать их к стандартному виду, во-вторых, еще до тестирования

определить ряд их характеристик.

Именно эти задачи и решает указанная подсистема.

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

структурно-функциональную схему системы тестирования ТКАСАО.

База

данных

Управление

прогоном

тестов

(ручной)

Управление

прогоном

тестов

(авто-)

Обработка результатов тестирования

ВЕБ приложение

(ТКАСАО)

Определение интерфейсных функций

Описание тестов в виде (тестового

сценария)

21

Расположенное в центре объединение – это сама тестируемая

обучающая система (на схеме также показаны связи между ее основными

компонентами; отметим, что хотя нам и известны эти связи, воздействовать

на них мы не можем). Окружающие блоки – это проектируемая нами система

тестирования.

Рассмотрим пошагово:

Первый шаг – создание модели Web-приложения – включает в себя

определение интерфейсных функций, описание требований к ним и их

связывание с Web-приложением. Основная задача этого шага –

формализация требований к интерфейсным функциям. На первом шаге

должно быть получено описание модели, состоящее из набора интерфейсных

функций и описания требований к ним. Интерфейсная функция

соответствует воздействию на интерфейс Web-приложения, в результате

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

на параметры этого обращения, включаются в список параметров

интерфейсной функции. Результатом воздействия является обновление

интерфейса, которое описывается в требованиях к интерфейсной функции.

Например, для HTML-формы регистрации можно описать интерфейсную

функцию, соответствующую отправке данных формы на сервер, параметрами

которой являются значения полей, входящих в форму. В описание

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

выполняется регистрация, и описываются ограничения на состояние

обновленного интерфейса.

Разбиение множества всех возможных состояний интерфейса Web-

приложений на классы эквивалентности представляется в модели набором

страниц. Это разбиение, которое, с одной стороны, используется при

описании требований, с другой стороны, является основой для определения

состояния в сценарии. По умолчанию разбиение на страницы осуществляется

по адресу (URL) HTML-документа, отображаемого в Web-браузере. Однако

22

пользователь может переопределить разбиение произвольным образом. При

традиционном способе построения Web-приложения, когда для каждого URL

определяется его собственный интерфейс, разбиение по умолчанию

соответствует представлению пользователя о тестировании Web-приложения

– пройти все страницы и проверить всю возможную функциональность на

каждой из них.

Также естественным для пользователя требованием к Web-приложению

является требование перехода с одной страницы на другую в результате

активизации гиперссылки или нажатия на кнопку HTML-формы. Такие

требования легко описываются с помощью понятия страниц. В более

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

HTML-формы поиска по некоторому критерию, требования формулируются

в виде условий на атрибуты элементов интерфейса.

На втором шаге нужно получить описание тестов для Web-приложения. При

создании тестов используется подход, предлагаемый технологией UniTesK.

Согласно этому подходу тесты описываются в виде тестовых сценариев, в

основе которых лежит алгоритм обхода графа переходов конечного автомата.

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

интерфейсных функций, для тестирования которых предназначен данный

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

которым будут перебираться ее параметры. Кроме того, нужно задать

правила идентификации состояний тестового сценария.

Для автоматизации процесса создания тестового сценария предоставляется

возможность определять итерацию для параметров выбранных

интерфейсных функций на основе готовых вариантов перебора. Для этого

могут использоваться библиотечные итераторы и итераторы, разработанные

пользователем. Данные, которые вводились в ходе сеанса работы с

инструментом на первом шаге, также могут быть включены в качестве

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

23

может предложить перебор параметров, построенный на основе анализа

интерфейса Web-приложения. Например, использовать для итерации

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

из разных интерфейсных элементов, например, расположенных в столбце

некоторой таблицы.

Следует заметить, что информации, собранной на шаге построения

модели Web-приложения, уже достаточно для создания тестового сценария.

При создании тестового сценария по умолчанию используются все

выделенные интерфейсные функции, для итерации параметров которых

используются итераторы по умолчанию и значения, введенные

пользователем в ходе сеанса построения модели, а в качестве состояния

сценария используется страница HTML-документа.

В качестве альтернативного способа создания тестов для Web-

приложения можно использовать подход Capture & Playback. В процессе

работы пользователя с Web-приложением инструмент записывает

последовательность воздействий на интерфейс, на основе которой

генерирует последовательность вызовов интерфейсных функций,

соответствующую записанным воздействиям.

На следующем шаге вход вступает блок обработки результатов

тестирования. Он черпает информацию из трех источников: от блока

управления прогоном тестов (эта информация представляет собой

полученные средствами среды исполнения данные о режиме работы

тестируемой системы с точки зрения правильности функционирования

системы), непосредственно из базы данных ТКАСАО (отметим, что

непосредственно изменять эту базу данных мы не можем, но существует

возможность получения некоторой информации о базе и о хранящихся в ней

данных напрямую), от блока тестовых сценариев.

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

несколько противоположных идейных течений, которые усердно

24

культивируются носителями этих идей. Точки зрения во многом

противоположны, во многом противоречивы. Тестирование видится с одной

стороны каким-то полумеханическим процессом, который не требует

особенной квалификации: тестировщика видят «кликальщиком», который

просто гоняет приложение, ждет пока оно «упадет», потом радостно

сообщает об ошибке и продолжает в том же духе. В последнее время, надо

отдать должное, появляются в свет книги, развиваются сайты посвященные

этому направлению – это направление мысли постепенно сходит на «нет». С

другой точки зрения, которую, наверное, культивируют отчасти и сами

тестировщики, тестирование – это процесс, покрытый множеством

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

Как мне кажется, связана такая ситуация с тем, что существует

определенное непонимание процессов связанных с тестирование. Но если

четко определить роли и задачи тестирования, то можно не только

представить себе более-менее стандартный процесс тестирования, но также

понять, что к чему относится.

Попробуем определиться и понять, какие же роли и задачи решаются в

контексте тестирования ТКАСАО.

2.2 Диаграмма вариантов использования.

Как можно увидеть, при ближайшем рассмотрении, оказывается, что

тестирование — вполне определѐнный процесс с выделенными ролями и

зоной ответственности для различных игроков проекта. Порядок

перечисления задачи определяет обычный цикл проведения тестирования.

Такой цикл может применяться, как для проектов ориентированных на

длительные итерации, так и для «быстрых» проектов ведущихся по

эволюционным методикам или согласно набирающему обороты XP.

Актор Описание

Администратор Обеспечивает управление и поддержку тестовых

окружений и данных, тестовых данных (баз данных)

25

Администрирует систему управления

тестированием

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

системам

Администрирует тестовые данные (базы

данных)

Разработчик

тестовой

системы

Разрабатывает систему тестирования

Разработка языка сценария

Разработка интерпретатора тестов

Имитатор действий пользователя

Разработка структур данных

Механизмы для их заполнения

Разработка средств журнализации тестирования

Разработчик

тестов

Разрабатывает тесты, тестовые классы и тестовые

наборы (пакеты), собирает тестовые пакеты и

интегрирует их в тестовую модель

Запись или программирование тестовых

скриптов

Создание\подготовка внешних наборов данных

Определение тесто-критичной

функциональности

Тестировщик Выполняет тесты

Выполняет тесты

o Выполнение тестовых процедур

o Оценка выполнения тестов

26

o Проверка результатов

o Исследование неожиданных результатов

o Запись ошибок (log)

Фиксирует результаты

Документирует запросы на изменение

Планировщик

тестов

Разрабатывает стратегию тестирования

Разрабатывает план тестирования

Определяет требования

Создание расписания последовательностей

Оценивает риски

Администратор

Авторизация

доступа

«модифицирует»

«модифицирует» Журнализация

тестирования

Конфигурирование

системы

«модифицирует»

Администрирование

системы

«модифицирует»

Модификация

базы данных

Мониторинг

права доступа

«модифицирует»

Разработчик

тестовой системы

«модифицирует»

Разработка

интерпретатора

скриптов

Разработка

структур данных

Разработка

механизмов

для заполнения

данных

Разработка

языка скриптов

«использует»

Разработка

структуры

скриптов

«модифицирует»

Разработка

имитатор

действий

пользователя

Разработка

средства

журнализации

тестирования

«использует»

Разработчик

тестов

Использование

сценариев

тестирования«модифицирует»

Элементарная

проверка

«модифицирует»

«расширяет»

Тестовые наборы

Определение

критериев качества

Определение

критериев

завершения

«модифицирует»

«использует»

Разработка тестов

Авто-запись

Ручное написание

«использует»

«использует»

«модифицирует»

«модифицирует»

Тестер

Выполнение

тестов

«выполнить»

Фиксирование

результатовиспользуетДокументирование

запросов

на изменение

«использует»

«использует»

«использует»

«использует»

«модифицирует»

Формирование

элементарных

проверок

Формирование

тестовых наборов

«модифицирует»

«использует»

«модифицирует»

«использует»

«модифицирует»

«использует»

«выбирает»

«использует»

«использует»

«использует»

«использует»

«использует»

«использует»

«использует»

«использует»

«использует»

Управление

данными«модифицирует»

«использует»

Разработка системы

анализа результатов

«модифицирует»

Разработка блока создания тестовых данных. Как уже отмечалось ранее, блок создания тестовых данных состоит из

двух частей – подсистемы автоматизированного получения тестовых данных

и тестов, формируемых непосредственно разработчиком тестов. Создание

конфигурационной информации тестов целиком является обязанностью

человека, ответственного за тестирование.

Отбор тестов

согласно

тестируемым требованиям

Сохранение

тестов в специальной

директории

Формирование

набора тестов

Формирование сценариев

тестов к ТКАСАО

Определение

структуры и конфигурации

тестов

Разработчик тестов

Система автоматической

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

Генерация тестов

Формирование

тестов

Написание вручную

Написание

с использованием

средства автоматизации

Разработка подсистемы автоматизации тестирования Подсистема автоматизации тестирования состоит из двух теснейшим

образом взаимосвязанных частей – блока управления прогоном тестов и

блока обработки результатов.

Обработка сохраненных результатов подразумевает, во-первых,

принятие решения о том, пройден или провален тест, а во-вторых,

29

предусмотреть возможность тестирования характеристик, количеством

одновременно обслуживаемых запросов, одновременным использованием

большим числом пользователей при нагрузочном тестировании, анализ и

обработку полученных показателей тестируемых процессов.

Однако сразу стоит отметить, что снятие характеристик нагрузочного

тестирования невозможно без привлечения специальных возможностей,

предоставляемых средой исполнения.

Взаимосвязи рассмотренных подсистем представлены на следующей

диаграмме.

Выполнение

тестового прогона

Обслуживание БД

результатов

Обработка

сохраненных результатов

Реакция

на превышение лимитов

использованния ресурсов

Определение

параметров нагрузки

Получение и сохранение

результатов

тестирования

Система

автоматизации

выполнения тестов

Система

обработки результатов

Система учета

использованных ресурсов

элементы функционального тестирования

элементы нагрузочного тестирования

Из данной диаграммы можно заметить одну интересную особенность

проектируемой нами системы тестирования, а именно: функциональное

тестирование и нагрузочное тестирование выполняются параллельно. Это

30

позволяет значительно сократить сроки тестирования в целом. Отметим, что

подобное совмещение во времени двух различных видов тестирования

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

тестирование функциональности ТКАСАО требует обработки в рамках

одного теста большого количества тестовых данных, что создает

благоприятные условия для тестирования производительности.

2.3. Диаграмма деятельности

Система обработки

результатов

Система автоматизации выполнения

тестов

ТестерРазработчик тестов

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

Прогон одиночного

тестаПрогон набора

С использованием

средств автоматизации

Без использования

средств автоматизации

Анализ,

обработка результатов

тестирования

Разработка тестового скрипта

Ручное

написаниеС использованием

средств автоматизации

Тестовый сценарий

Прервать

выполнение

Сохранить

промежуточные

результаты

Создание и подготовка

внешнего набора данных

Сохранение тестового

скрипта

Создание тестового

набора

Сохранение тестового

скрипта

Ручной прогон

Сохранение тестового

скрипта

Сохранение тестового

скрипта

Рассмотрим диаграмму деятельности, которая представлена.

Если хорошо приглядеться, то можно увидеть интересные моменты.

Возможно, осуществление прогона и создания тестов параллельно, при

условии, что при прогоне будет заранее известен сценарий. Это значительно

уменьшает время тестирования продукта. Также прогон тестов с

использованием средств автоматизации занимает значительно меньше

времени, чем те же действия вручную, иначе какой смыл был

автоматизировать.

2.4 Диаграмма классов.

Диаграмма классов по праву занимает центральное место в объектно-

ориентированном подходе. Перед тем как приступить к описанию

диаграммы классов, хотелось бы обратить внимание на одну особенность,

связанную с характером использованием этих диаграмм разработчиками. Я

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

представления понятий изучаемой предметной области.

33

+создание списка тестовых метрик()

+создание тестовой стратегии()

+создание сценариев()

+тестовые документы

+тестовая стратегия

+расписание тестовых циклов

+фиксация тестовой конфигурации

+список тестовых метрик

Тестовый план

+привести продукт в нужное состояние()

+верифицировать то что подлежит проверке()

+привести продукт в исходное состояние()

+тип теста

+время проведения теста

+статус теста

+название тестируемой программы

+способ формирования выборки

+тип контроля

+количество действий

+схема проведения теста

+название тестового случая

-замысел

-критерий покрытия

Тест

+выполнение тестов()

+начальные параметры

+количество часов прогонки

+количество пройденных тестов

+степень покрытия

+пользовательские параметры

+метрики покрытия

Модель тестового робота

+сворачивание окна()

+разворачивание окна()

+активирование окна()

+нажатие кнопки()

+получение сведения о состоянии кнопки()

+ввод информации в текстовое поле()

+удаление элементов предыдущего поля()

+получение значения текста в поле ввода()

+получение значения текста в поле ввода()

+получение количества строк в таблице()

+получение количества столбцов в таблице()

+возврат значения ячейки таблицы()

+клик на интерактивной кнопке()

+клик на ссылке()

+начальные параметры

+состояние окна

+пользовательские параметры

+начальное состояние элементов интерфейса

+конечное состояние элементов интерфейса

Исполняющая система интерпретора

+входная информация

+условия выполнения действий

+последовательность выполнения действий

+ожидаемый выходнойрезультат

Сценарий тестирования

+привести продукт в нужное состояние()

+верифицировать то что подлежит проверке()

+привести продукт в исходное состояние()

+начальные параметры

+время прогонки

+степень покрытия

+пользовательские параметры

+замысел

+операция

Элементарная проверка

+привести в нужное состояние()

+верифицировать то что подлежит проверке()

+привести продукт в исходное состояние()

+начальные параметры

+сходные задачи

+набор элементарных проверок

+время прогонки

+замысел

Тестовый набор+интерпретация тестовых данных()

+выполнение имитирующих функции()

+входные данные

+скрипт

+код ошибки

Интерпретатор языка сценариев

*

1

*

1

1

1

+разбор сценария()

+анализ сценария()

+лексеммы

Синтаксический анализатор языка сценариев

1

1

+запись событий()

+запись операций()

+логирование()

+документирование()

+электронные документы

+базы данных

Журнализатор

+анализ()

+разбор()

+обработка()

+покрытие функциональных требований()

+покрытие найденных дефектов()

+начальные параметры

+эталонные значения

+полученные значения в ходе прогона

Анализатор результатов тестирования

* 1

11

*

1

*

1

*

*

Начнем рассмотрение диаграммы классов с введения понятий:

элементарная проверка - минимальный элемент тестирования. Итак, для

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

действия, сравнить полученные результаты с ожидаемыми и сделать вывод о

том, имеется баг или нет. Все это и есть элементарная проверка. Хорошая

элементарная проверка состоит из трех частей:

Привести тестируемый продукт в нужное состояние

Верифицировать то, что подлежит проверке

Привести продукт в исходное состояние

Существенно то, что акт верификации только один. Именно поэтому

элементарную проверку нельзя измельчить, разбить на несколько. Именно

поэтому она является минимальным элементом проверки. Если верификаций

больше, чем одна, то это не элементарная проверка, а его фальсификация.

Первый и третий методы элементарной проверки тоже очень важны. Они

делают разные тест кейсы независимыми друг от друга. Их можно выполнять

34

в любой последовательности. Это исключительно важно при автоматизации

тестирования.

Тестовый набор – набор элементарных тестовых проверок, т.е. он

агрегирует в себя тесты, которые так и представлены на диаграмме.

2.5 Диаграмма последовательности.

На данном этапе представлены диаграммы последовательности для двух

вариантов использования: для авторизации доступа и для

автоматизированного прогона тестов.

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

при прогоне тестов.

В начале тестер запускает робота, которому нужна база скриптов. При

возвращении запроса из базы его перехватывает имитатор тестов, который

вызывает интерпретатора и он в свою очередь парсер скрипта. После

интерпретации происходит обработка результатов и сохранение.

TestRunner(): Запуск робота

Робот

LoadTestSuite: Загрузка из базы тестовых наборов

БДИнтерпретаторИмитирующая система интепретат

ора

Сохранение результатов

ProcessingResult(): обработка результатов

SaveResult(): Сохранение рузультатов

Обработка результатов

Верхний пакет::Тестер

interpretationScript(): Интерпретация скриптов

Анализатор

TestRun(): Запуск скриптов

Parse(): Парсинг

Пользователь

Браузер Система авторизации доступа База данных

Вызов браузера()

Приложение

Вызов приложения

и ожидание появления

формы авторизации()

Input(login, pass): Ввод имени и пароля

в поля формы()

Форма ввода имени и пароля

Send(login, pass): Отправка данных()

QueryToFind(): Поиск записи в базе

новый

Интерфейс приложения

2.6 Диаграмма развертывания.

Как уже отмечалось ранее, структура системы тестирования во многом

зависит от структуры тестируемой ТКАСАО. Для развертывания системы

этот тезис является еще более актуальным. Во-первых, ТКАСАО -

распределенная система, и ее отдельные компоненты, такие как база данных,

веб-сервер могут располагаться на различных хостах сети.

На одном сервере мы разместили:

БД ТКАСАО

ТКАСАО

САТ серверная часть

БД САТ.

Разносить по разным хостам базу данных ТКАСАО и саму ТКАСАО

лишено смысла по той простой причине: размер самой тестируемой системы

не велик, а размер базы данных не будет занимать чересчур много дискового

пространства. Выносить в отдельный сервер базу САТ не представляется

необходимым, в связи с тем, что максимальный объем который она сможет и

занять рассчитывается в 10Гб.

На рабочей станции разместилась сама клиентская часть с имитатором

действий пользователя.

В связи с этими предположениями мы развернули диаграмму следующим

образом.

38

Рабочая станция

Сервер

БД ТКАСАО

ТКАСАО

Серверная часть

САТ

Интерфейс1

БД САТ

Интерпретатор

сценариев

Клиентская часть САТ

Имитатор

действий пользователя

Браузер Интерфейс2

39

2.7 Диаграмма ER.

Тестовый вариант

Время проведения

Название тестируемой программыНомер теста

Статус

Статус релиз

id

Тест

Тестовый набор

id

Тестовый вариант

Статус

Тест

id

Деятельность

Имя элемента

Значение

Деятельность

id

Название

Действие

id

Имя

Проверка

id

Имя

Локатор

id

Имя

Элемент

id

Имя

Для хранения статистики о проведенных тестах создадим таблицу Тестовый

вариант. Она будет иметь примерно следующий вид:

Время проведения теста

Название тестируемой программы

Номер теста

Статус PASS, если тест прошел, и FAIL, если тест не прошел.

Релиз статус

При разборе данной таблицы можно вывести следующие результаты:

Время занимаемое тестированием данной программы

Определить трудные тесты которые чаще всего не проходят

40

Определить вероятность прохождения тестов

Определить скорость запуска тестов(количество пройденных или не

пройденных тестов за день)

Тестовые варианты объединяются в тестовые наборы.

2.8 Проектные решения процесса тестирования.

2.8.1 Механизм встраивания контрольной точки

Поиск ошибок в программе, основанный на проверке соответствия записи

программы некоторым формальным правилам, хотя и является достаточно

эффективным, однако не обеспечивает выявления всех ошибок. Это, прежде

всего, объясняется большим разнообразием ошибок, трудностями выделения

из описания программы информации, необходимой для выполнения

проверки, а также сложностью формализации постановки и решения задач

формирования эталона, который используется при поиске ошибок. Более

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

по результатам исполнения программы на заданных детерминированных

наборах значений исходных данных - отладка по результатам

детерминированного тестирования.

Чтобы обнаружить и локализовать ошибку, необходимо тестировать

программу.

В тест, наряду с входным и выходным наборами необходимо добавить

еще точку входа и точку выхода. Входному и выходному наборам

соответствуют набор исходных данных и результатов исполнения

программы. Точкам входа и выхода соответствуют команды или операторы

программы, которыми начинается и оканчивается исполнение программы

для заданных исходных данных. Таким образом, в каждой тестовой

совокупности точке входа соответствует входной набор, а точке выхода —

выходной набор. Точки входа и выхода стоит задавать символическим

41

наименованием меток, которые стоят перед соответствующими командами

или операторами программы. Точка входа может оказаться одним из входов

в программу либо некоторой промежуточной точкой программы. Аналогично

точкой выхода может быть один из выходов программы либо произвольная

точка программы. Контрольные точки, соответствующие точкам входа и

выхода одного тестового набора, образуют пару. Пару контрольных точек

могут составлять только те точки программы, которые связаны хотя бы

одним путем обработки информации.

Кроме данных о входных и выходных наборах и контрольных точках,

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

соответствующими им контрольными точками процесса исполнения

программы. Эти точки определяют путь исполнения программы при

заданном входном наборе. В зависимости от того, какая информация

используется при тестировании, различаются метод отладки только по

исходным данным и результатам и метод отладки с учетом промежуточных

результатов исполнения программы.

Работоспособность или правильность работы программы на заданном

тесте устанавливается, как правило, путем сравнения эталонных

(предполагаемых) и реальных результатов исполнения программы. При

существующей технологии отладки анализ результатов выполняется

программистом. Программа неработоспособна при заданном тесте, если хотя

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

контрольная точка выхода, значения промежуточных или окончательных

результатов не совпадают с реальными результатами.

Планирование отладки включает такие задачи, как

выбор перечня контрольных точек входа и выхода из программы, а

также

выбор соответствующих наборов значений исходных данных и

определение предполагаемых значений результатов исполнения программы.

42

Диаграмма состояний отладки программы по контрольным точкам

Планирование отладки:

Выбор контрольных

точек, трасс.

Составление тестов.

Планирование отладки:

Выбор контрольных

точек, трасс.

Составление тестов.

Составление задания

на отладку

по очередному тесту

Составление задания

на отладку

по очередному тесту

Ввод отладочного

задания теста.

Подготовка к тестированию

Ввод отладочного

задания теста.

Подготовка к тестированию

Выбор очередного

тестового набора

Выбор очередного

тестового набора

Исполнение программы

при очередном тесте

Исполнение программы

при очередном тесте

Информирование о

результатах

тестирования

Информирование о

результатах

тестирования

Анализ результатов

тестирования

Анализ результатов

тестирования

Анализ расхождения

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

и локализация и

области предполагаемой ошибки

Анализ расхождения

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

и локализация и

области предполагаемой ошибки

Результаты

совпадают с

предполагаем

ыми

Исчерпаны ли

тестовые

наборыВнесение исправлений

Проведение повторного

испытания на исходном

тестовом наборе

Внесение исправлений

Проведение повторного

испытания на исходном

тестовом наборе

Планирование проверки

выделенной части программы.

Выбор контрольных точек и тестов

Планирование проверки

выделенной части программы.

Выбор контрольных точек и тестов

Составление дополнительного

отладочного задания

Составление дополнительного

отладочного задания

Ошибка обнаружена с

детальностью,

достаточной

для исправления

Идея заключается в том, чтобы не печатать промежуточные результаты

вычислений, а получать их в ходе выполнения программы, например, с

помощью отладчика при первом запуске. В дальнейшем же в тесте в эти

места встраивать проверки соответствия эталонного значения, полученного

43

при первом прогоне теста в отладчике, с текущими вычисляемыми

результатами. В случае выявления расхождения в тесте организовать уход на

аварийную веточку с соответствующей печатью, либо завершать как fail.

Другой вариант организации этой же схемы – печатать промежуточные

значения при первом запуске теста. Полученную последовательность

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

как массив эталонных значений. В тех местах в программе, где вызываются

функции печати, заменить их вызовы условными ветвлениями, управление в

которых осуществляется посредством сопоставления очередного числа из

массива эталонных значений с промежуточными вычислениями.

В качестве промежуточных вычислений может быть взята несложная

хэш-функция от текущего контекста. Чем больше из перечисленных

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

промежуточного значения, тем более полно будет проверяться контекст при

исполнении теста. Но с другой стороны, при этом мы будем вносить все

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

частоты встраивания таких контрольных точек в тест. При достаточно частом

их появлении исходный код задачи сильно изменится.

2.8.2 Механизм выделения области локализации ошибок.

Поиск ошибок в программе по результатам тестирования является

достаточно трудно формализуемой задачей. На практике эта задача решается,

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

выделить две фазы. Первая фаза: сравнение результатов тестирования с

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

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

несовпадение.

44

Если данные о предполагаемых результатах исполнения программ

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

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

результатам сравнения и описанию программы. Эта операция представляет

вторую фазу решения задачи. На практике для поиска ошибок программист

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

информацию об управляющих, функциональных и информационных связях

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

граммист прогнозирует возможные нарушения описания программы,

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

Рассмотрим возможные постановки задач диагностики по результатам

тестирования. В общем случае задача локализации ошибок ставится

следующим образом. Имеется диагностическая модель программы, заданная

совокупностью <V, X > и представленная направленным графом, в котором

V—множество вершин, соответствующих линейным участкам команд, X —

множество вершин, соответствующих величинам, которые обрабатываются

программой. Заданы контрольные точки входов и выходов, а также наборы

наименований исходных данных и результатов, которые представляются

соответствующими вершинами множеств V и X.

Обозначим параметры некоторого тестового набора следующим

образом: vi — контрольная точка входа, ve — контрольная точка выхода, Хs

— множество вершин, соответствующих исходным данным, a Xr —

множество вершин результатов.

Можно предположить, что для успешного решения локализации

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

вершины vi, ve. На принципах, аналогичных выделению связывающего

подграфа, можно построить процедуру уточнения пути по дополнительной

45

информации о неверных результатах и информационно-функциональных

связях модели программы.

Задачу выделения подграфа, связывающего две произвольные вершины

графа, одна из которых достижима из другой, сформулируем следующим

образом. Пусть дан направленный граф G(V, D), отражающий связи по

управлению между участками программы, где V—множество вершин Vi Є V,

i=1, 2,.. .,п, a D — множество дуг, задаваемых парами вершин. Для двух

вершин vi, ve графа G, одна из которых соответствует контрольной точке

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

GP(VP, Dp) который включал бы в себя все вершины и дуги трафа G(V, D),

принадлежащие путям, которые ведут из вершины vi в вершину ve. Подграф

Gp(VP, Dp) будем называть максимальным подграфом связи вершин vi,ve,

еcли он образован из всех вершин vl Є Vp, для которых выполняются два

условия: вершина vl достижима из вершины vi, и вершина vj — из вершины vl.

Для этого нам стоит осуществить пошаговое движение от одной

вершины к другой в направлении дуг. При этом в точках разветвления

движение происходит по всем возможным направлениям. Из определения

операции распространения волны следует, что на каждом новом шаге

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

еще не проходила, если такие вершины еще остались на текущем шаге

процесса.

Алгоритм выделения подграфа, связывающего точку входа и выхода

46

Начало

Конец

Сформировать

множество W*

вершин сквозь

которые прошла

волна

Построить граф

обратный

исходному

Сформировать

множество W**

вершин

Определить

множество

вершин Vp

Выделение дуг

которые связывают

вершины vi veмежду собой

Выполнением операции

пересечения

сформированных ранее

множеств W* и W**

Высота текстового поля и

связанной с ним линии

увеличивается или

уменьшается по мере

добавления текста. Чтобы

изменить ширину

примечания, перетащите

маркер сбоку.

изменением направлений

дуг исходного графа на

обратные

путем пошагового

движения по дугам графа

G(V, D), начиная с

вершины vi

47

2.8.3 Разработка архитектуры организации тестов

Конфигура

тор

Генератор

тестов

системы

Имитатор

действий

пользователя

Выходные

данные

Сравне

ние

Желаемое

поведение

Отбор

Механизм обработки выходных данных

(ненужные отбрасывем)

Адаптация

Прагматизм

Выносливость

Генератор моделей

обучаемого

2.8.4 Разработка факторов влияющие на оценку обучающего

тестирования

Очевидно, что для построения эффективной модели обучаемого на

основе оценок требуется более глубокое изучение структуры «ошибок»,

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

Если исходить из того, что обучающее тестирование базируется на

стратегии случайно формирующихся тестовых выборок, то многократное

моделирование в различных режимах даст богатый материал для анализа

ситуации теста. Тогда все факторы можно разделить на три основные

48

категории: формализуемые, частично формализуемые и плохо предсказуемые.

В таблице представлена информация о том, как некоторые факторы

распределены по отмеченным ранее этапам компьютерного тестирования.

При внимательном рассмотрении таблицы можно заметить, что

некоторые факторы говорят не столько о знаниях, сколько о процессе

тестирования. В частности, из них можно выделить такие, от значения

которых зависит целесообразность всего процесса оценки. Это такие крайние

случаи, где можно с высокой степенью уверенности говорить о случайности

результата: чрезвычайно малое время прохождения теста («прощѐлкивание»),

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

(недостижение математического ожидания). Поэтому стоит учитывать такие

ситуации и этого можно достичь посредством анализа совокупности всех

факторов, собранных при тестировании, либо заданных априори. Например,

моделируя обучаемого, при норме прохождения теста в 20 минут модель-

систему должен «заинтересовать» результат, полученный уже через 4

минуты. В сочетании с распределениями неверно отмеченных и

пропущенных ответов тестовых заданий это даст дополнительную

информацию о процессе тестирования, позволяющую скорректировать

итоговый балл, либо отказать тестируемому в выставлении оценки. На

первых этапах достаточно будет промоделировать обучаемого по таким

факторам: адаптация, прагматизм, выносливость.

Таблица. Некоторые факторы, влияющие на оценку обучающего тестирования

№ Фактор Степень

формализации Источник

1 Случайность ТВ Высокая База тестовых заданий

2 Время тестирования Высокая

Программа

компьютерного

тестирования

3 Прагматизм

тестируемого Высокая Поведение тестируемого

4 Наличие тренировок Высокая Поведение тестируемого

49

5 Вероятность угадывания Высокая

Программа

компьютерного

тестирования

6

Распределение верных /

неверных /

пропущенных ответов

Высокая Поведение тестируемого

7 Режим тестирования

(тренировка/контроль) Высокая

Программа

компьютерного

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

тестируемого

8 Сложность теста Средняя База тестовых заданий

9 Степень адаптации Средняя

Программа

компьютерного

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

тестируемого

10 Динамика обучения Средняя

Программа

компьютерного

тестирования,

успеваемость

тестируемого при

предыдущих

тестированиях

11 Знания тестируемого,

умения и кругозор Средняя

Поведение тестируемого,

программа компьютерного

тестирования

12 Качество тестового

задания Низкая База тестовых заданий

13 Внешние воздействия на

тестируемого Низкая Поведение тестируемого

14 Выносливость Высокая Поведение тестируемого

Очевидно, что для качественного моделирования при обучении

требуется учитывать все три этапа единовременно. При этом первостепенное

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

предположить появления у системы механизма оценивания, состоящего из

50

этапов подсчѐта балла, его корректировки и перевода в нормативную

оценочную шкалу, то соответственно и моделирование обучаемого будет

исходить от этой поправки.

2.8.5 Разработка базовых моделей.

Т.е на основе оценки обучаемого мы можем смоделировать

предполагаемое поведение. Для моделирования возьмем за основу систему

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

По оси абсцисс: количество вопросов в тесте

По оси абсцисс: вероятность правильного ответа

Kд – конфигурационные данные, которые могут изменить или

калибровать модель.

1)адаптация обучаемого моделируется по закону.

0)/(

0

,

,1

xxey

xxy

xKд

p

n

1

50

2)выносливость обучаемого моделируется по закону.

Y = - arcctg(x/Kд-a) + 1

51

p

n

50

1

3)прагматизм обучаемого моделируется по закону.

0)/(

0

,

,0

xxey

xxy

xKд

p

n

50

1

Реализация этих факторов сводится по получению оценки запрограммировать эти кривые, сгенерировать тесты системы, подать их на

вход имитатор действий и на выходе ожидаются данные - результаты тестирования, которые хранятся в журнале успеваемости.

На основе этого моделирования можно запустить тестирование «на стресс».

И если выдвинуть гипотезу, что если нам удается не умозрительно обнаружить что люди обладают вот такими коэффициентами выносливости,

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

52

3. Реализация системы.

3.1 Реализация имитатора поведения.

Это объектно-ориентированное JavaScript приложение, которое может

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

них команды для манипуляции браузером и команды для выполнения

определенных проверок.

Архитектура имитатора действий пользователя представлена на рисунке:

HTTP REQUEST

ВЕБ- приложение

(ТКАСАО)Браузер

HTTP запрос

HTTP ответ

Основа браузера

(java script)

Интерпретатор

сценария

Сценарии

САТ

Основной элемент САТ основа браузера, написан на JavaScript. Это

позволяет сценариям тестов реализоваться в поддерживаемых браузерах.

Основа браузера выполняет команды, полученные от сценариев теста,

которые написаны или в HTML, с использованием схемы таблицы .

var BrowserBot = function(topLevelApplicationWindow) {

this.topWindow = topLevelApplicationWindow;

this.topFrame = this.topWindow;

this.baseUrl=window.location.href;

this.buttonWindow = window;

this.currentWindow = this.topWindow;

this.currentWindowName = null;

BrowserBot.prototype.selectWindow = function(target) {

if (target && target != "null") {

this._selectWindowByName(target);

} else {

this._selectTopWindow();

}

};

53

BrowserBot.prototype.openLocation = function(target) {

var win = this.getCurrentWindow();

LOG.debug("openLocation newPageLoaded = false");

this.newPageLoaded = false;

this.setOpenLocation(win, target);

};

Для того чтобы попробовать в работе, его необходимо положить в папку,

доступную для web-сервера и набрать в строке браузера приблизительно

такой путь: http://localhost/TestRunner.htm. Никаких дополнительных

настроек не требуется.

Вот так должно выглядеть окно вашего браузера после запуска :

Рабочее окно поделено на несколько областей. Снизу находится рабочая

область браузера. Здесь будут отображаться страницы тестируемого сайта. В

левом верхнем углу находится список тестовых случаев (TestCase-ов),

которые могут быть выполнены для текущего приложения. Это список

тестовых случаев называется TestSuite. В центральной верхней части

54

находится содержимое текущего TestCase-а, в правой верхней части –

управляющие кнопки для запуска тестов, а также статистика выполнения

тестов.

Для запуска тестов нажмите кнопку «Все Тесты» и начнется проверка.

Возможно выполнение тестов в трех скоростных режимах: выполнение,

выполнение с паузой и пошагово. Выполнение - выполняет тесты с

максимальной скоростью. Выполнение с паузой делает паузу в 0.5 сек (по-

умолчанию) на каждой команде, что может быть очень удобно при

визуальной проверке правильности работы сайта. Пошагово – вы

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

3.2 Реализация базы данных

Для реализации базы данных тестов системы тестирования была

выбрана СУБД PostgreSQL. Данный выбор был обуславливается следующим

рядом причин:

55

открытый исходный код

полное соответствие требованиям, предъявляемым к

современным реляционным базам данных (поддержка ссылочной

целостности, предоставление богатого набора типов данных и т.

п.)

качественная поддержка хранимых процедур

простота создания и администрирования баз данных

опыт работы проектировщика с данной СУБД

Общее описание таблиц, из которых состоит рассматриваемая база

данных, было дано в предыдущем разделе. Здесь приведем лишь фрагменты

SQL-кода, отвечающего за создание этих таблиц.

Реализация тестов

Содержимое Теста

Тест это обычные html - страницы с одной таблицей содержащей команды.

Каждая строка таблицы содержит 3 колонки

В первой колонке находится команда или утверждение.

Вторая колонка содержит цель команды или утверждения. Цель

задается с одного из поддерживаемых устройств обнаружения

элемента. Обычно используется ID или название элемента, также

возможно поддержка устройства обнаружения DOM.

В третий колонке находятся значения которые определяют параметры

для команд и утверждений. Это может быть требуемое значение для

текстового поля при использовании команды вывода на экран.

Организация тестов

56

Как уже было указано, тесты организованы в список, который называется

тестовый набор. Он также является обыкновенной html страницей,

приблизительно такого содержания:

<html>

<head>

<meta content="text/html; charset=win-1251" http-equiv="content-

type">

<title>Тестовый набор</title>

</head>

<body>

<table cellpadding="1" cellspacing="1" border="1">

<tbody>

<tr><td><b>Тестовый набор</b></td></tr>

<tr><td><a href="./TestOpen.html">ТестОткрытия</a></td></tr>

<tr><td><a

href="./TestLogin.html">ТестАвторизации</a></td></tr>

</tbody>

</table>

</body>

</html>

Теперь объясним чуть поподробнее то, как организуются тесты и как они

хранятся на диске. Все файлы тестов и наборов являются обычными

текстовыми html файлами и лежат в папке /tests. При запуске SAT пытается

найти файл TestSuite.html в этой папке и загружает список тестов из TestSuite

в левое верхнее окно. При щелчке на одну из ссылок файла TestSuite.html в

окно текущего теста загружается содержимого соответствующего файла с

командами.Вот в принципе и все. Для расширения набора тестов какого-либо

приложения мы должны создать соответствующий TestCase.html файл и

поместить на него ссылку в TestSuite.html. Отметим здесь же, что хотя SAT

воспринимает тесты только в виде html страниц, это вовсе не значит, что

сами тесты должны быть html файлами. Они могут генериться при помощи

PHP, JSP, CGI, в общем, при помощи любой технологии, которая может

показаться удобной.

Составляющие команд тестов В SAT существует несколько основных понятий:

действия

проверки

локаторы

57

Действия

Действия (actions) используются для того, чтобы управлять браузером из-под

SAT. Набор действий на данном этапе недостаточно широк. Ниже приведем

список наиболее часто используемых действий. Итак вот некоторые из

действий SAT:

• open – указывает браузеру открыть страницу по определенному

адресу

• click – указывает браузеру щелкнуть по ссылке или по элементу

формы, например, для пометки checkbox-а

• type – указывает браузеру ввести новое значение в элемент формы

• select – указывает браузеру выбрать определенное значение

<option> внутри <select> тега формы

• selectWindow – указывает браузеру переключить фокус на другое

окно

• goBack – указывает браузеру вернуться на предыдущую страницу

• close – указывает браузеру закрыть текущее окно

Проверки

Проверки (checks) используются для проверки правильности поведения

приложения. Любая проверка представлена двумя типами – assert и verify.

Если в тесте стоит проверка assertSomething и она не выполняется, тест

58

прекращает свою работы, а если verifySomething – то выдается сообщение об

ошибке, но тест продолжает работу.

Вот список проверок:

• verifyLocation / assertLocation – проверяет текущий URL окна

браузера

• verifyTitle / assertTitle – проверяет заголовок окна

• verifyValue / assertValue – проверяет, что поле формы имеет ука-

занное значение

• verifyTextPresent / assertTextPresent – проверяет, что текст стра-

ницы содержит указанный текст

• verifyElementPresent / assertElementPresent – проверяет, что эле-

мент присутствует на текущей странице

Локаторы

Локаторы используются для нахождения элементов, к которым относятся

команды. Список локаторов недостаточно большой:

• id – используется атрибут id (идентификатор) элемента

• name – используется атрибут name элемента

• identifier – используется атрибут id элемента, если по id-у эле-

мент не найден, то поиск будет вестись по атрибуту name

• dom – используется для поиска элемента по DOM выражению,

которое должно начинаться с document.

59

• link – используется для нахождения ссылок с указанным текстом.

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

чтобы все стало понятно. Возьмем знакомую форму аутентифика-

ции.

<form id='login_form' name='login_form' action='' method='post'>

Login : <input id='login' name='login' type='text' size='40'><br>

Password : <input id='password' name='password' type='password'

size='40'>

<input id='login_button' type='submit' value='Login'>

</form>

Для заполнения поля login формы login_form можно воспользоваться

следующими командами:

<tr>

<td>type</td>

<td>id=login</td>

<td>vasa</td>

</tr>

Использовали локатор id.

<tr>

<td>type</td>

<td>name=login</td>

<td>vasa</td>

</tr>

Использовали локатор name.

<tr>

<td>type</td>

<td>identifier=login</td>

<td>vasa</td>

</tr>

Использовали локатор identifier.

<tr>

<td>type</td>

<td>xpath=//input[@name=’login’]</td>

<td>vasa</td>

60

</tr>

Использовали локатор dom.

Если в команде не указано явно название типа локатора, например не

dom=document.forms[‘login_form’].login,

а просто

document.forms[‘login_form’].login , тогда происходит последовательный

поиск элемента при помощи следующих типов локаторов:

• identifier

• dom

Работа с popup-окнами

По умолчанию все команды применяются к текущему окну браузера. Так как

в ТКАСАО есть ссылки на popup-окна, то для того, чтобы команды

применялись к новому окну – введено действие selectWindow(name). После

того, как вы выполнили команду, которая закрывает popup-окно, выполните

команду selectWindow(null) для того, чтобы вернуться в главное окно.

Допустим, у вас есть такой html код:

<html>

<head>

<script type="text/javascript">

function openWindow() {

myPopupWindow = window.open('/path_to_popup_window',

'popup_window',

'height=200,width=500,top=400,left=50');

}

</script>

</head>

<body>

<button id="popup_link" onclick="openWindow();">Click here to open

a popup window</button>

</body>

</html>

Тогда ваш тест будет выглядеть приблизительно так:

<tr>

<td>click</td>

<td>popup_link</td>

61

<td>&nbsp; </td>

</tr>

<tr>

<td>selectWindow</td>

<td>popup_window</td>

<td>&nbsp; </td>

</tr>

[… команды для popup-окна]

<tr>

<td>click</td>

<td>close_popup</td>

<td>&nbsp; </td>

</tr>

<tr>

<td>selectWindow</td>

<td>null</td>

<td>&nbsp; </td>

</tr>

[… команды для главного окна]

Автоматическое выполнение тестов и сохранение результатов тестирования.

TestRunner.html понимает такой атрибут, как auto=true. Если этот параметр

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

http://project1/tests/TestRunner.html?auto=true, то сразу же начнется

выполнение всех тестов в режиме run. После выполнения тестов он

попытается сделать запрос по пути /postResults, куда он передаст результаты

выполнения тестов.

Значение /postResults можно изменить, передав в запрос параметр resultsUrl.

А тут дописывается приложение на php, которое будет сохранять и

интерпретировать результаты выполнения тестов.

3.3 Параметры реализации

Наименование модуля Количество строк Размер в байтах

Инициатор тестирования (Testrunner.js)

104 3686

62

Диалог с пользователем(Api.js) 322 10825

Движок (BrowserBot.js) 341 11231

Метрики(Metrics.js) 51 1808

Результат тестирования(TestResult.js)

128 3891

(Tokenizer.js) 152 5410

Панель управления (TestRunnerControlPanel.js)

123 3745

Тестовый вариант(TestCase.js) 117 3686

(TestRunner.html) 150 6802

Всего 1488 51084

Среди общего количества строк примерно 150-170 строк являются

комментариями и разделителями. Таким образом общее количество

операторных строк получается примерно 1400, что дает следующую оценку

по Б.Боэму:

ЧМ = 2,4*1,5*1,41,05

= 5,1 человеко-месяцев, где коэффициент 1,5 является

поправкой, учитывающей отсутствие опыта аналогичной разработки у

программистов.

63

Заключение

В рамках выпускной работы созданы базовые объектно-ориентированные

модели системы тестирования, язык сценарием тестирования и прототип

системы объемом примерно в 1400 операторных строк. Система

обеспечивает автоматическое выполнение всего комплекса тестов в целом,

интерпретацию сценариев на разработанном языке и представление

результатов функционального тестирования в форме, позволяющей

различать состояниям теста «пройден» и «провален.

В ходе выполнения работы определились следующие основные задачи

исследования, которые планируется решать в рамках магистратуры:

разработка и исследование моделей тестируемых объектов и процессов

с целью обеспечения автоматизации формирования сценариев тестирования

и обеспечения полноты тестов;

разработка и исследование математических моделей процессов

автоматической генерации тестов;

Развитие языка сценариев и разработка семейств сценариев

тестирования, покрывающих тестируемую систему в максимально

возможной степени;

Разработка шаблонов проектирования ТКАСАО, позволяющих встраивать в

проектные решения средства самотестирования, и выполнение

реинжениринга ТКАСАО на основе этих шаблонов.

64

Список литературы

1. Липаев В.В. Отладка систем управляющих алгоритмов ЦВМ реального

времени. – М.: «Советское радио», 1974, -328c.

2. Винниченко И. Автоматизация процессов тестированиия.: Издательский

дом «Питер», 2004.

3. Макгрегоф Д., Сайкс Д. Тестирование объектно-ориентированного

программного обеспечения. Практическое пособие: Пер. с англ. /

Макгрегоф Д., Сайкс Д. – К.: ООО «ТИД ДС». 2002. -432 с.

4. Леффиигуэл, Дин, Уидриг , Дон. Принципы работы с требованиями к

программному обеспечению. Унифицированный подход.: Пер. с англ. –

М.: Издательский дом «Вильямс», 2002. – 448с.

5. Саммервил, Иан. Инженерия программного обеспечения.: : Пер. с англ. –

М.: Издательский дом «Вильямс», 2002. – 624с.

6. Тамре Л. Введение в тестирование программного обеспечения.: Пер. с

англ. / Л.Тамре. – М.: Издательский дом «Вильямс», 2003.

7. Фаулер М. UML. Основы.: Пер. с англ. / М.Фаулер, К.Скотт. –

СПб.: Символ-Плюс, 2002.

8. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объктно-

ориентированного проектирования. Паттерны проектирования. – СПб:

Питер, 2001.

9. Калбертсон Р. Быстрое тестирование.: Пер. с англ. / Р.Калбертсон. – М.:

Изд. дом "Вильямс", 2002.

10. Веллинг Л., Томсон Л. Разработка Web-приложений с помощью PHP и MySQL, 2-е издание.: Пер. с англ. – М.: Издательский дом «Вильямс»,

2004. 11. Аргерих Л. И др. Профессиональное PHP программирование, 2-е издание.

– Пер. с англ. – СПб: Символ – Плюс, 2003.

12. Кренке Д. Теория и практика построения баз данных. 9-е изд. – СПб.:

Питер, 2005.

13. Дронов В.А. Java Script в WEB дизайне. – СПб.: БХВ - Петербург, 2001.