CC BY
11
УДК 004.415.53
Андреева Т.И. студент магистратуры 2 курса факультет «Информационные системы и технологии» Пензенский государственный университет архитектуры и строительства
Андреев А.И. преподаватель
ГАПОУПО "Пензенский колледж архитектуры и строительства "
научный руководитель: Гвоздева И.Г.
старший преподаватель Россия, г. Пенза ОСНОВНЫ ТЕСТИРОВАНИЯ СИСТЕМ Аннотация
Статья посвящена освещению основных моментов тестирования программного обеспечения, плюсы и риски развития автоматизированного тестирования.
Ключевые слова:
Тестирование, автоматизированное тестирование, качество тестирования.
Andreeva T.I. student of magisterial 2course, faculty " Information systems and technologies" Penza State University of architecture and construction
Russian Federation, Penza Andreev A.I. teacher
State Autonomous Professional Educational Institution of the Penza Region "Penza College of architecture and construction"
Russian Federation, Penza Scientific adviser: Gvozdeva I.G.
Senior teacher
BASES OF SYSTEMS TESTING
Summary
Article is devoted to inform of enlightenments of software testing, advantages and disadvantages of the automated testing development. Key words:
Testing, automation testing, quality testing.
Современный цикл жизни IT-продукта невозможно представить без тестирования на предрелизном этапе. Целью тестирования является выпуск качественного продукта, выявление проблем в бизнес-процессах, интеграции между системами, корректного отображении информации до момента
внедрения и эксплуатации.
Тестирование - мощный инструмент для обнаружения ошибок и повышения качества программного обеспечения, иногда с его помощью можно обнаружить дефекты, заложенные на этапах написания технического задания и разработки архитектуры приложения по ТЗ, что намного лучше, чем разгребать ошибки в уже проданном программном обеспечении.
На этапе проектирования релиза, формируются основные требования к выпускаемому продукту. Эти требования оформляются в функциональные требования и далее в техническое задание. Основываясь на этих документах, программист начинает разработку продукта, а тестировщик написание либо чек-листов, либо полноценных тест-кейсов.
Этап тестирования может начаться как после выхода продукта на стадию тестирования, так и идти параллельно с разработкой. Второй вариант значительно сокращает путь от нахождения ошибки до его исправления, и, следовательно, удешевляет стоимость исправления ошибок.
Первоначально разработчик пишет модульные (unit) тесты для каждого написанного им метода.
По окончании этапа разработки, новый функционал устанавливается на тестовую среду, где первоначально запускаются приемочные (smoke) тесты. В зависимости от их результата делается вывод о работоспособности продукта. Приемочные тесты должны относиться к высшей категории критичности и затрагивать основные бизнес-процессы.
После положительных приемочных тестов начинается этап регрессионного тестирования. При нахождении дефектов, они заводятся в баг-трекинге, с указанием проблемы и прикладыванием информации, ускоряющей понимание причины проблемы. Дефект назначается на ответственных аналитиков, которые после анализа проблемы назначают его на разработчика (рис 1).
Рисунок 1. Цикл жизни дефекта на этапе тестирования
Каждый чек-лист или тест-кейс имеет время прохождения от момента нахождения тестируемых данных, до момента проверки функциональности. Сумма времени прохождения всех кейсов (листов) составляет вес регрессионной модели. Для небольшого продукта данная цифра имеет разумную цифру, и без труда может обходиться функциональными тестированием без участия автоматизации. Если же вес модели переваливает за рамки выделенного времени тестирования или возрастает риск невозможности полноценно протестировать, то на помощь может прийти автоматизация тестирования.
Написанием автотестов, как правило, занимается узконаправленный ^-специалист. Разворачивание системы автотестрования включает в себя не только написание автотестов, но и подборку инструментов, библиотек и фрейворков для облегчения написания, запуска, и сбора результатов тестирования.
Автоматизация тестирования в разы сокращает время проведения регрессионного тестирования. Но стоит учитывать баланс между временем написания автотеста и временем функционального тестирования этого кейса. Трудозатраты (в человеко-часах) на написание автотеста сопоставляются со временем прохождения теста вручную и, исходя из этих данных, высчитывается количество итераций тестирования, после которых будет приносить чистую пользу. На практике есть случаи, когда написание
автотеста по бизнес-процессу невозможно. Как, например, тестирование телефонии, когда оператор должен сделать физические манипуляции вне экрана приложения.
Преимущества автоматизации тестирования:
1) Скорость выполнения тест-кейсов может в разы и на порядки превосходить возможности человека;
2) Средства автоматизации способны выполнить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скорости или иных факторов;
3) Средства автоматизации способны собирать, сохранять, анализировать, агрегировать и представлять в удобной для восприятия человеком форме колоссальные объёмы данных;
4) Средства автоматизации способны выполнять низкоуровневые действия с приложением, операционной системой, каналами передачи данных и т.д.
Риски автоматизации:
1) Необходимость наличия высококвалифицированного персонала в силу того факта, что автоматизация — это «проект внутри проекта;
2) Разработка и сопровождение как самих автоматизированных тест-кейсов, так и всей необходимой инфраструктуры занимает очень много времени;
3) Автоматизация требует более тщательного планирования и управления рисками, т. к. в противном случае проекту может быть нанесён серьёзный;
4) Коммерческие средства автоматизации стоят ощутимо дорого, а имеющиеся бесплатные аналоги не всегда позволяют эффективно решать поставленные задачи;
5) Средств автоматизации крайне много, что усложняет проблему выбора того или иного средства, затрудняет планирование и определение стратегии тестирования, может повлечь за собой дополнительные временные и финансовые затраты, а также необходимость обучения персонала или найма соответствующих специалистов.[1]
Ключевые процессы тестирования протекают в контексте проекта тестирования, который, в свою очередь, входит в объемлющий проект разработки, сопровождения, интеграции и приемо-сдаточных испытаний системы.[2]
Идеальной картиной считается пирамида тестирования, где основанием являются unit-тесты, далее интеграционные, системные и end-to-end тесты (рис. 2).
Рисунок 2. Правильная пирамида тестирования.
Но практика показывает, что:
1) Чаще всего пирамида оказывается перевернутой и количество E2E-тестов преобладает над количеством unit-тестов;
2) Пирамида становится моделью песочных часов, т.к. при большом количестве интеграции со сторонними сервисами необходимо больше end-to-end тестов.
Полнота тестирования, сложность проекта, зрелость команды, уровень межотдельной коммуникации, грамотность оперирования входными данными, умением анализировать выходящий результат - одни из главных показателей, от которых зависит качество тестирования, а значит и качество выпускаемого продукта. Что, в свою очередь, сказывается на восприятии пользователей системы и ведении бизнеса.
Использованные источники:
1. Куликов С. С. Тестирование программного обеспечения. Базовый курс / С. С. Куликов. - 2 издание — Минск: Четыре четверти, 2017. — 312 с.
2. Блэк Р. Ключевые процессы тестирование. Планирование, подготовка, проведение, совершенствование / Блэк Р.; пер. Павлов М., науч. ред. Головко А., - Москва: Лори, 2006. - 544 с.
