Нужно иметь тестовую среду для выполнения юнит-тестов. Пытаюсь разобраться с TestLink.
Насколько понимаю, эта система — веб-интерфейс к своей базе плюс API. Сами тесты пишутся отдельно на скриптовом языке. А можно ли их выполнять из интерфейса TestLink? Как их правильно связать с его тесткейсами? Как задействовать в них XML-RPC?
В мануалах — только установка и начало работы, схема бд. А нужно — как собственно организовать свои тесты, как интегрировать их в эту систему. И самое главное — как получить автоматизм их выполнения?

Здравствуйте, DenProg, Вы писали:

DP>Нужно иметь тестовую среду для выполнения юнит-тестов. Пытаюсь разобраться с TestLink.
DP>Насколько понимаю, эта система — веб-интерфейс к своей базе плюс API. Сами тесты пишутся отдельно на скриптовом языке. А можно ли их выполнять из интерфейса TestLink? Как их правильно связать с его тесткейсами? Как задействовать в них XML-RPC?
DP>В мануалах — только установка и начало работы, схема бд. А нужно — как собственно организовать свои тесты, как интегрировать их в эту систему. И самое главное — как получить автоматизм их выполнения?

Сдается мне, тут совершенно напрасно все в кучу смешано.

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

Юнит-тесты пишутся с другими целями и на другом языке. Среда для их запуска — выделенный (желательно) тестовый сервер с установленным на нем CruiseControl или любым другим средством удаленного запуска.

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

Здравствуйте, rlabs, Вы писали:

R>Сдается мне, тут совершенно напрасно все в кучу смешано.

R>Тест-линк и прочие инструменты для забивания и отчетности по тест-кейсам — предназначены для приемочного тестирования (хорошо, для интеграционного и системного).

R>Юнит-тесты пишутся с другими целями и на другом языке. Среда для их запуска — выделенный (желательно) тестовый сервер с установленным на нем CruiseControl или любым другим средством удаленного запуска.

R>Очень не советую "менеджить" тесты модульного уровня в системах типа тестлинка, поскольку кроме горя и слез это мало что приносит.

А как менеджить юнит-тесты? На уровне кода? Я хотел бы иметь систему с наглядным отображением иерархии тестов, их редактирования. Желательно в виде веб-приложения.
Cruise Control — это конечно хорошая система, но она ведь немного для другого? Насколько я посмотрел, там нет подобного. Там тесты просто вызываются в конфиге? То есть надо иметь некий скрипт, который будет дергать весь набор тестов после каждой сборки?
Я хотел нечто похожее на QTP, TestDirector или TestComplete, только в веб и желательно бесплатно. Чтобы запускать определенные группы тестов вручную, либо в интерфейсе выбирать какие тесты запускать автоматически после построения.

Здравствуйте, DenProg, Вы писали:

DP>Здравствуйте, rlabs, Вы писали:

R>>Сдается мне, тут совершенно напрасно все в кучу смешано.

R>>Тест-линк и прочие инструменты для забивания и отчетности по тест-кейсам — предназначены для приемочного тестирования (хорошо, для интеграционного и системного).

R>>Юнит-тесты пишутся с другими целями и на другом языке. Среда для их запуска — выделенный (желательно) тестовый сервер с установленным на нем CruiseControl или любым другим средством удаленного запуска.

R>>Очень не советую "менеджить" тесты модульного уровня в системах типа тестлинка, поскольку кроме горя и слез это мало что приносит.

DP>А как менеджить юнит-тесты? На уровне кода? Я хотел бы иметь систему с наглядным отображением иерархии тестов, их редактирования. Желательно в виде веб-приложения.
DP>Cruise Control — это конечно хорошая система, но она ведь немного для другого? Насколько я посмотрел, там нет подобного. Там тесты просто вызываются в конфиге? То есть надо иметь некий скрипт, который будет дергать весь набор тестов после каждой сборки?
DP>Я хотел нечто похожее на QTP, TestDirector или TestComplete, только в веб и желательно бесплатно. Чтобы запускать определенные группы тестов вручную, либо в интерфейсе выбирать какие тесты запускать автоматически после построения.

