Я увидел такой вопрос: необходимо ли при автоматическом тестировании интерфейса проверять каждое поле, возвращаемое интерфейсом?

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

В этой статье я расскажу о своем понимании утверждений и о том, как их подтверждают автоматические тесты.

1. Что такое утверждение?

Позвольте мне сначала поговорить о моем понимании утверждений.

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

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

Метод утверждения здесь можно понимать как ручную оценку правильности результатов теста путем сравнения.

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

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

Так называемое утверждение — это средство оценки результата, то есть способ оценить, является ли результат «да» или «нет».

2. Зачем устанавливать утверждение?

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

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

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

Если взять в качестве примера тестирование интерфейса, то хороший дизайн утверждений может принести следующие преимущества:

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

3. Некоторые недопонимания относительно установки утверждений

Когда многие новички впервые приступают к тестированию интерфейса или автоматическому тестированию, наиболее распространенной ошибкой является не установка утверждений или объектом утверждения является код состояния HTTP. Почему бы вам не пропагандировать и не рекомендовать использовать коды состояния HTTP в качестве объектов утверждений? Причины заключаются в следующем:

Прежде всего, сам HTTP-запрос не имеет состояния. Код состояния HTTP лишь выражает статус обработки текущего запроса и не имеет никакого отношения к тому, правильно ли выполнено дело или нет. Например, когда появляется код состояния 404, возможно, проблем с самой запрошенной услугой нет, но URL-адрес вашего запроса неверен.

Во-вторых, код состояния HTTP представляет только статус самого текущего запроса. Например, код состояния 200 означает, что запрос выполнен успешно. Сервер получил ваш запрос и успешно вернул данные ответа, но это не означает, что все в порядке (код состояния HTTP для неудавшихся заказов также равен 200, но это не значит, что все в порядке). с точки зрения бизнеса это провал).

4. Как настроить тестовые утверждения?

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

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

Проверка значения ключа：Различные в зависимости от бизнес-сценариев,может целенаправленно проверять определенные key-value Соответствуют ли результаты пары ключ-значение ожиданиям, дополняется комплексной проверкой путем запроса к базе данных подтверждения ввода данных.

Например: предположим, что бизнес-сценарий заключается в создании заказа. Если создание прошло успешно, в ответном сообщении помимо кода состояния HTTP 200 необходимо указать код состояния бизнеса (статус успеха = 0). Аналогично, если создание завершается неудачно, статус успеха кода бизнес-статуса = 1.

сделать это,есть дваОграничивающие факторы: 1. Проверка знаний студентов о бизнесе. 2. При проектировании интерфейса необходимо заранее определить различные коды статуса бизнеса для различных результатов бизнес-сценариев.。

Другие виды проверки：Если возвращаемые данные необходимы, они не требуются.,Проверка разрешений на доступ к URL (авторизация) и т. д.

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