Новые темы форума тестировщиков

TC не видит Пользовательскую область уведомлений
2014-10-17 13:30

Имеем: Windows 7 Pro + TC 9.31

Требуется: вызвать контекстное меню иконки в трее (клик правой кнопкой мыши по иконке, иконка всегда видима)

Вижу 3 варианта:

1. RClick по координатам. Не совсем гуд. Не пользуюсь.
2. Отыскать координаты самой пиктограммки в Shell_TrayWnd  и RCLick по ним. Вариант приемлим, но 3-й лучше.
3. Включить в MSAA объект ToolbarWindow32. Тогда становятся доступны объекты и можно красиво добраться до интересующего объекта.

Так вот проблема именно с тем, что TC процентов 90 перестает видеть виндоуский трей. Помогает только ручной запуск Display Object Spy и наведение на трей мишени. После чего все работает.

Сейчас думаю перейти ко второму варианту с поиском пиктограмки. Вообще, MSAA иногда странно ведет себя.

Кто сталкивался с проблемой?

Спасибо.

Доклад Алексея Баранцева с конференции Fun ConfeT&QA.

Вы нашли баг — но не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводился — но на следующий день больше не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводится — но только на вашей машине, а на других всё работает нормально.
Вы нашли баг, он успешно воспроизводится — но только не на машине разработчика и он не может пофиксить его.
Вы нашли баг, он успешно воспроизводился, и вот сам собой исчез, хотя разработчики говорят, что ничего не исправляли.
Знакомо? Наверняка.
Что делать в таких ситуациях?
Писать в баг-трекер или не писать?
А был ли баг вообще? Поверят ли вам?
Сколько времени потратить на попытки воспроизвести хитрый баг?
Я расскажу вам свои правила и маленькие хитрости, как действовать в этих случаях.

Подробнее...

Онлайн-тренинг с домашними заданиями, 3 занятия по 1,5 часа

Тренер: Баранцев Алексей

Чем тестирование веб-приложений отличается от тестирования каких-нибудь других приложений?

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

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

• фантастическое многообразие технологий, которые скрываются за простым фасадом браузера – фактически каждое веб-приложение является не самостоятельной программой, а частью всемирной паутины, и в работу веб-приложения вовлечено очень много разнородных компонентов,
• невероятная скорость веб-разработки как в узком, так и в широком смысле – короткие релизы, быстро меняющиеся требования, постоянное совершенствование существующих технологий и возникновение новых,
• потрясающее разнообразие пользователей, от случайных посетителей до постоянных клиентов, от младенцев до стариков, от новичков до хакеров,
• полная открытость технологий, протоколов передачи данных, стандартов, и одновременно с этим необходимость особенно тщательной защиты, с учётом написанного в предыдущем пункте.

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

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

После прохождения тренинга учащийся будет:

• понимать принципы работы веб-приложений и знать, какие технологии при этом используются,
• знать особенности тестирования веб-приложений по сравнению с десктопными приложениями,
• уметь проектировать тесты с учётом особенностей веб-приложений и оценивать покрытие тестами функциональности приложения,
• уметь выполнять тесты, при необходимости используя инструментальные средства для преодоления ограничений, накладываемых браузером,
• владеть инструментами, для выполнения специфических проверок, характерных для веб-приложений:
  • анализ целостности ссылок,
  • анализ соответствия веб-стандартам,
• понимать причины возникновения уязвимостей в веб-приложениях и уметь обнаруживать наиболее критические уязвимости в веб-приложениях,
• понимать принципы оценки производительности веб-приложений и уметь выполнять анализ серверной и клиентской производительности веб-приложений,
• уметь рассуждать об удобстве использования веб-приложений :)

Каждое занятие будет сопровождаться практическими заданиями, которые помогут быстрее и увереннее начать применять знания на практике.

Подробная программа и условия участия

Онлайн-тренинг, 4 занятия, начало 24 октября

"Младших тестировщиков производительности" не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности.

(с) Скотт Барбер (aka The Perf Guy)

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

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

На тренинге мы будем учиться обращаться с этим оружием:

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

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

Подробная программа и условия участия

