testomat.io управление авто тестамитонкие у тебя намеки :) у Леонардо да Винчи криптографии научился?
2 лайка
Кстати, ознакомится с этой книгой можно на Google Books:
Там с 1-й страницы по 159 есть.
а купить pdf слабо?
Как я понял, там не обзоры каких-нибудь инструментов, а об автоматизации в целом. Какая практическая польза от прочтения этих книг? Или теоретическая... Поделитесь опытом, пожалуйста
Условно, книги по программированию, можно разделить на две категории:
1. Изучение инструмента, языка программирования. Если Вы прочитаете учебник по C#, Java, Python, Perl – то результат будет очевидный. Вы сможете написать первую программу, и узнаете, как можно использовать те или иные технологии.
2. Вторая категория – это книги для совершенствования Вашего мастерства. Тут Вы изучаете новые подходы, рассматриваете варианты использования тех или иных подходов, взвешиваете все за и против вместе с автором. Это такие книги, как Design Patterns, Code Complete и т.д.
Точно так же и с книгами по автоматизации. Если Вам в данный момент нужно изучить инструмент – берите учебник или руководство по этому инструменту и сопутствующих технологий. Такие примеры содержат простые практические примеры, которые Вы, при желании, можете сразу же реализовать на практике.
Если же вы хотите набраться опыта и/или перед Вами стоит задача начала поддержки и развития проектов по автоматизации – то вторая категория для Вас. Обычно в таких книгах авторы делятся своим опытом, своими лучшими практиками, но, несмотря на это, в таких книгах больше теории.
Книги первой категории устаревают очень быстро. Книги второй – могут оставаться актуальными в течении 10-ти лет.
Тоже самое касается и книг по автоматизации.
Если Вы только осваиваете автоматизацию – то книги про инструменты – это то что Вам сейчас нужно. Если Вы в автоматизации уже не первый год – то стоит обратить внимание на теорию, вторую категорию.
А какая вообще польза от знания или не знания информации?
Книга вам предоставляет массу информации, иногда выработанной годами опыта, в аккумулированной форме.
Можно конечно работать несколько лет для того чтобы получить точно такой же опыт, но зачем? Если можно изучить опыт другого человека, подходы, стратегии, о которых вы возможно даже не догадываетесь, и выполнить определенную работу намного быстрее и качественее.
наверное, вы не будете спорить, что не все книги хороши, скажем так. Кроме того, уже написано много книг про тестирование и нельзя объять необъятное... Из предыдущего ответа (кстати, спасибо за ответ), я понял, что для меня и того "процесса", в котором я сейчас работаю, такие книги покарано разибрать.
А может кто-то посоветует книгу, в которой описаны именно методики построения тестового фреймворка в примерах, типа как статья о ButerBroD-е на этом сайте. Нужна книга, которая детально опишет как строить фреймворк для тестирования продукта (веб сайта к примеру) с нуля и до бесконечности, с примерами кода (и желательно побольше). Приветствую так же ссылки на хорошие статьи или онлайн уроки.
1 лайк
я делал все сам, не знаю насколько оно красиво и правильно, но работоспособность на ура))
могу скинуть презентацию.
дело в том, что таких книг нету. в основном, все книги описывают, как пользоваться инструментов, а не как создавать свой инструмент.
Нет, спасибо. Интересен не столько практический пример, сколько международно правильный шаблон построения. Но спасибо за предложение.
Плохо, значит придется реверсить существующие фреймворки в обучающих целях, спотыкаться, падать и подыматься.
А расшарь как-нибудь презентацию.
Я уже один фреймворк для авто тестов для веба создал с нуля, сейчас по аналогии создаю еще один но уже для десктоп приложения.
Я тоже не могу сказать насколько мои "творения" красивы и правильны - но главное что работают :)
Вот и интересно было б посмотреть на аналогичные решения но для других проэктов.
я сегодня ее доделаю и скину на слайд шар, розшарю ссылку.
http://www.slideshare.net/taraslytvyn/framework-for-web-automation-testing
вот закинул какая есть, буду вопросы по слайдам, (а они будут) ))))) - задавайте)
Вот, например, человек дискутирует сам с собой:
http://msdnrss.thecoderblogs.com/2011/11/object-model-design/
поискав по словам logical functional model physical и т.д., вы поимеет кучу информации, как по тестовым фреймворкам, так и архитектуре вообще
обычно, в моём понимании, дело обстоит так:
- у вас есть требование по акцептанс-тестам (максимальная имитация использования продукта конечным пользователем, вплоть до кликов или переходов по табам) - выбирайте LFM
- вам требуются быстрые тесты (транзакции, передача данных, и т.д.) - выбирайте POM
нужно и то, и другое - комбинируйте
после ковыряния в гугле (хотя двух пунктов, что я написал, имхо уже почти достаточно для принятия решения :)), переходите к чтению Framework Design Guidelines. Это международно правильный шаблон построения. На него ссылатся и к нему отсылают. Можно скачать, да и стоит книжка недорого (доступ к цитатам через амазоновское облако по всему миру разве вам не интересен?).
у нас, например, преобладают требования по имитации юзерской активности - поэтому мы использует пауэршелл. На пуэршелле можно достучаться и до нутра, т.е. и POM потрогать, если надо.
Кстати говоря, при оформлении кода в виде пауэршелл (не важно, в скомпилированном виде или нет), на вас автоматически падают требования по оформлению кода и по именованию (в особенности, если ваш модуль компилируемый).
мне вот не нравится идея подхода к тестовому фреймворку как к произведению искусства. У вас времени вагон или вы продаёте продукт сразу со средствами его тестирования? Хороший тестовый фреймворк
- эффективен в проверке
- дёшев (если в несколько раз дешевле написания самого продукта - это то, что надо)
- развёртывается на раз-два и работает весь срок жизни версии продукта
- понятен стороннему девелоперу/тестеру
вот пример, как работает один из наиболее эффективных людей у нас:
на всё, что он видит, он просто вешает проверки. Видит контролы - вешает проверку на их наличие, дизейбленность: количество и т.д. Стоит это копейки (конечно, тысячи таких тест-кейсов уже занимают дни, что ж поделать). Фактически, это юнит-тесты гуя (апологеты эджайла протифф), объединённые в акцептанс-сьюты.
Повторяющиеся вещи, разумеется, оборачивает в функции
clickButton 'Next >'
clickAction 'Create collection'
closeWindow
и т.д.
Если надо много работать с некоторой областью (окошко, или фича), то можно подумать о рефакторинге.
Что происходит после установки нового билда? Всё, что сломалось, всё что поменялось, всё что девелоперы добавили или убавили - всё это резко краснеет в репорте.
Дальше человек проявляет социальную активность и идёт к девелоперам на разборки. Когда узнают, была ли это поломка плановая или внезапная, принимает решения по изменениям в автотесте (в смысле, что не наугад фиксит).
Другой эффективный сотрудник, который не видит тестов без C#, сделал свой тул (очередная запускался тестового кода через рефлексию (это такой обходной способ подцеплять аддыны, если не хотите счастья от System.Addin)).
Это пример классического тестового фреймворка, да ещё и универсального.
У него есть требования (обычно решаемые на словах, т.е. без документации), как авторам аддынов назвать класс или метод.
Что тут сказать? Есть преимущества в таком подходе, но есть и недостатки: создание туля заняло время и понимабельность в случае недоступности автора не на высоте.
Это как раз пример тестового фреймворка, который и не LFM, и не POM, а универсальный движок, не завязанный на тестируемый продукт (немного напоминает mstest или nUnit, но не прошёл их уровня тестирования).
пдф не на всём удобно читать (а пдф с примерами кода требует большого экрана, а то и цвета).
Неплох амазон (и его формат) - цитаты из книг доступны вам по всему миру, хоть в браузере, хоть в десктопной версии киндла.
Но есть проблема с ценами: амазон не имеет стратегии переучёта. Т.е. на некоторые книжки они снижают цену (по разным причинам), а некоторые 2006-2007-2008 годов стоят по безумной цене баксов в сорок (за двести страниц), только потому, что когда-то сварить электронную версию стоило дорого, а доставить на устройство тоже не дёшево. Вот это обидно.
Если на покупке книжки за десять, пятнадцать или двадцать баксов выигрываешь в цене по сравнению с бумажной, то на безумных ценах проигрыш очевиден.
причём рейтинг вторых ("худлита") заметно выше, чем первых :)
посмотрите на счётчиках на амазоне (это не является официальным индикатором продаж, но сообщает кой-что склонному к анализу человеку):
если книжка по программированию (или по администрированию) на 100000-м месте или даже на 50000-м, это большой успех (и только книжки для новичков обычно поднимаются выше)
если же книжка от популярного автора по болтологии (эджайл, к примеры, или теория, но более-менее живо описано) - место может быть 15000-м или даже 6000-м.
бывают исключения в обеих группах, конечно.
из источников в собственном имхо...