90% наших тестов проверяют отдельные методы системы: вызов конкретной процедуры и оценка выходных параметров и/или состояния бд.
Как правильней назвать такой вид автоматического тестирования?)
Люблю этот вопрос)
Приёмочное, end to end, функциональное, интеграционное (или любой другой термин) тестирование это не замена, а дополнение к изолированному unit тестированию системы.
В чём проблемы:
1) Функциональные тесты намного сложнее писать. Представим, что мы проверяем бизнес-процессы интернет магазина, который безусловно интегрирован с базой данной лояльности. Но в цепочке «интернет магазин — база данных лояльности» используется ещё десяток микросервисов. Поэтому, чтобы писать такие тесты, нужно
— хорошо представлять архитектуру всей системы
— иметь эталонный набор данных во всех системах
— обеспечить что все системы находятся в валидном состоянии на тестовых контурах
2) Функциональные тесты работают существенно дольше, чем unit тесты. Например, клиент делает покупку и получает за неё бонусы. Факт покупки нужно обеспечить максимально быстро, а вот бонусы начисляются асинхронно в течение какого-то времени после покупки. Внутри системы мы можем дёргать нужные методы и сделать проверку процесса мгновенным, а что делать фронту?
3) Большой процент функционала в принципе может не иметь возможности быть покрытым функциональными тестами. Например, у нас в бд лояльности очень много логики, которая ни на какие фронты не вынесена.
Но функциональные тесты безусловно нужны, просто это отдельный уровень тестирования, который обычно осуществляется на изолированных серверах и отдельными командами. В Спортмастере мы таким также занимаемся.
Подскажите,
1) Есть ли оценка/понимание, какой объём ручного тестирования (в человекочасах или какой другой метрике) был закрыт автоматизацией?
2) Вы писали, что 3% от задач в Jire имеют статус «баг». А сколько это в количественном эквиваленте?
3) Как непосредственно разработчики ПО относятся к вашей системе автоматического тестирования?
Доброго времени суток!
Рад видеть в блоге автора utPLSQL)
В рамках системы лояльности мы действительно используем utPLSQL версии 2.3.1. При этом в Спортмастере есть несколько проектов, где с помощью 3-ьей версии пытаются организовать автоматическое тестирование.
Лично мы видели более продвинутые версии utPLSQL, проанализировали возможности и пришли к выводу, что в условиях нашего проекта преимуществ для перехода недостаточно.
Безусловно, отличий в 3-ьей версии немало. В первую очередь, хороша идея с определением метаданных о тестах (группы, правила и прочее) на уровне спецификации тестовых пакетов. Очень много сделано в плане интеграций с различными внешними компонентами.
Но
1) Вопрос о том, что проверяется автотестами не решён. Обычная реляционная структура (тестовый пакет-тест-тесткейс-группа тестов) существенно наглядней и удобнее в управлении, чем настройки на уровне спецификаций пакетов. Хотя нам и приходится тратить время на заполнение метаданных. Можно конечно было бы написать представление для utPLSQL, которое на основе парсинга настроек тестовых пакетов сформирует подобную структуру, но данный подход имеет свои минусы.
2) Запуск автотестов в 3-ьей версии стал удобней и гибче, но, как я понимаю, он до сих пор не позволяет передавать имя тестовой процедуры без указания пакета.
3) Как показывает практика для нас не актуальна интеграция с приложениями, и пока нет предпосылок для изменения ситуации.
4) Вокруг utPLSQL у нас уже развёрнут свой фреймворк, который мы реализовывали чисто под себя.
Вот и получается, что обновление версии utPLSQL для нас не актуально. Скажу больше, так как основной движок utPLSQL достаточно прост: с помощью динамического sql вызывается конкретная связка пакет-процедура, есть ненавязчивое намерение совсем отказаться от этого решения и перейти на полностью самописный фреймворк.
Ещё unit тесты можно писать в стандартном SQL Developer, PLUTO, Code Tester for Oracle или ruby-plsql-spec. И наверняка существует ещё немало других решений.
В любом случае основная часть работы приходится на написание самих тестов и важно, чтобы с ними было удобно работать.
Спасибо, я действительно немного дал маху.
Основной сайт по utPLSQL создан в 2016 г. вместе с одной из своих эталонных сборок 2.3.1.
А само решение намного-намного старше.
Доброе утро!
Сколько по времени сейчас работают автотесты? И сколько по времени работает весь pipeline?
Решался ли вопрос с запуском автотестов в параллели или сейчас автотесты работают в одном потоке?
Кто пишет автотесты?
Как правильней назвать такой вид автоматического тестирования?)
Приёмочное, end to end, функциональное, интеграционное (или любой другой термин) тестирование это не замена, а дополнение к изолированному unit тестированию системы.
В чём проблемы:
1) Функциональные тесты намного сложнее писать. Представим, что мы проверяем бизнес-процессы интернет магазина, который безусловно интегрирован с базой данной лояльности. Но в цепочке «интернет магазин — база данных лояльности» используется ещё десяток микросервисов. Поэтому, чтобы писать такие тесты, нужно
— хорошо представлять архитектуру всей системы
— иметь эталонный набор данных во всех системах
— обеспечить что все системы находятся в валидном состоянии на тестовых контурах
2) Функциональные тесты работают существенно дольше, чем unit тесты. Например, клиент делает покупку и получает за неё бонусы. Факт покупки нужно обеспечить максимально быстро, а вот бонусы начисляются асинхронно в течение какого-то времени после покупки. Внутри системы мы можем дёргать нужные методы и сделать проверку процесса мгновенным, а что делать фронту?
3) Большой процент функционала в принципе может не иметь возможности быть покрытым функциональными тестами. Например, у нас в бд лояльности очень много логики, которая ни на какие фронты не вынесена.
Но функциональные тесты безусловно нужны, просто это отдельный уровень тестирования, который обычно осуществляется на изолированных серверах и отдельными командами. В Спортмастере мы таким также занимаемся.
1) Есть ли оценка/понимание, какой объём ручного тестирования (в человекочасах или какой другой метрике) был закрыт автоматизацией?
2) Вы писали, что 3% от задач в Jire имеют статус «баг». А сколько это в количественном эквиваленте?
3) Как непосредственно разработчики ПО относятся к вашей системе автоматического тестирования?
Рад видеть в блоге автора utPLSQL)
В рамках системы лояльности мы действительно используем utPLSQL версии 2.3.1. При этом в Спортмастере есть несколько проектов, где с помощью 3-ьей версии пытаются организовать автоматическое тестирование.
Лично мы видели более продвинутые версии utPLSQL, проанализировали возможности и пришли к выводу, что в условиях нашего проекта преимуществ для перехода недостаточно.
Безусловно, отличий в 3-ьей версии немало. В первую очередь, хороша идея с определением метаданных о тестах (группы, правила и прочее) на уровне спецификации тестовых пакетов. Очень много сделано в плане интеграций с различными внешними компонентами.
Но
1) Вопрос о том, что проверяется автотестами не решён. Обычная реляционная структура (тестовый пакет-тест-тесткейс-группа тестов) существенно наглядней и удобнее в управлении, чем настройки на уровне спецификаций пакетов. Хотя нам и приходится тратить время на заполнение метаданных. Можно конечно было бы написать представление для utPLSQL, которое на основе парсинга настроек тестовых пакетов сформирует подобную структуру, но данный подход имеет свои минусы.
2) Запуск автотестов в 3-ьей версии стал удобней и гибче, но, как я понимаю, он до сих пор не позволяет передавать имя тестовой процедуры без указания пакета.
3) Как показывает практика для нас не актуальна интеграция с приложениями, и пока нет предпосылок для изменения ситуации.
4) Вокруг utPLSQL у нас уже развёрнут свой фреймворк, который мы реализовывали чисто под себя.
Вот и получается, что обновление версии utPLSQL для нас не актуально. Скажу больше, так как основной движок utPLSQL достаточно прост: с помощью динамического sql вызывается конкретная связка пакет-процедура, есть ненавязчивое намерение совсем отказаться от этого решения и перейти на полностью самописный фреймворк.
В любом случае основная часть работы приходится на написание самих тестов и важно, чтобы с ними было удобно работать.
Основной сайт по utPLSQL создан в 2016 г. вместе с одной из своих эталонных сборок 2.3.1.
А само решение намного-намного старше.