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

ВВЕДЕНИЕ

В современном мире большинство людей не мыслят себя без интернета и мобильных технологий. На сегодняшний день более 56млн. россиян пользуются мобильным интернетом^[1] и это число продолжает расти. В связи с этим с каждым днем популярность мобильных приложений повышается, и их количество неуклонно растет. С количеством растет и конкуренция, а конкуренция предъявляет все больше требований к качеству продукта. Поэтому сфера тестирования мобильных приложений приобретает всё большее влияние и значимость.

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

ГЛАВА 1 ЖИЗНЕННЫЙ ЦИКЛ ТЕСТИРОВАНИЯ

Согласно определению Алексея Баранцева^[2] тестирование — это проверка соответствия программы требованиям, осуществляемая путем наблюдения за ее работой в специальных, искусственно созданных ситуациях, выбранных определенным образом.

Сам процесс тестирования должен начинаться с подготовки к тестированию, а именно:

1. Подготовка и согласование плана тестирования -

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

1. Аудит заявленных к системе функциональных требований на соблюдение следующих критериев^[4]:

• Полнота
• Корректность
• Осуществимость
• Необходимость
• Назначение приоритетов
• Недвусмысленность
• Проверяемость
• Согласованность
• Отслеживаемость

1. Подготовка тест-кейсов

Тест-кейс, тестовый случай, тестовая ситуация (test case) — набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства^[5].

Затем происходит выполнение тестирования, оно содержит следующие этапы^[6]:

---

1. Выполнение тест-кейсов и фиксация найденных дефектов

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

Запись о дефекте должна содержать следующие данные^[7]:

• Краткое название дефекта - должно отвечать на вопросы «Где? Что? Когда?».
• Серьезность/Критичность - насколько сильно дефект влияет на использование функции ПО.
• Версия ПО – Версия, на которой проявляется дефект.
• Шаги воспроизведения – последовательность действий, которая приводит к проявлению дефекта.
• Результат – фактический результат, который происходит при выполнении шагов воспроизведения.
• Ожидаемый результат – результат, который, согласно требованиям, мы ожидаем.
• Приложения – различные снимки экрана и логи приложения, помогающие описать и локализировать проблему.

1. Анализ результатов тестирования и отчетность

Отчет по тестированию должен содержать следующие данные^[8]:

• Состав команды;
• Сроки выполнения, за которые составляется отчет;
• Описание процессов тестирования;
• Изменения тестовой модели, дополнение ТК;
• Процент пройденных ТК;
• Критичные и блокирующие проблемы и принятые меры по их устранению.

ГЛАВА 2 ОСОБЕННОСТИ ТЕСТИРОВАНИЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ

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

1. Размер экрана и touch-интерфейс:

• Проверка размеров элементов – элементы должны быть достаточного размера, чтобы пользователь мог однозначно попасть по ним.
• Отсутствие пустых экранов в приложении – пользователь не должен оказываться в ситуации, в которой не очевидно, что сейчас происходит и что делать.
• Проверка многократных нажатий на кнопку – часто, при повторном действии в момент выполнения действия, может случиться падение приложения.
• Проверка мультитача – необходимо проверять поведение приложения при нажатии на несколько элементов одновременно.
• Проверка наличия или отсутствия «нативных» жестов (pinch-to-zoom, doubletap) – если, например, поддерживается зум части приложения, то должен использоваться жест по умолчанию. А если нет необходимости выделять картинку, то по даблтапу она не должна выделяться.

---

1. Ресурсы устройства:

• Проверка потребления памяти – стоит проверять на экранах, с большим количеством информации, во время задач с длительным workflow (когда пользователь долго не выходит из приложения) при некорректно работающем кэшировании изображений.
• Проверка ситуаций нехватки памяти для функционирования ОС, когда приложение активно или работает в фоне.
• Проверка обработки отсутствия в некоторых устройствах поддерживаемых приложением функций (3G, SD-карта и т. п.).
• Проверка установки или переноса приложения на карту SD.

1. Различные разрешения экрана и версии ОС:

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

1. Реакция приложения на внешние прерывания

• Входящие и исходящие SMS, MMS, звонки, оповещения других приложений.
• Выключение устройства, изъятие аккумулятора, разрядка устройства.
• Переход в режим ожидания (в том числе и с защитой паролем). Смена ориентации устройства в режиме ожидания.
• Отключение и подключение провода.
• Отключение и включение сети, Bluetooth, авиарежима, GPS.
• Потеря связи с сервером или прокси (подключение есть, но пакеты не доходят).
• Отключение и подключение SD-карты, дополнительных устройств вроде физической клавиатуры или гарнитуры.
• Зарядка устройства.
• Работа с акселерометром.
• Работа с физической клавиатурой (если в списке поддерживаемых моделей есть такие).

