Размещено на http://www.allbest.ru/

Выпускная квалифицированная работа

Разработка методики комплексного тестирования Open Source приложений

Кутепов Илья Павлович

Аннотация

Объектом исследования данной выпускной квалификационной работы является аспект тестирования стека программных продуктов, который создаётся из приложений и инструментов с открытым исходным кодом и функционально подобный инструментам платформы IBMWatson.

Целью работы является разработка методики комплексного тестирования приложений с открытым исходным кодом и функционально подобных инструментам платформы IBMWatson.

В результате выполнения данной магистерской диссертации были проанализированы уровни и виды тестирования, применяющиеся при комплексном тестировании приложений по методу чёрного ящика. Изложена технология проведения процесса тестирования. Проанализированы платформа IBMWatson и стек лабораторных работ, основанный на инструментах платформы. По результатам анализа платформы предложены OpenSource приложения и написаны планы тестирования стека лабораторных работ, основанных на программных продуктах открытых источников. Написана методика проведения комплексного тестирования, по результатам которой было проведено тестирование разработанных лабораторных работ.

Выпускная квалификационная работа состоит из введения, трёх частей, заключения, списка использованной литературы и приложений. В магистерской диссертации использованы 14 рисунков, 14 таблиц, 35 источников литературы, 5 приложений. Общее количество страниц выпускной квалификационной работы - 100.

программный код тестирование лабораторный

Abstract

The subject of investigation in current academic project is the testing concept of software products set which consists of open source applications and software tools and which is functionally similar with IBM Watson platform tools.

The primary aim of the proposed study is to develop the methodology for complex testing of open source applications, the functionality of which is similar with tools of IBM Watson platform.

Speaking about results obtained during carrying out this study the analysis of testing levels and types, which are applying in complex testing of applications by black-box method, should be mentioned. Also, the carrying out technology of testing process has been described. In addition, the IBM Watson platform and set of laboratory works based on its tools have been analyzed. According to the results of the platform analysis, open source applications have been proposed and scenarios for laboratory works testing have been composed (laboratory works have been developed based on open source software). The methodology of complex testing execution has been written, according to results of which the developed laboratory works have been tested.

The academic project consists of such parts as introduction, main body (which includes three major paragraphs), conclusion, list of references and list of appendices. The research work presented by undergraduates contains 14 illustrations, 14 tables, 35 referencesand 5 appendices. The total number of dissertation pages is 100.

Введение

Данная выпускная квалификационная работа посвящена разработке методики комплексного тестирования OpenSource приложений в составе платформы для разработки информационно-аналитических систем.

На данный момент всё больше различных компаний в РФ идут по пути импортозамещения. Это происходит по разным причинам: прекращение выпуска новых версий используемых продуктов разработчиками, прекращение обслуживания и сопровождения продуктов из-за санкционной политики или же простого желания компаний отказаться от приобретения платных, как правило, дорогих лицензий. В любом случае, компании, чтобы не разрабатывать аналоги имеющихся у них проприетарных продуктов, так как данный подход подразумевает отставание от зарубежных производителей, зачастую прибегают к использованию и модификации OpenSource решений, то есть приложений с открытым исходным кодом. Данные приложения необходимо протестировать, причём комплексно, для того чтобы определить, насколько они функционально соответствуют проприетарным технологиям. Поэтому важна грамотно разработанная методика комплексного тестирования по методу «чёрного ящика».

Актуальность работы обусловлена необходимостью проводить комплексные тесты Open Source приложений, способные показывать уровень соответствия заменяемым продуктам. Также, следует упомянуть, в настоящее время в рассматриваемой области отсутствуют готовые технологии и решения для этих целей.

Научная новизна работы заключается в отсутствии на рынке на текущий период решений для проведения комплексного тестирования приложений с открытым исходным кодом.

Практическая значимость магистерской диссертации состоит в уменьшении временных затрат на проведение процесса комплексного тестирования приложений с открытым исходным кодом.

Объектом исследования данной работы является аспект тестирования стека программных продуктов, который создаётся из приложений и инструментов с открытым исходным кодом и функционально подобный инструментам платформы IBMWatson.

Целью магистерской диссертации является разработка методики комплексного тестирования OpenSource приложений, функционально подобных платформе IBMWatson.

Задачи, необходимые для достижения цели выпускной квалификационной работы:

- анализ и описание уровней и видов тестирования, составляющие основу проведения комплексного тестирования;

- описание платформы IBMWatson;

- выявление функций и технических особенностей программных продуктов, которые входят в платформу;

- выбор функционально подобных программных продуктов с открытым исходным кодом;

- написание планов тестирования для проверки соответствия функционала OpenSourceпродуктов по сравнению с исходными продуктами;

- написание методики комплексного тестирования.

Структура магистерской диссертации представлена введением, тремя частями с выводами по каждой части, заключением, списком использованных источников и приложениями.

1. Аналитическая часть

1.1 Общие положения тестирования

Прежде чем рассказывать об комплексном тестировании, необходимо разъяснить, а что же вообще такое тестирование и для чего оно нужно. Ни для кого, не секрет, что сразу создавать какое-либо программное обеспечение (ПО) или программный продукт в совершенстве, то есть чтобы создаваемое решение функционировало без ошибок, невозможно. Исходя из этого, для того чтобы у конечных пользователей не оказалось критических ошибок в используемых ими программных продуктах, желательно уже на этапах разработки данных ПО проводить тестирование, необходимое для снижения риска возникновения ошибок, которые в свою очередь оказывают негативное влияние на работоспособность разрабатываемого решения. Также, следует отметить, что обеспечивать выполнение качественного тестирования является в равной степени важной задачей. Что же такое тестирование? Дадим определение тестированию ПО.

