Ответы пользователя по тегу Тестирование ПО
  • Как именовать интеграционные тесты?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Вынес комментарии в отдельный ответ.
    "например сценарий выдачи книг читателю на абонемент. "

    Делите тесты на 3 группы
    Позитивные: где успешно выдается книга / несколько книг на разные сроки
    Негативные: все перечисленные ваши + отказы бд, сервисов, пустой ответ и т.д.
    Валидация: где запросы на выдачу составлены неправильно, не переданы аргументы и т.д.
    в таких случаях не должно быть изменений в базе.

    Пример нейминга
    rentBook_negative_cases:
    -rentedByOtherCustomer
    -cannotRentAgeStrictedBook (также в позитивные идет кейс когда можем выдать эту книгу)
    -bookRentOverlimit
    Ответ написан
    Комментировать
  • Каким инструментом можно подменить url при открытии ссылки в браузере?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Если вдруг пишете автотесты на ui (selenium например) - то можно прям в коде автотеста нажать ссылку, взять адрес из строки браузера и поменяв хост открыть новую ссылку.
    Ответ написан
    Комментировать
  • Как в jest протестировать метод в классе, который вызывается по условию?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Инициализировать объект класса с включенным условием?
    Ответ написан
    Комментировать
  • В чём разница между е2е и Unit тестами?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    unit test - тест одного модуля
    е2е - end to end - тест с заданными рамками

    юниты обычно лежат рядом с самими модулями (в golang например client.go и client_test.go рядом - это норм)
    а е2е помещаются в отдельную папку test в которой помимо этих е2е всякие helpers и клиенты к вспомогательным сервисам)

    и запускаются юниты перед сборкой, а e2e после нее
    Ответ написан
    Комментировать
  • Как передать фикстуру в параметры теста pytest?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Мне непонятно :)
    Фикстура - это вроде подготовленные объекты, которые можно использовать. Фикстурой может быть как запрос так и объект, который возвращается в этом запросе.

    Абстрагируемся от фикстур. Тестируется API? Позвольте перефразирую ваш вопрос.
    Первый метод возвращает список сущностей GET /items -> response {items: [{obj},{obj},{obj}]} (так?)
    А второй отдает инфу о конкретном obj по его id например GET /item?id=1 -> response {obj}
    тогда мы можем взять items из первого и пробежаться по массиву, вызвав для каждого элемента второй метод
    псевдокод:
    response = GET("/items")
    items = response.body.items
    for i, element in items {
    response = GET("/item", id=element.id)
    assert.equal(response.id, element[i].id) 
    }


    много зависит от реализации api, но чаще всего именно так
    Ответ написан
    Комментировать
  • Как начать автоматизацию на android?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Вы когда вручную тестили - мобилу же тестили?
    Вот там куча кейсов, которые вообщем можно отнести в 3 категории:

    -Отрисовка элементов интерфейса, доступность кнопочек и вьюшек
    -Взаимодействие c сервером
    -Обработка технических ошибок (нет связи, проблема с памятью в телефоне и т.д.)

    Автотесты элементов - с использованием Selenium-like фреймворков (вроде Appium), эмуляцией или использованием реального устройства

    Взаимодействие с сервером - берете проект в Android studio, добавляете тесты на api (retrofit фреймворк или что - то подобное)
    Обработка технических ошибок - тут я не знаю, возможно это надо проверять вручную при крупных релизах.

    Автоматизация нужна не просто "потому-что", а вполне для конкретной цели, иначе это будет бесполезная работа. Обозначьте проблемы, которые вы решаете с ее помощью.
    По языкам: kotlin, Java
    Ответ написан
  • Как вы тестируете кейсы когда у вас много разных пользователей?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Вы вручную засовываете токен в local storage?
    Вопрос немного непонятный, но попробую парочку заметок накидать:
    -В книгах по тестированию упоминается pairwise testing, в вашем результате можно сократить чеклист для каждого браузера (поясню, например нет необходимости тестить некоторые пункты одновременно в инкогнито и без)
    Вместо изнурительного прогона всех тестов для всех браузеров можно из регресса выделить "основную" часть, которую прогонять полностью на всех и "дополнительную", которая имеет меньший приоритет/критичность, и эту секцию поделить между клиентами.

    Описал сумбурно, попробую накидать пример:
    Чеклист онлайн-банка: (в скобках наличие большого количества js и подстройки (adapt) под конкретные браузеры в http api)
    Авторизация (adapt)
    Главная (js, adapt)
    Платеж (js)
    Перевод
    Налоги / справки (js, adapt)
    Список операций (js)
    Управление услугами
    Управление безопасностью (adapt)

    секции с adapt / js и критичные секции (которые также могут входить в смок чеклист) проверяем на всех шести клиентах (3 браузера в инкогнито и без)
    секции только с одним js или adapt проверяем только на разных браузерах (то есть 3 прогона)
    секции без js и adapt делим между неинкогнито вариантами трех браузеров (Перевод проверяем в хроме, управление услугами в firefox и т.д.)
    таким образом мы существенно сократим количество проверок без особо ущерба покрытию

    конечно это сугубо синтетический пример, в реальности надо подстраиваться под кучу других условий

    p.s. надеюсь без поллитра кто - нибудь почерпнет полезное из моей писанины
    p.p.s а лучше вкорячить автотесты на апи и автоматизировать проверку верстки / переходов автотестами на ui, там хоть двадцать браузеров вкорячить можно без просадки по затратам)
    Ответ написан
  • Практическое руководство к написанию тестов?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Начать стоит с вопроса "что тестировать?"(то есть про тест-дизайн)
    и закончить вопросом "как тестировать"(технологии)

    Условно выделите ключевой функционал вашего приложения.

    например если это блог, то краткий чеклист по категориям примерно такой:

    Пользователи:
    Регистрация
    Авторизация
    Смена пароля / восстановление

    Социальная часть:
    публикация сообщений
    комментарии к сообщениям
    настройки приватности

    После составления списка и дополнения его разными критичными замечаниями посчитайте сколько занимает проверка работы приложения по списку во время очередного регресс-тестирования.
    После этого нудные / массовые сценарии автоматизируйте.
    Ответ написан
    Комментировать
  • Что есть негативный сценарий из представленных?

    Ommonick
    @Ommonick
    qa+dev (scala, golang, ts/js, api, grpc)
    Позитивные сценарии - те сценарии, которые подразумеваются бизнесом
    -результат по поисковому запросу
    -пустой результат, если по адекватному запросу не было ничего найдено (насколько спецсимволы и пробел считаются адекватным запросом - прописывается в документации)

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