Я всегда работал один, и мой метод тестирования обычно компилируется очень часто и следя за тем, чтобы изменения, которые я сделал, работали хорошо и исправляли их, если они этого не делают. Тем не менее, я начинаю чувствовать, что этого недостаточно, и мне любопытно, какие стандартные тесты существуют.
Может кто-нибудь, пожалуйста, расскажите мне об основных тестах, простой пример каждого и о том, почему он используется/что он тестирует?
Спасибо.
У разных людей есть несколько разные представления о том, что представляет собой тест, но вот несколько идей о том, что я думаю, что каждый термин означает. Обратите внимание, что это сильно смещено в сторону кодирования на стороне сервера, как это я делаю:)
Unit test
A unit test должен тестировать только одну логическую единицу кода - обычно один класс для всего тестового примера и небольшое количество методов в каждом тесте. Единичные тесты (в идеале) небольшие и дешевые для запуска. Взаимодействия с зависимостями обычно изолируются с помощью тестового двойника, такого как макет, подделка или заглушка.
Интеграционный тест
Тест интеграции проверит, как работают разные компоненты. Внешние службы (те, которые не являются частью области проекта) все еще могут быть обмануты, чтобы обеспечить больший контроль, но все компоненты самого проекта должны быть реальными. Тест интеграции может протестировать всю систему или некоторое подмножество.
Системный тест
Системный тест похож на тест интеграции, но также и на реальные внешние службы. Если это автоматизировано, обычно система настраивается на известное состояние, а затем тестовый клиент работает независимо, делая запросы (или что-то еще), подобные реальному клиенту, и наблюдает за эффектами. Внешние сервисы могут быть производственными или настроенными только в тестовой среде.
Тест-тест
Это похоже на системный тест, но с использованием производственных услуг для всего. Они периодически запускаются, чтобы отслеживать работоспособность вашей системы.
Приемочный тест
Это, вероятно, наименее четко определенный термин - по крайней мере, на мой взгляд; он может значительно различаться. Обычно это будет довольно высокий уровень, например, системный тест или интеграционный тест. Приемочные тесты могут быть указаны внешним лицом (стандартная спецификация или заказчик).
Черный ящик или белый ящик?
Тесты также могут быть тестами "черного ящика", которые когда-либо касаются публичного API или тестов "белого ящика", которые используют некоторые дополнительные знания, чтобы облегчить тестирование. Например, в тесте с белым ящиком вы можете знать, что какой-либо внутренний метод используется всеми общедоступными API-методами, но его легче проверить. Вы можете проверить множество угловых случаев, вызвав этот метод напрямую, а затем выполните меньшее количество тестов с открытым API. Конечно, если вы разрабатываете публичный API, вы, вероятно, должны разработать его, чтобы его легко тестировать, но он не всегда так работает. Часто приятно иметь возможность протестировать один маленький аспект в изоляции остальной части класса.
С другой стороны, тестирование черного ящика обычно менее хрупкое, чем тестирование белого ящика: по определению, если вы проверяете только то, что API гарантирует в своих контрактах, тогда реализация может меняться так же, как и без тестов меняется. С другой стороны, тесты с использованием белого ящика чувствительны к изменениям в реализации: если внутренний метод изменяется тонко или, например, получает дополнительный параметр, тогда вам нужно будет изменить тесты, чтобы это отразить.
Все сводится к равновесию, в конце - чем выше уровень теста, тем вероятнее, что он будет черным ящиком. С другой стороны, модульные тесты могут включать в себя элемент тестирования белого ящика... по крайней мере, по моему опыту. Есть много людей, которые отказываются вообще использовать тестирование белого ящика, только когда-либо проверяют публичный API. Это кажется более догматичным, чем прагматичным для меня, но я тоже вижу преимущества.
Запуск
Теперь, когда вам нужно идти дальше - модульное тестирование, вероятно, лучше всего начать. Вы можете написать тесты до того, как вы разработали свой класс (тестовое развитие) или примерно в одно и то же время или даже через несколько месяцев (не идеально, но там много кода, который не имеет тестов, но должен), Вы обнаружите, что некоторые из ваших кодов более восприимчивы к тестированию, чем другие... две важные концепции, которые делают возможным тестирование (IMO), - это инъекция зависимостей (кодирование на интерфейсы и предоставление зависимостей вашему классу, а не предоставление им экземпляров этих зависимостей сами) и тестовые двойники (например, фальшивые фреймворки, которые позволяют вам протестировать взаимодействие или поддельные реализации, которые все делают простым способом в памяти).
Я бы предложил прочитать, по крайней мере, книгу об этом, так как домен довольно большой, и книги, как правило, лучше синтезируют такие понятия. Например. Очень хорошая основа: Тестирование тестирования программного обеспечения во всем жизненном цикле разработки программного обеспечения (2007)
Я думаю, что такая книга может лучше объяснить все, чем некоторые из примеров контекста, которые мы могли бы разместить здесь.
Привет... Я хотел бы добавить к тому, что отвечает Jon Skeet Sirs.. На основе тестирования белого ящика (или структурного тестирования) и тестирования черного ящика (или функционального тестирования) ниже приведены другие методы тестирования в каждой соответствующей категории:
Стресс-тестирование
Это используется для проверки объемных объемов данных в системе. Больше, чем обычно требует система. Если система может выдерживать эти тома, она, безусловно, может принимать нормальные значения.
например.
Может быть, вы можете принять условия переполнения системы, например, пытаться вывести больше, чем доступно в вашем банковском балансе, не должно работать, и выход на максимальный порог должен работать.
Используется, когда
Это может быть в основном использовано, мы не уверены в том, какие объемы могут обрабатываться вашей системой.
Тестирование выполнения
Готово, чтобы проверить, насколько опытная система.
Например
Рассчитать время обработки транзакций.
Используется, когда: В начале процесса разработки, чтобы убедиться, что критерии эффективности выполнены или нет.
Тестирование восстановления
Чтобы узнать, может ли система восстановить исходную форму после сбоя.
например.
Очень распространенный, например, в повседневной жизни - это восстановление системы, присутствующее в ОС Windows. У них есть точки восстановления, используемые для восстановления, как хорошо известно.
Используется, когда:
Когда пользователь чувствует, что приложение, критичное для него в этот момент, перестало работать и должно продолжать работать, для чего он выполняет восстановление.
Другие типы тестирования, которые вы могли бы найти, включают: -
Тестирование операций
Тестирование соответствия
Тестирование безопасности
Проверка требований
Регрессионное тестирование
Тестирование ошибок при обработке
Тестирование с поддержкой вручную
Межсистемное тестирование
Контрольное тестирование
Параллельное тестирование
Существует очень хорошая книга под названием "Эффективные методы тестирования программного обеспечения" Уильяма Перри из Института обеспечения качества (QAI), который, я бы предложил, должен быть прочитан, если вы хотите углубиться в w.r.t. Тестирование программного обеспечения.
Более подробно о вышеупомянутых типах тестирования, несомненно, будет доступно в этой книге.
Существуют также две другие очень широкие категории тестирования:
Ручное тестирование. Это делается для пользовательских интерфейсов.
Автоматическое тестирование. Тестирование, которое в основном включает в себя тестирование или тестирование белого ящика через инструменты тестирования программного обеспечения, такие как Load Runner, QTP и т.д.
Наконец, я хотел бы упомянуть конкретный тип тестирования под названием
Исчерпывающее тестирование
Здесь вы пытаетесь проверить все возможные условия, отсюда и название. Это, как можно было бы заметить, было бы очень неосуществимым, так как количество тестовых условий могло быть бесконечным.
Во-первых, существуют различные тесты, которые можно выполнить. Вопрос в том, как организовать его. Тестирование - это большой и приятный процесс.
Начать тестирование с помощью 1.Smoke Testing. После того, как вы пройдете, продолжите тестирование функциональности. Это основа тестирования. Если функциональность работает нормально, 80% тестирования выгодно.
2. Теперь продолжайте тестирование интерфейса пользователя. AS порой Пользовательский интерфейс - это то, что привлекает Клиента больше, чем функциональность. Это внешний вид, который клиент привлекает к нему больше.
3. Теперь его время, чтобы посмотреть на ошибки Косметики. Как правило, эти ошибки игнорируются из-за ограничений по времени. Но они играют важную роль в зависимости от найденной страницы. Ошибка орфографии становится майорой при обнаружении на экране Splash или вашей целевой странице или самом имени приложения. Следовательно, их нельзя игнорировать.
4.Do проводить тестирование совместимости. i, e Тестирование в разных браузерах и версиях браузера. Могут быть устройства и ОС для реагирующих приложений.
Счастливое тестирование:)