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

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

Содержание:

Введение

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

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

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

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

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

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

Для достижения поставленной цели необходимо решить ряд задач:

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

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

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

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

Глава 1. Сущность и основные принципы функционального тестирования программного обеспечения

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

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

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

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

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

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

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

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

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

Соблюдение отраслевых стандартов – это не то, чем вы можете пренебречь или заняться позже; это неотъемлемая часть процесса разработки встроенного программного обеспечения (ПО). Для некоторых индустрий, — таких как авионика, автомобилестроение и здравоохранение, — строгое следование стандартам качества при разработке сложных и безотказных встроенных систем становится жизненно необходимым условием выпуска продукта на рынок^[7]. Традиционно, тестирование играет важную роль в разработке встраиваемых систем для регулируемых стандартами отраслей. Однако за последние годы устоявшиеся практики и процессы тестирования, их место и роль в подобных проектах значительно преобразились. Это резко изменило все правила игры, а когда правила игры меняются, необходимо меняться вместе с ними, чтобы выиграть^[8].

В условиях постоянного развития новых, ультрасовременных технологий компаниям необходимо быстро предлагать рынку надежные, безопасные, простые в использовании и совместимые с другими системами продукты – просто чтобы не потеряться в быстро меняющемся технологическом мире. В такой ситуации традиционная каскадная модель, где процесс разработки ПО строго последователен и тестирование выполняется в самом его конце, уходит в прошлое. Большую популярность приобретают методы DevOps и Agile, поскольку они позволяют инженерам выполнять задачи, которые раньше следовали друг за другом, одновременно^[9].

Исследование, проведенное Ауригой при поддержке независимой исследовательской компании LTM Research, показывает, что эта эволюция роли тестирования в цикле разработки ПО имеет огромное значение. При постоянном дефиците времени производители по-прежнему не могут пожертвовать качеством, надежностью и безопасностью своего продукта. К примеру, широко обсуждаемые сегодня беспилотные автомобили являются источником повышенной опасности, а значит, требуют неукоснительного соблюдения стандартов^[10]. Нельзя обойтись и без тестирования встроенного ПО, поскольку практически все решения в области IoT и Connectivity основаны на встроенных технологиях.

Все отрасли стремятся к инновациям, быстрому развитию и распараллеливанию процессов, и это делает тестирование встроенного ПО еще более важным. Здравоохранение, где стандарты традиционно очень высоки, отличает огромный спрос на сложные и сверхточные алгоритмы – такие как, например, алгоритм автоматического распознавания сердечных ритмов для инновационного дефибриллятора, над которым сейчас трудятся инженеры Ауриги. Новые интеллектуальные больничные системы, «умное» медицинское оборудование и носимые устройства, которые появляются почти каждый день, должны быть безопасными и надежными^[11].

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

1.2 Стратегии «белого» и «черного» ящика при тестировании программного обеспечения

В зависимости от степени доступа к коду системы можно выделить два типа функциональных испытаний^[13]:

тестирование black box (черный ящик) – проведение функционального тестирования без доступа к коду системы,
тестирование white box (белый ящик) – функциональное тестирование с доступом к коду системы.

Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию)^[14]. Стоит отметить, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.

Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство^[15].

Стратегия Black-box тестирования применяется в^[16]:

Интеграционном тестировании. При использовании метода «черного ящика» тестировщик проверяет, корректно ли работают все компоненты в целом тогда, когда они интегрированы в большую систему. И действительно, нормальная работа каждой составляющей по отдельности – это еще не гарантия того, что они будут работать вместе в рамках всего проекта. Например, данные могут не отправиться через интерфейс, или интерфейс не отработает согласно документации. При планировании таких тестов тестировщики опираются на спецификацию.
Функциональном тестировании. Используя этот метод, тестировщик проверяет, выполняет ли программное обеспечение все заявленные функции и требования клиента в полном объеме согласно документации^[17].
Стресс-тестировании. Предположим, что у нас есть букмекерская онлайн-контора, в документации к которой заявлена возможность одновременной регистрации 1000 пользователей. В этом случае стрессовым тестированием будет непрерывный поток автоматизированных регистраций (как минимум, 1000 регистраций в минуту) на протяжении 12 часов.
Usability-тестировании. Пусть в упомянутой букмекерской конторе есть функционал «Купон»: мы проверяем, сколько времени уходит у пользователя для добавления ставки в купон, ввода суммы и завершения ставки^[18].
Тестировании производительности. Таким видом тестирования мы можем проверить: есть ли утечки памяти, насколько быстро система работает и выдает обратную связь, не потребляет ли наше ПО слишком много трафика и не создает ли избыточное количество подключений^[19].
Приемочном тестировании. После проверки ПО тестировщиками его отдают заказчику, который запускает приемочные тесты «черного ящика» на основе ожиданий от функциональности. Как правило, набор тестов в этом случае определяет сам заказчик, за ним же остается право отказаться от приемки (если его не устроили результаты тестирования).
Регрессионном тестировании. Проводится на протяжении всего цикла разработки. Цель такого тестирования – проверить работоспособность нового кода и выяснить, не привел ли он к ошибкам или поломкам в старом функционале.
Beta-тестировании. Практически готовое ПО отдают для «обкатки» желающим для выявления максимального количества ошибок еще до того, как оно попадет к конечному пользователю^[20]. Это дает разработчику ПО идентификацию непредвиденных ошибок (так как бета-тестеры используют ПО нестандартно), широкий набор окружений для проверки, который трудно обеспечить иными методами (разные операционные системы, разные настройки, разные версии браузеров), а также снижение расходов (так как работа бета-тестеров, как правило, не оплачивается)^[21].

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

