alk2alk

Прекратите уже пользоваться хакнутым старьем [...]

Как по мне - постоянная лицензия (а не подписка (на год) как у многих) - одна из сильных сторон SmartBear. Т.е. если не происходит постоянной гонки за последними технологиями/средствами разработки (например - поддержка существующего продукта), то тесты остаются работоспособными очень долго, без необходимости ежегодных финансовых трат.

Практически уверен, что в этом и причина.

Установите пробную версию ТС11 и посмотрите, будет-ли он работать с вашим приложением.

А версия ТестКомплит - 10.0 или выше? (Поддержка ХЕ5 была добавлена в ТС 10.0)

Все, в целом, уперлось в отсутствие статичных идентификаторов у объектов. В тех же элементах списков любое изменение их иерархии приводило к несовпадению сбою в привязке, т.к. объект был привязан к номеру ячейке в списке, а при изменении иерархии в списке номера ячеек не менялись, менялось их содержимое (текст). Если вместо номера ячейки пытаться привязаться к тексту в ячейке, то ТС уже не мог найти эту ячейку. Та же проблема была с выпадающим списком, т.к. как он формируется не совсем понятно и ТС видел разные списки как один и тот же. С таблицами та же проблема - количество ячеек формировалось исходя из того, что видно на экране в данный момент, и ячейка с номером 1 - это всегда верхняя ячейка.

Соответственно, как я понял, чтобы ТС корректно работал с приложением, необходимо иметь предельно четкое и статичное дерево объектов. 

Судя по всему - вы оказались "жертвой" одной из методологий разработки, когда объект генерируется "на лету" динамически, никак уникально не идентифицируется (только некий идентификатор, уникальный для данной сессии существования объекта данного типа) и с внешним миром общается путем отправки сообщений, которые обрабатываются кем-то, кто вполне может не иметь ни малейшего представления от кого он получил сообщение и кому он отвечает.

Возможно, что это и удобно при разработке, но при тестировании это вызывает отмеченные существенные проблемы идентификации целевого объекта тестирования. И это - не проблема TestComplete, а общая проблема, которая будет при использовании любого инструмента тестирования. Что можно сделать, например, если веб-страница постоянно перегенерирует таблицу? Как найти ее требуемую ячейку, если у нее нет определенного и уникального идентификатора? Только либо по известному значению данных в ней, либо по известному ее положению относительно иных стабильных объектов (например, вторая ячейка вниз и на столбец правее от ячейки, в которой находится кнопка "Сохранить").

Суммируя: статичное дерево объектов - не обязательно, но чем легче и уникальней идентифицируются тестируемые объекты - тем проще и надежней работать. Иначе - ищем ближайший стабильный объект (например - панель) и внутри нее начинаем перебор, пока не найдем требуемый объект (например, ищем все таблицы на панели и, для каждой найденной таблицы, перебираем все ячейки, пока не найдем нужную - то-ли по тексту внутри нее, то-ли по ее атрибутам (красный фон), то-ли еще как).

P.S. По хорошему - такая ситуация должна быть доведена до руководства и осознаваться им. По сути, вы являетесь разработчиком, которому для работы предоставлена среда (тестируемое приложение), которая не предоставляет достаточно информации о своем состоянии. Наверное, аналогичный пример, это если-бы при сохранении файла ОС не сохраняла-бы его по определенному и постоянному пути, а, например, где-то, в пределах данного диска. Т.е. даем команду записать файл - ОС отвечает: "записала на диск с:". А как найти? А как хочешь: то-ли сканируй все каталоги, то-ли еще как... Нашли файл. Поменяли в нем что-то. Снова командуем сохранить. ОС отвечает: "сохранила. Но сейчас - на диске d:. А тот, что был на с: - стерла". И снова ищи...

[...] сделали продукт, который может себя тестировать и продаем как 2 в 1м?! Или просто для себя или 3й вариант?! 

 

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

Например, из того, что пришло навскидку в голову - тестирование компонента, который использует captha. Такое извне тестируется только вручную, а изнутри - автоматизируется достаточно легко.

При этом, очевидно, что внешние и внутренние тесты могут комбинироваться. Например, TestComplete заполнит форму данными (внешний тест), потом - вызовет код (т.е. внутренний тест) тестируемого приложения который, зная ожидаемое значение captha, введет его в соответствующее поле, потом TestComplete продолжит выполнение теста, нажав кнопку "Сохранить" и т.д. В результате - тест будет автоматизирован и сможет выполняться на обычной версии тестируемого приложения, а не на специально подготовленной сборке.

Ну и кроме того, вы получаете в использование стандартную инфраструктуру TestComplete и своих тестов: единый лог, проектные переменные, NameMapping, тестовые данные и т.д.