Файл: Характеристика процесса тестирования.pdf

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

• 1. Уровни тестирования

Стандарт ISO / IEC 25010:2011 (ГОСТ Р ИСО / МЭК 25010 - 2015) определяет качество программного обеспечения как степень соответствия системе заявленных и подразумеваемых потребностей различных заинтересованных сторон. В соответствии со стандартом модель качества программного продукта включает восемь характеристик:

• функциональная пригодность;
• уровень производительности;
• совместимость;
• удобство пользования;
• надёжность;
• защищённость;
• сопровождаемость;
• переносимость (мобильность) [11].

Выделяют следующие уровни тестирования:

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

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

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

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

Часто для свободного и открытого программного обеспечения стадия альфа - тестирования характеризует функциональное наполнение кода, а стадия бета - тестирования — стадию исправления ошибок. При этом, как правило, на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям [10].

---

Следует различать статическое и динамическое тестирование.

При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях анализируется не исходный, а промежуточный код (такой как байт - код или код на MSIL) [10]. Статический анализ всегда быстрее всех остальных методов анализа.

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

Анализ факторов, влияющих на процесс тестирования

• 1. Зависимость процесса тестирования от аппаратных характеристик устройства

Платформа Android является свободно - распространяемой бесплатной системой, и именно поэтому она завоевала такой большой процент рынка. Однако рынок занят не только «флагманскими» устройствами, но и устройствами более низких классов. Также, технологии в электронике и производстве постоянно совершенствуются, и поэтому мы видим ежегодное обновление линеек смартфонов всех производителей от корейского Samsung и тайваньского HTC до российского Highscreen и пакистанского QMobile. Оба этих фактора создают серьезную сегментацию на рынке устройств с фактически одной операционной системой, что создает дополнительные трудности в тестировании нативных Android - приложений, в отличие от того же iOS. Первым, на что стоит обратить внимание в процессе тестирования, являются аппаратные характеристики устройства, такие как:

1. Объем оперативной памяти RAM Низкий объем оперативной памяти, очевидно, может серьезно повлиять на скорость работы приложения. Но также полностью занятая RAM может привести к нестабильности приложения и нарушению его работы. Этот момент обязательно нужно учитывать в процессе тестирования, испытывая работу приложения в условиях занятой другими приложениями памяти. В этих случаях, помимо «вылетов» приложения, могут возникнуть проблемы функционального плана, ошибки и пропажа элементов пользовательского интерфейса, остановка фоновых сервисов приложения и т.д.

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

---

3. Размер и разрешение экрана Важнейший параметр для любого приложения. От размера экрана зависит размер и положение элементов пользовательского интерфейса, поэтому надо уделить особое внимание устройствам с минимальными и максимальными параметрами экрана. На устройствах с минимальными параметрами экрана (для нынешнего рынка это порядка 3.5 дюймов и VGA - разрешение) возможны наложения элементов друг на друга, что делает невозможным использование этих элементов. На больших же экранах и разрешениях (для рынка сейчас это 12 дюймов и QHD - разрешение) элементы могут быть настолько малы, что пользователь просто не будет способен попасть по ним пальцем. Поэтому в процессе обеспечения качества ПО стоит учитывать эти параметры, и создавать элементы с динамическими размерами, которые подстраиваются под любые размеры и разрешения экрана.

4. Скорость и тип Интернет – соединения. Если в исходном коде приложения предусмотрено время отсечки запроса, приложение может просто не дождаться приходящей информации. Если скорость соединения чересчур мала, элементы интерфейса попросту не успеют загрузиться в отведенное время, что может привести к непредсказуемым последствиям, среди которых остановка приложения или невозможность использования приложения ввиду отсутствия части (или всех) элементов интерфейса. Тип соединения влияет в первую очередь на функционал приложения, предусматривающего загрузку пользовательской информации. Некоторые приложения позволяют пользователям запретить загрузку или фоновое обновление данных посредством мобильной сети, и это обязательно должно проверяться в процессе тестирования, поскольку от этого потенциально зависят расходы пользователя и, в конечном итоге, удовлетворение пользователя работой приложения.

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

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

---

• 1. Зависимость процесса тестирования и документирования ошибок от использования аппаратных и программных средств управления устройством

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

1. Сворачивание приложения.

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

1. Выгрузка приложения.

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

1. Смена ориентации.

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

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

• 1. Взаимодействие приложения с ОС и другими приложениями. Особенности воспроизведения критических ошибок

Рассмотрим взаимодействие тестового приложения с ОС и другими приложениями на примере аудиоплеера, который использует стандартный звуковой сервис Android.

1. Взаимодействие плееров.

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

1. Приложения по умолчанию.

Из всех стандартных приложений Android, использующих звуковой сервис, лучшим примером может служить приложение «Телефон». Основу взаимодействия телефона и аудиоплеера составляет переключение фокуса между звонком и проигрыванием звука. Приложение телефона сообщает ОС о том, что поступил звонок – значит приложение, проигрывающее звук в данный момент должно отдать фокус телефону для проигрывания мелодии звонка, и поставить на паузу собственный звук. Когда приложение телефона сообщает ОС о том, что звонок завершен – приложение забирает обратно фокус и продолжает воспроизведение с того момента, когда этот фокус был отдан телефону. Если условно принять, что приложение телефона не имеет ошибок, то все связанные с этим ошибки полностью находятся на стороне тестируемого приложения.

---

1. Взаимодействие с уведомлениями приложения.

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

1. Взаимодействие с уведомлениями сторонних приложений.

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

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

Заключение

Существует множество различных методологий разработки программного обеспечения. Выбор определённой методологии зависит от различных факторов: сложности, объемности проекта, количества человек, участвующих в реализации проекта. Поэтому перед началом работы перед разработчиком встает вопрос о выборе техники разработки программного обеспечения. Среди методов создания программного продукта различают: Agile (XP, Lean, Scrum, FDD др.), Cleanroom, DSDM и др.

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

---