Файл: Функциональное тестирование программного обеспечения на примере мобильных приложений (Характерные особенности тестирования мобильных приложений).pdf

Недостатки метода:

• Основным недостатком метода «черного ящика» является возможность пропуска границ и переходов, которые не очевидны из спецификации, но есть в реализации кода (собственно, это и заставляет тестировщиков использовать метод «белого ящика»)^[31]. Вспоминается случай, когда система получала котировки валют с биржи Forex и округляла до 3 знаков после запятой. Система успешно прошла тестирование методом «черного ящика» (так как ни одна валюта не выходила за соответствующие границы) и хорошо работала до тех пор, пока курс доллара к биткоин не вышел за границы 1000 долларов. Тестирование «белым ящиком» выявило бы ошибку: специалист увидел бы, что коэффициент конверсии валюты ограничен 3 знаками.
• Можно протестировать только небольшое количество возможных вводных (входящих) значений; многие варианты остаются без проверки.
• Тесты могут быть избыточными, если разработчик уже проверил данную функциональность (например, Unit-тестом)^[32].
• При отсутствии четкой и полной спецификации проектировать тесты и тест-сценарии оказывается затруднительно.

В стратегии White Box (белый ящик) тестирования рассматривается внутренняя логика и структура кода. Его также называют стеклянным, структурным, открытым или прозрачным ящиком тестирования. Тесты, написанные на основе стратегии White Box тестирования включают покрытие написанного кода, ответвлений, путей, отчетности, внутренней логики кода и др.^[33] В целях реализации метода тестирования белого ящика, тестировщик имеет дело с кодом, и, следовательно, ему необходимо владеть знаниями кодирования и логики то есть, внутренней работы кода. White Box тест также нужен в тестировщике, который взглянув на код может выяснить, какой блок/кусок кода работает неправильно. Крайне важно, чтобы тестер имел «структурные» знания о том, как система была внедрена. Не только код, но даже поток данных и поток управления должны быть оценены.

Участками кода, которые тестируются с помощью White Box тестирования являются^[34]:

• Покрытие кода,
• Строковое покрытие,
• Покрытие решений,
• Покрытие условий,
• Циклы,
• Пути,
• Покрытие потока данных.

Существует три аспекта кодекса, которые проверяются в White Box тестировании, а именно^[35]:

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

---

Преимущества White Box тестирования^[36]:

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

Недостатки White Box тестирования^[37]:

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

К видам испытаний White/Glass Box тестирования относится^[38]:

• Модульное тестирование. Разработчик выполняет модульное тестирование, чтобы проверить, правильно ли работает конкретный модуль или блок кода. Модульное тестирование происходит на самом базовом уровне и осуществляется при разработке конкретного модуля или при встраивании определенной функции.
• Статический и динамический анализ. Статический анализ состоит в просмотре кода, чтобы выяснить любые возможные дефекты в коде, динамический анализ предполагает выполнение кода и анализ выходных данных.
• Строковое покрытие. В этом типе тестирования, код выполняется таким образом, что каждая строка приложения выполняется как минимум 1 раз. Это помогает в обеспечении, того что все инструкции выполняются без каких-либо побочных эффектов. Различные средства управления покрытиями используются, чтобы оценить процент исполняемых элементов, которые в настоящее время были протестированы^[39].
• Покрытие решений. Ни одно приложение не может быть написано в непрерывном режиме кодирования. В какой-то момент мы должны разветвить код для того, чтобы выполнить ту или иную функциональность. Тестирование покрытия решений помогает в проверке всех ветвей в коде, и помогает убедиться, что ветвление не приводит к непредсказуемому поведению приложения.
• Тестирование утечки памяти. Когда код написан, есть вероятность, что в коде существует проблема утечки памяти, которая делает код неисправным. Поэтому, во время тестирования по методу белого ящика проверяется есть ли в коде утечка памяти. В случае утечки памяти, для программного обеспечения требуется больше памяти, и это влияет на скорость работы программного обеспечения, что делает его медленным^[40].
• Тестирование безопасности. Тестирование безопасности проводится для того, чтобы выяснить, насколько хорошо система может защитить себя от несанкционированного доступа, взлома (крекинг, любое повреждение кода и т.д.) которая имеет дело с кодом приложения. Этот тип тестирования требует сложных методов тестирования^[41].
• Мутационное тестирование - это своего рода тестирование, в котором, приложение тестируется на код, который был изменен после фиксации определенного бага/дефекта. Оно также помогает выяснить, какой код и какая стратегия кодирования может помочь в разработке эффективной функциональности^[42].