Для функционального тестирования, как правило, используются такие инструменты как 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].

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

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

Как уже было указано выше, тестирование проводится в соответствии с программой и методикой испытаний, которая разрабатывается в соответствии с ГОСТ 34.603-92.

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

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

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

Нагрузочное тестирование - процесс анализа производительности тестируемой системы под воздействием нагрузок^[61]. Цель нагрузочного тестирования- определить способность приложения к внешним нагрузкам. Обычно испытания проводятся в несколько этапов^[62]:

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

2. Разработка тестовой конфигурации. Имея сценарии тестирования, важно распределить порядок возрастания нагрузки. Для успешного анализа необходимо выделить критерии оценки производительности (скорость отклика, время обработки запроса и т.д.).

3. Проведение тестового испытания. При проведении тестов важно своевременно следить за исполнением сценариев и откликом тестируемой системы. Для эмуляции высоких нагрузок требуется серьезная аппаратная и программная инфраструктура. В некоторых случаях для удешевления работ применяются методы математического моделирования. За основу берутся данные, полученные при низких нагрузках, и аппроксимируются. Чем выше уровень моделируемой нагрузки, тем ниже точность оценки. Однако подобный способ существенно сокращает расходы^[63].

Основная особенность автоматизированного тестирования - возможность быстрого проведения регрессионных тестов. Главными плюсами автоматизации является увеличение эффективности персонала, более раннее обнаружение дефектов и более высокое качество бизнес-процессов^[64]. Эти преимущества компенсируются существенным недостатком: дороговизна, - из-за высокой цены на внедрение и поддержку автоматизации тестирования, около 50% компаний до сих пор применяют в основном ручное тестирование.

Любое приложение создается для того, чтобы им воспользовались. Удобство использования - важный качественный показатель программы. IT индустрия знает множество примеров, когда проекты взлетали после удачного исправления удобства использования^[65]. Чем шире аудитория, тем важнее фактор юзабилити. Тестирование юзабилити включает в себя детальный анализ поведения пользователей. Для оценки эргономики важно иметь данные не только о скорости выполнения бизнес-задачи, но и об эмоциях пользователя, мимике лица, тембра голоса.

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

Глава 2. Характерные особенности тестирования мобильных приложений

Мобильные приложения представляет собой приложения, процесс тестирования которых значительно отличается от тестирования десктопных приложений^[67]. При разработке мобильных приложений, а следовательно, и при тестировании, следует учитывать ряд определенных моментов^[68]:

мобильные устройства — это системы, которые чаще всего имеют не шибко мощную начинку. Они по определению не могут работать как персональный компьютер, поскольку слабее в разы.
прогресс в сфере информационных приложений движется очень быстро, поэтому операционные системы мобильных устройств быстро устаревают. Кроме того, есть предел на обновление их ОС. К примеру, на Iphone 4 — это версия 7.1.2.
многообразие экранов, их расширений и цветов. В отличие от монитора компьютера, экран мобильных устройств может менять ориентацию, что также необходимо учесть при разработке и тестировании мобильных приложений.
существует определенный список обязательных параметров мобильных приложений, которые создаются производителями устройств. Им следовать нужно обязательно.
мобильное устройство чаще всего находится в движении, поэтому следует ожидать, что могут возникнуть какие-то случайные действия на устройстве^[69] (если оно не заблокировано, если щекой нажимаешь кнопки или кто-то тебя пинает). При разработке приложения для мобилки нужно также учесть его пребывание в разных погодных условиях, при разном свете, поэтому нужно использовать контрастные цвета.
необходимо помнить, что основной задачей, к примеру телефона, по прежнему являются звонки, и приложение ну никак не должно мешать этой прямой и главной функции устройства.
разные мобильные устройства обладают разными примочками. И наполнение вашего приложения должно им соответствовать.
при тестировании мобильных приложений все-таки следует пренебречь эмуляторами, если у вас есть такая возможность. Дело в том, что в них не всегда функционал соответствует всем возможностям реального девайса.
на мобильных устройствах может быть представлено большое разнообразие специфических операционных систем и конфигураций комплектующих.
устройство постоянно пребывает в состоянии поиска сети. При тестировании следует проверить работу приложения на разных скоростях передачи данных.

Еще одна важная вещь в процессе тестирования мобильных приложений — это тип приложения. Существует три основных типа мобильных приложений^[70]: мобильные веб-приложения, нативные приложения и гибридные приложения.

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

Простая разработка.
Легкий доступ.
Простое обновление.
Мобильные веб-приложения не требует установки.

Недостатки мобильных веб-приложений:

Нет поддержки автономных функций.
Ограниченная функциональность в сравнении с гибридными и нативными приложениями (нет доступа к файловой системе и локальным ресурсам)
Проблемы с перераспределением: Google Play и App Store не поддерживают перераспределение мобильных веб-приложений.

