Синтетические vs реальные тестовые данные: плюсы, минусы, подводные камни

[NeverIn]

Представляю какого уровня наняли тестировщика, не справившегося с тестом email. В принципе видимо и разработка была того же уровня.

[Quality_lab]

Это скорее крайний случай. Хотя зачем далеко ходить.
Наша последняя статья: habr.com/ru/post/440486 — там последний коммент от reishi, он отлично отражает подход некоторых компаний к тестированию.
Потому не удивительно, что до сих пор случается после таких «QA инженеров» заходить на проект.

[maxkomp]

Расскажите в комментариях о своих кейсах работы с синтетическими и реальными тестовыми данными. Давайте разберёмся, кого среди нас больше: реалистов или синтетиков?

Сразу скажу, что работаю не с интернет-торговлей, и не с бухгалтерией, а разрабатываю софт для автоматизации промышленных предприятий. Так вот, тут для отладки обязательно надо использовать и то и другое. (можно без хлеба, но лучше с ним)

Вот вам первый «кейс»:
Как правило, в моих проектах компьютер работает не сам по себе. Он управляет какой-то подключенной к нему технологической установкой (станком, линией).

И в состав разрабатываемого софта практически всегда входит программа — эмулятор этой самой технологической установки, или станка. Она воспринимает команды устройству и в ответ генерирует набор тех самых синтетических данных.
Причем обычно сначала разрабатывается именно эмулятор.

Зачем это нужно:
1. Можно отлаживать свой код в спокойной обстановке, а не в цеху (там бывает шумно, жарко, холодно). Бывает, подключенный к компьютеру девайс должен находиться вне помещения. (Тут есть желающие отлаживать софт в Якутии зимой при температуре в минус 45?)
2. С помощью эмулятора можно легко получить такие предельные и запредельные величины, которые в ходе штатной работы системы получиться не должны. Например, датчик температуры воды в магистрали, который обычно выдает величины 10-20 градусов. Как проверить поведение софтины, если внезапно воды в магистрали не окажется? (В принципе, такое имеет право произойти, то есть зимой эта температура запросто может стать отрицательной).
3. Эмулятор позволяет легко и просто моделировать всякие отказы оборудования, поломки и аварийные ситуации. Например, программа посылает команду на закрытие какого-нибудь клапана, а расходомер жидкости, с этим клапаном связанный, спустя какое-то время продолжает показывать поток порядка несколько литров/сек. Это означает, что у нас или клапан не сработал, или еще что-то случилось, но где-то в цеху прямо сейчас льется кислота, причем куда она льется — непонятно! То есть софтина должна зажечь на операторском щите здоровенную красную лампу, и в дополнение к ней включить ревун (вдруг оператор дежурной смены ночью задремал). Причем в жизни эта логика иногда оказывается весьма хитрой и довольно таки не очевидной. Как все эти ситуации проверять на реальном оборудовании? (Проверка исправности сигнализации обычно предусмотрена, но ведь ломать оборудование никто не даст. А тут достаточно мышкой щелкать и спокойно смотреть, что происходит при возникновении той или иной аварии, в разных комбинациях).

То есть, без синтетических данных с эмулятора, как видите, не удастся обеспечить приемлемое покрытие тестами.

Но одним эмулятором тоже обойтись не получается. При отсутствии данных, полученных в ходе «боевой» эксплуатации системы, тоже не получается отловить многие баги и глюки. Причем проверять все надо в комплексе, ибо причина возникновения бага может крыться не только в программном коде.
Было дело, когда неправильное поведение моего софта были вызваны неудачным расположением оборудования на предприятии (дело было на мукомольном комбинате). Один из датчиков (который был довольно чувствителен к вибрационным помехам) оказался смонтирован совсем рядом с ситовейной машиной. (Ну вот представьте себе обычное сито, только через него просеивается больше 10 тонн муки в час). Когда оно работало, там вокруг все ходуном ходило, и датчик, понятно, выдавал нечто несуразное. Самое интересное, что и перенести этот датчик в другое, более спокойное место, не получалось. Пришлось мне допиливать софт, вводить фильтрацию нежелательных помех (уровень которых на порядок превышал уровень полезного сигнала). На этапе разработки и тестирования, ясен перец, такие вещи не приходили в голову никому. (Почему на других мельницах такой проблемы не возникало? Потому что обычно можно было найти более удобное место для установки этого датчика)

