В команде нет автотестеров – что делать?

Некоторые из вас, возможно, слышали, что в первую неделю декабря по всей России прошла образовательная акция “Час кода": для школьников 5-11 классов проводили открытые уроки, на которых показывали, что программировать это просто и увлекательно и каждый может этому научиться.

Мы в Acronis решили поделиться собственным опытом: как мы пробуем обучать программированию наших сотрудников, не отрывая их от работы.

Задача

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

Казалось бы, это совсем несложно: даны конкретные шаги и результаты, которые должны в итоге получиться, – однако есть одно большое «НО». Большинство тестировщиков не владеет языками программирования. Когда мы в Acronis столкнулись с этой проблемой, у нас возникла идея найти инструмент, который умел бы выполнять тестовые сценарии, написанные людьми без квалификации разработчика. Тестировщики будут писать сценарии, как и раньше (может, чуть более формализовано), но выполнять эти сценарии будет не человек, а машина.

Инструмент

В автоматизации уже давно сложились несколько общепринятых истин: например, keyword-driven или data-driven подходы, BDD (Behavior Driven Development) и ATTD (Acceptance Test Driven Development), написание тестовых библиотек под ваше приложение, генерация отчетов и т. д. В качестве инструмента для нашей задачи мы выбрали Robot Framework, который объединяет все эти вещи воедино. Это open-source фреймворк, который в первую очередь предназначен для автоматизации приемочного тестирования и ATTD. При этом его возможности выходят далеко за эти рамки и позволяют создать мощный каркас для автоматизации тестирования ПО с ориентацией на самые разные потребности.

Мы остановились именно на этом фреймворке по нескольким причинам. Во-первых, потому что в нем есть инструменты для тестирования веб-страниц и веб-приложений. Во-вторых, есть большой набор пакетов и расширений: мы, например, используем аддон управления машинами через SSH. Наконец, Robot Framework основан на принципе keyword-driven тестирования, то есть на разработке ключевых слов, которые потом могут использовать даже люди, не очень хорошо разбирающиеся в программировании.

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

Например:

open browser
welcome page should be opened
username field should be visible
password field should be visible
login button should be visible
input username   $username
input password    $password
press login button

На основании ключевых слов можно легко строить тесты с различными данными на входе, или же превращать тесты в читаемый и исполняемый текст. В Robot Framework встроены библиотеки для автоматизации веб-приложений, баз данных, действий с файловой системой, SSH, Swing, SWT, Windows GUIs и т. д. Также в этом фреймворке имеется редактор тестов и много дополнительных плагинов для интеграции в любые проекты. В целом архитектура фреймворка построена таким образом, что можно без труда расширять исходную функциональность и писать собственные библиотеки на языках Python или Java.

Реализация

К началу эксперимента большая часть наших сервисов уже была покрыта функциональными тестами, которые написали на «питоне» сами разработчики. При этом тестами не была покрыта веб-консоль и точки интеграции между ней и сервером. Мы решили, так сказать, «убить сразу двух зайцев»: научить тестировщиков писать автоматические тесты и привлечь фронт-энд разработчиков для написания базового функционала и ключевых слов на нижнем уровне. Например, код фразы “open browser” в Robot Framework выглядит следующим образом:

*** Keywords ***
  open browser
     [Arguments]    ${url}
      run keyword if  '${DEBUG}' == 'false'  set log level  debugging
     Browser.open browser    ${url}    ${BROWSER}  desired_capabilities=service_args:--ignore-ssl-errors=true;--ssl-protocol=tlsv1;--debug=${DEBUG};--disk-cache=true;--max-disk-cache-size=204800
     set browser implicit wait   ${IMPLICIT WAIT}
     set selenium speed          0.2s
     delete all cookies
     set window size   1400    1280  # for PhantomJS
     maximize browser window

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

Интеграция Robot Framework с нашей системой построения отчетов не вызвала особых проблем. Робот поддерживает любой вид аддонов для отчетов: для этого нужно всего лишь написать питоновский класс с парочкой методов:

class CustomReporter:
    def start_suite(self, name, attributes):
      # put your code here

    def end_suite(self, name, attributes):
      # put your code here

    def start_test(self, name, attributes):
      # put your code here

    def end_test(self, name, attributes):
      # put your code here

Еще одна фича, которую мы в данном случае оценили, – возможность группировать тесты с помощью тэгов. Каждому тесту можно присвоить тот или иной атрибут, а после выбирать для запуска только те, которые им обладают. К примеру, помечать тесты, которые выполняются долго, и не запускать их при каждом прогоне. Мы используем эту возможность в основном для того, чтобы мониторить наши боевые серверы. Выделяем часть тестов, которые проверяют доступность основных точек входа в систему, пишем соответствующий плагин (чтобы результат был в формате, понятном для zabbix-agent) и в итоге имеем постоянную систему мониторинга доступности нашего сайта.

По этой ссылке можно посмотреть демо версию робота-фреймворка: клик

Что же до привлечения наших тестеровщиков к автоматизации, мы двигаемся в нужном направлении. Теперь к каждому багу или задаче в баг-трекере разработчики пишут сценарии “как проверять”: причем пишут так, чтобы можно было легко использовать их в работе. Так, шаг за шагом мы убеждаем наших тестеров, что программирование и тестирование – это просто :)

Автор: bgaifullin

Источник