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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

Рисунок 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].

---