Comments 10
«Ловкость рук и никакого мошеничества...»
Мне кажется автор пишет не о том, как более эффективно решать поставленные задачи, а как ставить более упрощённые задачи.
Например:
На самом деле задача не становится «эффективно решаема», а становится другая задача.
В первом случае, вы покрываете тестами все комбинации, во втором — только небольшую часть. Для каких-то сценариев это подходит, а для каких-то нет, потому что важно проверить (иметь покрытие тестами) все комбинации.
То же самое и в случае перехода с тестов в браузере на тесты через веб-сёрвисы. Это не упрощённое решение задачи — это другая, более простая задача.
Мне кажется автор пишет не о том, как более эффективно решать поставленные задачи, а как ставить более упрощённые задачи.
Например:
когда мы пытаемся перебрать все варианты, у нас получается, что черный ящик (сложность такого тестирования) — это экспоненциальная сложность…
… Хорошо, давайте протестируем отдельным тест-кейсом каждую связь и прогоним какой-нибудь сквозной сценарий. Получился 31 тест. В итоге, мы экспоненциальную сложность меняем на линейную. И задача становится эффективно решаема.
На самом деле задача не становится «эффективно решаема», а становится другая задача.
В первом случае, вы покрываете тестами все комбинации, во втором — только небольшую часть. Для каких-то сценариев это подходит, а для каких-то нет, потому что важно проверить (иметь покрытие тестами) все комбинации.
То же самое и в случае перехода с тестов в браузере на тесты через веб-сёрвисы. Это не упрощённое решение задачи — это другая, более простая задача.
Создал аккаунт и могу ответить.
Задача другая, но суть в том, что она эквивалентна первой. Вместо большого сценария мы пишем много маленьких. Кажется, что их много, но по факту в долгосрочной перспективе их нужно меньше, чем если бы тестировать то же самое end-to-end тестами.
Плюс мы можем выбросить те вещи, которые заведомо нам не интересно тестировать. Например, third-party вещи, с которыми нам нужно протестировать только совместимость.
Тут аналогично. Если перестать тестировать в браузере, а тестировать только веб-сервисы, то мы потеряем покрытие, полностью согласен. Но если мы покроем тестами отдельно back-end, отдельно front-end, а затем посмотрим их интеграцию, то суммарный результат будет лучше, чем если мы будем все автотесты писать для системы целиком.
На моём проекте, о котором я рассказывал, вёрстка была коробочной, поэтому отдельно front-end не имело особого смысла тестировать.
Я ни в коей мере не стараюсь обмануть аудиторию. Я рассказывал про общепринятые подходы, которые принесли реальную пользу на проекте, где мне посчастливилось поработать.
Несколько пруф-ссылок:
Те же мысли другими словами от Мартина Фаулера
Доклад с Selenium-конференции, в котором говорят о том, что не надо всё покрывать всё end-to-end тестами через Selenium
На самом деле задача не становится «эффективно решаема», а становится другая задача.
Задача другая, но суть в том, что она эквивалентна первой. Вместо большого сценария мы пишем много маленьких. Кажется, что их много, но по факту в долгосрочной перспективе их нужно меньше, чем если бы тестировать то же самое end-to-end тестами.
Плюс мы можем выбросить те вещи, которые заведомо нам не интересно тестировать. Например, third-party вещи, с которыми нам нужно протестировать только совместимость.
То же самое и в случае перехода с тестов в браузере на тесты через веб-сёрвисы. Это не упрощённое решение задачи — это другая, более простая задача.
Тут аналогично. Если перестать тестировать в браузере, а тестировать только веб-сервисы, то мы потеряем покрытие, полностью согласен. Но если мы покроем тестами отдельно back-end, отдельно front-end, а затем посмотрим их интеграцию, то суммарный результат будет лучше, чем если мы будем все автотесты писать для системы целиком.
На моём проекте, о котором я рассказывал, вёрстка была коробочной, поэтому отдельно front-end не имело особого смысла тестировать.
«Ловкость рук и никакого мошеничества...»
Я ни в коей мере не стараюсь обмануть аудиторию. Я рассказывал про общепринятые подходы, которые принесли реальную пользу на проекте, где мне посчастливилось поработать.
Несколько пруф-ссылок:
Те же мысли другими словами от Мартина Фаулера
Доклад с Selenium-конференции, в котором говорят о том, что не надо всё покрывать всё end-to-end тестами через Selenium
Поспорю с завершающим слайдом. Совет по повторному использованию кода функциональных тестов не универсален.
Представьте, подготовка БД завершена, контекст настроен, в системе есть контакт с ИД 42.
Функциональный тест: открыть карточку контакта с ИД 42, проверить, что в поле Статус значение Действующий, и что значение можно сменить, убедиться, что в логах не появилось ошибок и предупреждений.
Если распараллелить такой тест на 100 пользователей, то проверим эффективную работу с кешем. А если работа с кешем эффективна, то нагрузка не будет создана. Для того, чтобы кеш испытал шок и рассыпался в пыль, придётся подключить 50 000 пользователей, а имеющееся оборудование может не позволить этого, или бизнесу может быть не интерсна поддержка такого количества, или, вообще, схватим deadlock при разборе логов уже на 10-м потоке.
Если переписать функциональный тест так: открыть карточку произвольного контакта, проверить, что значение в поле Статус можно сменить на случайное и код ответа сервиса — 200 (OK).
То тест становится более подходящим для нагрузки.
Но когда бизнес спросит: «Действующие контакты в новом билде по-прежнему действуют, при открытии карточки в логах нет предупреждений?», — дать положительный ответ, на основе функционально-нагрузочного теста не получится.
Представьте, подготовка БД завершена, контекст настроен, в системе есть контакт с ИД 42.
Функциональный тест: открыть карточку контакта с ИД 42, проверить, что в поле Статус значение Действующий, и что значение можно сменить, убедиться, что в логах не появилось ошибок и предупреждений.
Если распараллелить такой тест на 100 пользователей, то проверим эффективную работу с кешем. А если работа с кешем эффективна, то нагрузка не будет создана. Для того, чтобы кеш испытал шок и рассыпался в пыль, придётся подключить 50 000 пользователей, а имеющееся оборудование может не позволить этого, или бизнесу может быть не интерсна поддержка такого количества, или, вообще, схватим deadlock при разборе логов уже на 10-м потоке.
Если переписать функциональный тест так: открыть карточку произвольного контакта, проверить, что значение в поле Статус можно сменить на случайное и код ответа сервиса — 200 (OK).
То тест становится более подходящим для нагрузки.
Но когда бизнес спросит: «Действующие контакты в новом билде по-прежнему действуют, при открытии карточки в логах нет предупреждений?», — дать положительный ответ, на основе функционально-нагрузочного теста не получится.
Подход не универсален, согласен на 100%.
Случай достаточно уникален, так как редко такое удаётся провернуть. В виду итересности случая он и был упомянут в докладе.
Но в докладе я лишь бегло прошёлся по этой теме в виду банального ограничения по времени.
Конечно, функциональные тесты не реиспользовались «в лоб» в нагрузочных. Мы строили нагрузочные сценарии из тех же «кирпичей», из которых строились функциональные тесты.
Тот же разбор логов и ресурсоёмкие тестовые файловые манипуляции не паралелились.
Там было много подводных камней. Пришлось достаточно просидеть за профайлером, так как в самих тестах были местами критические секции, которые выполнялись лишь в одном потоке.
Были сделаны определённые допущения исходя из знаний Siebel'a. Нам было важно реалистично нагрузить базу, так как для Siebel'a чаще всего она узкое место. Поэтому мы в некотором роде пренебрегли реалистичностью нагрузки на web-сервер.
В общем, нужен был результат и его достигли, затратив на это меньше, чем если бы мы писали отдельные тесты на LoadRunner'e.
Вспоминается первая заповедь перфекциониста-прокрастинатора: «Лучше сделать хорошо, но никогда, чем кое-как и сегодня»
Случай достаточно уникален, так как редко такое удаётся провернуть. В виду итересности случая он и был упомянут в докладе.
Но в докладе я лишь бегло прошёлся по этой теме в виду банального ограничения по времени.
Конечно, функциональные тесты не реиспользовались «в лоб» в нагрузочных. Мы строили нагрузочные сценарии из тех же «кирпичей», из которых строились функциональные тесты.
Тот же разбор логов и ресурсоёмкие тестовые файловые манипуляции не паралелились.
Там было много подводных камней. Пришлось достаточно просидеть за профайлером, так как в самих тестах были местами критические секции, которые выполнялись лишь в одном потоке.
Были сделаны определённые допущения исходя из знаний Siebel'a. Нам было важно реалистично нагрузить базу, так как для Siebel'a чаще всего она узкое место. Поэтому мы в некотором роде пренебрегли реалистичностью нагрузки на web-сервер.
В общем, нужен был результат и его достигли, затратив на это меньше, чем если бы мы писали отдельные тесты на LoadRunner'e.
Вспоминается первая заповедь перфекциониста-прокрастинатора: «Лучше сделать хорошо, но никогда, чем кое-как и сегодня»
Что делать если поднял что-то похожее, оно работает, даже простой как пробка синтаксис для автотестов придумали, писать может практически любой, и вот все вертится, тесты потихоньку пишутся (скучно), параллельно тебе отдают задачки ручного тестирования (еще скучнее) и даже когда появляются задачи оптимизации готового стека тебе тоже скучновато, а иногда они даже не перепадают так как есть другие инженеры.
Ну в общем сплошная скука.
При этом времени на разработку чего-то крутого и получение опыта нет и не предвидится (особо нечего пилить по должности) — до разработчика как бы не дотягиваешь. Что делать в таком случае? До смерти пилить какой-то свой домашний «проект» и по капле получать опыт разработчика, или есть более гуманные методы?
Ну в общем сплошная скука.
При этом времени на разработку чего-то крутого и получение опыта нет и не предвидится (особо нечего пилить по должности) — до разработчика как бы не дотягиваешь. Что делать в таком случае? До смерти пилить какой-то свой домашний «проект» и по капле получать опыт разработчика, или есть более гуманные методы?
Влюбиться.
Направлений для развития полно. Поглядите эти схемы, например.
Я бы посоветовал критично взглянуть на свою текущую деятельность: всегда есть места, что улучшать и оптимизировать. И чаще всего это те проблемы, которые непонятно, как решать.
Бывает, для «просветления» нужно сходить в отпуск или съездить на профильную или смежную по тематике конференцию.
Бывает, для «просветления» нужно сходить в отпуск или съездить на профильную или смежную по тематике конференцию.
Как уже было отмечено выше, тестирование каждого модуля по отдельности — это далеко не тоже самое, что протестировать все модули в связке. В сложных проектах между отдельными модулями иногда бывают не тривиальные связи — например, ошибка возникает в модуле 3, при специфических параметров в модулях 2 и 7. Потому для полной гарантии наверное действительно надо совершить полный перебор все возможных комбинаций параметров для всех модулей. Иначе говоря точное решение имеет экспоненциальную сложность. Пара десятков параметров, каждый из которых может принимать несколько значений и задача полного перебора фактически становиться нерешаемой.
Здесь можно сделать шаг назад, и спросить: а нужна ли нам 100% уверенность? Может достаточно 99% или там 99.9%. В последнем случае достаточно покрыть полными тестами основные сценарии использования. А для проверки случаев экзотических нетривиальных связей между модулями — использовать тесты со случайными (но естественно в разрешенных границах) наборами параметров. Если параметры выбираются действительно случайным образом в каждом тестовом случае, то достоверность такого тестирования растет как квадратный корень от общего числа испытаний. Получаем своеобразное тестирование по методу Монте-Карло. :)
Здесь можно сделать шаг назад, и спросить: а нужна ли нам 100% уверенность? Может достаточно 99% или там 99.9%. В последнем случае достаточно покрыть полными тестами основные сценарии использования. А для проверки случаев экзотических нетривиальных связей между модулями — использовать тесты со случайными (но естественно в разрешенных границах) наборами параметров. Если параметры выбираются действительно случайным образом в каждом тестовом случае, то достоверность такого тестирования растет как квадратный корень от общего числа испытаний. Получаем своеобразное тестирование по методу Монте-Карло. :)
Про 100% уверенность более чем согласен, немногие из нас делают софт для атомных электростанций.
Наступили на больной мозоль. Если нам надо перебрать варианты работы модуля 3, то модули 2 и 7 не только не нужны, но будут только мешать. Сэмулировать ответ от 2 и 7 гораздо проще с заглушек, чем довести 2 и 7 до того состояния, при котором они самостоятельно нужным образом дёрнут модуль 3.
Если стоит задача протестировать модуль 3, то гораздо проще и дешевле во всех смыслах (время выполнения, время на разработку автотеста) сделать это в изоляции от 2 и 7.
Немного больше информации по этому поводу — Test Double Pattern
Эта штука работает. Знаю несколько удачных случаев, где подобный подход принёс хорошие результаты.
В сложных проектах между отдельными модулями иногда бывают не тривиальные связи — например, ошибка возникает в модуле 3, при специфических параметров в модулях 2 и 7.
Наступили на больной мозоль. Если нам надо перебрать варианты работы модуля 3, то модули 2 и 7 не только не нужны, но будут только мешать. Сэмулировать ответ от 2 и 7 гораздо проще с заглушек, чем довести 2 и 7 до того состояния, при котором они самостоятельно нужным образом дёрнут модуль 3.
Если стоит задача протестировать модуль 3, то гораздо проще и дешевле во всех смыслах (время выполнения, время на разработку автотеста) сделать это в изоляции от 2 и 7.
Немного больше информации по этому поводу — Test Double Pattern
Получаем своеобразное тестирование по методу Монте-Карло.
Эта штука работает. Знаю несколько удачных случаев, где подобный подход принёс хорошие результаты.
Sign up to leave a comment.
Доклад с SQA Days — Автоматизация тестирования: отбрасываем лишнее и проверяем суть