Открыть Электронные книги
Категории
Открыть Аудиокниги
Категории
Открыть Журналы
Категории
Открыть Документы
Категории
Введение ........................................................................................................................ 3
Глава 1. Теоретические и технологические основы тестирования программного
обеспечения................................................................................................................... 5
Обзор литературы ..................................................................................................... 5
Заключение ................................................................................................................. 67
Список используемых источников ........................................................................... 68
Приложение 1 ............................................................................................................. 74
2
Введение
На современном этапе развития информационных технологий стоит вопрос
автоматизации рабочих процессов. Тестирование является важным этапом
разработки программного обеспечения. Чем позже начато тестирование, тем
выше риски, и тем менее надежной она может получиться. Так же ошибки,
найденные до выпуска программного обеспечения, обходятся компании гораздо
дешевле, чем ошибки, выявленные пользователями в процессе эксплуатации.
Именно поэтому для любой компании очень важно, чтобы тестировщики
своевременно находили ошибки в программном обеспечении. Как правило,
процесс тестирования – очень трудоемкий, так как при появлении новой
функциональности в систему, тестировщику необходимо проверить сначала эту
функциональность, при этом обычно производится как позитивное, так и
негативное тестирование. То есть проверяется работоспособность системы при
правильном и неправильном обращении с ней пользователя. После проверки
новой функциональности тестировщику необходимо провести регрессионное
тестирование (проверить корректность работы старой функциональности).
Тестирование программного обеспечения позволяет вовремя выявить
ошибки в программном обеспечении, которые могут привести к краже данных
или к потере их целостности.
У автоматизации тестирования есть ряд преимуществ. Во-первых,
повышение производительности труда. Во время выполнения автоматических
тестов инженер-тестировщик может заниматься другими задачами. Часто
лучше, чтобы тесты выполнялись в нерабочее время, т.к. нагрузка на локальные
сети ночью снижена. Во-вторых, минимизация человеческого фактора,
повышение надежности. В отличие от компьютера, работоспособность человека
зависит от многих факторов: эмоционального состояния, психического
состояния и т.д. Тестирование иногда бывает рутинным и однообразным,
поэтому человек становится более невнимательным. В-третьих, удешевление
3
процессов (более эффективное использование ресурсов). Т.е. когда
автоматические тесты уже написаны, на их поддержку и анализ требуется
меньше времени, чем на тестирование вручную.
Во многих предприятиях, разрабатывающих программное обеспечение,
есть отдел тестирования. Чем больше предприятии и чем больше у него
проектов, тем больше штат отдела тестирования. Исследованиями в области
автоматизации тестирования занимаются как штатные сотрудники на
предприятиях (Яндекс, Google и другие крупные предприятия), так и в
Технологических Институтах (особенно усиленно изучается автоматизирование
тестирования в Массачусетском Технологическом Институте).
В связи с вышеизложенным мною была поставлена цель разработать
методологию и систему автоматизации контроля отсутствия ошибок в
программном обеспечении.
Для достижения цели в дипломной работе необходимо решить следующие
задачи:
проанализировать теоретические основы автоматизации тестирования
программного обеспечения;
рассмотреть виды автоматизации тестирования контроля целостности и
доступности и существующие системы автоматизации тестирования;
рассмотреть программное обеспечение, которое будет использоваться для
разработки системы автоматизации тестирования;
разработать методологию по организации автоматизации тестирования
программного обеспечения;
разработать систему автоматизации контроля отсутствия ошибок в
программном обеспечении;
проверить работу системы автоматизации контроля отсутствия ошибок в
программном обеспечении на примере Ocean for Petrel.
4
Глава 1. Теоретические и технологические основы тестирования
программного обеспечения.
Обзор литературы
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
Теоретические основы автоматизации тестирования
8
Повышение производительности сотрудников – вместо выполнения
каждый день тестов вручную инженер-тестировщик может просто
проанализировать автоматический отчет и выполнять другую работу.
Но у автоматического тестирования есть и некоторые минусы[1]:
Повторяемость тестов является как плюсом автоматического
тестирования, так и недостатком. Все тесты выполняются однообразно.
Выполняя тестирование вручную, тестировщик может обратить
внимание на некоторые детали, которые автоматический тест не
заметил.
Затраты на поддержку. Затраты меньше, чем на ручное тестирование
того же функционала, но, тем не менее, они есть.
Затраты на разработку автоматических тестов. К этому пункту
относятся: потраченное время сотрудников на написание скриптов и
отладку тестов, стоимость лицензионного программного обеспечения,
потраченное время на установку и настройку программного
обеспечения.
Из вышеперечисленного можно сказать, что автоматизирование
тестирования является достаточно эффективным решением для предприятий,
разрабатывающие программное обеспечение. Чтобы убедиться в этом, сравним
ручной и автоматизированный подходы к контролю отсутствия ошибок [7].
Критерий Ручное Автоматическое
Задание входных Гибкость в задании Входные значения
значений данных. Позволяет строго заданы
использовать разные
значения на разных
циклах запуска тестов,
расширяя покрытие
9
Проверка результата Гибкая, позволяет Строгая. Нечетко
тестировщику сформулированные
оценивать нечетко критерии могут быть
сформулированные проверены только
критерии путем сравнения с
эталоном
Повторяемость Низкая. Человеческий Высокая
фактор и нечеткое
определение данных
приводят к не
повторяемости
тестирования
Надежность Низкая. Длительные Высокая, не зависит от
тестовые циклы длины тестового цикла
приводят к снижению
внимания
тестировщика
Чувствительность к Зависит от детальности Высокая.
незначительным описания процедуры. Незначительные
изменениям в продукте Обычно тестировщик в изменения в
состоянии выполнить интерфейсе часто ведут
тест, если внешний вид к коррекции эталонов
продукта и текст
сообщений несколько
изменились
Скорость выполнения Низкая Высокая
Возможность Отсутствует. Низкая Поддерживается
10
генерации тестов скорость выполнения
обычно не позволяет
исполнить
сгенерированный
набор тестов
Таблица 1. Сравнение ручного и автоматизированного тестирования
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 и
др.).
18
Рисунок 2. Меню File
19
Рисунок 4. Insert image
Рисунок 7. Run
21
Рисунок 9. Стандартные функции Sikuli
22
Рисунок 10. Вкладка Target Offset
23
Красный регион показывает найденные соответствия. Можно поменять
точность изображения на ползунка Similarity (1 = 100%). Чем значение точности
ниже, тем больше соответствий найдет Sikuli IDE на экране. Регионы,
выделенные красным цветом - больше всего похожи на картинку, фиолетовые –
менее похожие.
24
Глава 2. Технологии и программное обеспечение тестирования ПО.
26
1. Создание билдагента.
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].
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.
29
Рисунок 15. Окно "New Inbound Rule Wizard"
31
Откроется вкладка Untitled. Желательно сразу сохранить тест. Нажимаем
File – Save as… (Или Ctrl+Shift+S)
32
Рисунок 18. Задание имени для сохранения автоматического теста
33
Теперь вместо вкладки Untitled появилась вкладка CommonOceanSDK.
Все процедуры, находящиеся в файле CommonOceanSDK, не будут описаны.
Рассмотрим только процедуры, используемые при создании трех тестов.
Полный код файла CommonOceanSDK можно посмотреть в Приложении 2
CommonOceanSDK. Для начала подключим библиотеки, использование
которых значительно упростит процесс написания автоматических тестов [25].
34
Рисунок 21. Процедура waitAndClick()
35
Сохраним созданные процедуры. Нажимаем File – Save (Или Ctrl+S).
Когда изменения в файле сохранены, то пропадает звездочка из вкладки с
названием теста.
В тестах часто понадобится открывать и закрывать Microsoft Visual Studio
2013. Напишем процедуры runVisualStudio() и closeVisualStudio(), которые
будут это делать.
36
Рисунок 24. Процедура getIDEVSFolder()
37
элементы(items). То есть в тесте будет открываться окно, а находиться шаблон
проекта будет с помощью процедуры find_ocean_templates().
Процедуры закрытия и построения проекта выглядят так:
38
Рисунок 27. Процедура TextChange()
39
Для того, чтобы проверить отсутствие ошибок при полноценном создании
установочного файла плагина, проверить, что плагин не устанавливает лишние
файлы, и что при удалении не оставляет после себя файлы и документы, нужно
написать процедуры для создания плагина (create_ocean_plugin()), создания pip
builder проекта (create_pip()), создание установочного файла (create_msi()), его
установку (install_msi()) и удаление (uninstall_msi()).
Процедура создания плагина выглядит следующим образом:
41
После создания pip builder проекта нужно создать инсталлятор плагина. В
тесте три входных параметра – версия Petrel, тип установки и имя плагина.
44
Рисунок 36. Процедура uninstall_msi()
45
тесте прописываем процедуру runVisualStudio(). Дальше нужно проверить, что
окно программы развернуто на весь экран. Поэтому пишем в тесте условие.
46
Рисунок 42. Проверка существования всех элементов меню Ocean
47
Приступим к написанию следующего теста. Тест AddingOceanWorkstep3
создает плагин с модулем, добавляет дополнительный элемент – Workstep и
добавляет элементы в графический интерфейс плагина.
48
Подключаем библиотеки sikuli, CommonOceanSDK, os. Далее откроем
окно создания проекта с помощью горячих клавиш. Находим Ocean Plug-in
проект, меняем название и создаем проект. При создании плагина добавляем
модуль и Workstep. Написанными в CommonOceanSDK процедурами изменяем
имена и параметры созданного Workstep’а. Так же выбираем создание
графического интерфейса. После завершения создания и настройки проекта
открываем файл с пользовательским интерфейсом и Toolbox. Добавляем
элемент BasicButton на форму, компилируем проект и закрываем его. С
помощью процедур, написанных в CommonOceanSDK, тесты разрабатываются
быстро и выглядят просто.
Приступим к написанию третьего теста. Этот тест будет состоять всего из
шести процедур, содержащихся в CommonOceanSDK. Подключим нужные
библиотеки и файл CommonOceanSDK, из которого подхватываются
процедуры. Далее запускаем Visual Studio и создаем плагин, в качестве
входного параметра передаем название плагина. Создаем pip builder проект и
установочный файл. Входные параметры для создания инсталлятора это –
версия Petrel, тип установки и название плагина. Устанавливаем плагин и
удаляем его. После установки и удаления в процедурах идет проверка на
наличие и отсутствие файлов плагина в соответствующих папках. В этом тесте
не использовано ни одного скриншота, и он занимает всего 6 строчек (не считая
библиотек).
50
4. Настройка билд-сервера Teamcity.
51
Рисунок 48. Задание параметров билда для автоматических тестов
55
Рисунок 52. Настройка Build Steps
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.
58
Рисунок 56. Настройка Build Features
59
Рисунок 58. Создание нового параметра билда
60
Рисунок 60.Настройка System Properties
61
Рисунок 62. Добавление нового требования к билдагенту
62
5. Отправка разработанных автоматических тестов на сервер с помощью
Perforce.
63
6. Запуск автоматических тестов и анализ полученных результатов.
64
Рисунок 66. Список проваленных тестов
Отчет выглядит как список всех шагов теста. Проваленный шаг выделен
красным, и после него идет снимок экрана. По снимку экрана можно понять,
что именно не выполнилось в тесте. После анализа результатов автоматических
65
тестов можно переходить к исправлению тестов или, если тесты нашли ошибку,
то сообщить инженерам-программистам об ошибке. После исправления тестов
повторяем отправку файлов на сервер с помощью Perforce и запускаем
автоматические тесты еще раз.
Так же в настройках сборки был создан триггер на запуск автоматических
тестов по расписанию. Таким образом автоматические тесты не придется
каждый раз запускать руками. Они будут запускаться в удобное для инженера-
тестировщика время.
66
Заключение
67
Список используемых источников
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.
Пример LDTP.
74
Пример Sikuli Script.
Пример AutoIt.
75
CommonOceanSDK
77
Рисунок 74. CommonOceanSDK часть 3
78
Рисунок 75. CommonOceanSDK часть 4
79
Рисунок 76. CommonOceanSDK часть 5
80
Рисунок 77. CommonOceanSDK часть 6
81
Рисунок 79. CommonOceanSDK часть 8
83
Рисунок 83. CommonOceanSDK часть 12
Файл UItests.py.
85
Рисунок 87. tests.py часть 3
86