Тестирование программного обеспечения - способ деятельности по поиску и обнаружению различных ошибок в разрабатываемом или сопровождаемом ПО. В процессе тестирования определяется проверка соответствия программной реализации какого-либо продукта и выносятся требования к ней. Иными словами, тестирование является процессом, содержащим в себе все как статические, так и динамические проявления активности жизненного цикла [1]. Эти активности жизненного цикла относятся к подготовке, планированию, а также оценке какого-либо программного продукта. Следует отметить, что данные активности соответствуют описанным требованиям, а также они подходят для обнаружения дефектов и для заявленных целей.

Важность проведения тестирования ПО может быть продиктована следующими условиями:

- необходимостью выработки оценки элементов тестирования, которые принадлежат ко всему жизненному циклу процесса разработки программного обеспечения;

- необходимостью выработки верификации проверяемых элементов тестирования;

- необходимостью выработки валидации проверяемых элементов тестирования;

- учёта того, что проверяемые элементы тестирования не всегда делают то, что от них ожидается;

- учёта того, что лица, которые принимают решения, могут запросить информацию о показателях качества элементов проводимого тестирования.

Какие-либо допущенные дефекты или ошибки как правило имеют место существовать и неизбежны. В разрабатываемом продукте, над которым работает человек, могут быть допущены непреднамеренные ошибки или попросту опечатки, которые в последствии приведут к возникновению дефекта в данном продукте. Этот дефект может не оказывать сразу сильного влияния на функционирование и стабильную работу программного обеспечения ровно до тех пор, пока не будет найден в результате эксплуатации ПО. Однако, когда разработанный продукт уже сдан в эксплуатацию конечным пользователям и там в реальных условиях обнаружились различные дефекты, то получается, что разработанное ПО не соответствует потребностям пользователей [2]. Эффект от программной ошибки может очень серьёзно повлиять, к примеру, на безопасность предприятия или самих пользователей, различный бизнес, бизнес-экономические или репутационные решения. Поэтому важно не допускать такого исхода событий.

Как известно, процесс тестирования направлен на поиск и обнаружение каких-либо существующих дефектов в каком-либо программном продукте или системе. Базируясь на данном определении, можно сформулировать цель проведения тестирования, которая заключается в обнаружении определённых обстоятельств, при которых выявляются ошибки или дефекты разрабатываемого программного продукта или комплекса программных пакетов, а также последующим занесением выявленных дефектов в систему отслеживания ошибок. После занесения в ходе тестирования найденных ошибок в систему их отслеживания (баг-трекинговую среду), данные ошибки исправляются командой разработчиков в процессе отладки или доработки программного кода какого-либо приложения, так как в задачи тестирования входит только обнаружение ошибок. Помимо обнаружения ошибок, в задачи тестирования входит проведения процессов различных проверок, соответствует ли разрабатываемое программное обеспечение предъявляемым к нему требованиям [3].

Таким образом, уменьшение числа ошибок в выпускаемом конечном программном продукте является ещё одной целью применения процесса проведения тестирования. Однако, следует отметить, что нельзя добиться полной гарантии исключения ошибок в каком-либо приложении при проведении тестирования [4].Тем не менее компетентно организованное тестирование позволяет быть уверенным в том, что разрабатываемое ПО полностью удовлетворяет предъявляемым к нему требованиям, а также позволяет быть уверенным в том, что данный программный продукт ведёт себя в соответствии с этими требованиями во всех предусмотренных ситуациях.

1.2 Объект тестирования

Существует множество объектов тестирования на различных этапах жизненного цикла программного обеспечения, для которых необходимо проводить процесс тестирования. К таким объектам могут относится:

- программные модули (также программный код данных модулей);

- различные спецификации программных модулей;

- группы программных продуктов, которые решают определённые функциональные задачи;

- программные средства, которые подлежат испытаниям для сдачи в опытную эксплуатацию;

- различные комплексы программ, на стадии проведения отладки;

- какое-либо сопровождаемое ПО.

Представленные примеры объектов тестирования различаются уровнем теоретической разработки этапов и методов процесса тестирования, а также сложностью самого проведения тестирования. Из-за большого количества разнообразных технологий, архитектур, интерфейсов, характеристик различных систем и функциональных предназначений - каждый требует определённого подхода к проведению тестирования. Поэтому важно точно определить объект тестирования.

Объектом исследования в данной работе является аспект тестирования стека программных продуктов, который создаётся из приложений и инструментов с открытым исходным кодом и функционально подобный инструментам платформы IBMWatson.

1.3 Уровни тестирования

В современном мире, согласно стандарту [2], в зависимости от того, что подвергается тестированию: модуль, группа модулей или единая система, применяются различные уровни тестирования. Принято выделять такие уровни тестирования, как модульное, интеграционное, системное и приёмочное тестирования [5]. На рисунке 1 представлены все эти уровни тестирования.



Рис. 1. Классификация уровней тестирования

В рамках модульного тестирования все тестировочные процессы осуществляются на уровне модулей и отдельных функций с целью выявления в них ряда ошибок, которые могли быть заложены ещё в ходе разработки алгоритмов функционирования этих функций [6]. Кроме того, на данном этапе выявляется степень готовности к переходу на следующий уровень тестирования. Уровень модульного тестирования предполагает знание внутреннего устройства программы, так как выявление различных дефектов и ошибок в алгоритмах построения функций невозможно без анализа тех или иных фрагментов программного кода. Применительно к исследуемому объекту тестирования, следует отметить, что модульное тестирование не применимо к данному объекту, так как приложения с открытым исходным кодом уже являются готовыми и протестированными модулями.

