Преподаватель который помогает студентам и школьникам в учёбе.

Функциональное тестирование ПО на примере мобильных приложений

Содержание:

Введение

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

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

В области конструирования, обеспечения и контроля качества программного обеспечения (ПО) можно выделить труды таких известных ученых, как: В.Н. Агафонова, А.П. Ершова, С.С. Лаврова, В.В. Липаева, В.А. Непомнящего, Р. Андерсона, Б. Боэма, Э. Дейкстры, Г. Майерса, Р. Флойда, Ч. Хоара.

В работах этих авторов описываются различные подходы и методы к контролю качества и оценке надежности ПО.

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

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

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

Для достижения поставленной цели планируется решить следующие задачи:

- анализ методов функционального тестирования;

оценка методов функционального тестирования для Web- приложений;
сравнительный анализ инструментов автоматизированного тестирования Web-приложений;
разработка методов и функциональных тестов для автоматизации тестирования Wев-приложения;
оценка эффективности разработанных средств.

Объектом исследования курсовой работы является методы тестирования программных средств.

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

1. Комплексная модель обеспечения качества программного обеспечения

1.1 Модель обеспечения качества программного обеспечения

Выделяют два основных подхода [1,2] обеспечения качества программных продуктов (рисунок 1):

использование стандартов и принятых отраслевых регламентов в процессах жизненного цикла программных средств (ЖЦ ПС), позволяющих гарантировать высокое качество создаваемых программ;
использование методов контроля качества, позволяющих выявить дефекты и ошибки разрабатываемого ПО.

Рисунок 1 - Комплексная модель обеспечения качества ПС

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

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

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

1.2 Дисциплина тестирования

К основным подходам контроля качества ПО относятся [8]:

процедуры ручного контроля;
аналитическая верификация (широко применяются методы Флойда и Хоара);
тестирование.

Аналитическая верификация основывается на следующем определении: «Программа S обладает свойством {P}S{Q}, где P и Q - некоторые утверждения о значениях переменных, используемых в программе, если каждому комплекту начальных значений переменных, относительно которых справедливо P, отвечают после завершения программы S такие значения переменных, относительно которых справедливо Q».

Иногда P называют предусловием (предутверждением), Q - постусловием (постутверждением), а пару P и Q - спецификацией программы S. Программу называют корректной относительно спецификации, если она обладает свойством {P}S{Q}. Более точно, имеется в виду частичная корректность программы, поскольку свойство завершимости программы здесь предполагается и должно доказываться отдельно. Запись {P}S{Q} называют также тройкой Хоара [22].

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

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

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

Пара называется тестовым случаем (тест- кейс), а все тестовые случаи, сгруппированные по определенному признаку, именуются тестовым комплектом.

Решение о наличии ошибки в ПО принимается либо при несовпадении результатов на одном из тестовых случаев:

либо, если отличаются законы распределения выходных данных (рисунок 2).

В обоих случаях считается, что тестирование прошло успешно, поскольку выявлена как минимум одна ошибка.

Рисунок 2 - Графики зависимостей результирующих и эталонных выходных данных от входного комплекта

Существует достаточно много способов классификации тестирования (рисунок 3). Рассмотрим некоторые из них [11].

Классификация по принципам работы с приложением

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

Негативное тестирование (negative testing) предусматривает отработку тех сценариев, которые могут произойти с системой, если, пользователь допустит ошибку при вводе данных. В данном случае, система должна ответить на запрос пользователя сообщением об ошибке. Хотя негативных тест-кейсов гораздо больше, чем позитивных, негативные не стоит объединять, т.к. подобное решение может привести к неверной трактовке поведения приложения и пропуску дефектов [11].

Рисунок 3 - Классификация тестирования

Классификация по природе приложения

Тестирование настольных приложений (desktop applications testing) является классическим примером тестирования, особенности этого вида тестирования зависят от предметной области приложения, аспектов архитектуры, главных характеристик свойства и т.д. [11]

Данную классификацию можно отдельно рассматривать как тестирование консольных приложений (console applications testing) и приложений с графическим интерфейсом (GUI-applications testing), серверных приложений (server applications testing) и клиентских приложений (client applications testing) и других.

Тестирование мобильных приложений (mobile applications testing) требует повышенного внимания к тестированию сопоставимости, оптимизации производительности, автоматизации тестирования с использованием эмуляторов мобильных устройств.

Тестирование веб-приложений (web-applications testing) необходимо для контроля сопоставимости (в особенности кроссбраузерности и кроссплатформенности тестирования), стресс тестирования, тестирования производительности, автоматизации тестирования с внедрением широкого диапазона инструментальных средств.

Классификация по фокусировке на уровне архитектуры приложения

Предоставленная классифицирование отображает сосредоточивание интереса на тестировании отдельной части приложения [11].

Тестирование уровня представления (presentation tier testing) больше уделен интерес той части приложения, которая отвечает за взаимодействие с «внешним миром» (как пользователями, так и другими приложениями). Здесь исследуются вопросы скорости отклика интерфейса, сопоставимости с браузерами, удобства применения, корректности работы интерфейсов.

Тестирование уровня бизнес-логики (business logic tier testing) отвечает за испытание основного набора функций и основывается на базе основных требований к приложению, а еще бизнес-требований и общей проверки функциональности.

Тестирование уровня данных (data tier testing) внимание уделено той части приложения, которая дает ответ за обработку и сохранение неких данных (чаще всего - в базе данных или каком-либо облачном хранилище). Здесь главный интерес заключается в тестирование данных, качественная проверка соблюдения бизнес-правил, тестирование производительности.

Классификация по степени формализации

Тестирование на основе тест-кейсов (scripted testing, test case based testing) - это формализованный подход, тестирование производится с помощью заблаговременно подготовленных тест-кейсов или тестовых планов, а также другой документации. Самый распространенный метод тестирования, с поддержкой которого достигается наибольшая полнота тестирования приложения за счет серьезной систематизации процесса, внедрения метрик и широкого комплекта выработанных и проверенных на практике советов [11].

Исследовательское тестирование (exploratory testing) - отчасти формализованный подход, в рамках которого тестировщик исполняет работу с приложением сообразно выбранному сценарию, который, в свою очередность, дорабатывается в процессе исполнения с целью наиболее совершенного изучения приложения. основным фактором успеха при выполнении исследовательского тестирования является именно работа по определенному сценарию, а не исполнение разрозненных бездумных операций. Есть даже специальный сценарный подход, называемый сессионным тестированием (session-based testing). В качестве альтернативного сценария при выборе действий с приложением время от времени могут использоваться чек- листы, и тогда этот вид тестирования именуют тестированием на основе чек- листов (checklist-based testing) [11].

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

Классификация по техникам автоматизации

Тестирование под управлением данными (data-driven testing) - метод разработки автоматизированных тест-кейсов, в котором входные данные и ожидаемые итоги выносятся за пределы тест-кейса и хранятся за пределами (в файле или в базе данных, а так же в облачных хранилищах).

Тестирование под управлением ключевыми словами (keyword-driven testing) - метод разработки автоматизированных тест-кейсов, в котором за пределы тест-кейса выносится не только комплект входных данных и ожидаемых результатов, но и логика поведения тест-кейса, которая описывается ключевыми словами (командами).

Тестирование под управлением поведением (behavior driven test-ing) - способ разработки автоматизированных тест-кейсов, в котором основной интерес уделяется корректности работы бизнес-сценариев, а не единичными деталям функционирования приложения.

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

Емкость тестовых комплектов определяется в соответствии с выбранными аспектами тестирования.

Анализ выбора метода тестирования

Интенсивность обнаружения ошибок на единицу затрат и надежность тесно связаны со временем тестирования и, поэтому, с гарантией качества продукта (рисунок 4, блок А). Чем больше мы затрачиваем времени в процессе тестирования, тем меньше остается в продукте критичных ошибок. Однако, как известно полное тестирование не достижимо, поэтому трудозатраты, связанные с получением программного продукта, а также с избытком качества, которое не востребовано заказчиком приложения, должны иметь пределы. Определение момента завершения тестирования - очень ответственная задача тестировщика и менеджера проекта [10, 12].

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

На практике известны последующие способы тестирования, упорядоченные по связанным с их применением затратам:

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

Зависимость эффективности внедрения перечисленных способов или их возможности к обнаружению соответственных классов ошибок (рисунок 4, блок С) сопоставлена на рисунке 4, блок В [20] с затратами. График указывает, что со временем, по мере обнаружения наиболее серьезных ошибок и недостатков, эффективность низкозатратных методов падает вместе с количеством обнаруживаемых ошибок.

$C:\Users\1\AppData\Local\Temp\FineReader11.00\media\image4.jpeg$

Рисунок 4 - Анализ эффективности критериев тестирования в процессе создания программного продукта.

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

Функциональное тестирование

Классифицирование главных критериев формирования тестовых комплектов тестирования [13] приведена на рисунке 5.

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

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

Рисунок 5 - Классификация критериев тестирования

К более известным критериям функционального тестирования относятся критерии тестирования функций и тестирования спецификаций.

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

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

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

Тестирование классов эквивалентности - одна из методик определения «оптимального» тестового комплекта. Она заключается в разбиении входной области определения и выходной области значений на конечное число классов эквивалентности. Если один тестовый случай данного класса эквивалентности обнаруживает ошибку, то и все другие тестовые случаи этого же класса эквивалентности также будут обнаруживать ту же самую ошибку. И наоборот, если тестовый случай данного класса эквивалентности не обнаруживает ошибку, то остальные тестовые случаи данного класса также не будут обнаруживать данную ошибку. Различают два типа классов эквивалентности: правильные классы эквивалентности, включающие корректные (правильные) данные и неправильные классы эквивалентности, охватывающие ошибочные данные.

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

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

Метод диаграмм причинно-следственных связей (метод функциональных диаграмм) позволяет формировать репрезентативные комплекты тестовых данных и исполнять систематическую генерацию высоко результативных тестов. Построение тестов методом причинно-следственных связей происходит в несколько этапов:

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

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

Рисунок 6 - Пример булевого графа тестирования

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

Тестовые метрики

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

покрытие функциональных требований;
покрытие большего количества сценариев;
покрытие кода продукта (конструктивно для модульного тестирования);
соотношение количества найденных дефектов с количеством тестов на данную функцию продукта;
количество или плотность найденных дефектов;
количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов.

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

Сильное несоответствие количества найденных дефектов с количеством тестов на данную функцию продукта показывает о неэффективности тестов (когда огромное количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено огромное количество дефектов на не очень большом количестве тестов).

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

1.4 Автоматизация тестирования

Автоматизация тестирования прежде всего нужна для повторного применения тестов. Рассмотрим жизненный цикл теста (рисунок 7) и определим условия повторяемости тестов.

Рисунок 7 - Жизненный цикл теста

К изменению существующих тестов могут привести три следующих вида деятельности программистов: создание новых тестов, выполнение тестов, изменение кода.

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

Уровень 1. Тест не допускает повторного использования. Требуется создание нового набора тестов (например, путем удаления или изменения этого теста).

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

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

Уровень 4. Наивысший уровень повторного использования теста предусматривает повторное использование входных данных, выходных данных и траектории теста. В том случае, если на траектории теста не изменяется ни один оператор, в повторном запуске этих тестов необходимости нет, так как выходные данные и траектория останутся неизменными [11].

Преимущества и недостатки автоматизированного тестирования

Преимущества автоматизации тестирования [14]:

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

Недостатки автоматизации тестирования:

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

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

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

базовые операции создания/чтения/изменения/удаления сущностей (например: создание, удаление, просмотр и изменение данных о пользователе);
типовые сценарии использования приложения, либо отдельные действия (пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта, все это end- to-end сценарий, который проверяет совокупность действий);
интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную (пример: система создает некоторый xml файл, структуру которого необходимо проверить).

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

Категории автоматизации тестирования web-приложений

Для тестирования web-приложения рекомендуется последовательно разрабатывать отдельные тест-комплекты (test case) следующих категорий.

