Введение

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

Процесс тестирования интерфейса

Цели качества для тестирования интерфейса

• Функция
• производительность
• Безопасность
• совместимый
• Надежность
• Высокая доступность (промежуточное программное обеспечение)

Метод анализа протокола

• Мониторинг сети:
• • TcpDump
  • WireShark
• Прокси
• • Рекомендуемые инструменты: ручное тестирование. Charles Все платформы、Безопасностьтест BurpSuite Все платформы Java
  • Автоматизированное тестирование: mitmproxy
  • Другие агенты: Скрипач только Windows、AnyProxy Все платформы

Метод разработки тестового примера интерфейса

Прежде чем формально разрабатывать тестовые примеры интерфейса, вам необходимо разобраться с идеями тестирования интерфейса:

Базовое функциональное тестирование процессов

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

Тестирование на основе полей ввода

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

• Проверка граничных значений

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

• Специальная проверка символов

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

• Проверка типа параметра

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

• Требуется проверка параметров

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

• Проверка параметров комбинации

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

• Логика дедупликации

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

• Идемпотентность интерфейса

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

Тестирование безопасности потоков

Тестирование потоков безопасности включает в себя параллельное тестирование и распределенное тестирование.

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

Существует две формы распределенной реализации:

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

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

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

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

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

внесение неисправностей

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

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

Redis внесение проблемы требуют сотрудничества в целях развития и устранения Redis Данные, отправить запрос, разбивка Редис, из DB Получите из него нормальные данные и запишите их обратно в Redis середина. Затем начинается сотрудничество в целях развития Redis Функция восстановления данных, тестирование можно провести с Redis чтобы получить правильные данные. Еще нужно развиваться и сотрудничать с производством Redis Сценарий сбоя, отправьте запрос, проверьте, стоит ли переходить на более раннюю версию DB Нормальные данные получены.

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

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

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

Элементы тестового примера интерфейса

• модуль
• название теста
• приоритет
• Предварительные условия
• Метод запроса
• Параметры запроса
• ожидаемые результаты
• фактические результаты

Подвести итог

• Цели качества для тестирования интерфейса
• Метод анализа протокола
• Тестирование интерфейса, идеи дизайна вариантов использования
• Элементы тестового примера интерфейса