Интеграционное тестирование представляет собой тестирование программных пакетов (функций), которые интегрированы в совместно работающие комплексы или в одну программно-аппаратную среду (окружение). На данном уровне тестирования осуществляется проверка корректности взаимодействия функций и их окружения (оборудования, самой операционной системы и т.д.) [7]. Интеграционное тестирование следует проводить в рамках любой системы, так как всегда нужна гарантия того, что любые объединённые функции или программные пакеты и их среды корректно работают в комплексе.

Уровень системного тестирования характеризуется совместной работой всех объединённых функций, то есть, по своей сути, данный уровень служит логическим продолжением уровня интеграционного тестирования [7]. На этом этапе устранению подлежат все существующие ошибки отдельно взятых программных пакетов и функций. Таким образом, на данном уровне тестирования осуществляется проверка работоспособности системы в целом.

Приёмочное тестирование является этапом тестирования, на котором выполняются приёмо-сдаточные испытания, то есть проверка соответствия разработанной системы или комплекса программных пакетов определенным требованиям, предъявленным к ней организацией-заказчиком [8]. В случае если система не прошла эти испытания с первого раза, её отправляют на доработку. Стадии приёмочного тестирования и доработки будут повторяться до тех пор, пока не будет принято решение о приёме системы и не будут подписаны документы об её выпуске.

1.4 Виды тестирования

Классификация тестирования может проводиться не только по уровням, но также и по видам тестирования, при этом на каждом уровне тестирования могут применяться различные виды тестирования. На сегодняшний день насчитывается несколько способов классификации видов тестирования, однако наиболее часто используемыми являются следующие принципы классификации [9]:

- по объекту тестирования;

- по времени проведения;

- по позитивности сценариев;

- по степени автоматизации;

- по доступу к коду ПО.

Данная классификация по перечисленным выше принципам представлена на рисунке 2.

Рис. 2. Виды тестирования

По объекту тестирования различают следующие две большие группы (рис. 3):

- функциональное или регрессионное;

- нефункциональное.



Рис. 3. Структура вида тестирования по объекту тестирования

Функциональное тестирование, как следует из названия, основывается на функциональных тестах, реализующих проверку и контроль функциональности тестируемой системы, подробно описанной в требованиях к системе [10]. Данный вид тестирования уделяет внимание внешнему поведению тестируемого продукта, а также учитывает его интеграцию с другими программными продуктами.

Функциональное (или регрессионное) тестирование включает в себя следующие виды тестов:

- функциональное тестирование;

- тестирование взаимодействия;

- регрессионное тестирование;

- тестирование безопасности.

Нефункциональное тестирования является тем видом тестирования, при котором составляются тесты, определяющие характеристики тестируемой системы, то есть описание того, как работает тот или иной программный пакет по отдельности и сама система в целом.

К нефункциональному тестированию можно отнести следующие виды тестов:

- стрессовое тестирование;

- тестирование на отказ;

- тестирование установки;

- нагрузочное тестирование;

- тестирование надежности;

- конфигурационное тестирование.

По времени проведения выделяют следующие виды тестирования (рис. 4):

- альфа-тестирование;

- бета-тестирование.

Рис. 4. Структура вида тестирования по времени проведения

Альфа-тестирование представляет собой вид тестирования, выполняемого на ранних стадиях разработки некоего программного продукта или системы и имитирующего процесс реальной работы с тестируемым продуктом разработчиками данного продукта.

Бета-тестирование применяется уже к практически готовому продукту и заключается в выявлении максимально возможного количества дефектов и ошибок, с целью последующего процесса их устранения.

По критерию позитивности сценариев, выделяются следующие виды тестирования (рис. 5):

- позитивное тестирование;

- негативное тестирование.



Рис. 5. Структура вида тестирования по позитивности сценариев

Позитивное тестирование представляет собой особый случай тестирования, при котором тестирование работы программного обеспечения производится при «корректном» (правильном) наборе входных данных [8]. Негативное тестирование противоположно по смыслу и исполнению позитивному тестированию.

По степени автоматизации, тестирование делится на:

- автоматизированное;

- полуавтоматизированное;

- ручное.

Разделение по степени автоматизации представлено на рисунке 6.

Рис. 6. Структура вида тестирования по степени автоматизации

Автоматизированное тестирование предназначено для проведения тестов и последующего контроля их работы [11]. Данный вид тестирования осуществляется тестировщиком при помощи специальных программных средств, как позаимствованных у сторонних разработчиков, так и самостоятельно написанных тестировщиком.

Полуавтоматизированное тестирование, согласно своему названию, производится тестировщиком как вручную, так и с применением специальных автоматизированных средств. Поэтому, данный вид тестирования можно считать золотой серединой при выборе между ручным и автоматизированным тестированием.

Ручное тестирование, в свою очередь, предполагает обратное выполнение, то есть проведение тестов вручную тестировщиком, без применения каких-либо специальных утилит. Такой вид тестирования предполагает взаимодействие с тестируемым продуктом в том виде, как это бы делал обычный пользователь.

По доступу к коду ПО выделяют следующие методы, которые представлены на рисунке 7:

- метод «чёрного ящика»;

- метод «серого ящика»;

- метод «белого ящика».

Рис. 7. Структура вида тестирования по доступу к коду ПО

Метод «чёрного ящика» подразумевает тестирование без доступа к коду ПО. Тестировщику необязательно знать внутреннее устройство и структуру программного продукта.

