checo

1) А попробуйте-ка составить план.

Во-первых, нужно время на обучение. Причем, судя по написанному, надо не только знакимиться с инструментами тестирования, но и подтянуть теорию и практику программирования. Как минимум, одну серьезную книжку по ЯП надо прочитать и поупражняться. Это будет явно не С, а один из распространенных сегодня в автоматизации языков (Java, JS, Python, C#, Ruby, PHP, Groovy, ...). Можно за основу взять то, на чем пишут девелоперы, чтобы они могли проконсультировать.

Во-вторых, изучение инструмента. Конечно, можно начать с Selenium IDE, тогда и ЯП особо не нужен, но если проект ожидается сложный, IDE уже будет не хватать.

Срок обучения нельзя назвать четко, у всех разная скорость усвоения информации. Но рассчитывайте, что на вхождение в тему и создание первого набора тестов может уйти месяца 2-3.

 

Дальше - самое интересное. Сейчас свободное время есть, а будет ли оно потом? Когда первые компоненты начнут уходить в тестирование и насколько срочно надо будет давать результат? Сколько в среднем времени можно будет тратить на ручное тестирование, на тест-дизайн, а потом еще на написание автотестов и их поддержку?

По опыту, если на автоматизацию выделяется меньше 50% времени, она либо не дает никакого результата, либо автотестами покрываются отдельные избранные кусочки из серии "трудно/долго/нудно делать вручную". Ну, или можно сделать сокращенную регрессию, но это уже на более поздних этапах.

 

Можно прямо расписать план по времени и прикинуть реалистичность.

 

2) Насчет зрелости проекта и регрессии. Бывает так, что создаются компоненты, которые потом мало изменяются. В этом случае чем раньше начать автоматизацию регрессии, тем больше эффекта можно от этого получить.

Если же то, что есть сейчас, будет перепахиваться вдоль и поперек, проделанную работу придется выбросить в мусорную корзину раньше, чем она окупит потраченное на нее время.

 

3) Теперь о неизбежном. Раз РП настаивает, начать заниматься имеет смысл, даже если архитектура проекта пока не устоялась. Надо сделать небольшой "пилотный" проект, при этом изменчивость проекта пока не играет никакой роли. Важно выработать подход и получить опыт. Тогда и РП увидит, на что он сможет рассчитывать, и Вы сможете точнее оценивать нужные сроки.

Допустим, Вы инициализируете страницу так:

PageFactory.initElements(driver, page);

Если вызов делается с другими параметрами или используется PageFactory не из стандартной библиотеки (например, HtmlElements), всё может быть немного сложнее. Рассмотрим самый простой случай, когда вызов именно такой. При этом автоматически используется фабрика локаторов DefaultElementLocatorFactory.

 

Мы подменяем ее своей фабрикой:

PageFactory.initElements(new MyElementLocatorFactory(driver), page);

Код фабрики, полная копия Default..., но с подменой локатора:

public final class MyElementLocatorFactory implements ElementLocatorFactory {
    private final SearchContext searchContext;

    public MyElementLocatorFactory(SearchContext searchContext) {
        this.searchContext = searchContext;
    }

    public ElementLocator createLocator(Field field) {
        return new MyElementLocator(searchContext, field);
    }
}

Код локатора:

public class MyElementLocator extends DefaultElementLocator {

    private final String byInfo;

    public MyElementLocator(SearchContext searchContext, Field field) {
        super(searchContext, field);
        this.byInfo = new Annotations(field).buildBy().toString();
    }

    @Override
    public WebElement findElement() {
        Log.info("Searching for an element by: " + byInfo);
        return super.findElement();
    }

    @Override
    public List<WebElement> findElements() {
        Log.info("Searching for elements by: " + byInfo);
        return super.findElements();
    }
}

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

Если нужно именно логировать ошибки, добавляем логику с try...catch и дальнейшим пробросом исключения.

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

 

1. Ruby и Python изучить никогда не помешает. Но вот как раз для всяких системных операций с виндой, поднятия служб и т.п. лучше брать родной PowerShell. Другое дело, что это будут изолированные скрипты, а не тесты. Если нужны именно тесты, с выбором языка определяйтель в своей команде . Просто будете из тестовых сценариев вызывать системные команды, это в любом языке можно делать.

 

