Что такое тестовая проводка?

Ответ 1

Несколько широких вопросов есть, попытайтесь ответить на основании моего опыта.

Подумайте о Test Harness как "enabler", который фактически выполняет всю работу (1) выполнение тестов с использованием (2) тестовой библиотеки и (3) генерации отчетов. Это потребует, чтобы ваши тестовые сценарии были разработаны для обработки различных (4) тестовых данных и (5) тестовых сценариев. По сути, когда тестовая проводка установлена ​​и подготовлены предварительные данные (например, подготовка данных), кто-то должен иметь возможность щелкнуть кнопку или запустить одну команду для выполнения всех ваших тестов и создания отчетов.

Испытательный жгут - это, скорее всего, коллекция разных вещей, которые делают все вышеизложенное. Если вы написали модульные тесты при разработке своего приложения, это будет частью тестового жгута. У вас также есть другие тесты для функциональности вашего приложения, например: пользователь регистрируется на сайте, видит панель избранного, последние сообщения и уведомления. Затем вы добавляете "бегун" видов, которые проходят через все ваши " тестовые сценарии" и запускают их (вместо того, чтобы выполнять тесты по одному за раз). Если кажется, что тестовая упряжка скорее представляет собой концептуальную коллекцию, чем отдельную часть программного обеспечения, то вы понимаете это правильно: -)

Теперь мой вопрос в том, в чем разница между тестовым случаем и тестом script?

Простой, но не совсем правильный ответ: A Test Case определяет цели тестирования, описание, предварительные условия, этапы (описательные или конкретные), ожидаемые результаты. A Тест Script был бы фактическим автоматическим script, который вы выполняете для выполнения этого теста. Это в контексте автоматизации. И это меняется. Много.

Какие сертификаты, такие как ISTQB, определяются как тестовые сценарии, обычно называются тестовыми примерами в некоторых компаниях и странах. В других случаях тестовые примеры переворачиваются с помощью тестовых сценариев при обращении к ручному тестированию (когда этапы подробно описаны, но не являются частью жгута автоматизации). Другие говорят, что тестовые сценарии исключительно означают автоматические тесты. С другой стороны, можно также утверждать, что несколько тестов можно объединить в тесте script и наоборот. Таким образом, возникает вопрос, как подходит процедура тестирования?

A тестовая разработка может иметь: "Процедуры тестирования, тестовые сценарии, тестовые примеры, тестовые наборы данных, тестовые сценарии для использования в тестовом программном обеспечении."

Если вы предполагаете отношение > (больше/коллекция), как бы вы связали это? Риторический вопрос - который зависит от того, где вы работаете, кто ваш клиент и т.д. Лучше всего определить его со своими коллегами/клиентами и согласиться на понимание терминов, а не определение. В настоящее время я тестирую script= автоматический script на основе ранее существующего ручного тестового сценария или сценария тестирования.

Кроме того, как вы используете программное обеспечение для тестирования различных функций AUT?

Вы пишете разные тесты для тестирования разных вещей. Каждый тест выполняет определенные действия и проверяет, соответствует ли результат AUT, что вы ожидали - If displayed_value == expected_value. Например, входной файл можно было использовать для предоставления данных для тестового списка тестовых имен пользователей и паролей, например. Или запустите один и тот же тест с разными данными - войдите в систему как другой пользователь с разными сообщениями и т.д.

Взгляните на RobotFramework и Selenium. Рамочный тест робота (написанный в текстовых или html файлах) в сочетании с библиотекой Selenium позволит вам написать автоматизированный тест, который проверяет что-то конкретное... как проверка на домашнюю страницу. Вы должны написать отдельный тест, чтобы пользователь мог видеть все его/ее сообщения. Другой - для проверки уведомлений. И так далее.

Ответ 2

тестовая жгут: тестовая среда, состоящая из заглушек и драйверов, необходимых для выполнения теста.

Испытательные жгуты и заглушки будут использоваться для репликации отсутствующих элементов (компоненты, еще не включенные в тесты или внешние системы). Часто, когда выполняется мелкомасштабное Интеграционное тестирование нескольких модулей или компонентов, необходимо разработать или импровизировать методы и инструменты, чтобы получить тестовые данные для тестируемых компонентов. Это часто называют испытательным ремнем безопасности. Из-за необходимости понять технические требования, необходимые для создания тестового жгута, это тестирование почти всегда выполняется командой разработчиков.

Испытательный жгут может облегчить тестирование компонентов или части системы путем имитации среды, в которой будет работать этот тестовый объект. Это может быть сделано либо потому, что другие компоненты этой среды еще недоступны, а заменены заглушками и/или драйверами или просто обеспечивают предсказуемую и контролируемую среду, в которой любые ошибки могут быть локализованы для тестируемого объекта. Обычно это программы на заказ, созданные разработчиками для помощи в процессе тестирования. Если они используются в зрелой организации, вполне возможно, что эти жгуты будут считаться "тестовыми активами и подлежат контролю версий и управлению конфигурацией".

Ответ 3

Тестовые жгуты содержат всю информацию, необходимую для компиляции и запуска теста. Это включает в себя тестовые примеры, исходные файлы под тестированием, заглушки и настройки конфигурации порта развертывания (TDP).

Ответ 4

Test Harness - это совокупность всех элементов, необходимых для тестирования программного обеспечения на уровне устройства, модуля, приложения или системы и предоставляет механизм для выполнения теста. Каждый элемент, такой как входные данные, параметры теста, тестовый пример, тест script, ожидаемые выходные данные, тестовый инструмент и отчет о результатах теста являются частью тестового жгута.