Метод «серого ящика» основывается на тестировании предыдущим методом, но подразумевается знание внутренней структуры ПО. Тестировщик должен быть знаком с внутренним устройством программного продукта или приложения, а также с взаимодействием между компонентами.

Метод «белого ящика» подразумевает тестирование какого-либо приложения или программного продукта с доступом к коду. Тестировщик должен знать тот язык программирования, на котором написано тестируемое ПО.

Следует отметить, что в основе комплексное тестирование прежде всего лежит интеграционная технология, так как главное создать среду тестирования, причем при интеграции туда очередного разработанного решения тестовые данные не изменяются. Также, комплексное тестирование связано и с функциональным, так как должна проверятся работоспособность функций. После того, как интеграция будет завершена и проверена правильность функций, можно проверить разработанный продукт на то, как он выдерживает нагрузку, то есть применить технологию нагрузочного тестирования. Исходя из всего вышеописанного, необходимо подробно описать данные технологии.

1.5 Технология тестирования

Тестирование - потенциально лучшая основа разработки программного обеспечения, поскольку она имеет дело с четко определённой ситуацией, то есть с какой-то фиксированной программой и тестом (конечным набором входных значений). Однако фундаментальная теория тестирования программ находится в замешательстве. Одной из причин является смешение целей тестирования - что делает какой-либо тест или метод тестирования «хорошим». Считается, что основной целью тестирования должно быть измерение надежности тестируемого программного обеспечения.

Книга Гленфорда Майерса озаглавлена «Искусство тестирования программного обеспечения», и она сохраняет свою популярность и значимость даже спустя довольно продолжительное время после публикации [12]. Действительно, тестирование обычно рассматривается как искусство с целью, которую Майерс поручает исполнению программного обеспечения для выявления сбоев. Тестирование программ занимает уникальную нишу в стремлении сделать разработку программного обеспечения инженерной дисциплиной. Инженерные испытания - это корректирующая обратная связь, которая позволяет усовершенствовать методы проектирования и строительства для достижения практических целей. Нигде аморфная природа программного обеспечения не является более очевидной трудностью: тестирование сложно проводить, и оно не отвечает техническим потребностям, потому что программные сбои ПО не поддаются простому пониманию и категоризации. Когда происходит сбой в какой-либо программной системе, часто мы мало что узнаем, за исключением того, что было слишком много возможных режимов отказов.

Чтобы планировать и выполнять тесты, тестировщики программного обеспечения должны учитывать ПО и вычисляемую им функцию, входные данные и способы их объединения, а также среду, в которой программное обеспечение в конечном итоге будет работать. Этот сложный, трудоемкий процесс требует технических знаний и правильного планирования. Тестировщики должны не только иметь хорошие навыки разработки - тестирование часто требует большого количества кодирования, но также должны быть хорошо знакомы с формальными языками, теорией графов и алгоритмами. Действительно, творческие тестировщики принесли много смежных компьютерных дисциплин для решения проблем тестирования, часто с впечатляющими результатами. Чтобы получить более четкое представление о некоторых трудностях, присущих тестированию программного обеспечения, мы можем подойти к тестированию в четыре этапа:

- моделирование программной среды;

- выбор тестовых сценариев;

- запуск и оценка тестовых сценариев;

- измерение прогресса тестирования.

Эти фазы предлагают тестировщикам структуру, в которой можно сгруппировать связанные проблемы, которые они должны решить, прежде чем перейти к следующему этапу.

1.5.1 Моделирование операционной среды

Задача тестировщика - моделировать взаимодействие между программным обеспечением и его средой. Тестировщики должны идентифицировать и моделировать интерфейсы, которые использует программная система, и перечислять входные данные, которые могут пересекать каждый интерфейс ПО [13]. Это может быть самой фундаментальной проблемой, с которой сталкиваются тестировщики, и это может быть трудно, учитывая различные форматы файлов, протоколы связи и сторонние интерфейсы прикладного программирования. Опишем четыре общих интерфейса:

1. Человеческие интерфейсы. Они включают в себя все распространенные методы взаимодействия людей с программным обеспечением. Наиболее заметным является графический интерфейс пользователя (graphicaluserinterface - GUI), но старые решения, такие как интерфейс командной строки и интерфейс на основе меню, все еще используются. Возможные механизмы ввода - это щелчки мыши, события клавиатуры и ввод с других устройств. Затем тестировщики решают, как организовать эти данные, чтобы понять, как собрать их в эффективный тест.

2. Программные интерфейсы приложения. Также называемые API (applicationprogramminginterface), - это то, как программное обеспечение использует операционную систему, базу данных или библиотеку среды выполнения. Услуги, предоставляемые этими приложениями, моделируются как тестовые входные данные. Задача тестировщиков - проверить не только ожидаемые, но и неожидаемые сервисы. Например, все разработчики ожидают, что операционная система сохранит файлы для них. Сервисом, которым они порой пренебрегают, является информирование операционной системы о том, что носитель данных заполнен. Даже сообщения об ошибках должны быть проверены.

3. Интерфейсы файловой системы. Они существуют каждый раз, когда программное обеспечение читает или записывает данные во внешние файлы. Разработчики должны написать много кода для проверки ошибок, чтобы определить, содержит ли файл соответствующие данные и форматирование. Таким образом, тестировщики должны создавать или генерировать файлы с контентом, который будет содержать как нормальные данные, так и ошибочные, а также файлы, содержащие различные текстовые и другие данные с различными форматами.

