Оглавление

Введение ........................................................................................................................ 3
Глава 1. Теоретические и технологические основы тестирования программного
обеспечения................................................................................................................... 5
Обзор литературы ..................................................................................................... 5

Теоретические основы автоматизации тестирования ........................................... 8

Обзор основных функций Sikuli ............................................................................ 17

Глава 2. Технологии и программное обеспечение тестирования ПО................... 25

1. Создание билдагента. ......................................................................................... 27

2. Установка и настройка необходимого программного обеспечения. ............. 28

3. Разработка автоматических тестов. .................................................................. 31

4. Настройка билд-сервера Teamcity. .................................................................... 51

5. Отправка разработанных автоматических тестов на сервер с помощью

Perforce. .................................................................................................................... 63

6. Запуск автоматических тестов и анализ полученных результатов................ 64

Заключение ................................................................................................................. 67
Список используемых источников ........................................................................... 68
Приложение 1 ............................................................................................................. 74

2
 Введение
На современном этапе развития информационных технологий стоит вопрос
автоматизации рабочих процессов. Тестирование является важным этапом
разработки программного обеспечения. Чем позже начато тестирование, тем
выше риски, и тем менее надежной она может получиться. Так же ошибки,
найденные до выпуска программного обеспечения, обходятся компании гораздо
дешевле, чем ошибки, выявленные пользователями в процессе эксплуатации.
Именно поэтому для любой компании очень важно, чтобы тестировщики
своевременно находили ошибки в программном обеспечении. Как правило,
процесс тестирования – очень трудоемкий, так как при появлении новой
функциональности в систему, тестировщику необходимо проверить сначала эту
функциональность, при этом обычно производится как позитивное, так и
негативное тестирование. То есть проверяется работоспособность системы при
правильном и неправильном обращении с ней пользователя. После проверки
новой функциональности тестировщику необходимо провести регрессионное
тестирование (проверить корректность работы старой функциональности).
Тестирование программного обеспечения позволяет вовремя выявить
ошибки в программном обеспечении, которые могут привести к краже данных
или к потере их целостности.
У автоматизации тестирования есть ряд преимуществ. Во-первых,
повышение производительности труда. Во время выполнения автоматических
тестов инженер-тестировщик может заниматься другими задачами. Часто
лучше, чтобы тесты выполнялись в нерабочее время, т.к. нагрузка на локальные
сети ночью снижена. Во-вторых, минимизация человеческого фактора,
повышение надежности. В отличие от компьютера, работоспособность человека
зависит от многих факторов: эмоционального состояния, психического
состояния и т.д. Тестирование иногда бывает рутинным и однообразным,
поэтому человек становится более невнимательным. В-третьих, удешевление
3
процессов (более эффективное использование ресурсов). Т.е. когда
автоматические тесты уже написаны, на их поддержку и анализ требуется
меньше времени, чем на тестирование вручную.
Во многих предприятиях, разрабатывающих программное обеспечение,
есть отдел тестирования. Чем больше предприятии и чем больше у него
проектов, тем больше штат отдела тестирования. Исследованиями в области
автоматизации тестирования занимаются как штатные сотрудники на
предприятиях (Яндекс, Google и другие крупные предприятия), так и в
Технологических Институтах (особенно усиленно изучается автоматизирование
тестирования в Массачусетском Технологическом Институте).
В связи с вышеизложенным мною была поставлена цель разработать
методологию и систему автоматизации контроля отсутствия ошибок в
программном обеспечении.
Для достижения цели в дипломной работе необходимо решить следующие
задачи:
 проанализировать теоретические основы автоматизации тестирования
программного обеспечения;
 рассмотреть виды автоматизации тестирования контроля целостности и
доступности и существующие системы автоматизации тестирования;
 рассмотреть программное обеспечение, которое будет использоваться для
разработки системы автоматизации тестирования;
 разработать методологию по организации автоматизации тестирования
программного обеспечения;
 разработать систему автоматизации контроля отсутствия ошибок в
программном обеспечении;
 проверить работу системы автоматизации контроля отсутствия ошибок в
программном обеспечении на примере Ocean for Petrel.

4
 Глава 1. Теоретические и технологические основы тестирования
программного обеспечения.

Обзор литературы

В первой главе дипломной работы мною рассмотрены основы

тестирования и автоматизации тестирования. Используя статьи «Управление
Качеством ПО» [1], «Автоматизированное функциональное тестирование» [6] и
другие источники [2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15] я описала основы
тестирования и автоматизации тестирования, с чего и как начать
автоматизацию, и в каких случаях она целесообразна. Так же подробно
сравнила преимущества и недостатки ручного и автоматического тестирования,
описала разные уровни тестирования программного обеспечения, их
достоинства, провела сравнение нескольких инструментов автоматизации.
Одним из рассмотренных мной инструментов автоматизации
тестирования был Sikuli Script. Изучив книги, статьи и некоторые научные
работы: «Instant Sikuli Test Automation» [16], «Sikuli Script» [19], статьях «Sikuli
/ SikuliX Documentation for version 1.1+» [17], «Automation Testing with Sikuli
Script» [22] и других источниках [18, 20, 21, 23, 24, 25, 26] я описала основные
возможности инструмента автоматизации. Также подробно описала основные
функции языка Sikuli Script, привела примеры использования, описала
некоторые особенности автоматизации тестирования через Sikuli Script.
Pywinauto был разработан, как стандартный инструмент автоматизации
тестирования для языка программирования Python. С его помощью можно
автоматизировать тестирование программного обеспечения. Так как плагин
бесплатен и является стандартным, существует много статей и книг о работе
данного инструмента. Работа pywinauto подробно описана в статьях [30, 31, 32],
так же приведены его достоинства и недостатки и пример простого приложения
с использованием данного плагина.

5
 LDTP – это еще один инструмент автоматизации тестирования. Он
использует технология помощи использования программного обеспечения для
ограниченных людей. Документация к программе ldtp описана в источниках [27,
28, 29]. Документация написана на английском языке и содержит
специализированную терминологию. Тем не менее, работа программы описано
подробно, приведены примеры использования.
В главе 1 данной дипломной работы я сравнила 4 инструмента
автоматизации тестирования (pywinauto, LDTP, Robot Framework, AutoIt),
разработав один и тот же автоматический тест на каждом из инструментов. Для
описания инструментов автоматизирования тестирования и написания тестов с
помощью этих инструментов были использованы источники [33, 34, 35, 36, 37,
38, 39, 40, 41].
В рассмотренных мной инструментах автоматизации используется
высокоуровневый язык программирования Python для разработки скриптов
автоматических тестов. Таким образом, пользуясь статьями и
исследовательскими работами [42, 43, 44, 45, 46], я изучила язык
программирования Python.
Непрерывная интеграция – необходимый процесс при разработке
программного обеспечения, особенно когда над проектом работает целая
команда разработчиков. Таким образом, было необходимостью изучить
материалы по непрерывной интеграции разработки программного обеспечения.
В этом мне помогли статьи на Wikipedia «Teamcity» [50], «Непрерывная
интеграция» [55] и другие источники [49, 51, 52, 53, 54, 56, 60, 61]. Так же о
достоинствах непрерывной интеграции и интеграции именно в Teamcity
рассказано в статье «Continuous Integration для чайников вместе с Teamcity»
[13].
Совместно с непрерывной интеграцией обычно используют системы
контроля версий. Для того, чтобы выбрать систему контроля версий,
6
необходимо было рассмотреть несколько подходящих вариантов. Используя
статьи «Обзор систем контроля версий» [57] и «Система управления версиями»
[58], в которых описаны многие современные системы контроля версий, их
достоинства и недостатки, а также произведено сравнение самый популярных
систем контроля версий, я выбрала систему контроля версий Perforce.
После того, как я определилась с используемой системой контроля
версий, нужно изучить особенности программы и основные функции. В статье
на Wikipedia под названием «Perforce» [59] можно получить достаточно полную
информацию о данной системе контроля версий.
Одной из потребовавшихся в разработке системы автоматизации
тестирования программой стала VMWare. Для запуска автоматических тестов
на сервере, а не на собственном локальном компьютере, необходимо
программное обеспечение виртуализации для создания виртуальных машин,
используемых для тестирования. Для настройки программы и создания
виртуальных машин я пользовалась статьями [47, 48].

7
 Теоретические основы автоматизации тестирования

Каждый разрабатываемый программный продукт обладает набором

свойств, по которым определяют, насколько продукт «хорош». Оценивают его
заказчики, разработчики, тестировщики, конечные пользователи, инженеры
поддержки, сотрудники отдела маркетинга и т.д. Таким образом, обеспечение
качества продукта выливается в задачу выявления заинтересованных лиц, их
критериев и нахождение оптимального решения, удовлетворяющего этим
критериям. Тестирование – устоявшийся способ обеспечения качества
разработки программного обеспечения [2]. Тестирование – проверка
соответствия поведения программы между реальным и ожидаемым,
выполняемая на наборе тестов [3]. Тестирование включает в себя планирование
работ (Test Management), создание тестов (Test Design), выполнению тестов
(Test Execution) и отчет по полученным результатам (Test Analysis) [4, 5].
Автоматизированное тестирование – часть процесса тестирования. Он
включает в себя выполнение тестов и отчет по полученным результатам.
Итак, плюсы автоматизации тестирования[1]:
 Повторяемость тестов – тесты будут выполняться однообразно, таким
