В таком случае, предложенный мной механизм вряд ли поможет. Знаю по своему опыту о «скрытой» бизнес-логике, с которой не раз приходилось встречаться, например «элементы с ID 1 и 2 нельзя удалять, потому что в некоторых ситуациях код приложения может рассчитывать на их существование». Тут без анализа и хранимых процедур и исходного кода бывает на обойтись.
Я с вами согласен. Действительно, если происходит несколько модификаций в одной таблице, то для более детального исследования нужно использовать профайлер.
Но, для того, чтобы предварительно узнать, какая таблица была модифицирована – достаточно и этого средства контрольных сумм. Это быстро и просто.
Если брать аналогию со (школьной) химией, то это средство действует как лакмусовая бумажка – чтобы узнать есть ли в стакане кислота. Ну а дальше нужно использовать несколько реакций, чтобы определить какая именно.
А я вас поддерживаю. Вместо того чтобы жевать мыслительную жвачку: а прав я или не прав, можно просто принять то, что не прав, и продолжать делать как задумал.
Нет, наши программисты тестов не пишут. Раньше писали юнит-тесты время от времени, но сейчас нет.
Автоматизированы у нас основные CRUD операции и инсталляция/конфигурация приложения. Перед началом моего рабочего дня тестировщика: скачан, проинсталлирован и сконфигурирован новый билд – и прогнаны основные тесты. Этого пока достаточно и поддержки требует минимум.
На моем текущем проекте эффективны средства полу-автоматизации: вот например, скрипты для отслеживания изменений в таблицах БД или xml файлов, слежка за HTTP запросами при помощи Fiddler’а, скрипты сигнализации об ошибках в логах приложения.
И сейчас осваиваю mdbg
И основная проблема пока что не в том, чтобы готовый код выполнялся корректно, а в том, чтобы правильно понять чего же хотят пользователи нашего продукта. Это уже процессная проблема. В таких условиях хорошо работают простые тесты и полу-автоматизированные инструменты, которые позволяют исследовать продукт быстрее.
Кроме того, пользователи нашего продукта модифицируют свои базы данных, расширяя размеры полей таблиц, добавляя триггеры и даже используя некоторые баги как фичи (например XSS уязвимости для вставки ссылок на свои файлы). В таких условиях, конечно же, более эффективно работает мануальное и исследовательское тестирование с использованием полу-автоматических инструментов.
Александр, я бы еще хотел порекомендовать вам посмотреть на bddify или StoryQ. Я ничего плохого не могу сказать про SpecFlow, сам пользуюсь этим фреймворком, но только в случае высокоуровневых сценариев. Для меня правило – что любой сценарий на SpecFlow должен состоять из трех строк максимум: один Given один When и один Then, который бы в общих чертах объясняли что делает сценарий. Вся сложная логика и детали у меня зашита в слое автоматизации на C#.
Вторым фреймворком я использую bddify, который позволяет разделять тест на блоки Given When Then и генерировать красивый отчет после прогона.
Вся бизнес логика работы приложения у меня находится в слое автоматизации, который я называю Тестовой Моделью. Там все логические страницы приложения задекларированы с использованием Page Object и DSL, вот например, следующий тест пересоздает пользователя и пробует залогинится:
В общем, в первую очередь, я старался добиться чтобы чтобы и на C# тесты смотрелись не плохо. Только потом я начал прикручивать SpecFlow и Bddify, с мыслью о том, что скорее всего в будущем я могу перейти на дргие тестовые фреймворки, но сам слой автоматизации останется не тронутым.
У меня есть длинные многострочные сценарии, из 10 – 15 шагов. Для их создания я использую Bddify, потому что в основном, написать на C# такой сценарий легче – и переменные можно использовать и контроля над кодом больше.
В SpecfLow я тоже изобрел свои велосипедо-переменные, но получилось не так эффективно как на C#.
Александр, а как вы, кстати, SpecFlow использовали, что-то типа такого:
Дано пользователя «Ваня» нет в системе
Когда я создаю нового пользователя «Ваня»
Тогда я могу залогиниться под пользователем «Ваня»
Или Дано зайти под пользователем ‘admin’/’admin’
И Кликнуть на ссылку «Администрирование»
И Кликнуть на ссылку «Пользователи»
И Удалить пользователя «Ваня»
Когда я на Главной странице
И я кликнул на ссылку «Регистрация»
И я заполнил поле Имя: Ваня
И я заполнил поле Фамилия: Иванов
И я заполнил поле Пароль: kjHKJKJhjkhU*IKL:”1
И я заполнил поле Подтвердите Пароль: kjHKJKJhjkhU*IKL:”1
И я нажал на кнопку «Регистрация»
И я ввел в поле Логин: Ваня
И я ввел в поле Пароль: kjHKJKJhjkhU*IKL:”1
И я нажал на кнопку «Вход»
Тогда я должен увидеть надпись «Привет, Ваня!»
Хочу добавить в список мифов: слышала такой миф от программистов, что тестировщики ищут баги только путем нажимания всех кнопок подряд, даже не задумываясь о входных и выходных параметрах.
Monkey testing – это неотъемлемая часть проверок. Вы отдадите продукт пользователю, который, поверьте, будет тоже нажимать на все кнопки не задумываясь о входных и выходных данных. Задача разработчиков – сделать так, чтобы пользователь не мог навредить самому себе и чтобы ответ приложения был всегда корректным. Если я могу нажать на все кнопки и приложение выдает непонятную ошибку, разве это нормально? Конечно же, не стоит ограничиваться лишь обезьяним тестированием, и в будущем стоит его автоматизировать, но сейчас, подумайте, если кнопка не работает – то я не смогу завершить свой самый сложный и самый продуманный сценарий. Так почему бы не убедиться в готовности приложения, проводя вначале сессию обезьяньего тестирования?
автоматизация позволяет сократить расходы;
Тут вопрос в том, что вы подразумеваете под автоматизацией. Если я, как мануальный тестировщик, использую инструменты для генерации тестовых данных, скрипты автоматизированого деплоймента базы данных, компиляции приложения из исходников, анализаторы логов, автоматизированную выкачку и установку билда перед мои приходом на работу, то это не автоматизация тестирования?
Многие люди думают, что автоматизация тестирования — это тесты на Селениуме. Вот вам еще один миф :)
автоматизация решает проблему с нехваткой ресурсов;
Ресурсов или кадров?
Если ресурсов, то да, автоматизация тестирования не заменит мне винт на 500 Гб.
Если кадров — то каких именно? Если вам нужен человек, который перегоняет данные из ворда в ексель, то я бы мог попробывать написать для этого скрипт.
чем больше автотестов, тем лучше;
Два теста лучше чем один, три теста лучше чем два, двадцать тестов лучше чем девятнадцать.
Вы — несогласны?
После какого числа это станет мифом.
Да, Selenium поддерживает внедрение пользовательского Яваскрипта в открытую страницу браузера. Но, использовать такой метод доступа к контролам, на мой взгляд, нужно лишь в самом крайнем случае.
Дело в том, что такие драйверы, как Selenium, WatiN, WatiR сами по себе внедряют очень много своего кода в страницу. И работают уже с модифицированной страницей, а не той, которую видят тестировщики и пользователи. Драйверы вызывают обработчики событий браузера, например onclick(), вместо того чтобы реально кликнуть мышкой по контролу в браузере.
Я как-то нашел в исходниках Селениума код функции на JavaScript, который выбрасывает исключение если элемент существует, но недоступен. И я хотел бы подчеркнуть, что это исключение выбрасывается логикой самого селениума, а не браузера.
Что было до появления этого кода? – Селениум мог вводить текст те контролы, которые никак недоступны для обычного пользователя.
Я это к тому, что разработчики Селениума встали на множество граблей, связанных с обработкой событий, вводом текста, определением доступности контрола, и поэтому, использование Селениума делает код автоматизации надежней. В некоторых ситуациях внедрение своего JS кода действительно необходимо, но при выборе «сложно через Selenium” и «просто через свой код» – я выбираю первый вариант.
Спасибо за Ваши пожелания, я их передал автору вебинара.
И спасибо за ссылку на доклад Николая Алименкова, я считаю этот доклад одним из лучших по Page Object.
На мой взгляд, Firebug/FirePath как то более очевидный для начинающих. Плюс Selenium IDE работает только под Firefox, но, в Chrome также есть немало полезностей. И на самом деле, это была просто рекомендация – использовать Firefox, а не неоспоримая аксиома.
Так это уже третий вебинар, а еще есть второй и первый.
Да, вы правы, качественный монтаж улучшил бы вебинары, а когда я делаю тайминг, то прослушиваю видео на 2x ускорении воспроизведения в VLC.
Мы поэкспериментируем с простыми техниками: увеличением скрости и обрезкой лишних частей.
Но, при этом очень важно сохранить саму оперативность публикации вебинара. В среду вечером он прошел, в четверг утром уже было доступно видео и сегодня утром появилась публикация на Хабре с коротким описанием и таймингом.
Но, для того, чтобы предварительно узнать, какая таблица была модифицирована – достаточно и этого средства контрольных сумм. Это быстро и просто.
Если брать аналогию со (школьной) химией, то это средство действует как лакмусовая бумажка – чтобы узнать есть ли в стакане кислота. Ну а дальше нужно использовать несколько реакций, чтобы определить какая именно.
Но, я думаю, что в закромах у вас завалялась «лабораторная» база данных более меньшего размера.
Смысл данного подхода в том, чтобы быстро найти те таблицы, которые были модифицированы в результате некоторой операции.
Наши программисты таких штук тоже не признают, и предпочитают изучать код хранимых процедур. Путь это и длительно, зато захватывающе.
Профайлером я тоже пользуюсь. Просто с применением данного подхода для меня нет необходимости его запускать каждый раз.
Автоматизированы у нас основные CRUD операции и инсталляция/конфигурация приложения. Перед началом моего рабочего дня тестировщика: скачан, проинсталлирован и сконфигурирован новый билд – и прогнаны основные тесты. Этого пока достаточно и поддержки требует минимум.
На моем текущем проекте эффективны средства полу-автоматизации: вот например, скрипты для отслеживания изменений в таблицах БД или xml файлов, слежка за HTTP запросами при помощи Fiddler’а, скрипты сигнализации об ошибках в логах приложения.
И сейчас осваиваю mdbg
И основная проблема пока что не в том, чтобы готовый код выполнялся корректно, а в том, чтобы правильно понять чего же хотят пользователи нашего продукта. Это уже процессная проблема. В таких условиях хорошо работают простые тесты и полу-автоматизированные инструменты, которые позволяют исследовать продукт быстрее.
Кроме того, пользователи нашего продукта модифицируют свои базы данных, расширяя размеры полей таблиц, добавляя триггеры и даже используя некоторые баги как фичи (например XSS уязвимости для вставки ссылок на свои файлы). В таких условиях, конечно же, более эффективно работает мануальное и исследовательское тестирование с использованием полу-автоматических инструментов.
Вторым фреймворком я использую bddify, который позволяет разделять тест на блоки Given When Then и генерировать красивый отчет после прогона.
Вся бизнес логика работы приложения у меня находится в слое автоматизации, который я называю Тестовой Моделью. Там все логические страницы приложения задекларированы с использованием Page Object и DSL, вот например, следующий тест пересоздает пользователя и пробует залогинится:
В общем, в первую очередь, я старался добиться чтобы чтобы и на C# тесты смотрелись не плохо. Только потом я начал прикручивать SpecFlow и Bddify, с мыслью о том, что скорее всего в будущем я могу перейти на дргие тестовые фреймворки, но сам слой автоматизации останется не тронутым.
У меня есть длинные многострочные сценарии, из 10 – 15 шагов. Для их создания я использую Bddify, потому что в основном, написать на C# такой сценарий легче – и переменные можно использовать и контроля над кодом больше.
В SpecfLow я тоже изобрел свои велосипедо-переменные, но получилось не так эффективно как на C#.
Дано пользователя «Ваня» нет в системеКогда я создаю нового пользователя «Ваня»
Тогда я могу залогиниться под пользователем «Ваня»
Или
Дано зайти под пользователем ‘admin’/’admin’И Кликнуть на ссылку «Администрирование»
И Кликнуть на ссылку «Пользователи»
И Удалить пользователя «Ваня»
Когда я на Главной странице
И я кликнул на ссылку «Регистрация»
И я заполнил поле Имя: Ваня
И я заполнил поле Фамилия: Иванов
И я заполнил поле Пароль: kjHKJKJhjkhU*IKL:”1
И я заполнил поле Подтвердите Пароль: kjHKJKJhjkhU*IKL:”1
И я нажал на кнопку «Регистрация»
И я ввел в поле Логин: Ваня
И я ввел в поле Пароль: kjHKJKJhjkhU*IKL:”1
И я нажал на кнопку «Вход»
Тогда я должен увидеть надпись «Привет, Ваня!»
И что такое для вас сложный сценарий?
У этого класса добавить метод load/open/invoke/show (любой из вариантов), который бы отвечал за показ страницы. Т.е.
MyPageC page = new MyPageC();
Page.Invoke();// После этого метода страница будет загружена.
В самом методе может содержаться логика любой сложности, которая ответственна за показ страницы MyPageC.
http://www.slideshare.net/dzhariy/what-isregularexpressions/download
В пост я ссылку также добавил
Monkey testing – это неотъемлемая часть проверок. Вы отдадите продукт пользователю, который, поверьте, будет тоже нажимать на все кнопки не задумываясь о входных и выходных данных. Задача разработчиков – сделать так, чтобы пользователь не мог навредить самому себе и чтобы ответ приложения был всегда корректным. Если я могу нажать на все кнопки и приложение выдает непонятную ошибку, разве это нормально? Конечно же, не стоит ограничиваться лишь обезьяним тестированием, и в будущем стоит его автоматизировать, но сейчас, подумайте, если кнопка не работает – то я не смогу завершить свой самый сложный и самый продуманный сценарий. Так почему бы не убедиться в готовности приложения, проводя вначале сессию обезьяньего тестирования?
Тут вопрос в том, что вы подразумеваете под автоматизацией. Если я, как мануальный тестировщик, использую инструменты для генерации тестовых данных, скрипты автоматизированого деплоймента базы данных, компиляции приложения из исходников, анализаторы логов, автоматизированную выкачку и установку билда перед мои приходом на работу, то это не автоматизация тестирования?
Многие люди думают, что автоматизация тестирования — это тесты на Селениуме. Вот вам еще один миф :)
Ресурсов или кадров?
Если ресурсов, то да, автоматизация тестирования не заменит мне винт на 500 Гб.
Если кадров — то каких именно? Если вам нужен человек, который перегоняет данные из ворда в ексель, то я бы мог попробывать написать для этого скрипт.
Два теста лучше чем один, три теста лучше чем два, двадцать тестов лучше чем девятнадцать.
Вы — несогласны?
После какого числа это станет мифом.
Selenium Meeting 19th may — Video Recording
Selenium Meeting 19th may — Video Recording
Дело в том, что такие драйверы, как Selenium, WatiN, WatiR сами по себе внедряют очень много своего кода в страницу. И работают уже с модифицированной страницей, а не той, которую видят тестировщики и пользователи. Драйверы вызывают обработчики событий браузера, например onclick(), вместо того чтобы реально кликнуть мышкой по контролу в браузере.
Я как-то нашел в исходниках Селениума код функции на JavaScript, который выбрасывает исключение если элемент существует, но недоступен. И я хотел бы подчеркнуть, что это исключение выбрасывается логикой самого селениума, а не браузера.
Что было до появления этого кода? – Селениум мог вводить текст те контролы, которые никак недоступны для обычного пользователя.
Я это к тому, что разработчики Селениума встали на множество граблей, связанных с обработкой событий, вводом текста, определением доступности контрола, и поэтому, использование Селениума делает код автоматизации надежней. В некоторых ситуациях внедрение своего JS кода действительно необходимо, но при выборе «сложно через Selenium” и «просто через свой код» – я выбираю первый вариант.
Спасибо за Ваши пожелания, я их передал автору вебинара.
И спасибо за ссылку на доклад Николая Алименкова, я считаю этот доклад одним из лучших по Page Object.
Да, вы правы, качественный монтаж улучшил бы вебинары, а когда я делаю тайминг, то прослушиваю видео на 2x ускорении воспроизведения в VLC.
Мы поэкспериментируем с простыми техниками: увеличением скрости и обрезкой лишних частей.
Но, при этом очень важно сохранить саму оперативность публикации вебинара. В среду вечером он прошел, в четверг утром уже было доступно видео и сегодня утром появилась публикация на Хабре с коротким описанием и таймингом.