По части творчества и не выделения какого-то вида теста при выполнении эффективного теста, такие мысли. По формальности тестирование может быть:
* по тестам
* исследовательское
* специализированное (профилирование, бенчмарк, например).
Опыт показывает, что в тесте лучше менять только один параметр:
1) Версию системы или настройку и поискать точку деградации/насыщения - нагрузочное
2) Интенсивность повышать до предела - максперф, capacity, ...
3) Количество узлов - масштабируемости, scale
4) Объем данных - объемное
...
Такое тестирование "по тестам" или "по видам". Если тестирование автоматизировано, или система несложная, то так можно.
Если же все вручную (дольше делается, чем автоматизированное), и инженера торопят (времени нет), то можно не делить на виды и делать просто "нагрузку". Сделать запуск, посмотреть на узкие места, и потом решить, что будем менять сегодня - исследовательский подход. Работал в аутсорсе и не в аутсорсе и именно так и тестировал, почти всегда.
Так есть исследовательское тестирование, а есть по тестам. И у того и у другого подхода есть свои плюсы. Исследовательское многие любят, ведь нет формализма. Оно быстрее по скорости нахождения дефектов. В нем смешивается всё: тест на трёх нодах, огромной базе, с нагрузкой выше продуктивной и на 30 часов. Дефектов находится много. Но оно сложнее на самом деле - не знаешь, что ищешь. У меня возникали сложности. Стремлюсь делать простые тесты теперь.
Если время появляется и система стала стабильной. То есть смысл выделить время, разделить на разные виды тестов. И понятно их назвать