4. Интерфейсы связи. Данные интерфейсы обеспечивают прямой доступ к физическим устройствам (таким как драйверы устройств, контроллеры и другие встроенные системы) и требуют протокола связи. Для тестирования такого программного обеспечения тестировщики должны иметь возможность генерировать как действующие, так и недействующие потоки протокола. Тестировщики должны собрать и представить тестируемому программному обеспечению множество различных комбинаций команд и данных в правильном формате пакета.

Также тестировщики должны обязательно понимать взаимодействие с пользователем, которое выходит за рамки контроля какого-либо тестируемого программного обеспечения, поскольку последствия могут быть серьезными, если ПО не протестировано должным образом.

Следует отметить, что, когда интерфейс представляет проблемы бесконечного размера или сложности, тестировщики сталкиваются с двумя трудностями: они должны тщательно выбирать значения для любой переменной ввода, а также должны решить, как упорядочивать ввод. При выборе значений тестировщики определяют значения отдельных переменных и назначают различные комбинации значений, когда программа принимает несколько переменных в качестве входных данных. Более сложным вопросом является выбор значений для нескольких переменных, обрабатываемых одновременно, которые могут потенциально влиять друг на друга. Тестировщики должны учитывать весь перекрестный продукт комбинаций значений.

При принятии решения о том, как упорядочить входные данные, у тестировщиков возникает проблема генерации последовательности. Они рассматривают каждый физический ввод и абстрактное событие как символы в алфавите формального языка и определяют модель этого языка. Модель позволяет тестировщикам визуализировать набор возможных тестов, чтобы увидеть, как каждый тест соответствует общей картине. Наиболее распространенной моделью является график или диаграмма состояний, хотя существует много других вариантов. Другие популярные модели включают регулярные выражения и грамматики, инструменты из теории языка. Менее используемые модели - это случайные процессы и генетические алгоритмы. Модель представляет собой представление, описывающее, как символы ввода и события объединяются для создания синтаксически правильных слов и предложений.

1.5.2 Выбор тестовых сценариев

Многие модели предметной области и различные разделы представляют собой бесконечное количество тестовых сценариев, каждый из которых стоит времени и денег. В любом реалистичном графике разработки программного обеспечения может быть применено довольно большое количество тестовых сценариев. Тестировщики пытаются покрыть исходный код модели или его входную область, то есть онистремятся к охвату предметной области. Охватывают операторы кода, то есть выполнение каждой строки исходного кода хотя бы один раз, а также охватывают входные данные, применяя при этом каждое внешне сгенерированное событие. Это минимальные критерии, которые тестировщики используют для оценки полноты своей работы; поэтому набор тестов, который выбирают многие тестировщики, соответствует их целям покрытия.

Однако, если бы охват кода и ввода был достаточным, в выпущенных продуктах было бы очень мало ошибок. Что касается кода, тестировщиков интересуют не отдельные операторы кода, а пути выполнения: последовательности операторов кода, представляющих выполнение программного обеспечения. К сожалению, существует бесконечное количество путей. Что касается области входных данных, то некоторых тестировщики интересуют не отдельные входные данные, а входные последовательности, которые в целом представляют собой сценарии, на которые должно реагировать программное обеспечение. Их тоже бесконечное множество.

Тестировщики сортируют эти бесконечные наборы, чтобы получить наилучшие критерии адекватности тестовых данных, которые предназначены для адекватного и экономичного представления любого из бесконечных наборов. «Лучший» и «адекватный» являются субъективными; тестировщики обычно ищут набор, который найдет наибольшее количество ошибок. Многие пользователи и специалисты по обеспечению качества заинтересованы в том, чтобы тестировщики оценивали типичные сценарии использования - то, что чаще всего происходит так сказать в полевых условиях. Такое тестирование гарантирует, что программное обеспечение работает, как указано, и что наиболее часто встречающиеся ошибки будут обнаружены.

Следует отметить критерии проверки выполнения теста. Критерии адекватности тестовых данных концентрируются либо на покрытии пути выполнения, либо на входной последовательности, но редко на обоих. Наиболее распространенные критерии выбора пути выполнения сосредоточены на путях, охватывающих управляющие структуры. Приведем пример критериев выбора:

- выберите набор тестов, которые приводят к тому, что каждый исходный оператор выполняется хотя бы один раз;

- выберите набор тестов, в котором каждая ветвящаяся структура (If, Case, While и т.д.) будет оцениваться с каждым из её возможных значений.

Тем не менее, поток управления является лишь одним аспектом исходного кода. На самом деле программное обеспечение перемещает данные из одного места в другое. Семейство потоков критериев адекватности тестовых данных описывает охват этих данных [14]. К примеру, можно выбрать набор тестов, которые вызывают инициализацию и последующее использование каждой структуры данных. Наконец, интересен поиск неисправностей, который требует от исследователей большего внимания, чем практиков. В этом методе ошибки преднамеренно вставляются (засеваются) в исходный код. Затем тестовые сценарии, предназначенные для поиска этих ошибок, в идеале, обнаруживают эти ошибочные данные, причем тестировшик также находит реальные ошибки. Таким образом, возможен критерий, как выбор набора тестов, который выявляет каждую из найденных неисправностей.

Также следует указать на критерии проверки входных данных. Критерии для диапазона охвата входной области от простого покрытия интерфейса до более сложных статистических измерений могут выглядеть следующим образом:

- выберите набор тестов, которые содержат каждый физический вход;

- выберите набор тестов, которые будут симулировать каждый элемент управления интерфейса (окно, меню, кнопки и т.п.).

Критерий дискриминации требует случайного выбора входных последовательностей, пока они статистически не представляют всю бесконечную входную область [15]. Данный критерий может быть представлен следующим образом:

