Структура кода для непрерывного тестирования

Я строю конвейер компакт-диска. Я планирую автоматическое тестирование. Я планирую проводить тестирование UI, WebService, Security, Perf. У меня вопрос о структуре кода. Так что я планирую иметь тесты в одном и том же репо, как и код, а затем иметь отдельные репозитории для основных тестовых фреймворков, например.Структура кода для непрерывного тестирования

Repo Продукт

Код продукта (Проект)
Интеграционные тесты (проект)
Функциональные/e2e тесты (проект)
- тесты UI (пакет)
- WebSvc Тесты (Пакет)
- Perf Tests (Package)
- Sec.Tests (пакет)

Repo Test Ядро

UI Test Framework Code (проект)
WebSvc Test Framework Code (проект)
Перф Test Framework Code (Проект)
Секционный код испытания (проект)

У вас есть проблемы с этой структурой? Любые другие идеи? Также я немного расплывчатый о том, что идет в тестах интеграции и в проектах функциональных тестов (например, тесты WebSvc могут быть частью обоих). И где проходят приемочные испытания (функциональные или интеграционные)? Будет здорово, если кто-то может указать на некоторые примеры репозиториев или статей об этом.

Thanks

источник

2016-05-12 user2666282

Примечание: Я бы предположил, что * приемочные испытания * исходят от ваших деловых людей; таким образом, вы, вероятно, хотите сделать свою жизнь максимально простой. Кроме того ... Я не уверен, что SO - хорошее место для такого широкого вопроса. Особенно вопрос для ресурсов вне сайта, безусловно, «отключен» от переполнения стека. Так что не удивляйтесь, если придут нисходящие потоки. – GhostCat

Спасибо - можете ли вы объяснить, что вы имеете в виду, когда говорите, чтобы сделать их жизнь легкой? Вы имеете в виду иметь собственный проект? – user2666282

Я имею в виду: если вы просите не IT-людей внести существенный вклад в ИТ-проект (и это то, что «тесты при приеме клиентов» по существу) ... тогда просто попробуйте понять их навыки и потребности. В идеальном случае дело только с одной платформой, и все, что им нужно для их работы, есть. Никаких сложных настроек не требуется ... таких вещей. – GhostCat

Я нахожу эту структуру несколько раздражающей.

Из предлагаемой структуры я вычитаю, что вы хотите создать свои собственные тестовые рамки. Это звучит для меня необычно, особенно если вы хотите написать 4 из них.

С другой стороны, вы помещаете их в один и тот же репозиторий, поэтому они, похоже, тесно связаны друг с другом. Опять же: не обязательно плохо/неправильно, но действительно неожиданно.

Поскольку я не могу найти подсказки в вашем вопросе, это дает веские основания иметь отдельные репозитории, поэтому я бы рекомендовал использовать только один, предполагая, что ваши «тестовые сценарии» - это просто утилиты для тестирования ваших основной проект.

Основное правило - это то, что меняется вместе, должно идти вместе (в одном хранилище). Все остальное делает разработку действительно громоздкой: измените A, установите, измените B, запустите, отлаживайте, повторяйте, вместо изменения, запускайте, отлаживайте, повторяйте

Поскольку вы упомянули, что вы не совсем понятны, что будет, где я буду рекомендовать следующие:

Начните с одного проекта. Напишите ВСЕ тесты в тестовом каталоге этого проекта. Соблюдайте, есть ли у вас проблемы. Если так приспособиться.Вещи, которые вы могли бы испытать, что извлечение триггера проектов:

Тестов работать медленно, и вы хотите, чтобы запустить их отдельно
тестов необходимо развернутое приложение, поэтому они должны работать после сборки и установок все остальное
тестов в разных модулях требуется доступ к коду, который не должен жить в основных проектах, поэтому он может оказаться в модуле с кодом поддержки тестирования

источник

2016-05-12 11:14:24

Спасибо, Дженс. Во-первых, почему вы думаете, что его рыбный напишет 4 рамки (учитывая, что они тестируют разные вещи)? Также, что я получаю от вашей предлагаемой структуры кода, каждая из четырех фреймворков должна идти в свои собственные репозитории - правильно? Но тогда, когда вы говорите один репо, я немного смущен, так как хочу, чтобы рамки были раздельными (потому что они понадобятся для тестирования других проектов). – user2666282

4 testframeworks звучат подозрительно для меня, потому что а) есть сотни фреймворков. Зачем писать новый? б) Написание 1 рамки - это большая работа. Вы уверены, что можете обрабатывать 4? Если вы собираетесь писать 4 независимые рамки, у них должно быть свое собственное репо. За исключением случаев, когда они тесно связаны. –

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

Структура кода для непрерывного тестирования

ответ

Смежные вопросы