Сообщений в теме: 5

[Dananas]

Доброго дня всем!

Возник тут вопрос, в ходе очередной дискуссии =)

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

 

Я же утверждаю, что это далеко от реальностей и гораздо оптимальней (ну то есть быстрей, а в следствии реального бизнеса продуктивней) проверять только через пользовательский интерфейс, ибо все остальные случаи (например, вписывать некорректные значения в БД или отправлять что-то невразумительное по апи) нереальны с точки зрения естественной эксплуатации. И как только появятся свободное время, то только тогда уже можно проверить отдельно серверную часть.

 

Рассудите нас, пожалуйста, так кто же прав? =)
И как процесс тестирования в данном разрезе выглядит у вас?

[Molechka]

Если в вашей компании это далеко от реальностей — это не значит, что так везде)))

 

А серверную часть, нижний уровень, предполагается проверять также, вручную, или речь про автотесты? Или просмотр кода? Или про что?

[Freiman]

Если есть возможность проверить и автоматизировать апи - то это вообще-то очень круто :)
 

гораздо оптимальней (ну то есть быстрей, а в следствии реального бизнеса продуктивней) проверять только через пользовательский интерфейс

Крайне сомнительное утверждение. Проверять через гуй надо в первую очередь бизнес сценарии, реализованность юз-кейсов и прочее, а если есть возможность что-то проверить через апи, то как-то непрагматично не пользоваться этой возможностью :)

[DmitriyQA]

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

А вот работа с серверной частью на прямую отнесется к тестированию безопасности.

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

[Dananas]

 

 

 

А серверную часть, нижний уровень, предполагается проверять также, вручную, или речь про автотесты? Или просмотр кода? Или про что?

Да любым из способов. Все же здесь от времени зависит, ведь так?

 

А если отойти от АПИ и брать БД ? С одной стороны вписывать какие-то значение руками в БД, а проверять только то, что можно сделать через пользовательский интерфейс, а с другой вписывать какие-то значения и смотреть как это отразится в интерфейсе. Можно ли это разделить на верхний и нижний уровни?

[leftCh]

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

 

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

В БД ручками лучше не лезть, вот это реально долго и можно сделать неправильно.