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

Question

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

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

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

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

Одна вещь, которую я рассмотрел, - это использование сценариев для автоматизации сбора данных о производительности и т. Д., Но я не был уверен, что это хорошая идея - не только время потрачено на разработку сценариев вместо тестирования, но и на ошибки в моих сценариях. может привести к тому, что я потеряю связь с вещами еще быстрее.

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Но ты сам должен попробовать.