Как отслеживать тестирование производительности

Question

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

• Есть много копий разных сборок
  • Первоначально выпущенные сборки
  • Официально выпущенные исправления
  • Созданные мною сборки, содержащие дополнительные исправления.
  • Созданные мною сборки, содержащие дополнительное ведение журнала диагностики или трассировку.
• Есть много патчей базы данных, некоторые из вышеперечисленных сборок зависят от применяемых определенных исправлений базы данных.
• Существует множество различных уровней ведения журнала., на разных уровнях (ведение журнала приложений, статистика производительности приложений, профилирование SQL-сервера)
• Есть много разных сценариев, иногда полезно протестировать только один сценарий, иногда мне нужно протестировать комбинации разных сценариев.
• Нагрузка может быть разделена между несколькими машинами или только одна машина
• Данные, присутствующие в базе данных, могут меняться, Например, некоторые тесты могут проводиться с использованием сгенерированных данных, а затем с данными, взятыми из действующей системы.
• После каждого теста необходимо собрать огромное количество потенциальных данных о производительности., например:
  • Множество различных типов ведения журналов для конкретных приложений.
  • Трассировки SQL Profiler
  • Журналы событий
  • DMV
  • Счетчики монитора производительности
• Размер базы данных составляет несколько ГБ. поэтому там, где я бы использовал резервные копии для возврата к предыдущему состоянию, я склонен применять изменения к любой базе данных, присутствующей после последнего теста, из-за чего я быстро теряю контроль над происходящим.

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

В то же время я трачу непропорционально много времени на запись всех этих деталей.

Я рассматривал одну вещь: использовать сценарии для автоматизации сбора данных о производительности и т. д., но я не был уверен, что это такая уж хорошая идея: мало того, что это время тратится на разработку сценариев вместо тестирования, но ошибки в моих сценариях могут привести к тому, что я потерять контроль над вещами еще быстрее.

Мне нужны советы/подсказки о том, как лучше управлять тестовой средой, в частности, как найти баланс между сбором все и на самом деле проходить какое-то тестирование с риском пропустить что-то важное?

Answer 1

Очень хорошая идея — написать сценарий сбора тестовых параметров + среды.Если вы проводите тестирование в течение нескольких дней, а написание сценария занимает день, это время потрачено не зря.Если через день вы увидите, что это не закончится в ближайшее время, переоцените и, возможно, прекратите следовать в этом направлении.

Но вы обязаны попробовать это ради себя.

Answer 2

Я склонен согласиться с @orip: написание сценариев хотя бы для части вашей рабочей нагрузки, скорее всего, сэкономит вам время.Вы могли бы подумать о том, чтобы спросить, какие задачи отнимают больше всего времени с точки зрения вашего труда и насколько они поддаются автоматизации?Скрипты особенно хороши в сборе и обобщении данных — обычно гораздо лучше, чем люди.Если данные о производительности требуют тщательной интерпретации с вашей стороны, у вас могут возникнуть проблемы.

Преимущество написания сценариев для некоторых из этих задач состоит в том, что вы можете затем проверить их вместе с исходным кодом/исправлениями/ветвями, и вы можете обнаружить, что получаете выгоду от организационной структуры сложности вашей системы, а не пытаетесь преследовать ее, как вы делаете сейчас.

Answer 3

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

Если вам действительно нужна описанная вами сложность, я бы рекомендовал создать простую базу данных, которая позволит вам запрашивать имеющиеся у вас многомерные результаты.Наличие столбца для каждого из важных факторов позволит вам задавать вопросы, такие как «Какая конфигурация тестирования имела самую низкую дисперсию в задержке?» и «Какая тестовая база данных позволила повысить большинство ошибок?».Я использую sqlite3 (вероятно, через оболочку Python или плагин Firefox) для такого рода облегченной коллекции, поскольку он позволяет снизить затраты на обслуживание и позволяет избежать слишком сильного нарушения тестируемой системы, даже если вам нужно запустить та самая коробка.

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