Всем привет! Я старший преподаватель направления функционального тестирования в «ЛАНИТ Экспертиза». К нам в штат приходят люди из разных профессий и с разным уровнем знаний. Поэтому в компании организованы курсы обучения практикам тестирования, которые уже стали базовыми. Одной из них является тестирование с помощью API запросов, или, как его еще называют, тестирование API. И сегодня для тех, кто этим занимается, я постараюсь доступным языком рассказать, как использовать этот формат для описания тестовых данных, подключаемых к прогонам коллекций в Postman.
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
Ранее я упоминала, что специально использую UI, дабы обозначить, что он должен находиться на вершине тест-пирамиды, в то время как в других случаях вершина называется E2E. Чувствую, надо подробнее это объяснить.
UI – это пользовательский интерфейс. UI-тестирование относится к тестированию, выполняемому через UI.
E2E – это end-to-end тестирование. Это тесты, которые выполняются от входной точки в приложения до выхода из него.
UI одавляющего большинства приложений дает и входную, и выходную точки, которые затем частично формируют E2E, и поэтому UI-тесты и E2E-тесты иногда используются, как эквивалентные термины.
Здравствуйте. У меня есть софт который бывает несовместим с отдельными обновлениями Windows. Когда клиент с этим сталкивается, он присылает баг-репорт и systeminfo.
Из systeminfo я беру ОС, билд и установленные апдейты.
Для воспроизведения багов хочу сделать следующее. Поднять виртуальную машину с той же версией/билдом Windows что и у клиента, и точечно поставить апдейты которые установлены у него.
Образы винды я ещё могу найти, а вот с отдельными апдейтами проблема.
Как я могу скачать все апрейты, например, на Windows 10, чтоб просто закинуть их в отдельную директорию которую я буду шарить между VM?
Тестирование API — неизменная задача при разработке продуктов. Проблема, с которой сталкиваются многие компании, — большой ручной регресс. Появляется автоматизация, но покрытие огромного количества API‑методов требует ресурсов, которых часто нет. Кроме того, в большинстве случаев написание API‑тестов — монотонная работа, которой никто не любит заниматься. Как решить эти проблемы?
Меня зовут Елизавета Андреева. Я инженер по автоматизации тестирования в ОК.Tech. Мы с коллегами в ОК разработали и внедрили автогенерацию API‑тестов, благодаря которой мы сокращаем ручную работу и время на написание однотипных автотестов, оставляем QA‑инженерам для покрытия только кейсы на бизнес логику. И в этой статье (которая станет первой в серии из двух частей) я начну рассказ о том, как мы реализовали наш генератор и каких результатов нам удалось достичь.
Автор: Джулиан Харти (Julian Harty) Оригинал статьи Перевод: Ольга Алифанова
Когда я приступил к задаче тестирования Kafka, то осознал, что мне нужно вникнуть во множество тем. В ходе работы над задачей я выкроил время на активное изучение этих тем, а также дополнительных, вскрывшихся в ходе работы – например, AWS.
Эта статья описывает эти темы. Я не буду детально вдаваться в них (возможно, напишу про них позже) – вместо этого сконцентрируюсь на том, как я учился в ходе этого проекта.