Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.

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

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

4. с чем он уже работает;

5. какую часть можно улучшить.В итоге – надо подумать.

7. Исходный код

8. Сборка

9. Тест

10. Стабильная сборка

11. Тип теста

12. Дефекты

13. Bug-tracking

14. Система управления версиями (CVS)

15. Регулярная сборка и тестирование

16. …

17. Отгрузка

18. Сервера и платформы

19. Ресурсы

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

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

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

25. Если одновременно есть и выполнение, и использование, то создаются связи.

31. Цель требует ресурсы для запуска, в Exclusive или Shared режиме.

32. Каждый ресурс имеет номинальную мощность, а цель – требуемую.

33. Цель может создать ресурс после своего выполнения

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

37. Необходимо задать структуру тестов

38. Можно задать последовательность тестов, если требуется

39. Тесты описываются любым членом команды и легко доступны

40. Тесты разбиты по классам, что позволяет работать с ними единообразноИнтерфейс!

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

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

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

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

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

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

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

51. Выполнение задач по событиям (изменения статусов дефектов, наступление пятницы 13…)

52. Автоматическая чистка процессов на серверах

53. Управление нагрузкой

55. Групповой захват – группа должна быть одинакова

56. Одновременный захват ресурсов для группы целей

57. Разный тип ресурса – разная процедура активации

58. Каждый ресурс имеет набор параметров и группу

59. Пользовательские и системные ресурсы

62. Web-части:

63. проверить кодировку

64. соответствие правилам разработки -

65. SQL :

66. контроль русских символов

67. список пакетов pl/sql, их состав и взаимные вызовы

68. Исходный код:

69. изменение SLOC

71. Для больших тестов – запускать, к примеру, по пятницам в 22:00

73. Выполняется произвольный пользовательский код

74. Деактивация – так же удаляются все процессы

75. Unix – kill, Windows – WinSSHd

77. Эксклюзивный захват сервера

79. Пусть она возвратит нам index.html как результат своей работы