testomat.io управление авто тестамиПлохо, значит придется реверсить существующие фреймворки в обучающих целях, спотыкаться, падать и подыматься.
А расшарь как-нибудь презентацию.
Я уже один фреймворк для авто тестов для веба создал с нуля, сейчас по аналогии создаю еще один но уже для десктоп приложения.
Я тоже не могу сказать насколько мои "творения" красивы и правильны - но главное что работают :)
Вот и интересно было б посмотреть на аналогичные решения но для других проэктов.
я сегодня ее доделаю и скину на слайд шар, розшарю ссылку.
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-м.
бывают исключения в обеих группах, конечно.
из источников в собственном имхо...
Подниму тему 
Появились ли еще свежие книги по автоматизации тестирования?
Есть масса книг датированных 2000-2005 годами - есть ли смысл их читать?
Такое ощущение, что “experiences of test automation” - так и остается самым “свежачком”.
Читаю в данный момент “Как тестируют в Google” Джеймса Уиттакера.
Кто еще кроме Уиттакера считается гуру тестирования (а особенно авто-тестирования), кого бы имело смысл почитать?
Особо не искал, но вот пару книжек 
И пара книг, может не совсем в тему но близко: Continuous Integration — Yandex Disk
3 лайка
О, достаточно интересная тема! По программированию книг достаточно, а вот по узким направлениям, типа автоматизации тестирования - голяк. Я в этом вопросе тоже достаточно рефлексивный, то есть если книга выпущена в 2005, то меня сьедят сомнения, стоит ли браться вообще? Ведь в наше время развитие прроисходит очень быстро и 10 лет разницы могут обесценить знания в книге.
и это те которые вспомнил, как придет вдохновение и память, добавлю еще 
1 лайк
Наткнулся на одну очень интересную книгу о тестировании сегодня. Хорошо написана и учит отлавливать серьезные баги.
2 лайка