Функциональные CRUD-тесты (Create, Read, Update, Delete) [9] необходимы для тестирования интерфейса стандартных операций по созданию, чтению, изменению, удалению элементов web-формы, добавляются

в соответствующие Unit-тесты. Обязательные действия в данной категории:

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

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

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

- добавить проверки успешного обновления данных.

Функциональные позитивные тесты необходимы для проверки

корректности завершения разрешенных (валидных) операций, входящих в CRUD-тесты (например, проверка того, что после сохранения корректно введенной информации выводится сообщение об успехе операции), добавляются в соответствующие Init-тесты. Обязательные действия в данной категории:

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

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

- добавить проверки наличия сообщений об успехе операций CRUD.

Функциональные негативные тесты необходимы для проверки корректной обработки неправильно введенных данных (например, проверка того, что при попытке ввода в текстовое поле слишком длинной строки выводится сообщение об ошибке), добавляются в соответствующие Init-тесты. Обязательные действия в данной категории:

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

- добавить проверки наличия сообщений о некорректных действиях пользователя или неверных исходных данных.

Выводы

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

Для тестирования web-приложения рекомендуется последовательно разрабатывать отдельные тест-комплекты (test case) следующих категорий: функциональные CRUD-тесты, функциональные позитивные тесты и функциональные негативные тесты.

2. Алгоритмы разработки тестов

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

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

Для анализа предметной области разработаем онтологическую модель.

2.1 Алгоритмы функционального тестирования

Метод функциональных диаграмм

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

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

Рисунок 8 - Базовые логические отношения функциональных диаграмм

Базовые символы для записи функциональных диаграмм показаны на рисунке 8.

Каждый узел диаграммы может находиться в двух состояниях: 0 или 1; 0 - означает состояние «отсутствует», а 1 - «присутствует».

Ортогональные массивы

При разработке тестов часто приходится анализировать работу системы с большим числом параметров (например, работа сайта в различных браузерах). Например, для проверки всех сочетаний 10 параметров с 10 значениями каждый, потребуется 10,000,000,000 тестов. Перебрать все сочетания параметров нетрудно. Трудность состоит в том, чтобы обеспечить при этом минимум тестов. Одним из подходов оптимизации количества тестов является использование ортогональных массивов.

Ортогональный массив [20] - это таблица L_m(kⁿ), где m - число строк, n - число столбцов, которое соответствует числу входных параметров, k - количество вариантов значений элементов таблицы, и обладающая следующими свойствами:

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

В ортогональных массивах необязательно все столбцы должны иметь одинаковое количество значений. Существуют так называемые смешанные (mixed) ортогональные массивы. Например: L₄(2³) - ортогональный массив с четырьмя строками, тремя столбцами (по количеству переменных), 2 означает, что все переменные принимают только два значения - 1 и 2. L₁₈(2¹ 3⁷) - смешанный ортогональный массив с восемнадцатью строками, у которого один столбец со значениями 1 и 2, и семь столбцов со значениями 1, 2, 3.

Для тестирования с использованием ортогональных массивов следует выполнить следующие шаги:

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

Например, матрица, в столбцах которой может быть значение 1 или 2, содержит все возможные комбинации трех цифр (рисунок 9):

Рисунок 9 - Исходная матрица

Ортогональный массив, полученный по исходной матрице следующий (рисунок 10).

Рисунок 10 - Ортогональный массив

В математике, для ортогонального массива, чьи записи состоят из фиксированного конечного набора символов (как правило, {1,2,...,n}), существует целое число T такое, что для каждого множества из T столбцов таблицы, все возможные Т-кортежи из исходных символов, образованные записью в каждой строке символов этих столбцов, появляются одинаковое количество раз. Число T называется силой ортогональности. Для рассмотренного примера (рисунки 9. 10) ортогональный массив с множеством символов {1,2} имеет силу - 2. При этом четыре упорядоченные пары, образованны первой и третьей колонках, а именно (1,1), (2,1), (1,2) и (2,2), порождают все возможные упорядоченные пары из двух элементов набора, и каждый появляется ровно один раз. Второй и третий столбцы дают: (1,1), (2,1), (2,2) и (1 ,2). И в этом случае также появляются все возможные упорядоченные пары. Аналогично можно получить все возможные упорядоченные пары, рассматривая первый и второй столбцы.

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

Таблица 1 - Пример параметров теста

#	Параметр 1	Параметр 2	Параметр 3
1	Значение 1.1	Значение 2.1	Значение 3.1
2	Значение 1.2	Значение 2.2	Значение 3.2

Формируем таблицу возможных сочетаний параметров (таблица 2). Переберем значения первого параметра со вторым (строки №1 - 4), первого с третьим (строки №5 - 8) и второго с третьим (строки №9 - 12).

Таблица 2 - Сочетание тестовых параметров

Удалив повторяющиеся наборы параметров (выделены серым), получим следующую таблицу тестов (таблица 3).

Таблица 3 - Оптимизированная таблица

Продолжение таблицы 3

Серым выделены уникальные пары всех параметров в таблице. Заметим, что значения выделенные белым не являются необходимыми для перебора всех пар в таблице, поэтому могут быть заменены на любое другое значение. Поэтому можно оптимизировать тесты, заменив их на пары таблицы 2 из строк 5 (Значение 1.1, Значение 1.2), 6 (Значение 1.2, Значение 3.2) и 7 (Значение 2.2, Значение 3.2). В результате получим таблицу 4.

Таблица 4 - Результирующие тесты

Ортогональные массивы обобщают табличное представление о взаимно ортогональных латинских квадратах.

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

На протяжении многих лет, был разработан целый ряд комбинаторных стратегий для того, чтобы помочь тестировщикам выбрать такое подмножества входных комбинаций, которое позволило бы максимально увеличить вероятность выявления дефектов: выборочное тестирование, «каждый-выбор» (each-choice) и «основание выбора» (base choice), антирандомизация (antirandom), стратегия тестирование t-способами (/-wise testing strategies) и другие. Парное тестирование (pairwise testing) [23] является наиболее видным среди них. На рисунке 11 показана зависимость увеличения числа исчерпывающих и парных тестов от количества тестовых уровней (возможного количества значений параметров).

$C:\Users\1\AppData\Local\Temp\FineReader11.00\media\image8.jpeg$

Рисунок 11 - Зависимость увеличения числа исчерпывающих и парных тестов от количества тестовых уровней

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

Формально стратегия парного тестирования определяется следующим образом: дан набор из N независимых испытаний факторов f₁,f₂,…,f_N, где каждый фактор f_i имеет L_j возможных уровней f_i = {l_i,₁,…,l_i, L_i}., и набор тестов R. Каждый тест в R содержит N тест-уровней, по одному для каждого тест- фактора f_i , и, в совокупности, все тесты в R охватывают все возможные пары уровней тест-факторов (относящихся к разным параметрам). Другими словами, для каждой пары уровней факторов l_i,_p и l_j,_q, где - существует по крайней мере один тест в R, который содержит l_j,_p и l_j,_q.

All-Pairs Algorithm (алгоритм всех пар) - это комбинаторная методика, которая была специально создана для парного тестирования. В ее основе лежит выбор возможных комбинаций значений всех переменных, в которых содержатся все возможные значения для каждой пары переменных. Исходя из определения, число комбинаций будет меньшее, чем при использовании ортогональных массивов.

Для тестирования с использованием All-Pairs алгоритма выполняют следующие шаги:

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

Рассмотрим пример формирования тестов в технике парного тестирования. Интерфейс пользователя приложения содержит список с 10 элементами (скажем, 0,1,2,3,4,5,6,7,8,9) вместе с флажком, радио-кнопкой, текстовым полем и кнопкой «ОК». Текстовое поле может принимать значения только в диапазоне от 1 до 100. Ниже приведены значения, что каждый из объектов GUI может принимать:

Список Box - 0,1,2,3,4,5,6,7,8,9

Check Box - зарегистрированный или незарегистрированный

Radio Button - ON или OFF

Text Box - любое значение от 1 до 100

Исчерпывающее количество тестов для приложения вычисляется следующий образом:

