Давным-давно, в одной далекой стране на три буквы, одна большая компьютерная компания (по странному стечению обстоятельств тоже на три буквы) – IBM, придумала слоган – «машины должны работать, а человек думать».
Тестировщики – автоматизаторы (далее по тексту просто автотестеры) фирмы СМС-ИТ, вдохновленные этим лозунгом, за пару лет написали систему для тестирования нашего флагманского продукта «КОТ».
Цель любого тестирования - сопоставление ожидаемого и фактического результата работы программы. Тестировщики выполняют определенные сценарии, чтобы проверить: если над программой выполнять определенную последовательность дейсвий, то в ответ она выдаст определенный и заранее ожидаемый результат.
Но ведь это же классическое определение алгоритма. Только в качестве исполнителя у нас человек – тестировщик. А можно ли его заменить на компьютер (помните слоган) ? Этим и занимаются автотестеры. Они пишут специальные программы, которые имитируют действия пользователя или браузера, выполняя разные сценарии в тестируемой системе.
Польза в том, что однажды написанный автотест можно потом запускать каждый час, каждый день, для проверки, что влитая вчера фича никак не отразилась на работе 100 старых фич.
Какие виды автотестов мы используем:
- Скриншот - тестирование. Проверяем, что верстка не поехала и все элементы на странице находятся на своих местах. Сравнивается текущий снимок страницы с запомненным как “идеальный”.
- Тестирование API. Вызываются методы сервера приложений, как если бы это делал браузер, и проверяем что метод не завершается с ошибкой, и данные приходят какие надо.
- Нагрузочное тестирование. Проверяем, что наше ПО не даст сбоя при большом количестве одновременных запросов от пользователей.
- Сквозное тестирование. Тут проверяем работу приложения, имитируя действия реального пользователя в браузере.
О последнем поговорим подробнее.
В видео можно посмотреть пример прогона такого теста. Открывается браузер, проходит логин, открывается нужная страница, заполняются поля, страница сохраняется. В нашем распоряжении есть лог тестовой системы, лог браузера и лог сервера приложений, для анализа результатов. Делаются скриншоты страницы в момент ошибок.
Тесты, который выполнились с ошибкой, тестер может проанализировать, завести баг, приложить к нему полученные скриншоты и логи, в помощь рахработчику.
Как мы используем автотесты в повседневной работе? У нас настроен процесс непрерывной сборки проекта. Любой код, написанный разработчиком, сразу же компилируется, и деплоится на тестовые площадки. Затем запускаются тесты, чтобы быстро понять - рабочая ли новая версия, какие баги появились с прошлого прогона. Новые баги заводятся в таск-трекер.
Каждую ночь на проекте КОТ запускается весь набор автотестов перечисленных выше видов. Запуск происходит на нескольких площадках одновременно, на разных конфигурациях продукта. За ночь делается более 20 тысяч проверок! Суммарно проверки длятся более 15 часов (на самом деле быстрее, поскольку выполняются на нескольких площадках одновременно). Только представьте, сколько людей и времени нужно, чтобы повторить эти проверки руками.
Часть 2. Программы пишут программы
На проекте КОТ очень много экранных форм - около сотни. Но все их можно поделить на 4 основных типа - список документов, карта документа, справочник, отчет. И для каждого типа выполняются одни и те же проверки - заполнить поля, проверить что заполнились, сохранить, проверить что сохранилось, проверить что поля не потерялись или не поменялись и. т. п.
Если задача типовая, то она хорошо решается компьютером. Потому, мы написали программу, которая знает про наши типы страниц, компоненты, нужные тесты для каждой страницы. И теперь, тестер открывает страницу, для которой нужен тест, нажимает кнопку и получает пачку готовых тестов для этой страницы. Можно дописать дополнительные проверки, специфичные для данной страницы.
Теперь процесс написания новых тестов стал простой задачей, для которой достаточно самых базовых навыков программирования.
Сам тестовый фреймворк мы тоже делаем все умнее и умнее. Например, научили его замечать разные окошки, панельки, оставшиеся с прошлых неудачных тестов, и мешающие взаимодействовать с интерфейсом, закрывать их и продолжать выполнение тестов. Или – дозаполнить произвольными значениями оставшиеся пустыми поля на форме, чтобы форма могла успешно сохраниться. А также научили его особенностям отображения КОТа на мобильных устройствах, чтобы те же самые тесты мы могли прогонять и на телефонах.
А что же остается автотестерам? Самое интересное. Придумывать и реализовывать новые специфичные сценарии тестирования системы, дорабатывать тестовый фреймворк, учить его новым полезным трюкам.