образом, исключен человеческий фактор.
 Быстрое выполнение – на автоматические тесты уйдет меньше времени,
чем на эти же тесты, выполненные вручную. Так же тесты могут
проходить ночью, когда нагрузка на локальную сеть меньше, чем днем.
 Меньшие затраты на поддержку – когда автоматические тесты уже
написаны, на их поддержку и выполнение затрачивается гораздо меньше
времени и денег, чем на ежедневное выполнение тестов вручную.
 Автоматические отчеты – после выполнения тестов автоматические
отчеты составляются и сохраняются.

8
  Повышение производительности сотрудников – вместо выполнения
каждый день тестов вручную инженер-тестировщик может просто
проанализировать автоматический отчет и выполнять другую работу.
Но у автоматического тестирования есть и некоторые минусы[1]:
 Повторяемость тестов является как плюсом автоматического
тестирования, так и недостатком. Все тесты выполняются однообразно.
Выполняя тестирование вручную, тестировщик может обратить
внимание на некоторые детали, которые автоматический тест не
заметил.
 Затраты на поддержку. Затраты меньше, чем на ручное тестирование
того же функционала, но, тем не менее, они есть.
 Затраты на разработку автоматических тестов. К этому пункту
относятся: потраченное время сотрудников на написание скриптов и
отладку тестов, стоимость лицензионного программного обеспечения,
потраченное время на установку и настройку программного
обеспечения.
Из вышеперечисленного можно сказать, что автоматизирование
тестирования является достаточно эффективным решением для предприятий,
разрабатывающие программное обеспечение. Чтобы убедиться в этом, сравним
ручной и автоматизированный подходы к контролю отсутствия ошибок [7].
Критерий Ручное Автоматическое
Задание входных Гибкость в задании Входные значения
значений данных. Позволяет строго заданы
использовать разные
значения на разных
циклах запуска тестов,
расширяя покрытие

9
Проверка результата Гибкая, позволяет Строгая. Нечетко
тестировщику сформулированные
оценивать нечетко критерии могут быть
сформулированные проверены только
критерии путем сравнения с
эталоном
Повторяемость Низкая. Человеческий Высокая
фактор и нечеткое
определение данных
приводят к не
повторяемости
тестирования
Надежность Низкая. Длительные Высокая, не зависит от
тестовые циклы длины тестового цикла
приводят к снижению
внимания
тестировщика
Чувствительность к Зависит от детальности Высокая.
незначительным описания процедуры. Незначительные
изменениям в продукте Обычно тестировщик в изменения в
состоянии выполнить интерфейсе часто ведут
тест, если внешний вид к коррекции эталонов
продукта и текст
сообщений несколько
изменились
Скорость выполнения Низкая Высокая
Возможность Отсутствует. Низкая Поддерживается

10
 генерации тестов скорость выполнения
обычно не позволяет
исполнить
сгенерированный
набор тестов
Таблица 1. Сравнение ручного и автоматизированного тестирования

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

нужно ответить на вопрос «Целесообразна ли автоматизация тестирования в
условиях проекта». Если ответ «Да», то необходимо создать план разработки
автоматических тестов, исходя из требований к объекту тестирования. План
разработки автоматических тестов является документом, в котором описано,
что автоматизировать, как и чем. Перечислим основные места, где нужно
применять автоматизацию [12, 13, 14]:
1. труднодоступные места (запись в базу данных, проверка лог-файлов);
2. часто используемые функции, где вероятность ошибок высока (таким
образом, автоматизация гарантирует быстрое нахождение ошибок, а
соответственно и их решение);
3. рутинные операции (например, формы с большим количеством полей);
4. валидационные сообщения;
5. проверка правильности сложных математических расчетов;
6. проверка правильного поиска данных;
7. и другие в зависимости от тестируемого программного обеспечения.
Для эффективной автоматизации тестирования рекомендуется разработать
тест-кейсы проверяющие:
 базовые операции – создания/изменения/удаления/чтения данных;
 типовые сценарии – совокупность типовых операций, выполняемых в данном
программном продукте;

11
 работа с файлами, которые неудобно тестировать вручную – проверка наличия
определенных разделов и фраз в документации;
Это и есть основные функциональности, от автоматизации которых
будет наибольшая отдача.
Тестируемое приложение можно разделить на три уровня:
 уровень модульного тестирования – создание модульных тестов,
проверяющих код приложения [8];
 уровень функционального тестирования – тестирование бизнес-логики
приложения в функциональном слое, минуя пользовательский интерфейс [6];
 уровень тестирования через пользовательский интерфейс дает возможность
тестировать не только интерфейс, но и функциональность, вызывая бизнес-
логику.
Рекомендуется использовать автоматизацию всех трех уровней для
наилучшего качества продукта.
Модульное тестирование сложно тем, что чтобы написать такие тесты,
нужно разбираться в чужом программном коде, что бывает крайне сложно [9].
При функциональном тестировании часто упускаются логические ошибки в
программном обеспечении [10]. Тестирование через пользовательский
интерфейс эмулирует действия пользователя, тестируя тем самым
работоспособность программного обеспечения, его функциональность и бизнес-
логику, поэтому рассмотрим подробнее тестирование через пользовательский
интерфейс [11].
Перейдем к выбору программного обеспечения. Есть три фактора, которые
стоит учитывать при выборе программного обеспечения для автоматизации
контроля отсутствия ошибок:

12
 Проверить распознавание элементов инструментом для автоматизации. Чем
больше элементов может распознавать инструмент, тем больше времени на
написании и исправлении скриптов вы сэкономите.
 Проверить, сколько времени понадобится на поддержку скриптов.
Графические элементы часто меняются. Для проверки нужно написать первый
простой тест с помощью выбранного инструмента, а потом представить, что
графический интерфейс программы тестируемой программы немного изменился.
Если для того, чтобы тест заработал, придется полностью его переписать, то
лучше подобрать другой инструмент для автоматизации.
 Оценить, насколько удобна среда для разработки автоматических тестов,
читаем ли код и т.д.
В данный момент существует множество программ для автоматизации
тестирования через пользовательский интерфейс [15]. Рассмотрим пять из них:
 PyWinAuto – не совсем программа, но плагин для Python’а [30];
 LDTP – изначально программа разрабатывалась только для Ос Linux [27];
 Sikuli Script - средство автоматизации GUI приложений, использующее
распознавание образов [16];
 Robot Framework – программная платформа для разработки автоматических
тестов, который предоставляет табличное форматирование[34];
 AutoIt – язык для автоматизации выполнения задач в Windows [37].
Нужно рассмотреть каждую программу, чтобы определиться, какую
использовать. Итак, PyWinAuto – плагин для Python. Он абсолютно бесплатен и
является хорошим средством для автоматизации тестирования. Плюсы этого
плагин: родной плагин для Python (не нужно искать, скачивать и устанавливать
дополнительные файлы), простой доступ к графическим элементам интерфейса,
встроенные элементы для автоматизации. Но есть и недостатки: работает
плагин только вместе с стандартными Windows API элементами (для

13
большинства приложений этого вполне достаточно, хотя даже нестандартное
окно pywinauto увидит, но кликать можно только по координатам, а это можно
сделать и без плагина pywinauto), последнее обновление плагина было в 2011
году. В приложении 1 Пример pywinauto приведен пример простого
автоматического теста: создание документа в блокноте с текстом «Hello world!»
и его сохранение. Далее для остальных инструментов автоматизации
тестирования будут приведены такие же примеры, чтобы после было удобно
сравнить скрипты. Перед созданием теста с помощью pywinauto необходимо
установить целый набор программ. Для написания теста необходимо знать
основы языка Python и изучить ключевые слова pywinauto [31, 32].
LDTP (Linux Desktop Testing Project Tutorial) – бесплатный инструмент,
использующий технологию помощи ограниченным людям для управления
пользовательским интерфейсом. Изначально инструмент рассчитан на ОС
Linux, но теперь есть возможность использовать его на ОС Windows и Mac OS.
В качестве языка разработки тестов использован Python. В приложении 1
Пример LDTP описан пример автоматического теста, написанный с помощью
LDTP. Для написания теста необходимо знать основы языка Python и изучить
ключевые слова LDTP [28, 29].
Sikuli Script – инструмент для автоматизации тестирования с помощью
компьютерного зрения, разработанный в университете MIT группой, которая
занимается дизайном пользовательских интерфейсов. В качестве языка
разработки тестов использована модификация языка Python - Jython. Главным
плюсом является то, что графические элементы используются как конструкции
языка. Таким образом, разработка тестов значительно упрощается. В
приложении 1 Пример Sikuli описан пример автоматического теста, написанный
с помощью Sikuli Script. Для написания простых тестов не нужно знать какого-
либо языка программирования, тесты можно написать с помощью стандартных
функций Sikuli Script [18, 19, 21, 22].
14
 На самом деле Robot Framework ничего не тестирует сам. Это интерфейс
