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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 23.04.2023

Просмотров: 1145

Скачиваний: 15

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Введение

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

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

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

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

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

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

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

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

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


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

В структуру данной работы входит: введение, основная часть, состоящая из трех глав, заключение, библиография и 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].