Сообщений в теме: 36

[novak]

Современные операционные системы и так умеют эффективно распараллеливать выполнение процессов при наличии нескольких процессоров или ядер. Зачем виртуализация? Просто запускайте несколько процессов параллельно и всё. Возможно, по каким-то причинам в Вашем случае это невозможно, конечно, но в общем случае -- параллельности можно достичь и без виртуализации.

Если брать достижение параллельности как самоцель - да, это может быть верным. Но в случае тестирования виртуальная машина служит не только в качестве механизма распараллеливания выполнения какой-либо задачи, а ещё и в качестве изолированной среды тестирования. И насколько само приложение, которое тестируется, является реентерабельным - большой вопрос.

[Clauster]

Современные операционные системы и так умеют эффективно распараллеливать выполнение процессов при наличии нескольких процессоров или ядер. Зачем виртуализация? Просто запускайте несколько процессов параллельно и всё. Возможно, по каким-то причинам в Вашем случае это невозможно, конечно, но в общем случае -- параллельности можно достичь и без виртуализации.

Если брать достижение параллельности как самоцель - да, это может быть верным. Но в случае тестирования виртуальная машина служит не только в качестве механизма распараллеливания выполнения какой-либо задачи, а ещё и в качестве изолированной среды тестирования. И насколько само приложение, которое тестируется, является реентерабельным - большой вопрос.

Но это справедливо для нагрузочного тестирования, для функциональных тестов - по барабану, не так ли?

[novak]

Но это справедливо для нагрузочного тестирования, для функциональных тестов - по барабану, не так ли?

В условиях отсутствия выполнения требования реентерабельности и для функционального тестирования будет не по барабану. Если раньше при разработке как тестов, так и приложения не учитывалось и не предполагалось параллельное выполнение - удобнее будет выполнять просто на разных машинах, виртуальных или нет.

[LeshaL]

Но это справедливо для нагрузочного тестирования, для функциональных тестов - по барабану, не так ли?

Не всегда так. ПО может использовать какие-нибудь общие ресурсы (стандартные порты, файловая система и тд.) которые можно разрулить виртуализацией.

[Clauster]

Но это справедливо для нагрузочного тестирования, для функциональных тестов - по барабану, не так ли?

В условиях отсутствия выполнения требования реентерабельности и для функционального тестирования будет не по барабану. Если раньше при разработке как тестов, так и приложения не учитывалось и не предполагалось параллельное выполнение - удобнее будет выполнять просто на разных машинах, виртуальных или нет.

Все, теперь понял. Обилие длинных слов со сдвоенными буквами сбило с толку :)

[galogenIt]

Возможно, по каким-то причинам в Вашем случае это невозможно, конечно, но в общем случае -- параллельности можно достичь и без виртуализации.

Наши тесты ориентированы на интерфейс, к сожалению таково тестируемое приложение. От гуи уйти не удается. Потому на сервер должне быть открытый ГУИ. Это можно сделать только для одного пользователя. ТестКомплит не позволяет запускать два или более экземпляра - это и понятно, как там потом разберешься это чье окно первого тестируемого приложения или второго. Поэтому у нас возможно либо запуск нескольких виртуальных машин. Либо разделять процессы физически

[galogenIt]

реентерабельным

Простите, а это что такое?

[novak]

Все, теперь понял. Обилие длинных слов со сдвоенными буквами сбило с толку :)

Немного мозгом в написании диплома, бывает сложно переключиться на простой язык :)
2 galogenIt
Проще говоря, это возможность исполнять одновременно один и тот же код, без опасности серьёзных осложнений, связанных с параллельностью.

[ch_ip]

У нас используется сервер под Suse (intel Core 2 DUO E6550, 8Gb оперативной памяти) для нужд отдела тестирования. На нем развернут VMWare Server, и в данный момент поднято 7 виртуальных машин (с ограничением в 512 /768 Мб на оперативную память и размером ЖД 8-10 Гб). Виртуальные машины используются как для прогона автотестов, так и для разбора логов / воспроизведения ошибок / занесения багов.
На каждой виртуальной машине созданы пользователи для всех тестировщиков. Настройки пользователей хранятся централизовано на отдельной машине (у нас на всех виртуалках стоит одна и та же ОС. 7 штук нужно потому что достаточно много автотестов + разные версии IE и офиса тестируются).
Плюсы:
Настраивать надо всего 1 машину, потом она копируется.
При любых глюках машины очень быстрое восстановление путем убивания данной виртуальной машины и копирования новой из бэкапа (время на восстановление работоспосбности - 10 минут)
1 сервер эмулирует сразу 7 рабочих станций. Тормозов не наблюдается, но мы тестируем веб-приложение, не требовательное к ресурсам процессора (хотя тесты написаны на QTP, который иногда любит покушать проц).
Все дальнейшие глобальные изменения настроек также делаются 1 раз, потом тиражируются

Минусы:
В случае выхода сервера из строя мы лишаемся сразу 7 рабочих станций. Понятно, что есть бэкап самих VMWare, однако запасного сервера, на которм можно быстро развернуть все 7 машин нет.
невозмодность тестировать зависимость работы приложения от разной конфигурации железа, но нам это не требуется.

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

[tom_13]

2. Параллельности можно достичь и без виртуализации. Для использования виртуальных машин должно быть более серьёзное обоснование.

Алексей, поясните, пожалуйста, Вашу вторую мысль. Что это за обоснование? И каким образом можно достичь параллельности, кроме как не использованием дополнительного "железа"?