взаимодействия библиотек Selenium и AutoIt с пользователем. Тесты выглядят
как таблицы. Язык, на котором пишутся тесты, понять легче, чем pywinauto и
LDTP. Robot Framework + Selenium используется для тестирования интернет
страниц в браузере, а Robot Framework + AutoIt для тестирования приложений.
Все же перед написанием тесты, нужно изучить ключевые слова библиотек
Robot Framework, а их немало. Т.к. для написания теста для приложений
используются Robot Framework + AutoIt, пример теста будет выглядеть так же,
как и для инструмента автоматизации AutoIt [33, 35, 36].
AutoIt изначально был предназначен для создания макросов, которые
выполняли часто повторяющиеся задачи. Например, установка наборов
программ на большое количество компьютеров. Так же AutoIt часто
используется для создания ботов к онлайн-играм (чем очень недовольны
разработчики AutoIt). Пример приложения, написанный с помощью AutoIt в
приложении 1 Пример AutoIt. Перед созданием теста с помощью AutoIt
необходимо установить целый пакет программ. Для написания теста
необходимо изучить ключевые слова AutoIt [37, 38, 39, 40].
Рассмотрим подробнее инструмент автоматизации тестирования Sikuli
Script, так как этот инструмент больше всего подходит для проверки отсутствия
ошибок в программном обеспечении через графический интерфейс. Sikuli Script
регулярно модифицируется разработчиками, очень удобен и понятен для
написания автоматических тестов, так же приспособлен не только для Windows,
но и для Mac OS и Linux.
Так же для автоматизации тестирования нужно выбрать билд-сервер для
непрерывной интеграции, чтобы автоматические тесты могли запускаться по
расписанию или по требованию, не используя персональный компьютер
инженера-тестировщика. Непрерывная интеграция – частые
автоматизированные сборки проекта, выполненные в процессе разработки
15
программного обеспечения. Плюсы непрерывной интеграции в том, что все
изменения быстро появляются в новой версии программы. Так же, если
несколько изменений несовместимы, то с помощью постоянных сборок проекта
это выяснится быстрее, чем без непрерывной интеграции, соответственно
быстрее исправится. Постоянное наличие стабильной версии программы для
тестирования демонстрации и т.д. тоже является значительным преимуществом
непрерывной интеграции [55, 56].
Для удобной командной работы нужно использовать систему управления
версиями. В настоящее время существует множество билд-серверов и систем
управления версиями. Система управления версиями – программное
обеспечение, которое упрощает командную работу с изменяющимися
приложениями. В настоящее время это необходимый элемент для разработки
программного обеспечения. Система управления версиями позволяет хранить
последние версии проекта и возвращаться к ним (откат). Так же она позволяет
работать с несколькими проектами одновременно и переключаться между ними.
Несколько программистов могут работать над одним проектом одновременно и
не передавать друг другу файлы, а отправлять изменения(commit) в систему
управления версиями, таким образом, экономится много времени при
разработке программного обеспечения [57, 58].
В дипломной работе используются билд-сервер Teamcity, и система
управления версиями Perforce.
Teamcity обладает следующими преимуществами [50, 53]:
 бесплатная версия включает в себя 20 конфигураций сборки и 3 агента
для сборки;
 поддержка платформ Java, .NET, Ruby;
 возможность запускать Personal build (тестирование, результаты
которого видны только запустившему тесты пользователю);
 параллельность сборок;
16
  интеграция с системами оценки кода.
Так же преимущества Perforce [59, 60]:
 гибкое управление ветками версий проекта, объединение и откат на
предыдущие ревизии;
 интеграция со множеством средств разработки программного
обеспечения (Eclipse, Petrel, Microsoft Office, Autodesk 3D Studio Max и
др.).

Обзор основных функций Sikuli

Sikuli Script – инструмент для поиска и автоматизации тестирования

графических пользовательских интерфейсов, использующий визуальный
подход. Sikuli Script изначально разрабатывался как исследовательский проект с
открытым исходным кодом командой дизайнеров в Массачусетском
технологическом институте. Плюсы инструмента автоматизации Sikuli Script
[20]:
 легко изучить;
 просто использовать;
 наглядно;
 обширное применение.
Но разрешение у скриншотов и изображения на билд-агенте должно быть
одинакового расширения, иначе Sikuli может не увидеть картинку.
Для работы с Sikuli Script нужно:
 Java SE Development Kit 7u65 - бесплатно распространяемый комплект
разработчика приложений на языке Java компании Oracle Corporation
[41];
 Sikuli-IDE - интегрированная среда разработки для написания скриптов с
использованием скриншотов.
На рисунке 1 показано главное окно Sikuli.
17
 Рисунок 1. Главное окно Sikuli

При создании проекта создается папка с расширением .sikuli, в которой

лежат файл с расширением .рy (сам скрипт автоматического теста), файл с
расширением .html (файл для просмотра автоматического теста в браузере) и
картинки, используемые в данном тесте. Чтобы открыть уже созданный проект,
нужно выбрать папку с расширением .sikuli.
Рассмотрим основные функции Sikuli IDE.В Sikuli IDE есть ряд основных
функций [20]:
 New – создание нового проекта;
 Open – открытие уже существующего проекта;
 Save – сохранение проекта;
 Save as – сохранение проекта с изменением директории.

18
 Рисунок 2. Меню File

Так же в Sikuli IDE есть функции [20]:

 Take screenshot (рисунок 3) – позволяет делать снимки с экрана для

использования в тестах. Картинки автоматически сохраняются в папку с
автоматическим тестом;

Рисунок 3. Take Screenshot

 Insert image(рисунок 4) – позволяет вставить в тест уже существующую

картинку;

19
 Рисунок 4. Insert image

 Create Region(рисунок 5) – выделение области, в которой будет

производиться поиск картинки;

Рисунок 5. Create Region

Пример использования (нахождение кнопки очищения корзины):

Рисунок 6. Create region example

 Run(рисунок 7) – запуск теста;

Рисунок 7. Run

 Run in slow motion (рисунок 8) – запуск теста в замедленном темпе.

Данная функция полезна для отладки автоматических тестов.

Рисунок 8. Run in slow motion

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

9 [20]:
20
 find(image) – нахождение картинки;
 findAll(image) – найти все совпадения;
 wait(image) – ждать появления картинки;
 waitVanish(image) – дождаться исчезновения картинки;
 exists(image/path) – проверка существования элемента (картинки, папки и
т.д.)
 click(image) – щелчок мыши на центре изображения;
 doubleClick(image) – двойной щелчок мыши на центре изображения;
 rightClick(image) – щелчок правой клавиши мыши на центре
изображения;
 hover(image) – навести указатель мыши на центр изображения;
 dragDrop(image, image) – перенести элемент из положения на первом
изображении в положение на втором изображении (например перенос
папки с рабочего стола в корзину);
 type(text) – напечатать текст;
 type(image, text) – напечатать текст в определенном месте(обычно
картинка - текстовое поле например для ввода имени)
 paste(text) – вставить
 paste(image, text) – вставить текст в определенном месте;

21
 Рисунок 9. Стандартные функции Sikuli

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

функциях click, doubleClick, rightClick, hover, dragDrop, type, paste. Для этого
нужно щелкнуть по нужной картинке, перейти во вкладку Target Offset и задать
нужные координаты (просто щелкнуть куда нужно или ввести координаты
цифрами). Пример вкладки Target Offset на рисунке 10.

22
 Рисунок 10. Вкладка Target Offset

Так же в свойствах картинки есть вкладка Matching Preview, в которой

можно посмотреть соответствие картинки изображению на экране.

Рисунок 11. Вкладка Matching Preview

23
 Красный регион показывает найденные соответствия. Можно поменять
точность изображения на ползунка Similarity (1 = 100%). Чем значение точности
ниже, тем больше соответствий найдет Sikuli IDE на экране. Регионы,
выделенные красным цветом - больше всего похожи на картинку, фиолетовые –
менее похожие.

Рисунок 12. Matching Preview с малой точностью соответствия

24
Глава 2. Технологии и программное обеспечение тестирования ПО.

Для того, чтобы рассмотреть автоматизацию контроля отсутствия ошибок

на примере Ocean for Petrel будет использоваться программное обеспечение:
 Teamcity Enterprise 9.0.4 – билд-сервер для непрерывной интеграции проекта;
 Perforce Visual Components – система управления версиями;
 VMware vSphere Client 5.0 – платформа для виртуализации инфраструктуры;
 Ocean for Petrel 2015 – программное обеспечение для разработки плагинов для
Petrel 2015;
 Petrel 2015 – платформа, которая предлагает пользователям интегрированные
рабочие процессы от сейсмики до разработки;
 Microsoft Visual Studio 2013 – интегрированная среда разработки
программного обеспечения;
 Java SE Development Kit 7u65 - бесплатно распространяемый комплект
разработчика приложений на языке Java компании Oracle Corporation;
 Sikuli-IDE - интегрированная среда разработки для написания скриптов с
