@southsoutheast
Мне интересно.

Регрессионое автотестирование бизнес-процессов — как правильно?

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

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

Сейчас появилось время разобраться - а как все-таки правильно?
С непосредственным нажиманием кнопочек вопросов нет - вместо watir-webdriver можно использовать selenium на любом удобном языке, хотелось бы понять, как это все разумно систематизировать и документировать (best practices или личный опыт с конкретными фреймворками).

При этом привязать к каждой функции или фиче по тесту недостаточно, важна "сценарность" ("развилки" из разных состояний процесса, которые можно получить только после предыдущих действий, просто правильная последовательность экранов у разных пользователей и сохранение в процессе всех необходимых данных и т.д.).
  • Вопрос задан
  • 270 просмотров
Пригласить эксперта
Ответы на вопрос 1
EvilsInterrupt
@EvilsInterrupt
System programming, Reversing Engineering, C++
1. В тестах развилок не может быть! Другими словами Вы всегда должны разбивать тестируемый код на участки. До условия это один участок кода. Ветка кода с if-true(т.е. когда условие true). И ветка кода с if-false(т.е. когда условие ложно). Это три разных тестовых сценария. Вам будет проще для сопровождения.

Тесты должны быть как можно проще!!! Было А, нажали что-то, Должно быть Б. Если не так, то заводим багу!

2. Прежде чем писать тест надо задаться вопросом "А если здесь будет бага, то что это будет значить для бизнеса?" ответ "Клиенты массово будут просить денег обратно" - значит надо писать тест "Клиент купит, но будет недоволен" - нужно думать стоит ли писать тест? Вдруг есть более важные участки кода
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы