Система генерации чек-листов для регрессионного...
Post on 11-Jul-2015
674 Views
Preview:
TRANSCRIPT
Система генерации чек-листов для регрессионного тестирования на основе анализа рисков
или QA паранойя
Солодов ВладимирSuperjob, Москва, Россия
Постановка задачи
Постановка задачи
Функционал, связанный с изменением, положительные кейсы, 15% критичных багов
Функционал, связанный с изменением, кейсы на предельные значения и отрицательные кейсы, 40% критичных багов
Функционал, не связанный с изменением, 45% критичных багов
Мы хотим
• получить набор тесткейсов, проведение которых гарантировало бы нахождение ВСЕХ(!) багов, привнесенных конкретным изменением кода
• получить приоритеты тесткейсов, чтобы сначала обнаружить наиболее критичные баги, привнесенные с изменениями, а затем находить наименее критичные баги
Постановка задачи
Природа багов
Задание: Вывести ссылку «Ссылка 10» красным цветом
Природа багов
Изменение 1.
Программист поменял код HTML на странице: он обрамил текст ссылки в тег <font color=”red”> и забыл его закрыть. Все работает, ссылка корректно окрашена.
Расширяем контекст.
Ниже в верстке есть поп-ап, который появляется при клике на ссылку «Ссылка3», Текст в попапе окрашивается в цвет, который мы установили для ссылки.
Природа багов
Природа багов
Изменение 2.
Программист поменял существующий стиль программы, добавил в css-стиль строку color: red и убрал style:linked.
Расширяем контекст.
В шаблонах других странице данным стилем обозначены все ссылки на данную страницу, а их текст мы хотим оставить прежним.
Природа багов
Изменение 3.
Программист добавил в css новый стиль, новый идентификатор, для которого корректно указал цвета.
Расширяем контекст.
С данным стилем, идентификатором был связан код JS, который сейчас не работает.
Риски реализации
Риск – вероятное событие, приводящее к негативным последствиям.
Величина риска = (вероятность) x (ущерб) = P x H
Ущерб
Ве
ро
ятн
ост
ь 1 2 3
1 1 2 3
2 2 4 6
3 3 6 9
Риски реализации
Гипотезы, которые мы приняли
• изменения, вносимые в систему однозначно определяют риски, которые могут материализоваться в системе,• риски, связанные с каждым изменением могут быть устойчивыми (регулярно повторяющимися), если взаимосвязи элементов, в которых вносятся изменения будут сохранять инвариантность (постоянство), то есть изменения должны касаться изменения частей системы, а не характера их взаимосвязей
Одним из таких инвариантов в компьютерной программе является архитектура приложения.
Инициализация. Шаги 1,2 из 4
Шаг 1. На основе архитектуры приложения выделить основные компоненты (элементы архитектуры: шаблоны, базы данных, модели, таблица стилей)
Шаг 2. Для каждого компонента выделить изменения, которые вносятся разработчиком
1. Изменения CSS (styles.css, blitz, ViewModel)2. Исправление JS (файлы плагинов, blitz, ViewModel)3. DOM-HTML (blitz). Добавление элемента в дерево4. DOM-HTML (blitz). Изменение существующего элемента5. DOM-HTML (blitz). Удаление элемента из дерева6. Изменения в БД. Добавление нового поля 7. Изменения в БД. Удаление поля8. Изменения в БД. Исправлен запрос9. Изменение PHP скриптов (Контроллер, VM). Логика
Инициализация. Шаги 3,4 из 4
Шаг 3. Для каждого изменения можно определить риски, следующие из здравого смысла и определить им вероятность возникновения 0,5, вред определить из логики приложения.
Шаг 4. Для каждого риска предусмотреть тест-кейсы, которые должны быть выполнены, чтобы данный риск был протестирован.
Риск Симптом
1 Стиль наследует данные, которые конфликтуют с версткой
Верстка нового элемента некорректна
2 Стиль используется другими элементами Верстка сопряженных элементов некорректна
3 Атрибуты наследуются другими элементами Верстка сопряженных элементов некорректна
4 Некорректно работают JS-обработчики Не работают скрипты добавления, модификации элементов DOMa
Алгоритм работы
Шаг 1. Отметить какие изменения были внесены в систему.
Шаг 2. Выбрать риски для изменений, которые отмечены и отранжировать их в порядке убывания параметра P x H, для данных рисков уже заранее определены тесткейсы
Шаг 3. Проверить, риски в порядке убывания параметра
Шаг 4. Отметить риски, которые материализовались, зафиксировать баги в системе.
Шаг 5. Пересчитать вероятности рисков с учетом того, какие материализовались, а какие – нет.
Обучение системы
В режиме обучения необходимо проводить регрессионные испытания, изменения вносятся, если:
• обнаруживается новый вид изменений в системе (такое изменение связано либо с изменением архитектуры, либо с неправильным исходным разбиением),• для изменения обнаруживается новый риск, который ранее не был учтен, в этом случае добавляется новый риск
Демонстрация работы
Демонстрация работы
Демонстрация работы
Демонстрация работы
1. Добавлено поле Expirience в таблицу- Изменены запросы на страницах, использующих поле - Меняется валидатор значений - Поле добавляется в фиды- Добавляется проверка на обязательность поля - Поле участвует в полях печати и т.д.
2. Добавлен элемент DOM на страницы Создания, Редактирования, Отображения вакансии- Добавляется клиентская валидация поля- Добавляется серверная валидация поля - Добавляется поле в БД - Добавляется поле в фид поисковой машины - Добавляется поле в админке с валидацией- Добавляется поле в бланк для печати - Добавляется поле с хинтом- Поле добавляется в поисковые запросы и параметры рассылок
3. Изменен обработчик JS для отображения поля в бланке вакансии для соискателя- Изменение DOM, добавление, удаление, изменение элемента- Изменение клиентской логики, отображение с прописной/строчной буквы
Демонстрация работы
Преимущества
1. Сокращается время тестирования проекта. Тескткейсы приоретизированы
2. До начала изменений разработчики могут увидеть как будет тестироваться данный функционал
3. До начала проектирования у аналитика есть опорные точки, по которым он может учесть проблемы, которые уже возникали в проекте, а тестировщик может выполнять тестирование требований
4. Появляется «память проекта», в которой учтены проблемы, возникавшие ранее.
5. Формируется модель проекта, позволяющая оценить взаимосвязь архитектурных элементов, таким образом, тестирование переносится в фазу обратной связи
Недостатки
1. На первом этапе обучения не все кейсы получают корректные приоритеты. Эта проблема проявляется в самом начале, но очень быстро устраняется в процессе работы системы. Причем устраняется значительно с меньшими затратами ресурсов и времени, чем, например, в тех же автотестах.
2. В начале работы системы не все кейсы учтены. Эффективность работы системы во многом зависит от квалификации инженера, выполняющего разбиение. Однако, это компенсируется тем, что в дальнейшем для систем с одной архитектурой база рисков уже полностью готова и требует только незначительной настройки приоритетов кейсов.
3. Изменение архитектуры проекта влечет необходимость изменить поменять набор рисков и тесткейсов. Архитектура проекта меняется не настолько часто и является скорее исключением, чем правилом.
Спасибо за внимание, и помните,
«Работа должна доставлять удовольствие»
top related