Что такое нефункциональное тестирование (Non-functional testing)?

А, слушай, вот эта вся хуйня про нефункциональное тестирование! Это ж самое интересное, блядь, в нашей работе! Ну представь: приложение вроде работает, кнопки жмутся, данные сохраняются. Но стоит на него народу побольше зайти — и оно, сука, ложится как шальной бык, блядь! Или начинает тормозить так, что волосы на жопе шевелятся от нетерпения! Вот именно от этого и спасает нефункциональное тестирование, ёпта!

Оно не про то, что система делает — это и дурак проверит. Оно про то, как она это делает, подлая тварь. Какая от неё польза, если она функционально идеальна, но работает со скоростью пьяного ленивца в сиропе, блядь?

Вот смотри, какие у нас тут главные «как» бывают, на которые надо глаз положить, и не один:

• Производительность (Performance): Это святое, блядь. Тут три кита, на которых всё держится.

  • Нагрузочное (Load): Вот ты сидишь, спокойно такой, один. А мы тебе подкинем сотню-другую таких же, как ты, виртуальных пользователей. И смотрим, не обоснётся ли наша система под этой толпой. Ожидаемая нагрузка, мать её.
  • Стрессовое (Stress): А это когда мы уже не играем в поддавки. Накидываем народу в три раза больше, чем она может выдержать, и смотрим, как она красиво и с какими словами на прощание ляжет. И главное — как потом встанет, когда нагрузку уберём. Выживет — герой. Не встанет — пиши пропало.
  • Объемное (Volume/Soak): А это, блядь, для выносливости. Запускаем тест на сутки, наливаем в базу данных столько, что она пухнет, как удав, съевший слона. И смотрим, не начнёт ли она через 10 часов тихонько срать памятью или дисковым пространством. Медленная смерть, ебать.

• Безопасность (Security): Ну тут всё ясно, как божий день. Не проверишь — придёт какой-нибудь пидарас шерстяной с интернета и вынесет тебе всю базу клиентов, пока ты чай с печенькой жуёшь. Проверяем все эти авторизации, инъекции и прочие радости жизни.

• Удобство (Usability): А вот это, блядь, вообще отдельная песня. Можно сделать функционал гениальный, но такой неудобный, что пользователь через три клика посылает всё нахуй и уходит к конкурентам. Интерфейс должен быть не для гения, а для распиздяя, который пальцем тыкает куда попало. Если он не запутается — красава.

• Совместимость (Compatibility): О, ёперный театр! Это когда твоё творение должно работать и в древнем Internet Explorer, который уже сам себя не помнит, и на телефоне с экраном размером с почтовую марку. А если нет — опять же, в пизду полетят все труды.

• Надёжность (Reliability): Ну это чтобы система не падала каждые пятнадцать минут, как заведённая. Должна работать стабильно, сука, как швейцарские часы, а не как отечественный автомобиль в дождь.

А зачем это всё, спросишь? Да затем, чувак! Можно хоть трижды функционально протестировать, но если сайт грузится полминуты, из него торчат дыры в безопасность, а в Хроме всё плывёт — пользователь скажет тебе одно короткое, но ёмкое слово и закроет вкладку. Нахуй никому не сдался такой «рабочий» продукт.

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

// Псевдоконфигурация для JMeter
Thread Group:
  Number of Threads (users): 100 // Сто виртуальных дебилов, которые будут жать кнопки
  Ramp-Up Period: 30 seconds // Не всех сразу, а подпускаем их толпой за полминуты, как на распродажу
  Loop Count: Forever // Пусть долбят, пока не надоест нам
  // Цель: проверить, выдерживает ли API 100 одновременных запросов.

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