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

[AlexP]

А чего это за сервис специальный ? =) мне тоже хотелось бы чтобы тесты можно было инициировать не через командную строку, а как-нить по другому. Расскажите поподробнее...

Я разработал Web Interface для работы с тестами. Для каждого модуля тестируемой системы - своя страница с гридом (с общей информацией о test-case'ах). Общая информация о test-case'ах (имя test-case'а, текущий статус test-case'а, дата последнего запуска, ссылка на лог с последнего запуска и т.д... но главное - флаг, нужно ли запускать test-case) находится в таблице БД, которая внешним ключом связана с другой таблицей - здесь определены необходимые для каждого test-case'а переменные. Далее, был разработан сервис, который установлен на машине с тестируемым приложением. Сервис с определённым интервалом чекает основную таблицу на наличие флага, и если у флага значение true, он запускает tast-case, а после завершения - снимает флаг. Вот, собственно, в двух словах.

[Dmitry N]

Здравствуйте.

TestComplete'ом можно управлять через его COM объект. Этот способ гораздо гибче и функциональнее запуска тестов из командной строки. Подробнее об этом в разделе справки 'Working With TestComplete via COM'.

Для того, чтобы работать с TestComplete таким образом, совсем не обязательно создавать отдельное приложение на одном из языков низкого уровня (C++, Delphi, C#, и т.п. -- "низкого" по сравнению со скриптовыми языками). Можно создать скрипт на JScript или VBScript, сохранить его в файл с расширением JS или VBS и просто запускать этот файл. Это не даст вам графического интерфейса, но позволит управлять тестами программно.

[ArtemRudenko]

Cпасибо за информацию
Раньше как то даже не задумывался над такими вариантами запуска. Теперь будет над чем пораскинуть мозгами в плане оптимизации всего процесса.

[serpent]

Для организации работы с логом я использую обработчики событий (OnLogMessage, OnLogEvent и т.д.). Это дает возможность в рантайм дублировать лог в текстовый файл, для того чтобы если ТС повиснет (что он частенько делает) была возможность разобраться в том что происходило. Также дает возможность в процессе выполнения скрипта генерировать HTML-представление лога (с картинками и т.п.) и потом в случае возникновения ошибки оперативно посылать его на e-mail ответственного тестировщика, не дожидаясь окончания работы всего проекта. От собственных функций добавления в лог это выгодно отличается тем, что из лога всегда можно перейти прямо в место возникновения сообщения в коде, а в случае использования своей функции мы всего лишь попадем в эту самую функцию.
Родным же логом ТС почти не пользуюсь, ибо на мой взгляд, он очень неудобен (вот в ТС3 был прекрасный лог: и после падения открывался, и в рантайм можно было доступ к нему получать, и можно было с другой машины за ним следить прямо по ходу выполнения скрипта).

Элементарные скрипты-тесткейсы сами по себе организованы в отдельные функции. Их запускает специальный скрипт-пускач через Runner.CallMethod, этот же пускач занимается отсылкой лога на e-mail в случае непрохождения тесткейса, и тому подобной обслуживающей деятельностью. Родными TestItem'ами также не пользуюсь, т.к. гибкости никакой, а предложенный метод позволяет запрограммировать произвольную логику запуска тесткейса.