Comments 12
По второму пункту вопрос: как тесты влияют на показатели качества?
Я, если честно, не понимаю Ваш вопрос. Сформулируйте, пожалуйста, точнее… Автоматические тесты — это инструмент для достижения какой-то цели — , например, понижения в среднесрочной перспективе стоимости регрессионного тестирования.
Список показателей качества большой: понятность; полнота; краткость; портируемость; согласованность; сопровождаемость; тестируемость; удобство использования; надёжность; cтруктурированность; эффективность; безопасность. Не занимаемся ли мы изначально самообманом, считая что автоматезированное тестирование как-то повлияют на показатели качества?
Ну так же можно считать самообманом, что IDE повышает скорость и качество разработки и что лучше всё писать в блокноте. Давайте отойдём от споров на тему глобальных определений и будем считать качеством соответствие продукта прямым требованиям и косвенным. Фактически автоматизация тестирования является инструментом для поддержания этой идеи.
«Понятность: Назначение ПО должно быть понятным, из самой программы и документации.»
Вы уж простите, но автоматические тесты для этого не предназначены.
К тому же, в Вашей ссылке на Вики:
«Фактор качества ПО — это нефункциональное требование к программе...»
Автоматические тесты в первую очередь предназначены для обеспечения гарантии качества именно функциональных требований (описанных в договоре и не описанных, но являющихся критичными для бизнес-процессов продукта и пользователей). Причём не просто гарантии, а гарантии во времени -, чтобы при появлении новых фич, аффекты по уже имеющимся были бы выявлены автоматически и быстро, без рутинных проверок руками.
«Понятность: Назначение ПО должно быть понятным, из самой программы и документации.»
Вы уж простите, но автоматические тесты для этого не предназначены.
К тому же, в Вашей ссылке на Вики:
«Фактор качества ПО — это нефункциональное требование к программе...»
Автоматические тесты в первую очередь предназначены для обеспечения гарантии качества именно функциональных требований (описанных в договоре и не описанных, но являющихся критичными для бизнес-процессов продукта и пользователей). Причём не просто гарантии, а гарантии во времени -, чтобы при появлении новых фич, аффекты по уже имеющимся были бы выявлены автоматически и быстро, без рутинных проверок руками.
Тогда пожалуйста правильно используйте термины. Понятие качество в том виде в каком представлено в вики можно увидеть у Роберта Гласса в «software conflict 2.0 The art and science of software engineering» и у Стива Макконнелла в «Code Complete».
Да, тестирование дает оценку надежности системы, но обеспечение качества это слишком объемная задача, что бы ее можно было выполнить исключительно путем тестирования.
Да, тестирование дает оценку надежности системы, но обеспечение качества это слишком объемная задача, что бы ее можно было выполнить исключительно путем тестирования.
Я стараюсь правильно использовать термины. По-прежнему не понимаю, что сказал не так. Если, говоря качество, имел ввиду ту часть качества, которая обеспечивается тестированием, а вам не нравится, что обеспечение качества — это не тестирование лишь, а совокупность мер… Ну ок… Это само собой и не противоречит тому, что написано в пункте 2. Если же я оскорбил чьи-то чувства… Ваши или Роберта Гласса или Стива Макконнелла, то прошу прощения. Не хотел… Просто привык говорить по существу, а не вязнуть в вопросах безукоризненной точности определений
Если мы можем внести случайность во входное поведение для теста, её обязательно надо включить.
Позвольте с Вами не согласиться. Считаю что одним из самых важных свойств тестов (если не самое важное) должна быть повторяемость. В противном же случае мы получаем гейзенбаги на тестах by design. В крайнем случае, тщательно логировать все сгенерированые входные данные, чтобы потом можно было воспроизвести.
На самом деле, идея рандомизации для отлова случаев, про которые программист просто не подумал, мне нравится. Однако реализация должна отличаться от простой замены всех констант на рандом.
В предыдущей моей статье предлагали разделить unit-тесты и функциональные авто-тесты. Я бы всё-таки старался этого не делать,
Если можно, то расскажите подробнее что Вы имели ввиду под разделением, а так же, почему этого лучше не делать. Дальше во всем пункте Вы говорите исключительно про рандомизацию. Если я правильно все понял, то с разделением это вообще не связано.
Повторяемость — безусловно важная черта тестов. Безусловно, реализация рандомизации должна отличаться «от простой замены констант на рандом». Конечно, тут нужно и логирование красивое и понятное — это, безусловно искусство. Основная идея, которую я уже не раз реализовывал, — это взять распределение наиболее вероятных значений (провести исследования, например), создать стратегию генерации случайных входных данных с разбросом в пределах нескольких сигма от матожидания. В результате мы получаем максимальную эмуляцию пользователя, — тест начинает быть не given-then, а given(спектр)-then(спектр). Да, ожидаемый результат будет варьироваться. Если тест раньше набивал один конкретный товар в корзину интернет-магазина и проверял конкретную цифру, которую заранее сгенерил и залил в базу, то теперь он будет добавлять случайные товары, которые надо будет верифицировать в конце суммами, наименованиями и прочими разностями. Конечно, цены в диапазоне, количество товаров в корзине в среднем, например, 4 +-.
Да, порой случается, что рандомизированные входные данные приводят к нестабильности теста при повторениях — это и есть тот прекрасный результат… Когда мы видим, что на значении суммы покупок в 109.11 вдруг округление сработало неведомым образом. Эти баги потом прилетают с боя и их намного сложнее воспроизвести, потому что неясные входные данные. Уж лучше тест сто раз прогонится с разными значениями и 1 раз упадёт и мы это пофиксим, чем сотый клиент, произведя операцию, получит неожидаемый результат или положит систему (такое, как ни странно, тоже бывает)…
Можно со мной не соглашаться, но именно эти мелкие трудновоспроизводимые, порой критичные баги, больше всего выводят разработчиков, — ещё больше выводят бизнес, потому что их фиксы занимают много времени…
По поводу разделения unit/функциональные. Если у нас есть модуль А, который вызывает модуль B, тот химичит, отдаёт модулю C. Если мы можем написать функциональный тест с рандомизированными(это я подчёркиваю) входными данными, который войдёт в процессе выполнения в точку А и выйдет из точки C с правильной верификацией, то в 99.9% случаев можно считать, что модуль B покрыт и будет работать правильно без каких-либо unit-тестов. Я никак не отвергаю идею unit-тестирования, просто стараюсь сузить область её применения. Наоборот — я тащусь от Mockito, закрываю моками всё, что можно и стараюсь генерить рандомные значения со стороны заглушек и смотреть, а как вот мой этот функциональный тест, поведёт себя в разрезе работы вот с этими модулями, этими методами…
Надеюсь, смог сформулировать свою мысль. Если есть вопросы, буду рад ответить
Да, порой случается, что рандомизированные входные данные приводят к нестабильности теста при повторениях — это и есть тот прекрасный результат… Когда мы видим, что на значении суммы покупок в 109.11 вдруг округление сработало неведомым образом. Эти баги потом прилетают с боя и их намного сложнее воспроизвести, потому что неясные входные данные. Уж лучше тест сто раз прогонится с разными значениями и 1 раз упадёт и мы это пофиксим, чем сотый клиент, произведя операцию, получит неожидаемый результат или положит систему (такое, как ни странно, тоже бывает)…
Можно со мной не соглашаться, но именно эти мелкие трудновоспроизводимые, порой критичные баги, больше всего выводят разработчиков, — ещё больше выводят бизнес, потому что их фиксы занимают много времени…
По поводу разделения unit/функциональные. Если у нас есть модуль А, который вызывает модуль B, тот химичит, отдаёт модулю C. Если мы можем написать функциональный тест с рандомизированными(это я подчёркиваю) входными данными, который войдёт в процессе выполнения в точку А и выйдет из точки C с правильной верификацией, то в 99.9% случаев можно считать, что модуль B покрыт и будет работать правильно без каких-либо unit-тестов. Я никак не отвергаю идею unit-тестирования, просто стараюсь сузить область её применения. Наоборот — я тащусь от Mockito, закрываю моками всё, что можно и стараюсь генерить рандомные значения со стороны заглушек и смотреть, а как вот мой этот функциональный тест, поведёт себя в разрезе работы вот с этими модулями, этими методами…
Надеюсь, смог сформулировать свою мысль. Если есть вопросы, буду рад ответить
Есть модули, которые непременно нуждаются в unit-тестировании. Но везде, где только возможно покрыть модуль сквозным процессом пользователя, лучше покрыть именно процессом, чем со всех сторон юнит-тестами. Быстрее по времени и эффективнее.
Конечно, если налажен полноценный TDD, то что тут мне спорить)) У всех разные задачи и разные реализации. Я просто делюсь своим опытом.
Конечно, если налажен полноценный TDD, то что тут мне спорить)) У всех разные задачи и разные реализации. Я просто делюсь своим опытом.
здесь была первая половина случайно отправленного комментария
что тут мне спорить)) Я просто делюсь своим опытом.Ну так в этом вся суть.
Теперь по делу. На всякий случай уточню, что я пишу с позиции программиста, а не тестировщика. Безусловно, в этом есть своя специфика.
Сначала про рандомизацию. Я вижу две проблемы:
1. Проблема верификации про которую Вы написали. Одно из преимуществ схемы given-then состоит в том, что в части then мы сравниваем актуально значение с константой, полученной как-нибудь из других источников (например, на бумажке). Это уменьшает вероятность того, что в тесте, при подсчете, будет допущена та же самая ошибка, что и в тестируемом коде. В случае given(спектр)-then(спектр) конечное значение необходимо либо тоже вычислять, что плохо, либо, как Вы написали, как-то сравнивать по диапазонам, среднему и пр., но тогда пропадает точность, т.е. можем пропустить баг.
2. Главная цель написания тестов — защита от регрессии. Вероятностные же тесты могут ее пропустить. Единственный выход — запускать их много раз, но это сильно увеличивает время работы тестов, а вероятность пропуска ранее оттестированной баги все равно выше нуля.
На самом деле, я вот сейчас о чем подумал. Глобально, баги делятся на две категории:
1. Обработанный случай, но код обработки содержит ошибку.
2. Про этот случай забыли и его обработки просто нет.
Так вот, вероятностное тестирование помогает находить баги второй категории, причем ненадежно и нестабильно. Классическое же находит баги первой категории. Причем (при качественной реализации) делает это абсолютно точно, надежно, стабильно. По крайней мере, способно на это хотя бы в теории. Т.е. при классическом подходе если у меня есть тест, проверяющий какой-то инвариант при каких-то условиях, то после очередной правки кода я буду уверен, что конкретно этот инвариант при конкретно этих условиях все еще сохраняется. При вероятностных тестах, я не могу быть уверен.
Так же, почти никогда нет случайного числа 109.11. У входных данных есть допустимые диапазоны и их граничные значения. Практически всегда ошибка на граничном значении и/или на всем диапазоне. Очень редко ошибка в конкретной точке допустимого диапазона (не граница), при том, что весь остальной диапазон работает корректно. Да и в этом случае, крайне маловероятно что вероятностный тест попадет именно в это точку. Как следствие, достаточно протестировать каждый модуль на каждом граничном значение, а так же произвольной точке из каждого диапазона. В большинстве случаев это будет полное покрытие модуля, причем стабильное и надежное.
Теперь про разделение.
1. Если я правильно понял, то, по сути, Вы предлагаете не объединить модульное и функциональное тестирование, а полностью выкинуть первое и оставить только второй, но обязательно с рандомизацией. Про нее я уже достаточно написал. А без рандомизации данная схема уже не работает.
2. У системы может быть много труднодостижимых состояний. В честных функциональных тестах их обычно тяжело протестировать.
3. Самый важный пункт. Модульные тесты значительно проще. Достаточно создать тариф (хоть из моков), вызвать функцию calculateCost(tariff) и заассертить результат. Все. И если подсчет цены работает неправильно, то абсолютно пофиг как и откуда этот тариф был получен.
4. Как следствие пред. пункта, модульные тесты работают быстрее, это способствует их более частому запуску.
Я не против функциональных тестов, но скорее как инструмент проверки стыковки модулей, а не полного тестирования приложения. Грубо говоря, штук 10 на все.
P.S. Вроде получилось сумбурно и размазано одновременно, прошу за это прощения.
Вам не за что просить прощения — конструктивная критика всегда приветствуется.
По проблемам:
1. Я за вычисление. Независимое вычисление. Которое проверит ожидаемый результат исходя из этих вычислений
2. Вероятностные тесты не могут пропустить регрессию. Они делают ровно то же, что и обычные тесты. К примеру, обычный тест нажимает на калькуляторе 2, +, 2, = и проверяет, что результат 4. Рандомизированный тест нажимает a, +, b, = (a+b). Да он берёт на себя логику по проверке суммирования. Но зато, в случае, если существуют значения, на которых сумма по каким-то неведомым причинам не сходится, то это причина для «посмотреть код». Фишка в том, что тесты гонять нужно ровно столько же сколько и раньше, просто в них появляется фактор нестабильности, напрямую отвечающий за отлавливание багов на данных, на которых ни один тестировщик не подумает их искать. Утрируя, 99 случаев из 100 обычный тест и рандомизированный будут вести себя одинаково — цель добиться, чтобы это было в 100 случаях из 100. Не нужно запускать рандомизированные тесты по 100 раз — гоняйте как и раньше, но внимательно следите за теми, которые «иногда» не проходят — поймите причины — найдите проблему.
Говоря о 109.11, я имел ввиду не точку на пространстве возможных значений, а точку из класса значений, с которыми округление ведёт себя неверно. Таких точек может быть много… Это же метафора…
1. «а полностью выкинуть первое и оставить только второй» — вы неправильно меня поняли. Я предлагаю выкинуть модульное там, где оно может быть покрыто рандомизированным функциональным, да и то не везде. Если проверяется хитрый алгоритм реализованный в недрах нескольких классов, то лучше, конечно, модульным. Если же речь идёт о том, что при нажатии на кнопку у контроллера спрашиваются данные, а потом передаются на вход хранимой процедуре, то есть два подхода — модульно вызовем метод со значениями какими-нибудь, а потом проверим, что в базе. Или же функционально нажмём кнопку и проверим, что в базе. При таком выборе я за второе, потому что в функциональное поведение первично. К примеру, — в реально работающей программе в контроллере нашем оказались пустыми какие-то значения и какие -то значения придут пустыми или некорректными. Хранимая процедура отработает, запишет всё в базу и модульный тест будет зелёный. Функциональный тест при этом упадёт. Как альтернатива этому одному функциональному — декартово произведение всех возможных входных параметров для модульного теста :) Но это будет дороговато и утомительно. В этом была моя мысль
2. Труднодостижимые состояния (если они не приводят к тому, что ПО останавливает свою работу) некритичны для пользователя, так как они редко по этим сценариям ходят. Закладывать в автомобиль стабилизацию курсовой устойчивости на случай замлетрясения также бессмысленно, как пытаться автоматически достичь этих самых труднодостижимых состояний.
3. Модульный тесты до тех пор проще, пока автоматические не становятся проще модульных :) Ещё надо создать «кривой» тариф, nullевой тариф, tariff, который меняется из другого потока — такое же тоже может вдруг случиться… Фуyкциональные тесты (рандомизированные) это выловят — если такое когда-нибудь произойдёт. Модульные вы так писать не станете. Модульные проверяют утверждение «эта отвёртка умеет откручивать эти винты», хотя в реальной работе системы могут оказаться другие винты. Да — эта отвёртка в большинстве случаев справится и с ними. Но если появится винт, с которым она не справляется, функциональный тест упадёт, пояснив, что при таком винте и при использовании этой отвёртки винт почему-то в конце не у нас в руках, а по-прежнему закручен в доску. Модульный тест будет по-прежнему зелёным потому что работает с тем винтом, с которым у него всё хорошо.
4. Да — это отдельный пункт. И самая главная критика автоматических тестов. Но, если не пользоваться sleep-ами, автоматические тесты начинают летать — habrahabr.ru/company/crystal_service/blog/251339/ — в конце этого моего поста есть ссылка на ютюб. Можете посмотреть видео.
Я на самом деле пытаюсь толкнуть теорию тестирования вперёд и мне очень интересны подобные споры. Я сам в целом разработчик, которого прёт от создания тестовых фрэймворков. Мне не нравятся классические идеи тестирования, потому что они рождались, когда мы жили в мире описанных хорошо или плохо, но всё-таки тех-заданий. Сейчас современное программирование и IT-бизнес, стараются идти от пользователя, развиваются и активно внедряются идеологии Agile. И меня можно было бы поругать, что я вот тут что-то придумываю и предлагаю голословно — но вот уже два проекта внедрены более чем успешно именно на этих идеях. Возможно, они не везде подходят — хочется об этом узнать, конечно. Но проблем с регрессией нет, вылавливаются баги, которые никогда бы не были выявлены никем кроме как пользователями продукта, все счастливы.
По проблемам:
1. Я за вычисление. Независимое вычисление. Которое проверит ожидаемый результат исходя из этих вычислений
2. Вероятностные тесты не могут пропустить регрессию. Они делают ровно то же, что и обычные тесты. К примеру, обычный тест нажимает на калькуляторе 2, +, 2, = и проверяет, что результат 4. Рандомизированный тест нажимает a, +, b, = (a+b). Да он берёт на себя логику по проверке суммирования. Но зато, в случае, если существуют значения, на которых сумма по каким-то неведомым причинам не сходится, то это причина для «посмотреть код». Фишка в том, что тесты гонять нужно ровно столько же сколько и раньше, просто в них появляется фактор нестабильности, напрямую отвечающий за отлавливание багов на данных, на которых ни один тестировщик не подумает их искать. Утрируя, 99 случаев из 100 обычный тест и рандомизированный будут вести себя одинаково — цель добиться, чтобы это было в 100 случаях из 100. Не нужно запускать рандомизированные тесты по 100 раз — гоняйте как и раньше, но внимательно следите за теми, которые «иногда» не проходят — поймите причины — найдите проблему.
Говоря о 109.11, я имел ввиду не точку на пространстве возможных значений, а точку из класса значений, с которыми округление ведёт себя неверно. Таких точек может быть много… Это же метафора…
1. «а полностью выкинуть первое и оставить только второй» — вы неправильно меня поняли. Я предлагаю выкинуть модульное там, где оно может быть покрыто рандомизированным функциональным, да и то не везде. Если проверяется хитрый алгоритм реализованный в недрах нескольких классов, то лучше, конечно, модульным. Если же речь идёт о том, что при нажатии на кнопку у контроллера спрашиваются данные, а потом передаются на вход хранимой процедуре, то есть два подхода — модульно вызовем метод со значениями какими-нибудь, а потом проверим, что в базе. Или же функционально нажмём кнопку и проверим, что в базе. При таком выборе я за второе, потому что в функциональное поведение первично. К примеру, — в реально работающей программе в контроллере нашем оказались пустыми какие-то значения и какие -то значения придут пустыми или некорректными. Хранимая процедура отработает, запишет всё в базу и модульный тест будет зелёный. Функциональный тест при этом упадёт. Как альтернатива этому одному функциональному — декартово произведение всех возможных входных параметров для модульного теста :) Но это будет дороговато и утомительно. В этом была моя мысль
2. Труднодостижимые состояния (если они не приводят к тому, что ПО останавливает свою работу) некритичны для пользователя, так как они редко по этим сценариям ходят. Закладывать в автомобиль стабилизацию курсовой устойчивости на случай замлетрясения также бессмысленно, как пытаться автоматически достичь этих самых труднодостижимых состояний.
3. Модульный тесты до тех пор проще, пока автоматические не становятся проще модульных :) Ещё надо создать «кривой» тариф, nullевой тариф, tariff, который меняется из другого потока — такое же тоже может вдруг случиться… Фуyкциональные тесты (рандомизированные) это выловят — если такое когда-нибудь произойдёт. Модульные вы так писать не станете. Модульные проверяют утверждение «эта отвёртка умеет откручивать эти винты», хотя в реальной работе системы могут оказаться другие винты. Да — эта отвёртка в большинстве случаев справится и с ними. Но если появится винт, с которым она не справляется, функциональный тест упадёт, пояснив, что при таком винте и при использовании этой отвёртки винт почему-то в конце не у нас в руках, а по-прежнему закручен в доску. Модульный тест будет по-прежнему зелёным потому что работает с тем винтом, с которым у него всё хорошо.
4. Да — это отдельный пункт. И самая главная критика автоматических тестов. Но, если не пользоваться sleep-ами, автоматические тесты начинают летать — habrahabr.ru/company/crystal_service/blog/251339/ — в конце этого моего поста есть ссылка на ютюб. Можете посмотреть видео.
Я на самом деле пытаюсь толкнуть теорию тестирования вперёд и мне очень интересны подобные споры. Я сам в целом разработчик, которого прёт от создания тестовых фрэймворков. Мне не нравятся классические идеи тестирования, потому что они рождались, когда мы жили в мире описанных хорошо или плохо, но всё-таки тех-заданий. Сейчас современное программирование и IT-бизнес, стараются идти от пользователя, развиваются и активно внедряются идеологии Agile. И меня можно было бы поругать, что я вот тут что-то придумываю и предлагаю голословно — но вот уже два проекта внедрены более чем успешно именно на этих идеях. Возможно, они не везде подходят — хочется об этом узнать, конечно. Но проблем с регрессией нет, вылавливаются баги, которые никогда бы не были выявлены никем кроме как пользователями продукта, все счастливы.
Sign up to leave a comment.
Риски и метрики в автоматизации тестирования