List Box = 10;

Check Box = 2;

Radio Button = 2;

Text Box = 100;

Общее число тестов: 10*2*2*100 = 4000

Общее число негативных тестов > 4000.

Теперь, идея разработки тестов заключается в том, чтобы уменьшить количество тестов. Сначала выясним число случаев с использованием обычного метода тестирования программного обеспечения. Мы можем рассматривать значения List Box как 0 и другие. Число значений радио-кнопки и Check Box не могут быть уменьшены, так что каждый из них будет иметь 2 комбинации (включен или выключен). Значения текстовое поле может быть уменьшено до трех: допустимое целое число, недопустимое целое (Invalid Integer), альфа - специальный символ.

Таким образом, число случаев с использованием программного обеспечения в методике тестирования составит: 2 * 2 * 2 * 3 = 24 (в том числе негативных случаев).

Далее уменьшим количество сочетаний значений параметров в технике All-pairs.

- шаг 1: Выберем параметры таким образом, что параметр с наибольшим количеством значений был первым и с наименьшим - последим;

- шаг 2: заполняем таблицу по столбцам. List Box может принимать 3 значения;

- шаг 3: в следующей колонке будет Text Box (может принимать 2 значения);

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

- шаг 5: будем использовать ту же стратегию для проверки радио - кнопки и Check Box.

- шаг 6: проверяем, что все значения пар параметров покрыты (таблица 5).

Таблица 5 - Покрытие тестовых значений

Для Pairwise тестирования используются алгоритмы, основанные на построении ортогональных массивов или на All-Pairs алгоритме, которые опираются на теоретические исследования в области комбинаторных алгоритмов, алгоритмов дискретной математики и, в частности, латинских квадратов [20].

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

2.2 Разработка онтологической модели тестового случая

Используем онтологический подход [21] для анализа предметной области разработки тестов. Сначала рассмотрим параметры тестового случая.

Под тестовым случаем (test case) обычно понимается структура вида: Action > Expected Result > Test Result

В таблице 6 показан пример тестового случая.

Таблица 6 - Пример тестового случая

Описание тестового случая может включать следующие части (таблица 7, 8) [17].

Таблица 7 - Описание тестового случая (вариант 1)

Таблица 8 - Описание тестового случая (вариант 2)

Описания параметров тестовых случаев необходимы для формирования отчетов, содержащих информацию об обнаруженных проблемах.

Более простая модель онтологии (без словаря и без определения типа отношений) приведена ниже. Под онтологией в этой работе понимается упорядоченная тройка вида [9 - 11]:

О = (C,R,F),

где C - конечное множество концептов (понятий, терминов) предметной области, которую представляет онтология О;

R - конечное множество отношений между концептами заданной предметной области;

F - конечное множество функций интерпретации (аксиоматизации), заданных на концептах и/или отношениях онтологий О.

Естественным ограничением, налагаемым на множество С, является его конечность и не пустота.

Создадим онтологическую модель тестового случая (рисунок 12)

Рисунок 12 - Онтологическая модель тестового случая

Рисунок 13 - Онтологическая модель тестового случая в Protege

Рисунок 14 - Классы онтологической модели тестового случая в Protege

Выводы

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

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

Заключение

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

Рассмотрены регламентирующие документы объектно-ориентированного подхода: стандарт IEC 61499, а также спецификация OPC UA.

В ходе научно-исследовательской работе были решены следующие задачи:

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

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

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

Список использованных источников

