Для проведения теста Тьюринга нужно грамотно выбрать группу экспертов. Иначе это будет профанация.
Как это сделать? А очень просто, с помощью обратного теста Тьюринга. Т.е. если группа экспертов не может отличить человека от компьютера, то мы её выгоняем.
А теперь серьёзно. Существует практический аспект обратного теста Тьюринга.
Это методика обратного тестирования. Я её использую при разработки ответственного софта.
Суть её в следующем. Мы пишем некоторый софтварный компонент.
Далее мы пишем тесты для него. Прогоняем.
Большинство программистов на этой стадии останавливаются. Но останавливаться не надо.
Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты.
Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Здравствуйте, Шахтер, Вы писали:
Ш>Это методика обратного тестирования. Я её использую при разработки ответственного софта. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Отлично! Так и надо. Только дефекты в коде уже есть, их не надо вносить, их надо искать вручную.
Здравствуйте, Шахтер, Вы писали:
Ш>Для проведения теста Тьюринга нужно грамотно выбрать группу экспертов. Иначе это будет профанация. Ш>Как это сделать? А очень просто, с помощью обратного теста Тьюринга. Т.е. если группа экспертов не может отличить человека от компьютера, то мы её выгоняем.
Вообще-то обратный тест — это когда эксперты не могут отличить человека от бота
Ш>А теперь серьёзно. Существует практический аспект обратного теста Тьюринга. ... Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Эмм, это к Тьюрингу не имеет никакого отношения, обычная проверка на false positives. Имхо, такие вещи не должны использоваться в сколько-нибудь серьёзных проектах. Доводы следующие:
1. Введение дефектов не автоматизируется, т.е. регулярно выполняться не будет. Получаем реальный шанс false positive в тестах на false positive. Need to go deeper?
2. (*если мы говорим о юнит-тестах) Тесты не должны тестировать внутренности реализации, только отслеживать соответствие "тестируемое поведение <-> спецификация API". Любая попытка "заглянуть глубже" неизменно приводит к тому, что расходы на тестирование перекрывают выигрыш на порядок.
То же самое, но чуть другими словами: если баг не затрагивает тестируемое поведение, то тест не может/не должен обнаруживать косяки. Например, если при тестировании API калькулятора у нас идёт утечка памяти, запись мусора в базу или пропадают кнопки в UI model, но все суммы сходятся, то тест пройден, как бы парадоксально это не звучало.
За ловлю вышеперечисленных косяков должны отвечать или специализированные тесты (интеграционные, дифф-тесты, ui-тестирование), или, ещё лучше, ассерты. В пользу ассертов говорит то, что они работают всегда и позволяют отловить косяки, которые в тепличных условиях юнит-теста фиг воспроизведёшь.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Шахтер, Вы писали:
Ш>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
J>Звучит как TDD наоборот J>В смысле, в TDD тесты сначала должны валиться, а в конце все хорошо, а тебя наоборот.
Тесты валится не должны. Они валится могут, если ты сделал ошибку в коде.
Вопрос в другом -- в достаточности множества тестов.
Здравствуйте, Шахтер, Вы писали:
Ш>>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
J>>Звучит как TDD наоборот J>>В смысле, в TDD тесты сначала должны валиться, а в конце все хорошо, а тебя наоборот.
Ш>Тесты валится не должны. Они валится могут, если ты сделал ошибку в коде.
Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты.
А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими.
И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов).
И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Ш>Вопрос в другом -- в достаточности множества тестов.
Да я понял Просто есть сходство.
Здравствуйте, Sinix, Вы писали:
S>Вообще-то обратный тест — это когда эксперты не могут отличить человека от бота
Не, обратный — это когда комп может отличить человека от бота
Здравствуйте, jazzer, Вы писали:
J>Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты. J>А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими. J>И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов). J>И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Я считаю TDD халтурой. Потому что не имея кода нельзя написать разумную систему тестов. В лучшем случае TDD вскроет ошибки в алгоритмах. Для того, что бы вскрыть ошибки в реализации, надо проанализировать код
и писать тесты отталкиваясь от кода. Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
Здравствуйте, Шахтер, Вы писали:
Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты.
это очень древняя методика. она использовалась еще когда ассемблера не было.
в программу умышленно вносится определенное число ошибок. пускай для определенности сто. если в результате тестирования выявлено только 50, то это позволяет нам оценить качество тестирования и кол-во скрытых ошибок в релизе.
так что новое это хорошо забытое старое.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, jazzer, Вы писали:
J>>Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты. J>>А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими. J>>И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов). J>>И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Ш>Я считаю TDD халтурой. Потому что не имея кода нельзя написать разумную систему тестов. В лучшем случае TDD вскроет ошибки в алгоритмах.
Не совсем так. Ты в любом случае ведь пишешь код, отталкиваясь от требований к нему. Начиная от функциональных требований (что должен делать и когда какие результаты выдавать) и заканчивая нефункциональными (время работы и т.п.). TDD требует выразить все эти требования в виде тестов к еще ненаписанному коду.
Это позволяет (по моему собственному опыту) сконцентрироваться именно на требованиях и на разных темных углах и узких местах спецификации и проработать вопрос гораздо глубже, чем при написании тестов после кода.
Тут очень важно, что кода еще нет — реализация не застит глаза, и ты пишешь тесты, отталкиваясь о того, что код должен делать, а не от того, что он (случайно) делает в данной реализации.
Ш>Для того, что бы вскрыть ошибки в реализации, надо проанализировать код и писать тесты отталкиваясь от кода.
В качестве второго этапа — можно, но это не отменяет рулезов TDD.
Ну и потом это тоже ведь хождение по граблям.
Ну будет у тебя в реализации какая-то особая точка, скажем, ты делишь на 3-x, и поэтому надо особо обрабатывать случай x=3. Ну, допустим, ты это заметил, даже тест написал. А потом пересчитал свою матмодель и поменял реализацию на 5-x — все твои существующие тесты замечательно это схавают, если в них случайно не будет проверки случая x=5 (а с чего бы). И что, выкинуть 3, добавить 5? или добавить тестирование всего натурального ряда, и заодно числа пи — мало ли как еще изменится реализация?
Ш>Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
Предполагается, что людям для определения разумности собеседника достаточно иметь представление о разумности вообще.
А вот знать устройство мозга и биоэлектрохимию синапсов для этого совсем необязательно.
Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Я читал про такое тестирование ещё в древней университетской методичке. К сожалению, не могу вспомнить имя лектора и найти методичку. Почему-то все любители Unit тестирования очень обижаются, когда я предлагаю им проверить качество их тестирования, например, элементарно заменив >= на > в некоторых местах.
Здравствуйте, jazzer, Вы писали:
Ш>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
J>Звучит как TDD наоборот J>В смысле, в TDD тесты сначала должны валиться, а в конце все хорошо, а тебя наоборот.
Это не тдд наоборот, это контроль качества тестов. С тдд очень легко написать код, в котором тесты будут проверять только моки и тестовые данные.
Здравствуйте, Sinix, Вы писали:
S>Эмм, это к Тьюрингу не имеет никакого отношения, обычная проверка на false positives. Имхо, такие вещи не должны использоваться в сколько-нибудь серьёзных проектах. Доводы следующие:
S>1. Введение дефектов не автоматизируется, т.е. регулярно выполняться не будет. Получаем реальный шанс false positive в тестах на false positive. Need to go deeper?
Да, задача не автоматизируется. Но это не значит, что нужно забивать на неё. Написание логики тоже не автоматизируется. Зато с помощью предложеного способа можно найти куски проекта, кторые как бы покрыты тестами, а на самом деле тесты или работают при нерабочем приложении, или отваливаются при рабочем приложении.
То есть, приложение не работает, но проходит тесты, или приложение работает но тесты не проходит. Если такие проблемы не свести к минимуму, то совершенно не ясно, для чего нужны собственно тесты.
Отсюда вопрос — покажи как свести к минимум эти проблемы, не пользуясь предложеным способом.
Здравствуйте, Ikemefula, Вы писали:
S>>1. Введение дефектов не автоматизируется, т.е. регулярно выполняться не будет. Получаем реальный шанс false positive в тестах на false positive. Need to go deeper? I>Да, задача не автоматизируется. Но это не значит, что нужно забивать на неё. Написание логики тоже не автоматизируется. Зато с помощью предложеного способа можно найти куски проекта, кторые как бы покрыты тестами, а на самом деле тесты или работают при нерабочем приложении, или отваливаются при рабочем приложении.
На мой взгляд, это шаманство в самом плохом смысле слова. Ну, как гадать на погоду по мокрому пальцу, когда рядом стоит метеостанция.
Уже есть стабильные, автоматизируемые, повторяемые методики тестирования. Ты сам наверно знаешь, просто перечислю:
* Для анализа покрытия тестами есть само покрытие тестами плюс поиск непокрытых вариантов через code flow analysis (см chess/pex).
* Для случайных ошибок-опечаток — компилятор, статический анализ, code contracts, валидация аргументов и ассерты.
* Для поиска неочевидных ошибок и нарушений любых инвариантов — всё те же ассерты и инструментирование через AOP (postsharp или инварианты в CodeContracts). Этот пункт великолепно уживается с отладочными сборками, интеграционными и ui-тестами. И, в отличие от юнит-тестов, как раз позволяют тестировать детали реализации.
* Для софта с экстремальными требованиями по надёжности есть полная статическая верификация и генерация кода по верифицированной матмодели + дифф-тесты по эталону.
Что может дать нового методика "ломаем код, запускаем" (aka мета-тестирование) с учётом всего вышеперечисленного?
Ну ок, допустим, тесты упали. Значит ли это что всё хорошо и тесты корректны? Нифига, нет никаких гарантий, что тесты не пропустят любую другую ошибку.
Допустим, тесты не упали. Это тоже не показывает ничего, кроме того что код надо смотреть. Возможно, ошибку внесли в код, который отключен на текущей итерации. Возможно, тесты не покрывают какой-то частный набор сценариев (который скорее всего нигде не используется). Возможно, обработка ошибок предусмотрена уровнем выше и оговорена в тестах. Возможно, ошибка ловится ассертом, который был отключен на время тестирования.
Ок, покрываем этот сценарий тестами. См предыдущий пункт — где гарантии, что покрыты все варианты, или что непокрытый код не появится потом?
В любом из вариантов мы узнаем только одно — надо разбираться в коде, чтобы определить где косяк: в тестах, в коде или в техзадании. Сорри, но то же самое известно и так, без лишних приседаний. По затратам: code review на предмет места для поломки + запуск тестов + анализ результатов + добавление тестов + тестирование добавленных тестов — мы обменяли иллюзию "у нас всё хорошо" где-то на пару-тройку незакрытых тикетов.
О чём и было сказано выше: любая попытка при помощи юнит-тестов "заглянуть глубже" публичного API неизменно приводит к тому, что расходы на тестирование перекрывают выигрыш на порядок.
I>То есть, приложение не работает, но проходит тесты, или приложение работает но тесты не проходит. Если такие проблемы не свести к минимуму, то совершенно не ясно, для чего нужны собственно тесты. I>Отсюда вопрос — покажи как свести к минимум эти проблемы, не пользуясь предложеным способом.
Элементарно — ассерты + использование кода
Давай ещё раз. Ни одно из средств тестирования само по себе не даёт гарантии, что в коде нет ошибок. В комплексе они также не дают 100% уверенности, но обеспечивают достаточный уровень надёжности софта.
Посмотри на блог PVS-Studio: что ни софт — так тонны глупых ошибок, опечаток, копипасты и тд и тп. Тем не менее, на практике ни одна из этих ошибок не была обнаружена раньше (кэп, ага). Очевидно, большинству клиентов от наличия/отсутствия этих ошибок ни холодно, ни жарко.
Мне понравился ответ на типовой вопрос в комментариях к одной из статей:
evocatus
Глупый вопрос: как вообще это всё работает? Вы уже немало статей написали с явными ошибками. Не синтаксическими, а логическими. Если их ещё не исправили, значит они не заметны и программа вроде как работает. Почему? Ведь надёжность сложной системы, составленной из блоков, меньше, чем сумма надёжностей этих блоков?
tzlom
Едет ли машина у которой не горят фары?
Так вот, тестирование через поломку кода нифига не поможет найти нерабочие фары. Максимум, поймать ДПС-ника, пропустившего машину, сдающую задним ходом с негорящим белым. Ну и нафига оно надо производителю? Особенно если учесть, что подобная ошибка скорее всего будет обнаружена пользователем раньше и починена при первом обращении в поддержку.
Здравствуйте, Sinix, Вы писали:
S>На мой взгляд, это шаманство в самом плохом смысле слова. Ну, как гадать на погоду по мокрому пальцу, когда рядом стоит метеостанция.
S>Уже есть стабильные, автоматизируемые, повторяемые методики тестирования. Ты сам наверно знаешь, просто перечислю:
Я просил не методики тестирования, а проверку тестов.
Как выяснить, что твои тесты действительно полезны ?
Здравствуйте, Шахтер, Вы писали:
J>>Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты. J>>А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими. J>>И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов). J>>И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Ш>Я считаю TDD халтурой. Потому что не имея кода нельзя написать разумную систему тестов.
ТДД это не написание системы тестов. ТДД оно про проектирование. Знать код не нужно, но вот представлять, как решается задача очень даже нужно. Скажем, нужно хотя бы представлять более-менее детально вычислительную модель.
>В лучшем случае TDD вскроет ошибки в алгоритмах. Для того, что бы вскрыть ошибки в реализации, надо проанализировать код Ш>и писать тесты отталкиваясь от кода. Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
ТДД это пример как хорошая методика из за плохого названия трактуется как попало.
Здравствуйте, De-Bill, Вы писали:
Ш>>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
DB>Я читал про такое тестирование ещё в древней университетской методичке. К сожалению, не могу вспомнить имя лектора и найти методичку. Почему-то все любители Unit тестирования очень обижаются, когда я предлагаю им проверить качество их тестирования, например, элементарно заменив >= на > в некоторых местах.
Я подозреваю, что мы просто решаем довольно разные по характеру задачи. Может TDD где-то и полезно, но я как-то не проникся.
Ш>>Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
J>Предполагается, что людям для определения разумности собеседника достаточно иметь представление о разумности вообще. J>А вот знать устройство мозга и биоэлектрохимию синапсов для этого совсем необязательно.
Это слишком низкий уровень. Нужен уровень логики.
Давай я приведу пример, чтобы моя мысль была более ясной. Представь, что мы проверяем уровень знаний с помощью системы тестов, типа ЕГЕ.
Вот машина взяла и ответила правильно на 100% вопросов, значит ли это, что она знает предмет? Вовсе нет, представь себе, что эта машина -- всего-навсего база данных готовых ответов.
Интелект способен рождать новую информацию. Но при тестировании нужно быть уверенным, что система действительно родила что-то новое, а не просто вспомнила, как надо отвечать в конкретном случае.
Не случайно, на экзаменах задают задачи и дополнительные вопросы на понимание. Чтобы отсеять безмозглых зубрил.
Здравствуйте, Ikemefula, Вы писали:
I>Я просил не методики тестирования, а проверку тестов.
А кто сказал, что тесты надо целенаправленно проверять? Какой риск мы этим устраняем?
Пропустить ошибку из-за некорректного теста? Так ошибку можно пропустить по сотне других причин, для лечения этих рисков есть тонна способов дешевле метатестирования — от статистики билд-сервера и до ретро-тестов, когда новый тест автоматом прогоняется на нескольких предыдущих версиях исходников. Вот тут как раз даже ломать ничего не надо — уже известно и когда поломалось, и когда починилось.
Остаться с неполным набором тестов? Так этот риск не устраняется в принципе, только сводится к приемлемому уровню. Опять-таки более дешёвыми способами.
Остаться с старой версией теста при новых исходниках? Так рандомные поломки кода никак этот риск не уменьшат.
В общем, нужна хоть одна причина по которой рутинное ручное тестирование может оказаться лучше и дешевле автоматизированного.
I>Как выяснить, что твои тесты действительно полезны ?
Если не скатываться к чисто формальным показателям типа покрытия, то только проверкой соотношения общих затрат на поддержку с тестами и без них. Других работающих способов я что-то не припомню.
Просто есть сходство.