Современные операционные системы и так умеют эффективно распараллеливать выполнение процессов при наличии нескольких процессоров или ядер. Зачем виртуализация? Просто запускайте несколько процессов параллельно и всё. Возможно, по каким-то причинам в Вашем случае это невозможно, конечно, но в общем случае -- параллельности можно достичь и без виртуализации.

Тесткомплит не позволит запустить на одной машине сразу два паралельно :)

По поводу паралельности, был у меня такой опыт с комплитом, тоже время выполение тестов заваливал уже за 10 часов на одной машине, мне тогда выделили сервер , приблизительно такой же как у вас(core 2 DUO 8400 и 4гб оперативки)), на нем стояла винда 2008 серверная, а на ней сервер управления виртуалками HyperV. На нем в свою очередь успешно ставало три виртуалки с винХР(по 500мб оперативки каждая) где собственно стояло по тест екзекьюту, все это дело синхронизировалось между собой (помимо этого было еще две тестовые машыны :))
Время выполнения (в общей сложности на 5-ти машинах) уменьшилось приблизительно в 4-ре раза, (уходило время на синхру)

Из минусов HyperV - он не подымает виртуалки раньше винХР, тоестьесть виртуалку вин 2000 уже не подымете (почему так сделано понятия не имею, по-моему очень большой минус)
ну и насколько я знаю (могу ошибаться) стает на винду не меньше висты :)
Работает вприныпе быстрее чем VirtualPC сам проверял :)

Сколько стоит - не знаю но п-омоему не дешево :)

В общем мой вывод распределение на несколько машин весьма оправдано, но могут появится новые проблемы : синхронизация и тп. И лучше виртуализировать, если железо позволяет, еще раз у меня ХР-шки успешно бегали имея при себе по 500 Мб оперативки с тестекзекьютом .

[galogenIt]

Тесткомплит не позволит запустить на одной машине сразу два паралельно :)

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

TestExecute у нас к сожалению отсутствует, мы используем Standart Edition, т.к. как нам мы не тестируем web_приложения.

[tom_13]

Тесткомплит не позволит запустить на одной машине сразу два паралельно :)

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

нет вы меня не правильно поняли - не на одной физической машине а на одной операционке, тоесть на одной машине на нескольких виртуалках все будет работать :)

TestExecute у нас к сожалению отсутствует, мы используем Standart Edition, т.к. как нам мы не тестируем web_приложения.

Для синхроной работы на нескольких машинах вам понадобится ентерпрайз версия, ведь что бы запустить на виртуалке туда нужно ставить то что сможет запустить скрипты, а это или тест комплит или тест екзекьют, можно конечно купить екзекьют отдельно, но в для синхронизации между собой ваших скриптов вам понадобится такой компонент как NetworkSuite а он доступен только в ентерпрайз версии :(. В любом случае в этой ситуации выгоднее покупать ентерпрайз версию так как с ней идет 4-ре екзекьюта :)

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

[galogenIt]

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

Не совсем понял, что Вы понимаете тут под синхронизацией?

У меня будет скажем 1 машина на 1 стенд. Все файлы проекта синхронизируются через SVN. Update все равно приходится делать вручную. Обновление будем делать из общего репозитория. Так что файлы проекта будут всегда актуальны

[tom_13]

Не совсем понял, что Вы понимаете тут под синхронизацией?

Синхронизация выполнения скриптов, именно выполнения а не хранение репозитория. Имеется введу что NetworkSuite позволяет синхронизировать выполнение нескольких скриптов на разных машинах в определенных точках синхоронизации, очень нужная вещь когда приложение использует одну и туже базу данных.

Допустим у вас есть скрипты 1,2,3,4 1 и 2 последовательно выполняются на машине А, в тоже время на машине Б выполняются последовательно скрипты 3 и 4
вам нужно чтобы скрипты 2 и 4 стартовали одновременно (причины могут быть самыми разными, например нужно поднять бекап базы). Вот для того что бы скрипты 2 и 4 стартовали синхронно и используется NetworkSuite.

[galogenIt]

Не совсем понял, что Вы понимаете тут под синхронизацией?

Синхронизация выполнения скриптов, именно выполнения а не хранение репозитория. Имеется введу что NetworkSuite позволяет синхронизировать выполнение нескольких скриптов на разных машинах в определенных точках синхоронизации, очень нужная вещь когда приложение использует одну и туже базу данных.

Допустим у вас есть скрипты 1,2,3,4 1 и 2 последовательно выполняются на машине А, в тоже время на машине Б выполняются последовательно скрипты 3 и 4
вам нужно чтобы скрипты 2 и 4 стартовали одновременно (причины могут быть самыми разными, например нужно поднять бекап базы). Вот для того что бы скрипты 2 и 4 стартовали синхронно и используется NetworkSuite.

Теперь понял о чем Вы. Правда пока о таком способе тестирования не задумывались. Правда в любом случае, если это будет нужно, потребуется докупать до Профессиональной редакции.

А эта технология работает для win32 приложений?

[tom_13]

А эта технология работает для win32 приложений?

Не совсем понял вопрос, NetworkSuite это не технология а компонент тесткомплита, ему впринцыпе все равно какое приложение вы тетсите... Вы просто в скриптах прописываете точки синхронизации и какие скрипты на каких машиных должны запускаться :)

[galogenIt]

Не совсем понял вопрос, NetworkSuite это не технология а компонент тесткомплита, ему впринцыпе все равно какое приложение вы тетсите... Вы просто в скриптах прописываете точки синхронизации и какие скрипты на каких машиных должны запускаться :)

Нуц почему же, все отлично поняли. Спасибо