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

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

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

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

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

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

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

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

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

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

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

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

·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 Record-Run script

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

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

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

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

2.2 Data-Driven Testing

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

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

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

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

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

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

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

2.3 Object-Driven Testing

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

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

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

2.4 Вывод

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

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

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

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

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

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

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

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

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

3.1 Global XB

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

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

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

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

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 метод поиска объектов на странице, так как для этого необходимо было внести изменения в код, что в данном случае противоречило требованиям заказчика. Был проведен анализ структуры сайта и разработан новый подход, позволяющий не только быстрее выделять нужное поле, но и упрощающий логику кода.

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

· Исходя из требований проектов выбран оптимальный инструмент разработки скриптов — продукт компании AutomatedQA TestComplete;

· Разработан план обеспечения качества для продуктов Global XB, GCube и Thistle. В соответствии с планом был реализован набор автоматических тестов для вышеуказанных приложений.

В ходе работ над дипломным проектом было создано 3 пакета автоматических тестов, реализующих более 3000 тестовых случаев. В настоящее время все полученные результаты активно применяются в процессе разработки и поддержки вышеуказанных продуктов. С помощью данных тестов было найдено более 500 дефектов, вследствие чего значение метрики «Количество дефектов, найденных клиентами в релизе» сократилось на 42%.

Эффектом от внедрения данных методик стало сокращение затрат на тестирование:

· по проекту Global XB в рассматриваемом модуле — 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. Геннадий Алпаев. Учебник по TestComplete. http://tctutorial.ru/

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

Приложение 1

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

Sub add1000docs

For i = 1 To 1000

Set PremiumProperties = Aliases.Global.WaitWinFormsObject («PremiumProperties», 100 000)

PremiumProperties.WinFormsObject («btnProduceDocs»).ClickButton

Set produceDocs = Aliases.Global.ProduceDocs

Call produceDocs. WinFormsObject («grdList»).Click (15, 111)

produceDocs.WinFormsObject («btnOK»).ClickButton

Next

End Sub

Приложение 2

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

Приложение 3

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

Приложение 4

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

Public Function GetReports

Set Reports = CreateObject («Scripting.Dictionary»)

Set objRecordset = CreateObject («ADODB.Recordset»)

