Добрый день. Я уже пол года занимаюсь автоматизацией тестирования в обной маленькой компании. У меня была задача сделать так, чтоб как можно быстрее появились автотесты. Задачу я решил, но скорее всего не лучшим образом (а если честно, то собрал из палок, гуаны и ответов со стак оферфлоу). Сам чувствую нехватку опыта, а уж если кто оппытнее посмотрет - ахнет.
Наверное мало у кого есть такая возможность сделать именно так, как он хочет, а у меня такая возможность есть, но очень мало идей. Сейчас вопрос касается только автоматизации бэкэнд тестов. Опишу к чему я пришел.
Немного о технологиях. Язык программирования - Java, склад кейзов и их результатов - TestRail, среда в которой вертятся все приложения - Docker.
Как происходит процесс тестирования:
-
Пишу тест кейзы в тест рейл.
-
Объединяю все кейзы в наборы.
-
Пишу код для каждого теста, после чего помечаю его аннотацией, чтоб связать реализацию теста с его описанием в тест рейле.
-
При запуске тестов для каждого набора создается отдельный запуск в тест рейле.
-
В сами тесты передается айдишник созданных в тест рейле ранов.
-
По апихе вытаскиваю все айдишники тестов, которые должны быть запущены.
-
При помощи рефлексии ищу все классы, которые должны быть запущены.
-
Запускаю тесты.
-
По той же апихе отправляю в тест рейл результаты работы тестов и закрываю раны.
Для всего этого точно есть какие-то инструменты, но гугл оправляет на стак оверфлоу, но ответы там совершенно не те.
2 лайка
Ну, во первых, это у вас не процесс тестирования. Это процесс написания автоматизированных сценариев и их запуск.
Для понимания процесса тестирования прочитайте istqb foundation (на русском).
Что касается того, как вы это автоматизируете, то у нас так же сделано. Единственное, что хочется, чтобы вы подумали над следующими вопросами:
- Вы тратите время на тест рейл, а вы уверены, что эти кейсы кому-то сейчас нужны?
- Вы отправляете результаты в тест рейл. А вы уверены , что кому-то это надо?
Я считаю, что пока вы нормально не можете ответить на эти вопросы, то надо сокращать свои трудозатраты на такие вещи.
Не надо делать на будущее или потому что так другие делают и говорят, что надо.
Например, 1 пункт можно исключить, потому что если вы пишете чистый, понятный и хорошо документированный код, то по сути вам не нужно ещё какое-либо описание вашего теста.
2 пункт. Попробуйте в своем CI в сборке тестов прикрутить просто html отчёт. Снова не нужен тест рейл. Попробуйте report portal.
Но отчёт - это лишь способ представления состояния SUT. Информативен ли ваш отчёт? Можно ли заглянув в ошибку понять сразу из отчета, где сломалось и тут же идти писать багу или надо копать глубоко? Если надо копать, то займитесь улучшением локализации дефектов тестами.
Любой процесс должен базироваться на целях и принципах. Процесс автоматизации состоит из своих целей, своих принципов, своих запахов. Об этом подробно прочитайте в книге xunit паттерны. Рефакторинг кода тестов. Эта книга - концентрат опыта автоматизации.
http://www.ozon.ru/context/detail/id/4127815/
3 лайка
Наличие описания тестов и ежедневным отчётам были желаниями технического директора. Мне из из когда понятно что делает тест, но вот придут другие люди, и не факт, что им будет все понятно.
Спасибо за книжку надеюсь я на верном пути.
Может, как вариант перенести тесты в BDD фреймворк типа Cucumber? Сам сейчас об этом задумываюсь, т.к. поддерживать тесты в TestRail становится сложно.
testomat.io управление авто тестами