Нативное приложение — это приложение, разработанное специально для одной платформы (Android, iOS, BlackBerry)^[72]. Достоинства нативных приложений:

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

Недостатки нативных приложений:

Разработка нативных обходится дороже в сравнении с мобильными веб-приложениями.
Требуется больших затрат на техническое обслуживание^[73].

Гибридное приложение — это сочетание нативного и мобильного веб-приложений. Его можно определить как отображение содержимого мобильного сайта в формате приложения. Достоинства гибридных приложений^[74]:

Более рентабельно по сравнению с нативным приложением.
Простое распространение.
Встроенный браузер.
Особенности устройства.

Недостатки гибридных приложений:

Работает не так быстро, как нативное приложение.
Графика менее адаптирована к ОС в сравнении с нативным приложением.

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

Мобильное приложение должно быть интуитивно понятным, удобным, работать бесперебойно, безопасно, круглосуточно и достаточно быстро реагировать на действия пользователя^[75]. Рассмотрим основные моменты и особенности тестирования мобильных приложений, на которые стоит обратить внимание при функциональном тестировании мобильных приложений^[76]:

К размеру экрана и touch-интерфейса предъявляются следующие требования:

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

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

Факт утечки памяти можно проверить с помощью таких программ, как например, Instruments (стандартное приложение MacOS). Может быть не более 30 мб. на 2 г. айфон/айпод, примерно 70мб для всех устройств до 2-го айпада,
Нужно уделить внимание окнам с большим количеством информации, при длительном пребывании пользователя в приложении.

Проверка работы приложений на ретина экранах и различных версия OS учитывает следующие параметры^[77]:

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

Проверка работы обратной связи учитывает эффективную работу следующих элементов^[78]:

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

Проверка работы обновлений подразумевает корректную работу мобильного приложения исходя из^[79]:

проверка различных путей установки обновлений (wifi, bluetooth, usb),
проверка работы установленных изменений, мест, куда они вносились,
необходимо также убедиться в поддерживаемости обновлений более старыми ОС, чтобы элементы, которые на новой системе работают хорошо не падали на более старых версиях.

Проверка реакции приложения на внешние прерывания включает:

входящие/исходящие смс, ммс, звонки
разряд/изъятие батареи
отключение сети/wifi
подключение кабеля, карты, зарядки.

Фактор рекламы в мобильном приложении должен пройти проверку по следующим факторам:

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

При проверке локализации необходимо учитывать:

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

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

К основным этапам функционального тестирования мобильного приложения можно отнести^[81]:

Тестирование документации. Проверка документации — это необходимый подготовительный этап процесса тестирования мобильных приложений. Фактически, тестирование начинается до процесса разработки программного обеспечения. Тестировщики получают навигационные диаграммы, схемы экрана, другие требования. Эти требования анализируются на предмет полноты и несогласованности. Противоречия в требованиях должны быть решены до начала разработки. На этом этапе создаются и анализируются требования (спецификация, PRD), план тестирования, тестовые сенарии, матрица отслеживания^[82].
Основной этап функционального тестирования. Функциональное тестирование направлено на работу приложения в соответствии с определенными требованиями. Проще говоря, тестировщик проверяет, выполняет ли приложение ожидаемые функции, которые обычно описываются в спецификации^[83]. При этом, необходимо обратить внимание на следующие важные факторы при проведении функционального тестирования вашего мобильного приложения:

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

Стоит также рассмотреть основные проверки, которые должны быть проведены для определения функциональности мобильных приложений:

Установка и запуск приложения
Установка приложения должна выполняться без значительных ошибок, если устройство соответствует системным требованиям.
Необходимо убедиться, что приложение автоматически запускается правильно.
Необходимо убедиться, что руководство пользователя доступно.
Необходимо убедиться, что работа приложения во время запуска / выхода соответствует основным требованиям.

При тестировании полей необходимо проверить правильность функционирования необходимых полей, а также убедится, что обязательные и необязательные поля отображаются по-разному^[84].

В процессе тестирования функциональности нужно убедится, что заявленная цена и контент соответствуют полученной пользователем информации, убедится, что пользователь может выполнять типичные операции: покупка, добавление товаров в корзину, заказ товаров, а также нужно убедится, что приложение поддерживает платежные операции через платежные системы, такие как Visa, Mastercard, Paypal^[85].

Кроме того, требуется проверка на возможность восстановление покупки независимо от устройства, но с привязкой к учетной записи^[86].

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

Входящие и исходящие звонки, SMS и MMS.
Разрядка / снятие батареи.
Отключение и подключение сети / Wi-Fi.
Отсоединение и подключение SD-карты.
Зарядка устройства.

Постоянное тестирование отзывов пользователей включает в себя тестирование^[87]:

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

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

Все пользовательские данные сохраняются после обновлений.
Ход обновления отображается правильно.
Обновления поддерживаются более старыми операционными системами.
Тестирование различных способов установки обновлений (Wi-Fi, Bluetooth, USB) успешно пройдены.

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

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

К дополнительным процедурам тестирования можно отнести^[89]:

Тестирование правильности подключения / разъединения игроков, подключения игроков через разные сети.
Убедитесь, что сообщения об ошибках верны и уместны.
Проверьте подключение к аналитическим инструментам, таким как Google Analytics.
Тестирование энергопотребления.
Проверьте необходимые параметры правильной работы с социальными сетями — «Поделиться», «Опубликовать», «Навигация».

Юзабилити-тестирование направлено на обеспечение удобства использования приложения, создание интуитивно понятного интерфейса, соответствующего принятым стандартам. Он выполняется для создания быстрых и простых в использовании приложений^[90]. Вот 3 основных критерия оценки приложений^[91]:

Удобство,
КПД,
Эффективность.

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

Убедитесь, что кнопки имеют нормальный размер и помещены в одну область экрана.
Убедитесь, что приложение работает в многозадачном режиме, когда это необходимо.
Проверьте навигацию важных модулей приложений.
Убедитесь, что значки и изображения выглядят естественно в среде приложения.
Убедитесь, что цвет кнопок, которые выполняют одну и ту же функцию, одинаковый.
Текст должен быть простым, понятным и видимым для пользователя. Можно читать короткие предложения и параграфы.
Определите оптимальный размер шрифта.
Обеспечьте правильную работу системы Zoom-in and Zoom-out.
Проверьте, что контекстные меню не перегружены.
Убедитесь, что приложение может быть прервано любым состоянием и что оно возобновляет работу в том же состоянии.
Убедитесь, что компоненты приложения синхронизированы с действиями пользователя.
Убедитесь, что пользователь может вернуть или отменить действие, если он нажал неправильную кнопку.
Убедитесь, что скорость ответа элемента достаточно высока.

Тестирование пользовательского интерфейса UI выполняется для обеспечения соответствия графического пользовательского интерфейса вашего приложения спецификациям^[92]:

Обеспечить соответствие стандартам пользовательского интерфейса. Соответствие стандартным разрешениям экрана: 640 × 480, 800 × 600, 1024 × 768, 1280 × 800, 1366 × 768, 1400 × 900, 1680 × 1050^[93].
Протестируйте работоспособность приложений на разных устройствах.
Проверьте основные элементы дизайна: кнопки, значки, цвета, ссылки, шрифты, размеры шрифта, макет, текстовые поля, форматирование текста, ярлыки, титры, кнопки, списки и т. д.
Убедитесь, что реклама не перекрывает кнопки управления приложениями.
Убедитесь, что у рекламы есть доступная кнопка закрытия.
Проверьте отображение всех элементов с ориентацией на портретную и альбомную страницу.

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

Кросс-платформенное тестирование помогает тестировать мобильное приложение на разных ОС: Windows, iOS, Android и BlackBerry и т. д. Кросс-браузерное тестирование позволяет обеспечить правильную работу приложения в разных конфигурациях браузера: Mozilla Firefox, Google Chrome, Opera Mini и т. д.^[94]

Тестирование базы данных предназначено для проверки правильной работы вашего приложения в разных конфигурациях базы данных: Oracle, DB2, MySql, MSSQL Server, Sybase. При тестировании конфигурации устройства должны учитываться такие параметры^[95]:

Тип устройства: смартфон, планшет и т. д.
Конфигурация устройства: ОЗУ, тип процессора, разрешение экрана, емкость аккумулятора и т. д.
Тестирование конфигурации сети выполняется для обеспечения правильной работы в различных сетевых конфигурациях (GSM, TDMA) и стандартах (2G, 3G, 4G).

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

Основные цели тестирования производительности^[96]:

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

Тестирование безопасности предназначено для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложений от хакеров, вирусов, несанкционированного доступа к конфиденциальным данным^[97]:

Убедитесь, что данные пользователей приложения (логины, пароли, номера банковских карт) защищены от сетевых атак автоматизированных систем.
Убедитесь, что система безопасности приложений требует надежного пароля и не позволяет злоумышленнику получать пароли других пользователей.
Убедитесь, что приложение не предоставляет доступ к конфиденциальному содержимому или функциям без надлежащей проверки подлинности.
Защитите приложение и сеть от DoS Attacks.
Защитите приложение от вредоносных атак на клиентов.
Предотвратите возможные вредоносные последствия кэширования файлов.
Изучите файлы пользователей и предотвратите их возможные негативные последствия.
Анализ взаимодействия системных файлов, выявление и исправление уязвимостей^[98].

Тестирование восстановления проверяет тестируемое приложение с точки зрения его способности выдерживать и успешно восстанавливаться после возможных сбоев, вызванных ошибками программного обеспечения, сбоями оборудования или проблемами связи^[99]:

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

Глава 3. Практическое применение инструментов функционального тестирования мобильных приложений

Наиболее распространёнными на данный момент инструментами для функционального тестирования мобильных приложений являются:

