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

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

  • There are many copies of different assemblies
    • Orignally released assemblies
    • Официально выпущенные исправления
    • Сборки, которые я создал, содержащие дополнительные дополнительные исправления
    • Сборки, которые я создал, содержащие дополнительное ведение журнала диагностики или трассировку
  • Существует множество исправлений базы данных, некоторые из вышеперечисленных сборок зависят от применения определенных исправлений базы данных.
  • Существует множество различных уровней ведения журнала на разных уровнях (ведение журнала приложений, статистика производительности приложений, профилирование SQL-сервера).
  • Существует много разных сценариев, иногда полезно протестировать только один сценарий, в других случаях мне нужно протестировать комбинации разных сценариев.
  • Нагрузка может быть разделена между несколькими машинами или только одной машиной.
  • Данные, присутствующие в базе данных, могут изменяться, например, некоторые тесты могут быть выполнены с использованием сгенерированных данных, а затем с данными, взятыми из действующей системы.
  • There is a massive amount of potential performance data to be collected after each test, for example:
    • Many different types of application specific logging
    • Трассировки SQL Profiler
    • Журналы событий
    • DMV
    • Счетчики производительности
  • База данных имеет размер в несколько гигабайт, поэтому там, где я использовал бы резервные копии для возврата к предыдущему состоянию, я обычно применяю изменения к любой базе данных после последнего теста, что приводит к быстрой потере отслеживать вещи.

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

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

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

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


performance-testing test-environments
person Justin    schedule 09.09.2009    source источник

Ответы (3)


arrow_upward
0
arrow_downward

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

Но вы должны сделать это ради себя, чтобы попробовать это.

person orip    schedule 09.09.2009

arrow_upward
0
arrow_downward

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

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

person DaveParillo    schedule 10.09.2009

arrow_upward
0
arrow_downward

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

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

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

person Mike Burrows    schedule 11.09.2009