Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Создание системы тестирования с динамическими проверками основанными на конфиге.

json
Теги: #<Tag:0x00007f7b629dbf18>

#1

Коллеги, добрый день. Возникла проблема с построеннием тестовой системы.

Суть:

В общем нужно проверять параметры элемента на сайте ( размер, расположение и т.д). Параметры которые нужно проверять будут приходить в json’е в формате(имя параметра: значение). Заранее известны какие параметры могут быть(весь набор параметров), но не известно какая комбинация прийдет в файле и собственно пока тест не прочитает json мы не знаем какие именно параметры нужно проверить.

Вопрос в чем: существуют ли какие-то известные практики для такого рода задач ? Может кто-то сталкивался с таким, буду благодарен за пример.

Пока из мыслей это смотреть по ключу (имени параметра) и формировать набор проверок в зависимости от ключа и потом передавать их в тест, но не уверен что это лучший путь и я не изобретаю велосипед.


(Mykhailo Poliarush) #2

Ну это в какой-то степени описывает существующую модель построения автоматизации через keyword driven подход. Погуглите

Вот пару картинок с архитектурой (остальные можно найти самостоятельно https://www.google.com/search?site=&tbm=isch&source=hp&biw=1436&bih=751&q=keyword+driven+approach&oq=keyword+driven+approach&gs_l=img.3..0i24k1l2.1580.3296.0.3547.10.3.0.7.7.0.113.306.2j1.3.0…0…1ac.1j2.64.img…0.10.317…0j0i30k1.tAe2E4kWAiI#tbm=isch&q=keyword+driven+architecture&imgrc=_ )

Добавлю еще вот эту ссылку сюда

и вот эту презентацию


(Michael Korolev) #3

Мы для подобных задач используем генераторы тестов и их фрагментов (которые порождают код на языке Robot Framework). В настройках теста (точнее, его параметров - у нас используется свой IDE) указыаем атрибутику для проверок.

Пример (из нашей жизни): есть САП, входные параметры для теста, нужно убедиться, что в результате работы теста вход правильно разложился по интерфейсным элементам САПа. Для этого про эти интерфейсные элементы мы храним (в IDE) последовательность команд “как сфокусироваться на контроле” и “как прочитать его значение”. Тогда наш генератор в конец теста прописывает стандартные проверки типа “входное значение равно ли тому, что получится после фокусировки на элементе и взятии его значения”.

Тесты тем самым упрощаются - достаточно описать интерфейс (который меняется, но не так часто).

За счет текстового характера робота генераторы получаются архи простыми. Мы на этот путь встали (у нас тесты полностью генерятся из IDE), пока нравится…