Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Регрессионное тестирование, как лучше производить учет тестов?

database
java
webdriver
testng
selenium
Теги: #<Tag:0x00007fedb7f0a5d0> #<Tag:0x00007fedb7f0a2d8> #<Tag:0x00007fedb7f0a0f8> #<Tag:0x00007fedb7f09ea0> #<Tag:0x00007fedb7f09cc0>

(Anna Butorina) #1

У нас есть автотесты (java + selenium) для регрессионного тестирования продукта, который написала наша компания.
Есть перечень страниц. Для каждой страницы решили составить перечень действий для примерного представления покрытия тестами функционала.
Прошлись по существующим тестам и прописали, какие действия проверяет каждый тест.
Решили занести эти данные в БД: страницы-действия-тесты.
Есть мысль написать приложение для работы с этой БД, к примеру: при добавлении новой страницы мы через приложение описываем действия, которые на этой странице можно произвести и пишем какие тесты проверяют эти действия.

Вопросы в моей голове:

  1. Вообще целесообразно ли делать проверку всего функционала автотестами? Сейчас проверяется даже меньше половины и то тесты идут пару часов.
  2. Есть ли смысл делать подобное приложение-справочник? Какие вы плюсы-минусы видите? Есть ли что-то подобное уже?

(елена бырканова) #2

А почему бы не воспользоваться готовыми системами типа testlink.


(Vjacheslav Lukashevich) #3
  1. Только Вы можете оветить на вопрос целесообразно ли тестировать весь функционал в вашем приложение.
    Например ничего страшного если не покрыт функционал который не используется и не меняется,
    но … если он используется и меняется это уже риск и наверное плохо (стоит задуматся о покрытии).
  2. Такие функциональные карты/ матрицы покрытия часто делают.
    В самом простом случае это страничка на вики. confluence или табличка в экселе.
    Почти все тест менеджмент тулы поддерживают создание таких Functional Map / Requirement Traceability Matrix

Из плюсов

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

Из минусов

  • такая таблица по сути альтернативное представление приложения и она настолько хороша насколько её хорошо составили (может не отображать реальный функционал, реальную картинку покрытия)
  • кто то должен её поддерживать актуальной - может утяжелить процесс

#4

1 При “проверяется даже меньше половины” неплохо учитывать еще и критичность функционала. По опыту редко когда детальная автоматизация всего подряд дает реальный профит. А вот затраты на поддержку фреймворка значительно возрастают, как и время прогонов.
2 И как было сказано выше вместо написания велосипедов лучше использовать готовые решения систем тестМенеджмента
3 Очень часто после пары релизов на подобную документацию-справочники кладут болт)