svetsmirnova (svetasmirnova) wrote,
svetsmirnova
svetasmirnova

Зачем Support Engineer-у знакомство с исходным кодом

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

Вообще во время собеседований меня постоянно спрашивали что я делаю на текущей работе. Я отвечала, что основная моя обязанность - это верификация баг репортов. Настоящая компания не была исключением. Мы обсудили что такое верификация, как я её делала. А затем они стали спрашивать про мои знания MySQL и знакомство с кодом. Я ответила: "А как же?" И тут они мне задали тот самый вопрос: "А зачем вам нужно знать код, вы же занимались black box testing?" К сожалению в тот день у меня не было хорошего примера зачем нужно знакомство с исходниками. Пример появился буквально на следующий день!

Вообще говоря bug verification - это не всегда black box testing, а просто подтверждение бага любыми доступными способами.

Bug #75706 "alter table import tablespace creates a temporary table"

Фактически это feature request: это значит, что функциональность отсутствует и решение появится только в следующей мажорной версии. То есть это не прям такой серьёзный баг, который нужно верифицировать уже сегодня и чем раньше, тем лучше. Тем не менее подтвердить его нужно. И чтобы его подтвердить возможны варианты:

  1. Brute force. Тот самый black box testing. То есть нужно создать достаточно большую таблицу и сделать ALTER, затем отслеживать создалась ли временная табличка. Минус этого способа очевидный: очень долго, очень много тупой работы и чем быстрее диск - тем большую нужно создавать таблицу. Соответственно возможны варианты, что на моём лаптопе создание временной таблицы можно будет увидеть легко, а на сервере разработчика - уже нет.

  2. Поставить breakpoint в месте, где создаются временные таблицы и отследить его в gdb, например. Но тут уже нужно знать код.

  3. Просто прочитать код.


Способы 2 и 3, на мой взгляд, сильно эффективнее "black box ради black box" способа 1. В данном случае я применила способ 3. Если бы это был баг применила бы способ 2: с ним проще доказать, что баг в наличии.

Пример использования способа 2 попался буквально на днях на новой работе. Это Bug #1452397 "Gaps in Retrieved_Gtid_Set while no gaps in Executed_Gtid_Set" или Bug #76959 "Gaps in Retrieved_Gtid_Set while no gaps in Executed_Gtid_Set". Клиент предоставил relay log файлы, которые приводили к описанному поведению. В принципе когда я поняла почему ошибка происходит достаточно было запустить mysqlbinlog на них и баг репорт был бы готов. Проблема в том, что Percona Server - это fork Oracle MySQL Server и по-хорошему баг нужно было слать и в Oracle тоже. И, как вы понимаете, relay логи клиента Percona я в Oracle послать не могу. Поэтому пришлось придумывать как их создать. Опять-таки, можно было манипулировать максимальным размером логов и посылаемыми запросами из мастера, но при появлении любых дополнительных служебных данных, записываемых в binary log в любой из последующих версий, тест бы поломался и нельзя было бы точно сказать баг ли устранили или просто формат binary log поменяли. Да и долго размер запросов подбирать! Поэтому я применила более эффективный способ: Test Synchronization и DBUG_EXECUTE_IF. Что, опять-таки, без знакомства с кодом MySQL было бы невозможно.
Tags: bugs, job, mysql
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 6 comments