Принципы тестирования программного продукта
Тестирование программного обеспечения как часть процесса создания программного продукта, требования к нему, этапы и закономерности. Его разновидности: регрессионное, автоматизированное. Возможность построения конфигураций для настройки LTE-сетей.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 08.02.2017 |
| Размер файла | 110,9 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Введение
Тестирование программного обеспечения является неотъемлемой частью процесса создания программного продукта. При применении любой модели разработки программного обеспечения роль тестирования трудно переоценить. Особенно высока значимость верификации продукта при использовании итеративной методологии разработки программного обеспечения (ПО), которая включает в себя все этапы жизненного цикла, вплоть до внедрения разрабатываемого ПО и получения реакции пользователей.
Некачественное тестирование может спровоцировать резко отрицательные отзывы о продукте и впоследствии сформировать негативное впечатление от его использования.
Понимание важности процесса тестирования приводит к возникновению тенденций, направленных на применение промышленных способов проверки качества программного обеспечения. Наиболее важным направлением здесь является внедрение различных систем автоматизированного тестирования.
Автоматические тесты давно стали не инновацией, а в некотором роде стандартом при разработке корпоративного ПО. Их использование обеспечивает более высокое качество кода и, соответственно, программного обеспечения в целом, помогая заметно повысить надежность системы.
1. Что такое регрессионное тестирование
Появление первых компьютеров отразилось на программном обеспечении. Программирование, в частности, невозможно без различного рода ошибок, совершенных под влиянием человеческого или других немаловажных факторов. Если процесс отладки программного продукта не был значительной проблемой еще два десятилетия назад в виду его примитивности, то сейчас ПО - это сложнейшая система, которая постоянно подвергается изменениям. Несмотря на то, что изначально программа отвечает большинству заявленным в спецификации требованиям, имеют место модификации, внесенные в работу продукта для корректировки обнаруженных дефектов на этапе его тестирования. В результате, такие изменения могут привести к регрессии функциональной части приложения. Таким образом, постоянное тестирование необходимо для того, чтобы поддерживать высокий уровень качества ПО.
Регрессионное тестирование является исключительно ресурсоемкой и дорогой (в рамках бизнес-проекта) деятельностью. Причина заключается в том, что регрессионное тестирование должно быть выполнено даже после незначительных изменений в коде программы. Таким образом, количество выполняемых тестов постоянно растет.
2. Автоматизированное тестирование
Автоматизированное тестирование программного обеспечения - один из вариантов верификации продукта на стадии его разработки. Автоматизация подразумевает под собой использование определенных программных средств для выполнения тестов и отслеживания результатов тестирования, что позволяет значительно упростить процесс тестирования и сократить время на его проведение.
Как правило, автоматизирование тестирования влияет на весь бизнес-процесс, является ресурсозатратной деятельностью как в финансовом отношении, так и в плане временных затрат на разработку тестовых сценариев с их дальнейшей поддержкой. Однако при внедрении автотестов есть положительные моменты. Во-первых, исключен человеческий фактор, поскольку однажды написанный скрипт будет выполняться однообразно. Таким образом, тестировщик не сможет упустить шаги в тестах и ничего не напутает в результатах. Во-вторых, предусмотрено хранение результатов тестирования, что весьма полезно именно для регрессионного тестирования. В-третьих, автоматические тесты частично выполняются независимо от человека, т.е. без его вмешательства. Если речь идет о регрессионном тестировании, которое является лидером по ресурсоемкости, во время выполнения тестов инженер может заниматься какой-либо другой немаловажной деятельностью.
Принятие решения о внедрении автоматизации тестирования должно происходить после анализа всех ее нюансов, достоинств и недостатков.
3. Постановка задачи
В проекте несколько раз в течение жизненного цикла тестируемого продукта проводится ручное регрессионное тестирование такой функциональности, как проверка соответствия конфигураций их идеальным состояниям. Эта деятельность постепенно стала отнимать значительное количество человеческих и временных ресурсов. В то же время, наряду с регрессионным тестированием, в проекте выполняются и другие виды тестирования, которые на данный момент уже имеют реализацию в качестве автоматических тестов. Для выполнения этой задачи используется инструмент для автоматического тестирования Cucumber.
Передо мной были поставлены задачи применения вышеуказанного приложения для автоматизации регрессионного тестирования элементов проверки соответствия в текущем проекте, анализа полученных результатов и оценки целесообразности перехода от ручного регрессионного тестирования к автоматическому.
4. Практическая часть
программный регрессионный автоматизированный тестирование
Ход работы
Одной из основных функций тестируемого программного обеспечения является возможность построения конфигураций для настройки LTE-сетей. Конфигурации могут отличаться своим предназначением, объемом и глубиной. Для того, чтобы конфигурации отвечали требованиям, не содержали лишних объектов или, наоборот, включали в себя все необходимые элементы, ПО предусматривает проверку соответствия построенных конфигураций их оракулам (эталонам).
Полная проверка соответствия основана на проверке отдельных элементов, которые отвечают за различные типы и формы конфигураций. Таких элементов в тестируемом продукте может быть несколько сотен на одну версию. Каждый элемент имеет определенную постоянную структуру: название, область применения, содержание сообщений, описание элемента, шаги для корректировки конфигурации, код для ее построения. При запуске проверки соответствия на корневом элементе, который в свою очередь также является частью структуры, происходит обработка и отображение сообщений, соответствующих данному элементу.
Задача тестировщика в этом случае заключается в максимально возможном покрытии структуры элемента проверки соответствия, анализе полученных результатов, определении его соответствия ожидаемому поведению. При этом, в случае регрессионных тестов, нет необходимости в построении новых или изменении старых конфигураций, происходит мониторинг текущего состояния программного продукта на возможное косвенное влияние со стороны введения новых функций или их изменения, исправления найденных ранее дефектов.
Мониторинг текущего состояния программного продукта осуществлялся с помощью монотонных действий со стороны тестировщика с данными большого объема, поэтому введение автоматизации этой деятельности видится перспективной заменой ручного рутинного труда.
Для принятия решения о целесообразности автоматизации тестирования элементов соответствия в текущем проекте мною были определены для выполнения следующие действия:
· исследование возможности автоматизации тестирования элементов проверки соответствия тестируемого программного обеспечения,
· автоматизация тестирования элементов проверки соответствия тестируемого программного обеспечения,
· запуск автоматических тестов для кампании элементов проверки соответствия ранее протестированных вручную,
· сравнение и анализ полученных результатов,
· выводы по целесообразности / нецелесообразности автоматизации тестирования элементов проверки соответствия.
Тестируемое программное обеспечение было исследовано в течение нескольких месяцев для написания текущей работы. Как правило, календарный год - время разработки и тестирования одной версии продукта, затем продукт уходит к пользователям. За этот период, согласно итерационной модели разработки ПО, планируется выпуск 20 итераций тестируемого программного продукта. Каждая итерация в какой-либо мере отличается от предыдущей: имеет обновленный функционал либо корректировку дефектов, найденных на предыдущем этапе жизненного цикла. Порой даже самые незначительные изменения могу повлечь за собой регрессию. Регрессионные тесты выполняются дважды за версию продукта.
Структура приложения
Тестируемый программный продукт работает с телекоммуникационными сетями нового поколения. Имеет следующие функции: конфигурация, настройка, изменение и оптимизация параметров сетей беспроводного доступа.
Клиентская часть реализует пользовательский интерфейс, формирует запросы к серверу и обрабатывает ответы от него. Основой клиентской части в тестируемом программном продукте является программная платформа Microsoft Silverlight.
Серверная часть получает запрос от клиента, выполняет операции, после этого формирует отчет и отправляет его клиенту. В текущем продукте сервер написан на языке Java. При этом весь функционал ПО, используемые плагины и библиотеки также находятся на стороне сервера. Основная работа в процессе автоматического тестирования будет проходить с плагинами при использовании библиотек сервера.
Процесс регрессионного тестирования
Ограничение ресурсов
Прежде, чем приступать к описанию процесса регрессионного тестирования, следует обратить внимание, на что затрачиваются ресурсы во время верификации элементов проверки соответствия.
Для того, чтобы выполнить регрессионное тестирование, тестировщику необходимо иметь файл с описанием конфигурации в формате XML (созданный во время ручного тестирования элемента проверки соответствия) и отчет с результатами проведения проверки соответствия на текущей конфигурации. Отчет имеет удобную форму, в которой сообщается о тестируемых объектах конфигурации и соответствующих им сообщениях после проведения тестирования. Таким образом, задачей тестировщика является запуск тестируемого приложения, загрузка файла конфигурации, запуск определенного элемента проверки соответствия, сравнение полученных результатов с имеющимся отчетом и анализ этих данных.
По стандарту, установленному нашим проектом, на выполнение ручного регрессионного тестирования одного элемента уделяется 0,5 ч/ч (человеко-час). Максимальное количество членов команды, которое может быть задействовано в ручном регрессионном тестировании, ограничивается общим количеством людей в команде, выделяемых для проведения данного вида тестирования, и для нашего проекта составляет не более 4 человек.
Ручное регрессионное тестирование проверки соответствия
В начальной версии 2.0 тестируемого программного продукта не производилось регрессионное тестирование проверки соответствия, т.к. не было необходимых файлов с описанием конфигураций, участвующих в процессе тестирования элементов проверки соответствия, и отчетов ее выполнения. В течение года члены команды, в зависимости от своей деятельности, выполняли обычное тестирование элементов проверки соответствия. На один тест тестировщик, исходя из стандартов проекта, может потратить 2,5 ч/ч.
В следующей версии 2.1 тестируемого программного продукта не только появились новые элементы проверки соответствия, но и образовалась база из файлов и отчетов проведенных тестов на проверку соответствия в предыдущей версии программного обеспечения.
В текущей версии 2.2 тестируемого приложения увеличилось количество тестов для регрессионного тестирования, и также прибавились новые элементы, структуры которых будут покрыты тестировщиками в течение жизненного цикла этой версии.
Таким образом, можно сделать вывод о том, что количество тестов, участвующих в регрессионном тестировании элементов проверки соответствия, с каждой версией становится все больше и больше, а значит количество времени, затрачиваемое на данную деятельность, также растет.
Приведенная схема на Рис. 2 отображает, какое количество времени тратится на тестирование элементов проверки соответствия и их ручное регрессионное тестирование при идеальных условиях, выполняемое один раз для различных версий продукта. (Прим.: Как уже было сказано, ручное регрессионное элементов проверки соответствия выполняется дважды за жизненный цикл продукта.) Под идеальными условиями подразумевается трудовая деятельность в течение 8 часов в день (нормальная продолжительность рабочего времени человека) с минимальной производительностью.
Регрессионное тестирование элементов проверки соответствия занимало не более 37 дней рабочего времени (md, «man-days»; единица измерения производительности трудящегося) инженера по тестированию в год, то для версии продукта 2.2 это заняло бы более 60 рабочих дней в год при его обычном выполнении дважды за версию одним человеком и в три раза меньше в условиях работы трех членов команды. Несмотря на то, что регрессионное тестирование является одним из самых важных видов тестирования любого программного продукта, проект не может позволить себе затрачивать столь значительные ресурсы. Это также стало одной из причин проявления интереса к автоматизации регрессионного тестирования элементов проверки соответствия.
Cucumber-инструмент
Общие сведения
В качестве инструмента для автоматизированного регрессионного тестирования был выбран Cucumber.
Cucumber - приложение, широко используемое для тестирования программного обеспечения, выполняющее приемочное тестирование в стиле BDD (Behaviour-Driven Development) процесса. Это означает, что во время тестирования инструмент фокусируются не на тестах, а на спецификациях поведения объектов, с которыми он работает; также существует связь кода с требованиями, которые записываются с помощью обычных фраз, тем самым рождается специфичный для предметной области язык (DSL) и улучшается общение с пользователем.
Другими словами, Cucumber позволяет описывать ожидаемое поведение приложения обычным текстом. Текст написан на предметно-ориентированном языке. Cucumber может работать с Ruby, Jаvа.NET, Flex, а также с веб-приложениями, написанными на любом языке.
Cucumber способен автоматически сохранять отчёты в заданном пользователем формате. Для использования Cucumber как инструмента тестирования в нашем проекте потребовалось добавить функции, специфичные для тестируемого приложения.
История Cucumber
Cucumber - свободно распространяемое приложение, является переписанным Аслаком Хеллесойем вариантом RSpecStoryRunner Дэна Норта.
В апреле 2008 Аслак Хеллесой начал развивать проект Cucumber, чтобы устранить внутренние дефекты дизайна и проблемы удобства использования проекта RSpecStoryRunner. Затем к проекту присоединились Джозеф Уилк и Бен Мэбей. После этого, в октябре 2009, к проекту присоединились Майк Сассак и Грегори Хнатик, создавшие самый быстрый парсер для Cucumber.
Язык Gherkin, который используется в Cucumber, был создан Дэном Нортом, Крисом Маттсом, Лиз Ког и Дэвидом Келимски.
На данный момент Cucumber только набирает популярность в качестве приложения для автоматизированного тестирования.
Структура Cucumber
Структура Cucumber
Тестирование с использование программы Cucumber происходит как с помощью встроенных функций Cucumber, так и с помощью дополнительных функций, которые были получены от разработчиков тестируемого программного продукта.
Также есть 4 внешние составляющие.
Данные - файлы формата XML, описывающие конфигурации для тестирования элементов проверки соответствия.
Файл конфигурации с указанием путей к директориям, где располагаются плагины и библиотеки сервера тестируемого ПО.
Настраиваемые аргументы JVM для корректной работы инструмента Cucumber на базе используемой машины.
Файл CucumberRunner, где описаны пути к внутренним директориям проекта автоматизации, содержащим.rb и.feature файлы, необходимыми для выполнения автоматического тестирования.
Конфигурирование Cucumber
Для корректного выполнения автоматических тестов Cucumber должен быть правильно настроен. Настройка происходит путём изменения следующих файлов (описанных выше):
· файл CucumberRunner.mwe2,
· файл с расширением.feаture,
· файл с расширением.rb,
· файл конфигурации,
· аргументы виртуальной Java-машины (JVM),
а также с помощью добавления необходимых пользовательских файлов в соответствующие директории.
Файл с расширением.feаture
Feature-файл является неотъемлемой частью Cucumber. Файл используется для записи шагов тестирования на понятном для пользователя языке. Все feature-файлы имеют расширение.feature.
Описанный сценарий впоследствии будет отображаться в html отчете, который автоматически генерируется инструментом для тестирования:
Given I have an <consElementId> specified
When I load version <conf> with <model>
Then I run all elements on the <confElementId> with <fix>
Then I can receive a <severity> and <nbMsg> MESAND <nbAutoMsg> describe in <msg1> MESAND <msg2> MESAND <msg3> MESAND <msg4> MESAND <auMsg1> MESAND <auMsg2>
Затем должны быть указаны необходимые атрибуты:
| conf | model | confElementId | consElementId | severity | nbMsg | msg1 | msg2 | msg3 | msg4 | nbAutoMsg | auMsg1 | auMsg2 |
Файл с расширением.rb
Файл с расширением.rb также является одним из основных файлов для тестирования с помощью инструмента Cucumber. Он представляет собой пошаговое описание сценария тестирования на языке Ruby.
Одному.rb файлу может соответствовать несколько.feature файлов, в то время как одному.feature файлу может соответствовать только один.rb файл. Именно первая особенность подходит для реализации автоматического регрессионного тестирования элементов проверки соответствия, поскольку, как правило, количество feature-файлов равно либо больше, чем самих элементов проверки соответствия.
Пример:
When /^I load version (.*) with (.*)$/ do | conf, model|
@confpath = «data/dir/confs/» + conf
@conf = Cucumber: Conf.new (@consElementSession.getServiceDirectory())
@conf.openConf(@confpath)
end
Файл конфигурации
В файле конфигурации указывается путь к библиотекам и плагинам тестируемого приложения.
Пример:
<JаrDirectory> C:\Program Files\program\jars</JаrDirectory>
<PluginDirectory> C:\Program Files\program\plugins</PluginDirectory>
Настраиваемые аргументы инструмента Cucumber
Файл CucumberRunner.mwe2 содержит специализированные аргументы для настройки и корректной работы инструмента для тестирования Cucmber. Обязательной частью данной файла является наличие указанных путей к директориям проекта, где располагаются.feature и.rb файлы. Кроме того, очень часто в нем указываются настройки для виртуальной Java-машины, на которой запускается Cucumber. Для корректных результатов значения аргументов JVM Cucumber'a должны точно соответствовать настройкам JVM приложения.
Также тут указываются значения других необходимых аргументов.
Наиболее часто используемые настраиваемы аргументы JVM - это Xmx и XX: MаxPermSize.
Xmx{число} m - максимальное количество оперативной памяти, выделяемой под виртуальную машину Java, в мегабайтах. Вместо {число} указывается любое требуемое число, исходя из суммарного количества оперативной памяти на компьютере.
Пример записи: - Xmx1500m
XX: MaxPermSize={число} m - количество памяти Permanent Generation (сокр. PermGen), выделяемой под виртуальную машину Java, в мегабайтах. В этой памяти хранится исполняемый код программы. Если выдаётся ошибка OutOfMemory: PermGenSpace, необходимо увеличить выделение PermGen. Вместо {число} указывается любое требуемое число. Слишком большое число указывать не рекомендуется, так как исполняемый код занимает немного места, а излишнее выделение PermGen зачастую приводит к задержкам в работе инструмента для тестирования.
Пример записи: - XX: MaxPermSize=150m
Здесь очень важно найти баланс между установленными значениями аргументов для JVM и техническими возможностями машины. Слишком маленькие значения могут сделать процесс тестирования медленным. А слишком большие значения аргументов окажут неблагоприятное влияние на работу компьютера, поскольку значительное количество оперативной памяти будет занимать работа инструмента для тестирования.
Пояснение статусов тестов
Во время определения статуса теста Cucumber не просто решает, насколько удачно выполнился тест, но работает с исключениями в случае неудачного выполнения тестирования. Если сценарий шаг за шагом не вызывает никаких исключений, тест однозначно получает статус «PASSED», и продолжает свое выполнение. В другом случае тест может иметь статус «FAILED», «PENDING SCENARIO» или «UNDEFINED SCENARIO». Эта особенность Cucumber, как инструмента для внедрения автоматизации тестирования в проекте, помогает тестировщику, как разработчику автоматического сценария, отследить прогресс выполнения тестирования.
PASSED - статус для успешно пройденного теста, при условии что все шаги сценария в.feature файле соответствуют шагам кода в.rb файле и были полностью выполнены.
FAILED - статус для неудачно пройденного теста, при условии что все шаги сценария в.feature файле соответствуют шагам кода в.rb файле и были полностью выполнены, учитывая отсутствие ожидаемых исключений, которые могут быть выполнены дальше по коду сценария.
PENDING SCENARIO - статус для теста, для которого определены шаги как в сценарии - .feature файле, так и в коде - .rb файле, но по ходу выполнения были объявлены возможные исключения. Исключения необходимы в том случае, когда для дальнейшего выполнения сценария нужны дополнительные параметры, которые будут получены в другой части кода, за которую отвечает иной раздел сценария.feature или.rb файла. При отсутствии объявленных исключений там, где они нужны, выполнение сценария будет прекращено.
UNDEFINED SCENARIO - статус для теста, который показывает, что существует несоответствие сценариев, описанных в.feature и.rb файле. Этот статус полезен для инженера по тестированию во время разработки автоматического сценария, чтобы показать, какие шаги были пропущены в том или ином файле.
Все статусы, полученные в результате автоматического тестирования, место в файле с кодом или сценарием, и возможное решение возникшей проблемы, будут отображены в html-отчете, который будет сгенерирован программой Cucumber во время выполнения тестирования.
Инструкция по использования тестового сценария
В нашем проекте, занимающимся тестированием вышеописанного программного продукта, используемого для настройки и конфигурации коммуникационных сетей, для каждого вида тестирования существует определенная документационная база, подробно описывающая сам процесс тестирования.
Ручное регрессионное тестирование элементов проверки соответствия не является исключением: все шаги, которые должен выполнить инженер по тестированию для получения результата, также строго закреплены инструкцией. Поскольку автоматическое регрессионное тестирование элементов проверки соответствия значительно отличается от ручного по роду деятельности, было решено создать документ (описывающий техническую сторону тестирования), который будет помогать тестировщику во время выполнения тестирования. Поскольку разработанный автоматический скрипт гипотетически может быть использован глобально внутри межнационального проекта, язык инструкции - английский.
Анализ полученных результатов
Применяемые метрики
Как и любая деятельность прогресс тестирования оценивается определенными метриками, которые отображают временные, человеческие и финансовые ресурсы, затраченные на ту или иную активность. Также метрики показывают производительность одного сотрудника и команды в целом.
Для анализа полученных результатов использовались следующие метрики.
Производительность выполнения тестовых сценариев ручным способом (кол-во/час)
, где
ТР - производительность ручного тестирования,
NT - количество выполненных тестовых сценариев,
Тm - время, затраченное на выполнение всех ручных тестовых сценариев.
Производительность выполнения тестовых сценариев автоматическим способом (кол-во/час)
, где
АТР - производительность автоматического тестирования,
NАT - количество выполненных автоматических тестовых сценариев,
Тa - время, затраченное на выполнение всех автоматических тестовых сценариев.
Таким образом, при переходе от ручного тестирования к автоматическому производительность тестирования изменится в раз.
, где
n - количество выполненных автоматических тестов,
tm - время, затрачиваемое на выполнение одного теста ручным способом,
ta - время, затрачиваемое на выполнение одного теста автоматическим способом,
tap - время, затрачиваемое на подготовку к автоматическому тестированию.
Количественный анализ
Расчет разницы между ручным и автоматическим тестированием по времени
Анализ работы применяемого инструмента для тестирования Cucumber показал, что на выполнение теста на один элемент проверки соответствия тратится от 0,5 до 1,5 минут в зависимости от конфигурации. Автоматическое тестирование всех имеющихся элементов проверки соответствия в версии продукта 2.1 занимает 7,5 часов, то есть около одного рабочего дня одного члена команды.
Также стоит отметить, что на разработку, отладку и тестирование автоматических скриптов было затрачено около 27 рабочих дней. Однако необходимо учесть, что автоматический скрипт оказался универсальным для различных версий продукта. Кроме того, вероятность внедрения новых методов работы в программном продукте крайне мала, поэтому дальнейших ресурсов на обслуживание данного тестового сценария не требуется.
Здесь же отметим, что при выполнении автоматических тестов, необходимо около трех дней на подготовку к тестированию, сбор и обработку информации, анализ отчетов.
Таким образом, учитывая все действия, совершенные для первого использования автоматического скрипта для регрессионного тестирования элементов проверки соответствия версии 2.1 программного продукта (с учетом того, что первое регрессионное тестирование элементов проверки соответствия выполнялось вручную), выигрыша во времени не было из-за траты значительного количества времени на разработку, отладку и тестирование автоматического сценария.
Однако уже для версии 2.2 программного продукта для автоматического регрессионного тестирования элементов проверки соответствия нам необходимо на 50 дней меньше времени, чем для выполнения аналогичного ручного тестирования, при условии выполнения тестов одним человеком.
Поскольку уже известно количество элементов проверки соответствия, для которых будет проведено регрессионное тестирование для ПО версии 2.3, можно рассчитать затраты временных ресурсов для данного вида деятельности команды. В итоге, количество дней, высвобожденных после внедрения автоматического тестирования для 2.3 релиза, составляет 65 рабочих дней при условии выполнения регрессионного тестирования 1 человеком дважды за жизненный цикл этой версии программного продукта. Для версии продукта 2.k это значение составляет .
Текущая и спрогнозированная тенденция прироста времени после внедрения автоматического тестирования отображена на графике на Рис. 5.
Тенденция прироста времени (в днях) после внедрения автоматизированного тестирования
Расчет разницы между ручным и автоматическим тестированием по производительности
Если говорить о производительности, то регрессионное тестирование 500 элементов проверки соответствия версии 2.2 ПО занимало бы 31 день, производительность ручного тестирования составила 16 тестов в день. Аналогичная метрика для производительности автоматизированного регрессионного тестирования элементов проверки соответствия дает результат в 111 тестов в день. Из этих данных полагаем, что при переходе от ручного регрессионного тестирования элементов проверки соответствия к автоматическому производительность команды относительно данного вида деятельность увеличится почти в 7 раз. Таким образом, автоматизация тестирования значительно повышает уровень производительности команды и благоприятно сказывается на временных и человеческих затратах при проведении регрессионного тестирования элементов проверки соответствия.
Качественный анализ
Основой качественного анализа является анализ преимуществ и недостатков автоматического тестирования, применимых к текущему проекту.
Во-первых, Cucumber, как инструмент для проведения автоматического тестирования, удобен и прост в своем использовании. Он позволяет обычными, прямолинейными предложениями задавать сценарий выполнения теста. Тестировщику необходимо создать понятный односложный скрипт, задать аргументы для внутренних функций, тем самым подготовив авто-тест к воспроизведению. Также простота в использовании сказывается на отсутствии необходимости обучать каждого члена тест-команды работать со специфичным языком, объяснять тонкости тестовой программы.
Во-вторых, создав однажды такой сценарий, сотруднику не придется каждый раз тратить время на его обслуживание: от версии к версии методы, отвечающие за проверку соответствия, остаются неизменными (проанализирована применимость полученных автоматических тестов на 3 предыдущих релизах). В этом случае определенно прослеживается такое преимущество автоматического тестирования как снижение трудоемкости, поскольку всё, что необходимо сделать тестировщику - это поместить требуемые файлы, отражающие конфигурацию, в соответствующие им директории.
В-третьих, следует обратить внимание на человеческий фактор. Значительное различие машины и человека состоит в том, что человек не может работать идеально на протяжении всего рабочего дня: внешние и внутренние раздражители влияют на состояние тестировщика; к тому же деятельность человека многогранна, и из-за многозадачности человек может упустить какие-либо дефекты продукта. Поскольку внимательность компьютера не падает по причине усталости, при большом объеме монотонной работы, автоматизация является наилучшей альтернативой.
В-четвертых, инструмент для автоматического тестирования имеет возможность автоматического формирования и сохранения отчетов о результатах тестирования. При ручном тестировании сотруднику приходится самостоятельно составлять эти отчеты в виду их дальнейшей необходимости при регрессионном тестировании. Когда речь идет о значительном количестве тестов, время на ручное тестирование увеличивается за счет ручной генерации отчетов.
Также в качестве преимущества следует отметить, что Cucumber помогает отследить мелкие недочеты, касающиеся содержания ошибок соответствующих элементов. В эту категорию входят орфографические, пунктуационные ошибки и дефекты, связанные с формированием списка ошибок (их непостоянное месторасположение в массиве). Не всегда тестировщик может обратить внимание на такие недостатки, особенно после нескольких часов монотонной деятельности.
Следующее преимущество является исключительной особенностью тестируемого продукта. Бывают случаи, когда разработчики в силу человеческого фактора не учитывают изменения в модели некоторых элементов при составлении соответствующей документации. При автоматическом тестировании неучтенные элементы могут быть с легкостью выявлены, что довольно трудоемко при ручном тестировании.
Одним из недостатков автоматического тестирования является риск пропуска определенного вида дефектов. Однако, как показывает анализ Таблицы 1 обнаруженных дефектов, инструмент для автоматического тестирования отслеживает все важные недостатки, что также является весомым преимуществом в пользу автоматического тестирования. Результаты представлены в таблице:
Таб. 1. Количество обнаруженных дефектов
|
Sum of passed |
Sum of failed |
Sum of bugs |
|||
|
major |
minor |
||||
|
manual |
490 |
10 |
10 |
5 |
|
|
auto |
491 |
9 |
9 |
- |
По классификации дефектов тестирования, а именно по Градации Серьезности дефекта (Severity), существуют major и minor дефекты, «значительный» и «незначительный» соответственно. Существуют и другие уровни значимости дефектов: blocker - «блокирующие», critical - «критичные» и trivial - «тривиальные». В процессе ручного тестирования дефекты таких уровней не были обнаружены, поэтому не участвуют в анализе. Они характеризуют влияние дефекта на работоспособность приложения в определенной мере. Таким образом, при обнаружении дефекта ранга major тест получает статус failed. Текущий статус говорит о том, что объект тестирования не отвечает заявленным требованиям. Поскольку дефект типа minor незначительно влияет на программное обеспечение, тест получает статус passed.
Действительно, Cucumber не покрывает часть элемента проверки соответствия. В данную категорию входят область применения элемента, его описание, шаги для корректировки конфигурации. Как правило, ошибки, относящиеся именно к этим частям структуры, получают уровень minor. Для объективности результатов был проведен анализ количества обнаруженных ошибок, относящихся к различным элементам проверки соответствия, что также отображено в таблице. Поскольку их число незначительно и составляет лишь 1% от общего числа, было принято решение о допустимости этого процента ошибок уровня minor.
Другим недостатком автоматического тестирования является то, что инструмент для тестирования не может отследить ошибки, связанные с внешним оформлением программного обеспечения (GUI), сопутствующие ошибки функционала ядра (такие как неточности в позиционировании окон, ошибки форм и т.п.). Также упускается проверка дружественности интерфейса (usability): автоматизированный тест не может оценить дружелюбность, цветовую гамму, красоту и стиль интерфейса разрабатываемого продукта, это, несомненно, является недостатком автоматизации; с другой стороны, при ручном тестировании мнение тестировщика в данном вопросе может быть субъективным и не отражать реального состояния дел.
Более того такие важные нюансы учитываются во время других видов ручного тестирования, поэтому это так же не является существенным недостатком, влияющим на принятие решения о недопустимости автоматизации. Хочется отметить, что 100-процентная автоматизация не является совершенной альтернативой ручному тестированию. Дефекты, которые были найдены при ручном тестировании и являются косвенными по отношению к элементам проверки соответствия, также могут оказать влияние на статус соответствующего теста. Именно такую картину отражает таблица: при ручном тестировании было обнаружено 10 недочетов типа major, 2 из которых относятся к функциональной части программного обеспечения и не могут быть замечены инструментом Cucumber. Так как их количество невелико, то, принимая во внимание очевидные выгоды автоматизированного тестирования, здесь также было принято решение о допустимости данного процента ошибок при автоматизированном регрессионном тестировании элементов проверки соответствия.
Ко всему прочему следует отметить, что автоматическое тестирование не является бесконтрольным процессом, и каждый раз тестировщиком проводится анализ отчетов, полученных при выполнении автоматических тестов.
В процессе анализа полученных результатов было выявлено, что преимущества при автоматизации регрессионного тестирования для текущего проекта существенно перевешивают недостатки. Таким образом, можно сделать вывод, что риск внедрения автоматических тестов минимальный в виду его ощутимой эффективности. Даже при наличии упущений значительных (major) дефектов, доля обнаруженных недочетов остается несоизмеримо большой.
Как уже было отмечено, автоматическое тестирование имеет свои преимущества и недостатки и не служит панацеей в погоне за выигрышем во времени.
Заключение
В ходе работы было установлено что, внедрение автоматического тестирования для регрессионных тестов элементов проверки соответствия значительно повышает производительность команды, начиная со второй версии тестируемого программного продукта, и освобождает ресурсы без потери качества тестирования. Освобожденные ресурсы могут быть направлены на решение других немаловажных задач проекта.
Также для автоматизации регрессионного тестирования элементов проверки соответствия были определены дальнейшие перспективы развития.
Запускаемый тестовый сценарий может быть применен для автоматизации другой - параллельно разрабатываемой - версии продукта. Используемый скрипт может быть оформлен как универсальный посредством некоторых изменений в его коде. Таким образом, существует возможность его применения на объектах не только разных версий, но и разных доменов коммуникационных сетей: WCDMA, LTE и SmallCell.
Текущая загруженность тестировщика позволяет проводить регрессионное тестирование проверки соответствия в несколько раз чаще, что позволит более тщательно следить за развитием функционала программного обеспечения и наличием сопутствующей регрессии. Здесь необходимо обратить внимание на такое понятие как «стоимость ошибки»: чем позже обнаружен дефект, тем он «дороже». Если недочет, обнаруженный тестировщиком, может быть исправлен, то недочет, обнаруженный пользователем после официальной публикации приложения, останется до выхода следующей версии программного продукта, оказывая негативное влияние как на репутацию продукта, так и на репутацию команды тестировщиков.
Разработанный автоматический тест используется глобально внутри межнационального проекта и для других аналогичных программных продуктов заказчика.
В ходе работы над внедрением автоматизации регрессионного тестирования в текущем проекте были достигнуты следующие индивидуальные результаты:
· знакомство с инструментом для автоматизированного тестирования Cucumber,
· получение опыта автоматизации тестирования,
· улучшение навыков написания тестовых сценариев на языке Ruby,
· получение опыта анализа результатов автоматизированного тестирования и оценки целесообразности его применения.
Список литературы
1. Bertolino, A. Software Testing Research: Achievements, Challenges, Dreams / A. Bertolino // Future of Software Engineering. - 2007. - pp. 83-105.
2. Fewster, M. / Common Mistakes in Test Automation / M. Fewster // Grove Consultants. - 2001. - pp. 1-7.
3. Gulechha, L. / Software Testing Metrics / L. Gulechha // Cognizant Technology Solutions Collection. - 2008. - pp. 1-17.
4. Hartmann, J. / 30 Years of Regression Testing: Past, Present and Future / J. Hartmann // PNSQC. - 2012. - pp. 1-8.
5. Lin, X. / Regression Testing in Research and Practice / X. Lin // University of Nebraska Collection. - 2003. - pp. 1-6.
6. Ludewig, J. / Software Engineering in the year 2000 minus and plus ten / J. Ludewig // Informatics: 10 years back, 10 years ahead. - 2001. - pp. 102 - 111.
7. Pettichord, B. / Seven Steps to Test Automation Success / B. Pettichord // STAR West. - 2001. - pp. 1-17.
8. Economic Perspectives in Test Automation: Balancing Automated and Manual Testing with Opportunity Cost / R. Ramler [et la] // AST. - 2006. - pp. 85-91.
9. Walia, M. / Realizin Efficiency & Effectiveness in Software Testing through a Comprehensive Metrics Model / M. Walia // Building Tomorrow's Enterprise. - 2012. - pp. 1-24.
10. Wynne, M. The Cucumber Book / M. Wynne, A. Hellesoy. - The Pragmatic Bookshelf, 2012. - 328 pp.
11. Трудовой кодекс Российской Федерации [Электронный ресурс]: [федеральный закон: от 30.12.2001 г. №197-ФЗ, в ред. от от 28.12.2013 №421-ФЗ]. - Режим доступа: www.consultant.ru (дата обращения: 21.01.2015).
12. Винниченко, И. Автоматизация процессов тестирования / И. Винниченко. - СПб.: питерб 2005. - 203 с. - ISBN 5-469-00798-7.
13. Дастин, Э. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация / Э. Дастин, Д. Рэшка, Д. Пол; пер. с англ. Е. Молодцова, М. Павлов. - М.: ЛОРИ, 2003. - 589 с. - ISBN 5-85582-186-2.
14. Котляров, В.П. Основы тестирования программного обеспечения: учебное пособие / В.П. Котляров, Т.В. Коликова. - М.: Интернет-Ун-т Информ. Технологий, 2006. - 288 с. - ISBN 5-94774-406-4.
Размещено на Allbest.ru
Подобные документы
Тестирование как составляющая часть процесса отладки программного обеспечения, его роль для обеспечения качества продукта. Обнаружение ошибок в программах, выявление причин их возникновения. Подходы к формулированию критериев полноты тестирования.
курсовая работа [1,6 M], добавлен 20.12.2012Архитектура программного продукта и требования к платформе, обоснование выбора разработки. Закономерности и основные этапы алгоритмизации и программирования, а также отладка и тестирование продукта. Разработка и содержание руководства пользователя.
дипломная работа [2,3 M], добавлен 19.01.2017Анализ существующего программного обеспечения. Этапы создания проекта. Концептуальное, логическое и физическое проектирование базы данных. Структура программного продукта. Руководство программиста и оператора. Тестирование программного продукта.
курсовая работа [586,4 K], добавлен 26.06.2015Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.
курсовая работа [112,2 K], добавлен 22.03.2015Описание исходных текстов программного продукта. Системные требования и установка программного продукта. Тестирование пользователя по двадцати вопросам указанной темы и сохранение результатов тестирования. Форма отображения результатов тестирования.
курсовая работа [2,8 M], добавлен 09.07.2013Основные требования к составу и параметрам технических средства. Верификация программного продукта. Расширение функционала программы и его реализация. Отладка и тестирование программного продукта. Тестирование программы в граничных и реальных условиях.
курсовая работа [1,3 M], добавлен 29.12.2014История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
курсовая работа [309,5 K], добавлен 16.12.2015Технологии разработки программного обеспечения. Процедура постановки задачи, определения требований. Последовательность действий логической, разветвленной и циклической структуры. Терминология программирования. Этапы создания программного продукта.
презентация [793,8 K], добавлен 15.11.2010Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем.
курсовая работа [3,0 M], добавлен 19.11.2009Комплексное функциональное и структурное тестирование программного продукта - граф-программа решения квадратного уравнения. Постановка задачи структурного тестирования маршрутов. Заключение о типе и причине ошибки, предложение по ее исправлению.
курсовая работа [2,8 M], добавлен 05.01.2013