2. TeamCity - это не тестовый инструмент. Он запускает некую последовательность процессов и собирает с них информацию, например, всякие логи и файлы. В том числе будет запускать тесты через агенты, которые Вы установите на виртуалках, и собирать результаты в центральную систему. Для удобства работы с тестами есть плагины (смотрим тут: https://confluence.j...ameworksSupport), как с ними работать - зависит от того, какой язык и тестовый фреймворк будет выбран.

Здесь многое зависит от того, готов ли проект платить за инструменты и ресурсы.

 

1. Должен быть какой -то программный продукт, из которого будут запускаться (храниться) тесты

Тесты - это, как правило, код, который хранится в системе версионирования. Далее он компилируется (если это нужно) и запускается средствами интеграции. Что за инструмент - не совсем пока понятно, какие функции от него ожидаются?

 

2. Тестирование хотелось бы проводить на вирт средах ( есть опыт работы с WMware workstation) т.е перед началом теста подниматься должны 5-10-15 вирт машин разных ОС и там прогоняться все тесты.

Если столько виртуалок, да еще под Windows, Вам наверняка понадобится выделенный физический сервер или облако. Посмотрите в сторону бесплатных гипервизоров от vmWare на базе ESXi.

Процесс запуска самих машин зависит от используемых инструментов. На гипервизоре, в принципе, оси могут быть запущены постоянно или включаться/выключаться при помощи shell-комманд.

Запуск тестов, опять же, зависит от выбранного инструмента интеграции. Если это TFS или TeamCity (условно бесплатные), у них есть свои билд-агенты, если Jenkins или CC.Net (бесплатные) - скорее всего, запуск пойдет через скрипты, здесь можно использовать OpenSSH или (для Windows) Sysinternals Process Utilities. TestComplete тоже умеет запускать распределенные тесты, даже без CI системы, но всё за деньги.

 

3. Какими средстdами тестировать GUI написанное на WPF.

4. На каком языке писать сами скрипты ( powershell, autoIT, )

Язык - берем, который ближе, и на котором легче сможете написать. Про powershell не совсем понятно, какой именно инструмент для работы с UI будет в нем вызываться.

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

AutoIt - наверное, можно использовать, если этого достаточно.

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

Twin - позволяет выполнять тесты удаленно: запускаем тесты на одной машине, а тестируемое приложение - на другой, клиенская библиотека сделана для Java.

TestComplete - глубоко залезает в объекты, дает очень много возможностей, плюс хорошо организует тесты, но платный.

Есть еще интересная штука - UIAutomationClient - это библиотека в составе .NET, специально созданная для тестирования WPF, но она очень абстрактная, т.е. весь фреймворк, все полезные функции для работы с элементами придется писать с нуля (ну или поискать, м.б. есть готовые решения). Это альтернатива, если захочется писать под дотнетом, т.к. у Visual Studio с функцией тестирования цена неподъемная.

Ну, а платных инструментов вообще много, если поискать.

Браузер у Вас почти последней версии, а селениум старый. Для начала можно попробовать обновить.

1. Не встречал. Всегда легко написать собственный коллектор, который будет обнуляться в [TestInitialize], а в конце теста будет один Assert в зависимости от количества накопленных ошибок. Сами ошибки можно выдавать в текстовый лог с оформлением, по которому их легко находить.

2. Вывод в консоль (в т. ч. через System.Console) весь перенаправляется в .trx.

Не совсем понятно, почему тесты на удаленных машинах должны писать результаты в консоль. Можно прикрутить вывод в любой файлик.

 

Например:

public class Log
{
    static int errorCounter;
    static List<TextWriter> loggers = new List<TextWriter>(); // сюда можно добавить хоть консоль, хоть файловые стримы
    
    // ...

    public static Error(string errorText)
    {
        errorCounter++;
        postToAllLoggers(errorText);
    }

    // ...
}

Возможно, сервер падает не из-за нагрузки, а из-за конкретной баги. Надо заново подумать, в чем причина.

Потом, из вопроса непонятно, что происходит: Падает веб-приложение или окружение? "Падает" - это появляется ошибка на странице? Перестает работать конкретный функционал? Вообще всё зависает и перестает отвечать? Какие-то коннекты отваливаются?

Для начала, вы уже выяснили, что нагрузка сама по себе не роняет сервер (если, конечно, цифры близки к реальным).
Если воспроизводится достаточно часто, можно попросить разработчиков сделать более подробное логирование и по логам определять критический момент, что же там такое происходит. Потому что может быть банальная утечка ресурсов и переполнение, причем 20 минут - недостаточно, чтобы это привело к падению. Может быть ошибка в логике, которая проявляется при стечении каких-то специфичных условий, и простым манки тестингом ее найти сложно.

Зависит от того, из какой какую библиотеки компонентов этот RibbonBar брали разработчики.
Во-первых:
Есть риббоны, сделанные для WPF, WinForms, VCL (Delphi) и, наверняка, еще какие-нибудь.
Во-вторых:
TC старая версия. Если, например, интерфейс сделан в WPF для .NET >=4.0, 7-й TC с ним не работает (а это значит, что могут появиться проблемы и с другими компонентами).

Что попробовать:
1. Поиграться с настройками проекта. Попробуйте найти нужный компонент в ObjectMapping. Попробуйте добавить класс объекта в Open Applications -> MSAA и обновить ObjectBrowser. Иногда после таких манипуляций многое меняется в дереве объектов.
2. Если компонент полностью "рисованный", почему бы не поискать по картинкам (Regions.Find). Оно для этого и сделано, тогда абсолютные координаты уйдут из тестов.

for (String handle : driver.getWindowHandles()) {

	driver.switchTo().window(handle);

	if ( /* проверим тут URL, Title или что-то еще */ )

    	break;

}

Немного поработаю кэпом, раз никто не пишет.
Возможно, нужные ответы затерялись в глубинах форума. И скорее всего, многое из этого Вы уже знаете.

1. Когда в проекте появляется автоматизация.
По определению, автоматизация нужна: а) для избавления человека от рутинной и затяжной работы, б) для того, что человек вручную сделать не может.
По пункту А. Мы в своей компании автоматизируем тесты, которые повторяются из цикла в цикл и не требуют какого-то творческого подхода, поиска багов и узких мест. Просто верификация основного функционала. При постоянном выполнении этих тестов вручную человек начинает чувствовать себя мартышкой. Да и выигрыш по времени значительный, а люди освобождаются для более творческой работы.
Почему, например, автоматизации так много у производителей веб-приложений. Им приходится тестировать одно и то же в разных браузерах и разных средах, и делать это вручную совсем неприятно.
Автоматизируем в основном "проходящие" тесты. Не надо с помощью автоматизации искать баги. Пусть они будут находиться, но это не цель автоматизации, иначе она будет неэффективна.
По пункту Б. Здесь могут быть разные варианты "работы для робота": нагрузочное тестирование (имитация большого чиста тестировщиков), тестирование производительности (снятие бенчмарков, не будешь же сидеть с секундомером), тестирование опций (Вот попробуйте поперебирать несколько тысяч опций вручную. А алгоритм может, только дайте ему список.) и т.п.

