'

Опыт создания системы управления сборкой и тестированием

Понравилась презентация – покажи это...





Слайд 0

Опыт создания системы управления сборкой и тестированием Олег Ладыгин oladygin@gmail.com Часть 0 - теоретическая


Слайд 1

О чем речь вообще? Где взять дистрибутив? Что реализовано? Что делает этот тест? Тест валиден для этой версии? Когда тестировать? Какая сборка стабильная? … кто здесь?!… А если сотни подсистем? А если тысячи тестов? Как этим управлять? Модель «Организационная жаба»


Слайд 2

Сначала надо подумать Прежде чем что-то разработать, надо определить: кто этим будет пользоваться; с чем он уже работает; какую часть можно улучшить. В итоге – надо подумать.


Слайд 3

артефакты Дистрибутив Исходный код Сборка Тест Стабильная сборка Тип теста Дефекты Bug-tracking Система управления версиями (CVS) Регулярная сборка и тестирование … Отгрузка Сервера и платформы Ресурсы Отчеты


Слайд 4

Автоматизируем? Надо формально описать. Как выглядит сборка Как выглядит тестирование


Слайд 5

Как еще выглядит сборка Как еще выглядит тестирование Вариант описания - дерево Что значит «ВЗЯТЬ»? Только последний? Где-то конкретно указанный? Стабильную сборку?


Слайд 6

Блоки сборки, теста, подготовки среды можно описать единообразно. Так как все эти действия совершаются не просто так, а преследуют некоторую цель, назовем это все Целью, которая либо достигается, либо используются ее результаты. Что внутри прямоугольничков? Происходит выполнение какой-то команды


Слайд 7

Зачем нужна структура? Автоматический поиск и выбор необходимых методов и данных.


Слайд 8

Объединим все в сложную схему…. Если совместить предыдущие слайды, получится очень большая и красивая схема. При наличии бинокля ее можно будет разглядеть. Или можно порисовать самостоятельно вместо перекура…. Цели либо выполняются, либо доставляются ее результаты. Если одновременно есть и выполнение, и использование, то создаются связи. Как действовать, если цель не выполнилась, и какие результаты какого именно выполнения надо использовать?


Слайд 9

Превратим дерево в граф Если множество целей выполняются в едином пространстве – то свяжем все одинаковые цели между собой, и будем использовать именно их результаты. Иначе будем использовать на выбор: самые достоверные результаты, последние, заданные вручную. Что получим в переводе «на пожрать»? При одиночном запуске теста берутся стабильные дистрибутивы. При запуске теста и сборки тестируется только эта сборка Опционально можно сделать и так: При запуске теста выбирается дистрибутив из списка успешных Если стадия разработки – берется последний, если в тестировании – переданный на тестирование.


Слайд 10

Связи - автоматические Билд 3 Билд 2 Билд 1


Слайд 11

Управление ресурсами Не хватает одной детали – управления последовательностью запуска тестов и подготовкой среды их выполнения. Ресурс – это БД, общие файлы, данные, схемы, сервера и т.д. Цель требует ресурсы для запуска, в Exclusive или Shared режиме. Каждый ресурс имеет номинальную мощность, а цель – требуемую. Цель может создать ресурс после своего выполнения Группировка ресурсов по серверам или БД


Слайд 12

Подготовка – как ресурс Логика ресурсного планирования обеспечивает не только последовательность и непротиворечивость работы, но и удобство. Тест L1 требует БД монопольно для crush-теста, БД должна быть поднята из снапшота M Тест F2 требует БД для unit-теста, на БД должны быть данные набора К При активации ресурса производится поднятие БД из снапшота М При активации ресурса производится заполнение БД тестовыми данными набора К


Слайд 13

Итог – придумали описание далее – представим модель Необходимо описать сборку дистрибутива Необходимо задать структуру тестов Можно задать последовательность тестов, если требуется Тесты описываются любым членом команды и легко доступны Тесты разбиты по классам, что позволяет работать с ними единообразно Интерфейс!


Слайд 14

Требования к интерфейсу ГОСТ 19.201-78* Единая система программной документации. Техническое задание. Требования к содержанию и оформлению 18.12.1978 ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения. требования к информационной и программной совместимости: United System for Program Documentation. Technical specification for development. Requirements to contents and form of presentation 2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть Требования: Все должно быть максимально просто. Можно собрать дистрибутив и его протестировать Можно выполнить все тесты или только часть Должны учитываться «ресурсы» (базы, сервера…), используемые для тестирования, прозрачно и автоматически Все должно быть очень быстро. Все должно быть очень прозрачно. Кто, куда, когда, и сколько.


Слайд 15

Быстро Напишем весь код HTTP SOAP SOAP/SQL SQL SSH FTP MVFS Интерфейс Ядро и прочее


Слайд 16

Включаем, все работает Представим, что ядро запущено, интерфейс не тормозит, задачи сборки/тестирования выполняются. И при этом нет ни одной проблемы в инфраструктуре. Как все это выглядит? Разработчики – указывают в билдах, что именно реализовано или исправлено. Они же видят тесты и результаты. А тестировщики? Как это выглядит для них?


Слайд 17

