Ответ
Виды тестирования классифицируются по различным критериям. Вот ключевые категории:
По объекту проверки:
- Функциональное: Проверка соответствия функциональности заявленным требованиям (например, работа кнопки "Отправить" в форме).
- Нефункциональное: Оценка характеристик системы:
- Нагрузочное/Производительности: Проверка поведения под нагрузкой.
- Безопасности: Выявление уязвимостей.
- Юзабилити: Оценка удобства интерфейса.
По уровню/области:
- Модульное (Unit): Тестирование отдельных функций или классов.
- Интеграционное: Проверка взаимодействия между модулями или системами (например, приложение и БД).
- Системное (End-to-End, E2E): Тестирование полностью собранной системы.
По времени проведения и целям:
- Дымовое (Smoke): Базовая проверка работоспособности ключевых функций после сборки.
- Регрессионное: Проверка, что новые изменения не сломали существующий функционал.
- Приемочное (UAT): Финальная проверка заказчиком перед выпуском.
Пример модульного теста на Java (JUnit 5):
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class CalculatorTest {
@Test
void additionShouldReturnCorrectSum() {
Calculator calculator = new Calculator();
int result = calculator.add(2, 3);
assertEquals(5, result, "2 + 3 должно равняться 5");
}
}Ответ 18+ 🔞
О, классификация тестирования, да? Ну, слушай, тут как в армии — всё по полочкам, но если разобраться, то всё просто, как три копейки, блядь.
Вот смотри, есть куча способов потыкать палкой в программу, и их все как-то надо разложить, чтобы не запутаться, как последний мудак. Итак, поехали.
Что мы вообще проверяем, на что смотрим:
- Функциональное: Это когда ты проверяешь, работает ли кнопка так, как задумано. Нажал «Отправить» — письмо улетело. Не улетело? Ну, пидарас шерстяной, пошёл баг репортить. Всё просто.
- Нефункциональное: А вот это уже про то, КАК оно работает. Не «что делает», а «насколько хорошо/быстро/безопасно».
- Нагрузочное: Это когда ты наваливаешь на систему овердохуища пользователей и смотришь, не ляжет ли она с криком «мама, я не могу!». Если ляжет — пиздец, надо чинить.
- Безопасности: Тут ты пытаешься быть маленькой хитрожопой обезьянкой и сломать всё, что можно. Найти дыры, куда можно влезть. Если нашёл — герой, если нет — ну, может, и хорошо.
- Юзабилити: А это когда ты сажаешь бабушку за интерфейс и смотришь, сможет ли она разобраться, или сразу начнёт материться. Если бабушка матерится — дизайнеру пизда.
А теперь — на каком уровне долбим:
- Модульное (Unit): Самый мелкий, ювелирный уровень. Берёшь одну маленькую функцию, одну методичку, и долбишь её со всех сторон в изоляции. Как будто проверяешь, работает ли один винтик в часах. Отдельно от всех остальных.
- Интеграционное: А вот тут начинается веселье. Ты берёшь два этих винтика, скручиваешь и смотришь, не посылают ли они друг друга нахуй при взаимодействии. Приложение пытается поговорить с базой данных — говорит ли база «иди в пизду» или отвечает по-человечески?
- Системное (End-to-End, E2E): Это уже полный цирк с конями. Запускаешь всю систему целиком, как будто ты реальный пользователь: нажал тут, заполнил там, получил результат. Если всё прошло — красота. Если где-то застряло — начинается волнение ебать, потому что искать причину — это пиздец как долго.
И наконец, когда и зачем мы это делаем:
- Дымовое (Smoke): Собрали новую версию? Первым делом — быстренько, по верхам, проверить, а не развалилось ли самое основное. Не горит ли уже? Если дым пошёл — дальше можно не проверять, всё, пизда, билд кривой.
- Регрессионное: Вот это святое, блядь. Сделали новую фичу, пофиксили баг. А теперь надо проверить, не сломали ли мы при этом всё остальное, что уже работало. Потому что бывает так: починил одно — сломал десять. Классика.
- Приемочное (UAT): Это когда уже вроде всё готово, и ты подкатываешь к заказчику или продукт-оунеру со словами «ну что, мудила, принимай работу». Они тыкают, и если их всё устраивает — можно выкатывать. Если нет — ну, ты понял, допиливай.
А вот, смотри, пример того самого модульного теста, про который я говорил. Это Java, JUnit 5. Ничего не трогаем, оставляем как есть:
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class CalculatorTest {
@Test
void additionShouldReturnCorrectSum() {
Calculator calculator = new Calculator();
int result = calculator.add(2, 3);
assertEquals(5, result, "2 + 3 должно равняться 5");
}
}Вот и вся магия. Проверяем, что 2 + 3 даёт 5. Если даёт 6 — значит, кто-то там в калькуляторе накосячил, и ему сейчас впендюрят. Вот так, коротко и без воды, блядь.