Основы тестирования и отладки приложений на смартфоне

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

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

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

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

Любая технология предполагает наличие набора методов, в тестировании обычно выделяют два самых распространенных метода: метод "черного ящика" и метод "белого ящика".

Метод "черного ящика" (англ. Black-box testing), предполагает доступ к программному обеспечению только через те интерфейсы, которые доступны (или будут доступны) пользователю. Как правило, тестирование черного ящика ведется с использованием спецификаций или иных документов, описывающих требования к системе.

Метод "белого ящика" (англ. White-box testing), предполагает доступ к исходному коду программ. Разработчик тестов может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы.

В некоторых случаях используется метод "серого ящика" (англ. Gray-box testing), представляющий собой нечто среднее между методами белого и черного ящиков. Разработчик тестов имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

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

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

Покрытие, основанное на спецификации или требованиях (Specification-Based or Requirements-based Test Coverage). Этот критерий оценивает степень покрытия, принимая во внимание требования заказчика или системные спецификации. Основой может быть, например, таблица требований, use case модель и диаграмма состояний-переходов. Набор тестов должен покрывать все функциональные требования, иногда необходимо проверить только некоторый набор требований, в этом случае набор тестов должен покрывать именно эти функциональные требования. Данный критерий показывает в процентном отношении количество покрытых тестами требований. Чаще всего используется при тестировании методом "черного ящика".

Покрытие, основанное на коде (Code-Based Coverage). Этот критерий относится к потоку управления и потоку данных программы. Можно выделить следующие критерии покрытия кода:

• Покрытие строк (Line Coverage) — мера измерения покрытия кода, указывающая процентное отношение строк программы, затронутых тестами, к общему числу строк. Это очень неточная метрика, так как даже стопроцентное покрытие по ней пропускает много ошибок.
• Покрытие ветвей (Branch Coverage) — мера измерения покрытия кода, указывающая процентное отношение ветвей потока управления, затронутых тестами, в общем числе таких ветвей. Эта метрика надежней предыдущей, но и в ней стопроцентное покрытие не гарантирует отсутствие ошибок.
• Покрытие путей (Path Coverage) — мера измерения, характеризующая процент всевозможных путей (и/или комбинаций ветвей), которые покрываются тестами. Однако, даже не смотря на стопроцентное покрытие (достичь которого практически нереально в коммерческих системах) все еще могут присутствовать скрытые ошибки.

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

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

Классификация по объектам (элементам) тестирования. Часто разделение на виды тестов по данному критерию называют разделением тестирования на уровни.

• Модульное тестирование (автономное или Unit-тестирование). На данном уровне тестируются по отдельности небольшие разработанные компоненты системы, максимально отделенные от других компонентов, но при этом пригодные для тестирования. Обычно проводится сразу после разработки компонента, направлено на оценку соответствия его функциональности спроектированной архитектуре компонентов системы (Component Design).
• Комплексное тестирование (сборочное тестирование, Integration testing). На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей системы, направлено на проверку взаимодействия компонентов в соответствии с архитектурой системы (System Design). Тесты данного уровня обычно проверяют все интерфейсы взаимодействия между компонентами, определенные в системной архитектуре, до тех пор, пока все компоненты не будут разработаны, отлажены и проинтегрированы друг с другом в единую систему.
• Системное тестирование (System testing). На данном уровне тестируется разрабатываемая система целиком, проверяется соответствие системным спецификациям (System specification), а также реализация всех функциональных и нефункциональных требований к разрабатываемой системе.
• Приемочное тестирование (приемо-сдаточное тестирование, Acceptance testing). На данном уровне производится тестирование завершенной системы заказчиком, конечным пользователем или соответствующим уполномоченным с целью определения соответствия системы требованиям заказчика и ее готовности к внедрению. На этом уровне оформляется процесс передачи продукта от разработчика заказчику.
• Операционное тестирование (Release testing). На данном уровне проверяется функционирование системы в среде эксплуатации, оценивается соответствие требованиям пользователя и выполнение роли, определенной в бизнес-модели (Business case или Business model) системы. Необходимо учитывать, что бизнес-модель также может содержать ошибки, поэтому очень важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в эксплуатации позволяет выявить и нефункциональные проблемы, такие как конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях, недостаточная производительность системы в среде эксплуатации.

Рассмотрим основные типы тестирования.

• Инсталляционное тестирование (Installation testing). Проверяется корректность инсталляции и деинсталляции программного продукта в среде максимально приближенной к эксплуатационной. Позволяет проверить возможность инсталляции/деинсталляции продукта при различных условиях: новая инсталляция, обновление системы (upgrade), инсталляция по умолчанию, полная инсталляция, выборочная инсталляция.
• Конфигурационное тестирование (Configuration testing). Проверяется работоспособность при различных конфигурациях, предполагает тестирование работы системы на различных платформах: различных вариантах аппаратной конфигурации, версиях операционной системы и окружения.
• Тестирование интернационализации (Internationalization testing). Проверяется возможность быстрой локализации продукта под необходимую локаль потенциальных пользователей системы.
• Дымное тестирование (Smoke testing). Первый прогон программы, проверяется готовность программы для проведения более обширного тестирования. Чаще всего тестируется основная бизнес-логика программы.
• Регрессионное тестирование (Regression testing). Повторное тестирование после внесения изменений в программный продукт или его окружение. Предполагается выявление потенциальных проблем, которые могли возникнуть в результате изменений, проверка исправления найденных ранее дефектов.
• Функциональное тестирование (Functional testing). Проверяется соответствие продукта функциональным требованиям и спецификациям.
• Тестирование графического интерфейса пользователя (User interface testing). Предполагается проверка работы интерфейса в целом и его отдельных компонентов, выполняется поиск ошибок функциональности посредством интерфейса.
• Тестирование удобства использования (Usability testing). Включает в себя тесты на человеческий фактор, эстетику интерфейса и его непротиворечивость, наличие и качество оперативной и контекстной помощи, руководств пользователя и учебных материалов.
• Тестирование производительности (Performance testing). Проверяется скорость работы системы (время отклика, частота транзакций) в имитационной и реальной средах, с целью установить реальную производительность программного продукта.