Проектирование и управление сценариями интеграционного тестирования

1. Введение

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

В этом проекте я занимал должность QA, где я писал сценарии интеграционного тестирования на основе документа о требованиях и выполнял и управлял ими на трех этапах: разработка (dev), тестирование (stg) и продакшн (prod). В этом процессе я в конечном итоге создал и управлял документом интеграционного тестирования, состоящим из 71 тестового сценария (TS) и 376 детализированных тестовых случаев (TC).

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

2. Предпосылки необходимости проектирования сценариев интеграционного тестирования

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

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

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

3. Как структурировать документ о требованиях в тестовые сценарии

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

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

Второй уровень — это тестовый случай (TC). TC относится к отдельным условиям, которые необходимо проверить в рамках сценария. В случае вышеупомянутого сценария 'Согласие с условиями и проверка личности' под ним будет несколько случаев, таких как обработка случаев, когда имя не введено, обработка случаев, когда формат номера телефона неверен, и обработка случаев, когда номер подтверждения не совпадает.

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

4. Классификация по двум осям: цель и функциональная область

С увеличением количества сценариев и случаев управление ими в простом списочном формате становится трудным. Для эффективного управления 71 сценариями и 376 случаями всем случаям были назначены две оси классификации.

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

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

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

5. Производство исключительных случаев, выходящих за рамки Happy Path

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

• Обязательная проверка значений: Попытка перейти к следующему шагу, когда требуемый элемент ввода пустой

• Проверка формата: Ввод значения, отклоняющегося от заданного формата (количество цифр, разрешенные символы и т. д.)

• Проверка на основе состояния: Случаи, когда уже существует существующее или повторяющееся состояние или когда значения не соответствуют друг другу

• Проверка на основе политики: Случаи, когда поток изменяется из-за политик, таких как превышение временных лимитов или лимитов попыток

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

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

6. Стратегия тестирования для сред разработки, промежуточной и производственной

Написанные сценарии выполнялись в три этапа: разработка (dev), промежуточная (stg) и производственная (prod). Поскольку цели этих трех сред различались, даже при одинаковом случае подход к верификации изменялся в зависимости от среды.

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

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

7. Принципы записи результатов тестирования

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

Для случаев, зарегистрированных как ОТМЕНЕНО и ЗАБЛОКИРОВАНО, мы всегда оставляли конкретную причину в разделе замечаний. Например, было подтверждено, что конкретная функция уведомлений не может гарантировать точные результаты, если прием уведомлений и вызов API запроса из внешней системы обрабатываются как одна транзакция. Поэтому мы решили разделить логику и повторно проверить ее позже. Классифицируя это как ЗАБЛОКИРОВАНО, а не просто оставляя как 'неуспешно' и записывая причину и условия повторной проверки вместе, мы смогли точно найти и повторно выполнить этот случай, когда логика была позже разделена.

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

8. Принципы управления идентификаторами (ID) в сценарных документах

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

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

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

9. Результаты применения и отражение

Основываясь на вышеизложенных принципах, мы завершили документ интеграционного тестирования, состоящий из 71 сценария и 376 тестов, и выполнили их последовательно в средах разработки, тестирования и эксплуатации. Большинство случаев прошли нормально, в то время как некоторые были классифицированы как ОТМЕНЕНО или ЗАБЛОКИРОВАНО из-за интеграции с внешними системами или ограничений окружения и остаются под отдельным управлением.

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

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

eunice