t.me/atinfo_chat Telegram группа по автоматизации тестирования

А вам интересно, какие проекты по автоматизации вокруг вас?


(Mykhailo Poliarush) #1

меня всегда мучили подобные вопросы:

  • а сколько вообще людей работают автоматизаторами в СНГ?
  • как много вообще проектов по автоматизации?
  • как их выполняют?
  • что у таких проектов общего?
  • какая архитектура используется и почему она выбирается?

я говорил с разными автоматизаторами и компаниями, и спрашиваю вас.

а ВЫ (ваша компания) готовы поделиться такой информацией во благо того, чтобы другие узнали как она в принципе делаете на просторах СНГ?

 

Шаблон, который хотелось бы увидеть:

  1. Почему вы начали автоматизацию? Т.е. цели, которые вам ставили
  2. Что вы автоматизируете? И что не удалось автоматизировать?
  3. Как выбирали конкретный инструмент?
  4. Какой технологический стек вы используете?
  5. Сколько людей задействовано в автоматизации?
  6. Как организованна работа автоматизатора?
  7. Какой подход был выбран и почему? Какая его архитектура?
  8. Как быстро оправдалась ваша автоматизация?
  9. Плюсы вашей автоматизации? Или чем вы больше всего гордитесь?
  10. Минусы вашей автомматизации? Или чем вы недовольны?

(VoronchihinAV) #2

У нас WPF\WCF приложение. Автоматизация с использование TestComplete 8. Тесты пишутся в VS2010. Запуск и обновление организовано с использованием Build Sevice. Готов поделиться опытом.


(Максим Таран) #3

Наша компания занимается интеграционными решениями, поэтмоу используем самописное решение. Если тесируем GUI, то стараемся это делать при помощи RFT, если нет определённых требований от заказчика.


(Lich) #4

На предыдущем месте работы было очень много автоматизации. Все писали на TestComplete7 / JavaScript

Создал отдельный движок по обработке тестов (которые хранились в базе) и работали по принципу keyword driven test. Тестами занимались в той или иной степени все в отделе. 

 

Сейчас использую WebDrover для GWT портала. (Java) Отлично идет, тоже подход keywork driven с хранением самих тестов и результатов в базе. Все можно отслеживать в online режиме + интеграция в одном отчете атоматизированного и ручного тестов если в том есть необходимость. Сейчас нас 2 человека и оба полностью во все это погружены. Ручками все равно много тестируем, но лишь потому что от нового функционала никуда и никогда не избавишься а старого много. Но постепенно весь регрешн закроем автоматизацией с запуском на CI сервере.

 


(rpwheeler) #5

Компания, видимо, пока не готова. Ну что ж, расскажу за себя.

 

- Почему вы начали автоматизацию? Т.е. цели, которые вам ставили

Почему начал:  "Машина должна работать, а человек - думать". 

Какие цели:

а) автоматизация рутины. Все, что я хочу видеть сделанным не ручными повторениями.

б) В 2009-2010 году мы (команда) занимались разработкой брендовых мобильных приложений под Windows Mobile для Очень Известной Компании. В требования ОИК входило monkey testing с помощью Microsoft Hopper Test Tool, - инструмента, посылавшего приложению последовательность случайных кликов, движений, клавиатурного ввода и всякого такого прочего. Это "кунг-фу стиля обезьяны" оказалось очень эффективным инструментом для проверки приложения на устойчивость и утечки памяти. 

В конце 2010-го уже в другой компании мне была предложена задача реализовать аналогичный функционал, "обезьяну" для тестирования iPad-приложения на эмуляторе.
 

- Что вы автоматизируете? И что не удалось автоматизировать?

а) то самое monkey testing, несколько его разнообразя-"притирая" под текущие приоритеты

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

- Как выбирали конкретный инструмент?

По-моему через alternativeto.net, с прицелом на Free and Open Source, а также кросс-платформенность
 

- Какой технологический стек вы используете?

В данный момент лично я использую  "чистое" Sikuli/Python.  Для выяснения того, "что именно сделала "обезьяна" чтобы завалить приложение" иногда используется видеосъемка на веб-камеру.

Вообще в рамках проекта также используется тестирование серверной части с помощью SoapUI.


- Сколько людей задействовано в автоматизации?

Двое соответственно. Один - SoapUI, я - "дрессировщик обезьяны".


- Как организованна работа автоматизатора?

Подход monkey testing не требует существенных затрат времени на кодирование и организацию. Переписывание скрипта-инструмента под специфическую задачу с пробными пусками теста занимает несколько часов максимум.

По поводу части автоматизации SoapUI - отвечать не готов, но люди, которые знакомы с этим инструментом, все и так знают :)

- Какой подход был выбран и почему? Какая его архитектура?

Как я уже сказал выше, monkey testing оказалось довольно эффективным инструментом тестирования на стабильность: падения и утечки памяти, в том числе в регрессионном тестировании:  если в предыдущей итерации "не падало", а после изменений в этой в случайных тестах пошли падения - определенно где-то что-то "сломали" или плохо (на/пере)писали.
 
Архитектура для "случайных тыков" особо не требуется, но свои хитрости есть, скажем, механизм выведения обезьяны из "тупиков", ситуаций где отношение площади кнопки выхода к общей площади экрана эмулятора очень мало. Позже я усовершенствовал скрипт, добавив возможность выбора с разной вероятностью разных серий действий (общая серия кликов, серия в регионе меню, серия перетаскиваний, серия вперед-назад... всякие).

По причинам выбора Sikuli добавлюто 

  • визуальное распознавание ситуации на экране, позволяющее эффективно реагировать на разные ситуации
  • отсутствие привязок к api или там XPATH позволяет "кликать все, что шевелится", - совершенно недружественный эмулятор и в нем движущуюся галерею картинок, написанную на некоем варианте OpenGL.
  • мне очень нравится совместимость инструмента с языком программирования общего назначения, позволяющем реализовывать "любые фантазии"


- Как быстро оправдалась ваша автоматизация?

Быстро.  "Валит" приложение - значит работает и ловит баги :). Ну и, кроме того, скрипт довольно легко приспосабливать под разные проекты, повторяюсь.
 

- Плюсы вашей автоматизации? Или чем вы больше всего гордитесь?

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

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

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

 

- Минусы вашей автоматизации? Или чем вы недовольны?

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

Да и сам скрипт можно еще оптимизировать и усовершенствовать.

Движок Sikuli - это продукт beta-качества от небольшой команды, в котором довольно сильно течет память.


(re1ax) #6

1. Почему вы начали автоматизацию? Т.е. цели, которые вам ставили

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

2. Что вы автоматизируете? И что не удалось автоматизировать?

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

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

3. Как выбирали конкретный инструмент?

Гугль + форумы + общение с тем, кто в теме :)

4. Какой технологический стек вы используете?

В итоге остановился на Selenium'e, использую его в связке с Python'ом. Тесты крутятся на Jenkins CI.

5. Сколько людей задействовано в автоматизации?

Пока-что только я один, но в скором времени ко мне добавится ещё один боец :)

6. Как организованна работа автоматизатора?

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

7. Какой подход был выбран и почему? Какая его архитектура?

Я использую разделение тестирования функционала и "статики" (элементы интерфейса, которые обязательно должны быть на странице).

Это упрощает написание скриптов - один раз сделал скрипт test_mainpage и можешь вызывать его из всех своих скриптов типа test_registeration, test_login, test_forgot_password и т.д.

Это упрощает поддержку скриптов - если вдруг что-то изменилось, то достаточно внести изменения только в один скрипт.

Это уменьшает количество строк кода в скрипте тестирования функционала и улучшает читабельность кода.

8. Как быстро оправдалась ваша автоматизация?

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

9. Плюсы вашей автоматизации? Или чем вы больше всего гордитесь?

Она есть и она работает!

10. Минусы вашей автомматизации? Или чем вы недовольны?

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