- выберите набор тестов, которые имеют те же статистические свойства, что и все входные данные;

- выберите набор путей, которые могут быть выполнены обычными пользователями.

В настоящее время, исследователи тестирования активно изучают алгоритмы выбора минимальных наборов тестов, которые удовлетворяют критериям для путей выполнения и входных данных. Большинство исследователей согласны с тем, что при принятии важных решений о выпуске целесообразно использовать несколько критериев. Необходимы эксперименты, сравнивающие испытания о адекватности исследуемых критериев. Однако в настоящее время тестировщики должны знать, какие критерии встроены в их методологию, и понимать присущие им ограничения при представлении результатов.

1.5.3 Запуск и оценка тестовых сценариев

Определив подходящие тесты, тестировщики преобразуют их в исполняемую форму, часто в код, чтобы результирующие сценарии тестирования имитировали типичные действия пользователя. Поскольку ручное применение тестовых сценариев является трудоемким и подверженным ошибкам, тестировщики стараются максимально автоматизировать тестовые сценарии. Во многих средах возможно автоматизированное применение входных данных с помощью кода, имитирующего пользователей.

Полная автоматизация требует моделирования каждого входного источника и выходного значения всей операционной среды. Тестировщики часто включают код для сбора данных в моделируемую среду в качестве тестовых перехватчиков или утверждений. Этот код предоставляет информацию о внутренних переменных, свойствах объекта и т.п. Этаинформация удаляется при выпуске программного обеспечения, но во время выполнения сценария тестирования она предоставляет ценную информацию, которая помогает тестировщикам выявлять сбои и изолировать их.

Оценка сценария, вторая часть этого этапа, она легко формулируется, но ее трудно выполнить, причём гораздо реже её удаётся автоматизировать. Оценка включает в себя сравнение фактического вывода программного обеспечения, полученного в результате выполнения тестового сценария, с его ожидаемым результатом, задокументированным спецификацией, считающиеся правильной.

На практике это сравнение трудно достичь. Такая трудность является причиной того, почему фактическое сравнение ожидаемых результатов обычно выполняется человеком: тестировщиком, который визуально контролирует вывод на экран и тщательно анализирует выходные данные. Существует два подхода к оценке тестового сценария: формализм и встроенный код теста.

Формализм в основном включает в себя тяжелую работу по формализации написания спецификаций и извлечения из них конструкций и кода [16]. Как объектно-ориентированная, так и структурированная разработка содержат механизмы для формального выражения спецификаций, чтобы упростить задачу сравнения ожидаемого и фактического поведения. Промышленность обычно уклоняется от формальных методов; тем не менее, хорошая спецификация, даже неофициальная, все еще чрезвычайно полезна. Без спецификации тестировщики, вероятно, найдут только самые очевидные ошибки. Кроме того, отсутствие спецификации тратит значительное время процесса тестирования, когда тестировщики сообщают о неуказанных функциях как об ошибках.

Существуют два типа встроенного тестового кода. Самым простым типом является тестовый код, который предоставляет определенные внутренние объекты данных или состояния, которые облегчают тестировщику оценку правильности. Как правило, такая функциональность невидима для пользователей. Тестировщики могут получить доступ к результатам тестового кода, например, с помощью API тестирования или отладчика.

Более сложный тип встроенного кода включает в себя программы самотестирования [17]. Иногда это включает в себя кодирование нескольких решений проблемы и наличие одного решения для проверки другого, или написание обратных подпрограмм, которые отменяют каждую операцию. Если операция выполняется, а затем отменяется, результирующее состояние программного обеспечения должно быть эквивалентно его предоперационному состоянию. В этой ситуации тестировщик может не найти ошибку, так как ошибка может содержаться в обеих операциях, где каждая ошибка маскирует другую.

После того, как тестировщики отправляют успешно воспроизведенные ошибки или сбоина доработку, разработчики обычно создают новую версию программного обеспечения, в которой якобы была устранена ошибка. Тестирование проходит через последующие версии программного обеспечения до тех пор, пока одно из них не будет признано пригодным для выпуска. Вопрос в том, сколько раз нужно провести повторное тестирование, так называемое регрессионное тестирование.

Любое конкретное исправление ошибок может сделать следующие ситуации:

1) исправить только проблему, о которой было сообщено;

2) не решить проблему;

3) исправить проблему, но сломать что-то, что ранее работало;

4) не решить проблему и сломать что-то остальное.

Учитывая эти возможности, было бы целесообразно перезапускать каждый тест с предыдущей версии на следующую версию, прежде чем тестировать что-либо новое, хотя такая практика, как правило, непозволительна по стоимости [18]. Более того, новые версии программного обеспечения часто имеют расширенные новые функциональные возможности в дополнение к устранённой ошибке, поэтому регрессионные тесты отнимали бы достаточно много времени от тестирования свежей версии разрабатываемого продукта. Поэтому для экономии ресурсов тестировщики работают в тесном сотрудничестве с разработчиками, чтобы расставить приоритеты и минимизировать регрессионные тесты.

Другим недостатком регрессионного тестирования является то, что эти тесты могут временно изменить назначение критериев адекватности данных тестовых сценариев, выбранных на более ранней стадии. Выполняя регрессионные тесты, тестировщики стремятся только показать отсутствие ошибки и заставить приложение демонстрировать определенное поведение. В результате, критерии адекватности тестовых данных, которыми до сих пор руководствовались при отборе тестов, игнорируются.

В идеале, разработчики будут писать код с мыслью о тестировании. Если код будет трудно тестировать и проверять, то его следует переписать, чтобы сделать его более тестируемым. Аналогично, методология тестирования должна оцениваться по её вкладу в решение проблем автоматизации. Следует учесть, что слишком много методологий дают мало рекомендаций в любой области.

