1. Процесс тестирования интерфейса
1. Обсуждение спроса
2. Обзор спроса
3. Дизайн сцены
4. Подготовка данных
5. Выполнение теста
2. Анализ элементов интерфейса интерфейса
1. Имя интерфейса
2. Адрес интерфейса
3. Формат поддержки
4. Метод запроса
5. Параметры запроса (название параметра, тип, обязательность, описание параметра и т.д.)
6. Возвращаемые параметры (код возврата, информация о возвращаемом значении, информация о возвращаемой строке JSON).
3. Как разработать тестовые примеры интерфейса
3.1. Зачем разрабатывать тестовые примеры
1. Уточняйте идеи и не пропускайте тесты
2. Повышение эффективности тестирования
3. Следите за ходом тестирования
4. Отразите загруженность задачи
5. Выполняйте повторяющиеся задачи
3.2 Какие аспекты следует учитывать при разработке тестовых примеров интерфейса
?
Является ли функция нормальной
Реализована ли функция в соответствии с документом интерфейса
нормальная сцена
Аномальная сцена
2. Логичный бизнес
Зависит ли это от бизнеса, например, успешен ли вход в систему
3. Аномальный тест
(1) Аномальные параметры
Аргументы по ключевым словам, пустые аргументы, много аргументов, мало аргументов, неправильные аргументы.
Охватить все обязательные параметры, объединить необязательные параметры, иметь параметры, не иметь их или иметь значение NULL, порядок, количество и тип параметров.
Размер значения типа параметра, диапазон входных значений, длина строки параметра, параметр содержит специальные символы
(2) Аномальные данные
Данные ключевого слова, пустые данные, несоответствующая длина, неверные данные
4. Безопасность
печенье
заголовок
уникальный идентификатор
4. Распространенные методы покрытия тестовых сценариев интерфейса
1. Требуемый охват параметров
Что касается параметров интерфейса, в документе интерфейса обычно объясняется, какие из них необходимы, а какие нет.
Для необходимых параметров обязательно проверьте, работает ли интерфейс, который передает параметры и не сообщает об ошибках.
2. Параметры должны учитываться в различных ситуациях.
Недопустимые символы, специальные символы, нулевые значения и параметры, выходящие за границы, будут регистрироваться как ошибки? Правильно ли сообщение об ошибке?
3. Охват несущественных параметров
Как правило, интерфейс не определяет, были ли несущественные параметры переданы ненормально, поэтому необходимо проверить допустимое значение параметра и правильность содержимого, возвращаемого интерфейсом.
Если существует документ интерфейса, в котором указано, что необязательные параметры были проверены ненормально, их также следует проверить.
4. Охват комбинаций параметров
Для работы некоторых параметров необходимо взаимодействие друг с другом. Например, «смещение» и «счетчик» объединяются для перелистывания страниц. На данный момент их необходимо объединить для тестирования.
5. Охват, связанный с бизнес-логикой
Некоторые интерфейсы тесно связаны с бизнес-логикой, и тестирование только с точки зрения интерфейсов может пропустить некоторые ошибки, вызванные бизнес-логикой.
Поэтому, если это связано с бизнес-логикой, следует также рассмотреть тестовые примеры, связанные с бизнес-логикой.
Пять, приоритет интерфейса тестирования интерфейса
1. Приоритет – для всех интерфейсов
(1) Интерфейс открыт снаружи, поскольку обычно интерфейс вызывается третьей стороной.
(2) Основной функциональный интерфейс для внутреннего вызова системы.
(3) Чтобы система могла вызывать внутренние интерфейсы неосновных функций.
2. Приоритет – для одного интерфейса
(1) Сначала тестируются прямые варианты использования, а затем обратные варианты использования (обычно не абсолютные).
(2) Соблюдаются ли предварительные условия > Переносить ли параметры по умолчанию > Требуются ли параметры > Существует ли связь между параметрами > Ограничения типа данных параметра > Ограничения диапазона данных самого типа данных параметра
6. Анализ дизайнерских идей тестирования интерфейсов
1. Выполнены ли предпосылки
Некоторые API должны соответствовать предварительным условиям для успешного получения данных. Как обычно, вам необходимо войти в систему Token.
Обратный вариант использования:
Разработайте 0–n вариантов использования для определения того, выполняются ли предварительные условия (предполагается, что это n условий).
2. Переносить ли параметры значений по умолчанию.
Вариант использования вперед:
Параметры со значениями по умолчанию не заполняются и не передаются. Обязательные параметры заполняются правильными и существующими «обычными» значениями. Остальные не заполняются, и разрабатываются положительные варианты использования.
3. Бизнес-правила и функциональные требования
В зависимости от реальной ситуации и описания параметров интерфейса может потребоваться разработать n вариантов прямого и обратного использования.
4. Является ли параметр обязательным?
Обратный вариант использования:
Для каждого обязательного параметра разработайте обратный вариант использования с пустым значением параметра.
5. Есть ли связь между параметрами
Некоторые параметры имеют взаимную ограничительную связь друг с другом.
Обратный вариант использования:
В зависимости от реальной ситуации может потребоваться разработать 0–n вариантов использования.
6. Ограничения типа данных параметра
Обратный вариант использования:
Для каждого параметра разработайте обратный вариант использования, в котором тип значения параметра не соответствует.
7. Ограничение диапазона данных самого типа данных параметра.
Вариант использования вперед:
Для всех параметров разработайте позитивный вариант использования, в котором значение каждого параметра является максимальным значением в диапазоне данных.
Обратный вариант использования:
Для каждого параметра (при условии, что n) разработайте n обратных вариантов использования, в которых значение каждого параметра превышает максимальное значение диапазона данных.
Для каждого параметра (при условии, что n) разработайте n обратных вариантов использования, в которых значение каждого параметра меньше минимального значения диапазона данных.
Подведем итог:
Если принять во внимание вышеуказанные аспекты, то в основном можно охватить следующие аспекты:
(1) Тестовый пример основного процесса: обычная проверка функции основного процесса.
(2) Тестовый пример ответвленного потока: проверка нормальной функции ответвленного потока
(3) Тестовый случай аномального расхода: проверка устойчивости к аномальным отказам.
7. Сравнение возвращаемых результатов тестов интерфейса.
Цель:
Код подтверждения в порядке
Код подтверждения верен
1. Сравните код возврата
2. Сравнить целостность возвращаемого значения, т. е. возвращенный ключ является неполным.
3. Сравните тип данных значения ключа.
4. Сравните значение, соответствующее ключу (включая проверку значения бизнес-данных).
В заключение хочу поблагодарить всех, кто внимательно прочитал мою статью.Взаимность всегда необходима.Хоть это и не очень ценная вещь, но при необходимости ее можно забрать:
Апплет для собеседования по тестированию программного обеспечения
Банк вопросов для тестирования программного обеспечения заполнен миллионами людей! ! ! Кто есть кто знает! ! ! Самая полная мини-программа-викторина во всей сети. Вы можете использовать свой мобильный телефон для выполнения викторин в метро или автобусе, сверните его!
Охвачены следующие разделы вопросов интервью:
1. Базовая теория тестирования программного обеспечения, 2. Интернет, приложение, тестирование функций интерфейса, 3. сеть, 4. база данных, 5. Linux
6. Интернет, приложения, автоматизация интерфейса, 7. Тестирование производительности, 8. Основы программирования, 9. Вопросы для собеседования с персоналом, 10. Вопросы открытого теста, 11. Тестирование безопасности, 12. Основы работы с компьютером
Эти материалы должны стать наиболее полным и полным складом подготовки для друзей [по тестированию программного обеспечения].Этот склад также сопровождал десятки тысяч инженеров-тестировщиков в самом трудном путешествии.Надеюсь, он поможет и вам!