Тестирование как работа Получение билда Ожидать письма от разработчика, где есть ссылка на дистрибутив, список реализованной функциональности, результаты пройденных тестов. Или найти это все через веб. Выполнение тестирования Нажать кнопку «выполнить все» или выбрать, что же именно выполнить. Оповещение разработчика В вебе найти кнопку «завершить тестирование билда» – формируется отчет с созданными или закрытыми дефектами. Написание тестов Создать файл в каталоге подсистемы, в котором написать тест, предполагая, что дистрибутив уже установлен/запущен. В вебе добавить описание и интервал версий, для которых тест валиден. Отчет о проделанной работе Составляется автоматически – кто и что обнаружил, какие тесты написал.


Слайд 18

Как это работает, п. 1 Оповещение о разработанной функциональности, открытых и закрытых дефектах. Исходные требования к подсистеме к моменту начала разработки превращаются в дефекты типа «пожелание по доработке» Разработчик, создавая заявку на сборку, ставит галочки против открытых дефектов. Эта информация присутствует в отчете о сборке. Если тест завершается с ошибкой, по его «результатам» создаются дефекты. Если дефект с таким именем уже есть и якобы исправлен – он открывается заново. Если тест успешен, дефект закрывается. По окончании тестирования - отчет с разницей дефектов в начале и в конце тестирования.


Слайд 19

Как это работает, п. 2 Создание тестов В первую очередь, тест надо написать и куда-то положить. Положим его в специальный каталог рядом с подсистемой. Не надо думать о том, где взять дистрибутивы – система сама положит их рядом и распакует, если необходимо. Далее, надо описать тест как кирпичик. Указать исходные файлы теста, команду, и ожидаемые результаты. Указать тип теста. Предыдущий пункт может сделать робот, который ходит по файловой системе. Если тест требует ресурсов, например, выделенный БД, или подготовленной среды переменных окружения, это тоже надо заполнить. Не нужно описывать то, когда будут запущены тесты, и вообще об этом думать. Достаточно указать, что он есть.


Слайд 20

Как это работает, п. 3 Выполнение тестирования Система знает, какие тесты существуют для данной версии подсистемы. Они все будут запущены единообразно. Если нужна более сложная последовательность, необходимо описать ее, к примеру, так: для подсистем А и Б есть тесты: функциональные Func-A1, Func-AB, Func-B1 нагрузочные Load-A1, Load-B1


Слайд 21

Часть 0 - теоретическая Часть 1 - практическая


Слайд 22

Что же на практике? Подробнее о ядре Ресурсы – подробнее Выполнение задач - подробнее Но это только теория. На практике, у нас еще есть: Регулярное тестирование – кодировки файлов, контроль русских символов, контроль правописания… Выполнение задач по событиям (изменения статусов дефектов, наступление пятницы 13…) Автоматическая чистка процессов на серверах Управление нагрузкой Средства формирования и рассылки отчетов


Слайд 23

Подробнее о ресурсах Ресурс - это именованная запись, имеющая один и более «экземпляров», каждый из которых имеет некоторую «удельную мощность», и может быть «привязан» к серверу. Захват полной группы – одновременный захват всего списка Групповой захват – группа должна быть одинакова Одновременный захват ресурсов для группы целей Разный тип ресурса – разная процедура активации Каждый ресурс имеет набор параметров и группу Пользовательские и системные ресурсы Конструкторы и деструкторы ресурсов


Слайд 24

Подробнее о задачах Задача – запись о том, что некоторая версия цели должна быть выполнена на некоторой платформе.


Слайд 25

Регулярное тестирование Если состав дистрибутивов известен и поддается автоматическому анализу, мы можем вытащить все исходные коды, находящиеся в разработке, и проверить: Орфографию Web-части: проверить кодировку соответствие правилам разработки - SQL : контроль русских символов список пакетов pl/sql, их состав и взаимные вызовы Исходный код: изменение SLOC матерный словарь


Слайд 26

Выполнение задач по событиям Если для запуска любого теста или сборки достаточно пройти по своей БД и вызвать функцию запуска, то: Дополнительно – внешний конвейер событий. Что туда положила внешняя система – будет исполнено. Это механизм scheduler-а на всей инфраструктуре. Или просто мега-триггер на какие-либо изменения. Если не отключен режим автосборки – то собирать каждую ночь и выполнять все тесты Для больших тестов – запускать, к примеру, по пятницам в 22:00 Для контроля оперативных данных – формирование отчетов каждые 2 часа


Слайд 27

Автоматическая чистка процессов Задачи выполняются на серверах через SSH. Есть системный ресурс – логин из пула пользователей. Активация – удаляются все процессы этого пользователя на сервере. Выполняется произвольный пользовательский код Деактивация – так же удаляются все процессы Unix – kill, Windows – WinSSHd Дополнительно – робот удаления процессов старше 7 дней и defunc-процессов


Слайд 28

Управление нагрузкой, выбор сервера Управление нагрузкой – выбор сервера из нескольких доступных Эксклюзивный захват сервера Активация сервера – установка набора переменных окружения


Слайд 29

формирование и рассылка отчетов Отчет – лишь цель определенного типа Пусть она возвратит нам index.html как результат своей работы Выполнение – по заказу или по расписанию


Слайд 30

Часть 0 – теоретическая Часть 1 – практическая спасибо Олег Ладыгин oladygin@gmail.com


×

HTML:





Ссылка: