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

К основным техникам тестирования методом «черного ящика» относится^[22]:

• Эквивалентное разбиение. Данная техника включает в себя разделение входных значений на допустимые и недопустимые разделы и выбор репрезентативных значений из каждого раздела в качестве тестовых данных. Она может быть использована для уменьшения количества тестовых случаев. Допустим, у нас есть целая переменная N в диапазоне от -99 до 99: позитивными классами эквивалентности будут [-99, -10], [-9, -1], 0, [1, 9], [10, 99], а недействительными (негативными) – <-99, >99, пустое значение, нечисловые строки.
• Анализ граничных значений. Техника, которая включает в себя определение границ входных значений и выбор в качестве тестовых данных значений, находящихся на границах, внутри и вне границ. Многие системы имеют тенденцию вести себя некорректно при граничных значениях, поэтому оценка значений границ приложения очень важна. При проверке мы берем следующие величины: минимум, (минимум-1), максимум, (максимум+1), стандартные значения^[23]. Например, в том же случае -99 <= N <= 99 будет использоваться набор: -100, -99, -98, -10, -9 -1, 0, 1, 9, 10, 98, 99, 100.
• Тестирование таблицы переходов. При данной технике сценарии тестирования выбираются на основе выполнения корректных и некорректных переходов состояний^[24]. Допустим, мы хотим записаться на прием к врачу и зарезервировать время своего приема: заходим в форму, выбираем удобное для нас время и нажимаем кнопку «Записаться». Сразу после этого выбранное нами время становится недоступно для другой записи, так как первая запись привела к изменению в базе.
• Тестирование по сценариям использования. Эта техника используется при написании тестов для индивидуального сценария пользователя с целью проверки его работы^[25].

Достоинства метода «черного ящика»^[26]:

• Тестирование методом «черного ящика» позволяет найти ошибки, которые невозможно обнаружить методом «белого ящика». Простейший пример: разработчик забыл добавить какую-то функциональность. С точки зрения кода все работает идеально, но с точки зрения спецификации это – сверхкритичный баг^[27].
• «Черный ящик» позволяет быстро выявить ошибки в функциональных спецификациях (в них описаны не только входные значения, но и то, что мы должны в итоге получить). Если полученный при тестировании результат отличается от заявленного в спецификации, то у нас появляется повод для общения с аналитиком для уточнения конечного результата^[28].
• Тестировщику не нужна дополнительная квалификация. Часто мы пользуемся различными сервисами и приложениями, не очень в них разбираясь. Для того, чтобы открыть инстаграм и обработать свою фотографию, нам совсем не нужно знать способ реализации фильтров. Мы хотим открыть фотографию, выбрать фильтр и получить красивую картинку на выходе. Задача тестировщика, который тестирует эту функцию в инстаграм, – убедиться, что пользователь получит эту самую красивую картинку в соответствии с выбранным фильтром. При этом нам совсем не обязательно иметь какую-либо специализацию – нужны лишь телефон и инстаграм^[29].
• Тестирование проходит «с позиции пользователя». Пользователь всегда прав, он конечный потребитель практически любого ПО, а значит, ему должно быть удобно, комфортно и понятно.
• Составлять тест-кейсы можно сразу после подготовки спецификации. Это значительно сокращает время на тестирование: к тому моменту, как продукт готов к тестированию, тест-кейсы уже разработаны, и тестировщик может сразу приступать к проверке^[30].

---

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

• Основным недостатком метода «черного ящика» является возможность пропуска границ и переходов, которые не очевидны из спецификации, но есть в реализации кода (собственно, это и заставляет тестировщиков использовать метод «белого ящика»)^[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 трудно классифицировать их в любой из этих двух широких типов тестирования программного обеспечения.

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---