Посмотреть отзывы участников онлайн-тренинга "Тестирование производительности"

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

Минимум теории, максимум практики!

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

Легко? Нет!

Эффективно? Очень!

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

Уже дважды наши ученики устраивались на работу в середине курса, благодаря первым 3 урокам! Присоединяйся к ним!

ВАЖНО!

Онлайн-интенсив хорош тем, что всего за неделю мы отрабатываем основные навыки, которые нужны тестировщику. При этом на целую неделю вы становитесь тестировщиком реального проекта, а не абстрактного карандаша. Каждое домашнее задание основано «на реальных событиях»!

Каждый день в течение недели у вас будет:

• 15-25 минут теории (видеозапись)

• 3-4 часа практики (домашние задания)

НО!

Это будет неделя интенсивной работы. Придется поднапрячься, но оно того стоит! Правила жесткие – не получил приемлемую оценку спустя сутки после выкладки ДЗ, вылетел с курса. Поблажек не будет.

Подробности...

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

Хочу сделать параллельный запуск разных тестов на разных браузера.

На сегодня есть 2 теста которые я хочу запускать на Хроме и ФФ, холчу что бы одновременно выполнялись два теста на ФФ и те же два теста на Хроме. С ИЕ пока непонятно так как он дико глючит с селениумом.

Что есть

Selenium Grid + Java + TestNG, все на Windows машинах

Начнем с настроек HUB-a и NODE-a в Selenium Grid . Для запуска использую json файлы, по мне так проще чем каждый раз писать большую команду.

NUB: java -jar selenium-server-standalone-2.43.0.jar -role hub -hubConfig hubconfig.json

{
  "host": null, // тут я не понимаю почему налл, но если прописать ИП - хаб не запускается
  "port": 4444, // тоже самое и из портом, если поставить не дефольтный - не запускается 
  "newSessionWaitTimeout": -1,
  "servlets" : [],
  "prioritizer": null,
  "capabilityMatcher": "org.openqa.grid.internal.utils.DefaultCapabilityMatcher",
  "throwOnCapabilityNotPresent": true,
  "nodePolling": 5000,

  "cleanUpCycle": 5000,
  "timeout": 300000,
  "browserTimeout": 0,
  "maxSession": 2,      // этот параметр отвечает за максимально к-сто запущенных браузеров в общем количестве, или нет ?
  "jettyMaxThreads":-1
}

NODE: java -jar selenium-server-standalone-2.43.0.jar -role node -nodeConfig nodeconfig.json

{
  "capabilities":
      [
        {
          "browserName": "*firefox",
          "maxInstances": 2,// этот параметр отвечает за к-сто браузеров которые запускаются одновременно ?, если до зачем тогда ещё есть и "maxSession"
          "seleniumProtocol": "Selenium"
        },
        {
          "browserName": "*googlechrome",
          "maxInstances": 2,
          "seleniumProtocol": "Selenium"
        }
      ],
  "configuration":
  {
    "proxy": "org.openqa.grid.selenium.proxy.DefaultRemoteProxy",
    "maxSession": 2, // зачем тут этот параметр если он есть и в NODE параметрах ?
    "port": 6667,
    "host": 10.2.2.224,
    "register": true,
    "registerCycle": 5000,
    "hubPort": 4444,
    "hubHost": 10.2.2.236 // ИП машины где запущен HUD
  }
}

В результате у меня появляется вот это 

Далее Тест на Java

package tests.formulaNew;

public class Formula_Aggregate_functions1_Selenium_Server {

	SeleniumMethod seleniummethod=SeleniumMethod.getInstance();
		@Parameters({"browser"})
		@BeforeClass
		
	public void setUp(String browser) throws Exception {
		SeleniumMethod seleniummethod=SeleniumMethod.getInstance();
		seleniummethod.starSelenium(browser);
		}

	@Test
	public void test() throws Exception {
             //test ...
		
	@AfterClass
	public void after() throws Exception {
	     seleniummethod.stopSelenium();
	}
	}
}