Calabash - это фреймворк для автоматизации функционального тестирования, который является своего рода драйвером, управляющим работой приложения на девайсе или симуляторе. Подходит как для Android-приложений, так и для приложений для iOS. Разработкой и поддержкой занимается компания Xamarin. Также компания Xamarin предоставляет платную услугу тестирования в «облаке»^[100].
Appium - это open source фреймворк, который помогает автоматизировать тестирование мобильных приложений. В последнее время Appium часто упоминают на конференциях, а используется он даже Яндексом.
Robotium предназначен для Android-приложений. С помощью него разработчики могут писать функциональные тесты, охватывающие несколько Android активити^[101].
Espresso — это инструмент для тестирования пользовательских интерфейсов Android-приложений. Основной API невелик и прост, но поскольку исходный код инструмента открыт, вы можете расширить его для своих нужд^[102].
iOS UI automation - родной инструмент функционального тестирования программ для устройств Apple.
MonkeyRunner - API для написания программ, которые управляют Android-устройством или эмулятором извне Android-кода. Дает возможность написать программу на Python, которая установит приложение или тестовый пакет, запустит его, отправит нажатия, сделает скриншоты интерфейса и сохранит их.
Ranorex — это GUI-фреймворк для автоматизации тестирования настольных, веб- и мобильных приложений. У него нет своего языка — вместо этого он использует C# и VB.NET.
TestFairy. При публичном тестировании мобильных приложений очень сложно узнать, из-за чего конкретно у пользователя возникла та или иная проблема. TestFairy решает эту проблему, записывая все тесты на видео, а также запоминая технические характеристики устройства^[103].

Рассмотрим специфику функционального тестирования мобильного приложения на примере ПО Calabash. Calabash состоит из библиотек, которые дают возможность тесту программно взаимодействовать с нативными и гибридными приложениями. Взаимодействие заключается в виде реализованных действиях пользователя. Такими действиями могут быть:

Касания и жесты (tap, swipe, rotate и т.п.).
Проверки. Например: Должна присутствовать кпопка «Login» на экране.

Calabash поддерживает Сucumber. Cucumber позволяет нам описать поведение программы используя простой «человеческий» язык, который понятен бизнес-аналитику, менеджеру и тестировщику без знаний программирования^[104]. Наиболее нужными командами интерактивной среды calabash являются: query для поиска необходимых объектов и их свойств, tap – команда нажатия на объект, а также команда performAction – исполнение определенных действий^[105] (нажатие на кнопку «назад», «меню», проскроллить и тому подобное).

Для примера описания работы calabash, напишем простейший тестовый сценарий. Откроем файл my_first.feature, который находится в директории features и пишем наш тестовый сценарий:

Feature: Menu localization

# Заголовок сценария

Scenario: As a user I can open a menu and verify options

# Нажимаем на кнопку "Меню"

When I press the menu key

# Проверяем, если текст "Settings", "Update" и т.д.

Then I see "Settings"

Then I see "Update"

Then I see "Like us"

Then I see "Rate us"

Then I see "Feedback"

Then I see "FAQ"

Then I see "Fast Clean"

Then I see "About"

Scenario: As a user I can change language app to Nedelrands

When I press the menu key

When I press "Settings"

Then I press "Language"

When I press "Nederlands"

Then I see "Taal"

When I go back

When I press the menu key

Then I see "Instellingen"

Then I see "Moderniseren"

Then I see "Net als wij"

Then I see "Beoordeel ons"

Then I see "Terugcontact"

Then I see "FAQ"

Then I see "Snel schoonmaken"

Then I see "Over ons".

После этого запускаем тест в ОС Android:

calabash-android run "Clean Master_3.8.1.apk"

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

Заключение

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

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

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

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

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

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

Использование рассмотренной в работе программы Calabash framework очень удобно для качественного функционального тестирования мобильных приложений. Тестировщик имеет возможность писать тестовые сценарии, которые будут работать как для Android, так и для iOS приложений без больших усилий. Фреймворк активно развивается, прост в использовании и интеграции.

Библиография

