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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

---