+ метод start Selenium c другого класса

	public void starSelenium(String browser) throws Exception {
		Appender appender = new FileAppender(layout, "C:\\log.txt");
		log.addAppender(appender);
		selenium = new DefaultSelenium("10.2.2.236", // server localhost
				4444, // port
				"*"+browser, // browser iexplore, googlechrome
				BASEURL); // url
		selenium.start();
		selenium.windowMaximize();
		selenium.windowFocus();
		selenium.open(BASEURL2);
		
	}

Теперь testng.xml файл

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Tests" parallel="tests" thread-count="2" verbose="2">
  <test name="Test1Firefox">
    <parameter name="browser"  value="firefox"/>
    <packages>
      <package name="tests.formulaNew"/>
    </packages>
  </test>  
  <test name="Test1Chrome">
    <parameter name="browser"  value="googlechrome"/>
    <packages>
      <package name="tests.formulaNew"/>
    </packages>
</test>
</suite>

Как влияет thread-count="2" в testng.xml файле на запуск тесто ?

По факту после запуска тестов через testng.xml селениум запускает 2 браузера ФФ и 2 Хрома, по через пару секунд почти все закрываются, кроме 1-го: один браузер Хроме выполняет 1 из тестов, но он зависает на этапе логина на веб приложение.

При использовании обычного селениума все тесты запускаются и выполняются нормально.

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

Помогите пожалуйста, сейчас только 2 теста, но уже есть готовых 18 новых тестов и их к-ство будет расти точно так же как и время на их выполнения по очереди.

Всем привет! Недавно начал пробовать автоматизацию, DataDrivenTest и @Dataprovider. Столкнулся со следующей проблемой: есть поп-ап регистрации, в нем нужно проверить инвалидные значения е-мейлов. Тест проходит по сценарию: "открытие браузера - переход на сайт - открытие поп-апа - ввод первого е-мейла и данных - закрытие окна" и так для каждого значения мыла. Нужно чтобы тест проганял все е-мейлы в одном окне и после - закрывал страницу. 

Уже пользовался clear();sendkeys();click(); теперь пробую упрощать процедуру. Посоветуйте пожалуйста, какие методы можно для этого использовать ?

public static FirefoxDriver driver;

@BeforeMethod
public void startDriver(){
driver = new FirefoxDriver();
driver.get("blabla.com");
driver.manage().window().maximize(); 
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
}

@DataProvider(name = "InvalidEmails")
public Object[][] SendIncomeEmail() {
return new Object[][] {
{"        "},
{"абвгдежз"},
{"________"},
{"--------"},
{"@#$%^&@#"},       
};
}

@Test (dataProvider = "InvalidEmails")
public void enterWrongValues(String email) throws InterruptedException{
InputIncorrectEmailValues values = new InputIncorrectEmailValues(driver);
values.clickRegButton();
values.setEmail(email);
values.setFirstPassField();
values.setSecondPassField();
values.clickSubmitButton();

}
@AfterMethod
public void stopDriver()throws Exception{
driver.quit();
}

Возникла необходимость раскидать баги по категориям Back и Front, для этого решили использовать поле Fix Version/s. Пока ковырялся с тем как бы сделать всё по-быстрому, поискал на форуме и не нашёл подсказки. Теперь сам делюсь решением.

Задача:

На разработчике более 100 багов. Как быстро проставить "Fix Version/s" для всех?

Решение:

Используем функцию "Bulk" в меню "Tools" для выбранного фильтра. Далее проходим по шагам: выбираем нужные Issues чекбоксами, решаем что с ними делать, делаем, применяем для всех

Тонкости: 

1. Fix Version/s таким образом не добавляется, а заменяется. Позаботьтесь о том, чтобы не потерять то, что было установлено (например, отсортируйте Issues и снимите чекбоксы)

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

Стоит задача автоматизировать некий бизнес-процесс: интеграционное сообщение должно прийти в систему, лечь в базу и отобразиться в web-интерфейсе.

Понятное дело, обязательно проверим в интерфейсе (в сравнении с тем, что было в сообщении), но стоит ли осуществлять тестирование на уровне БД и проверять там или это лишнее?

Вопрос в том, как корректнее проверить, чтоб ничего не упустить?

© 2010 | Software-Testing.Ru