Home

Продолжаем публикацию слайдкастов выступлений с прошедшей конференции SQA Days 8, на очереди рассказ Игоря Любина "Тестирование компонентов без пользовательского интерфейса".

Кстати, в начале своего выступления Игорь немного рассказал о своём родном городе Казани, где пройдёт следующая конференция SQA Days 9.

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

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

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

А что рекомендуется делать с “нечислами”? Они все объединяются в один большой класс “невалидных” данных, из него наугад берётся одно-два значения и всё.

И всё? А вот и нет!

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

Публикуем очередной слайдкаст с прошедшей конференции SQA Days 8 -- рассуждения Михаила Павлова о том, "Отвечает ли тестировщик за качество?"

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

Приглашаем Вас принять участие в работе конференции профессиональных программистов Application Developer Days, которая состоится 29-30 апреля 2011 в г. Санкт-Петербурге.

Это уникальное мероприятие, созданное экспертами в области разработки программного обеспечения, которое объединит на одной площадке отдельных профессионалов и целые ИТ-сообщества.

Application Developer Days ­— единственная технологическая конференция, которая не будет ограничена какой-то определенной технологией или платформой.

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

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

На консультации к тренингу "Программирование для тестировщиков" я пообещал записать небольшую демонстрацию того, как можно смотреть в отладчике Eclipse свойства объектов типа WebElement (в виде таких объектов представляются элементы веб-страницы в Selenium 2.0), а когда записал, решил выложить в открытый доступ, вдруг ещё кому-нибудь окажется полезной эта информация.

Для тех, кто не в курсе небольшое пояснение. Selenium 2.0 использует новый механизм доступа к веб-страницам, с использованием "нативных" интерфейсов. Поэтому объект типа WebElement сам не содержит никакой информации, только некий уникальный идентификатор. А при необходимости вся нужная информация извлекается непосредственно из памяти браузера. Это доставляет определённые неудобства при отладке тестов -- трудно понять, что за веб-элемент перед тобой, если видишь только какой-то идентификатор, состоящий из длиннющей последовательности букв и цифр. К счастью, в среде разработки Eclipse имеется специальный механизм для визуализации таких элементов, именно про него я и рассказал в этом небольшом видеоролике.

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

Это в теории. А на практике некоторые тестировщики находят дефектов в программе больше, чем другие, в том числе они умеют находить весьма нетривиальные дефекты. Почему? Как им это удаётся? Что за секретные техники они применяют?

Увы, никаких особых приёмов проектирования тестов, о которых не было бы написано в любой книжке, не существует. Эффективные тестировщики применяют те же самые техники, что и все остальные. Разница лишь в том, КАК они их применяют.

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

Мы постоянно будем держать в уме два противоборствующих фактора:

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

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

Продолжаем публиковать слайдкасты с прошедшей конференции SQA Days 8, сегодня мы представляем вам выступление Александра Александрова "Дефектные дефекты".

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

Недавно ученики моего курса Программирование для тестировщиков пришли ко мне с жалобой – тесты, которые у них успешно выполнялись в браузерах FireFox и Internetr Explorer по непонятной причине падали в браузере Google Chrome. Когда я посмотрел, что происходит, мне показалось, что я вернулся лет на пять в прошлое – налицо были все симптомы проявления same origin policy, с которым давно уже все научились бороться при использовании браузеров Internet Explorer и FireFox.

Страшные слова same origin policy знакомы практически каждому тестировщику, который начал использовать Selenium достаточно давно, когда ещё не было режимов запуска *iehta и *chrome. Производители браузеров, заботясь о защищенности пользователей, изобретают различные средства борьбы с уязвимостями в веб-приложениях. И как одно из средств защиты от XSS-уязвимостей, был придуман запрет в JavaScript-коде получать данные с любых сайтов, за исключением того, с которого был первоначально загружен этот самый JavaScript-код. Вот он-то и называется same origin policy.

Мы не будем здесь обсуждать, насколько этот запрет эффективен как средство защиты. Важно то, что его наличие вызывает проблемы при выполнении тестов при помощи Selenium. Дело в том, что ядро Selenium реализовано на языке JavaScript. При запуске теста ядро загружается в браузер, и всё работает хорошо до тех пор, пока в процессе выполнения теста не возникает необходимость перейти на другой сайт – браузер немедленно замечает это "опасное" действие и блокирует его.

Чтобы обойти это ограничение, были реализованы специальные режимы запуска браузеров с отключеной защитой, это режим *chrome для браузера FireFox и режим *iehta для браузера Internet Explorer.

А вот для браузера Google Chrome существует только один единственный режим запуска *googlechrome, и в этом режиме он запускается с включенными средствами защиты.

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