Зачем Support Engineer-у знакомство с исходным кодом
Я недавно сменила работу. Перед тем как это сделать я собеседовалась в несколько компаний и в одной из них мне задали очень интересный вопрос.
Вообще во время собеседований меня постоянно спрашивали что я делаю на текущей работе. Я отвечала, что основная моя обязанность - это верификация баг репортов. Настоящая компания не была исключением. Мы обсудили что такое верификация, как я её делала. А затем они стали спрашивать про мои знания MySQL и знакомство с кодом. Я ответила: "А как же?" И тут они мне задали тот самый вопрос: "А зачем вам нужно знать код, вы же занимались black box testing?" К сожалению в тот день у меня не было хорошего примера зачем нужно знакомство с исходниками. Пример появился буквально на следующий день!
Вообще говоря bug verification - это не всегда black box testing, а просто подтверждение бага любыми доступными способами.
Bug #75706 "alter table import tablespace creates a temporary table"
Фактически это feature request: это значит, что функциональность отсутствует и решение появится только в следующей мажорной версии. То есть это не прям такой серьёзный баг, который нужно верифицировать уже сегодня и чем раньше, тем лучше. Тем не менее подтвердить его нужно. И чтобы его подтвердить возможны варианты:
Пример использования способа 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 было бы невозможно.
Вообще во время собеседований меня постоянно спрашивали что я делаю на текущей работе. Я отвечала, что основная моя обязанность - это верификация баг репортов. Настоящая компания не была исключением. Мы обсудили что такое верификация, как я её делала. А затем они стали спрашивать про мои знания MySQL и знакомство с кодом. Я ответила: "А как же?" И тут они мне задали тот самый вопрос: "А зачем вам нужно знать код, вы же занимались black box testing?" К сожалению в тот день у меня не было хорошего примера зачем нужно знакомство с исходниками. Пример появился буквально на следующий день!
Вообще говоря bug verification - это не всегда black box testing, а просто подтверждение бага любыми доступными способами.
Bug #75706 "alter table import tablespace creates a temporary table"
Фактически это feature request: это значит, что функциональность отсутствует и решение появится только в следующей мажорной версии. То есть это не прям такой серьёзный баг, который нужно верифицировать уже сегодня и чем раньше, тем лучше. Тем не менее подтвердить его нужно. И чтобы его подтвердить возможны варианты:
- Brute force. Тот самый black box testing. То есть нужно создать достаточно большую таблицу и сделать ALTER, затем отслеживать создалась ли временная табличка. Минус этого способа очевидный: очень долго, очень много тупой работы и чем быстрее диск - тем большую нужно создавать таблицу. Соответственно возможны варианты, что на моём лаптопе создание временной таблицы можно будет увидеть легко, а на сервере разработчика - уже нет.
- Поставить breakpoint в месте, где создаются временные таблицы и отследить его в gdb, например. Но тут уже нужно знать код.
- Просто прочитать код.
Пример использования способа 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 было бы невозможно.