Басок Б.М. Тестирование программного обеспечения. Москва: МГТУ МИРЭА, 2012.
Бедердинова О.И., Иванова Л.А. Совершенствование метода тестирования программного обеспечения «Белый ящик». // Arctic Evironmental Research, №5, 2014
Бейзер Б. Тестирование черного ящика. СПб.: Питер, 2011, - 316 с.
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. - 434 с.
Бирюков С.В. Анализ стратегий тестирования программного обеспечения. // Известия Южного федерального университета. Технические науки, №6, 2008
Варакин М.В. Разработка мобильных приложений под Android. УЦ «Специалист» при МГТУ им. Н. Э. Баумана, 2012, - 128 с.
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 120 с.
Котляров В.П. Основы тестирования программного обеспечения. 2-е изд. — М.: Интуит, 2016. — 348 с.
Криспин Л., Грегори Дж. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. М.: Вильямс, 2010. — 464 с.
Куликов С. Тестирование программного обеспечения. 2-е издание. Минск: Четыре четверти, 2017, - 298 с.
Куликова Н.Л. Новые исследования и современные тенденции в тестировании. Российский гос. соц. ун-т, Каф. программного обеспечения вычислительной техники. Москва : АПКиППРО, 2010
Липаев В.В. Тестирование компонентов и комплексов программ. М.: СИНТЕГ, 2011. — 408 с.
Майерс Г. Искусство тестирования программ. 3-е изд. – Москва, 2012. – 270 с.
Мартюков А.С. Методология функционального тестирования программного обеспечения на основе сценариев использования и схемы приоритетов. // Новые информационные технологии в автоматизированных системах, №1, 2010
Остренков А.А. Тестирование программного обеспечения. Москва: б. и., 2007, - 63 с.
Павловская О.О. Статические методы оценки надежности программного обеспечения. // Вестник Южно-Уральского государственного университета. Серия: Компьютерные технологии, управление, радиоэлектроника, №4, 2009
Парамонов И.В. Разработка мобильных приложений для платформы Android. Ярославль: ЯрГУ, 2013. — 88 с.
Пероцкая В.Н., Градусов Д.А. Основы тестирования программного обеспечения. Владимир: Владимирский государственный университет им. А.Г. и Н.Г. Столетовых (ВлГУ), 2017. — 100 с.
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 166 с.
Полянский А. Функциональное тестирование программного обеспечения. М.: СИНТЕГ, 2016, - 32 с.
Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения. 2-е изд. М.: Интуит, 2016. — 445 с.
Тамре Л. Введение в тестирование программного обеспечения. Москва: Вильямс, 2003. - 359 с.
Фадеев А.Ю., Волкова Е.А. Сравнительный анализ программного обеспечения для разработки мобильных приложений. // Наука и перспективы, №5, 2016
Эпп В.В. Качество и тестирование программного обеспечения. Пенза: Изд-во ПГУ, 2012. – 108 с.
Автоматизация тестирования мобильных приложений с Calabash. [Электронный ресурс], режим доступа: https://anadea.info/ru/blog/automated-testing-of-mobile-applications-with-calabash
Как тестировать мобильное приложение? [Электронный ресурс], режим доступа: https://punicapp.com/blog/ru/pages/648/kak-testirovat-mobilnoe-prilozhenie/
Нагрузочное тестирование: виды, описание процесса [Электронный ресурс], режим доступа: http://fb.ru/article/243491/nagruzochnoe-testirovanie-vidyi-opisanie-protsessa
Руководство для начинающих по тестированию мобильных приложений. [Электронный ресурс], режим доступа: https://freelance.today/poleznoe/rukovodstvo-dlya-nachinayuschih-po-testirovaniyu-mobilnyh-prilozheniy.html
Тестирование мобильных приложений. [Электронный ресурс], режим доступа: https://apptractor.ru/test/testirovanie-mobilnyih-prilozheniy.html
Agile и DevOps на службе крупного бизнеса. [Электронный ресурс], режим доступа: https://www.osp.ru/os/2016/02/13049287/
TestFairy – новая платформа для тестирования приложений под Android. [Электронный ресурс], режим доступа: http://app2top.ru/news/testfairy-novaya-platforma-dlya-testirovaniya-24706.html
Robotium is Selenium but for Android. [Электронный ресурс], режим доступа: https://www.360logica.com/blog/robotium-selenium-android/

Приложение 1

Рисунок 1. Результаты тестового сценария.

Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения. 2-е изд. М.: Интуит, 2016. — 29 с. ↑
Майерс Г. Искусство тестирования программ. 3-е изд. – Москва, 2012. – 33 с. ↑
Пероцкая В.Н., Градусов Д.А. Основы тестирования программного обеспечения. Владимир: Владимирский государственный университет им. А.Г. и Н.Г. Столетовых (ВлГУ), 2017. — 52 с. ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 42 с. ↑
Липаев В.В. Тестирование компонентов и комплексов программ. М.: СИНТЕГ, 2011. — 123 с. ↑
Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения. 2-е изд. М.: Интуит, 2016. — 30 с. ↑
Пероцкая В.Н., Градусов Д.А. Основы тестирования программного обеспечения. Владимир: Владимирский государственный университет им. А.Г. и Н.Г. Столетовых (ВлГУ), 2017. — 59 с. ↑
Майерс Г. Искусство тестирования программ. 3-е изд. – Москва, 2012. – 33 с. ↑
Agile и DevOps на службе крупного бизнеса. [Электронный ресурс], режим доступа: https://www.osp.ru/os/2016/02/13049287/ ↑
Бирюков С.В. Анализ стратегий тестирования программного обеспечения. // Известия Южного федерального университета. Технические науки, №6, 2008 ↑
Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения. 2-е изд. М.: Интуит, 2016. — 60 с. ↑
Пероцкая В.Н., Градусов Д.А. Основы тестирования программного обеспечения. Владимир: Владимирский государственный университет им. А.Г. и Н.Г. Столетовых (ВлГУ), 2017. — 63 с. ↑
Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения. 2-е изд. М.: Интуит, 2016. — 115 с. ↑
Липаев В.В. Тестирование компонентов и комплексов программ. М.: СИНТЕГ, 2011. — 124 с. ↑
Котляров В.П. Основы тестирования программного обеспечения. 2-е изд. — М.: Интуит, 2016. — 211 с. ↑
Куликов С. Тестирование программного обеспечения. 2-е издание. Минск: Четыре четверти, 2017, - 53-54 с. ↑
Майерс Г. Искусство тестирования программ. 3-е изд. – Москва, 2012. – 64 с. ↑
Как тестировать мобильное приложение? [Электронный ресурс], режим доступа: https://punicapp.com/blog/ru/pages/648/kak-testirovat-mobilnoe-prilozhenie/ ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 51 с. ↑
Бейзер Б. Тестирование черного ящика. СПб.: Питер, 2011, - 109 с. ↑
Котляров В.П. Основы тестирования программного обеспечения. 2-е изд. — М.: Интуит, 2016. — 213 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 56-57 с. ↑
Куликов С. Тестирование программного обеспечения. 2-е издание. Минск: Четыре четверти, 2017, - 68 с. ↑
Мартюков А.С. Методология функционального тестирования программного обеспечения на основе сценариев использования и схемы приоритетов. // Новые информационные технологии в автоматизированных системах, №1, 2010 ↑
↑
Липаев В.В. Тестирование компонентов и комплексов программ. М.: СИНТЕГ, 2011. — 127-128 с. ↑
Куликов С. Тестирование программного обеспечения. 2-е издание. Минск: Четыре четверти, 2017, - 72 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 57 с. ↑
Как тестировать мобильное приложение? [Электронный ресурс], режим доступа: https://punicapp.com/blog/ru/pages/648/kak-testirovat-mobilnoe-prilozhenie/ ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 112 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 60 с. ↑
Липаев В.В. Тестирование компонентов и комплексов программ. М.: СИНТЕГ, 2011. — 128 с. ↑
Котляров В.П. Основы тестирования программного обеспечения. 2-е изд. — М.: Интуит, 2016. — 229 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 79 с. ↑
Бедердинова О.И., Иванова Л.А. Совершенствование метода тестирования программного обеспечения «Белый ящик». // Arctic Evironmental Research, №5, 2014 ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 150 с. ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 151-152 с. ↑
Куликов С. Тестирование программного обеспечения. 2-е издание. Минск: Четыре четверти, 2017, - 172 с. ↑
Куликова Н.Л. Новые исследования и современные тенденции в тестировании. Российский гос. соц. ун-т, Каф. программного обеспечения вычислительной техники. Москва : АПКиППРО, 2010, - 81 с. ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 152 с. ↑
Куликова Н.Л. Новые исследования и современные тенденции в тестировании. Российский гос. соц. ун-т, Каф. программного обеспечения вычислительной техники. Москва : АПКиППРО, 2010, - 83 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 66 с. ↑
Эпп В.В. Качество и тестирование программного обеспечения. Пенза: Изд-во ПГУ, 2012. – 40 с. ↑
Остренков А.А. Тестирование программного обеспечения. Москва: б. и., 2007, - 23 с. ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 90 с. ↑
Куликова Н.Л. Новые исследования и современные тенденции в тестировании. Российский гос. соц. ун-т, Каф. программного обеспечения вычислительной техники. Москва : АПКиППРО, 2010, - 60-61 с. ↑
Криспин Л., Грегори Дж. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. М.: Вильямс, 2010. — 302 с. ↑
Полянский А. Функциональное тестирование программного обеспечения. М.: СИНТЕГ, 2016, - 14 с. ↑
Остренков А.А. Тестирование программного обеспечения. Москва: б. и., 2007, - 55-56 с. ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 92 с. ↑
Куликова Н.Л. Новые исследования и современные тенденции в тестировании. Российский гос. соц. ун-т, Каф. программного обеспечения вычислительной техники. Москва : АПКиППРО, 2010, - 60 с. ↑
Плаксин М.А. Тестирование и отладка программ: для профессионалов будущих и настоящих. Москва: Бином. Лаб. знаний, 2007. – 90 с. ↑
Полянский А. Функциональное тестирование программного обеспечения. М.: СИНТЕГ, 2016, - 19-20 с. ↑
Тамре Л. Введение в тестирование программного обеспечения. Москва: Вильямс, 2003. - 132 с. ↑
Остренков А.А. Тестирование программного обеспечения. Москва: б. и., 2007, - 56 с. ↑
Полянский А. Функциональное тестирование программного обеспечения. М.: СИНТЕГ, 2016, - 22 с. ↑
Тамре Л. Введение в тестирование программного обеспечения. Москва: Вильямс, 2003. - 146 с. ↑
Павловская О.О. Статические методы оценки надежности программного обеспечения. // Вестник Южно-Уральского государственного университета. Серия: Компьютерные технологии, управление, радиоэлектроника, №4, 2009 ↑
Тамре Л. Введение в тестирование программного обеспечения. Москва: Вильямс, 2003. - 149 с. ↑
Остренков А.А. Тестирование программного обеспечения. Москва: б. и., 2007, - 57 с. ↑
Нагрузочное тестирование: виды, описание процесса [Электронный ресурс], режим доступа: http://fb.ru/article/243491/nagruzochnoe-testirovanie-vidyi-opisanie-protsessa ↑
Как тестировать мобильное приложение? [Электронный ресурс], режим доступа: https://punicapp.com/blog/ru/pages/648/kak-testirovat-mobilnoe-prilozhenie/ ↑
Эпп В.В. Качество и тестирование программного обеспечения. Пенза: Изд-во ПГУ, 2012. – 48-49 с. ↑
Тамре Л. Введение в тестирование программного обеспечения. Москва: Вильямс, 2003. - 214 с. ↑
Эпп В.В. Качество и тестирование программного обеспечения. Пенза: Изд-во ПГУ, 2012. – 50 с. ↑
Остренков А.А. Тестирование программного обеспечения. Москва: б. и., 2007, - 58 с. ↑
Тестирование мобильных приложений. [Электронный ресурс], режим доступа: https://apptractor.ru/test/testirovanie-mobilnyih-prilozheniy.html ↑
Басок Б.М. Тестирование программного обеспечения. Москва: МГТУ МИРЭА, 2012, - 36 с. ↑
Руководство для начинающих по тестированию мобильных приложений. [Электронный ресурс], режим доступа: https://freelance.today/poleznoe/rukovodstvo-dlya-nachinayuschih-po-testirovaniyu-mobilnyh-prilozheniy.html ↑
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. - 37 с. ↑
Тестирование мобильных приложений. [Электронный ресурс], режим доступа: https://apptractor.ru/test/testirovanie-mobilnyih-prilozheniy.html ↑
Тестирование мобильных приложений. [Электронный ресурс], режим доступа: https://apptractor.ru/test/testirovanie-mobilnyih-prilozheniy.html ↑
Парамонов И.В. Разработка мобильных приложений для платформы Android. Ярославль : ЯрГУ, 2013. — 40-41 с. ↑
Руководство для начинающих по тестированию мобильных приложений. [Электронный ресурс], режим доступа: https://freelance.today/poleznoe/rukovodstvo-dlya-nachinayuschih-po-testirovaniyu-mobilnyh-prilozheniy.html ↑
Басок Б.М. Тестирование программного обеспечения. Москва: МГТУ МИРЭА, 2012, - 37 с. ↑
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. - 135 с. ↑
Тестирование мобильных приложений. [Электронный ресурс], режим доступа: https://apptractor.ru/test/testirovanie-mobilnyih-prilozheniy.html ↑
Парамонов И.В. Разработка мобильных приложений для платформы Android. Ярославль : ЯрГУ, 2013. — 42 с. ↑
Руководство для начинающих по тестированию мобильных приложений. [Электронный ресурс], режим доступа: https://freelance.today/poleznoe/rukovodstvo-dlya-nachinayuschih-po-testirovaniyu-mobilnyh-prilozheniy.html ↑
Басок Б.М. Тестирование программного обеспечения. Москва: МГТУ МИРЭА, 2012, - 76-77 с. ↑
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. – 151-152 с. ↑
Басок Б.М. Тестирование программного обеспечения. Москва: МГТУ МИРЭА, 2012, - 75 с. ↑
Парамонов И.В. Разработка мобильных приложений для платформы Android. Ярославль : ЯрГУ, 2013. — 44 с. ↑
Басок Б.М. Тестирование программного обеспечения. Москва: МГТУ МИРЭА, 2012, - 77 с. ↑
Руководство для начинающих по тестированию мобильных приложений. [Электронный ресурс], режим доступа: https://freelance.today/poleznoe/rukovodstvo-dlya-nachinayuschih-po-testirovaniyu-mobilnyh-prilozheniy.html ↑
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. - 155 с. ↑
Варакин М.В. Разработка мобильных приложений под Android. УЦ «Специалист» при МГТУ им. Н. Э. Баумана, 2012, - 53 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 48-49 с. ↑
Басок Б.М. Тестирование программного обеспечения. Москва: МГТУ МИРЭА, 2012, - 64-65 с. ↑
Варакин М.В. Разработка мобильных приложений под Android. УЦ «Специалист» при МГТУ им. Н. Э. Баумана, 2012, - 33 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 119 с. ↑
Липаев В.В. Тестирование компонентов и комплексов программ. М.: СИНТЕГ, 2011. — 137 с. ↑
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. - 154 с. ↑
Дворянкин А.М., Ерофеев А.А., Аникин А.В. Основные методы тестирования программного обеспечения. Волгоград: ВолгГТУ, 2015. — 67 с. ↑
Липаев В.В. Тестирование компонентов и комплексов программ. М.: СИНТЕГ, 2011. — 140 с. ↑
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. – 153-154 с. ↑
Варакин М.В. Разработка мобильных приложений под Android. УЦ «Специалист» при МГТУ им. Н. Э. Баумана, 2012, - 81 с. ↑
Котляров В.П. Основы тестирования программного обеспечения. 2-е изд. — М.: Интуит, 2016. — 208-209 с. ↑
Березовская Ю.В., Юфрякова О.А., Вологдина В.Г. и др. Введение в разработку приложений для ОС Android. М.: НОУ "ИНТУИТ", 2016. - 155 с. ↑
Автоматизация тестирования мобильных приложений с Calabash. [Электронный ресурс], режим доступа: https://anadea.info/ru/blog/automated-testing-of-mobile-applications-with-calabash ↑
Robotium is Selenium but for Android. [Электронный ресурс], режим доступа: https://www.360logica.com/blog/robotium-selenium-android/ ↑
Фадеев А.Ю., Волкова Е.А. Сравнительный анализ программного обеспечения для разработки мобильных приложений. // Наука и перспективы, №5, 2016 ↑
TestFairy – новая платформа для тестирования приложений под Android. [Электронный ресурс], режим доступа: http://app2top.ru/news/testfairy-novaya-platforma-dlya-testirovaniya-24706.html ↑
Фадеев А.Ю., Волкова Е.А. Сравнительный анализ программного обеспечения для разработки мобильных приложений. // Наука и перспективы, №5, 2016 ↑
Автоматизация тестирования мобильных приложений с Calabash. [Электронный ресурс], режим доступа: https://anadea.info/ru/blog/automated-testing-of-mobile-applications-with-calabash ↑