Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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



Содержание

• Введение
• Глава 1. Обзор средств и методов автоматизации
• 1.1 Назначение и специфика автоматизации
• 1.2 Обзор средств автоматизации
• Глава 2. Методологии автоматического тестирования
• 4.1 Record-Run script
• 4.2 Data-Driven Testing
• 4.3 Object-Driven Testing
• 4.4 Вывод
• Глава 3. Практическая реализация
• 3.1 Global XB
• 3.2 GCube
• 3.3 Thistle
• Заключение
• Список литературы
• Приложение 1
• Приложение 2
• Приложение 3
• Приложение 4
• Приложение 5
• Приложение 6
• Приложение 7
• Приложение 8
• Приложение 9
• Приложение 10
• Приложение 11



Введение

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

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

Постановка задачи

У каждой компании-разработчика программного обеспечения рано или поздно возникает необходимость во внедрении автоматизации тестирования.

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

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

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

определить цели тестирования и вывести критерии эффективности автоматизации

ознакомиться с существующими средствами и методиками автоматизации

· вывести алгоритм разработки эффективных автоматических тестов с наименьшими затратами

· реализовать полученный алгоритм на примере приложенийGlobal XB, GCube и Thistle



Глава 1. Обзор средств и методов автоматизации

1.1 Назначение и специфика автоматизации

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

Современных менеджеров и разработчиков программного обеспечения просят осуществлять подготовку своих продуктов в минимальные сроки с минимальными ресурсами. Более 90% разработчиков срывают даты поставки. Нарушение сроков носит регулярный характер для 67% разработчиков. Кроме того, в 91% случаев приходилось удалять в цикле разработки ключевую функциональность, чтобы уложиться в срок [1]. Компании вынуждены снижать свои расходы. Прежде всего, это можно сделать за счет автоматизации и модернизации бизнес-процессов с помощью программных ресурсов.

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

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

Рис. 1 Эффект от внедрения средств автоматического тестирования [4]

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

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

· Следует выбирать сценарии, которые легко автоматизировать. В качестве отрицательных примеров можно привести детальное сравнение содержимого документов или переустановку операционной системы.

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

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

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

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

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

Критерии выбора фреймворка для тестирования GlobalXB, GCube и Thistle определялись спецификой этих приложений. Следующие критерии были выделены как наиболее приоритетные:

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

2. Поддержка языка разработки VBScript. В связи с тем, что тестируемое приложение написано на на языке VB.Net, для обеспечения наиболее полной интеграции было принято решение о разработке автотестов на языке VBScript.

3. Интеграция с системами контроля версий. В компании существуют установившиеся процессы и стандарты работы с кодом. Для обеспечения качества приложений и управляемости версиями компания использует систему контроля версий от Microsoft Visual Studio Team Foundation Server. В связи с тем, что автотесты являются неотъемлемой частью программного кода приложения, и в целях обеспечения их качества и управляемости, данный критерий к средствам автоматизации был признан приоритетным.

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

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

Согласно выбранным критериям после проведения исследования рынка средств автоматизации HP Quality Center, Test Complete, Selenium, NUnit, Rational Robot и Silk Test максимально соответствующими были признаны два продукта: HP Quality Center от компании Hewlett Packard и Test Complete от компании Automated QA.

На окончательный выбор Test Complete в качестве инструмента автоматизации повлияло два фактора:

1. Продукт HP Quality Center приобретен компанией Hewlett Packard у Mercury Interactive в 2006 году и является всего лишь очередным расширением компании на новую сферу рынка. В то же время компания Automated QA специализируется исключительно на программном обеспечении для тестирования и активно поддерживает и развивает свои продукты.

2. Несмотря на высокую стоимость обоих продуктов, приобретение корпоративных лицензий Test Complete было признано более выгодным.



Глава 2. Методологии автоматического тестирования

2.1 Record-Runscript

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

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

В качестве примера рассмотрим задачу по генерации тысячи одинаковых документов через интерфейс тестируемого приложения (см. Приложение 1). Основа для скрипта была сгенерирована при помощи встроенной в фреймворк утилиты, после чего был добавлен метод Wait Win Forms Object, ожидающий появления нужного окна, и цикл.

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



2.2 Data-DrivenTesting

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

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

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

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

1. база данных (MySQL, Oracle). Для разработчика это наиболее удобный способ хранения тестовой информации, так как имеется возможность упорядоченного хранения и легкого взаимодействия с данными. Со стороны конечного пользователя, то есть тестера, могут возникнуть сложности при необходимости внесения изменений в тесты.

2. таблица данных (Excel). Также предоставляет возможности чтения и записи данных при помощи скрипта, но с некоторыми ограничениями.

2.3 Object-DrivenTesting

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

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

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

Вывод

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

Для автоматизации приложений Global XB, GCubeи Thistle был выведен следующий алгоритм планирования автоматических тестов:

1. Изучить тестируемое приложение

2. Проанализировать существующие ручные тесты

3. Выбрать наиболее подходящие для автоматизации тесты

4. Выбрать источник тестовых данных

5. Спланировать сценарий выполнения скрипта

6. Разделить приложение на логические объекты, которые будут описаны отдельными классами

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



Глава 3. Практическая реализация

3.1. Global XB

Описание приложения

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

Постановка задачи

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

Global XB предоставляет пользователю возможность генерировать различные отчеты, содержащие статистические данные о состоянии системы,например, о количестве действующих на данный момент страховых полисов или объеме платежей, проведенных за последнее время. Результат выводится в двух вариантах: в виде страницы HTML или в файл Excel. При создании отчета пользователь может задать некоторый набор параметров, влияющий на выводимые данные.

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

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



Решение

Алгоритм генерации отчета основан на клиент-серверной архитектуре. Клиент (тестируемое приложение) посылает параметризированный запрос, сервер обрабатываемого, запускает запрошенную хранимую процедуру и возвращает в ответ готовый отчет.

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

· Запустить приложение

· Открыть список отчетов

· Выбрать отчет

· Заполнить все необходимые поля

· Запустить генерацию отчета

· Дождаться результата

· Проверить полученные данные

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

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

Информация о доступных отчетах хранится в баз данных MySQL 2008. В приложении 4 приведен листинг кода, получающего данную информацию, обращаясь к базе при помощи интерфейса ADODB. Как упоминалось выше, для создания каждого отчета используется свой набор переменных. В зависимости от переменной выбирается тип поля, в которое она вводится (см. Приложение 3). Тип переменной определяется значением в таблице базы данных. Получив это значение можно сгруппировать поля и определить метод для работы с каждой группой. Пример работы с полями типа CustomEx приведен в приложении5.

Для покрытия большего количество случаев было реализовано два сценария создания отчета: со стандартными значениями и с заполнением всех полей случайными значениями. В приложении 6 приводится блок-схема полученного скрипта.

Результат выполнения теста определяется по ключевому элементу заголовка HTML страницы, присутствующему в каждом отчете, т.е. в случае, если сервер возвращает ошибку, заголовок отсутствует, и записывается в файл Excel в следующем формате:

Название отчета	Строка запроса со стандартными значениями	Результат	Строка запроса со случайными значениями	Результат

Анализ результата

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

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

На планирование и разработку скрипта понадобилось 20 часов. Среднее время выполнения скрипта на базе, содержащей 130 отчетов, составляет 4 часа. Запуск скрипта и анализ результатов тестирования занимает около 30 минут. На полное ручное тестирование отчетов в одной базе отводилось до 8 часов. Таким образом, расходы на разработку окупаются эффективностью полученного результата.

3.2 GCube

Обзор приложения

GCube - это веб приложение, разработанное для страховых компаний (см. Приложение 7) с использованием таких технологий, как технологии ASP.NET и MySQL. Используя его, пользователи, сотрудники страховой компании, могут создавать и тестировать новые страховые продукты. На основе стандартных продуктов можно создавать вариации - схемы, специфичные для групп уполномоченных посредников, агентов или клиентов. Можно создать образцы документов со специфичными логотипами и текстом, добавлять необходимые вопросы на страницы сайта и модифицировать схемы расчета премий. На каждом шаге этого процесса выбираются необходимые типы транзакций, и на основе этого выполняются необходимые операции (например, определение статуса переданных на рассмотрение предварительных договоров о страховании, расчет премий, определение необходимого набора документов и т.д.).

Постановка задачи

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

Данные были предоставлены в таблицах Excel, и менеджером проекта было принято решение о переносе данных посредством TestComplete. Создание страховых договоров через пользовательский интерфейс гарантировало полноту и непротиворечивость вводимых данных структуре базы данных новой системы автоматизации страхования. Также созданные для переноса данных скрипты планировалось использовать для автоматизации регрессионного тестирования.

Перед автором была поставлена задача через интерфейс приложения занести в базу данных приложения около 1200 объектов страхования в 5 различных схемах.Также было предъявлено два обязательных требования к скрипту:

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

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

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

Решение

В первую очередь необходимо было считать данные из файла Excel. Эта функциональность была реализована при помощи интерфейсаADODB. Приведенный в приложении 8 код получает данные в зависимости от передаваемого запроса и формирует из них объект типа Scripting.Dictionary, использующийся в дальшейшем в работе скрипта.

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

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

Следующим пунктом необходимо было решить, каким образом обращаться к элементам страницы. Созданная средствами ASP.Net страница генерируется динамически, что практически исключает возможность обращаться к ее элементами по имени, так как зачастую оно имеед вид типа «ctl00_ctl00_cphBody_QuoteInnards_ctl09_rpt_ctl00_popupSubQuestions_ClaimssPanel_tcTabledData_gdvTabbledData_ctl02_rptSubQuestions_ctl00_QuestionAnswerString_I». После изучения структуры страниц и обсуждения проблемы с разработчиками было принято решение внести незначительное изменение в код приложения, а именно: добавить рядом с каждым полем объект типа Span нулевого размера, однако имеющий название, уникальное на странице.

Таким образом, целевое поле определяется в два этапа: сначала производится поиск соответствующего ему объекта типа Span, затем на основе ID объекта получается имя искомого поля.

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

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

Анализ результата

Полученный в результате работы скрипт успешно справился с поставленной задачей. Миграция данных была проведена в срок и без ошибок. После стабилизации логики скрипта добавление одного страхового объекта занимало около 7 минут. Запущенные одновременно на трех платформах тесты выполнялись на протяжении двух суток, данные о ходе выполнения снимались каждые 12 часов.

На рисунке 1 можно видеть, что выделение дополнительных двадцати часов на стабилизацию скрипта позволило сократить время миграции примерно на 220 часов, не смотря на то, что время выполнения скрипта увеличилось при этом с 80 до 140 часов.

Рис. 2. График зависимости времени выполнения скрипта и времени, затраченного на миграцию, от времени, затраченного на стабилизацию

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

3.3 Thistle

Обзор приложения

Как и GCube, Thistle - это веб-приложение, разработанное для страховых компаний. Однако, будучи схожими по направленности, они различаются по реализации. Основная функциональность Thistle заключается в расчете платежей по страховым объектам.

Постановка задачи

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

Перед автором была поставлена задача путем автоматизации тестирования минимизировать затраты ресурсов на проведение регрессионного тестирования. В первую очередь необходимо было автоматизировать проверку системы расчетов. К результату предъявлялись следующие требования:

· Покрытие всех имеющихся на данный момент схем

· Возможность с наименьшими затратами расширять скрипт под новые схемы

· Независимость тестера от разработчика

Решение

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

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

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

Было установлено, что каждое поле содержится в контейнере определенной структуры:

Контейнер Иконка (опционально) Название поля Поле типа Input Дополнительные данные (опционально)

Рис. 3 Элементы, составляющие один контейнер поля

Название поля всегда присутствует в контейнере, так как оно служит для навигации пользователя по сайту.При этом имя всех элементов в группе составляется из имени контейнера, порядкового номера элемента в контейнере и типа элемента.

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

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

В результате все необходимые для работы скрипта поля покрываются всего лишь двумя функциями: GetByLabel и GetBy Name, листинг которых приведен в приложении 11.

Анализ результата

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

В настоящий момент покрытие кода автоматическими тестами для данного проекта составляет около 10%. Ведутся работы по добавлению новых тестов, что расширит покрытие ориентировочно до 20-25%. Также ведется расширение скрипта на дополнительный функционал. Примерная оценка покрытия кода в результате этих работ составляет 50-60%.



Заключение

В рамках этой работы решены следующие задачи:

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

· Изучена специфика работы с локальными и веб-приложениями и найден эффективный подход к автоматизации их тестирования;

· Исходя из требований проекта выбран инструмент разработки скриптов. Таковым инструментом является продукт компании AutomatedQATestComplete;

· Спланирован и разработан набор автоматических тестов для приложений GlobalXB, GCube и Thistle.

В рамках диипломного проекта было разработано 3 пакета автоматических тестов, покрывающих более 3000 тестовых случаев. В настоящее время все разработки активно применяются в процессе регрессионного тестирования с положительным результатом.

Сокращение затрат на тестирование соствило:

· по проекту GlobalXB в рассматриваемом модуле - 25%;

· по проекту GCube 20%

· по проекту Thistle более 30%



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

1. ЭлфридДастин, ДжеффРэшка, Джон Пол \ Е. Молодцова, М. Павлов. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. // Москва, Издательство «ЛОРИ», 2003

2. Mark Fewster, Dorothy Graham. Software Test Automation. Effective use of test execution tools. // New York, ACM Press, 1999

3. И. Винниченко. Автоматизация процессов тестирования.// СПб, «Питер», 2005

4. В. Полевой. Как автоматизировать тестирование ПО? // Cnews, 2007.

5. В.П. Котляров, Т.В. Коликова. Основы тестирования программного обеспечения. // СПб, Бином. Лаборатория знаний, 2006.

6. Борис Бейзер. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем. // СПб: Питер, 2004.

7. Геннадий Алпаев. Учебник по Test Complete. http://tctutorial.ru/

8. Панкратов Вячеслав. Разработка критериев анализа систем автоматизации тестирования. http://www.it4business.ru/



Приложение 1

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

Sub add1000docs

For i = 1 To 1000

Set PremiumProperties =

Aliases.Global.WaitWinFormsObject("PremiumProperties", 100000)

PremiumProperties.WinFormsObject("btnProduceDocs").ClickButton

Set produceDocs = Aliases.Global.ProduceDocs

Call produceDocs.WinFormsObject("grdList").Click(15, 111)

produceDocs.WinFormsObject("btnOK").ClickButton

Next

EndSub



Приложение 2

Интерфейс приложения Global XB



Приложение 3

Интерфейс формы генерации отчета



Приложение 4

Функции, считывающие информацию об отчетах, содержащихся в базе данных.

PublicFunctionGetReports

Set Reports = CreateObject("Scripting.Dictionary")

SetobjRecordset = CreateObject("ADODB.Recordset")

SetobjRecordset = DBConn.Execute("Select ReportID, ReportName, ReportFileForExport From ["&Database&"].dbo.toReports Where StoredProcedureName != 'NULL'")

i = 1

DoWhileNotobjRecordset.EOF

SetnewReport = new Report

newReport.rNumber = i

newReport.rID = objRecordset.Fields(0).Value

newReport.rName = objRecordset.Fields(1).Value

newReport.rExportFile = objRecordset.Fields(2).Value

Reports.AddReports.Count, GetFilters (newReport)

objRecordset.moveNext

i = i + 1

Loop

SetGetReports = Reports

objRecordset.Close

SetobjRecordset = Nothing

EndFunction

PublicFunctionGetFilters (report)

Set Filters = CreateObject("Scripting.Dictionary")

SetobjRecordset = CreateObject("ADODB.Recordset")

SetobjRecordset = DBConn.Execute("Select ReportFilterID, FilterType, FilterKey, FilterName From ["&Database&"].dbo.toReportFilters Where Visible = 1 and ReportID = "&report.rID)

DoWhileNotobjRecordset.EOF

SetnewFilter = newrFilter

newFilter.fID = objRecordset.Fields(0).Value

newFilter.fType = objRecordset.Fields(1).Value

newFilter.fKey = objRecordset.Fields(2).Value

newFilter.fName = objRecordset.Fields(3).Value

report.rFilters.Addreport.rFilters.Count, newFilter

objRecordset.moveNext

Loop

SetGetFilters = report

objRecordset.Close

SetobjRecordset = Nothing

EndFunction



Приложение 5

Часть метода, заполняющего поле типа CustomEx

SubFilterFillTest(report, filterCollection, check)

foreachfilterIteminreport.rFilters.Items

Sleep (1000)

filterItemName = filterItem.getName

iffilterItem.fType = "CustomEx"orfilterItem.fType = "Custom"then

for i = 0 tofilterCollection.ChildCount - 1

setfilterBox =

filterCollection.Child(i).WinFormsObject("pnlMain").Child("1")

iffilterBox.get_Name = filterItemNamethen

setcheckBox =

filterCollection.Child(i).WinFormsObject("pnlMain").Child("0")

ifcheckBox.Checked = falseand check = truethen

checkBox.Checked = true

endif

ifcheckBox.Checked = truethen

callreport.fillCustomEx(i, filterItemName)

Log.Message(filterItem.fName&" filter filled")

endif

endif

next

endif

End Sub

SubfillCustomEx (i, filterName)

Sys.Process("TOGlobalPolicy").ReportWizard.WinFormsObject("pnlMain")

.pnlFilters.pnlFilterCollection.Child(i).WinFormsObject("pnlMain").WinFor

msObject(filterName).WinFormsObject("btnSelect").ClickButton

Sleep (1000)

ifSys.Process("TOGlobalPolicy").WaitWinFormsObject("RefBookForm",

2000).Exists then

Log.Message("RefBookForm found")

Sys.Process("TOGlobalPolicy").WinFormsObject("RefBookForm").WinFor

msObject("grdRef").Keys("[Down][Enter]")

elseifSys.Process("TOGlobalPolicy").WaitWinFormsObject("AccountsList",

1000).Exists then

Log.Message("AccountsList found")

CallSys.Process("TOGlobalPolicy").WinFormsObject("AccountsList").Win

FormsObject("tabLists").WinFormsObject("tpClient").WinFormsObject("gr

dClients").Keys("[Down][Enter]")

Elseif

Sys.Process("TOGlobalPolicy").WaitWinFormsObject("RiskObjectsList",

1000).Exists then

Log.Message("RiskObjectsList found")

Sys.Process("TOGlobalPolicy").WinFormsObject("RiskObjectsList").WinF

ormsObject("grdList").Keys("[Down][Enter]")

endif

End Sub



Приложение 6

Блок-схема автоматического теста по генерации отчетов в Global XB

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Блок-схема процесса заполнения полей отчета

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/



Приложение 7

Интерфейс сайта Gcube



Приложение 8

Класс для чтения данных их файла в формате Excel

ClassExcelData

PublicRows()

Public Connection

PublicSheetName

PublicTableName

PublicFileName

PublicSubInitDataADODB(FileName, SheetName, TableName, SQLStr)

Me.FileName = FileName

Me.SheetName = SheetName

ConnectString = "Provider=Microsoft.ACE.OLEDB.12.0;"& _

"Data Source="&chr(34) &FileName&chr(34) &";"& _

"Extended Properties=""Excel 12.0;HDR=Yes;IMEX=1"";"

Set Conn = CreateObject("ADODB.Connection")

Conn.OpenConnectString

Set Rec = Conn.Execute(SQLStr)

DowhileNotRec.EOF

IfIsObject(Rows(0)) Then

RedimPreserveRows(UBound(Rows)+1)

EndIf

SetRows(UBound(Rows)) = CreateObject("Scripting.Dictionary")

For i = 0 to Rec.Fields.Count-1

IfisNull(Rec.Fields(i).Value) Then

val = ""

Else

val = CStr(Rec.Fields(i).Value)

EndIf

Rows(UBound(Rows)).add Rec.Fields(i).Name, val

Next

j = j+1

Rec.MoveNext

Loop

Conn.Close

EndSub

SubClass_Initialize

RedimRows(0)

EndSub

EndClass



Приложение 9

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

Class Fill

Sub InputStd(abbrLabel, str)

Sub InputDate(abbrLabel, str)

Sub InputRadio(abbrLabel, bool)

Ifbool = "" Then Exit Sub

GetInputRadio(abbrLabel, bool).Click

End Sub

Sub InputRadioOther(abbrLabel, bool)

Sub SelectStd(abbrLabel, str)

Property Get GetAbbriviationID(abbrLabel)

Set Abbriviation =

Page.SPAN.WaitChild("Item("&Chr(34)&abbrLabel&Chr(34)&")", 10000)

IfIsEmpty(Abbriviation) Then Log.Error("Script couldn't find abbriviation

object "&abbrLabel)

GetAbbriviationID = Abbriviation.ID

End Property

Property Get GetInputStd(abbrLabel)

Property Get GetInputDate(abbrLabel)

Property Get GetInputRadio(abbrLabel, bool)

IfStrComp(Trim(bool), "Yes",1) = 0 Then _

ID = GetAbbriviationID(abbrLabel) + 3

IfStrComp(Trim(bool), "No",1) = 0 Then _

ID = GetAbbriviationID(abbrLabel) + 5

Fori = 0to100

SetField = Page.INPUT.FindId(ID)

Sleep(100)

IfField.ExistsThen

SetGetInputRadio = Page.INPUT.FindId(ID)

Exit For

End If

Next

End Property

Property Get GetInputRadioOther(abbrLabel, bool)

Property Get GetSelectStd(abbrLabel)

EndClass



Приложение10

Интерфейс сайта Thistle



Приложение11

Функции для поиска объекта на странице

FunctionGetByLabel(pType, pLabel, cType, cPref, cSuff)

tmpStr = ""

ctlNumber = ""

SetobjMatches = Nothing

SetGetByLabel = Nothing

Set re = newRegExp

re.Pattern = "ctl\d{2}"

re.Global = True

For i = 0 to 3

SettmpParent = Page.WaitChild(pType, 1000).FindChild("innerText",

pLabel)

IftmpParent.ExistsThen

SetobjMatches = re.Execute(tmpParent.Name)

ExitFor

EndIf

Page.Refresh

Next

If (objMatchesIsNothing) ThenExitFunction

For i = 0 to objMatches.Count-2

tmpStr = tmpstr&objMatches.Item(i).Value &"*"

Next

ctlNumber = objMatches.Item(objMatches.Count-1).Value

For i = 0 to 10

SettmpObject = Page.WaitChild(cType, 10000).FindChild("idStr",

tmpstr&cPref&ctlNumber&cSuff)

IftmpObject.ExistsThen

SetGetByLabel = tmpObject

ExitFor

EndIf

Sleep (500)

Page.Refresh

Next

EndFunction

FunctionGetByProperty(pType, prop, name)

For i = 0 to 3

SettmpParent = Page.WaitChild(pType, 1000)

IftmpParent.ExistsThen

SettmpChild = tmpParent.FindChild(prop, name)

IftmpChild.ExistsThen

SetGetByProperty = tmpChild

ExitFor

ElseSetGetByProperty = Nothing

EndIf

ElseSetGetByProperty = Nothing

EndIf

Page.Refresh

Next

If (GetByPropertyIsNothing) ThenLog.Warning ("Object not found. Prop: "&prop&". Name: "&name)

EndFunction

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