Еще одна проблема для тестировщиков при выполнении и проверке разрабатываемого приложения - координация действий по отладке с разработчиками [19]. Поскольку сбои выявляются тестировщиками и диагностируются разработчиками, возникают две проблемы: воспроизведение сбоев и повторное выполнение сценариев тестирования.

Воспроизведение тестирования с ошибками не является легким делом, как может показаться. Конечно же, можно просто повторно запустить тест с ошибками и снова наблюдать за ошибочным поведением, хотя повторный запуск теста не гарантирует, что будут созданы точно такие же условия, как и до этого. Повторное выполнение сценария требует, точное знания состояния операционной системы и любого сопутствующего ПО. Например, клиент-серверные приложения потребовали бы воспроизведения условий, окружающих как клиента, так и сервер. Кроме того, мы должны знать состояние автоматизации тестирования, периферийных устройств и любых других фоновых приложений, работающих локально или по сети, которые могут повлиять на тестируемое приложение.

1.5.4 Определение прогресса тестирования

Определения прогресса проведённого тестирования достаточно субъективный процесс. Причина в том, что для оценивания прогресса тестирования необходимо посчитать несколько вещей. Подсчитываются количество примененных в тесте входных данных, процент кода, который мы охватили, и количество раз, когда вызывалось приложение. Также подсчитываются, сколько раз успешно закрывалось приложение, количество обнаруженных сбоев и т.д. Интерпретировать такие подсчёты сложно, так как большое количество ошибок может означать, что тестирование было тщательным и их осталось очень мало. Или это может означать, что в программном обеспечении просто много ошибок, и, хотя многие из них были обнаружены, многие из них всё равно останутся.

Поскольку показатели подсчета дают очень мало информации о ходе тестирования, многие тестировщики дополняют эти данные, следуя определённым моментам, которые предназначены для определения полноты структурного и функционального тестирования. Например, чтобы проверить структурную полноту, тестировщики могут следовать следующим моментам:

- осуществление проверки на общие программные ошибки [20];

- использование всего исходного кода [14];

- инициализация и использование всех внутренних данных [15];

- нахождение всех намеренно добавленных ошибок [14].

Чтобы проверить функциональную полноту, тестировщики могут следовать следующим моментам:

- проведение анализа о том, какое программное обеспечение может дать сбой, а также показывают ли проведённые тесты, что ПО не дало сбой [21];

- применение всех входных данных [1];

- исследование пространства состояний программного обеспечения [15];

- выполнение всех сценариев поведения, которые ожидались от пользователей [22].

Эти моменты, по существу, являются критериями адекватности тестовых данных, что полезно для тестировщиков. Однако определение того, когда прекратить тестирование, определение того, готов ли разрабатываемый продукт к выпуску, является более сложным. Тестировщики хотят количественно измерить наличие ошибок, оставленных в программном обеспечении, и вероятность того, что любая из этих ошибок будет обнаружена при эксплуатации данного ПО. Если тестировщики могут достичь такой меры, то становится понятно, что нужно прекратить тестирование. Можно подойти к этой проблеме с двух точек зрения; структурной и функциональной.

Со структурной точки зрения, тестируемость - способ определения сложности тестирования приложения [23]. Идея заключается в том, что количество строк кода, определяющее сложность тестирования программного обеспечения, устарела; проблема намного сложнее. Если продукт обладает высокой тестируемостью, его легко тестировать и, следовательно, легче находить ошибки. Затем можно отследить тестирование и наблюдать, что из-за того, что ошибок мало, маловероятно, что их осталось много нераскрытых. Низкая тестируемость потребует еще больше тестов, чтобы сделать те же выводы, то есть ожидается, что ошибки будет труднее найти.

С функциональной точки зрения, модели надежности - математические модели тестовых сценариев и данных о сбоях, которые пытаются предсказать будущие паттерны отказов на основе прошлых хорошо известных данных [23]. Таким образом, эти модели пытаются предсказать, как программное обеспечение будет вести себя при эксплуатации на основе того, как оно ведёт себя во время тестирования. Для этого большинству моделей надежности требуется спецификации рабочего профиля, то есть описания того, как пользователи должны применять входные данные. Чтобы вычислить вероятность отказа, эти модели делают некоторые предположения о лежащем в основе распределении вероятности, которое управляет возникновением отказа. Однако такие профили очень сложно собрать. Тем не менее, успешные тематические исследования показали, что эти модели заслуживают доверия.

1.6 Методы проведения тестирования

1.6.1 Основные подходы к проведению тестирования

Тестирование программного обеспечения является наиболее часто используемым методом проверки и подтверждения качества ПО. Следует отметить, что данный процесс является достаточно трудоемким, а также дорогим, что составляет больше половины от общей стоимости разработки программного обеспечения [24]. Тестирование ПО является одной из самой важной деятельностью жизненного цикла разработки программного обеспечения. Рассуждая о методе тестирования чёрного ящика, нельзя не сказать и о противоположном методе - методе белого ящика. На языке верификации и валидации тестирование черного ящика часто используется для валидации, а тестирование белого ящика часто используется для верификации [25].