1. Платный контент внутри приложения:

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

1. Интернационализация (проверять и в портретном, и в ландшафтном режиме!):

---

• Проверка корректности перевода.
• Проверка того, что все надписи входят в соответствующие формы, кнопки и т.п.
• Проверка форматов дат, разделителей в числах, специфических особенностей локализации (вроде пробела перед знаком вопроса во французской, верхних индексов “o” и “a” в порядковых числительных в испанской и других нетривиальных моментов).

1. Постоянная обратная связь с пользователем:

• У всех нажимаемых элементов должно быть нажатое состояние (отклик на действие) – благодаря этому пользователь всегда будет видеть, действительно ли нажатие случилось. В Android-приложениях у элементов может быть ещё одно состояние – focused.
• Реакция кнопок на нажатие. Скорость отклика элементов должна быть достаточно высокой. Желательно использовать для проверки этого пункта самые слабые устройства среди поддерживаемых.
• Сообщения при загрузке контента или прогресс-бар.
• Сообщения при ошибке доступа к сети, BT, GPS.
• Наличие понятных сообщений при попытке удалить важную информацию.
• Наличие экрана или сообщения при окончании процесса или игры.
• Наличие и синхронность звуков или вибрации с уведомлениями и другими событиями на экране.

1. Обновления:

• Убедиться, что поддерживаются те же версии ОС, что и предыдущая версия (если новая версия приложения использует новые возможности ОС, то для старых поддерживаемых версий ОС необходимо создание урезанной версии приложения).
• Проверка адекватного обновления (сохраняются все данные пользователя и т. п.).

1. Root-права

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

Глава 3. Тестирование приложения на примере Veros Wallet.

Для применения полученной теории было выбрано приложение из GooglePlay для последующего тестирования. Я ориентировался на не слишком популярные приложения с оценкой около 4 звезд.

Результатом поиска стал VEROS Wallet со следующими показателями:

Количество установок

500–1 000

Оценка

4.0

Текущая версия

1.3

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

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

1). Создание кошелька

---

• Ввод имени кошелька
• Ввод пароля
• Ввод повтора пароля
• Ввод email-адреса
• Выбор типа секретного вопроса
• Ввод ответа на секретный вопрос
• Кнопка создания кошелька

2). Импорт кошелька через хэшированную строку

• Проверка пароля при импорте

3). Импорт кошелька через сканирование QR кода

• Проверка пароля при импорте

4). Отображение кошелька в приложении

• Отображение названия кошелька
• Отображение адреса кошелька
• Отображение баланса кошелька

5). Взаимодействие с кошельком

5.1). Перевод с кошелька (Send Veros)

• Отправка через QR код
• Отправка через адрес кошелька

5.2). Получение валюты (Receive Veros)

• Генерация QR кода

5.3.). История операций (Transaction)

• Пополнение
• Списание

5.4). Дополнительно

• Поделиться адресом кошелька через другое приложение
• Экспорт кошелька
• Удаление кошелька

6). Обновление состояния кошельков

7). Общий баланс кошельков

8). Восстановление кошелька

Список проверок:

1). Проверка сохранения валидных данных в имя кошелька.

Шаг	Действие	Ожидаемый результат
1	Войти в приложение VerosWallet.	Отобразилось главное окно приложения.
2	Нажать кнопку плюса для добавления нового кошелька.	Отобразился поп-ап предлагающий создать новый кошелек или импортировать существующий.
3	Выбрать создание нового кошелька.	Появилась форма создания нового кошелька.
4	Заполнить все поля валидными значениями и нажать кнопку сохранения.	Кошелек успешно сохранен.
5	Проверить, что для созданного кошелька сохранено указанное имя.	Для созданного кошелька сохранено указанное имя.

2). Проверка сохранения спецсимволов и кириллицы в имя кошелька.

Шаг	Действие	Ожидаемый результат
1	Войти в приложение VerosWallet.	Отобразилось главное окно приложения.
2	Нажать кнопку плюса для добавления нового кошелька.	Отобразился поп-ап предлагающий создать новый кошелек или импортировать существующий.
3	Выбрать создание нового кошелька.	Появилась форма создания нового кошелька.
4	Заполнить поле «Name» спец.символами и символами кириллицы. Нажать кнопку сохранить.	Кошелек не сохранен. Появилось уведомление о недопустимости использования веденных символов.

---