Другой «кейс» — когда множественные малопонятные сбои компьютера были вызваны его неправильным подключением к электросети. Местные КИПовцы, не подумавши, подключили промышленный компьютер к той же самой питающей линии, на которой находились несколько довольно мощных (около 20 кВт каждая) машин. Помехи, вызываемые электродвигателями, так лихо пролезали через не самый дешевый ИБП и через блок питания компьютера. (до того мне и в голову не приходило, что такое может быть) А я там всю голову сломал в размышлениях «какого ж хрена программа-то виснет, причем вместе со всей системой?». А там программа была не особо простая: асинхронный ввод-вывод, несколько потоков, всякие там мьютексы с критическими секциями, и вот это все. Естественно, я грешил на свою ошибку в синхронизации потоков, которая могла вызвать «перекрестное ожидание». А обнаружился этот «баг» совсем случайно. (Мне стало интересно, а с чего это мой софт виснет только в те моменты, когда в вашем цеху что-то такое эдакое мощное выключается?).
Поглядел, куда идут кабели… Сказал КИПовцам, чтобы они больше так не делали. Они шустро перебросили питание на другую линию, и случилось чудо — подвисания пропали.

Вот оно как бывает в жизни.

[sokovikova]

Вот это пример, спасибо, очень интересно! Вообще жаль, что в сети не так много информации о тестировании в производстве — все чаще разговор про корпоративные и массовые ИТ продукты (на которые внешняя среда не так сильно влияет). Здесь я бы передала «привет» специалистам, которые тестируют некоторые бытовые датчики пожара, которые воспринимают пыль как дым и во время ремонта срабатывают каждые 15 минут :(

[Stas911]

Работал в банке — там к нашим услугам был анонимизированный дамп прямо с прода. Вот это было удобно, но не совсем безопасно

[rudinandrey]

не совсем безопасно

почему? я видел на соревнованиях по машинному обучению используются банковские данные или например сотовых операторов, и надо было предотвратить на основе этих данных отток клиентов например. Или там нереальные а какие то искусственные данные?

[sokovikova]

А в чем был риск, если не секрет? Не все анонимизировали? Или в самом механизме обезличивания? Мы сейчас на внутреннем проекте тоже анонимизируем информацию о финансовых потоках и адреса электронной почты, а остальные данные накатываем с прода.

[Stas911]

Там база была таблиц на несколько сотен и механизм анонимизации был, так сказать, не идеален — помню, что где-то в недрах базы можно было наткнуться на необработанные данные клиентов.

[Germanjon]

Параллельно же вскрылось, что ранее эту форму уже тестировал другой тестер, потратив на это 7 часов. Почему? Просто он решил прогнать тест по реальным данным 12 сотрудников из штатного расписания и не учёл, что тест по одному сотруднику покрывает все атрибуты, одинаковые для каждого регистрируемого профиля.

В случае единичного тестирования по одному сотруднику, снижается вероятность обнаружить потенциально проблемный участок: юзер без отчества; юзер, родившийся 29 февраля; юзер с двойной фамилией; юзер с несклоняемой фамилией

[sokovikova]

Полностью поддерживаю. Тут как раз без синтетики и наработок/опыта не обойтись. В реальных данных может быть 100 человек со «стандартными» ФИО и датой рождения, адресом и паспортом, а 101й окажется иностранцем без отчества с двойной несклоняемой фамилией, родившийся 29 февраля — и будет как в анекдоте "… Первый реальный клиент заходит в бар и спрашивает, где туалет. Бар вспыхивает пламенем, все погибают." :)

[kentastik]

А где брать реальные данные для нового проекта непонятно :) отсюда и баги с почтами и прочее. Еще я не понял как эти реальные данные появятся, если они не пройдут валидацию и не запишутся в БД.

[sokovikova]

Все зависит от проекта, конечно — в некоторых случаях реальным данным взяться неоткуда, спасет только синтетика. Но, бывает, применимы базы, которые есть в открытом доступе (мы на проектах периодически использовали) — государственные реестры (если это применимо к проекту опять же), базы адресов, товаров, видов деятельности, учреждений и компаний. Если говорить про корпоративную или отраслевую ИС, можно взять данные из реальной деятельности. Например, при тестировании системы для полиграфии мы брали в т.ч. реальные данные по заказам продукции у заказчика. Если заказчика нет, то идешь на сайты покупки/продажи услуг, объявлений :)

[rudinandrey]

в сеть же сливают разные взломанные аккаунты, мне кажется вот их и можно использовать для таких тестов.

[KristinaMyLife]

Спасибо за статью, в моей практике процентов 80% проблем найденных уже на проде были из-за того, что не смогли предугадать такой вариант в тесте, и нет тестировщики были не начинающие и знали систему хорошо. Просто варианты настроек клиента + использование фичи, да много можно чего вспомнить. И чем крупнее система, тем к сожалению чаще такое встречается, тем и хороши canary релизы, с постепенным увеличением охватываемого объема.
И да — данные с прода очень хороши для проверок, к сожалению в тех системах, с которыми я работала их все равно приходилось обфусцировать и опять же есть вопросы к тому, что получалось в итоге обфускации, но как говорится, нет предела совершенству.

[nikandr23]

Логи надо писать нормальные. и анализировать их.