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

[Сергей]

Добрый день, коллеги.

 

Есть одно большое десктопное приложение с частью от веб.

 

Разбил программу условно на функциональные области.

 

Как лучше организовать тесты в TestComplete для тестирования различного функционала?

 

Увидел три направления:

 

1. Создавать в одном проекте подпроекты (по тестируемым областям) + один проект Common с общими функциями и объектами. В остальных подпроектах делать ссылки на общие скрипты. Но что делать с NameMapping, Stores и TestedApps? NameMapping - можно смержить, как я понял. А TestedApps - только добавлять в каждый новый проект. Stores - тоже нужно создавать каждый раз новые элементы. В общем не совсем удобно.

 

2. Создать один большой проект, разбить по папкам и подпапкам и организовать это все в Test Items. Но это не совсем читабельно, будет тонна скриптов с папочками и будет очень тяжелый проект. Плюс нельзя давать скриптам одинаковое имя, даже если они в разных папках.

 

3. Создавать каждый раз отдельный проект. Это мне совсем не нравится, т.к. не вижу единой структуры тестов.

 

Выбрал первый вариант. Но все равно не устраивает, т.к. некоторые элементы структуры нужно каждый раз копировать существующие.

 

Специалисты-автоматизаторы больших проектов в TestComplete, как Вы поступили бы в данном случае? Может есть ещё один вариант?

 

Спасибо за любой совет.

[Rebz]

Не считаю себя опытным спецом, но я за первый вариант.

"Но что делать с NameMapping, Stores и TestedApps" - у меня было проще - я их не использовал.

 

Был вариант, когда 2 продукта - один на вебе, другой - WPF, удобно было в рамках одного проджект сьюта иметь разные проекты под каждую из сред программирования, удобно. Можно вызывать оба продукта в одном тесте.

Библиотека общих функций/процедур, конечно же, выносится отдельно.

[Сергей]

Хм, NameMapping пока почти не использую, не вижу смысла, кроме всплывающих подсказок после точки; Stores - можно отказаться, там хранятся иконки и кое-какие данные, к-е можно брать отдельно с диска и хранить в к-л хранилище-папки, TestedApps - хм, да тоже можно отказаться, т.к. нужно только для того, чтобы запустить приложение, в принципе и без TestedApps запущу...

 

Остаются общие объекты и функции. Возможно, есть смысл так и сделать, отказаться от этих всех вспомогательных наворотов.

 

Спасибо, хе-хе как просто оказывается, нужно подумать...

 

Может ещё у кого-либо есть вариант?

[Stanislav_alphaopen]

Доброго утра.

 

Вот как у меня реализовано:

1. один скрипт отвечает за возвращение нужных мне объектов

2. в скрипте повыше - примитивные операции, типа кликов, shift+O всякие, координатные клики внутри конкретного объекта

3. в скрипте еще повыше - комбинации и шаблоны, собранные из операций из скрипта 2. 

4. скрипт парсер, который преобразует из фразы "Вынести виджет Солнце на панель дизайнера в координаты 100, 50" в вызов функции типа "operation("Палитра виджетов", "Солнце","панель дизайнера",  "100,50")"

 

и тьма текстовых файлов, с тесткейсами, написанными формализированным языком, их могут писать мануал-тестировщики/менеджеры. 

 

Конкретно для твоего случая подойдет следующий способ - несколько скриптов из пункта 3, под каждую область. Соответственно, за сборку будет отвечать 4-й уровень.  

Если 2-й скрипт получается тоже слишком толстым, его можно аналогично разбить. 

[Genka]

Но что делать с NameMapping, Stores и TestedApps?

 

Их можно использовать один для всех проектов, если что.

Добавляете в первом проекте эти элементы как обычно, а в остальных делаете Add-Existing Item...

[Сергей]

В том то и дело, что у меня было желание все это сделать общим, а потом добавлять ссылки, но в 9.3 у меня не получилось.

Вот как это выглядит у меня:

1. TestedApps -> Add -> только New Item (Existing задизаблен!!!)
2. Stores -> Add -> Exixsting Item -> .tcFile (из другого подпроекта в том же проекте) -> Unable to add.... because already exists...!!!
3. NameMapping -> Merge with... (Existing нет!!!)