Здравствуйте, Poopy Joe, Вы писали:
N>>Это очень прикольно, учитывая, что 1) я никогда не говорил, что ведём "разработку через тестирование", 2) никогда не утверждал отсутствие багов как результат применения тестов.
PJ>
PJ>Для того, чтобы с достаточной уверенностью доверять результатам тестов, нужно:
PJ>1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
PJ>2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
PJ>3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
PJ>4) Доверие среде и библиотекам.
PJ>Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
PJ>Погоди, перед тем как уйдешь, позови, пожалуйста, того, кто писал эту цитату с твоего аккаунта.
"С практически достаточной уверенностью". Но не абсолютно.
Когда поймёшь разницу и расскажешь про это — продолжим.
Здравствуйте, netch80, Вы писали:
N>Этого не понял — это для какого языка так? N>Если описано внешнее требование, то существенные ошибки приведут к нарушению доказательства.
Покажи пример, а то мне непонятно.
I>>Здесь ничего странного. Сценариев обычно немного, несколько десятков или сотен. Это все реализуемо относительно небольшими затратами.
N>Хм, попытался подсчитать сценарии в своём текущем продукте — со всеми вариациями идёт на десятки тысяч. N>А всего-то: паркинг против пикапа, транскодинг/трансрейтинг данных, прохождение NAT, темпы реавторизации, ещё десяток факторов... N>и разделить, зараза, нельзя толком...
Таких проектов нынче капля в море, к сожалению. Типичный проект это гораздо более простые вещи.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Почему нельзя воспользоваться требованиями, методиками, подходами и далее по списку, в отношении решения, а не теста? Этого либо достаточно, либо еще нужен тест для теста для теста...
Кто сказал, что нельзя? Пользуйся сколько угодно. Только это не отменяет тесты, нисколько. А раз так, то все это нужно применять и к тестам.
Тест теста в большинстве случаев заменяется на верификацию — посмотрели, прошли чеклист, закрыли. С кодом самого приложения тоже многие вещи решаются верификацией.
PJ>Для того, чтобы с достаточной уверенностью доверять результатам тестов, нужно:
PJ>1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
PJ>2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
PJ>3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
PJ>4) Доверие среде и библиотекам.
PJ>Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
PJ>Погоди, перед тем как уйдешь, позови, пожалуйста, того, кто писал эту цитату с твоего аккаунта.
Здравствуйте, Poopy Joe, Вы писали:
N>>"С практически достаточной уверенностью". Но не абсолютно.
PJ>В системе, где должно быть багов 0, найдено 30. Я бы сказал это крайне низкий порог для любого уровня уверенности.
"должно быть 0 багов" — это неадекватное ожидание. Никто и никогда, ни при каких условиях, не может гарантировать выполнение этого требования.
То есть, нет способа различить две ситуации — "нет багов" и "мы не знаем, есть ли новые неизвестные баги".
Здравствуйте, Ikemefula, Вы писали:
I>То есть, нет способа различить две ситуации — "нет багов" и "мы не знаем, есть ли неизвестные баги".
Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п.
И тем не менее можно для каждого набора входных данных проверить корректность состояния и быть увереным, что багов
нет. Но это только для простых случаев. Т.е. в теории ситуация "нет багов" возможна, на практике -- едва ли.
Здравствуйте, Sharov, Вы писали:
I>>То есть, нет способа различить две ситуации — "нет багов" и "мы не знаем, есть ли неизвестные баги".
S>Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п.
Каким образом понять, что некто воспользовался этим инструментом, а не накида КА на глазок?
Каким образом понять, что интеграция этого КА сделана как положено, а не просто затычкой вида "и так сойдет" ?
Здравствуйте, Ikemefula, Вы писали:
S>>Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п. I>Каким образом понять, что некто воспользовался этим инструментом, а не накида КА на глазок?
1)КА реализуется программистом, верфицируется кодом.
2)Ответ на вопрос выше -- соотв. процессом.
I>Каким образом понять, что интеграция этого КА сделана как положено, а не просто затычкой вида "и так сойдет" ?
Соотв. процессом.
Если пилится софт для каких-то космических миссий, где запуск стоит 100млн$ долларов, и делается только один раз --
то только соотв. организацией и процессами.
Под процессом имеется в виду соотв. инструменты, системы сборки, тесты, code review и, вероятно, много чего еще.
На глазок в подобным проектах никто ничего не делает.
То же самое и для авионики и подобных критических систем.
Но речь о том, что софт вполне себе можно верифицировать.
А ошибки будут либо на уровне тз (метры с дюймами попутали, читал где-то про какой-то луноход или что-то в этом роде:
в одном месте дюймы, в другом метры -- ну и что-то куда улетело не туда). В тз четко это не было прописано, поэтому каждый
модуль мог делать по своему. Либо ошибки железа. Но это др. история.
Здравствуйте, Sharov, Вы писали:
S>>>Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п. I>>Каким образом понять, что некто воспользовался этим инструментом, а не накида КА на глазок?
S>1)КА реализуется программистом, верфицируется кодом. S>2)Ответ на вопрос выше -- соотв. процессом.
Ты опредились, код или процесс. Если процесс, то он всегда двигается людьми, т.е. некто должен посмотреть глазом, что все идет путём.
I>>Каким образом понять, что интеграция этого КА сделана как положено, а не просто затычкой вида "и так сойдет" ?
S>Соотв. процессом.
Именно. Ибо код принципиально не может решить задачу "кто будет сторожить сторожа"
S>Под процессом имеется в виду соотв. инструменты, системы сборки, тесты, code review и, вероятно, много чего еще. S>На глазок в подобным проектах никто ничего не делает.
Делают, только такие попытки не проходят верификацию.
S>Но речь о том, что софт вполне себе можно верифицировать.
Ок. начинаем сначала — кто проверит, что КА ты накидал не от балды, а руководствовался внятным подходом?
S>А ошибки будут либо на уровне тз (метры с дюймами попутали, читал где-то про какой-то луноход или что-то в этом роде:
А еще бывают ошибки, когда некто струячит в духе "и так сойдет"
И все это покрывает вечно-зелеными тестами.
Здравствуйте, Ikemefula, Вы писали:
S>>1)КА реализуется программистом, верфицируется кодом. S>>2)Ответ на вопрос выше -- соотв. процессом. I>Ты опредились, код или процесс. Если процесс, то он всегда двигается людьми, т.е. некто должен посмотреть глазом, что все идет путём.
Так, наверное, почти любой процесс можно автоматизировать.
S>>Под процессом имеется в виду соотв. инструменты, системы сборки, тесты, code review и, вероятно, много чего еще. S>>На глазок в подобным проектах никто ничего не делает. I>Делают, только такие попытки не проходят верификацию.
Ну и хорошо.
S>>Но речь о том, что софт вполне себе можно верифицировать. I>Ок. начинаем сначала — кто проверит, что КА ты накидал не от балды, а руководствовался внятным подходом?
Другой код. Который проверяет вход и выход. Как пример.
S>>А ошибки будут либо на уровне тз (метры с дюймами попутали, читал где-то про какой-то луноход или что-то в этом роде: I>А еще бывают ошибки, когда некто струячит в духе "и так сойдет" I>И все это покрывает вечно-зелеными тестами.
Докопаться можно до чего угодно, было бы желание. В проектах о которых я говорил, надеюсь, подобного нет. Там все и все
под контролем. Это сложно, но разрабатывают они на относительно простых языках без всякой многопоточности. Это легче.
I>Какой код проверит, что твои тесты вечнозелёные?
К чему этот вопрос, заданный выше не один раз в той или иной форме. И да, в коде верификатора тоже могут быть ошибки.
Но я повторю, что написать корректную программу вполне не сложно. Написать большую и сложную корректную программу очень и очень
сложно.
Здравствуйте, Sharov, Вы писали:
I>>Ты опредились, код или процесс. Если процесс, то он всегда двигается людьми, т.е. некто должен посмотреть глазом, что все идет путём.
S>Так, наверное, почти любой процесс можно автоматизировать.
Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость.
S>>>Но речь о том, что софт вполне себе можно верифицировать. I>>Ок. начинаем сначала — кто проверит, что КА ты накидал не от балды, а руководствовался внятным подходом?
S>Другой код. Который проверяет вход и выход. Как пример.
Никакой гарантии. Тот, кто пишет абы как, и этот другой код тоже напишет абы как.
S>Докопаться можно до чего угодно, было бы желание. В проектах о которых я говорил, надеюсь, подобного нет. Там все и все S>под контролем. Это сложно, но разрабатывают они на относительно простых языках без всякой многопоточности. Это легче.
Вопрос в том, как именно этот контроль реализован.
I>>Какой код проверит, что твои тесты вечнозелёные?
S>К чему этот вопрос, заданный выше не один раз в той или иной форме.
А ты продолжаешь утверждать, что это можно как то автоматизировать. Вот мне и интересно, что это за чудо.
Скажем, до сих пор никто не может автоматизировать поиск новых багов. Кое что можно находить автоматически. А вот полностью заменить поиск новых, неизвестных багов еще пока никто не научился.
И верифицировать произвольный код тоже никто не научился автоматически.
S>>Так, наверное, почти любой процесс можно автоматизировать. I>Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость.
Что такое вечнозеленость? Проверить, прошел тест или нет, не то?
S>>Другой код. Который проверяет вход и выход. Как пример. I>Никакой гарантии. Тот, кто пишет абы как, и этот другой код тоже напишет абы как.
А кто сказал, что это один и тот же человек? Скорее всего это всегда будут разные люди. Человек, написавший
какой-нибудь верфикатор, и человек, написавшей прикладное ПО, скорее всего всегда будут разными людьми.
S>>Докопаться можно до чего угодно, было бы желание. В проектах о которых я говорил, надеюсь, подобного нет. Там все и все S>>под контролем. Это сложно, но разрабатывают они на относительно простых языках без всякой многопоточности. Это легче. I>Вопрос в том, как именно этот контроль реализован.
Ну посмотрите или почитайте как в том же NASA процесс организован. Я как-то читал и понял, что пишут они на каком-то
Си подобном диалекте, куча тестов и др. инструментов для валидации корректности кода.
S>>К чему этот вопрос, заданный выше не один раз в той или иной форме. I>А ты продолжаешь утверждать, что это можно как то автоматизировать. Вот мне и интересно, что это за чудо.
Я же не категорично утверждал, верно. Ну вот как-то всяческие спутники и прочие марсоходы и луноходы выполняю свою
миссию. Как-то все это делается, и большая вероятность, что не через ручной труд или с самым его минимумом.
I>Скажем, до сих пор никто не может автоматизировать поиск новых багов. Кое что можно находить автоматически. А вот полностью заменить поиск новых, неизвестных багов еще пока никто не научился. I>И верифицировать произвольный код тоже никто не научился автоматически.
Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь.
Вы на многие свои вопросы можете найти ответы банальным гуглежом по практикам НАСА или как крупные компании повышают качество своего кода.
Здравствуйте, Sharov, Вы писали:
S>>>Так, наверное, почти любой процесс можно автоматизировать. I>>Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость.
S>Что такое вечнозеленость? Проверить, прошел тест или нет, не то?
Вечнозеленый тест, это который никогда не фейлится, что бы ни ломалось в коде.
Тесты зеленые — компоненты не работают, степень покрытия — 99% строк в коде.
S>Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь.
А что, диалект как то решает проблему "и так сойдёт" ?
Здравствуйте, Ikemefula, Вы писали:
I>>>Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость. S>>Что такое вечнозеленость? Проверить, прошел тест или нет, не то? I>Вечнозеленый тест, это который никогда не фейлится, что бы ни ломалось в коде. I>Тесты зеленые — компоненты не работают, степень покрытия — 99% строк в коде.
Ну значит требовать 100% покрытия.
S>>Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь. I> А что, диалект как то решает проблему "и так сойдёт" ?
"И так сойдет" обязательный code review, тесты и замеры производительности могут выявить. Но степень свободы в таких
диалектах явно будет меньше, т.е. возможности налажать и выстрелить в ногу будет меньше.
В целом хороший вопрос, а как борются с не оптимально написанным кодом, который корректно решает проблему?
Замеры, code review. Что тут еще можно придумать? Наверное в компаниях типа NASA с мотивацией сотрудников все в порядке,
т.е. сотрудники не позволяют себе "и так сойдет", а делают все оптимально возможным образом +
минимум аджайла, когда нужно было вчера и т.п. подобные организационные вещи. Т.е. личные кач-ва сотрудников + соотв. процессы.
А как иначе?
Хотя вот Boeing это не очень помогло, но там видимо был лютый бардак в процессах.
Здравствуйте, Sharov, Вы писали:
I>>Вечнозеленый тест, это который никогда не фейлится, что бы ни ломалось в коде. I>>Тесты зеленые — компоненты не работают, степень покрытия — 99% строк в коде.
S>Ну значит требовать 100% покрытия.
Это или невозможно, вообще говоря, в большинстве случаев, или же этот 1% будет таким же как и остальные 99%.
S>>>Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь. I>> А что, диалект как то решает проблему "и так сойдёт" ?
S>т.е. сотрудники не позволяют себе "и так сойдет", а делают все оптимально возможным образом + S>минимум аджайла, когда нужно было вчера и т.п. подобные организационные вещи. Т.е. личные кач-ва сотрудников + соотв. процессы. S>А как иначе?
Не стоит вообще не пытаться решать обозначеную проблему ни автоматизацией, ни кодом, ни покрытием, ни тестами-тестов.
Можно, например, внедрять код-ревью в котором верификация решения как обязательный чек поинт.
Собственно, почти всегда за такими вот тестами кроется и код, который писался ровно с таким же отношением к работе.
Людей замеченых в написании подобных решений отстранять, если не хотят работать иначе.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sharov, Вы писали:
S>>Ну значит требовать 100% покрытия. I>Это или невозможно, вообще говоря, в большинстве случаев, или же этот 1% будет таким же как и остальные 99%.
А как такое возможно в случае 100%? Это значит что результат работы ф-ий банально не проверялся, код вроде бы не падает,
а работает не корректно. Это либо намеренно, либо . Если такое обнаруживается -- 100% покрытие, а ничего не работает --
то тут только серьезное разбирательство поможет и разговор с программистами.
S>>А как иначе? I>Не стоит вообще не пытаться решать обозначеную проблему ни автоматизацией, ни кодом, ни покрытием, ни тестами-тестов. I>Можно, например, внедрять код-ревью в котором верификация решения как обязательный чек поинт. I>Собственно, почти всегда за такими вот тестами кроется и код, который писался ровно с таким же отношением к работе. I>Людей замеченых в написании подобных решений отстранять, если не хотят работать иначе.
Как вариант, но лучше больше инструментария задействовать чем только cr.
Здравствуйте, Sharov, Вы писали:
I>>Это или невозможно, вообще говоря, в большинстве случаев, или же этот 1% будет таким же как и остальные 99%.
S>А как такое возможно в случае 100%?
Элементарно — тесты написаны кое как.
Более того, когда менеджеры спускают требование 100% именно так и случается — вечнозеленые тесты повсюду, абы достичь этих процентов.
По этой причине никогде не нужно задирать планку выше разумного.
S>>А как такое возможно в случае 100%? I>Элементарно — тесты написаны кое как. I>Более того, когда менеджеры спускают требование 100% именно так и случается — вечнозеленые тесты повсюду, абы достичь этих процентов. I>По этой причине никогде не нужно задирать планку выше разумного.
За исключением тех случаев, когда эти 100% действительно нужны.
Здравствуйте, Sharov, Вы писали:
I>>Элементарно — тесты написаны кое как. I>>Более того, когда менеджеры спускают требование 100% именно так и случается — вечнозеленые тесты повсюду, абы достичь этих процентов. I>>По этой причине никогде не нужно задирать планку выше разумного.
S>За исключением тех случаев, когда эти 100% действительно нужны.
Это не добавляет качества, а количество работы удесятеряет. Стоит покрывать не строчки кода, а ключевые кейсы. Здесь проценты не зафиксируешь, зато эффекта будет гораздо больше.
Нужно понимать, что 100% это всего лишь про строчки, а не ветвления.
То есть, покрыв 100% строчек можно нисколечко не приблизиться к покрытию основных кейсов.
Считать ветвления еще не научились, а простой подсчет говорит о том, что покрытие ветвлений требует астрономическое количество тестов.
Зато покрытие основных кейсов вполне может дать покрытие 80% строчек. Остальное покроется тестами верхнего уровня, тестами на стейджинге и тд.
А что, диалект как то решает проблему "и так сойдёт" ?
. Если такое обнаруживается -- 100% покрытие, а ничего не работает --