Перейти к содержимому

Фотография

Вопрос про ретестинг и регрессионное тестирование


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 3

#1 KnopkaZapuska

KnopkaZapuska

    Активный участник

  • Members
  • PipPip
  • 103 сообщений
  • ФИО:Kate

Отправлено 31 июля 2018 - 11:28

Как я понял ретестинг - это проверка на старые баги, после фикса. А регрессионное - это проверка того, что те новые фиксы, фичи, обновления не сделали новые баги. Все верно? 
Если так, то как будет осуществляться выбор регрессионных тестов? Например я добавил новую фичу к себе в ПО ( кнопки назад и вперед). Но вдруг мой код задел что-то где-то еще? Но ведь кнопки функционируют как надо. Так  как можно будет произвести регрессионное тестирование,  зная, что я ввёл новую фичу? 
Т.е. откуда я буду знать, что именно должно быть протестировано этим видом теста?


  • 0

#2 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 31 июля 2018 - 12:12

Вы добавили кнопки назад-вперед, но кнопка "назад" на самом деле отправляет тоже вперед. Вы завели баг, горе-программист его исправил. Вы снова жмете на кнопку "назад" и проверяете, куда она вас отправляет. Это ретестинг. После этого вы проверяете, что из-за добавления кнопок, например, не поехала верстка страницы, не поменялись другие кнопки (с которыми, возможно, задействованы общие стили и пр.) Это регрессия. Регрессионные тесты выбираются, в первую очередь, по наличию чего-то общего с добавленной фичей. Если добавили новые кнопки - надо просмотреть все остальные кнопки. Если, скажем, в багтрекере каком-нибудь что-то изменили в технологии хранения прикрепленных файлов, не помешает протестировать, например, копирование багов, в том числе с файлами, которые были прикреплены до изменений.

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


  • 1

#3 QuadBit

QuadBit

    Новый участник

  • Members
  • Pip
  • 48 сообщений

Отправлено 31 июля 2018 - 14:48

А регрессионное - это проверка того, что те новые фиксы, фичи, обновления не сделали новые баги

Новые баги в старом функционале, не просто новые. Например, у вас был какой-нибудь список, который определенным образом формируется. Поверх него можно осуществлять ещё какие-то сортировки\выборки. Если вы поменяли алгоритм формирования первоначального списка - логично будет проверить все связанные действия.

 

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

Платиновый вопрос, в идеале - нужно протестить абсолютно весь старый функционал. В реальном мире - вам нужно максимально выявить интеграционные связи измененного функционала и существовавшего до изменений. Как? Документация( всякие ERD, flowchart, etc), общение с разработкой, аналитиками, опыт на конкретном проекте и составление сьютов на определенные части интеграции. Если есть изменения, которые попадают под 1-2 теста съюта - прогоняете его целиком на регрессе.


  • 0

#4 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 31 июля 2018 - 15:13

регрешон, в большинстве случаев, это тестирование тестов, написанных на основе найденных багов. И даёт результат, этот вид тестов, в виде багов, в случае если в команде программистов есть нечистоплотный участник, который делает мержы на "а ну, и так сойдёт". С появлением git данные проблемы с нечистоплотностью, в большинстве случаев, решает система контроля версий.

А у тех кто досих пор работает на SVN, Perforce, или VCS либо очень прямые руки, либо очень хорошие тестировщики =)

 

для тех кто работает над общими кусками кода в системе контроля версий будет до боли понятно о чём я тут пишу =)


  • 0


Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных