Комментарии 12
Вообще хочу отметить что часто когда статьи (а я их читал достаточно) говорят об автоматизации тестирования, как правило не разделяют виды тестирования. Получается что тезисы безоговорчно равноприменимы ко всем видам тестирования. На практике это не так. И нужно и важно выделять специфику разных видов автоматизированного тестирования.
Например: «Тесты должны быть независимы друг от друга. Их можно выполнять в любой последовательности».
Для юнит-тестов это высказывание может быть верным. Там подготовка теста (Setup) не сильно влияет на время прогона.
Но UI тесты, (приемочные тесты, где мы проверяем кусок фунционала в качестве пользователя) могут отклоняться от этого правила потому, что тесты должны быть быстрыми. Если я каждый раз буду заходить в свой раздел приложения перед началом проверки, то это будет занимать больше половины всего времени.
Я руководствуюсь принципом — тест должен делать только то что является предметом теста. Вход в раздел является тестом, и выполяется первым. После этого не нужно выполнять вход. Поэтому у меня тесты идут друг за другом. И это нормально. Упал вход, все тесты за ним посыпались — разрабы чинят вход. Потому что иначе пользователь до нижележащего фунцкионала просто не доберется. Все честно. Я мог бы исхитриться и обойти процедуру входа для последующих тестов, но это бы исказило пользовательский сценарий. Для сравнения: я мог бы выполнять вход перед каждым тестом, но если он сломан результат будет тем же. В первом случае первый тест покажет что вход не был выполнен, а последующие за ним тесты покажут что подраздел не найден. Во втором случае все тесты покажут что вход не был выполнен. Красных тестов будет что так что эдак одинаково.
Вобщем, для каждой задачи свой подход. Нельзя сваливать всю автоматизацию в одну кучу. И это главная проблема среди проблем автоматизации.
Например: «Тесты должны быть независимы друг от друга. Их можно выполнять в любой последовательности».
Для юнит-тестов это высказывание может быть верным. Там подготовка теста (Setup) не сильно влияет на время прогона.
Но UI тесты, (приемочные тесты, где мы проверяем кусок фунционала в качестве пользователя) могут отклоняться от этого правила потому, что тесты должны быть быстрыми. Если я каждый раз буду заходить в свой раздел приложения перед началом проверки, то это будет занимать больше половины всего времени.
Я руководствуюсь принципом — тест должен делать только то что является предметом теста. Вход в раздел является тестом, и выполяется первым. После этого не нужно выполнять вход. Поэтому у меня тесты идут друг за другом. И это нормально. Упал вход, все тесты за ним посыпались — разрабы чинят вход. Потому что иначе пользователь до нижележащего фунцкионала просто не доберется. Все честно. Я мог бы исхитриться и обойти процедуру входа для последующих тестов, но это бы исказило пользовательский сценарий. Для сравнения: я мог бы выполнять вход перед каждым тестом, но если он сломан результат будет тем же. В первом случае первый тест покажет что вход не был выполнен, а последующие за ним тесты покажут что подраздел не найден. Во втором случае все тесты покажут что вход не был выполнен. Красных тестов будет что так что эдак одинаково.
Вобщем, для каждой задачи свой подход. Нельзя сваливать всю автоматизацию в одну кучу. И это главная проблема среди проблем автоматизации.
Независимость тестов это технический способ обеспечить их стабильность,
а значит и доверие к ним. Это важно если это достижимо.
Если независимость стоит слишком дорого, можно искать другие технические решения.
То что вы говорите вполне оправдано.
а значит и доверие к ним. Это важно если это достижимо.
Если независимость стоит слишком дорого, можно искать другие технические решения.
То что вы говорите вполне оправдано.
Стабильность тестов в моем понимании это когда тесты на одной и той же версии продукта выдают при повторном выполнении один и тот же результат. Результат может быть и красным, но он не должен изменяться при повторении. Если тесты всегда выдают стабильный красно-зеленый результат — на доверии это скажется негативно. Значит обеспечив стабильность мы еще не обеспечили доверие. Так же если все тесты всегда зеленые это тоже скажется на доверии негативно. Может они и не тестируют ничего.
А стабильность сама по себе действительно очень важна. У нас были фазы где мы красно-зеленые тесты гоняли чтобы проверить обновления в инструменте. Если все как и раньше — едем дальше.
Другое дело надежность, она определяет вероятность ложного срабатывания (срабатывание это красный результат) Вот надежность она влияет на «доверие». Еще раз, стабильность — одинаковый результат при повторном исполнении в одинаковых условиях, надежность — обратная величина количеству ложных срабатываний. Если стабильность можно проверить повторным прогоном, надежность проверить можно только заглянув в код.
Автоматизация помогает выявить неявные изменения. Это может кому-то показаться странным но несмотря на то что наши UI тесты описывают пользовательские сценарии, сам «предмет теста» как я его называю, практически всегда в порядке, в 85% случаев ломается что-то вокруг, и тесты перестают работать. И это хорошо. Т.е. тесты ненадежные. Мы обмотали наш продукт красной проволкой и смотрим где эта проволока порвется. Получается как в том анекдоте, что «по дырочкам никогда не рвется». И пусть. Главное чтобы тесты реагировали на изменения.
А вообще я не доверяю тестам ни своим ни чужим. Всегда есть что-то что я не учел, пусть это даже пробел в спецификации. Тесты всегда недостаточно хороши. Так что такая категория как доверие, она слишком человеческая, чтобы применять ее в техническом плане. Я доверяю автоматизации тогда когда она находит ошибки в ПО. Находит — хорошо, не находит — плохо. А полагаюсь я на автоматизацию каждый день иначе я бы просто был не в состоянии даже близко проверить столько конфигураций
А стабильность сама по себе действительно очень важна. У нас были фазы где мы красно-зеленые тесты гоняли чтобы проверить обновления в инструменте. Если все как и раньше — едем дальше.
Другое дело надежность, она определяет вероятность ложного срабатывания (срабатывание это красный результат) Вот надежность она влияет на «доверие». Еще раз, стабильность — одинаковый результат при повторном исполнении в одинаковых условиях, надежность — обратная величина количеству ложных срабатываний. Если стабильность можно проверить повторным прогоном, надежность проверить можно только заглянув в код.
Автоматизация помогает выявить неявные изменения. Это может кому-то показаться странным но несмотря на то что наши UI тесты описывают пользовательские сценарии, сам «предмет теста» как я его называю, практически всегда в порядке, в 85% случаев ломается что-то вокруг, и тесты перестают работать. И это хорошо. Т.е. тесты ненадежные. Мы обмотали наш продукт красной проволкой и смотрим где эта проволока порвется. Получается как в том анекдоте, что «по дырочкам никогда не рвется». И пусть. Главное чтобы тесты реагировали на изменения.
А вообще я не доверяю тестам ни своим ни чужим. Всегда есть что-то что я не учел, пусть это даже пробел в спецификации. Тесты всегда недостаточно хороши. Так что такая категория как доверие, она слишком человеческая, чтобы применять ее в техническом плане. Я доверяю автоматизации тогда когда она находит ошибки в ПО. Находит — хорошо, не находит — плохо. А полагаюсь я на автоматизацию каждый день иначе я бы просто был не в состоянии даже близко проверить столько конфигураций
Простите, но вы или новичек в автоматизации или не серьезно ей занимаетесь. Тут есть сразу две проблемы(может больше): 1. При вашем подходе вы не сможете параллелить тесты. 2. При вашем подходе вы вообще ничего не протестируете(упал вход, чинят вход). Вот реальный кейс: разработчики выкатывают патч, в котором кроме изменений в логине(которые и сломали) есть так же изменения в других частях приложения. И вот при вашем подходе, когда тесты зависимы — все будут сидеть и ждать пока пофиксят логин(ну или переключаться на другие таски). А если делать независимы — то при сломанном логине, тесты по документообороту, обмену сообщениями, чем угодно еще, что входило в патч — будут идти и давать результат. В итоге уже после первого прогона станет более менее ясно — сломали логин или вообще все сломали и не выкатываемся
Ну у нас такая ситуация, что не мы выполняем тесты мы их только пишем и анализируем результаты. Инструмент у нас самописный и приложение embedded. И результат автоматизированных тестов мы получаем только на следующий день, хотя новый билд у ручных тестировщиков уже сегодня, и соотв. информация «рабочий» ли билд известна уже сегодня. Т.е автоматизация не перед ручным тестированием, а после ручного смоук теста. Да, после. И все были бы рады, если бы автоматизация могла предоставить общую картину состояния билда, а она и предоставляет, только заказчик собирает все результаты в общий процент и смотрит на него. А контекстов штук двенадцать, разные команды, все пишут свои тесты. Кроме того у нас кроме красного результата есть еще и желтый, желтый результат не отображается в статистике, и не я это придумал. Вобщем все весьма и весьма грустно.
Ну да, можно сказать, что заказчик не серьезно подходит к автоматизации.Ведь она даже в бюджет команд не заложена. Чистая прихоть заказчика.
Так что, как правильно все проходили а в жизни по разному бывает. И добрых книжных истин хватает везде, а информации как же люди справляются в жизни — об этом в основном никакой информации.
Меня просто не устраивает когда догму пытаются втюхать так как будто вот только так и правильно. Как правильно разрабатывать об этом десятилетиями спорят, наверное потому что серебрянной пули нет. Так и тут.
Но спасибо вам за ответ, здравая мысль она вдохновляет.
Ну да, можно сказать, что заказчик не серьезно подходит к автоматизации.Ведь она даже в бюджет команд не заложена. Чистая прихоть заказчика.
Так что, как правильно все проходили а в жизни по разному бывает. И добрых книжных истин хватает везде, а информации как же люди справляются в жизни — об этом в основном никакой информации.
Меня просто не устраивает когда догму пытаются втюхать так как будто вот только так и правильно. Как правильно разрабатывать об этом десятилетиями спорят, наверное потому что серебрянной пули нет. Так и тут.
Но спасибо вам за ответ, здравая мысль она вдохновляет.
Я еще несколько раз перечитал ваш ответ, и понял что же меня при первом прочтении резануло: по вашей логике продукт со сломаным логином можно выдавать пользователю? И зачем оно ему если он даже зайти в систему не сможет?
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.
Нет, вы не правильно поняли. Я к тому, что главная задача — сократить время на тестирование. и в вашем случае — вы фиксите баги последовательно(так как находятся они последовательно во время запуска автотестов). А в моем случае — все тестируется паралелельно и соответственно фиксятся они тоже паралелльно.
Да, при таком подходе есть недостаток, что завалившийся тест перекрывает «видимость» на следущий за ним функционал. И пока причина не будет устранена, эти перекрытые части остаются непротестироваными. С другой стороны, по скольку багрепорты пишу тоже я, а мой ресурс не бесконечен, такой подход работает. Писать тест так чтобы он выполнялся в любом случае, заставило бы нас сильно залезать во внутреннее состояние системы, а это во первых на нашей системе очень сложно (при проектировании тестируемость в нее не закладывали), во вторых черевато побочными эффектами.
Основные принципы инвестирования ресурсов можно попробовать сформулировать в виде короткого манифеста.
Вы тестируете собственные тексты?
Ожидал увидеть если не все, то хотябы что-то из этого:
1. Сравнение подходов ручного и автоматического тестирования, плюсы и минусы.
2. На сколько автоматические тесты могут заменить ручные, какие соображения и противопоказания.
3. Добавлять ли юнит тесты в автоматические или они должны жить отдельно.
4. С чего начать «приручать» автотесты.
1. Сравнение подходов ручного и автоматического тестирования, плюсы и минусы.
2. На сколько автоматические тесты могут заменить ручные, какие соображения и противопоказания.
3. Добавлять ли юнит тесты в автоматические или они должны жить отдельно.
4. С чего начать «приручать» автотесты.
4. Начать нужно с доверия.
3. Не думаю что это принципиальный вопрос. Могут быть за и против в зависимости от ситуации.
На остальные пункты ответы есть в предыдущей статье.
3. Не думаю что это принципиальный вопрос. Могут быть за и против в зависимости от ситуации.
На остальные пункты ответы есть в предыдущей статье.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как приручить автотесты