Top.Mail.Ru
Разработка
Борьба за робастность системы сценарного, регрессионного и нагрузочного тестирования 1С
10 апреля
11.45-12.25
Зал 3

1. Разнообразные источники сбоев и шума (некорректные данные, обновления кода исследуемой базы, коллизии многопоточной работы, влияние наблюдателя, ошибки тестирующей оснастки и пр.) влияют на валидность, сроки и стоимость тестов

2. Способы повышения робастности системы тестирования на примере гибридной Python+1С системы, и обратная сторона решений

2.1. Неинвазивность - снимает целые классы проблем, но требует внешнего не-1С-кода движка (который надо поддерживать) и веб-клиента 1С

2.2. "Консультант-френдли" хранение и управление тестом из 1С - возможность сохранять сценарии, доступность создания тестов для не-программистов, но снова необходимость поддерживать движок, и все равно это абстракция, хотя и проще, чем Gherkin

2.3. Распределенные стартеры-агенты - снимаем зависимость от ограничений терминального сервера и RDP-сессии, но надо делать оркестрацию

2.4. Снижение перфекционизма при старте и финише - работа стартует и завершается, но у заказчика появляются вопросы

2.5. Хоткеи и "Умные локаторы" - действия гарантированно выполняются, но распухает глоссарий

2.6. Промежуточный сбор логов - не теряются логи при аварии агентов, но это шум

2.7. Аналоги "Goto" в сценариях - обходим ошибки (в данных, в многопотоке), но "возвращаемся к программированию"

3. Вывод. Учим систему выполнять задачу вопреки обстоятельствам, а не благодаря идеальным условиям