Обзоры продуктов - нужен ли подфорум
От: Double Robert Россия  
Дата: 31.10.10 17:03
Оценка:
Я вижу здесь немало вопросов о подборе продуктов под конкретную ситуацию. Совсем недавно и сам рылся
в инете в поисках чего-нибудь простенького для тестирования веб-сайтов.
Соответствующий раздел статей в RSDN — мягко говоря, бедноват.

Хорошо было бы заиметь прямо на RSDN подборку обзорных статей про разные системы для тестирования (а то ссылки имеют нехорошую тенденцию помирать).
Таких статей, чтобы человеку, даже далекому от тестирования,было понятно — что это за продукт,
что он может и как примерно с ним НАЧАТЬ работать, его плюсы и минусы.
Не могли бы уважаемые профессионалы в тестировании накидать ссылок с краткими пояснениями,
а еще лучше — поделиться СВОИМ опытом с новичками?
Re: Обзоры продуктов - нужен ли подфорум
От: OpenQuality http://openquality.ru/
Дата: 01.11.10 07:00
Оценка:
DR>Не могли бы уважаемые профессионалы в тестировании накидать ссылок с краткими пояснениями,
DR>а еще лучше — поделиться СВОИМ опытом с новичками?

http://openquality.ru/software-testing/automation.php — работа с инструментами для автоматизации тестирования

http://openquality.ru/software-testing/unit-tests.php — модульные тесты
OpenQuality.ru | Качество программного обеспечения
Re: А гонорар хороший? Ж:-)
От: Green Azbuk  
Дата: 01.11.10 16:01
Оценка:
Здравствуйте, Double Robert, Вы писали:
DR>Таких статей, чтобы человеку, даже далекому от тестирования,было понятно — что это за продукт,
DR>что он может и как примерно с ним НАЧАТЬ работать, его плюсы и минусы.
На самом деле нормальная статья подобного рода — времени требует. Соответственно — оплаты
DR>а еще лучше — поделиться СВОИМ опытом с новичками?
Коучинг?
Re[2]: История про TesterBench (автотестирование сайтов)
От: Green Azbuk  
Дата: 01.11.10 17:19
Оценка:
Сразу скажу: я не тестер, но подумать о приемлемой автоматизации тестирования одного проекта мне все-таки потребовалось. Причем хотелось заложить на это как можно меньше ресурсов – проект никак нельзя назвать выскобюджетным. Так что возникла и мысль отдать тестирование на аутсорсинг куда-нибудь подальше от двух столиц: удаленно можно нанять неплохих разработчиков по цене московских тестеров не самой высокой квалификации. Конечно, некоторые организационные проблемы при этом возникают – но стоит только один раз попробовать, чтобы понять, что у страха глаза велики, а разница во времени – это даже выгодно.

Конечно, на рынке присутствует море самых разных платных и бесплатных решений – Selenium, QuickTest Pro, SilkTest и т. д. Советовали Selenium – бесплатный и относительно широко распространенный. Но на рынке обнаружилось и почти никому не известное изделие компании MouseClick. Как оказалось, их группа разработки находится в Питере – так что при желании можно получить и поддержку на русском. Ребята сделали оригинальную систему “Tester Bench” ( http://www.testerbench.com/). Эта система не бесплатная, но ее стоимость меньше месячных расходов на одного тестера.

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

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

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

Вся установка с настройкой сводится к запуску setup и нажатию кнопок “согласен” – и в меню “Пуск” появляется “MouseClick Technologies” с тремя ярлыками. Эти три ярлыка — Demonstration, Readme и Uninstall. Запуск демонстрационного скрипта, ссылка на страничку на сайте производителя с поздравлением об успешной установке и запуск деинсталляции. Все! Никакой IDE, только интерфейс командной строки плюс конфигурационный файл(обычный XML, лежит в директории установки). Необычно. Хотя что-нибудь простенькое из трех полей (к примеру, что запускать, куда сохранять логи и автоматические скриншоты, какой браузер использовать) и энного количества чекбоксов не помешало бы. Может, и появится – вроде бы продукт развивается шустро.

Своей IDE нет вообще, зато нет и никаких лишних серверных компонентов: все, что этому движку нужно – скрипт да доступ по HTTP к тому сайту, который нужно протестировать (я для начала немного побаловался с В Контакте, Яндексом и Google) . Ну и набор браузеров, для которых нужно протестировать сайт (если нужен не браузер по умолчанию, то можно указать конкретный браузер в командной строке). Так что к тестированию можно привлечь любого обладателя компьютера с доступом к интернету.

Написание скриптов – процесс нудный, но тоже несложный. Язык скриптов – JavaScript. Скрипты представляют собой имитацию обращений из JavaScript к jQuery, но фактически для написания скриптов достаточно знать всего несколько конструкций. Так что на самом деле для большинства задач нет необходимости ни в знании JavaScript, ни в знакомстве с jQuery .
Из одного файла вызывать другие файлы можно, так что управление наборами тестов не превращается в кошмар. Также можно подключать дополнительные модули CommonJs.
Один скрипт представляет собой текстовый файл с расширением jsq, который содержит набор блоков вида

test(
    function(){
            open('http://www.testerbench.com/demonstration.html');
         ...
  }
)


Open('…') – обязательная конструкция, открывающая страничку.
После команды Open идут блоки команд к элементам страницы. К примеру, ниже – строчка, которая переводит курсор на текстовое поле “ firstTabTextArea'” и вводит в него текст в точности так же, как это сделал бы человек:

$('#firstTabTextArea', 'Text Area').mousemove('top left', +5, +5).click('top left', +5, +5).type("PLEASE DON'T USE YOUR MOUSE DURING THIS DEMONSTRATION");


Подвести мышиный курсор к элементу, кликнуть с небольшим отступом, ввести текст с клавиатуры… Все прозрачно. Причем все это делается не изнутри браузера, а через Windows API . Так что получается действительно полная имитация действий человека.
При желании команды к элементу можно разделять таймаутами при помощи wait(…):

 $('#firstTabTextArea', 'Text Area').wait(1500).mousemove('top left', +5, +5).wait(1500).click('top left', +5, +5).type(‘one’).wait(1500);


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

А строчка ниже — проверка, что в текстовом поле находится именно текст “ DON'T USE YOUR MOUSE ”Ж

 $('#firstTabTextArea', 'Text Area').mousemove('bottom right').val().contains("DON'T USE YOUR MOUSE");


Если текст не тот, что нужен, то тест помечается как failed. Для проверок значений может быть использовано энное количество методов типа .contains(value), .is(value), .not(value) и т. д. Плюс – замечательный метод .matches, который позволяет использовать регулярные выражения.
Что приятно – если сорвется какая-либо из промежуточных операций над элементом, то в лог пишется, что именно сорвалось и почему. К примеру, если возник сбой при попытке кликнуть по элементу из-за того, что элемент находится за пределами видимости, то в логе и будет написано: “click position outside of browser window”.

Не менее приятно и то, что есть метод .screenshot(name) – как из названия и следует, он позволяет получить скриншот. Но вот с местом расположения скриншотов (да и логов) тут перемудрили – по умолчанию они выкладываются в C:\ Documents and Settings\...\Application Data\Mouseclick Technologies\Tester Bench\TestResults\...\Images. Понятно, что все это настраивается в config.xml – но ведь ожидаешь, что если ты ничего не указывал, то логи и скриншоты будут сохранены по умолчанию в какой-нибудь поддиректории рядом с файлом конфигурации. Файл конфигурации ведь положили именно на привычное место — в директорию установки, а не закопали в application data.

В общем, если человек имеет хоть какие-то навыки программирования и представление об HTML – уйдет всего несколько часов на то, чтобы по диагонали просмотреть документацию и разобраться. Хотя многим будет достаточно просто заглянуть в пример скрипта — http://www.testerbench.com/support/testDemo.jsq .

Именно этот скрипт и исполняется при щелчке по ярлычку “Demonstration”. Но таймауты, которые в этом скрипте расставлены, не являются обычной практикой: они нужны только для того, чтобы он не пролетел слишком быстро для человеческих глаз и пользователь успел увидеть “киношку” про манипуляции мышкой и ввод текстовых данных в поля на демонстрационной странице со вполне приличным набором контролов: http://testerbench.com/demonstration.html?web .
И эта “киношка” – отнюдь не покоординатная запись движений мышкой и действий пользователя в духе “record macros & replay”. Конечно, элементы сайта, над которыми производятся действия, при желании могут указываться и через указание координат с описаниями шевеления мышкой. Но, понятно, это не основной режим . В качестве основного способа предполагается именно выбор элементов по именам, по классам, перебором списка. Важная именно для тестирования деталь: движок, несмотря на использование в скриптах jQuery, является на самом деле внешним по отношению к браузерам. Движения мышью, ввод данных с клавиатуры – все это делается через операционную систему. Благодаря этому выполняется действительно полная имитация действий пользователя.

То есть идет не просто инициирование события click. Без лишних усилий со стороны автора скрипта сначала подводится курсор мышки к элементу. Поэтому происходит полный набор событий, включая всякие mouseout(), mouseover() и т д
В общем, вкусностей и полезностей предостаточно.

А из минусов... Большая часть того, что приходит в голову, зависит от сферы применения. Так что мнения могут быть прямо противоположными. Кому-то не понравится полное отсутствие IDE, а кто-то возразит: IDE здесь нужно не настолько, чтобы я за него переплачивать, пусть лучше сам продукт останется дешевым, а IDE пусть будет отдельным продуктом . Точно такие же аргументы “за” и “против” можно привести и насчет фичи типа “record & play”. Ее в этом продукте тоже нет – а ведь при грамотной реализации она может ощутимо ускорить разработку скриптов, снизив количество черновой работы.
Другой пример: поскольку события мыши и клавиатуры инициируются через OS, сейчас есть единственный способ заставить один компьютер прогонять несколько тестирований одновременно. Этот способ — создание на компьютере нужного количества виртуальных машин . Для кого-то это — существенный
минус. А у кого-то вообще нет потребности гнать несколько тестов одновременно.

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

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

Ну и конечно, он однозначно будет полезен в тех компаниях, которые не имеют тестеров ВООБЩЕ. Да, это неправильно, и по всем известным причинам (не лень, как думают некоторые управленцы, а “замыленный глаз”,”в одном месте лечим, в другом — калечим” и все такое) продукт должен тестироваться не только самими разработчиками – в противном случае в тестеров превращаются конечные пользователи продуктов. Но таких фирм в России немало: на тестировании ведь нередко пытаются сэкономить.

Но лучше сэкономить деньги, сэкономив время разработчиков. Да и тоскливо (умное слово – “потеря мотивации к работе”) разработчику, который не планирует стать профессиональным тестировщиком, тратить лишнее время на то, что не имеет прямого отношения к его основным обязанностям. Ну вот подобные продукты как раз и могут помочь сэкономить.

В общем, automated testing рулит!
automated testing
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.