Липаев, В.В. Методы обеспечения качества крупномасштабных программных средств. / М.: СИНТЕГ, 2003. 520 с.
Липаев, В.В. Обеспечение качества программных средств Методы и стандарты. Серия "Информационные технологии". - М.: СИНТЕГ, 2001. 380с.
Майерс, Г. Искусство тестирования программ / Пер. с англ.- М.: Финансы и статистика, 1982. - 176 c.
Макгрегор, Д. Сайкс, Д. Тестирование объектно-ориентированного программного обеспечения / Пер. с англ. - К.: ООО “ТИД ДС”, 2002. - 432 с.
Калбертсон, Р и др. Быстрое тестирование / Пер. с англ. - М.: “Вильямс”, 2002. - 384 с.
Канер, С и др. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Пер. с англ. - К.: “ДиаСофт”, 2001. - 544 с.
Котляров, В., Коликова, Т., Некрасов, Н., Епифанов, Н. Технологии программирования. Основы современного тестирования программного обеспечения, разработанного на C# / Учеб.пособие - СПб.: Издательство СПбГПУ, 2004. - 168 c.
Тампре Л. Введение в тестирование программного обеспечения / Пер. с англ. - М.: “Вильямс”, 2003. - 368 с.
Савин Р. Тестирование Дот Ком, или Пособие по жесткому обращению с багами в интернет-стартапах. - М.: Дело, 2007. - 312с http://adm-lib.ru/books/4/testirovanie_dot-com.pdf
Котляров, В., Тренинг Основы тестирования программного обеспечения [Электронный ресурс]. URL: http://www.intuit.ru/studies/courses/48/48/info (дата обращения: 19.05.2017)
Куликов, С., Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015 [Электронный ресурс]. URL: http://svyatoslav.biz/software_testing_book/ (дата обращения: 19.05.2017)
Криспин, Л., Грегори, Д,. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. : Пер. с англ. - М. : ООО “И.Д. Вильямс”, 2010. - 464 с.
Балыков, Е. Тестирование программных средств. Источник: RSDN Magazine #4, 2006
Тестирование и качество ПО. - Режим доступа: [Электронный ресурс]. URL: http://software-testing.ru/ (дата обращения: 19.05.2017)
Кучеренко, Е. Что такое Тест кейс (Test Case)? https://software- testing.org/testing/test-keys-test-case-iz-kakih-poley-sostoit-tipichnyy-test-ys.html http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa- 8dbd- c6f76cc014b/pict33.msi [Электронный ресурс]. URL: (дата обращения: 7.06.2017)
Миронов А. Применение модульного подхода для тестирования Web-приложения. - НИТиС - 2016 - XIII Международная научно техническая конференция "Новые информационные технологии и системы"- Пенза : ПГУ, 2016
Миронов, А. Инструменты для автоматизации тестирования Web- приложений ПАУТС - 2017 XXXII Международная научно техническая конференция "Проблемы автоматизации и управления в технических системах". - Пенза : ПГУ, 2017
Миронов, А Использование функциональных тестов регистрации пользователей / Л.В. Гурьянов, А.В. Миронов // сб. науч. ст. 4-ая Ежегодная межвузовская научно-практическая конференция. - Пенза : ПГУ, 2017
Холл, М. Комбинаторика. - М. : Мир, 1970. - 424 с.
Ной Н. Ф., МакГиннесс Д.Л. Разработка онтологий 101. Руководство по созданию вашей первой онтологии // International Forum of Educational Technology & Society [Электронный ресурс]. URL: http://ifets.ieee.org/russian/depository/ontology101_rus.doc (дата обращения: 19.05.2017).
C. A. R. Hoare. «An axiomatic basis for computer programming». Communications of the ACM, 12(10):576-580,583 October 1969
Black, Rex. Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional. New York: Wiley. 2007 - p. 240.

Приложение А

ГЛОССАРИЙ

(справочное)

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

Класс онтологии - компонент онтологии, описывающий понятие, явление или процесс предметной области.

Онтология - точная спецификация концептуализации предметной области.

ЖЦ ПС - жизненный цикл программных средств.

ПС - программные средства.

ПО - программное обеспечение.

Функциональные CRUD-тесты (Create, Read, Update, Delete) -тесты для тестирования интерфейса стандартных операций по созданию, чтению, изменению, удалению элементов web-формы, добавляются в соответствующие Unit-тесты

Тестовый случай (test case) - структура вида:

Action > Expected Result > Test Result

Метод парного тестирования - основан на довольно простой идее, что подавляющее большинство ошибок выявляется тестом, проверяющим один параметр, либо сочетание двух

All-Pairs Algorithm (алгоритм всех пар) - комбинаторная методика для парного тестирования

Приложение В

ТЕСТЫ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