2. Что попробовать.
Начать, конечно же, нужно с простых функциональных тестов.
Не знаю, какой у вас профиль - десктоп или веб.
Сейчас наиболее популярный инструмент автоматизации - Selenium. Он для веба, и есть в 2-ух вариантах: IDE - для записи и воспроизведения тестов, WebDriver - для использования с ЯП. По ним легко найти множество тренингов для начинающих, например: Selenium IDE, WebDriver.
Хороший, но не бесплатный тренинг по IDE и WebDriver есть у плюралсайта.
Можно взять произвольный сайт, составить несколько тестов и их автоматизировать, чтобы почувствовать "как это делается".

Для десктопа большинство хороших инструментов - платные. Из бесплатных можно попробовать Sikuli, AutoIt. Аналогично, тренинги и туториалы в сети ищутся легко.
Из платных можно взглянуть на демо-версии SmartBear TestComplete или Visual Studio Premium/Ultimate. Ну или другое - по вкусу.
Ну и конечно, для кругозора нужно знать, что делают разные инструменты:
- фреймворки для юнит-тестирования (JUnit, TestNG, NUnit, Gallio/mbUnit, MSTest),
- инструменты для тестирования нагрузки и производительности (JMeter, LoadRunner, LoadComplete),
- для тестирования сервисов (SoapUI),
- BDD (Cucumber, Thycidides, SpecFlow),
- автоматическое тестирование с помощью моделей и роботов (но это больше в теории, на практике это не всегда реально применить, и уж тем более не с этого начинают) (SpecExplorer, NModel, JavaTESK, свои разработки Яндекса)

3. Чем грозит внедрение автоматизации.
Да, знать, что такое автоматизация и где ее применить - необходимо. Но браться за нее нужно с расчетом. Нужно иметь план, и не на 10-15 тестов, а достаточно большой. Нужно выделять людей конкретно на автоматизацию. Нужно выделять время, при этом не ждать мгновенной отдачи и не ждать, что автотесты будут находить море багов. Иначе может получиться пустая трата ресурсов без отдачи.
По этому поводу не перестану рекомендовать выступление Игоря Хрола, пока кто-то не расскажет лучше.


Теперь немного пессимизма по поводу навыков автоматизации. Чем занимается тестировщик-автоматизатор? Огромное время уходит на отладку сценариев и на поиск решений, как сделать ту или иную хитрую проверку. Тратится время на анализ фейлов. Тратится время на настройку большого числа тестовых машин и окружений. Да, работа интересная, увлекательная и приносит много новых знаний. Но этот человек очень мало занимается реальным тестированием и поиском багов. Он практически не развивается, как тестировщик. Он также не развивается как программист, поскольку архитектура тестовых наборов очень специфическая и значительно проще реальных программных систем. Кем же он становится? "Специалистом по автоматизации". А это довольно узкая область. Так что надо дважды подумать, прежде чем заниматься этим всерьез.