---

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

Этапы и уровни функционального тестирования

Функциональное тестирование представляет собой часть процесса проверки соответствия поведения системы первоначально заявленным функциональным требованиям^[43]. Цель проведения функционального тестирования – подтвердить, что система реализована в соответствии с предъявленными к ней функциональными требованиями и полностью готова к работе.

Функциональное тестирование — это тестирование программного обеспечения в целях проверки реализуемости функциональных требований, то есть способности программы в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО и какие задачи оно решает^[44].

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

Для проведения функционального тестирования разрабатывается специальный документ – программа и методика испытаний функционала приложения (ПМИ). ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Шаги сценария описывают все возможные действия пользователя и ожидаемый результат – ответной реакции программы на эти действия^[46]. Программа и методика испытаний имитирует эксплуатацию прикладной программы, мобильного или облачного приложения в реальном режиме. Сценарии тестирования строятся на основе анализа операций, которые могут выполнять будущие пользователи программного продукта или системы^[47].

---

Для проведения функционального тестирования персоналом отдела технического контроля разрабатывается документ программа и методика испытаний функционала приложения (ПМИ). Документ ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Каждый шаг сценария тестирования характеризуется действиями пользователя (специалиста по тестированию) и ожидаемыми результатами – ответной реакции программы на эти действия^[48]. Программа и методика испытаний обязана имитировать эксплуатацию программного продукта в реальном режиме. Это означает, что сценарий тестирования должен быть построен на основе анализа операций, которые будут выполнять будущие пользователи системы, а не быть искусственно составленной последовательностью понятных только разработчику манипуляций.

Обычно, функциональное тестирование проводится на двух уровнях:

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

Также функциональное тестирование достаточно часто попадает под разделения понятий (По признакам позитивности сценариев)^[49]:

• Позитивное функциональное тестирование,
• Негативное Функциональное тестирование.

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

Среди основных этапов функционального тестирования следует выделить следующие:

• ПМИ – разработка программы и методики испытаний функционала приложения (ПМИ). ПМИ содержит перечень сценариев тестирования на основе документов об объекте тестирования: функциональные и бизнес-требования, техническое задание и проектный паспорт^[51].
• Тесты – обычно функциональное тестирование ПО осуществляется вручную, исходя из разработанных заранее тестовых скриптов, которые заносят все найденные ошибки в систему баг-трекинга.
• Отчет – в ходе этого этапа наши специалисты разрабатывают и согласовывают отчеты о проведенном тестировании со всеми обнаруженными дефектами и рекомендациями по оптимизации системы.

---

Для функционального тестирования, как правило, используются такие инструменты как TeamCity, Selenium, Web Driver, Firebug, XPather, IE Developer Toolbar, JUnit, JMeter, VMWare, TestLink и др., а также багтрэкинговые системы Bugzilla, Mantis, Jira, XBtrack^[52].

Методики функционального тестирования^[53]:

• Проверка функциональности (метод «черного ящика») — проверка соответствия программного обеспечения требованиям спецификации. Проводиться полное тестирование или проверяется только базовая функциональность;
• Регрессионное тестирование (regression testing) — тестирование функциональности продукта после исправления ошибок или реализации новых функциональных возможностей;
• Тестирование интерфейса — проверка работоспособности элементов интерфейса и проверка функциональности форм и последовательностей процессов^[54];
• Проверка функциональности (метод «черного ящика») — проверка соответствия программного обеспечения требованиям спецификации. Проводиться полное тестирование или проверяется только базовая функциональность;
• Регрессионное тестирование (regression testing) — тестирование функциональности продукта после исправления ошибок или реализации новых функциональных возможностей;
• Тестирование интерфейса — проверка работоспособности элементов интерфейса и проверка функциональности форм и последовательностей процессов.

К недостаткам функционального тестирования можно отнести следующие факторы^[55]:

• велика вероятность при проверке функциональности упустить различные логические ошибки в ПО;

• вероятность избыточного тестирования.

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

Избыточность тестирования особенно актуальна на ранних этапах тестирования, избежать ее можно — строгими требованиями, профессионализмом, четкой постановкой задач^[56].

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

---