Ответ 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 позволит вам написать автоматизированный тест, который проверяет что-то конкретное... как проверка на домашнюю страницу. Вы должны написать отдельный тест, чтобы пользователь мог видеть все его/ее сообщения. Другой - для проверки уведомлений. И так далее.