Я уже выпускал статью на тему какие проверки нужно осуществлять для полей ввода.
Тут больше перечислены всевозможные варианты, которые можно проверить. На деле не всегда удастся ввести всё что там написано, да оно и не всегда нужно. Сейчас на примере расскажу как определять какие проверки нужно провести для API запроса.
Для начала смотрим ТЗ
У нас есть метод, который нужен для создания записей. Это метод POST. Но также с помощью данного метода нам нужно осуществлять изменение PUT, удаление DELETE и поиск записей GET.
В примере изменены названия полей, на пример они не повлияют.
Реализовать метод POST /testmethod
Который содержит:
- "Medical" - Медицинская организация, которая устанавливает список обязательных услуг из справочника test.medical.id (varchar, обязательный, запись в test.testRestrictions.Mo.
- "Code" - Код услуги из справочника test.medicalcode.code (varchar, обязательный, запись в test.testRestrictions.code)
- "Area" - Анатомическая область из справочника test.anatom.id(varchar, обязательный, запись в test.testRestrictions.area)
- "Documents" - Перечень видов документов (ключ, внутри которого передаётся массив значений varchar, условно обязательный, запись в test.testRestrictions.doc) Передаётся значение поля test.documents.id.
- "Diagnosis" - Код диагноза из справочника test.diagnosis.id, (varchar, не обязательный, запись в test.testRestrictions.diagnosis)
- "lab" - Лабораторный тест из справочника (varchar, обязательный при указании Diagnosis, запись в test.testRestrictions.diagnosis)
- "Value" - Пороговое значение (numeric, обязательный при указании lab, запись в test.testRestrictions.value)
При добавлении записи необходимо проверять наличие в таблице у текущей мо дубли по следующим параметрам:
Medical+ Area + Documents
Medical+ Diagnosis+ lab
Это наше ТЗ из которого мы можем сделать вывод:
- Метод запроса выглядит следующим образом - https://testMethod.ru/testmethod
- Данные добавляются в таблицу test.testRestrictions
- Есть обязательные и необязательные поля
- Есть проверка на уже существующие записи в БД по сочетанию параметров
- Некоторые значения имеют первичный ключ из других таблиц (означает, что мы не сможем в эти поля прописывать данные от балды)
- Итоговое тело запроса выглядит так:
{
"Medical": 1,
"Code": "A.00",
"Area": 1,
"Documents": [
"1", "2", "3"
],
"Diagnosis": "00",
"lab": "1",
"Value": 1
}
Давайте начинать тестировать.
Проверки для POST запроса
✅Для начала как и со свеми другими проверками, нужно отправить валидные данные и убедиться что данные добавились в таблицу test.testRestrictions.
🔵 1 проверка.
Результат: данные добавились
✅В некоторых случаях у поля есть только несколько верных значения, например 3. Нужно проверить их все.
🔵 0 проверок, у нас такого нет.
Результат: данные добавились только с допустимыми параметрами
✅Сейчас также проверим обязательность полей . Мы можем отправить данные без необязательных и не можем без обязательных.
Тут важно уточнение, нужно проверить как отсутствие параметра в целом, так и его нулевое значение, например:
"Diagnosis": null
В коде может быть разные варианты обработки отсутствующего поля, если его не отправить, то будет ошибка, а если отправить в нём null то всё ок. Как итог поле не будет всё равно заполнено в БД, но ошибки при отправке у нас нет.
У нас есть поля, обязательность которых, зависит от других полей. К примеру поле lab зависит от Diagnosis. Если укажем только Diagnosis без lab, то должна быть валидная ошибка.
🔵 1 проверка - без Documents, Diagnosis, lab, Value
🔵 1 проверка - с Diagnosis, но без lab
🔵 1 проверка - с lab, но без Value
🔵 1 проверка - с Value, но без Diagnosis и lab
🔵 1 проверка - без Medical
🔵 1 проверка - без MedicalCode
🔵 1 проверка - без Area
Результат: результаты должны совпадать с ожидаемым результатом. Не должно быть ошибок в логике обязательности полей.
✅Всё также проверяем, но теперь не убираем поле, а прописываем в нём null.
🔵 7 проверок.
Результат: сервер умеет реагировать как и на отсутствие поля, так и на значение null.
✅Проверяем сочетание уникальных параметров. После их отправки, повторно те же самые параметры мы отправить не сможем. Должна быть ошибка.
🔵 1 проверка - отправили Medical+ Area + Documents
🔵 1 проверка - отправили ещё раз Medical+ Area + Documents
🔵 1 проверка - отправили Medical+ Diagnosis+ lab
🔵 1 проверка - отправили ещё раз Medical+ Diagnosis+ lab
Результат: ошибка на уникальность параметров.
✅Проверяем ввод значений в поля. Поля Medical, Code, Area, Documents, lab берут значения из других таблиц, так что если написать значение не из них, то сразу будет ошибка.
🔵 5 проверки.
Результат: такого то значения не существует для поля.
В целом не особо имеет смысл прописывать какие нибудь символы для полей выше. Но для подстраховки можете указать какие нибудь
✅Ввод символов
🔵 5 проверки.
Результат: такого то значения не существует для поля.
✅Вводим пробелы, верхний/нижний регистр, тире
Бывает такое, что в коде не сделали зависимость от регистра - это ошибка. Ведь значение для параметра "A00" и "а00" это разные значения, а для кода без разницы.
То же самое и для пробела и тире.
🔵 5 проверки.
Результат: ошибка на пробел вначале/конце, на регистр (если значение в БД значение в верхнем регистре, то нижний не принимает), тире также нужно обработать, если в значении есть тире то его нужно спокойно принимать.
✅Можно ещё добавить проверку на попробовать ввести вместо String Integer и наоборот.
С этим также может быть связана проблема. В коде может стоять какая нибудь проверка, например 1 и "1" - число то введено верно, но ошибка будет потому что это разные типы. Поэтому в запросе не должно проходить другого типа значения.
🔵 7 проверки.
Результат: такого то значения не существует для поля.
✅Для убедительности можно проверить ввод спец знаков, в полях со String значениями.
К примеру вы можете написать - [\"[|]'~<!--@/*$%^&#*/()?>,.*'/]
Или можно прописать - [<script>alert(\"I hacked this!\")</script>]
Суть такой проверки, что сервер не принимает просто строку, не заглядывая и не пытаясь выполнить какие либо команды внутри строки. Иными словами ему все равно, что вы передадите в строку, он должен просто принять её как есть. Если он выполняет команду из неё, тогда проблемы.
🔵 4 проверки.
Результат: если нет валидации на значение в поле, то просто принимает String.
В итоге мы провели следующие проверки:
- Валидная отправка значений
- Отправка только допустимых значений, если их немного (по ситуации)
- Отправить без необязательных полей
- Отправить в необязательных полях null
- Отправить без обязательных полей
- Отправить в обязательных полях null
- Проверка обязательности полей, которые зависят от других полей
- Проверка уникальности сочетания параметров
- Проверка не валидных значений, которые берутся из таблиц в БД
- Ввод символов, пробелов, тире, верхний/нижний регистр.
- Ввод вместо String Integer
- Ввод спец символов.
И того примерно у нас получилось, что для проверки POST запроса, мы его отправили 45 раз.
Мы проверили все проверки, которые покрывают полный функционал данного метода. Если думаете, что упустил какие то, то обязательно пишите в комментариях, что ещё нужно проверить.
В следующей статье разберём остальные методы PUT, DELETE и GET.
Если у вас есть вопросы или вы просто хотите стать частью команды тестировщиков, то переходи в ТГ канал, где можем пообщаться с единомышленниками и найти много интересных и полезных знаний! Также если вам нужна индивидуальная консультация, менторство и помощь в создании проекта пишите в ТГ канал!