Set objRecordset = DBConn.Execute(«Select ReportID, ReportName, ReportFileForExport From [» &Database&" ]. dbo. toReports Where StoredProcedureName ≠ 'NULL'")

i = 1

Do While Not objRecordset. EOF

Set newReport = new Report

newReport.rNumber = i

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

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

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

Reports.Add Reports. Count, GetFilters (newReport)

objRecordset.moveNext

i = i + 1

Loop

Set GetReports = Reports

objRecordset.Close

Set objRecordset = Nothing

End Function

Public Function GetFilters (report)

Set Filters = CreateObject («Scripting.Dictionary»)

Set objRecordset = CreateObject («ADODB.Recordset»)

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

Do While Not objRecordset. EOF

Set newFilter = new rFilter

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.Add report.rFilters.Count, newFilter

objRecordset.moveNext

Loop

Set GetFilters = report

objRecordset.Close

Set objRecordset = Nothing

End Function

Приложение 5

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

Sub FilterFillTest (report, filterCollection, check)

for each filterItem in report.rFilters.Items

Sleep (1000)

filterItemName = filterItem. getName

if filterItem. fType = «CustomEx» or filterItem. fType = «Custom» then

for i = 0 to filterCollection. ChildCount — 1

set filterBox = filterCollection. Child (i).WinFormsObject («pnlMain»).Child («1»)

if filterBox. get_Name = filterItemName then

set checkBox = filterCollection. Child (i).WinFormsObject («pnlMain»).Child («0»)

if checkBox. Checked = false and check = true then

checkBox.Checked = true

end if

if checkBox. Checked = true then

call report. fillCustomEx (i, filterItemName)

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

end if

end if

next

end if

End Sub

Sub fillCustomEx (i, filterName)

Sys.Process («TOGlobalPolicy»).ReportWizard.WinFormsObject («pnlMain»).pnlFilters.pnlFilterCollection.Child (i).WinFormsObject («pnlMain»).WinFormsObject (filterName).WinFormsObject («btnSelect»).ClickButton

Sleep (1000)

if Sys.Process («TOGlobalPolicy»).WaitWinFormsObject («RefBookForm», 2000).Exists then

Log.Message («RefBookForm found»)

Sys.Process («TOGlobalPolicy»).WinFormsObject («RefBookForm»).WinFormsObject («grdRef»).Keys («[Down][Enter]»)

elseif Sys.Process («TOGlobalPolicy»).WaitWinFormsObject («AccountsList», 1000).Exists then

Log.Message («AccountsList found»)

Call Sys.Process («TOGlobalPolicy»).WinFormsObject («AccountsList»).WinFormsObject («tabLists»).WinFormsObject («tpClient»).WinFormsObject («grdClients»).Keys («[Down][Enter]»)

Elseif

Sys.Process («TOGlobalPolicy»).WaitWinFormsObject («RiskObjectsList», 1000).Exists then

Log.Message («RiskObjectsList found») Sys.Process («TOGlobalPolicy»).WinFormsObject («RiskObjectsList»).WinFormsObject («grdList»).Keys («[Down][Enter]»)

end if

End Sub

Приложение 6

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

Приложение 7

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

Приложение 8

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

Class ExcelData

Public Rows ()

Public Connection

Public SheetName

Public TableName

Public FileName

Public Sub InitDataADODB (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.Open ConnectString

Set Rec = Conn.Execute(SQLStr)

Do while Not Rec. EOF

If IsObject (Rows (0)) Then

Redim Preserve Rows (UBound(Rows)+1)

End If

Set Rows (UBound(Rows)) = CreateObject («Scripting.Dictionary»)

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

If isNull (Rec.Fields (i).Value) Then

val = «»

Else

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

End If

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

Next

j = j+1

Rec.MoveNext

Loop

Conn.Close

End Sub

Sub Class_Initialize

Redim Rows (0)

End Sub

End Class

Приложение 9

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

Class Fill

Sub InputStd (abbrLabel, str)

Sub InputDate (abbrLabel, str)

Sub InputRadio (abbrLabel, bool)

If bool = «» 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)&")", 10 000)

If IsEmpty (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)

If StrComp (Trim (bool), «Yes», 1) = 0 Then _

ID = GetAbbriviationID (abbrLabel) + 3

If StrComp (Trim (bool), «No», 1) = 0 Then _

ID = GetAbbriviationID (abbrLabel) + 5

For i = 0 to 100

Set Field = Page.INPUT.FindId (ID)

Sleep (100)

If Field. Exists Then

Set GetInputRadio = Page.INPUT.FindId (ID)

Exit For

End If

Next

End Property

Property Get GetInputRadioOther (abbrLabel, bool)

Property Get GetSelectStd (abbrLabel)

End Class

Приложение 10

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

Приложение 11

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

Function GetByLabel (pType, pLabel, cType, cPref, cSuff)

tmpStr = «»

ctlNumber = «»

Set objMatches = Nothing

Set GetByLabel = Nothing

Set re = new RegExp

re.Pattern = «ctld{2}»

re.Global = True

For i = 0 to 3

Set tmpParent = Page. WaitChild (pType, 1000).FindChild («innerText», pLabel)

If tmpParent. Exists Then

Set objMatches = re.Execute(tmpParent.Name)

Exit For

End If

Page.Refresh

Next

If (objMatches Is Nothing) Then Exit Function

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

Set tmpObject = Page. WaitChild (cType, 10 000).FindChild («idStr», tmpstr & cPref & ctlNumber & cSuff)

If tmpObject. Exists Then

Set GetByLabel = tmpObject

Exit For

End If

Sleep (500)

Page.Refresh

Next

End Function

Function GetByProperty (pType, prop, name)

For i = 0 to 3

Set tmpParent = Page. WaitChild (pType, 1000)

If tmpParent. Exists Then

Set tmpChild = tmpParent. FindChild (prop, name)

If tmpChild. Exists Then

Set GetByProperty = tmpChild

Exit For

Else Set GetByProperty = Nothing

End If

Else Set GetByProperty = Nothing

End If

Page.Refresh

Next

If (GetByProperty Is Nothing) Then Log.Warning («Object not found. Prop: «&prop&». Name: «&name)

End Function