В целом при тестировании, используются, как правило, только два данных метода. Следует отметить, что тестирование черного ящика также называется функциональным тестированием, методом функционального тестирования, который разрабатывает тестовые наборы на основе информации из написанной спецификации к программному продукту [26]. При тестировании «черного ящика» тестировщик программного обеспечения не должен или не имеет доступа к внутреннему исходному коду, то есть он не касается внутренних механизмов системы; они сосредоточены исключительно на выходах. При данном подходе, код просто считается «большим чёрным ящиком» для тестировщика, который не может видеть, что внутри ящика. Тестировщик программного обеспечения знает только, что информация может быть введена в чёрный ящик. Это может быть сделано исключительно на основе знаний спецификации требований для конкретного программного продукта; тестировщик знает, чего ожидать от отправки чёрного ящика, и проверяет, отправляет ли чёрный ящик то, что он должен отправить [27].

С другой стороны, тестирование белого ящика называется структурным тестированием или тестированием «стеклянного ящика». Данное название дано не случайно. Технику структурного тестирования, которая разрабатывает тестовые наборы на основе информации, полученной из исходного кода, можно назвать прозрачной, так как виден сам программный код. Следует сказать, что тестирует методом белого ящика, чаще всего разработчик программного кода, который знает, как выглядит код, и записывает тестовые сценарии, которые выполнят определённые методы с различными параметрами. Тестирование белого ящика связано с внутренним механизмом системы, оно в основном сфокусировано на потоке управления или потоке данных программ [28].

1.6.2 Спектр тестирования

Тестирование программного обеспечения вовлечено в каждый этап жизненного цикла ПО, но способ тестирования, проводимый на каждом этапе разработки программного обеспечения, различен по своей природе и имеет разные цели.

Определим, для каких основных типов тестирования применятся тот или иной метод проведения тестирования. Данное сравнение представлено в таблице 1.

Таблица 1 Таблица спектра тестирования

Тип тестирования	Метод тестирования	Описание	Кто проводит тестирование?
Интеграционное	«белый ящик» «серый ящик» «чёрный ящик»	низкоуровневая и высокоуровневая разработка	как программисты, так и тестировщики
Системное	«чёрный ящик»	этап анализа требований	тестировщики
Приемочное	«чёрный ящик»	этап анализа требований	клиенты
Функциональное	«серый ящик» «чёрный ящик»	высокоуровневая разработка	тестировщики
Регрессионное	«белый ящик» «серый ящик» «чёрный ящик»	высокоуровневая разработка	как программисты, так и тестировщики
Альфа	«белый ящик»	низкоуровневая разработка	программисты
Бета	«чёрный ящик»	высокоуровневая разработка	как программисты, так и тестировщики

Интеграционное тестирование подтверждает, что две или более интеграции работают вместе должным образом, и склоняется к тому, чтобы сосредоточиться на интерфейсах, указанных в низкоуровневом дизайне, поэтому возможны три подхода проведения тестирования. Системное тестирование показывает, что система работает непрерывно в производственном месте, чтобы обеспечить бизнес-функции, указанные в проекте верхнего уровня. Для данного вида тестирования применяется метод черного ящика. Приемочное тестирование проводится владельцами бизнеса, цель приемочного тестирования - проверить, действительно ли система соответствует их бизнес-требованиям, поэтому здесь не нужно лезть во внутренний код. Регрессионное тестирование - это тестирование ПО после внесения изменений. Данное тестирование проводится для того, чтобы убедиться в надежности каждого выпуска программного обеспечения, протестировав разрабатываемый продукт после внесения каких-либо изменений, чтобы гарантировать, что изменения не привели к появлению каких-либо новых ошибок в приложении. Как правило, для данного вида тестирования применяется метод черного ящика, но и не исключается применение метода серого ящика в некоторых случаях. Реже применяется метод белого ящика. Альфа-тестирование обычно проводится разработчиками, тут очевидно необходимо тестировать код программы.Бета-тестирование проводится на стороне клиента, поэтому используется подход черного ящика. Функциональное тестирование проводится для готового приложения; это тестирование должно проверить, что оно обеспечивает все поведения, требуемые от него, поэтому также используется метод черного ящика, но и не исключается доступ к внутренней структуре ПО [29].

1.6.3 Метод «чёрного ящика»

Тестирование черного ящика - это тестирование, основанное на спецификациях требований, и нет необходимости проверять код в тестировании черного ящика. Это сделано исключительно с точки зрения клиентов, только тестировщик знает набор входных данных и предсказуемые выходные данные. Тестирование черного ящика проводится на полностью готовом продукте [30].

Тестирование «чёрного ящика» играет важную роль в тестировании программного обеспечения, оно помогает в общей проверке функциональности разрабатываемой системы или приложения. Тестирование по методу чёрного ящика проводится на основе требований клиентов, поэтому любые неполные или непредсказуемые требования могут быть легко идентифицированы и могут быть рассмотрены позже. Процесс тестирование «чёрного ящика» проводится на основе точки зрения конечного пользователя. Основная важность данного метода заключается в том, что он обрабатывает как действительные, так и недействительные входные данные с точки зрения клиента.

Тестирование «чёрного ящика» выполняется с начала жизненного цикла программного продукта. Следует отметить, что все члены команды тестирования должны быть вовлечены с самого начала проекта. Во время тестирования данным методом необходимо участие тестировщиков на этапе сбора и анализа требований клиентов. На этапе проектирования необходимо подготовить тестовые данные и тестовые сценарии [30].

Основным преимуществом тестирования методом чёрного ящика является то, что тестировщикам не нужно иметь знания по конкретному языку программирования, но они должны знать этапы реализации разрабатываемого продукта. В тестировании данным подходом программисты и тестировщики независимы друг от друга. Ещё одним преимуществом является то, что тестирование проводится с точки зрения пользователя. Существенным преимуществом тестирования черного ящика является то, что оно помогает выявить любые неясности или несоответствия в спецификациях требований.

...