- PVSM.RU - https://www.pvsm.ru -
(http://bp-la.ru/bespilotnyj-apparat-danem [1])
Билд => Тест => Не пройден => и километры логов, разбросанных по разным системам, и десятки минут сведения концов с концами в поисках причины сбоя. Знакомо?
А если иначе?
Билд => Тест => Не пройден => Тикет в JIRA — и разработчик берет баг в работу, потому как вся информация у него уже есть.
Работая в команде Acronis Kernel, я задался целью создать именно такой автотест.
Под катом — моя история.
Тестирование программного обеспечения — это исследование с целью снабдить заинтересованные стороны (Stakeholders, далее Заказчики) информацией о качестве продукта или услуги (из Википедии [2]).
Заказчики воспринимают результаты тестирования по-разному:
Данные должны быть доступны как можно скорее, в идеале — в реальном времени, сразу по появлению новой сборки продукта.
Теперь представим рабочий процесс, достаточный для выполнения указанных требований:
Здесь, в команде Acronis Kernel, мы построили такой процесс — не сразу, конечно.
Сперва расскажу, с чего мы начинали.
(http://spongebob.wikia.com/wiki/Primitive_Sponge [3])
Тесты шли несколько часов, часто давая случайный (невоспроизводимый) результат. Для анализа фейлов проходили целый квест с посещением ATMS, CC, шары с логами, детальным разбором логов и поиском аналогичных багов в Jira — все врукопашную.
Зарегистрированные сбои иногда воспроизводились, чаще — нет. По большинству заведенных багов разработчики просили уточнить шаги, предоставить виртуальную машину или приложить забытые логи.
Примерно раз в неделю ATMS падал. Если тест завис, или по другой причине ресурсы не освободились, приходилось вручную удалять виртуальные машины, снимать задачу в АТМС и обнулять счетчик занятости хоста.
Сравнить результаты тестов на разных сборках можно было по статичным email-репортам с графиком Тип результата / Номер сборки, или перебирая результаты вручную в СС. Чтобы сравнить результаты одного и того же теста на разных операционных системах, приходилось вручную просматривать логи тестов с каждой ОС.
В результате, девелоперы не доверяли автотестам, более полагаясь на ручной запуск собственных тестов на своем окружении. Подобная "механизация" меня никак не устраивала, ситуацию надо было исправлять.
(http://dkrack.wikispaces.com/Brave+New+World [4])
0 (ноль) велосипедов.
Pytest с помощью встроенной функции test discovery подбирает кейсы и стартует тест. Код фреймворка выполняется на Gate VM — контрольной машине, а System Under Test (в нашем случае kernel driver) разворачивается на Test VM, чтобы в случае BSOD не потерять результаты.
Стандартная python logging библиотека пишет info лог и debug лог в два разных файла:
a) Info лог содержит шаги теста и отвечает двум требованиям: 1) human readable формат, 2) информации достаточно для воспроизведения сбоя.
b) Debug лог включает таймштамп, адрес номер строки выполняемого кода и развернутое сообщение. Лог позволяет отследить детальную историю событий, прямо не относящихся к сути теста, но влияющих на результат: удалось ли установить соединение, сколько времени выполнялся ребут, etc.
Приведу схему для наглядности:
(© Acronis)
Имя бага добавляется суффиксом к имени VM, так что девелоперы легко могут найти машину при необходимости. Машинка, на которой воспроизвелся уже известный баг, будет автоматически удалена через три дня. Машинка с новым багом будет автоматически удалена после того, как разработчик переведет ее в статус Resolved, а соответствующий тест пройдет без ошибок.
(© Acronis)
Раньше автоматизатор вынужден был 80-90% времени тратить на ручной разбор результатов тестов. Теперь достаточно посмотреть на список багов в Jira. Баг продукта идет разработчикам, сбой тестов автоматизатор забирает себе. Если какой-то информации в баг репорте не хватает, не нужно учить людей заводить баги иначе — достаточно изменить код.
(© Acronis)
Поддержка тестов свелась к обработке в коде еще неучтенных видов сбоев. Corner cases будут всегда, это надо понимать, и не стоит ставить целью избавление от 100% сбоев автотестатестовой инфраструктуры. Достаточно превратить эти сбои в конкретные action items — баги в Jira, в нашем случае, и исправлять их один за другим.
Общий обзор состояния тестируемых компонент теперь можно получить, взглянув на Jenkins dashboard:
(© Acronis)
Дашборд реализован с помощью плагина https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View [5].
Возможно не все читатели знакомы с Jenkins, так что поясню значения колонок:
Систему, которую я описал выше, мы построили и отладили к концу осени прошлого года, и затем активно добавляли новые сценарии для тестирования. С февраля 2016 года я перешел full time на другой проект.
За время моего отсутствия (полгода):
Проект полгода жил и развивался усилиями только разработчиков, без единого тестировщика. Разработчики самостоятельно добавили новый компонент, создав Jenkins проекты и Pyhton код по аналогии с существующими.
Некорректных багов за это время тоже заведено довольно много, в основном дубликатов, рожденных некорректным сетапом нового теста или отказами тестового сервера. Однако это уже тема для отдельной статьи.
Автор: Acronis
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/195653
Ссылки в тексте:
[1] http://bp-la.ru/bespilotnyj-apparat-danem: http://bp-la.ru/bespilotnyj-apparat-danem
[2] из Википедии: https://en.wikipedia.org/wiki/Software_testing
[3] http://spongebob.wikia.com/wiki/Primitive_Sponge: http://spongebob.wikia.com/wiki/Primitive_Sponge
[4] http://dkrack.wikispaces.com/Brave+New+World: http://dkrack.wikispaces.com/Brave+New+World
[5] https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View: https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View
[6] Источник: https://habrahabr.ru/post/282682/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.