Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Это завершающие заметки к серии статей про исследовательское тестирование API.

Исследовательское тестирование API, часть 3

Исследовательское тестирование API, часть 2

Исследовательское тестирование API, часть 1

Давайте вернемся к исходному вопросу:

Тестируете ли вы API исследовательским методом? Как?

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

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

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

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

Тестирование через API – исследовательское тестирование, потому что исследовательское тестирование и есть, по сути, тестирование. (Исследовательское) тестирование – это не просто "вести себя как пользователь", "тестировать без инструментов", это не просто "техника ручного тестирования".

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

Инструменты играют в тестировании важную роль. Мы используем их, чтобы расширить, улучшить, сделать возможным, ускорить и усилить наше тестирование. Инструменты важны и в программировании, но никто не говорит о "ручном программировании", никто не называет компилирование "автоматизированным программированием". Компилирование – это то, что делает машина, это перевод одного набора строк (исходный код) в другой набор строк (машинный код). Это, конечно, не умаляет роли компилятора и авторов компиляторов: создание сложного компилятора – это задача для очень опытного программиста.

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

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

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

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

Когда проверки написаны, их легко повторить, особенно с целью выявить регрессии, однако будьте осторожны. В Rapid Software Testing регрессионное тестирование – это не просто повторный прогон проверок. Для нас регресс означает тестирование, сконцентрированное на связанным с переменами риском, "дорогу назад" (это то, что означает "регресс" – это антоним "прогресса").

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

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

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

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

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

Питер Хутон (Peter Houghton) как-то привел мне элегантный пример использования проверок в исследовании. Имея под рукой API для компонента, он создает простой скрипт, который вызывает одну и ту же функцию тысячи раз по кругу и замеряет время, которое занял процесс. Периодически он заново запускает скрипт и сравнивает время с первым прогоном. Если он видит значительные перемены во времени, он исследуте вопрос. Два раза из четырех, по его словам, он находит баг.

Подведем итоги: все тестирование – исследовательское. Исследованию помогают инструменты, а автоматизированные проверки – это подход к использованию инструментов. Исследование неизвестного и обнаружение новых знаний очень важны для исследовательского подхода. Чтобы найти баги, мы должны исследовать. Любое тестирование API – исследовательское..

Обсудить в форуме