использованием скриншотов.
Тестируемое программное обеспечение Ocean for Petrel 2015 можно
установить, только если на компьютере или виртуальной машине уже
установлен Petrel 2015, т.к. не имеет смысла создавать разрабатывать плагины
для Petrel, без Petrel. Visual Studio 2012(или Visual Studio 2013) является
необязательным компонентом для установки Ocean for Petrel 2015, но при этом
без Visual Studio установятся не все компоненты программы. Чтобы полноценно
протестировать Ocean for Petrel на отсутствие ошибок, нужно обязательно иметь
установленные Petrel 2015 и Visual Studio 2012(Visual Studio 2013).
VMware vSphere понадобится для создания виртуальной машины (далее
билд-агент), чтобы запускать автоматические тесты. В рассмотренном примере
билд-сервер будет настроен на запуск тестов по расписанию. Тесты будут
25
запускаться ночью, чтобы инженер-тестировщик мог в начале рабочего для
проанализировать отчет о результатах и, если необходимо, сообщить
программистам об обнаруженных ошибках.
Perforce будет использоваться для интеграции автоматических тестов, так
как над автоматическими тестами может работать не один инженер-
тестировщик. Java SE Development Kit 7u65 и Sikuli-IDE будут использоваться
для написания и воспроизведения автоматических тестов. Как уже
упоминалось, если разрешение изображения на билд-агенте и разрешение
изображения Sikuli-теста не совпадают, то Sikuli не распознает это
изображение. Поэтому, билд-агент будет использоваться не только для запуска
тестов, но и для их создания.
На локальном компьютере уже должны быть установлены Microsoft Visual
Studio 2013, Java SE Development Kit 7u65, Sikuli-IDE и Perforce. Установка
производится с настройками по умолчанию.
Рассмотрим основные шаги автоматизации тестирования, а потом опишем
каждый шаг подробнее:
1. Создание билд-агента для написания и запуска автоматических тестов.
2. Установка необходимого программного обеспечения на билд-агент (Visual
Studio 2013, Java SE Development Kit 7u65, Sikuli-IDE).
3. Разработка автоматических тестов.
4. Настройка билд-сервера Teamcity. Нужно настроить так, чтобы при каждом
запуске тестов на билд-агент копировались последние версии Petrel 2015 и
Ocean for Petrel 2015. Так же настроить автоматическую установку Petrel и
Ocean for Petrel.
5. Отправка автоматических тестов на сервер с помощью системы управления
версиями Perforce.
6. Запуск автоматических тестов и анализ результатов.

26
 1. Создание билдагента.

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

обеспечение виртуализации. Для создания билдагента моей системы я
использовала VMWare. Создадим виртуальную машину с перечисленными
параметрами [47, 48]:

 операционная система Windows 7;

 имя виртуальной машины в моей системе Admin-PC
 оперативная память: 8192 MB;
 количество процессоров: 4;
 остальные параметры по умолчанию.

27
 2. Установка и настройка необходимого программного обеспечения.

Как уже было сказано ранее, для полного тестирования Ocean for Petrel
2015 необходимо установить Microsoft Visual Studio 2013 (Professional,
Enterprise или Developer), поэтому я установила Microsoft Visual Studio
Professional 2013 с параметрами по умолчанию.
Далее описывается установка обязательного программного обеспечения и
задание необходимых настроек билдагента для запуска на нем автоматических
тестов. Загрузим с официального сайта Java SE Development Kit 7u65
(http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-
javase7-521261.html) и запустим файл установки. Устанавливаем Java SE
Development Kit 7u65 со всеми настройками по умолчанию [41].
Скачаем Sikuli-IDE с официального сайта
(http://www.sikuli.org/download.html) и запустим скачанный файл.
Рекомендуется перед запуском перенести файл в отдельную папку (в данной
системе C:\sikuli). После запуска еще два файла (runSetup, SikuliX-1.0.1-
SetupLog) распакуются рядом со скачанным файлом. Теперь запустим файл
runSetup. Откроется окно с выбором опций. Каждая опция описывает, для каких
целей будет использоваться Sikuli-IDE. Выберем 1 опцию, нажмем на кнопку
“Setup now” и в диалоговом окне выберем “Yes” [17].
Далее для запуска автоматических тестов нужно установить Teamcity
Build Agent. Для этого на сайте TeamCity перейдем во вкладку Agents. В правом
верхнем углу будет ссылка Install Build Agent, нажимаем и выбираем MS
Windows Installer. Начнется загрузка файла agentInstaller [52].

Рисунок 13. Загрузка файла для билдагента

28
 После завершения загрузки скопируем установочный файл на
виртуальную машину и запустим его. При установке следуем всем
рекомендованным параметрам. В процессе установки откроется окно “Configure
Build Agent Properties”. Указываем в поле ownPort порт, через которые агент
будет получать команды сервера. Так же изменим поле serverUrl на URL
сервера TeamCity. Нажимаем OK, и установка завершается. Выбираем запуск
TeamCity Build Agent с правами системного администратора и нажимаем
“Next”. Установка завершается. Так же понадобится открыть порт, который был
указан в настройках агента. Для этого идем в Control Panel – System and Security
– Window Firewall – Advanced settings и выбираем Inbound Rules – New rule.

Рисунок 14. Настройки фаервола

Откроется окно “New Inbound Rule Wizard”.

29
 Рисунок 15. Окно "New Inbound Rule Wizard"

В первом окне выбираем пункт “Port” – Далее – Указываем номер порта в

поле Specific local ports – Далее – Далее – Далее – Указываем имя и описание
входящего правила и завершаем создание правила.
Настроим автоматический запуск TeamCity Build Agent. Для этого
перейдем в %userprofile%\AppData\Roaming\Microsoft\Windows\Start
Menu\Programs\Startup и создадим ярлык для agent.bat (если параметры
установки не изменялись, то это C:\BuildAgent\bin\agent.bat). Добавим в путь к
файлу “start” (имя ярлыка “agent.bat start”).
Далее нужно дать имя ярлыку и завершить создание. Запустим ярлык,
откроется консольное окно “TeamCity Build Agent”. Можно переходить к
соединению сервера и агента. Для этого перейдем на сайт TeamCity во вкладку
Agents. Появилась вкладка Unauthorized, перейдем в нее и нажмем на
“Unauthorized” напротив созданного агента. Соединение установлено, теперь
агент доступен для запуска автоматических тестов. После установки всего
необходимого нужно сделать снимок виртуальной машины, чтобы не
производить установку программного обеспечения и настройку параметров
билдагента каждый раз.
30
 3. Разработка автоматических тестов.

В проделанной практической работе создано более 90 автоматических

тестов. Рассмотрим сам процесс написания автоматических тестов и опишем
процесс создания трех тестов. Первый самый простой тест не проверку
существования элементов Ocean for Petrel 2015 в Microsoft Visual Studio
(VerifyOceanMenuItemsInVisualStudio2012). Второй тест на создание плагина,
модуля и добавление в плагин дополнительного элемента Workstep
(AddingOceanWorkstep3). Третий, самый сложный тест, на создание плагина,
pip-файла, файла установки msi, а также установку плагина, проверку его
установки и удаления (InstallSingleWixCurrentUser). Приступим к написанию
первого автоматического теста.
Для начала нужно создать файл, в котором будут прописаны процедуры
(CommonOceanSDK). Это сделано в целях уменьшения кода тестов и времени
их поддержки, т.к. многие процедуры используются очень часто, например,
создание плагина. Создавать тесты будем на локальном компьютере с помощью
билдагента. Открываем Sikuli IDE и нажимаем File – New (Или Ctrl+N).

Рисунок 16. Создание нового автоматического теста

31
 Откроется вкладка Untitled. Желательно сразу сохранить тест. Нажимаем
File – Save as… (Или Ctrl+Shift+S)

Рисунок 17. Сохранение автоматического теста

Откроется стандартное окно сохранения файла Windows, в котором

пропишем путь сохранения теста и его название. Необходимо написать
название, так как уже говорилось ранее, что при создании теста создается папка
(.sikuli), в которой лежат файл теста (.py), файл просмотра теста (.html) и все
картинки, использующиеся в тесте. Нажимаем кнопку Save.

32
Рисунок 18. Задание имени для сохранения автоматического теста

Рисунок 19. Сохраненные файлы автоматического теста

33
 Теперь вместо вкладки Untitled появилась вкладка CommonOceanSDK.
Все процедуры, находящиеся в файле CommonOceanSDK, не будут описаны.
Рассмотрим только процедуры, используемые при создании трех тестов.
Полный код файла CommonOceanSDK можно посмотреть в Приложении 2
CommonOceanSDK. Для начала подключим библиотеки, использование
которых значительно упростит процесс написания автоматических тестов [25].

Рисунок 20. Используемые библиотеки

Рассмотрим каждую библиотеку по отдельности. Библиотека sikuli.Sikuli

импортирует методы Sikuli, чтобы использовать их совместно с Python.
Библиотека os позволяет использовать функции операционной системы, такие
как старт процессов, их завершение и другие. Библиотека subprocess отвечает за
процедуры открытия папок, их закрытия и другие. Библиотека shutil позволяет
копировать, перемещать и выполнять другие операции с файлами и папками
[24].
Далее напишем простые процедуры, использующие встроенные функции
Sikuli. Данные процедуры значительно упростят написание тестов. Начнем с
waitAndClick(). Если попробовать написать простой тест, то можно убедиться,
что почти после каждого запуска программы или открытия папки приходится
указывать время ожидания, так как если использовать функцию click(), то она
не будет ждать, пока прогрузится файл. Поэтому совместим функции click() и
wait().

34
 Рисунок 21. Процедура waitAndClick()

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

если время не будет передаваться вторым параметром, то ожидание картинки
будет 150 секунд. Аналогично напишем процедуры waitAndRightClick(),
waitAndDoubleClick(), waitAndFind().

Рисунок 22. Процедуры waitAndRightClick(), waitAndDoubleClick(), waitAndFind()

35
 Сохраним созданные процедуры. Нажимаем File – Save (Или Ctrl+S).
Когда изменения в файле сохранены, то пропадает звездочка из вкладки с
названием теста.
В тестах часто понадобится открывать и закрывать Microsoft Visual Studio
2013. Напишем процедуры runVisualStudio() и closeVisualStudio(), которые
будут это делать.

Рисунок 23. Процедуры runVisualStudio() и closeVisualStudio()

Рассмотрим процедуру runVisualStudio(). В первой строчке завершаем

процесс установки/удаления плагинов. Это необходимо для тестов на создание
плагинов, их установку и удаление, так как если что-то в процессе установки
или удаления пойдет не так, то тест завершит свою работу, и запустится
следующий тест. Если в следующем тесте потребуется опять установить плагин,
то установочный файл не запустится, так как процесс установки/удаления уже
запущен. Далее с помощью процедуры getIDEVSFolder(), описанной ниже,
определим папку, в которой установлена Microsoft Visual Studio 2013, и
запишем ее в переменную vsExe. Следующей строчкой откроем
программу с помощью переменной vsExe, созданной предыдущим шагом. И
последние две строчки отвечают за открытие и загрузку Visual Studio.
Процедура getIDEVSFolder() выглядит следующим образом:

36
 Рисунок 24. Процедура getIDEVSFolder()

В первой строчке определяем версию установленной Visual Studio с

помощью переменной окружения VSVERSION, так как на билдагенте может
быть установлено несколько экземпляров Visual Studio с разными версиями.
Переменная VSVERSION задается при запуске тестов в настройке сборки через
TeamCity. Настройка сборки TeamCity рассмотрена в пункте 4. Далее
составляем название еще одной переменной окружения с помощью версии,
полученной на предыдущем шаге. На третьей строчке определяем путь
установки Visual Studio с помощью переменной окружения, полученной на
второй строке процедуры. И последней строкой возвращаем путь, по которому
установлена Microsoft Visual Studio [17].
Теперь рассмотрим процедуру closeVisualStudio(). В этой процедуре
выбирается File из строки меню и в выпадающем меню Exit.
Почти в каждом тесте приходится создавать проекты и их компилировать,
поэтому напишем процедуры, которые позволят создавать
проект(find_ocean_templates()), выполнять его построение (buildSolution()) и
закрывать(closeSolution()). Первая процедура find_ocean_templates() выглядит
так:

Рисунок 25. Процедура find_ocean_templates()

Создаем процедуру по нахождению шаблонов потому, что в тестах

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

37
элементы(items). То есть в тесте будет открываться окно, а находиться шаблон
проекта будет с помощью процедуры find_ocean_templates().
Процедуры закрытия и построения проекта выглядят так:

Рисунок 26. Процедуры buildSolution() и closeSolution()

Обе процедуры просты и применяются практически в каждом тесте. В них

используются стандартные средства Visual Studio, поэтому, они останутся
актуальными, даже если изменится графический интерфейс тестируемого
программного обеспечения. Перед закрытием проекта он сохраняется, а потом
уже закрывается, так как, если проект не сохранен, то появится сообщение о
сохранении. А проверка наличия окна сохранения и сохранение занимает две
строчки кода теста. Поэтому оптимизируем код и запишем то же самое одной
строчкой. В процедуре построения проекта открывается вкладка результатов,
чтобы убедиться, что проект был скомпилирован без ошибок. Обычно,
сообщение об успешном построении проекта появляется в строке состояния
Visual Studio, но это бывает не всегда, поэтому следует открыть вкладку
результатов.
Так же в тестах часто приходится менять текст в полях имени и не только,
поэтому целесообразно будет написать процедуру, которая меняет текст в
заданном месте. Процедура называется TextChange() и выглядит так:

38
 Рисунок 27. Процедура TextChange()

Во входных параметрах картинка и текст, который нужно ввести.

Принцип процедуры в том, что нужно выбрать текстовое поле, выделить все,
что в нем есть, и написать нужный текст. Так же очень полезная процедура для
замены текста FindAndReplace(). На вход процедуре идут две строки: первая та,
которую нужно заменить, вторая - которой заменить. Выполняется процедура
стандартными средствами Visual Studio, поэтому изменения интерфейса
тестируемой программы никак не повлияют на это процедуру. Процедура
вполне проста и понятна. Она дает возможность не только заменить строку
введенным текстом, но и ранее скопированной строкой.

Рисунок 28. Процедура FindAndReplace()

39
 Для того, чтобы проверить отсутствие ошибок при полноценном создании
установочного файла плагина, проверить, что плагин не устанавливает лишние
файлы, и что при удалении не оставляет после себя файлы и документы, нужно
написать процедуры для создания плагина (create_ocean_plugin()), создания pip
builder проекта (create_pip()), создание установочного файла (create_msi()), его
установку (install_msi()) и удаление (uninstall_msi()).
Процедура создания плагина выглядит следующим образом:

Рисунок 29. Процедура create_ocean_plugin()

В процедуре create_ocean_plugin() имеется один входной параметр – это

имя создаваемого плагина. Вначале, нужно дождаться загрузку Visual Studio.
40
После этого создаем новый проект, находим проекты Ocean’а, выбираем Ocean
Plug-in, вводим имя, полученное нами в качестве входного параметра. После
нажатия кнопки ОК, появится окно создания плагина. В процессе создания
плагина нужно выбрать “Create new module”. Больше ничего выбирать не
нужно, поэтому доходим до последней страницы окна создания плагина и
нажимаем Finish. Далее открываем вкладку свойств плагина и удалим событие,
происходящее после построения плагина (Post-build event). Это необходимо
сделать, так как данное событие устанавливает плагин в Petrel, а если плагин
установится, то нельзя будет установить плагин с помощью инсталлятора [17].
Следующая процедура – создание pip builder проекта. Добавляем проект в
имеющееся решение (так как pip builder проект нельзя создать без плагина,
соответственно в пустое решение проект не добавится), выбираем pip builder
проект. При создании проекта менять ничего не нужно, поэтому доходим до
последней страницы и завершаем создание pip builder проекта. После этого
скомпилируем решение. Это необходимо делать перед созданием
установочного файла, так как при создании используется файл с расширением
.pip, созданный pip builder проектом. Если не построить решение, то файл не
появится.

Рисунок 30. Процедура create_pip()

41
 После создания pip builder проекта нужно создать инсталлятор плагина. В
тесте три входных параметра – версия Petrel, тип установки и имя плагина.

Рисунок 31. Процедура create_msi()

Вначале, с помощью процедуры delete_project_directory() удалим

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

Рисунок 32. Процедура delete_project_directory()

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

который устанавливает плагин с помощью msi. В конце теста созданный
установочный файл копируется в папку “C:\OceanSDKTesting\WixInstaller
2015”, но там уже может быть инсталлятор из предыдущего теста, поэтому
необходимо удалить все из этой папки. Процедура delete_project_directory()
использует стандартные средства языка python. Далее идет знакомый код –
создание проекта, только в этот раз создается Wix Plug-in Installer проект. При
создании проекта выбираются DeployPlugin проект и DeployPlugin.pip файл.
После этого определяем тип установки, и в зависимости от значения второго
42
параметра меняем в файле Product.wsx строчку perMachine с помощью
процедуры FindAndReplace(). Далее компилируем проект, закрываем его и
закрываем Visual Studio. После этого убеждаемся в существовании папки
WixInstaller 2015 и копируем установочный файл из папки с проектом в папку
для инсталляторов. В коде теста использованы уже знакомые процедуры и
стандартные средства языка python [42].
Следующая процедура устанавливает плагин через установочный файл и
проверяет, что все необходимые файлы созданы. Тест разделен на две
процедуры: install_any_msi() и checking_install_msi(). Процедура
install_any_msi() производит установку плагина, а checking_install_msi()
проверяет целостность установки. Можно было бы сделать это все в одной
процедуре, но бывает, что один инсталлятор устанавливает несколько плагинов,
поэтому пришлось бы дополнительно создавать процедуру, для проверки
установки второго плагина. В данном случае имеется две процедуры
checking_install_msi() и checking_install_multiple_msi(). С кодом процедуры
checking_install_multiple_msi() можно ознакомиться в приложении 1
CommonOceanSDK.

Рисунок 33. Процедура install_msi()

Процедура checking_install_msi() принимает на вход два параметра:

версию Petrel и опцию установки. Вначале теста открывается установочный
файл и, если Visual Studio по какой-либо причине оказалась запущена, то она
закрывается. Далее идут стандартная установка и проверка опции установки.
Если второй параметр равен “optimization”, то в процессе установки будет
выбрана опция “Plug-in Startup Optimization”, выбор которого ускорит процесс
запуска Petrel. Далее после нажатия кнопки “Install” запускается сам процесс
установки, дожидается его завершения и закрывает установочный файл.
43
 Рисунок 34. Процедура install_any_msi()

После установки плагина проверяется целостность его установки.

Открываются определенные папки, и проверяется наличие файлов плагина.

Рисунок 35. Процедура checking_install_msi()

После проверки установки плагина его можно удалять. В процедуре

удаления есть один входной параметр – версия Petrel. Начинается тест точно так
же, как и тест для установки плагина: открывается установочный файл и
закрывается Visual Studio. Далее идет стандартный процесс удаления –
последовательное нажатие кнопок Next-Remove-Remove. После этого плагин
удаляется и можно закрывать инсталлятор. Но необходимо проверить, что
плагин полностью удалился. Для этого вызывается процедура
checking_uninstall_msi(), входной параметр которой такой же, как и у
uninstall_msi().

44
 Рисунок 36. Процедура uninstall_msi()

Процедура checking_uninstall_msi() проверяет отсутствие папок, в которые

создаются при создании установке плагина.

Рисунок 37. Процедура checking_uninstall_msi()

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

билдагенте, поэтому запускаем билдагент на сохраненном снимке и
устанавливаем Petrel 2015 и Ocean for Petrel 2015.
Так же, как создали файл CommonOceanSDK, создадим файл
VerifyOceanMenuItemsInVisualStudio2012. Так же, как и в CommonOceanSDK
пропишем используемые библиотеки и файлы.

Рисунок 38. Библиотеки для теста VerifyOceanMenuItemsInVisualStudio2012

Библиотека CommonOceanSDK – это только что созданный файл,

содержащий в себе процедуры, которые будут использоваться в автоматических
тестах. Итак, для начала нужно открыть Microsoft Visual Studio 2013 и для
написания теста, и для его последующего запуска. Поэтому открываем
билдагент и запускаем Microsoft Visual Studio 2013. Одновременно с этим в

45
тесте прописываем процедуру runVisualStudio(). Дальше нужно проверить, что
окно программы развернуто на весь экран. Поэтому пишем в тесте условие.

Рисунок 39. Разворачивание окна

Так же установим точность картинки на 80 процентов, так как при

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

Рисунок 40. Ожидание загрузки Visual Studio

Таким образом дождемся полной загрузки Visual Studio и появления

Ocean Start Page. Далее напишем цикл, который будет нажимать “OCEAN” в
строке меню, пока не появится меню.

Рисунок 41. Открытие меню Ocean

Цикл используется на случай, если все-таки Visual Studio не успела

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

46
 Рисунок 42. Проверка существования всех элементов меню Ocean

Полный код данного теста выглядит так:

Рисунок 43. Автоматический тест VerifyOceanMenuItemsInVisualStudio2012

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

Рисунок 44. Автоматический тест AddingOceanWorkstep3

48
 Подключаем библиотеки sikuli, CommonOceanSDK, os. Далее откроем
окно создания проекта с помощью горячих клавиш. Находим Ocean Plug-in
проект, меняем название и создаем проект. При создании плагина добавляем
модуль и Workstep. Написанными в CommonOceanSDK процедурами изменяем
имена и параметры созданного Workstep’а. Так же выбираем создание
графического интерфейса. После завершения создания и настройки проекта
открываем файл с пользовательским интерфейсом и Toolbox. Добавляем
элемент BasicButton на форму, компилируем проект и закрываем его. С
помощью процедур, написанных в CommonOceanSDK, тесты разрабатываются
быстро и выглядят просто.
Приступим к написанию третьего теста. Этот тест будет состоять всего из
шести процедур, содержащихся в CommonOceanSDK. Подключим нужные
библиотеки и файл CommonOceanSDK, из которого подхватываются
процедуры. Далее запускаем Visual Studio и создаем плагин, в качестве
входного параметра передаем название плагина. Создаем pip builder проект и
установочный файл. Входные параметры для создания инсталлятора это –
версия Petrel, тип установки и название плагина. Устанавливаем плагин и
удаляем его. После установки и удаления в процедурах идет проверка на
наличие и отсутствие файлов плагина в соответствующих папках. В этом тесте
не использовано ни одного скриншота, и он занимает всего 6 строчек (не считая
библиотек).

Рисунок 45. Автоматический тест InstallSingleWixCurrentUser

49
 Для запуска автоматических тестов по списку и понятного отображения
автоматических отчетов можно использовать файлы UItests.py и tests.py,
приведенные в приложении 1 файл UItests.py и приложении 1 файл tests.py.
Первый файл отвечает за список тестов, автоматически запускаемых на сервере.
Файл tests.py при провале теста создает html файл на виртуальной машине, куда
записывает скрипт автоматического теста, выделяет строку, на которой
программа не выполнила ожидаемое действие и вставляет в html файл снимок
экрана в данный момент. Таким образом, при использовании этих файлов тесты
буду проходит в нужном порядке, и в случае провала теста отчеты будут
выглядеть просто и понятно для анализа. Для использования файлов нужно
подключить их как библиотеки, используя import.

50
 4. Настройка билд-сервера Teamcity.

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

билдагент копировались последние версии Petrel 2015 и Ocean for Petrel 2015.
Так же настроить автоматическую установку Petrel 2015 и Ocean for Petrel 2015.
Открываем сайт TeamCity и кликаем по ссылке Administrator в правом
верхнем углу [51].

Рисунок 46. Вкладка Administrator TeamCity

Откроется окно со списком текущих проектов. Если еще ни одного

проекта не существует, то в списке будет только пункт <Root project>.
Выбираем нужный пункт в меню, откроются настройки проекта. На вкладке
General Settings представлен список всех текущих сборок. Для создания новой
сборки для автоматических тестов нажмите на кнопку “Create build
configuration”.

Рисунок 47. Создание нового билда для автоматических тестов

Откроется окно создания нового проекта “Create New Project”. Введем

имя проекта (Name), ID проекта (Project ID) и описание (Description).

51
 Рисунок 48. Задание параметров билда для автоматических тестов

Нажимаем кнопку Create. Билд появился в списке Build Configurations.

Выберем созданный билд и произведем его настройку. Во вкладке General
Settings есть возможность поменять имя проекта (Name) и его ID (Build
Configuration ID) [53].
Параметр Build number format отвечает за номер сборки. Его можно
задавать как вручную, так и настроить автоматический счетчик сборок, указав
%build.counter%.
Параметр Build counter используется в номере сборки. При каждом
запуске сборки проекта значение Build counter автоматически увеличивается на
единицу. Для сброса значения Build counter на 1 нужно нажать Reset рядом с
текстовым полем.
Параметр Artifact paths отвечает за путь сохранения результатов
автоматического тестирования. Изначально результаты сохраняются на
билдагент. Для сохранения результатов на локальной машине или на сервере
укажите путь следующим образом: путь_до_результатов_на_агенте =>
пользовательский_путь. Если достаточно сохранить результаты тестирования на
билдагенте (после отката виртуально машины результаты сотрутся), то
оставляем данный параметр пустым [53].
52
 Параметры Build options задают дополнительные параметры сборки и
являются необязательными. Параметр “enable hanging builds detection” отвечает
за остановку сборки проекта в случае зависания билдагента или автоматических
тестов. Билд считается зависшим, если время его выполнения значительно
превышает среднее время длительности сборки. Это очень полезный параметр,
т.к. если автоматические тесты запускаются ночью, и несколько сборок
проектов автоматических тестов должны проходить подряд (например,
тестирования на разных версиях Visual Studio), то это позволит не зависнуть
всем сборкам из-за зависания одного из них. То есть зависшие автоматические
тесты через некоторые время прекратятся, а дальше автоматические тесты
пойдут по расписанию. Параметр “Enable status widget” извлекает статус и
основные детали из последнего запуска сборки проекта, не требуя
аутентификации пользователя. Параметр “Limit the number of simultaneously
builds” отвечает за количество сборок, которые могут выполняться
одновременно.

Рисунок 49. Настройка General Settings

Выполним настройки на вкладке General Settings и перейдем на вкладку

Version Control Settings. Здесь нужно добавить синхронизацию с системой
53
контроля версий. Для этого нажимаем на кнопку “Attach VCS root”. Выбираем в
первом раскрывающемся списке нужный проект, нажимаем Attach. Выбираем
во втором раскрывающемся списке нашу систему контроля версий - Perforce.
Нажимаем кнопку Create. Открывается окно VCS Roots, где появилась только
что созданная связь с системой контроля версий Perforce. Остальные настройки
оставим по умолчанию [53].

Рисунок 50. Настройка Version Control Settings

Переходим на вкладку Build Steps. В текущих автоматических тестах 3 шага:

1. Установка Petrel и Ocean for Petrel 2015.
2. Удаление ключа из реестра для того, чтобы не появлялось окно
регистрации Ocean for Petrel 2015 в Visual Studio.
3. Запуск автоматических тестов.
Рассмотрим создание одного из шагов. Во вкладке Build Steps нажимаем на
кнопку Add build step. Откроется окно New build step. В выпадающем списке
Runner type выбираем тип запускаемого события. В зависимости от выбранного
типа появятся определенные поля. При выборе типа Command Line появляются
поля Step name, Execute step, Working directory, Run и Custom script [53].
54
 Рисунок 51. Создание нового шага билда

Параметр Step name отвечает за имя создаваемого шага. Параметр Execute

step отвечает за запуск данного шага. По умолчанию стоит значение if all
previous steps finished successfully. Это означает, что данный шаг запустится,
только если все предыдущие шаги завершились без ошибок. Параметр Working
directory отвечает за директорию текущего процесса сборки. Параметр Run
отвечает за запуск текущего шага. Есть два варианта запуска шага: первый –
запуск текущего скрипта, второй – запуск с параметрами. Параметр Custom
script содержит в себе скрипт, который необходимо запустить. В нашем случае
он будет выглядеть примерно так: путь_до_Sikuli\runIDE.cmd -r
путь_до_автотестов\UItests.sikuli.

55
 Рисунок 52. Настройка Build Steps

После настройки всех шагов сборки переходим к настройке триггеров во

вкладке Triggers. В данной вкладке есть возможность настраивать запуск
автоматических тестов по расписанию, задавать события перед запуском тестов,
после завершения автоматических тестов и другие. Создадим триггер для
автоматического запуска тестов по расписанию. Нажмем на кнопку “Add new
trigger” и выберем из выпадающего списка Schedule trigger. Откроются
дополнительные настройки триггера.

Рисунок 53. Создание нового триггера

56
 Параметр When отвечает за период времени, через который запускаются
автоматические тесты. Есть параметры daily - ежедневно, weekly – еженедельно
и advanced – расширенный (для указания пользовательского периода). Параметр
Time отвечает за время, в которое будет запускаться сборка проекта. Параметр
Timezone отвечает за часовой пояс, по которому определяется время запуска
автоматических тестов. Параметр Trigger only if there are pending changes
отвечает за запуск триггера, только если были внесены какие-либо изменения в
сборку. Параметр Trigger rules отвечает за дополнительные правила триггера.
Параметр Build Changes отвечает за запуск триггера, только при условии, что
сборка другого проекта завершилась успешно. Например, мы хотим, чтобы
автоматические тесты запускались тогда, когда у нас появится новый
установщик. Для этого отметим данный параметр и укажем путь к сборке
установщика. Таким образом после каждого успешного прохождения сборки
установщика будет работать триггер [53].
Во вкладке Additional Options есть два параметра: первый – Clean all files
in checkout directory before build (Удалить все выходные файлы из директорий
перед запуском сборки) и второй – Trigger build on all enabled and compatible
agents (Запускать триггер на всех доступных и совместимых билдагентах).
Настроим нужные параметры и нажмем кнопку Save. Созданный триггер
появился в списке Triggers.

Рисунок 54. Настройка Triggers

Далее перейдем к настройке раздела Failure Conditions, а котором

определяются условия провала сборки. Параметр “it runs longer than specified
limit in minutes” определяет время, после превышения которого сборка проекта
57
считается проваленным. Параметр “the build process exit code is not zero”
отвечает за провал сборки, если код ошибки отличен от 0. Параметр “at least one
test failed” отвечает за провал сборки, если хотя бы один из тестов не прошел.
Параметр “an error message is logged by build runner” отвечает за провал сборки
проекта, если ошибка вызвана build runner’ом. Параметр “an out-of-memory or
crash is detected (Java only)” отвечает за провал сборки, если недостаточно
свободной памяти или случилось падение Java. Так же в разделе Failure
Conditions есть возможность добавить пользовательские условия провала
сборки проекта. Настроим раздел Common Failure Conditions.

Рисунок 55. Настройка Failure Conditions

В разделе Build Features можно настроить особенности сборки проекта,

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

58
 Рисунок 56. Настройка Build Features

Раздел Dependencies содержит в себе связи текущей сборки с другими

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

Рисунок 57. Настройка Dependencies

В разделе Parameters указываются параметры конфигурации, системные

параметры и переменные среды. Для создания параметра нажмем на кнопку
“Add new parameter”. Откроется окно “Add New Parameter”, в котором выберем
тип параметра (Kind), введем имя параметра (Name) и его значение(Value).
Нажмем на кнопку “Save”. Созданный параметр появился в списке всех
параметров сборки проекта.

59
 Рисунок 58. Создание нового параметра билда

Часть параметров могут быть перенесены из корневой сборки. В этом

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

Рисунок 59. Настройка Configuration Parameters

В System Properties указываются папки, из которых брать установочные

файлы Petrel 2015 и Ocean for Petrel 2015, имена серверов и пароли.

60
 Рисунок 60.Настройка System Properties

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

сборки, например, версия Microsoft Visual Studio (VSVERSION) и другие.

Рисунок 61. Настройка Environment Variables

Во вкладке Agent Requirements задаются требования к билдагентам. В

системе может существовать множество билдагентов, но тесты будут
запускаться только на тех, которые соответствуют требованиям, прописанным в
данном разделе. Для добавления требования нажмем на кнопку “Add new
requirement”. Открывается окно “Add Requirement”, где нужно заполнить имя
параметра (Parameter Name) и условия для этого параметра (Condition).
Параметр может существовать, не существовать, быть
равным/меньшим/большим какого-либо значения и другое [53].

61
 Рисунок 62. Добавление нового требования к билдагенту

Добавим следующие требования:

 На агенте должна быть установлена Microsoft Visual Studio 2012.

 Зададим конкретное имя билдагента.

После добавления требований в разделе Agent Compatibility можно увидеть

список подходящих билдагентов.

Рисунок 63. Настройка Agent Requirements

62
 5. Отправка разработанных автоматических тестов на сервер с помощью
Perforce.

После написания тестов и настройки сборки проекта приступим к

отправке тестов на сервер, откуда они будут запускаться. Для отправки
разработанных автоматических тестов можно использовать любую систему
контроля версий. В моей работе использована система контроля версий Perforce.
Отправим разработанные тесты на сервер, откуда они будут копироваться на
билдагент. Отправка осуществляется стандартным способом [59]:
 выбор измененных файлов для отправки;
 отправка файлов на сервер с необходимым комментарием.

63
 6. Запуск автоматических тестов и анализ полученных результатов.

После отправки тестов на сервер откроем в TeamCity настроенную

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

Рисунок 64. Билд с изменениями

Для запуска тестов нажмем кнопку “Run”, находящуюся в строчке сборки

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

Рисунок 65. Просмотр проваленных тестов

В этой вкладке можно смотреть отчеты по не пройденным тестам.

64
 Рисунок 66. Список проваленных тестов

Выберем один из не пройденных тестов и посмотрим его отчет.

Рисунок 67. Лог отчета проваленного теста

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

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

66
 Заключение

Тестирование – устоявшийся способ обеспечения качества разработки

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

67
 Список используемых источников

1. Минеева О. Управление Качество ПО. Лекция 3. URL: http://delta-

course.org/docs/delta3/IDC3-D6T2L1.pdf (Дата обращения: 31.03.2016).
2. Wikipedia. Обеспечение качества. URL:
https://ru.wikipedia.org/wiki/Обеспечение_качества (Дата обращения:
31.03.2016).
3. Загвязинский В. И., Атаханов Р. Методология и методы психолого-
педагогического исследования: Учеб. пособие для студ. высш. пед. учеб.
заведений. -2-е изд., стер. — М.: Издательский центр «Академия». 2005.
Тестирование (метод тестов). URL: http://scibook.net/issledovanie-
psihologii-knigi/testirovanie-metod-testov-17699.html (Дата обращения:
31.03.2016).
4. Bugs catcher. Базовые вопросы о тестировании. URL:
http://bugscatcher.net/archives/2118 (Дата обращения: 31.03.2016).
5. Люпан А. Основные положения тестирования. URL:
https://habrahabr.ru/post/110307/ (Дата обращения: 31.03.2016).
6. Автоматизированное функциональное тестирование. URL:
http://www.protesting.ru/automation/functional.html (Дата обращения:
02.04.2016).
7. Поляруш М. Автоматизация Windows GUI приложений на Python. URL:
http://automated-testing.info/t/avtomatizacziya-windows-gui-prilozhenij-na-
python/2309 (Дата обращения: 02.04.2016).
8. Аршинов М. Юнит-тестирование для чайников. URL:
https://habrahabr.ru/post/169381/ (Дата обращения: 02.04.2016).
9. Каща А. Модульное тестирование: 2+2=4? URL:
http://rsdn.ru/article/testing/UnitTesting.xml (Дата обращения: 02.04.2016).

68
10. Software-testing.ru Тестирование и качество ПО. Функциональное
тестирование. URL: http://www.software-testing.ru/library/testing/functional-
testing (Дата обращения: 02.04.2016).
11. НОУ ИНТУИТ. Тестирование пользовательского интерфейса. URL:
http://www.intuit.ru/studies/courses/1040/209/lecture/5418 (Дата обращения:
02.04.2016).
12. HabraHabr. Автоматизация тестирования программных систем. URL:
https://habrahabr.ru/post/160257/ (Дата обращения: 02.04.2016).
13. Панкратов В. Разработка критериев анализа систем автоматизации
тестирования. URL: http://citforum.ru/SE/testing/pankratov/criterion/ (Дата
обращения: 02.04.2016).
14. Полевой В. Как автоматизировать тестирование ПО? URL:
http://www.interface.ru/home.asp?artId=7382 (Дата обращения: 02.04.2016).
15. Pukabu. Пост №3. Инструменты автоматизации тестирования. URL:
http://pikabu.ru/story/post_3_instrumentyi_avtomatizatsii_testirovaniya_39812
11 (Дата обращения: 07.04.2016).
16. Ben Lau. Instant Sikuli Test Automation. Packt Publishing Ltd., 2013, 54 c.
17. Sikuli / SikuliX Documentation for version 1.1+ (2014 and later). URL:
http://sikulix-2014.readthedocs.org/en/latest/index.html (Дата обращения:
07.04.2016).
18. Подробнее о Sikuli в автоматизации тестирования. URL:
http://habrahabr.ru/post/163883/ (Дата обращения: 07.04.2016).
19. Snehal M Patel. Sikuli Script. Mahatma Gandhi Institute of Technical
Education & Research Centre-Navsri, 2011, 32 c.
20. Satish Gorripotu. Sikuli. 105 c.
21. Tom Yeh, Rob Miller. Practical Sikuli using screenshots for GUI automation
and testing. 41 c.
22. Panupan Sriautharawong. Automation Testing with Sikuli Script. 2013, 8 c.
69
23. SikuliX powered by RaiMan. QuickStart. URL:
http://www.sikulix.com/quickstart.html (Дата обращения: 07.04.2016).
24. StackOverflow. Newest ‘sikuli’ questions. URL:
http://stackoverflow.com/questions/tagged/sikuli (Дата обращения:
13.04.2016).
25. Жарий Д. Sikuli – простые примеры правильной автоматизации (Java).
URL: https://habrahabr.ru/post/164679/ (Дата обращения: 13.04.2016).
26. Блог о тестировании и не только. Sikuli – технология автоматизации
пользовательского интерфейса с помощью скриншотов. URL:
https://cryptrat.wordpress.com/2010/09/26/sikuli-технология-автоматизации-
пользова/ (Дата обращения: 13.04.2016).
27. Linux Desktop Testing Project Tutorial. URL:
https://github.com/ldtp/ldtp2/blob/master/doc/ldtp-tutorial.rst#push-button
(Дата обращения: 15.04.2016).
28. LDTP User manual. URL: http://ldtp.freedesktop.org/user-doc/index.html
(Дата обращения: 15.04.2016).
29. Linux Desktop Testing Project – LDTP. Tutorial. URL:
http://fossies.org/linux/ldtp/doc/ldtp-tutorial.pdf (Дата обращения:
15.04.2016).
30. Pywinauto 0.4.2 documentation. 2010. URL:
http://pywinauto.googlecode.com/hg/pywinauto/docs/index.html (Дата
обращения: 21.04.2016).
31. Hellt. Win32 QUI Automation при помощи pywinauto. URL:
https://habrahabr.ru/post/37153/ (Дата обращения: 21.04.2016).
32. Saju’s Tech Blog. Using Python / pywinauto for automating Windows
GUI applications. URL: https://techsaju.wordpress.com/2013/03/06/using-
python-pywinauto-for-automating-windows-gui-applications/ (Дата
обращения: 21.04.2016).
70
33. Поляруш М. Как установить и настроить Robot Framework. URL:
http://automated-testing.info/t/kak-ustanovit-i-nastroit-robot-framework/2403
(Дата обращения: 21.04.2016).
34.Robot Framework. URL: http://robotframework.org (Дата обращения:
21.04.2016).
35. Robot Framework User Guide Version 2.8.5. URL:
http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUse
rGuide.html (Дата обращения: 21.04.2016).
36. Virtuous Programmer. Test Automation with Robot Framework. URL:
http://www.virtuousprogrammer.com/?p=264 (Дата обращения: 21.04.2016).
37. AutoItLibrary – Documentation. 2009. URL: http://robotframework-
autoitlibrary.googlecode.com/svn/tags/robotframework-AutoItLibrary-
1.0/doc/AutoItLibrary.html (Дата обращения: 29.04.2016).
38. Примеры автоматизации работы в AutoIt. URL:
http://habrahabr.ru/sandbox/38638/ (Дата обращения: 29.04.2016).
39. AutoIt Script. Autoit Documentation. URL:
https://www.autoitscript.com/site/autoit/documentation-localization/ (Дата
обращения: 29.04.2016).
40. Харитон А. Автоматизация, как много в этом слове. AutoIt в примерах.
URL: http://stproject.info/blog/?p=88 (Дата обращения: 29.04.2016).
41. Java. Установка Java. URL:
http://www.java.com/ru/download/help/index_installing.xml (Дата
обращения: 29.04.2016).
42. Python. Documentation. URL: https://www.python.org/doc/ (Дата
обращения: 01.05.2016).
43. Pythontutor. Интерактивный учебник языка Python. URL:
http://pythontutor.ru (Дата обращения: 01.05.2016).
44. WikiPython. URL: http://wikipython.ru (Дата обращения: 01.05.2016).
71
45. CLinuxWorld. Преимущества Python. URL:
http://www.clinuxworld.com/admin/334-benefits (Дата обращения:
01.05.2016).
46. Wikipedia. Python. URL: https://ru.wikipedia.org/wiki/Python (Дата
обращения: 01.05.2016).
47. Wikipedia. VMware. URL: https://ru.wikipedia.org/wiki/VMware (Дата
обращения: 03.05.2016).
48. VMWare. VMWare vSphere 6 Documentation. URL:
https://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-6-
pubs.html (Дата обращения: 03.05.2016).
49.Александрова Ю. TeamCity VMWare vSphere plugin. URL:
http://blog.jetbrains.com/teamcity/2014/12/teamcity-vmware-vsphere-plugin/
(Дата обращения: 03.05.2016).
50.Wikipedia. Teamcity. URL: https://ru.wikipedia.org/wiki/TeamCity (Дата
обращения: 07.03.2016).
51. Цуканов П. Continuous Integration для чайников вместе с Teamcity. URL:
http://www.slideshare.net/ptsukanov/tuladev-team-city (Дата обращения:
07.03.2016).
52. Jake Ginnivan’s blog – TeamCity UI Test Agent. 2013. URL:
http://jake.ginnivan.net/teamcity-ui-test-agent/ (Дата обращения: 07.03.2016).
53. Confluence Jetbrains. TeamCity Documentation. URL:
http://confluence.jetbrains.com/display/TCD9/Build+Configuration (Дата
обращения: 11.05.2016).
54. SavePearlHarbor. Настройка TeamCity для новичков. URL:
http://savepearlharbor.com/?p=205402 (Дата обращения: 11.05.2016).
55. Wikipedia. Непрерывная интеграция. URL:
https://ru.wikipedia.org/wiki/Непрерывная_интеграция (Дата обращения:
11.05.2016).
72
56. Ильин А. Непрерывная интеграция и TeamCity. URL:
https://habrahabr.ru/post/105895/ (Дата обращения: 11.05.2016).
57. Все о Hi-Tech. Обзор систем контроля версий. URL: http://all-
ht.ru/inf/prog/p_0_1.html (Дата обращения: 14.05.2016).
58. Wikipedia. Система управления версиями. URL:
https://ru.wikipedia.org/wiki/Система_управления_версиями (Дата
обращения: 14.05.2016).
59.Wikipedia. Perforce. URL: https://ru.wikipedia.org/wiki/Perforce (Дата
обращения: 14.05.2016).
60.Perforce. Configuring Perforce with TeamCity Streams. URL:
https://www.perforce.com/blog/151007/configuring-teamcity-perforce-streams
(Дата обращения: 14.05.2016).
61. Diary of a Ninja. Automated deployments with TeamCity, Deployment
projects and SVN. URL:
http://www.diaryofaninja.com/blog/2010/05/09/automated-site-deployments-
with-teamcity-deployment-projects-amp-svn (Дата обращения: 14.05.2016).