QTP, TestComplete — это непосредственно средства, выполняющие команды, заданные в тестах + IDE для работы с ними. Когда речь идет о юнит-тестах, то о каких-то внешних по отношению к средствам разработки тестируемого приложения инструментах для создания/редактирования тестов говорить незачем. Значительная часть того, что вам нужно, обеспечивается теми же средствами разработки, что используются непосредственно для написания тестируемого приложения. Всё, что вам остается определить — это чем управлять сборкой данного решения. То есть направление Cruise Control вам указано верно. То есть, вам нужен какой-то подобный инструмент.

Но прежде чем рекомендовать что-то, желательно получить информацию по таким пунктам:
1) На каком языке разрабатывается тестируемое приложение
2) Какая тестовая библиотека используется для юнит-тестов (обычно это JUnit, NUnit и подобные библиотеки)
Вот после этого уже можно подобрать несколько систем (в т.ч. возможно и бесплатных), из которых можно выбирать

Здравствуйте, Marduk, Вы писали:

M>Но прежде чем рекомендовать что-то, желательно получить информацию по таким пунктам:
M>1) На каком языке разрабатывается тестируемое приложение
M>2) Какая тестовая библиотека используется для юнит-тестов (обычно это JUnit, NUnit и подобные библиотеки)
M>Вот после этого уже можно подобрать несколько систем (в т.ч. возможно и бесплатных), из которых можно выбирать

Я наверно неправильно назвал это юнит-тестами.
Вобщем есть некий сервис, язык C++. Есть отдельное стороннее приложение OpenSource, которое предназначено для тестирования именно такого рода сервисов. Оно запускается из командной строки и работает по своему XML файлу. Один его запуск — один тест, который может занимать много времени. Часто для одного теста запускается несколько таких приложений.
Все это должно работать и тестироваться в Windows и Linux.
Вопрос в том, как организовать такое тестирование. Хочется иметь некий интерфейс, где бы можно было прописать пути к тестам, выстроить их в иерархию, запускать все сразу или по отдельности.

Здравствуйте, DenProg, Вы писали:

DP>Здравствуйте, Marduk, Вы писали:

M>>Но прежде чем рекомендовать что-то, желательно получить информацию по таким пунктам:
M>>1) На каком языке разрабатывается тестируемое приложение
M>>2) Какая тестовая библиотека используется для юнит-тестов (обычно это JUnit, NUnit и подобные библиотеки)
M>>Вот после этого уже можно подобрать несколько систем (в т.ч. возможно и бесплатных), из которых можно выбирать

DP>Я наверно неправильно назвал это юнит-тестами.
DP>Вобщем есть некий сервис, язык C++. Есть отдельное стороннее приложение OpenSource, которое предназначено для тестирования именно такого рода сервисов. Оно запускается из командной строки и работает по своему XML файлу. Один его запуск — один тест, который может занимать много времени. Часто для одного теста запускается несколько таких приложений.
DP>Все это должно работать и тестироваться в Windows и Linux.
DP>Вопрос в том, как организовать такое тестирование. Хочется иметь некий интерфейс, где бы можно было прописать пути к тестам, выстроить их в иерархию, запускать все сразу или по отдельности.

Ага, вот оно что. В общем, TestLink для этой задачи вам точно не товарищ. Подобные задачи ближе к автосборщикам типа CruiseControl, Hudson, Team City.
Суть их работы таковы, что вы создаете набор отдельных задач, которым определяются триггеры для старта, выполняемые действия + нотификация о завершении. Все это может работать по расписанию или при определенном событии (например, check-in). В результате у вас есть панель с разными задачами, которые соответствуют запускам разных групп тестов.

Но это целесообразно использовать именно для групповых запусков, для запуска тестов поотдельности это просто неудобно, если тестов слишком много.