Home

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

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

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

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

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

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

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

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

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

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

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

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