Способы тестирования программного обеспечения

Всем привет! Уже на следующей неделе мы запускаем новый поток по курсу «Автоматизация веб-тестирования». Этому и будет посвящен сегодняшний материал.

В этой статье рассматриваются различные способы тестирования программного обеспечения, такие как модульное тестирование (unit testing), интеграционное тестирование (integration testing), функциональное тестирование (functional testing), приемочное тестирование (acceptance testing) и т.д.

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

Тестирование: ручное или автоматизированное?

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

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

Автоматизированные тесты – это ключевой компонент непрерывной интеграции (Continuous Integration) и непрерывной доставки (continuous delivery), а также хороший способ масштабировать ваш QA процесс во время добавления нового функционала для вашего приложения. Однако в ручном тестировании все равно есть своя ценность. Поэтому в статье мы обязательно поговорим об исследовательском тестировании (exploratory testing).

Различные типы тестов

Модульные тесты считаются низкоуровневыми, близкими к исходному коду вашего приложения. Они нацелены на тестирование отдельных методов и функций внутри классов, тестирование компонентов и модулей, используемых вашей программой. Модульные тесты в целом не требуют особых затрат на автоматизацию и могут отрабатывать крайне быстро, если задействовать сервер непрерывной интеграции (continuous integration server).

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

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

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

Сквозные тесты (End-to-end tests)

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

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

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

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

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

Дымовое тестирование (Smoke testing)

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

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

Как автоматизировать тесты

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

Для автоматизации тестирования, вам для начала придется написать их на каком-то из языков программирования с использованием фреймворка для тестирования, который подойдет для вашего приложения. PHPUnit , Mocha, RSpec – это примеры фреймворков для тестирования, которые вы можете использовать для PHP, Javascript и Ruby, соответственно. В них есть множество возможностей для каждого языка, поэтому вам стоит немного позаниматься исследованием самостоятельно и проконсультироваться с сообществами разработчиков, чтобы понять, какой фреймворк подойдет вам лучше всего.

Если ваши тесты могут запускаться с помощью скриптов из терминала, вы можете автоматизировать их, использовав сервер непрерывной интеграции по типу Bamboo или же облачного сервера Bitbucket Pipelines. Эти инструменты будут мониторить ваши репозитории и исполнять наборы тестов, как только новые изменения будут запушены в основной репозиторий.

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

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

Вопрос заключается в том, надо ли вообще в таком случае проводить ручное тестирование? Короткий ответ – да, и оно должно быть сфокусировано на том, что называется «исследовательское тестирование» (exploratory testing), которое помогает выявить неочевидные ошибки.

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

Заметка о тестировании

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

И, наконец, тесты – это тоже код! Так что не забывайте о них во время code review, поскольку они могут быть последним этапом перед выпуском продукта на потребительский рынок.

По устоявшейся традиции ждем ваши комментарии и приглашаем всех на день открытых дверей, который уже 18 марта проведет наш преподаватель — ведущий автоматизатор в тестировании в Group-IB — Михаил Самойлов.

Источник

В поисках самого лучшего способа тестирования системы

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

В основе статьи – выступление Яна на июньской конференции Heisenbug 2017 в Питере. Ян занимается тестированием более двадцати лет. В настоящее время он работает тест-менеджером для приемочных тестов в голландской компании по стандартизации Squerist. Этот доклад о самых разных подходах к тестированию: от детальной проработки сценариев и до исследовательских туров, от сессионного тестирования и до поиска ошибок совместно с пользователями. Его цель – помочь вам повысить профессионализм, обратив внимание на те методы, которые вы до сих пор не использовали.

Почему существуют разные подходы к тестированию?

Я хотел бы начать с Линды Фишер. Вы ее не знаете, но более 19 лет назад я у нее проходил курсы по тестированию. Она говорила о том, что тестирование нужно делать вот так: сначала это, потом то (интерфейсы, проектирование и т.д.).

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

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

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

Гибкость в разработке преобладает над четким планированием.
Мы больше ориентируемся на мастерство, чем на методы.
Цели важнее, чем процесс. Если раньше мы следовали двухсотстраничному руководству, в котором был пошагово описан весь процесс тестирования, сегодня в этом нет необходимости. Важно смотреть, какого результата мы хотим достичь, и делать все для этого.
Быстрое тестирование преобладает над основательным. Большинство организаций хотят выйти на рынок как можно быстрее.
Прагматичные методы преобладают над стандартами. Следование стандартам может увеличить время тестирования, количество необходимой документации и требуемого персонала более чем в три раза. Поэтому даже в организациях, которые занимаются стандартизацией, часто отказываются от тестирования по стандартам.

Основные подходы к тестированию

Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).

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

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

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

Промежуточные подходы к тестированию

Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.

Почему я расположил их в таком порядке? Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.

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

Подробное сценарное и общее сценарное тестирование (Detailed Scripting & Global scripting)

В чем отличия между подробным сценарным и общим сценарным тестированием? Объясню на примере.

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

Перейдите на стартовую страницу
Нажмите на кнопку «Новый»
В поле «Кому» напишите j.cannegieter@squerist.nl
Нажмите на кнопку «Файл»
Выберите документ «Тест1»
В поле «Тема» напишите «Тестовое вложение »
Откройте почтовый ящик jcannegieter
Проверьте, доставлено ли сообщение и вложение.

Для этого же примера сценарий общего тестирования может выглядеть так:

Создайте и отправьте письмо с вложением одному получателю
Проверьте, доставлено ли сообщение и вложение

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

Сессионное тестирование и поиск багов (Session Based Testing & Bug Hunts)

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

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

Сессионное тестирование предусматривает наличие:

Сессий тестирования.
Миссии и точки тестирования / идей для тестирования.
Заметок во время сессии.
Отчета после сессии (что мы обнаружили, каково качество системы и пр.).

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

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

Исследовательское тестирование и туры (Exploratory Testing & Test Tours)

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

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

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

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

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

В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:

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

Основные различия методов тестирования и сравнение их эффективности

Сценарное тестирование	Исследовательское тестирование
Сфокусировано на подготовке	Сфокусировано на действии
Сфокусировано на планировании	Гибкое
Опирается на методы	Прагматичное
Подчиняется процессу	Ставит в центр внимания тестировщика
Сфокусировано на документации	Сфокусировано на выполнении тестов

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

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

Как решить, какой метод тестирования подходит лучше

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

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

Категория	Ситуация	Сценарное	Исследовательское
Система	Много вычислений	+
	Ориентирована на интерфейс		+
	Ориентирована на бэкенд	+
	Мобильное приложение		+
Цели тестирования	Проверка на соответствие требованиям	+
	Проверка ценности системы		+
	Юзабилити		+
	Тестирование бизнес-правил	+
	Производительность	+
	Проверка автоматизации	+
	Безопасность	+	+
Организация	Ориентирована на планирование и подготовку	+
	Энергичный современный стартап		+
	Иерархическая, традиционная	+
	Приветствует самоуправление	+	+
Документация	Много подробной документации	+	+
	Немного документации		+
	Требования / документация постоянно меняются		+
Разработка	Каскадная модель	+	+
	Agile		+
Бюджет	Большой	+	+
	Небольшой
Время	Включение в работу на ранних сроках	+	+
	Включение в работу на поздних сроках		+
	Много времени	+	+
	Мало времени		+
Навыки тестировщиков	Аналитические, скрупулезные	+
	Критическое мышление (сомневаются во всем)		+
	Гибкость		+
	Профессиональные тестировщики	+	+
	Непрофессиональные тестировщики	+	+

Вместо заключения

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

Если ваша профессиональная деятельность связана с тестированием, наверняка вас заинтересуют вот эти доклады на нашей двухдневной декабрьской конференции Heisenbug 2017 Moscow:

Источник