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

[serega]

Вопрос в следующем.

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

Увидит ли робот эти свойства при считывании ObjectProperties?
Если нет, то есть ли метод как это сделать?

[Petr]

На форуме уже поднимался вопрос про то, каким образом устроены программы для автоматизации тестирования (Как устроены программы для автоматизации тестов). В нем Dmitry_NJ писал, что

Win32 API позволяет вам не только посылать events различным контролам (на чем собственно и основано автоматическое воспроизведение действий пользователя), но также и получать значения любых свойств этих контролов, которые разработчик сделал доступными внешнему миру, т.е. например, не объявил их private

.
Т.е. насколько я понимаю, считать такие свойства нельзя.

[Dmitry_NJ]

Разрабатываются базовые компоненты для прикладных программистов, где часть свойств скрыта (privat), что бы их невозможно было изменить
Увидит ли робот эти свойства при считывании ObjectProperties?
Если нет, то есть ли метод как это сделать?

Ни Robot, ни какой другой тул ничего не увидит. По той простой причине, что private свойства как раз специально и созданы для того, чтобы их НЕ было видно извне. И никакого доступа извне к ним нет, если только программист не определил какие-нибудь public методы в классе, которые позволяют контролируемый доступ к этим свойствам.
Собственно не совсем понятно зачем вам нужен доступ к private properties. Они же нужны исключительно для внутренней кухни класса. Если только вы не тестируете непосредственно код (но тогда при чем тут Robot?), вас, как тестировщика работающего с UI, т.е. с "черным ящиком", не должна беспокоить внутренняя реализация объектов.

[serega]

Собственно не совсем понятно зачем вам нужен доступ к private properties. Они же нужны исключительно для внутренней кухни класса.

Дело в том, что скрыты такие свойства объектов как размер, цвет шрифта и т. п.
Свойства, которые очень хотелось бы видеть при тестировании интерфейсов, т. к. осуществляется автоматизация тестирования на соответствие стандарту предприятия

Пробовал через вызов метода класса SQAInvokeMethod, но
SQAInvokeMethod is only supported for Visual Basic and OCX/ActiveX objects. А у нас C#, выдает ошибку 1019

Получается нет решения, или я не тот инструмент использую:((

[Dmitry_NJ]

Пробовал через вызов метода класса SQAInvokeMethod, но
SQAInvokeMethod is only supported for Visual Basic and OCX/ActiveX objects. А у нас C#, выдает ошибку 1019

Получается нет решения, или я не тот инструмент использую:((

Я не знаток текущей версии Robot, но я бы проверил для начала поддерживает ли он тестирование приложений, написанных на C#. Что-то сомнения у меня на этот счет. Опять таки вызов метода подойдет, если вы точно знаете, что программист определил public method, который позволяет контролируемый доступ к private properties. Если такой метод определен не был, то вы ничего не сможете сделать, потому что программист так реализовал класс, что доступа извне к размеру/цвету шрифта нет. Здесь надо разговаривать с самими разработчиками, чтобы понять почему так вышло. Или они "перегнули палку", или вы хотите тестировать то, что от вас не требуется.

[Yarilo]

По поводу Робота под .NET, не знаю как сейчас, но в его версии до 2000 года под .NET он у меня все время падал и мы оставили идею с Роботом; может быть сейчас что-то изменилось...

Если вы решили автоматизировать тестирование под .NET, то рекомендую ознакомиться со статьями James McCaffrey, они доступны, например по ссылке
http://msdn.microsof.....mes McCaffrey

В частности, статья по автоматизации GUI в Visual Studio .NET доступна по ссылке
http://msdn.microsof...TestAutomation/
Знать C#, конечно, нужно обязательно, чтобы этот способ использовать.
Предложенным способом можно добыть любые поля типа и их значения, даже private (используется библиотека System.Reflection, метод Type.GetField).

В статьях есть прямо отрывки кода для реализации, что делает статьи еще полезнее и понятнее :)

[Dmitry_NJ]

Tак до 2000 года и .NET еще не было :)

Вообще все эти статьи - о тестировании на уровне кода, что не имеет ничего общего с тестированием "черного ящика", для чего собственно Robot и предназначен. Если действительно надо тестировать на уровне кода (а судя по всему так оно и есть), то Robot, как средство реализации, выбран ошибочно. И дело тут даже не в том, что он, скорее всего, не умеет распознавать объекты .NET, а в том, что он изначально для другого предназначен.

[Yarilo]

Вообще все эти статьи - о тестировании на уровне кода, что не имеет ничего общего с тестированием "черного ящика", для чего собственно Robot и предназначен.

Я не очень поняла, что Вы имеете в виду под тестированием на уровне кода.... Конечно, при автоматизации придется возиться с исх. кодом проекта (если не написать своего обнаружителя объектов :) )

Статья про тестирование GUI - автоматизируется как раз тестирование по типу черного ящика: автор предлагает только ПОДХОД к тому как имитировать действия пользователя с GUI и сравнивать реакцию системы с ожидаемой.

Может быть я Вас не правильно поняла, тогда поправьте меня :)

[Dmitry_NJ]

Когда вы автоматизируете тестирование такими средствами, как Robot, то вы тестируете на уровне GUI, то есть кликаете кнопки, выбираете пункты меню и пр. Вы понятия не имеете какой код все это реализует. Вы не работаете с исходным кодом приложения напрямую. Просмотрев статьи по вашей ссылке я увидел примеры кода на C#, которые что-то делают с приложением. Это тестирование на уровне API самого приложения. Вы же не хотите сказать, что запустив эти примеры вы увидите на экране как мышка будет сама двигаться по экрану и повторять действия пользователя? Вы просто сами вызываете, например, какой-то метод, который вызывается, когда пользователь кликает, например, на кнопку. А потом проверяете что-то в самом приложении. Опять же на уровне кода, а не на уровне того, что видит пользователь на экране. Какой же это "черный ящик", когда вы точно знаете какой метод должен отработать? :)

[serega]

Тема вызвала бурные обсуждения, с огромным интересом слежу

2Yarilo не сдавайся, твой ход:))

[Yarilo]

Какой же это "черный ящик", когда вы точно знаете какой метод должен отработать? :)

А я думала, что "черный ящик" - это когда тестирование по типу когда знаем что должна функция принимать на входе и что на выходе соответственно, а вот когда пути охвата тестируем, тогда и смотрим как непосредственно функция написана, а в предложенном способе не требуется знать, как функция внутри реализована, поэтому это как раз по типу "черного ящика" :P

[Dmitry_NJ]

Это зависит от того, что понимать под ящиком :) Если ящиком является функция (в смысле программного кода), то все так и есть. Если же ящиком является GUI, с которым пользователь работает, то тут все несколько иначе.

[Yarilo]

Тема вызвала бурные обсуждения, с огромным интересом слежу

2Yarilo не сдавайся, твой ход:))

Serega, а тебе действительно все еще надо эти private поля "доставать"? :D

[Yarilo]

Это зависит от того, что понимать под ящиком :) Если ящиком является функция (в смысле программного кода), то все так и есть. Если же ящиком является GUI, с которым пользователь работает, то тут все несколько иначе.

Согласна :)

Нам Serega не сказал, как именно он хочет автоматизировать - копаться в исходном коде или работать исключительно с GUI :)

[serega]

Serega, а тебе действительно все еще надо эти private поля "доставать"?  :D

Попробую сформулировать ответ

В базовых объектах необходимые мне свойства будут прописаны как private, по идее, достаточно проверить на уровне кода свойства этих объектов в очередной сборке.

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

Но кто знает, задал ли архитектор эти свойства правильно в своих базовых объектах для данной сборки
И второе, я хочу дать рядовому тестеру скрипт и пусть он запускает, а не изучает VisualStudio и не бегает за архитектором, а где, мол, лежат твои данные объекты для текущей версии.

Резюме, хочется, но обойтись можно

[Yarilo]

Как мне видится решение задачи, которую Serega обозначил:

1.Определить типы контролов, которые нужно тестировать именно на значения private полей.

2.Составить список контролов для каждого из типов. (Это можно сделать по-разному, наверное и скорее всего, можно автоматически).

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

4.Разработать главную процедуру, запускающую перебор контролов и вызывающую соответствующую процедуру сравнения с эталоном. (Тоже решается по-разному).

[Dmitry_NJ]

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