BonBonSlick
@BonBonSlick
Web Developer Trainee

Какие тесты на каких этапах развития проекта наиболее важны?

http://www.softwaretestinghelp.com/types-of-softwa...
https://www.testingexcellence.com/types-of-softwar...

После прочтения, я так понял можно разбить на 2 этапа, если запустить тесты на 4-ом этапе или 3-ем, все в БД слетит ;)
1 - Alpha (dev)
2 - Beta (dev)
3 - Stage (dev, but hosted)
4 - Production

Так вот, по ссылке свыше, 46 типов тестов, однако как я понял их существует более 100+, и немного запутался, какие и когда применять.

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


Есть у меня Unit тест, который проверяет создание юзера. Куда его пихать? И как я понимаю надо еще пол сотни тестов разных типов напилить на регистрацию юзера?)
  • Вопрос задан
  • 172 просмотра
Решения вопроса 2
@kn0ckn0ck
Продюсер
Не знаю как на счет тех 46, но для начала выполните хотя бы обязательную программу:

1. модульные тесты, проверяющие что модуль вообще алё - запускаются перед коммитом или в бранче разработчика;
2. смоук тесты, проверяющие, что сборка вообще алё - запускаются перед мерджем в мастер;
3. интеграционные и функциональные тесты с целью проверки сборки на регресс - запускаются сразу после коммита в мастер;
4. тесты безопасности с целью проверки на типовые уязвимости - запускаются если сборка мастер-ветки прошла предыдущие тесты;
5. нечеткие и ручные тесты, выполняемые перед выкладкой на прод - убеждаемся, что основные сценарии и новая функциональность работают как задумано.

Этого должно хватить на ближайший год, потом спросите про остальные виды тестов :)
Ответ написан
lxsmkv
@lxsmkv
Test automation engineer
Да там все в кучу свалено: тормоз, фара, водитель, права, дорожный знак. Все понятия относящиеся к вождению индивидуального транспортного средства. Бррр..

Есть подходы к тестированию (парадигмы, напр. TDD), есть методики для систематического подхода к покрытию тестами (pairwise, boundary). Есть разделение по стадиям разработки (alpha, beta). Категоризировать и писать определения можно сколько угодно.
Вам нужно проверять работоспособность приложения на регулярной основе. Это, как правило, юнит тесты на сам код, и функциональные тесты на приложение (эмуляция пользователя). Функциональный от слова проверка функции фичи.
Это обеспечивает какую-то степень распознавания регрессий. Ревью кода - тоже тестирование. И когда Вы запускаете программу чтобы убедиться, что то, что Вы написали работает - тоже тестирование. Только вы знаете какие проверки Вам нужнее всего.
Ответье себе на вопрос: "В чем вы хотите каждый день, после каждой сборки, после каждого коммита, быть уверены?" Не надо писать тесты только потому, что все так делают. Надо понять какая Вам от них польза. И все встанет на свои места.
Ведь проблема в чем, приложение растет, и со временем разработчик тестирует только ту часть приложения которую только что написал. А все старое перепроверяется гораздо реже. Так вот автоматизация при систематичном ее применении может Вам в этом помочь.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы