Какие аспекты системы проверяются в рамках нефункционального тестирования?

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

1. Тестирование производительности (Performance Testing) Тут мы проверяем, не сломается ли всё, если навалится толпа. Как в метро в час пик.

• Нагрузочное тестирование (Load Testing): Это как загнать в систему столько народу, сколько мы ожидаем в реальности. Цель — понять, не упрётся ли всё в потолок и не начнёт ли тормозить так, что волнение ебать.
  • Инструменты: k6, Apache JMeter, Gatling. Взял, настроил, запустил — и смотришь, как система пыхтит.
• Стресс-тестирование (Stress Testing): А это уже сверхреализм. Наваливаем народу овердохуища, пока система не начнёт хрипеть и не накроется медным тазом. Цель — найти самое слабое звено: где первым пиздец наступит — в базе, в памяти или ещё где.
• Тестирование стабильности (Soak Testing): А тут мы систему мучаем не спеша, но долго. Средняя нагрузка, но на протяжении часов или даже дней. Цель — поймать коварные утечки памяти, которые тихой сапой съедают все ресурсы. Система вроде работает, а потом — бац! — и терпения ноль ебать, потому что всё зависло.

Вот, смотри, как это примерно в k6 выглядит, чтоб ты понимал масштаб:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // Плавно нагоняем сотню юзеров
    { duration: '5m', target: 100 }, // Держим их, как на раскалённой сковороде
    { duration: '1m', target: 0 },   // Плавно отпускаем, смотрим, отдышится ли
  ],
};

export default function () {
  const res = http.get('https://api.example.com/data');
  check(res, { 'status was 200': (r) => r.status == 200 });
  sleep(1);
}

2. Тестирование безопасности (Security Testing) Тут мы примеряем роль хитрожопого злоумышленника. Задача — найти дыры, куда можно пролезть.

• Ищем уязвимости из священного списка OWASP Top 10.
• Пробуем всякие инъекции: SQL, XSS — вдруг система проглотит эту хуйню и отдаст все пароли?
• Проверяем, нельзя ли зайти в админку, просто поменяв цифру в адресной строке. Если можно — пидарас шерстяной тому, кто это писал.

3. Тестирование совместимости (Compatibility Testing) А вот это весёлый аттракцион. Надо проверить, будет ли твой шедевр работать не только у тебя на новом Макбуке в Хроме, но и у тёти Маши на Windows XP в древнем IE, или на каком-нибудь левом андроид-смартфоне. Иначе выходит, что вы ходите по охуенно тонкому льду, когда половин пользователей всё плывёт.

4. Тестирование удобства использования (Usability Testing) Тут мы смотрим на систему глазами пользователя, который в жизни не видел твоего интерфейса. Кнопка спрятана так, что её найти — это квест? Шрифт такой мелкий, что глаза сходят с ума? А сможет ли человек, который не видит, пользоваться сайтом? Если нет — это пиздопроебибна с точки зрения доступности.

5. Тестирование надежности (Reliability Testing) И, наконец, главный вопрос: а можно ли на эту штуку положиться? Не отвалится ли она через неделю работы? А если отвалится (например, сервер базы данных), то как быстро и без потерь встанет обратно? Проверка на вшивость, одним словом.

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