Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Эвристики для дебага интеграционных проблем
02.10.2019 00:00

Автор: Санджит Хохар (Sunjeet Khokhar)
Оригинал статьи
Перевод: Ольга Алифанова

Выдающиеся тестировщики, с которыми я имел счастье сотрудничать, не просто "сообщали, что там пожар" – они очень хорошо умели расследовать и сообщать –

  • Как долго горит
  • Каков масштаб бедствия
  • Какие области затронуты, а какие нет
  • Какова природа бедствия
  • Когда оно началось
  • Когда мы проверяли это последний раз
  • Что могло быть причиной
  • Что мы можем впредь сделать лучше, чтобы найти ответы на вышеуказанные вопросы, когда начнется следующий пожар.

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


Исходя из своего опыта тестирования мульти-технологичных интегрированных систем, я составил список общих эвристик, которым я пользуюсь для исследования и поиска  информации, помогающей в дебаге и вносящей вклад в выявление исходной причины проблем конечного пользователя.

Эвристики "сверху вниз"

Под "сверху вниз" в этом контексте я понимаю дебаг того стека системного компонента, где проклюнулся симптом.

Цель тут – задавать вопросы, чтобы выяснить, лежит ли исходная причина в вертикальном срезе архитектуры. Если это не так, то мы перейдем ко второму набору эвристик (то есть к интеграции этого системного компонента с другими компонентами архитектуры).

  • Повторяемость симптомов. Можно ли систематически воспроизвести проблему через интерфейс? Какие комбинации браузеров и платформ лучше всего подходят для воспроизведения симптома?
  • API-трафик для стека. Какие конечные точки API вызываются интерфейсом стека, когда происходит ошибка? Отвечают ли они? Что говорят инструменты разработчика в браузере (или другие методы) о структуре запроса и ответе при возникновении ошибки? Вызовите конечную точку API напрямую, с той же точно структурой запроса, и сравните ответ с ответом, полученным через интерфейс. Есть ли ошибки в консоли инструментов разработчика? Связаны ли они? Как вы это узнали?
  • Транзакции базы данных внутри стека. В какие таблицы API должен вносить данные? В какие поля? Правильно ли наполнены эти таблицы/поля? Актуальны и верны ли определения схемы базы данных? Если вызывается сохраненная процедура, вызывается ли она на самом деле, как вы узнаете об этом? Логируются ли ошибки API/базы данных в базе? Если да, то есть ли ошибки в логах во время возникновения ошибки в интерфейсе пользователя? Если нет, вы должны ратовать за постоянное логирование ошибок для облегчения дебага.
  • Последняя рабочая версия стека. В какой версии стека эта ошибка не возникала? Откатите стек к этой версии, теперь ошибка воспроизводится? Если нет, проведите совместную оценку изменений, осуществленных с тех пор. Есть ли у вас автотесты, сообщающие о статусе всех версий между рабочей и нерабочей? Просматривая эти проверки или меняя по одной переменной за раз вручную, можете ли вы точно сказать, с какой версии стека проблема начала появляться?

Эвристики архитектуры "из конца в конец".

Что ж, прогон наших проверок сверху вниз по стеку не привел к успеху, и теперь нужно исследовать интеграционные точки и другие компоненты системы, с которыми взаимодействует ваше приложение.

  • Поток данных и события на интеграционных точках. Есть ли у вас диаграмма архитектурного решения, подтверждающая, с какими компонентами системы общается ваш стек? Можете ли вы ее нарисовать? Можете ли вы выяснить, каких данных или событий ваше приложение ожидает от системных компонентов, с которыми оно интегрируется, в момент возникновения ошибки? Получает ли ваше приложение ожидаемые данные? В правильном ли они формате? Можете ли вы проверить, какие данные пишутся в другие компоненты системы при возникновении ошибки? Как вы узнаете, что это действительно происходит? Есть ли логи, подтверждающие ваши ответы? Если их нет, боритесь за постоянное логирование ошибок.
  • Последняя рабочая версия архитектуры. Знаете ли вы последние рабочие версии (в которых не возникала ошибка) всех интеграционных точек и системных компонентов? Можно ли откатить всю архитектуру к рабочей версии? Есть ли у вас автотесты, сообщающие о статусе всех компонентов между рабочими и нерабочими копиями архитектуры? Просматривая эти проверки (или вручную), можно ли выявить, в какой версии или при каком изменении компонента/точки интеграции начала возникать ошибка?
  • Полнота архитектуры. Полна ли архитектура, все ли компоненты и точки интеграции отвечают? Есть ли логи, подтверждающие (или отрицающие), что в системе нет отсутствующих компонентов или нерабочей точки интеграции? Если их нет, обсудите с системным архитектором, как можно улучшить ситуацию для упрощения дебага.
  • Нефункциональная/времязависимая деятельность в архитектуре. Есть ли какие-либо ресурсоемкие (CPU, память, диск, ввод-вывод) процессы, запущенные или стартующие в другой части архитектуры в момент возникновения проблемы? можно ли отслеживать ресурсы компонентов и точек интеграции? Как вы узнаете, что эти процессы завершились или зависли? Если это нельзя сделать, куда обратиться за подтверждением отказа этих процессов или задач? Нет ли таймаутов – не ожидает ли какой-либо системный компонент ответа другого, не получая его? Есть ли логирование этих моментов? Если нет, то вы уже знаете, что делать :-)