Какие общие функциональные проверки выполняют для всего приложения

Обновлено: 05.01.2025

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

Далее мы постараемся более подробно рассказать о каждом отдельном виде тестирования, его назначении и использовании при тестировании программного обеспечения.

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функционтальности компонента или системы в целом.

1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

Преимущества функционального тестирования:

Недостатки функционального тестирования:

возможность упущения логических ошибок в программном обеспечении;
вероятность избыточного тестирования.

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

2. Тестирование безопасности (Security and Access Control Testing)

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

Конфиденциальность

Целостность

Существует два основных критерия при определении понятия целостности:

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

Доступность

Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть.

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

Нефункциональные виды тестирования

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

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

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

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

Стрессовое тестирование ( Stress Testing )

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

Объемное тестирование ( Volume Testing )

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

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

Тестирование стабильности или надежности( Stability / Reliability Testing)

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

2. Тестирование Установки (Installation Testing)

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также на обновление или удаление программного обеспечения.

3. Тестирование удобства пользования (Usability Testing)

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

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

Уровни проведения

Советы по улучшению удобства пользования:

Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример: если поле требует цифровое значение,то логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

Заблуждения о тестировании удобства пользования:

Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

Тестирование удобства пользования можно провести без участия эксперта

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

4. Тестирование на отказ и восстановление (Failover and Recovery Testing)

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

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

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

Для наглядности, рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования, в большинстве случаев, являются весьма вероятные эксплуатационные проблемы, такие как:

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

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

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

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

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

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

5. Конфигурационное тестирование (Configuration Testing)

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

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости(portability testing: The process of testing to determine the portability of a software product.).

Связанные с изменениями виды тестирования

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

1. Дымовое тестирование (Smoke Testing)

Понятие дымовое тестирование пошло из инженерной среды:

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

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

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

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

2. Регрессионное тестирование (Regression Testing)

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

3. Тестирование сборки (Build Verification Test)

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

4. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

Функциональное тестирование

Каждый релиз конфигурации "1С:Документооборот" проходит тщательное тестирование. Вносимые изменения проходят несколько этапов проверки:

Тестирование разработчиком собственного кода.
Кросс-аудит - тестирование кода другими разработчиками.
Ручное функциональное тестирование командой тестирования.
Автоматизированное тестирование.

Каждый этап важен и помогает найти ошибки разного характера:

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

Функциональное тестирование

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

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

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

Поле заполнено текстом.
Поле заполнено цифрами.
Поле не заполнено.
Поле заполнено пробелами.
Поле заполнено текстом с тире (например, если фамилия двойная) и так далее.

Представлены два позитивных и три негативных сценария: 1 – корректные данные, 2,4 - некорректные данные, 3 – пустые данные, 5 - неочевидный сценарий.
Первый сценарий проверяет, что отправка анкеты в принципе работает. Со второго по четвертый проверяется работа с некорректными входными данными, при вводе которых анкета не должна быть отправлена. Пятым пунктом выявляется некий неочевидный сценарий, который мог быть не учтен разработчиком. Он является наименее критичным, поэтому такого рода сценарии нужно проходить в последнюю очередь. Первые четыре разновидности входных данных обязательно должны быть протестировании. Неочевидные сценарии выполняются после проведения основных тестов при наличии времени. Количество неочевидных сценариев ничем не ограничено, но все же необходимо оценивать их адекватность - некоторые сценарии лучше согласовать с разработчиком или, если есть возможность, с конечным пользователем.

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

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

Особенности ручного функционального тестирования

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

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

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

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

Все действия тестов должны быть записаны. Написанию тестов нужно уделять достаточно внимания. Качественно составленный тест экономит время. Рассмотрим фрагмент регламентного теста "Приемочный тест почты", где максимально коротко и точно описан каждый шаг:

«Предусловия:
Установлена последняя версия "1С:Предприятия".
Установлена конфигурация "1С:Документооборот" тестируемой версии.
Включены регламентные задания для клиент-серверной версии.
Выполнен вход в систему документооборота пользователем "Фролова".
Тест проводится для клиент-серверной и файловой версии конфигурации. Редакция КОРП.

Идеальный тест не оставляет вопросов к автору или разработчику. Задача теста – помимо выявления ошибок, не позволяющих использовать функционал программы, не создавать препятствий работе тестировщика. Тест должен давать ответы и точные руководства к действиям, а не оставлять вопросы из-за неточных формулировок. Поверхностный и неточный тест - это не "возможность проверить большее количество механизмов", а почти наверняка пропуск ошибок и потеря времени на разъяснения и консультации с коллегами. В итоге получается дорого и некачественно. Точный тест дает гарантии работоспособности и не требует вмешательства других сотрудников.

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

Первичное тестирование проводится от имени пользователей с ограниченными правами: один пользователь с минимальным набором прав (учетная запись самого младшего специалиста), другой - с максимальным (руководитель подразделения/предприятия).

ВАЖНО!
Регламентные тесты проводятся только после того, как все изменения в программу уже внесены, иначе он будет неэффективным. Во время проведения регламентного теста допустимо исправление только критичных ошибок. Остальные ошибки фиксируются для исправления в следующих версиях.

Что пишут в блогах

Что такое тестирование. Курс молодого бойца (моя книга вышла!)
Расписание на декабрь
Как вырасти из тестировщика в тест-менеджера
Организация обучения джуниоров внутри команды. 2 декабря, Кострома
Автоматизация рутины. Скачиваем файлы через bash
Панбагон. 12 часов — опасное время
Оффер сразу после курса для тестировщиков с нуля. Что бывает, если выйти из зоны комфорта
Мои 12 недель в году. Часть 17 (переезд, ДР и пневмония)
Как тестировщику с небольшим опытом подготовиться и сдать экзамен ISTQB FL: интервью
Метрики в тестировании: какие выбрать и что делать, когда они становятся KPI?

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

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

Публикуем подборку докладов с конференции SQA Days 24, посвященную функциональному тестированию.

Автор: Андрей Петров

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

Аддоны к браузерам вряд ли пригодятся в автоматизации тестирования web-систем, но при ручном тестировании они могут оказаться полезны. К примеру, можно заполнять элементы на выбранной странице, исходя из своих условий и входных данных. Ниже рассмотрено создание такого аддона для Firefox и Chrome без претензий на красоту кода.

Задача: разработать аддон для Firefox и расширение для Chrome со следующей функциональностью:

1. В тулбаре появляется кнопка (иконка).
2. При нажатии на эту кнопку анализируется URL активной страницы (вкладки). Если URL – один из заранее заданных URLs, то при нажатии на кнопку тулбара скрипт берет пару “пользователь-пароль” из опций в зависимости от URL и заполняет поля ввода логина и пароля на странице. Далее скрипт нажимает кнопку логина.

Автор: Ольга Панина

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

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

Что такое «черный ящик» согласно терминологии ISTQB?

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

Автор: Джо Колантонио (Joe Colantonio)

Перевод: Ольга Алифанова

Сдвиг влево, происходящий благодаря таким процессам, как непрерывная интеграция и непрерывные релизы, приводит к растущей необходимости быстрой обратной связи от тестировщиков.

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

Прежде чем рассматривать инструменты тестирования API, давайте убедимся, что мы одинаково понимаем, что это вообще такое.

Автор: Джорис Меерц (Joris Meerts), Testing References

Перевод: Ольга Алифанова

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

Список основан на моем личном опыте тестирования программных продуктов. Я также благодарен Джеймсу Баху за эвристику SFDPOT, и Элизабет Хендриксон, Джеймсу Линдси и Дейлу Эмери, как создателям чит-листа эвристик тестирования.

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

Представляем доклад Глеба Рыбалко.

Популярность техник тестирования основанных на опыте набирает популярность с каждым годом. Скорее всего, Вы уже не найдете ни одного профессионала по тестированию и обеспечению качества, которому были бы не знакомы термины exploratory & ad hoc. Об этих видах тестирования пишутся книжки. Популярность этого направления уже дошла до того, что такое тестирование было включено в некоторые американские стандарты и предписания. Естественным образом такая ситуация отражается и на клиентах. Все чаще и чаще клиент сам приходит к Вам с инициативой внедрения исследовательского или ad hoc тестирования. И первое, что в таком случае хочется ответить это: «Да, да, конечно. Это нам поможет. Это же последние веяния. Давайте попробуем… «Но всегда ли исследовательское тестирование помогает?

Я дам несколько практических советов, которые помогут использовать данный вид тестирования на практике. Мы поговорим о следующих вещах:

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

По традиции, мы публикуем лучшие, по мнению участников, выступления с наших онлайн-конференций. Сегодня мы предлагаем ознакомиться с докладом "диверсанта", пришедшего на нашу конференцию Auto ConfeT&QA 2012 "с той стороны баррикад" -- более разработчика, чем тестировщика, Николая Алименкова. Не секрет, что разработчики тоже пишут тесты, для себя, и даже придумали специальный подход к разработке, направляемый тестами - TDD (Test-Driven Development). Николай предложил перенести эту идею с уровня модульного тестирования на уровень разработки пользовательского интерфейса. Насколько удачно это получилось -- судите сами.

Несколько дней назад завершилась онлайн-конференция Auto ConfeT&QA 2012, чуть меньше месяца остается до следующей конференции -- Chief ConfeT&QA 2012.

А тем временем мы предлагаем посмотреть рассказ Алексея Баранцева о кроссбраузерном тестировании с прошлогодней "конфетки" -- конференции ConfeT&QA 2011. Вы узнаете, где именно в работе браузеров существуют различия, почему недостаточно проверять соответствие стандартам, где взять различные версии браузеров, что следует варьировать при выполнении тестов помимо версии браузера, какими онлайн-сервисами можно пользоваться для тестирования в разных браузерах. Если вы специализируетесь на тестировании веб-приложений -- уделите полчаса своего внимания для повышения квалификации, это стоит потраченного времени.

Продолжаем публикацию слайдкастов выступлений с прошедшей конференции SQA Days 8, на очереди рассказ Игоря Любина "Тестирование компонентов без пользовательского интерфейса".

Кстати, в начале своего выступления Игорь немного рассказал о своём родном городе Казани, где пройдёт следующая конференция SQA Days 9.

Вы разработали мобильное приложение и выложили в сторы. Но почему-то в отзывах пользователи гневаются, а вы недополучаете прибыль. Как так? Где допущена ошибка? Ведь вы все продумали и записали в техзадании.
Дело в том, что пользователи могут взаимодействовать с мобильным приложением не так, как мы ожидали. Или так как мы ожидали, но результаты нас не устраивают — мы хотим лучше и больше.
Первый шаг к решению проблемы — тестирование.

[Тестирование должно сопровождать каждый этап разработки. То есть, на выходе продукт должен быть оттестирован сверху до низу. Однако не стоит думать, что после релиза о тестировании можно забыть. О, нет! Поведение живых пользователей сложно имитировать, часто они взаимодействуют с приложением непредсказуемо. Поэтому узнать о некоторых проблемах приложения можно только «в бою».]

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

Функциональное тестирование приложения

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

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

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

проверка корректности работы полей
проверка логики переходов по экранам
проверка корректности работы всех кнопок
проверка корректности взаимодействия с соцсетями
проверка поддержки транзакций через системы онлайн-оплаты
проверка корректности установки приложения и его работы на всех предусмотренных устройствах
В каждом случае нужно проверять позитивные и негативные кейсы. Кейс считается позитивным, если пользователь успешно достигает своей цели. Негативным — если на каком-то этапе приложение должно выдавать ошибку (то есть пользователь использует приложение неправильно). Ведь мы понимаем, что жизнь не сказка, и часто пользователи действуют «не по правилам».

