Обучение тестированию

Продолжаем усовершенствовать наш проект, одно из полезных навыков это перезапустить упавший тест. А если он это сделает ещё и автоматически, то будет просто прекрасно. Мы уже разобрали с 0 как настроить дополнительные методы на перезапуск, сегодня продолжим. Вернёмся сначала к данному методу. Наши тесты в дальнейшем будут всегда запускаться на удалённом сервере, который стоит на Linux. А файлы в линукс немного отличаются. Наш файл называется RebaseTestLocal.bat, на Линукс нужно другое расширение RebaseTestLocal...

Мы уже разобрали 3 метода - Post, Put, Get, остался ещё один Delete. Это 4 основных, которыми пользуются в основном все. К остальным вы сможете применять те же самые правила. Метод Delete один из самых простых. Но иногда бывают свои особенности. К примеру можно удалять по одному параметру. А можно удалять по сочетанию уникальных параметров. Поэтому нужно смотреть по ситуации. Реализовать метод Delete /testmethod/{id} В параметрах метода указывается {id} клинической рекомендации из таблицы test.testRestrictions...

Мы уже разобрали с вами методы POST и PUT, сегодня разберём метод GET. Хоть сам URL может быть тем же, поиск по параметрам можем отличаться. В данном случае мы имеем следующее ТЗ. Какие особенности есть в данном случае. У нас данные берутся из БД. Значит нет смысла искать по иным данным. Мы конечно можем попробовать, но по одной проверке. Мы можем искать как по одному параметру, так и по нескольку сразу, всё должно корректно работать. ✅Для начала давайте сверим, все ли параметры учёл разработчик...

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

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

В прошлой статье мы разобрали как можно проверить POST запрос. У нас вышло достаточно много проверок, сейчас продолжим тестировать тот же самой запрос, только теперь метод PUT. Реализовать метод PUT /testmethod/id При добавлении записи необходимо проверять наличие в таблице у текущей мо дубли по следующим параметрам: Medical+ Area + Documents Medical+ Diagnosis+ lab По условиям обычно, метод изменения не сильно отличается от метода добавления. Если у нас есть ограничение при добавлении, то при изменении это ограничение не должно ломать логику...

Я уже выпускал статью на тему какие проверки нужно осуществлять для полей ввода. Тут больше перечислены всевозможные варианты, которые можно проверить. На деле не всегда удастся ввести всё что там написано, да оно и не всегда нужно. Сейчас на примере расскажу как определять какие проверки нужно провести для API запроса. У нас есть метод, который нужен для создания записей. Это метод POST. Но также с помощью данного метода нам нужно осуществлять изменение PUT, удаление DELETE и поиск записей GET. В примере изменены названия полей, на пример они не повлияют...

Продолжаем разбирать метрики тестирования. Требования – это описание того, какие функции и при каких условиях должно выполнять приложение для решения задач, полезных для пользователя. Если на проекте есть требования, то обычно их много. Требования можно разделить на небольшие части, каждая из которых описывает определённую работу приложения. Для каждой такой части нужно создать тест-кейс, который проверит выполнение требования. Из-за большого объёма может быть сложно отследить, для какого количества требований уже созданы тест-кейсы...

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

Многим наверное интересно какие программы стоит изучить для того чтобы стать тестировщиком. Поделюсь с вами своим списком программ, которые необходимы мне как тестировщику. Стоит понимать ещё специфику своей работы, так как программы могут отличаться. Это основа основ. Это база) Без отправки запросов вообще никуда, тут каким бы профилем вы не обладали, вы всё равно полезете в эту программу. То на сколько глубоко, это уже зависит от вашей квалификации, ведь в Postman очень много удобных функций....

Продолжаем настраивать наш контур для перезапуска упавших тестов. Для чего это нужно рассказываю в прошлой статье. Мы уже добавили в прошлой статье сохранение название класса и метода нашего теста. Теперь после падения теста нам нужно чтобы он запускался повторно. Для этого напишем следующий метод. Вспомним строку запуска тестов из командной строки, она выглядит следующим образом. mvn test -Dtest="NameClass#NameMethod" Теперь нам нужно точно такую же строку сохранить в файл, только добавив название класса и метода...

Продолжаем изучат метрики в тестировании, в прошлой статье мы в целом разобрали, что это такое. Показатель покрытия кода даёт возможность определить, насколько тщательно написанный программистом код протестирован модульными или интеграционными тестами. Для вычисления показателя используется формула: T = (C / Code) ⋅ 100%, где: T — тестовое покрытие; C — количество строк кода, покрытых тестами; Code — общее количество строк кода. Для разработчиков важно регулярно писать и использовать модульные тесты, чтобы проверять корректность кода...