http://www.protesting.ru/automation/practice/automation_from_scratch.html
1. Определяем требования к системе автоматизированного тестирования
2. Определение компонентов системы.
Автоматический инсталлятор приложения, а также сопутствующая ему функциональность для получения новой версии из репозитория, ftp, либо другого места куда автоматически выкладываются сборки поможет вам избежать выполнения всех этих действий вручную, а значит – освободит время на другие задачи.
Автоматизированные тесты (скрипты + фреймворк для их выполнения). Этот компонент включает всю инфраструктуру тестов - компоненты для работы с удаленной и локальной файловой системой, сервисами/демонами, фреймворк для работы с формами приложения и, собственно, сами тест-скрипты.
Автоматический деинсталлятор приложения. Его лучше будет вызывать перед инсталляцией новой версии. Это также освобождает время на другие задачи. Вместо него можно использовать полное восстановление системы (например, из полного бэкапа диска).
Автоматизированная система восстановления рабочей среды.
Автоматизированная система хранения результатов автоматических тестов. Для построения графиков ретроспективы, выявления ошибок в тестах, оценки динамики роста/падения качества приложения необходимы не только последние, но и предыдущие результаты автотестов. Лучше хранить их в базе данных, так как она обеспечивает более богатые возможности манипуляции данными.
Автоматизированная система формирования и рассылки результатов тестов.
3. Определение компонентов для разработки
На данном этапе вы уже должны определиться со списком и приоритетами задач по автоматизации и решить, какие задачи решать с помощью готовых компонентов, а что разрабатывать самому.
4. Оценка объемов работы.
После того как выбор компонентов закончен, есть резон потратить некоторое время на осмысление того, что вам предстоит сделать. Естественно, готовые компоненты не нуждаются в оценке. Оценивать нужно работу по их интерграции в вашу систему.
5. Разработка. Практические рекомендации.
5.1 WEB/GUI
1. Выделяем классы форм
2. Выносим общие методы взаимодействия с элементами из классов форм в общий суперкласс
3. Выносим данные теста из скрипта в подгружаемый файл (поддержка Data-Driven testing)
4. Создаем кейворды (поддержка Keyword-Driven testing)
5.2 Файловая система
копирование/создание/удаление/проверка существования файлов
архивация/разархивация файлов и каталогов
копирование файлов с/на целевую файловую систему
поиск в файлах по паттерну (логи) / изменение содержимого текстовых файлов (конфиги)
выполнение команд на удаленной системе и получение стандартного вывода (stdout) и ошибок (errout) от них.
5.3 Сервисы и демоны
Общий алгоритм такой:
1. Проверка состояния.
2. Если сервис/демон уже в нужном состоянии - выход.
3. Если достигнут таймаут запуска/остановки сервиса - выход с ошибкой.
4. Если сервис/демон в промежуточном состоянии (starting|stopping) - ждем таймаут и идем на шаг1.
5. Отдаем команду запуска/остановки сервиса.
6. Проверка состояния.
7. Если сервис/демон в нужном состоянии - выход.
8. Если достигнут таймаут запуска/остановки сервиса - выход с ошибкой.
9. Если сервис/демон в промежуточном состоянии (starting|stopping) - ждем таймаут и идем на шаг6.
5.4 Базы данных
Единый интерфейс для работы с базами данных будет полезен, если тестируемое приложение должно поддерживать работу на нескольких типах баз данных.
5.5 Отчеты
Время начала выполнения теста
Время завершения выполнения теста
Результат (passed / failed / blocked)
Полный лог выполнения теста и крайне желательно - с метками времени для каждой записи в логе
Номер билда для которого проводился тест
Конфигурация (аппаратная платформа + настройки) на которой проводился тест. (Актуально только если используется несколько конфигураций)
Скриншот (в сучае отличного от passed результата)
Еще одна большая тема. Всегда нужно помнить о том что отчеты - это результат вашей работы.
1. Определяем требования к системе автоматизированного тестирования
2. Определение компонентов системы.
Автоматический инсталлятор приложения, а также сопутствующая ему функциональность для получения новой версии из репозитория, ftp, либо другого места куда автоматически выкладываются сборки поможет вам избежать выполнения всех этих действий вручную, а значит – освободит время на другие задачи.
Автоматизированные тесты (скрипты + фреймворк для их выполнения). Этот компонент включает всю инфраструктуру тестов - компоненты для работы с удаленной и локальной файловой системой, сервисами/демонами, фреймворк для работы с формами приложения и, собственно, сами тест-скрипты.
Автоматический деинсталлятор приложения. Его лучше будет вызывать перед инсталляцией новой версии. Это также освобождает время на другие задачи. Вместо него можно использовать полное восстановление системы (например, из полного бэкапа диска).
Автоматизированная система восстановления рабочей среды.
Автоматизированная система хранения результатов автоматических тестов. Для построения графиков ретроспективы, выявления ошибок в тестах, оценки динамики роста/падения качества приложения необходимы не только последние, но и предыдущие результаты автотестов. Лучше хранить их в базе данных, так как она обеспечивает более богатые возможности манипуляции данными.
Автоматизированная система формирования и рассылки результатов тестов.
3. Определение компонентов для разработки
На данном этапе вы уже должны определиться со списком и приоритетами задач по автоматизации и решить, какие задачи решать с помощью готовых компонентов, а что разрабатывать самому.
4. Оценка объемов работы.
После того как выбор компонентов закончен, есть резон потратить некоторое время на осмысление того, что вам предстоит сделать. Естественно, готовые компоненты не нуждаются в оценке. Оценивать нужно работу по их интерграции в вашу систему.
5. Разработка. Практические рекомендации.
5.1 WEB/GUI
1. Выделяем классы форм
2. Выносим общие методы взаимодействия с элементами из классов форм в общий суперкласс
3. Выносим данные теста из скрипта в подгружаемый файл (поддержка Data-Driven testing)
4. Создаем кейворды (поддержка Keyword-Driven testing)
5.2 Файловая система
копирование/создание/удаление/проверка существования файлов
архивация/разархивация файлов и каталогов
копирование файлов с/на целевую файловую систему
поиск в файлах по паттерну (логи) / изменение содержимого текстовых файлов (конфиги)
выполнение команд на удаленной системе и получение стандартного вывода (stdout) и ошибок (errout) от них.
5.3 Сервисы и демоны
Общий алгоритм такой:
1. Проверка состояния.
2. Если сервис/демон уже в нужном состоянии - выход.
3. Если достигнут таймаут запуска/остановки сервиса - выход с ошибкой.
4. Если сервис/демон в промежуточном состоянии (starting|stopping) - ждем таймаут и идем на шаг1.
5. Отдаем команду запуска/остановки сервиса.
6. Проверка состояния.
7. Если сервис/демон в нужном состоянии - выход.
8. Если достигнут таймаут запуска/остановки сервиса - выход с ошибкой.
9. Если сервис/демон в промежуточном состоянии (starting|stopping) - ждем таймаут и идем на шаг6.
5.4 Базы данных
Единый интерфейс для работы с базами данных будет полезен, если тестируемое приложение должно поддерживать работу на нескольких типах баз данных.
5.5 Отчеты
Время начала выполнения теста
Время завершения выполнения теста
Результат (passed / failed / blocked)
Полный лог выполнения теста и крайне желательно - с метками времени для каждой записи в логе
Номер билда для которого проводился тест
Конфигурация (аппаратная платформа + настройки) на которой проводился тест. (Актуально только если используется несколько конфигураций)
Скриншот (в сучае отличного от passed результата)
Еще одна большая тема. Всегда нужно помнить о том что отчеты - это результат вашей работы.
Комментариев нет:
Отправить комментарий