ЗЫ в 9м прекрасное свойство, если при включенном Error dilog и Minimize TestComplete скрипт ловит exception - окно IDE не разворачивается и намертво зависает ))

Лучше сразу пишите в им поддержку или на форум. Может быть, они не знают об этом баге, всем поможете.

Возможно, не встали на место какие-то другие библиотеки, от которых зависит ее работа.
Попробуйте проверить зависимости, например с помощью Dependency Walker. Иногда просто достаточно скопировать нужные dll с той машины, где работает.

- найти тулу (помогите ))) ) которая на осовании данных сгенерит тест кесы (сама разобьет по классам эквивалентности) для простых инпут полей

А зачем нужны тестировщики, если бы все кейсы можно было сгенерировать? Шютка.
Если серьезно, то действительно такой тулзы иногда не хватает. Либо дают ссылки на инструменты для перебора комбинаций (AllPairs etc.). Либо скатываются к модельному тестированию, а это, извините, дружественной тулзой никак не назовёшь. Так что если кто-то даст ссылку на хороший простой инструмент, тоже буду благодарен.
Инструментики поискать можно, они в основном самодельные и с очень ограниченным функционалом. Сам не без интереса смотрел на TestCaseGenerator, но так и не стал пользоваться, потому что комбинации-то он строит, а вот полноценную диаграмму переходов создать не дает (в моем проекте это важнее).

- нарисовать модель зависимостей для if... than

Это называется диаграмма состояний и переходов (State-Transition Diagram). Копайте в эту сторону, кучу материала накопаете.

Возможно ли скрыть эту форму, что бы весь процесс происходил фоном? Как вариант

this.Visible = false;

Ну как бы да, компонент RDP по определению должен быть визуальным и открываться на форме или в веб-странице. Хотя, если не жалко времени, можно разобраться с протоколом )) http://www.freerdp.com/


Если есть какие-то проблемы со свойством Visible, возможно, следует попробовать дополнительные параметры.
Например, хорошая программка VirtuaWin, чтобы прятать окна, использует винапишный вызов SetWindowLong(). В .NET можно либо напрямую подтянуть из библиотеки, либо оверрайдить CreateParams у формы. вот тут еще несколько советов по прятанью формы.

Application app = new Application(new URL("http://localhost:4444"));
Element desktop = app.getDesktop();

выдает ошибку

Exception in thread "main" java.lang.IllegalStateException: Session not open
	at org.ebayopensource.twin.Application.request(Application.java:178)
	at org.ebayopensource.twin.Application.requestArray(Application.java:207)
	at org.ebayopensource.twin.ElementImpl.getElements(ElementImpl.java:455)
	at org.ebayopensource.twin.ElementImpl.getChildren(ElementImpl.java:402)
	at org.ebayopensource.twin.ElementImpl.getChildren(ElementImpl.java:399)
	at pack.Example.main(Example.java:21)

если же перед тем, вызвать getDesktop запустить приложение с помощью

app.open("notepad",null);

рабочий стол содержит только один элемент, которй только что вызвали.

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

Иначе говоря, из десктопа-то видно всё, но клиенту отправляются элементы, жестко отфильтрованные по процессу.
Есть 2 пути:
1) Если нужен глобальный контроль над рабочим столом, придется пересобрать своими руками. Перед этим найти в коде все фильтры по AutomationElement.ProcessIdProperty и убрать, где это необходимо. Но нет гарантии, что это не выльется в кучу глюков, и не придется менять гораздо больше.
2) Если достаточно будет приаттачиться к конкретному приложению и работать только с ним, есть недокументированная (вроде бы) настройка для SharpClaws.
Например:

<!-- sharpclaws.xml -->

<?xml version="1.0" encoding="utf-8" ?>
<server port="4444" log-level="INFO">
	<servlet context="/" class="Twin.TwinRC" assembly="twin-rc.dll">
		<param name="app.notepad.name">notepad</param>
		<param name="app.notepad.path">C:\windows\notepad.exe</param>
 		<!-- SIC! --><param name="app.notepad.launch-strategy">Attach</param>
	</servlet>
</server>

Есть 3 доступных стратегии launch-strategy: Launch, Attach, AttachOrLaunch.

P.S. Опенсорс такой опенсорс. Автор выкладывает свой "домашний" инструмент, чтобы нести добро людям. Естественно, полноценных доков не пишет. А мы потом ищи у него скрытые фичи. Как было написано в readme одной консольной проги для Linux: "У нашей программы нет справки по параметрам вызова. Но вы всё можете найти в исходном коде. Наслаждайтесь."