| Если хочется | , то для этого нужно | и скиллы ролей |
|---|---|---|
| проектирования и разработки автотестов | 1. Сначала нужно провести тест-анализ продукта/сервисов — выявить требования, определить процент покрытия их существующими тестами, определить технологический стек, используемый тестируемыми сервисами и их БД. | тест-аналитика, лида |
| 2. Определиться с уровнем тестирования: фронт, бэк, UI, API (web REST, web не REST, RPC,...), десктоп/мобильное приложение и т.п. | тест-аналитика | |
| 3. Определиться каким образом будем тестировать: функциональное, интеграционное, нагрузочное. | тест-аналитика | |
| 4. Исходя из п.1-3 подобрать ЯП и фреймворк (готовый или создавать самим) для автотестов.
Используем ли Selenium для UI, используем ли Cucumber с его Gherkin. И т.п. |
опытного разработчика автотестов, тест-аналитика | |
| 5. Для подачи на вход автоматизаторам, требуется, чтобы кто-то составлял тест-кейсы по требованиям. Возможно, это будет тест-аналитик или сами тестировщики.
Требуется удобный инструмент для хранения тест-кейсов (какой-нибудь древний HP ALM, современная Jira-плагин TM4J, что-то ещё. |
тест-аналитика, тестировщика | |
| 6. Непосредственно разработка автотестов.
Требуется обеспечить разработчиков удобной IDE (платной/бесплатной), исходя из выбранных языков/фреймворков в п.4. |
разработчика автотестов | |
| 7. Исходя из п.1-3 можно уже сколько и каких сервисов требуется развернуть для тестирования.
Таким образом выходим на технические требования к тестовому стенду (CPU/RAM, OS, будет ли это Openshift и прочее и прочее) и БД на них. Нужны ли в наличии актуальные мобильные устройства для прогона на них автотестов. Далее происходит обсуждение с ЛПР есть ли бюджет на покрытие этих технических требований, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс "торговли" за бюджет и поиски компромисса. |
||
| встраивания автотестов в CI/CD | 8. Выбрать инструмент для CI/CD. Возможно, решено использовать Jenkins как один из самых распространённых, по установке/настройке/решению проблем с которым легко найти ресурсы в Сети.
Определить как будут запускаться job'ы с автотестами, на каких машинах, с какими параметрами, в каком виде мы хотим получать отчёт о тесте (Allure, кастомные виды представлений,...). Определить на какой машине с какими ресурсами будет размещён выбранный инструмент, какая там будет ролевая модель (кто будет иметь права на запуск/редактирование job'ов). Если делать это всё без инструмента, т.е. запуск будет производиться вручную или средствами cron в linux или job'ов Windows — то всё равно это требует обсуждения. |
любого кто пользовался выбранным инструментом CI/CD
-- разработчика автотестов, администратора, тестировщика... |
|
* методик нагрузочного тестирования,
* разработки и актуализации средств нагрузочного тестирования (сценарии и скрипты НТ , эмуляторы, скрипты генерации данных , скрипты анализа результатов), |
9. После п.1 провести тест-анализ сервисов в разрезе именно нагрузочного тестирования, в т.ч. получение профия нагрузки с ПРОДа, опрос администраторов, поддерживающих ПРОД и т.п.
Отталкиваясь от требований, определить что следует нагружать и каким образом, какими способами будем измерять, какие метрики будем использовать. |
тест-аналитика, тестировщика-нагрузочника |
| 10. Определить какие технические ресурсы нам потребуются для реализации задуманного по НТ.
Провести обсуждение с ЛПР есть ли бюджет на такие ресурсы, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс "торговли" за бюджет и поиски компромисса. |
тестировщика-нагрузочника, архитектора, тест-аналитика, лида | |
| 11. На основании тест-анализа в разрезе НТ из п.9 спроектировать сценарии НТ, определить необходимость скриптов анализа данных, учесть их в сценариях. | тестировщика-нагрузочника, тест-аналитика | |
| 12. На основании сценариев НТ из п.9 определяем необходимость подготовки данных в БД. Какие они должны быть. Нужно ли их подготавливать отдельными скриптами или же можем себе позволить репликацию с БД прода полностью или частично. | тестировщика-нагрузочника, тестировщика данных, тест-аналитика | |
| 13. На основании тест-анализа из п.1 и п.9 определяем нужны ли нам заглушки, моки, синтетические тестовые приложения (имитирующие поведение задействованных в сценарии сервисов) | тестировщика-нагрузочника, разработчика автотестов, тест-аналитика | |
| 14. Непосредственно разработка скриптов НТ. | тестировщика-нагрузочника, разработчика автотестов | |
| 15. На основании данных из п.10 и п.12 провести обсуждение с ЛПР есть ли бюджет на такие ресурсы, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс "торговли" за бюджет и поиски компромисса. | тестировщика-нагрузочника, архитектора, тест-аналитика, лида. | |
| поддержки разработанных автотестов | - | разработчика автотестов и немного тест-аналитика. |
Автотесты пишутся на фреймворке XXX.
Принцип работы автотестов:
Создадим примитивные helloworld GUI-тест и API-тест с использованием Java, Maven, Cucumber (+JUnit) и Selenium.
Нижеизложенное выполнялось под Windows 10 и Intellij IDEA Ultimate 2020.1.