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

Тестирование программного обеспечения может показаться сложной и бесконечной задачей. Как тестировщики, мы быстро понимаем, что невозможно протестировать каждый сценарий, каждый уголок приложения и выявить все дефекты. Я работал над приложениями, которые сильно различаются по сложности. Некоторые приложения просты: их функции настроены, и каждый пользователь использует их как есть. Например, приложение, которое показывает информацию о вашем рейсе на мониторах у выхода на посадку. Другие приложения имеют ограниченную пользовательскую базу и созданы для целевой аудитории, что позволяет при тестировании оттачивать меньшее количество пользователей. Эти приложения встречаются чаще. Однако наиболее распространенные из них имеют сложную базу пользователей: все. Подумайте об интернет-магазинах Facebook, Twitter, Target или Best Buy, приложениях для мобильного банкинга и (барабанная дробь для этой истории) приложениях для онлайн-регистрации авиакомпаний.

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

Подумайте о розничном торговце, таком как Target, Best Buy или Walmart. Эти розничные торговцы продают тысячи товаров. Некоторые товары, например одежда, бывают разных размеров и цветов. Для некоторых требуются дополнительные элементы (например, ноутбук с установленной Windows). Эти компании также предлагают услуги и гарантийные планы. Объедините их с пользовательской базой всех, кто делает покупки в Интернете, и то, как выглядит онлайн-заказ, будет сильно отличаться. У вас есть заказы на самовывоз из магазина, заказы на доставку, а теперь с COVID - самовывоз у обочины. Есть подписки и предварительные заказы, которые нужно учитывать. Несмотря на разнообразие данных здесь, варианты, с которыми они имеют дело, являются частью самой системы, а не обязательно ее пользовательской базой. Если вы отправляетесь разместить заказ, вы добавляете товары в корзину и выбираете варианты выполнения в пределах определенных границ их системы.

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

Наконец, реальный пример проблемы, с которой столкнулась моя команда: не одна, не две, а три крупные авиакомпании объединили свои усилия, чтобы обеспечить беспрепятственную регистрацию и создание посадочных талонов для пассажиров. Наша клиентская база: любой пассажир любой из этих авиакомпаний, следующий в пункт назначения одной авиакомпании или из пункта назначения другой, с любым количеством остановок между ними. Аккуратный! Теперь любой путешественник в мире может стать одним из наших пользователей. Любая авиакомпания, в любой части своей системы, сталкивается со сложными проблемами с данными о пассажирах. Как пассажир, я могу самостоятельно забронировать внутренний рейс в одну сторону из пункта отправления A в пункт назначения B. Отлично. Простой. За исключением… нет, потому что, если вы когда-либо путешествовали по воздуху, у вас, скорее всего, был другой маршрут, чем я только что описал.

Проблема с данными

Один пассажир, два пассажира, 7 пассажиров. 9 и более пассажиров. Групповое путешествие. Поездки на одном сегменте (от точки A до B). Обзорные экскурсии. Подключения! Внутренние рейсы, международные рейсы. Путешествие с супругом и младенцем из Канады, за бабушкой во Флориде, продолжение поездки в Мексику. Едем в Европу на 6 месяцев! Путешествие в страны и из стран, которым требуется виза. Корпоративные поездки. Право на обновление! Право на повышение класса обслуживания, когда вашего попутчика нет! Повышение класса обслуживания до Первого класса :) Отказ от повышения класса обслуживания :( Быть членом клуба миль (или нет). Путешествовать в качестве несовершеннолетнего без сопровождения. Путешествуя с аллергией на арахис, инвалидной коляской, нарушением зрения. Проверять свои сумки. Не проверять свои сумки. специальный пункт. Отправляясь в рейс в аэропорту, который требует более ранней регистрации на рейс после регистрации багажа. Оплата милями, оплата кредитной картой, оплата сертификатом вознаграждения. Путешествие в основном салоне, или в комфортном, или в первом салоне, или …

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

Вы не можете проверить все

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

Нетрадиционное использование автоматизации тестирования

Любой в индустрии программного обеспечения мог представить, что у нас были жесткие установленные сроки для этого проекта. Координация с двумя другими авиакомпаниями означала, что мы должны были быстро реагировать на изменения и всегда обеспечивать качество наших API-интерфейсов на уровне наших (и их) стандартов. Мы потратили время и усилия на создание настраиваемой среды автоматизации (JavaScript, Mocha и Chai), которая позволила нам действительно управлять данными тестовых сценариев и связывать вместе наши запросы API в модульном режиме, имитируя реальное поведение приложения при сохранении наших тестов. ремонтопригодный. Как упоминалось выше, наши самые распространенные пользовательские сценарии стали нашими базовыми автоматическими тестами - нашим традиционным подходом к автоматизации.

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

Мы знаем, что для большинства * наших миллиардов различных пользовательских сценариев это правда: каждый пассажир должен пройти регистрацию на свой рейс и получить посадочный талон. Точно так же для любой международной поездки каждый пассажир должен предоставить свои проездные документы, зарегистрироваться и получить посадочный документ. Модульный подход нашей платформы автоматизации означал, что мы могли очень легко создавать вышеупомянутые сценарии для любого количества сценариев, которые мы хотели протестировать - я говорю о ~ 5 минутах усилий. Мы используем данные для наших тестов из простого CSV-файла, предоставляя указатель записи и город отправления для поиска поездки. Итак, я создал эти базовые тесты (регистрация, получение посадочного талона), в которые мы вводили случайно полученные тестовые данные и просто смотрели, что происходит!

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

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

Подробнее об этом проекте в новостном центре Delta.