Регрессионое автотестирование бизнес-процессов — как правильно?
Какое-то время назад пришлось столкнуться с задачей автоматизации тестирования многопользовательских процессов.
Условно, нужно было проверять некий веб-интерфейс, где происходят разные длинные и сильно разветвленные сценарии: пользователь А нажал кнопку, после этого пришло сообщение пользователю Б, потом (в зависимости от действий пользователей А и Б), приходят сообщения пользователю В или Г и т.д.
На тот момент средства и методы выбирались по критериям простоты и действенности реализации, в итоге вышла пачка файлов-сценариев ужасающей длины на watir-webdriwer, которая запускалась каждый день за завтраком (если нормально отрабатывавший вчера скрипт ломался на середине, значит нужно садиться разбираться: либо что-то изменилось, либо что-то сломалось).
Сейчас появилось время разобраться - а как все-таки правильно?
С непосредственным нажиманием кнопочек вопросов нет - вместо watir-webdriver можно использовать selenium на любом удобном языке, хотелось бы понять, как это все разумно систематизировать и документировать (best practices или личный опыт с конкретными фреймворками).
При этом привязать к каждой функции или фиче по тесту недостаточно, важна "сценарность" ("развилки" из разных состояний процесса, которые можно получить только после предыдущих действий, просто правильная последовательность экранов у разных пользователей и сохранение в процессе всех необходимых данных и т.д.).
1. В тестах развилок не может быть! Другими словами Вы всегда должны разбивать тестируемый код на участки. До условия это один участок кода. Ветка кода с if-true(т.е. когда условие true). И ветка кода с if-false(т.е. когда условие ложно). Это три разных тестовых сценария. Вам будет проще для сопровождения.
Тесты должны быть как можно проще!!! Было А, нажали что-то, Должно быть Б. Если не так, то заводим багу!
2. Прежде чем писать тест надо задаться вопросом "А если здесь будет бага, то что это будет значить для бизнеса?" ответ "Клиенты массово будут просить денег обратно" - значит надо писать тест "Клиент купит, но будет недоволен" - нужно думать стоит ли писать тест? Вдруг есть более важные участки кода
1. Да, это три тестовых сценария (в реальности - гораздо больше), и все их надо проверить. Вопрос в том, как и в чем наглядно систематизировать заходы на все развилки.
2. Вопрос "а будем ли мы писать этот тест" в данной задаче считается решенным на предыдущем этапе. И да, именно в моем случае все эти длинные сценарии были нужны и отлавливали много багов самых разных сортов и степеней критичности, поэтому интересно не как от них избавиться, а как сделать их удобнее.
southsoutheast: Я не понимаю в чем именно у Вас сложности?
Сценарии возникают в рамках работы с той или иной функциональностью. В чем сложности собрать тесты в набор и назвать "Тесты по функциональности .... "? Тестируется не "сценарность", тестируется ВСЕГДА "Функциональность". То что пользователь пошел по развилке "А" это тоже Функциональность!
Простой
Простой
Простой