73
 Приложение 1
Пример pywinauto.

Рисунок 68. Пример pywinauto

Пример LDTP.

Рисунок 69. Пример LDTP

74
Пример Sikuli Script.

Рисунок 70. Пример Sikuli Script

Пример AutoIt.

Рисунок 71. Пример AutoIt

75
CommonOceanSDK

Рисунок 72. CommonOceanSDK часть 1

76
Рисунок 73. CommonOceanSDK часть 2

77
Рисунок 74. CommonOceanSDK часть 3

78
Рисунок 75. CommonOceanSDK часть 4

79
Рисунок 76. CommonOceanSDK часть 5
80
Рисунок 77. CommonOceanSDK часть 6

Рисунок 78. CommonOceanSDK часть 7

81
Рисунок 79. CommonOceanSDK часть 8

Рисунок 80. CommonOceanSDK часть 9

82
Рисунок 81. CommonOceanSDK часть 10

Рисунок 82. CommonOceanSDK часть 11

83
 Рисунок 83. CommonOceanSDK часть 12

Файл UItests.py.

Рисунок 84. UItests.py

84
Файл tests.py.

Рисунок 85. tests.py часть 1

Рисунок 86. tests.py часть 2

85
Рисунок 87. tests.py часть 3

Рисунок 88. tests.py часть 4

86