Широкие категории, на мой взгляд, будут:
Тестирование черного ящика . Вы не видите код и просто до некоторой степени тестируете вслепую, поскольку то, что находится в приложении или системе, скрыто от вас. Таким образом, в этом случае люди не знают всех случаев ошибок и должны угадывать различные граничные условия, которые могут быть или не быть очевидными, чтобы найти все случаи.
Тестирование белого ящика . Вы действительно видите код и можете проверить, какие пути кода используются, чтобы покрытие кода можно было использовать в качестве метрики, чтобы гарантировать, что вся логика используется в системе. Идея здесь состоит в том, чтобы узнать, как выглядит код, помогающий проводить тесты, чтобы он не был таким загадочным, как тестирование черного ящика.
Тестирование серая коробка - гибрид двух предыдущих.
Пограничные случаи, как правило, могут быть чем-то, что можно увидеть в тестировании белого ящика, поскольку в коде, в котором пишутся тесты, есть различные условия, например, если у вас была программа, которая запрашивает число, и кто-то вводит X, как это обрабатывается должно быть видно где-то в коде.
Общие классификации тестирования будут:
Модульные тесты . Как правило, это самые маленькие тесты, которые тестируют что-то довольно специфическое, например, обрабатывает ли этот метод этот граничный случай? Обратите внимание, что внедрение зависимостей может использоваться здесь для случаев, включающих фиктивные объекты, чтобы уменьшить любые зависимости для тестов.
Интеграционные тесты . Это тесты, в которых подключены несколько компонентов и выполняются тесты, чтобы убедиться, что компоненты работают хорошо. Обратите внимание, что хотя модульные тесты могут работать независимо друг от друга, именно здесь проводится проверка того, насколько хорошо все складывается, поскольку между слоями может возникать недопонимание, из-за которого эти тесты могут быть полезны при обнаружении различных ошибок. Термин « сквозные тесты» используется для интеграционных тестов, где полная цепочка компонентов тестируется от «одной конечной точки приложения к другой» (что бы это ни значило).
Регрессионные тесты . Это будут тесты, выполненные в прошлом, которые будут выполнены снова, чтобы убедиться, что исправленное остается неизменным и ошибки не повторно вводятся в код.
Юзабилити-тесты . Это будут тесты, выполненные для определения того, насколько хорошо конечные пользователи могут работать с программным обеспечением для выполнения различных задач. Где можно что-то автоматизировать, чтобы сделать что-то быстрее или настроить интерфейс так, чтобы что-то было проще в использовании.
Пользовательские приемочные тесты . Это будут тесты, выполненные конечными пользователями, чтобы они из первых рук увидели, как что-то работает, и согласились с тем, что программное обеспечение действительно отвечает бизнес-потребностям, которые запрашивали его в первую очередь.
Функциональные тесты - это все виды тестов, основанные на функциональной спецификации тестируемого программного обеспечения. Это всегда тесты черного ящика.
Тесты производительности, Это будут тесты, выполненные для того, чтобы система могла обрабатывать определенную нагрузку, не становясь слишком медленной. Например, тестирование новой веб-фермы серверов может обрабатывать 100 пользователей, одновременно попадающих на сайт, - это пример теста производительности. Их также можно назвать «нагрузочными тестами» или «стресс-тестами», так как обычно идея состоит в том, чтобы либо довести систему до своего предела, либо убедиться, что система может обрабатывать некоторые прогнозы из другого отдела. Основанием для этих тестов является то, что часто есть множество параметров конфигурации для оптимизации, которые могут потребовать больше, чем небольшую работу, чтобы обнаружить узкие места и решить проблемы с этим. Узким местом здесь может быть память, ввод-вывод, загрузка ЦП или сети, что приводит к тому, что система не реагирует должным образом.
Разработка через тестирование - это методология, которая относится не к конкретному виду тестов, а к тому, что тесты пишутся перед кодом, так что тесты - это то, что движет разработкой, а не поведением , областью или функцией, являющимися некоторыми другими примерами с точки зрения процесс.
Непрерывная интеграция - это практика регулярного запуска некоторых тестов, таких как модульные, интеграционные и регрессионные тесты, так что если изменение нарушает тест, это обнаруживается как можно раньше.