Можно конкретный пример?
Допустим, пользователю нужно зарегистрироваться и авторизоваться в приложении. Возможны варианты авторизации с паролем и через соцсети.
Позитивный сценарий: пользователь регистрируется в системе, затем может авторизоваться любым удобным для него способом. Его данные корректно заполнены в профиле.
Негативные сценарии: пользователь пытается зарегистрироваться повторно на тот же email, хочет авторизоваться в системе с неправильным паролем.

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

Нагрузочное тестирование

Для чего нужно?
Цель — проверить, корректно ли функционирует приложение при разном количестве пользователей и при переходе из Wi-Fi в мобильную сеть. Найти участки приложения, которые могут тормозить его работу. Убедиться, что приложение не съедает всю батарею смартфона. Важность этого тестирования переоценить невозможно — если приложение не справится и начнет тормозить или вовсе вылетать, разработчики получат дозу пользовательского гнева в карму.

В чем суть?
Нагрузочное тестирование проходит в автоматическом режиме путем имитации действий нужного количества пользователей.

Как проводится?
Первый этап нагрузочного тестирования — сбор информации о системе. Нужно знать среднее и максимальное количество пользователей, нормальное и максимальное время ответа приложения и т.п.
Второй этап — создание моделей загрузки (проблемные участки можно потенциально увидеть уже тут).
Третий — собственно запуск тестов.

Конфигурационное тестирование

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

В чем суть?
Обычно перед конфигурационным тестированием готовится матрица покрытия, куда заносят все нужные конфигурации. Далее конфигурации приоретизируют и проверяют в первую очередь важные варианты. Потому как проверить функционирование и отображение на всех устройствах и при всех условиях практически невозможно — мы должны понять, чем можно пожертвовать, а лучше, как найти оптимальный компромисс. Для этого и нужны приоритеты конфигураций.
Приоритеты берутся не с потолка и не подстраиваются под возможности и интересы разработчиков, а обуславливаются нуждами конечных пользователей. Например, если мы определили, что наше кроссплатформенное приложение в подавляющем большинстве все же будут использовать владельцы смартфонов на Android — то ставим их в приоритет.
Затем поэтапно проверяем все конфигурации. Так как другие пользователи тоже хотят получить качественный продукт.

Как проводится?
Приложение тестируют в соответствии с техническим заданием:

на различных гаджетах: планшеты, смартфоны, декстоп и др.
в разных конфигурациях: типы процессора, разрешение экрана, оперативная память
на разных версиях операционных систем iOS, Android
в разных типах сети: GSM, Wi-Fi

Тестирование безопасности мобильного приложения

Для чего нужно?
Собирая данные пользователей, вы обязаны обеспечить их безопасность. Но приложение не становится безопасным от рождения, таким его делают специально. Тестирование же помогает понять, все ли мы сделали, чтобы защитить данные (и не только пользовательские) от угроз. То есть по сути, проверяется устойчивость приложения к различным угрозам безопасности: DoS-атакам, вирусам, воровству данных.

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

Как проводится?
Варианты сценариев тестирования:

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

Юзабилити-тестирование приложения

Для чего нужно?
Юзабилити — это свойство интерфейса, которое либо помогает взаимодействию пользователей с приложением, либо затрудняет его. С одним интерфейсом мы ладим легко и непринужденно — от взаимодействия с другим испытываем раздражение и не достигаем нужной цели (либо достигаем с трудом).
Тестирование помогает выяснить, как пользователи взаимодействуют с приложением. Понять заранее поведение и эмоции пользователя трудно. Даже если у вас есть здравый смысл и логика (два столпа юзабилити). Все потому что вы видите приложение иным взглядом: вам все понятно, вы давно «в теме». А вот пользователи видят его впервые.

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

Читайте также: