Система генерации чек-листов для регрессионного тестирования на основе анализа рисков
Download as PPTX, PDF0 likes2,757 views
Документ описывает систему генерации чек-листов для регрессионного тестирования на основе анализа рисков, целью которой является выявление и тестирование критичных багов, связанных с изменениями кода. Основные шаги включают инициализацию архитектуры приложения, определение рисков и соответствующих тест-кейсов, а также методы оценки их вероятности и ущерба. Также обсуждаются преимущества и недостатки системы, включая возможность сокращения времени тестирования и необходимость корректировки приоритетов тест-кейсов в процессе обучения.
Система генерации чек-листов для регрессионного тестирования на основе анализа рисков
- 1. Система генерации чек-листов для регрессионного тестирования на основе анализа рисков или QA паранойя Солодов Владимир Superjob, Москва, Россия
- 3. Постановка задачи Функционал, связанный с изменением, положительные кейсы, 15% критичных багов Функционал, связанный с изменением, кейсы на предельные значения и отрицательные кейсы, 40% критичных багов Функционал, не связанный с изменением, 45% критичных багов
- 4. Мы хотим • получить набор тесткейсов, проведение которых гарантировало бы нахождение ВСЕХ(!) багов, привнесенных конкретным изменением кода • получить приоритеты тесткейсов, чтобы сначала обнаружить наиболее критичные баги, привнесенные с изменениями, а затем находить наименее критичные баги Постановка задачи
- 5. Природа багов Задание: Вывести ссылку «Ссылка 10» красным цветом
- 6. Природа багов Изменение 1. Программист поменял код HTML на странице: он обрамил текст ссылки в тег <font color=”red”> и забыл его закрыть. Все работает, ссылка корректно окрашена. Расширяем контекст. Ниже в верстке есть поп-ап, который появляется при клике на ссылку «Ссылка3», Текст в попапе окрашивается в цвет, который мы установили для ссылки.
- 8. Природа багов Изменение 2. Программист поменял существующий стиль программы, добавил в css-стиль строку color: red и убрал style:linked. Расширяем контекст. В шаблонах других странице данным стилем обозначены все ссылки на данную страницу, а их текст мы хотим оставить прежним.
- 9. Природа багов Изменение 3. Программист добавил в css новый стиль, новый идентификатор, для которого корректно указал цвета. Расширяем контекст. С данным стилем, идентификатором был связан код JS, который сейчас не работает.
- 10. Риски реализации Риск – вероятное событие, приводящее к негативным последствиям. Величина риска = (вероятность) x (ущерб) = P x H Ущерб Вероятность 1 2 3 1 1 2 3 2 2 4 6 3 3 6 9
- 11. Риски реализации Гипотезы, которые мы приняли • изменения, вносимые в систему однозначно определяют риски, которые могут материализоваться в системе, • риски, связанные с каждым изменением могут быть устойчивыми (регулярно повторяющимися), если взаимосвязи элементов, в которых вносятся изменения будут сохранять инвариантность (постоянство), то есть изменения должны касаться изменения частей системы, а не характера их взаимосвязей Одним из таких инвариантов в компьютерной программе является архитектура приложения.
- 12. Инициализация. Шаги 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). Логика
- 13. Инициализация. Шаги 3,4 из 4 Шаг 3. Для каждого изменения можно определить риски, следующие из здравого смысла и определить им вероятность возникновения 0,5, вред определить из логики приложения. Шаг 4. Для каждого риска предусмотреть тест-кейсы, которые должны быть выполнены, чтобы данный риск был протестирован. Риск Симптом 1 Стиль наследует данные, которые конфликтуют с версткой Верстка нового элемента некорректна 2 Стиль используется другими элементами Верстка сопряженных элементов некорректна 3 Атрибуты наследуются другими элементами Верстка сопряженных элементов некорректна 4 Некорректно работают JS-обработчики Не работают скрипты добавления, модификации элементов DOMa
- 14. Алгоритм работы Шаг 1. Отметить какие изменения были внесены в систему. Шаг 2. Выбрать риски для изменений, которые отмечены и отранжировать их в порядке убывания параметра P x H, для данных рисков уже заранее определены тесткейсы Шаг 3. Проверить, риски в порядке убывания параметра Шаг 4. Отметить риски, которые материализовались, зафиксировать баги в системе. Шаг 5. Пересчитать вероятности рисков с учетом того, какие материализовались, а какие – нет.
- 15. Обучение системы В режиме обучения необходимо проводить регрессионные испытания, изменения вносятся, если: • обнаруживается новый вид изменений в системе (такое изменение связано либо с изменением архитектуры, либо с неправильным исходным разбиением), • для изменения обнаруживается новый риск, который ранее не был учтен, в этом случае добавляется новый риск
- 19. Демонстрация работы 1. Добавлено поле Expirience в таблицу - Изменены запросы на страницах, использующих поле - Меняется валидатор значений - Поле добавляется в фиды - Добавляется проверка на обязательность поля - Поле участвует в полях печати и т.д. 2. Добавлен элемент DOM на страницы Создания, Редактирования, Отображения вакансии - Добавляется клиентская валидация поля - Добавляется серверная валидация поля - Добавляется поле в БД - Добавляется поле в фид поисковой машины - Добавляется поле в админке с валидацией - Добавляется поле в бланк для печати - Добавляется поле с хинтом - Поле добавляется в поисковые запросы и параметры рассылок 3. Изменен обработчик JS для отображения поля в бланке вакансии для соискателя - Изменение DOM, добавление, удаление, изменение элемента - Изменение клиентской логики, отображение с прописной/строчной буквы
- 21. Преимущества 1. Сокращается время тестирования проекта. Тескткейсы приоретизированы 2. До начала изменений разработчики могут увидеть как будет тестироваться данный функционал 3. До начала проектирования у аналитика есть опорные точки, по которым он может учесть проблемы, которые уже возникали в проекте, а тестировщик может выполнять тестирование требований 4. Появляется «память проекта», в которой учтены проблемы, возникавшие ранее. 5. Формируется модель проекта, позволяющая оценить взаимосвязь архитектурных элементов, таким образом, тестирование переносится в фазу обратной связи
- 22. Недостатки 1. На первом этапе обучения не все кейсы получают корректные приоритеты. Эта проблема проявляется в самом начале, но очень быстро устраняется в процессе работы системы. Причем устраняется значительно с меньшими затратами ресурсов и времени, чем, например, в тех же автотестах. 2. В начале работы системы не все кейсы учтены. Эффективность работы системы во многом зависит от квалификации инженера, выполняющего разбиение. Однако, это компенсируется тем, что в дальнейшем для систем с одной архитектурой база рисков уже полностью готова и требует только незначительной настройки приоритетов кейсов. 3. Изменение архитектуры проекта влечет необходимость изменить поменять набор рисков и тесткейсов. Архитектура проекта меняется не настолько часто и является скорее исключением, чем правилом.
- 23. Спасибо за внимание, и помните, «Работа должна доставлять удовольствие»