В JMeter есть возможность записывать сценарии с помощью прокси. Берем тест-план, начинаем запись, ходим по страницам, останавливаем запись. Вычищаем запросы к статике и внешним ресурсам (политика зависит от целей тестирования: лоад/стресс). Ставим задержку на выполнение каждого потока со случайной погрешностью N +- M секунд. В чем грубость? Статику по-хорошему все-равно надо выносить на отдельный домен и там тестировать уже отдельно.
Давно пытаюсь найти информацию о возможности управлять газовым котлом. Есть ли какие-то наработки в этом направлении? На сколько я понимаю есть 2 пути:
1) искать вендора, предлагающего какой-то API для котла (такого я не видел)
2) самому делать делать контроллер, с вероятностью взорвать котел.
ИМХО, лучше даже не пытать проводить нагрузочное тестирование с помощью Selenium. Достоверные результаты можно получить, запустив JMeter с нескольких хостов. Однажды тестировали приложение, которое хостилось в Бельгии. Результаты одного и того же тест-плана, запущенного с компьютеров в Праге, Москве и Антверпене были разные, но в пределах одной статистической погрешности.
На моей практике просто очень хорошие менеджеры получаются из разработчиков с развитым социальным компонентом: люди с большим опытом разработки, которые смещаются в менеджмент. С такими людьми всех этих проблем просто не возникает. Другой вопрос, что людей у которых хорошо развита и «техническая» и «гуманитарная» составляющая довольно мало.
Да, перепутал. Спасибо. Я на сайте и прочитал. У них просто филиал на Кипре есть — в голове перемешалось.
Думаю вы согласитесь, что это не меняет сути моего комментария.
Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.
SpecFlow — плагин для Visual Studio — такой Cucumber для .NET. Будут рассмотрены базовые понятия и сложные сценарии.
Последний пост будет про то, как к этому привязать Selenium WD, встроить в CI и создавать автоматические отчеты.
Юлия, этот процесс призван решить следующие проблемы:
Необходимость дублирования данных — BRD, Test Cases, техническая спецификация. С помощью такой записи мы получаем это в одном файле с описание стори. В этот файл входит user-storiy, сценарии, примеры.
Устаревание спецификации. Конечно это надо подписать. Никто не спорит, но дальше у Вас будут чейндж-реквесты. Вам придется внести их в BRD, поправить тест-кейсы и тест-план, исправить логику, определить, какие тесты более не актуальны. В данном случае все произойдет «автоматом». Пришел чейндж-реквест: не беда. Убираем лишнии сценарии или шаги из сценариев. Соответствующие тесты автоматически перестанут выполняться (как это происходит, я опишу вследующей статье)
«Неправильные стори». Нельзя давать бизнесу диктовать стори. У клиента может быть слишком узкое видение. Есть пример с Бельгийской компанией, которая хотела разработать веб-приложение, вместо существующего десктопного из-за того, что они выросли и вместо 1 клиента стало много. Разработку оценили в 40.000 евро, кажется. Проблему решили тем, что вытащили десктопный-клиент на RDP и административными мерами разрешили заходить на RDP одним с 13:00 до 13:30, другим с 13:30 до 14:00 и т.д. Специфика системы была такова, что частое обновление данных не требовалось, а на чтение все работало отлично, через открытый порт. Решилось за 500 евро и 2 дня работы
Далеко не в каждой компании есть аналитик, который, особенно, запишет требования в адекватном техническом виде, мы живем реальном мире
В ситуации, где я опрашивал народ, была документация и BRD. Неполная и outdated и без покрытия тестами, так что толку от этой спеки не было.
Попробуйте смотреть на проблему немного шире. Это как раз решение для реального мира, а не коней в вакууме.
Есть вариант держать «голову» за границей. Альпари, например на Кипре зарегистрирована, что не мешает существовать казанскому филиалу, из которого компания и выросла.
Не предполагается, что примеры пишет разработчик, когда мы работали по этой схеме сценарии писали как QA, так и разработчик. После этого мы оба их правили (QA добавлял правильные кейсы, я помогал с автоматизацией, мы вместе исправляли неточные места). Таким образом, разрушается стена между отделами QA и Dev. Мое личное мнение, что это — очень хорошо.
Спецификация становится исполняемой, т.е. спецификация, приемочные критерии, приемочные тесты и тест-кейсы — все в одном месте. Документ, который вы составите и будет вашим BRD. (QA не кидайтесь помидорами, сначала посмотрите презентацию Алименкова).
Избыточность вы должны будете удалить на этапе refining the specification.
Схему базы данных вообще я предпочел бы не показывать в BRD — клиенту по барабану что у вас там SQLServr, MongoDB или ваш другой теплый ламповый способ хранения данных
Алгоритмы в спецификации не расписываются — в ней расписываются сценарии. Если вы думаете, что это бесполезная информация, вы, вероятно, не работали с системами, которым по 5-6 лет, спецификацию которых никто не составлял/не поддерживал. Существует даже термин «Code Archiology» — выделение бизнес-логики из кода. Серьезно, такое бывает. В одной компании для составления плана работ мне пришлось опросить 5 человек (в т.ч. начальников всех отделов и ген.директора) и порыться в исходниках, чтобы построить диаграммы процессов.
На сколько я понял речь идет о понятиях, которые не совсем привычны нам. На западе существует терминология employee — сотрудник на зарплате и independent consultant — то, что мы назвали бы фрилансером. Разница в том, что в Европе тот самый индепендент консалтант — оформлен как ИП и может запросить до 600 евро в день и более. Учитывайте, что в Бельгии, например, вы будете отдавать 20 евро за парковку ежедневно и около 7-10 евро за скромный ленч. + Пропахать 70км до работы — в порядке вещей. Многие европейские экономисты полагают, что те самые индепендент консалтенты — это основная движущая часть европейской экономики сейчас, потому что они создают рабочие места (аутсорс бухгалтерии, налоговый консльтант, бензин и т.д.). То есть единицей бизнеса становится не компания, а один человек, бизнесс которого продавать свои уникальные знания.
А вот те профессии, которые не требуют высокой квалификации будут автоматизироваться и отдаваться на полный аутсорс (в т.ч. за счет миграции в страну). Дело в том, что уже сейчас даже если вы получаете, так называемую «визу раба» в Евросоюз или США, это вообще не гарантирует вам получение даже вида на жительства, а не то, что гражданства.
Мне приходилось работать с человеком, которого зовут Guillaume Schuermans. Даже его имя никто из команды, в который был русский, белорус и чех, не произнес правильно. С тех пор придерживаюсь правила «не уверен — не играй».
1) искать вендора, предлагающего какой-то API для котла (такого я не видел)
2) самому делать делать контроллер, с вероятностью взорвать котел.
Думаю вы согласитесь, что это не меняет сути моего комментария.
SpecFlow — плагин для Visual Studio — такой Cucumber для .NET. Будут рассмотрены базовые понятия и сложные сценарии.
Последний пост будет про то, как к этому привязать Selenium WD, встроить в CI и создавать автоматические отчеты.
В ситуации, где я опрашивал народ, была документация и BRD. Неполная и outdated и без покрытия тестами, так что толку от этой спеки не было.
Попробуйте смотреть на проблему немного шире. Это как раз решение для реального мира, а не коней в вакууме.
А вот те профессии, которые не требуют высокой квалификации будут автоматизироваться и отдаваться на полный аутсорс (в т.ч. за счет миграции в страну). Дело в том, что уже сейчас даже если вы получаете, так называемую «визу раба» в Евросоюз или США, это вообще не гарантирует вам получение даже вида на жительства, а не то, что гражданства.