Комментарии 5
"… к аналитикам и по совместительству тестировщикам" — это как???
Ты сегодня аналитик, а завтра тестировщик?
Как бы это немного разные профессии в принципе…
Ты сегодня аналитик, а завтра тестировщик?
Как бы это немного разные профессии в принципе…
Об этом говорится в первой части
Да, простите, посмотрел первую часть…
Но все равно, странно, я понимаю, когда в компаниях небольшого масштаба отсутствуют тестировщики, потому что и не нужны как прослойка.
Но в таких масштабных проектах это все таки странно, пусть закрытая система, пусть пользователи сотрудники компании, пусть там старый, побитый интерфейс…
Просто удивительно слышать о внедрении системы автоматизированного тестирования в компании, где нет специалистов по ручному тестированию(ни в коем случае не хочу обидеть ваших аналитиков)…
Но все равно, странно, я понимаю, когда в компаниях небольшого масштаба отсутствуют тестировщики, потому что и не нужны как прослойка.
Но в таких масштабных проектах это все таки странно, пусть закрытая система, пусть пользователи сотрудники компании, пусть там старый, побитый интерфейс…
Просто удивительно слышать о внедрении системы автоматизированного тестирования в компании, где нет специалистов по ручному тестированию(ни в коем случае не хочу обидеть ваших аналитиков)…
Привет. Судя по всему, вы используете старую (v2) версию utPLSQL, она давно уже не поддерживается. Я призываю вас посмотреть в сторону новой версии utPLSQL V3 (текущая 3.1.7) — utPLSQL.org. В ней масса новых возможностей, таких как подсчёт coverage, интеграция с CI, различные способы запуска, интеграция с SQL Developer, а в ближайшее время Фреймворк получит нашивную поддержку в Toad. Вы сможете гораздо более гибко управлять запуском тестов, получать расширенную информацию о причинах и местах ошибок в тестах.
Так случилось, что я — один из авторов utPLSQL v3, так что могу подсказать, рассказать о новых возможностях и ответить на вопросы.
Так случилось, что я — один из авторов utPLSQL v3, так что могу подсказать, рассказать о новых возможностях и ответить на вопросы.
Доброго времени суток!
Рад видеть в блоге автора utPLSQL)
В рамках системы лояльности мы действительно используем utPLSQL версии 2.3.1. При этом в Спортмастере есть несколько проектов, где с помощью 3-ьей версии пытаются организовать автоматическое тестирование.
Лично мы видели более продвинутые версии utPLSQL, проанализировали возможности и пришли к выводу, что в условиях нашего проекта преимуществ для перехода недостаточно.
Безусловно, отличий в 3-ьей версии немало. В первую очередь, хороша идея с определением метаданных о тестах (группы, правила и прочее) на уровне спецификации тестовых пакетов. Очень много сделано в плане интеграций с различными внешними компонентами.
Но
1) Вопрос о том, что проверяется автотестами не решён. Обычная реляционная структура (тестовый пакет-тест-тесткейс-группа тестов) существенно наглядней и удобнее в управлении, чем настройки на уровне спецификаций пакетов. Хотя нам и приходится тратить время на заполнение метаданных. Можно конечно было бы написать представление для utPLSQL, которое на основе парсинга настроек тестовых пакетов сформирует подобную структуру, но данный подход имеет свои минусы.
2) Запуск автотестов в 3-ьей версии стал удобней и гибче, но, как я понимаю, он до сих пор не позволяет передавать имя тестовой процедуры без указания пакета.
3) Как показывает практика для нас не актуальна интеграция с приложениями, и пока нет предпосылок для изменения ситуации.
4) Вокруг utPLSQL у нас уже развёрнут свой фреймворк, который мы реализовывали чисто под себя.
Вот и получается, что обновление версии utPLSQL для нас не актуально. Скажу больше, так как основной движок utPLSQL достаточно прост: с помощью динамического sql вызывается конкретная связка пакет-процедура, есть ненавязчивое намерение совсем отказаться от этого решения и перейти на полностью самописный фреймворк.
Рад видеть в блоге автора utPLSQL)
В рамках системы лояльности мы действительно используем utPLSQL версии 2.3.1. При этом в Спортмастере есть несколько проектов, где с помощью 3-ьей версии пытаются организовать автоматическое тестирование.
Лично мы видели более продвинутые версии utPLSQL, проанализировали возможности и пришли к выводу, что в условиях нашего проекта преимуществ для перехода недостаточно.
Безусловно, отличий в 3-ьей версии немало. В первую очередь, хороша идея с определением метаданных о тестах (группы, правила и прочее) на уровне спецификации тестовых пакетов. Очень много сделано в плане интеграций с различными внешними компонентами.
Но
1) Вопрос о том, что проверяется автотестами не решён. Обычная реляционная структура (тестовый пакет-тест-тесткейс-группа тестов) существенно наглядней и удобнее в управлении, чем настройки на уровне спецификаций пакетов. Хотя нам и приходится тратить время на заполнение метаданных. Можно конечно было бы написать представление для utPLSQL, которое на основе парсинга настроек тестовых пакетов сформирует подобную структуру, но данный подход имеет свои минусы.
2) Запуск автотестов в 3-ьей версии стал удобней и гибче, но, как я понимаю, он до сих пор не позволяет передавать имя тестовой процедуры без указания пакета.
3) Как показывает практика для нас не актуальна интеграция с приложениями, и пока нет предпосылок для изменения ситуации.
4) Вокруг utPLSQL у нас уже развёрнут свой фреймворк, который мы реализовывали чисто под себя.
Вот и получается, что обновление версии utPLSQL для нас не актуально. Скажу больше, так как основной движок utPLSQL достаточно прост: с помощью динамического sql вызывается конкретная связка пакет-процедура, есть ненавязчивое намерение совсем отказаться от этого решения и перейти на полностью самописный фреймворк.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Unit-тесты в СУБД — как мы делаем это в Спортмастере, часть вторая