Укажите в главном pom.xml в параметре <opencv.dir> (строка 380) путь до файла libopencv_java341.so на вашей машине.
Если возникнут трудности — пишите в личку.
Да, CI есть. Несколько путей решения:
1) в финальном отчете выставляем фильтры в соответствии с изменениями и принимаем эти риски (например обновили стили, поэтому в отчете убираем из фильтрации ошибки css)
2) Если изменения касаются конкретных элементов, то убираем из списка локаторов те, что ссылаются на измененный (что тоже несет некоторые риски)
Для подстраховки используем скриншот-тесты отдельных компонент в Storybook: верстка, как правило меняется не радикально, а лишь отдельные элементы (банеры, кнопки, и т.д.). В storybook компоненты вынесены на отдельные страницы. Так, что проверка изменений не занимает много времени даже при «ручном» тестировании, а проверка остальных компонент на отсутствие изменений уже с помощью Qvisual.
Анимацию и динамический контент (банеры с рандомными рекомендации продуктов, например) перед снятием снапшота удаляем со страницы при помощи js. Потом отдельно проверяем другими тестами (иногда руками).
Как уже вам ответили, предложенный вами подход разобьется о количество сравниваемых изображений. В среднем обычное наше приложение содержит 150 страниц, и проверяется в 6 разрешениях на 3 браузерах, итого: 2700. А есть и больше.
Суть нашего подхода в том, что человек нужен только для разбора упавших тестов (сравнений).
Белая точка действительно не попала в выделенную зону. Финальная картинка не была получена в результате сравнения нашим инструментом. Но смею заверить, наш инструмент нашел бы ее ;)
Так как мы используем Continuous Integration, то нам необходимо запускать тесты из TeamCity, SBT позволяет это сделать. Также мы используем в нагрузочных тестах различные библиотеки, которые SBT загружает автоматически. Использование SBT для Gatling по большей части вопрос удобства.
Для того, чтобы ширина сетевого канала не являлась ограничением необходимо генерировать нагрузку с машин, которые находятся в одной локальной сети, что и тестируемый сервер. Мы запускаем тесты внутри локальной сети с высокопроизводительных машин(8 CPU, 32 Gb RAM). Ваш подход запуска скриптов из Amazon S3 лучше, чем генерировать нагрузку удаленных серверов из офисных машин. Лучшей практикой будет являться, если вы разместите тестовую среду в облаке Amazon, по возможности с идентичными ресурсами что и продуктивная среда, а также в одном сетевом сегменте.
Протокол HTTP/2 не поддерживает, но поддержку практически любого протокла всегда можно реализовать самостоятельно. В статью добавили раздел «Реализация расширения для Gatling», где показано как можно заставить Gatling работать со своим кодом.
Приложение собирают разработчики и выкладывают билд в hockeyApp. Experitest предоставляет файл Experitest.framework, который разработчики встраивали в приложение и для поддержки iOS10 мы этот фреймворк обновляли
Документация не поменялась. Единственный момент, не знаю было ли раньше, но сейчас можно получить конфигурационный файл со всеми параметрами и объяснениями через sbt команду:
gatling:copyConfigFiles
Насчет второго. Мне помогла принудительная проверка таймаута в таком виде:
Содержание файла: login;password
nameasd;passasd
asdname;sdsfjksdfk
...
Чтобы посчитать критическую нагрузку на сайт(на самом деле на одну из бек систем), мы линейно увеличиваем число потоков, при этом мониторим, например, через jmx бек. Также на графике «число ответов в секунду», можно будет выделить момент, при каком числе потоков(клиентов) начинается увеличение числа ошибок.
Да KO это ошибки.
2000 запросов это общее число запросов для этого метода за все время нагрузки. Каждый клиент вызывал этот метод 15 раз
Да. Также из коробки есть поддержка wss, jms и sse. А так в общем вы можете создать любое «brute force» приложение, в статье я написал, что внутри блока
exec( session => {
// ваш код
})
можно писать любой scala код. Так что тут ограничиваемся только своей фантазией и возможностями Scala/Java.
1. Если я верно понял ваш вопрос. Тестовые данные, использующиеся в процессе работы теста и являются эталонными. То есть, они заведомо верны, даже для негативных проверок. Стараемся все тестовые данные выносить из самых BDD-кейсов, оставляя только «привязки» к их расположению в БД через API.
2. Да, пользователь сам формирует свои тестовые данные. Это полностью его ответственность. Однако, есть тестовые данные которые являются общими, и мы, автоматизаторы, помогаем их формировать: например, тестовые учетные записи для входа в Интернет-банк.
3. Программисты могут писать свои кейсы, если посчитают нужным. Это приветствуется, но не пока обязательно. У самых программистов большое желание использовать наши web-интерфейсные автотесты для проверки корректности выполнения своих задач, сейчас работаем над этим.
Сценарий происходящего, если его сильно утрировать, следующий:
1. Менеджеры создают новую задачу в багтрекинге и ставят постановку в формате BDD
2. Задача поступает технологам и детализируется ими для разработчиков, задача дополняется новыми BDD-кейсами
3. Задача поступает разработчикам, которые видят всю постановку в формате BDD и начинают её реализовывать. Попутно они могут пополнить постановку своими кейсами
4. Задача поступает в тестирование. Тестировщик получает готовые сценарии для тестирования и быстро их переносит в BDD-фреймворк. Плюс дополняет задачу всеми BDD-кейсами, которых не хватает в постановке и переносит во фреймворк и их
5. Новый BDD-кейс проходит ревью, и если этому кейсу чего-либо не хватает, создается задача на автоматизаторов
6. Новый BDD-кейс попадает в рабочую ветку авторегресса. И его можно использовать при регрессе
Наш плагин в репозитории JetBrains будет загонять пользователей под наши жёсткие рамки формата описания элементов. Плагин должен быть гибким. Будет более правильным выложить исходники в github, и такие мысли у нас есть, и дать возможность пользователям собирать плагин под себя. Или реализовать возможность редактирования формата описания элементов прямо через сам плагин и залить в jetbrains-repo такой вариант.
Заинтересованные в плагине нас стимулируют)
Внедрение заняло пол года и проходило поэтапно: начинали с создания ядра фреймворка с привлечением одного специалиста и затем вводили новые ресурсы по мере наращивания объемов BDD-кейсов. На данный момент мы имеем 30 функциональщиков, пишущих BDD-кейсы и 6 автоматизаторов, успевающих автоматизировать новый функционал и поддерживать большой объем текущих кейсов. Развиваем автоматизацию совместными усилиями — в автоматизации теперь заинтересованы и функциональщики, и автоматизаторы. Все чувствуют фидбек от своей работы.
Вопрос об оправданности внедрения методологии у нас не возникает. Имеем значительную разницу между тем, что было до внедрения BDD, и что стало после. Повысили показатели по и как по объемам автоматизации, так и по скорости. Плюс имеем много дополнительных приятных моментов, начиная от прозрачности процесса автоматизации и заканчивая дополнительной мотивацией функциональщиков в их развитии как специалистов.
Рядовые разработчики положительно восприняли новость о внедрении BDD, активно помогают нам со своей стороны. А самое главное, скоро оно начнут полноценно пользоваться нашими автотестами. Надеемся сократить количество возвратов задач тестировщиками на разработчиков.
Кто знает, возможно это первые шаги к Continuous delivery.
Если возникнут трудности — пишите в личку.
1) в финальном отчете выставляем фильтры в соответствии с изменениями и принимаем эти риски (например обновили стили, поэтому в отчете убираем из фильтрации ошибки css)
2) Если изменения касаются конкретных элементов, то убираем из списка локаторов те, что ссылаются на измененный (что тоже несет некоторые риски)
Для подстраховки используем скриншот-тесты отдельных компонент в Storybook: верстка, как правило меняется не радикально, а лишь отдельные элементы (банеры, кнопки, и т.д.). В storybook компоненты вынесены на отдельные страницы. Так, что проверка изменений не занимает много времени даже при «ручном» тестировании, а проверка остальных компонент на отсутствие изменений уже с помощью Qvisual.
Анимацию и динамический контент (банеры с рандомными рекомендации продуктов, например) перед снятием снапшота удаляем со страницы при помощи js. Потом отдельно проверяем другими тестами (иногда руками).
Суть нашего подхода в том, что человек нужен только для разбора упавших тестов (сравнений).
Белая точка действительно не попала в выделенную зону. Финальная картинка не была получена в результате сравнения нашим инструментом. Но смею заверить, наш инструмент нашел бы ее ;)
Так как мы используем Continuous Integration, то нам необходимо запускать тесты из TeamCity, SBT позволяет это сделать. Также мы используем в нагрузочных тестах различные библиотеки, которые SBT загружает автоматически. Использование SBT для Gatling по большей части вопрос удобства.
Для того, чтобы ширина сетевого канала не являлась ограничением необходимо генерировать нагрузку с машин, которые находятся в одной локальной сети, что и тестируемый сервер. Мы запускаем тесты внутри локальной сети с высокопроизводительных машин(8 CPU, 32 Gb RAM). Ваш подход запуска скриптов из Amazon S3 лучше, чем генерировать нагрузку удаленных серверов из офисных машин. Лучшей практикой будет являться, если вы разместите тестовую среду в облаке Amazon, по возможности с идентичными ресурсами что и продуктивная среда, а также в одном сетевом сегменте.
Да, поддержка WebSockets есть.
Протокол HTTP/2 не поддерживает, но поддержку практически любого протокла всегда можно реализовать самостоятельно. В статью добавили раздел «Реализация расширения для Gatling», где показано как можно заставить Gatling работать со своим кодом.
Насчет второго. Мне помогла принудительная проверка таймаута в таком виде:
В этом случае если вдруг коннект повиснет, то через 10 секунд вылетит ошибка Check failed: Timeout
По поводу их модели ничего сказать не могу. Всегда хватало бесплатной версии.
login;password
nameasd;passasd
asdname;sdsfjksdfk
...
Чтобы посчитать критическую нагрузку на сайт(на самом деле на одну из бек систем), мы линейно увеличиваем число потоков, при этом мониторим, например, через jmx бек. Также на графике «число ответов в секунду», можно будет выделить момент, при каком числе потоков(клиентов) начинается увеличение числа ошибок.
Да KO это ошибки.
2000 запросов это общее число запросов для этого метода за все время нагрузки. Каждый клиент вызывал этот метод 15 раз
можно писать любой scala код. Так что тут ограничиваемся только своей фантазией и возможностями Scala/Java.
1. Если я верно понял ваш вопрос. Тестовые данные, использующиеся в процессе работы теста и являются эталонными. То есть, они заведомо верны, даже для негативных проверок. Стараемся все тестовые данные выносить из самых BDD-кейсов, оставляя только «привязки» к их расположению в БД через API.
2. Да, пользователь сам формирует свои тестовые данные. Это полностью его ответственность. Однако, есть тестовые данные которые являются общими, и мы, автоматизаторы, помогаем их формировать: например, тестовые учетные записи для входа в Интернет-банк.
3. Программисты могут писать свои кейсы, если посчитают нужным. Это приветствуется, но не пока обязательно. У самых программистов большое желание использовать наши web-интерфейсные автотесты для проверки корректности выполнения своих задач, сейчас работаем над этим.
Сценарий происходящего, если его сильно утрировать, следующий:
1. Менеджеры создают новую задачу в багтрекинге и ставят постановку в формате BDD
2. Задача поступает технологам и детализируется ими для разработчиков, задача дополняется новыми BDD-кейсами
3. Задача поступает разработчикам, которые видят всю постановку в формате BDD и начинают её реализовывать. Попутно они могут пополнить постановку своими кейсами
4. Задача поступает в тестирование. Тестировщик получает готовые сценарии для тестирования и быстро их переносит в BDD-фреймворк. Плюс дополняет задачу всеми BDD-кейсами, которых не хватает в постановке и переносит во фреймворк и их
5. Новый BDD-кейс проходит ревью, и если этому кейсу чего-либо не хватает, создается задача на автоматизаторов
6. Новый BDD-кейс попадает в рабочую ветку авторегресса. И его можно использовать при регрессе
Заинтересованные в плагине нас стимулируют)
Вопрос об оправданности внедрения методологии у нас не возникает. Имеем значительную разницу между тем, что было до внедрения BDD, и что стало после. Повысили показатели по и как по объемам автоматизации, так и по скорости. Плюс имеем много дополнительных приятных моментов, начиная от прозрачности процесса автоматизации и заканчивая дополнительной мотивацией функциональщиков в их развитии как специалистов.
Рядовые разработчики положительно восприняли новость о внедрении BDD, активно помогают нам со своей стороны. А самое главное, скоро оно начнут полноценно пользоваться нашими автотестами. Надеемся сократить количество возвратов задач тестировщиками на разработчиков.
Кто знает, возможно это первые шаги к Continuous delivery.