Управление качеством разработки микроконтроллерных систем

[andrej]

Моя личная искренняя благодарность тоже будет безгранична.

Господа, вы сами можете организовать свой закрытый клуб на закрытом форуме, где смогут отписываться только избранные, а еще лучше и читать тоже. Пользы будет намного больше, уверяю...

т.е. Ваше кредо - если где то не закрыто на замок (а лучше два), то туда можно ходить и гадить. удобно, да...

[Слесарь]

Мне это не нужно.
А искал я как обычно, http://ru.wikipedia.org/wiki/Unity

[Satyr]

Мне это не нужно.
А искал я как обычно, http://ru.wikipedia.org/wiki/Unity

Ты нам хочешь пожаловаться, что в википедии нет статьи о Unity или в чем был смысл того гениального послания ?

[andrej]

Мне это не нужно.
А искал я как обычно, http://ru.wikipedia.org/wiki/Unity

Ты нам хочешь пожаловаться, что в википедии нет статьи о Unity или в чем был смысл того гениального послания ?

это намек, что нам пытаются всучить фуфел, о котором даже вики не вкурсах.
тут все знают, что скрипки Страдивари делал для лохов, а для настоящих пасаноф он делал БАРАБАНЫ

[Слесарь]

Смысл в том, что упомянутая среда не популярна и совершенно не интересны тесты в отрыве от аппаратной части. А описать функционал который будет выводить сообщение об ошибке в случае нетипичной ситуации на время тестирования агрегата и дальнейшей эксплуатации, труда не составляет. Банально устанавливаю лампу аварии, которая на время тестирования агрегата специальной последовательностью миганий указывает на конкретную нетипичную ситуацию. Тоже и для последующей эксплуатации.
Этим существенно повышается качество разработки микроконтроллерной системы

[andrej]

Goldsmith я бы добавил еще пару тестов - для остро и тупоугольного треугольников.

А то был у нас случай, когда один из разработчиков отрефакторил класс, считая что у него все треугольники прямоугольные, забыв, что классом его еще другие пользуются....

[Goodefine]

т.е. Ваше кредо - если где то не закрыто на замок (а лучше два), то туда можно ходить и гадить. удобно, да...

Если Вы внимательно перечитаете мои сообщения в этой теме, то увидите, что я и слова против идеи тестирования не сказал. Я всего лишь описал ее так, как понимаю. Даже предыдущую тему вспомнил не я. А человек, который обвинял меня в "издании звуков в воду" или как то так. И понеслось. В тоже время он сам появился в той пресловутой теме со "своими" (читай чужими мыслями, бо своих не имеет) про "ужасное зло". И когда его попросили разъяснить выход из вполне конкретной ситуации, после бессмысленного примера от него более ничего не последовало, за исключением сообщений о всеобщей тупости. Как это назвать, как ни его же словами о "звуках в воде"? Надо терпимей относится к другой точке зрения, господа, а то такое ощущение, что юношеский максимализм зашкаливает...

[O-LED]

Ничего с обсуждением этой темы в данном месте не получится, все либо скатится в ругань и флуд, либо тихо мирно заглохнет.
Не верите?? Увидите!
Тема - нужная, хорошая, интересная, но как говорят на радио - "не формат".

[Goldsmith]

Goldsmith я бы добавил еще пару тестов - для остро и тупоугольного треугольников.

А то был у нас случай, когда один из разработчиков отрефакторил класс, считая что у него все треугольники прямоугольные, забыв, что классом его еще другие пользуются....

Это довольно тонкий момент. С одной стороны, желательно протестировать все ветви функции и все возможные сочетания параметров. С другой - лишние тесты тоже нежелательны. В идеальном тестовом наборе каждый тест отвечает за одну возможную ошибку. И наоборот, каждая ошибка вызывает провал ровно одного теста. В случае избыточности одна ошибка проваливает несколько тестов, и на первый взгляд не так легко определить, одна это ошибка или их сразу несколько.

В нашем случае (использована формула Герона) никак не разделяются остроугольные, прямоугольные и тупоугольные треугольники, формула одна для всех видов. Предположим, мы реализовали три теста. Если по какой-то причине формула "испортится" (например, из-за опечатки вместо (p-a) будет набрано (p+a) и т.п.), откажут сразу все три эти теста. В общем в этом нет ничего страшного, разобраться в такой ситуации будет несложно, но вообще так не принято.

Теперь рассмотрим такую ситуацию. Предположим, что некто нашел лучший способ решения задачи, но с отдельными формулами для каждого вида треугольников:

Код: Выделить всё

if (остроугольный)
  формула_1;
else if (тупоугольный)
  формула_2;
else // прямоугольный
  формула_3;

Все это замечательно, но в процессе улучшения формула_1 или формула_2 (а возможно, и обе) были реализованы с ошибкой. Но у нас имеется единственный тест для прямоугольного треугольника, т.е. реально тестируется только формула_3. Получается неприятная ситуация: после изменения кода все тесты прошли, а необнаруженные ошибки остались в коде. Три предложенных вами теста спасли бы положение.

Однако, к сожалению, все сочетания мы заранее предусмотреть не можем. Например, наш "благодетель" пошел дальше и ввел отдельные ветки для равнобедренных и равносторонних треугольников (разумеется, опять наделав ошибок). На эти случаи мы не догадались припасти тестов, а они очень бы пригодились. Получается, у нас как будто и есть тестовый набор, но он пропускает ошибки, как решето воду. Сама идея тестирования дтскредитируется.

К счастью, не все так плохо. Во-первых, как я упоминал в статье, желательно периодически профилировать выполнение тестов. Профиль покажет, что в процессе тестирования не все ветки проверяемой функции были выполнены, а значит, тестовый набор необходимо расширить. Во-вторых, в последней (на данный момент) статье, посвященной TDD, приводится важное правило: ни строчки кода без соответствующего теста. Если твердо придерживаться этого правила, все добавляемые ветки будут протестированы. Важно лишь придерживаться его и при разработке, и при рефакторинге.

Но в любом случае: если сомневаетесь, стоит ли добавлять тест, - обязательно добавьте. Избыточный тестовый набор гораздо лучше неполного.

[Goldsmith]

Ничего с обсуждением этой темы в данном месте не получится, все либо скатится в ругань и флуд, либо тихо мирно заглохнет.
Не верите?? Увидите!
Тема - нужная, хорошая, интересная, но как говорят на радио - "не формат".

По-моему, вы сильно недооцениваете уровень здешних обитателей. Да, он разный, полно неадеквата. Но есть и те, кто понимает, о чем речь, и интересуется темой. А профессионализм - товар штучный, сотен энтузиастов я и не ожидал увидеть. Да и ни на одном форуме они не водятся массово, а этот ничем не хуже других. "Формат" же задают посетители: если обсуждать темы только школьного уровня, то и формат будет соответствующий (содрал чужую схему, ничего не работает, спасите!).

Чтобы не гадили и не флудили в теме, достаточно просто не кормить троллей. Это не так уж весело - бубнить одну и ту же фразу, что "это никому не нужно" и что "писать программы нужно творчески". Пройдет немного времени - наговорятся сами с собой вдоволь и отпадут.

[Goodefine]

По-моему, вы сильно недооцениваете уровень здешних обитателей. Да, он разный, полно неадеквата.

Из этого следует что вы один из немногих адекватов? Или господь бог, чтоб давать другим оценки? Я вас умоляю, сделайте лицо попроще...

А профессионализм - товар штучный, сотен энтузиастов я и не ожидал увидеть. Да и ни на одном форуме они не водятся массово, а этот ничем не хуже других.

Именно поэтому вы открыли тему на типично радиолюбительском форуме, где профессионалов можно пересчитать по пальцам двух рук. А не на электрониксе, где процентов 80 личного состава профи, в полном смысле этого слова, которые реально занимаются разработкой. Забавно слышать, что вы там почитали темы и решили что это там не будет интересно. Вероятно поняли, что с вашими знаниями там делать нечего и откровениям, которые можно почитать в оригинале, тоже?

[Мастер Ломастер]

Если хотите, могу дать список толковых книг по азам программирования. Для быстрого чтения вот небольшая статья: http://www.gunsmoker.ru/2011/04/blog-post.html

в этой статье автор продемонстрировал, что называется, заказной характер статьи. по мере чтения не оставляло ощущение, что автору ну просто необходимо было доказать пагубность глобальных переменных, и он притягивал за уши все, что более-менее попадало под руку.

просто любо-дорого читать о том, как плохо при помощи глобальных переменных работать с функциями и как хорошо, когда переменные становятся локальными в функциях, в то время как в ПАСКАЛЕ, который автор выбрал в качестве основы своим доказательствам, просто не существует иного способа сохранить от вызова к вызову функции значение ЛОКАЛЬНОЙ переменной, кроме как сделав переменную глобальной... в общем, статья должна производить сильное впечатление на начинающих, но не производит. где-то попадалась статья о ПОЛЬЗЕ goto - она впечатляла больше

что касается основной темы обсуждения, то по-моему скромному мнению многие тут не понимают, что речь идет совсем не о поиске ошибок в поведении программы.... речь идет о проверке умения программиста ПЕРДУСМОТРЕТЬ варианты обработки нетипичных ситуаций. то есть если в программе вычисления площади треугольника НЕТ ПРОВЕРОК ВХОДНЫХ ПАРАМЕТРОВ, то и тестировать будет совершенно нечего. собственно, тестируется качество этих самых проверок, но отнюдь не качество итоговой программы. естественно, что если анализ ВХОДНЫХ данных на корректность сделан в полном объеме и качественно, предпосылок у программы работать НЕ ТАК, КАК НАДО становится существенно меньше... только и всего.

с учетом того, что очень многие любители вообще не обращают внимание на варнинги компилятора, довольствуясь сообщением "errors: 0", актуальность сей темы среди них все-таки сомнительна... а ведь простое сведение числа обрабатываемых вариантов switch-ем к определенному типу enum уже повышает качество кода, и даже тесты не понадобятся... но признайтесь, среди местного населения многие ли так делают?

[Goldsmith]

в общем, статья должна производить сильное впечатление на начинающих, но не производит.

Наверное, лучше разобрать пару-тройку конкретных случаев применения глобальных переменных, решить ту же задачу без них, а затем оценить плюсы и минусы каждого варианта. Хорошо бы еще не в этой теме.

где-то попадалась статья о ПОЛЬЗЕ goto - она впечатляла больше

Да, она была довольно популярна: http://articles.org.ru/cfaq/index.php?qid=2541

что касается основной темы обсуждения, то по-моему скромному мнению многие тут не понимают, что речь идет совсем не о поиске ошибок в поведении программы.... речь идет о проверке умения программиста ПЕРДУСМОТРЕТЬ варианты обработки нетипичных ситуаций.

Это тоже не совсем точно. Вот так, пожалуй, будет точнее: речь идет об автоматизированном средстве сравнения результата реального поведения программы с эталонным, заданным в спецификациях, и генерации отчета о результатах этого сравнения. Поиск ошибок в программе производится уже программистом на основе информации о результатах тестов. Сами тесты не показывают причину ошибки, их задача - как можно надежнее обнаружить ее наличие и дать сигнал тревоги.

с учетом того, что очень многие любители вообще не обращают внимание на варнинги компилятора, довольствуясь сообщением "errors: 0", актуальность сей темы среди них все-таки сомнительна...

Дело в том, что качественное тестирование - довольно трудоемкий и дорогой процесс. Лично я эти технологии использую примерно лет 5 и могу сказать, что в среднем объем тестового кода превышает объем целевого раза в 2-3 (а когда мне пришлось писать транслятор с некоего специализированного языка, то почти на порядок, уж больно много вариантов требовалось проверить). Поэтому очень сомневаюсь, что любители заинтересованы в применении такого подхода - он не окупится для мигалок-свистелок (впрочем, об этом ранее уже говорил Satyr). Если в вашем МК одно килослово программной памяти, при всем желании в программе нельзя сделать более 1024 уникальных ошибок, потом они начнут повторяться

Именно поэтому интересно в первую очередь пообщаться с профессионалами, для которых цена ошибки достаточно велика, чтобы были оправданны такие дополнительные расходы. Лично я работаю в сфере телекоммуникаций, тут весьма жесткие требования к отказоустойчивости, поэтому на такие вещи денег не жалеют. Те, кто не понимает даже сообщений компилятора, не есть целевая аудитория данной темы, не сочтите за снобизм. Ведь не дают случайные прохожие советов гинекологам лишь на том основании, что проявляют искренний интерес к предмету исследования.

[Мастер Ломастер]

где-то попадалась статья о ПОЛЬЗЕ goto - она впечатляла больше

Да, она была довольно популярна: http://articles.org.ru/cfaq/index.php?qid=2541

нет, это не та статья, которую я имел ввиду - речь шла именно о ПОЛЬЗЕ (без иронии) goto. статья впечатляла именно обоснованностью доказательств столь крамольного утверждения

в общем, статья должна производить сильное впечатление на начинающих, но не производит.

Наверное, лучше разобрать пару-тройку конкретных случаев применения глобальных переменных, решить ту же задачу без них, а затем оценить плюсы и минусы каждого варианта. Хорошо бы еще не в этой теме.

так как потенциальные опасности так же являются угрозами надежности ПО, думаю, обсуждение глобальных переменных может быть уместным и в этой теме. но не настаиваю на этом

в качестве конкретного случая давайте обсудим альтернативы глобальным переменным для задач, которые в Си решаются при помощи локальных static-переменных, но в применении к программам на ПАСКАЛЕ - как это было сделано у автора вышерассмотренной статьи. правда, к ПО микроконтроллеров данный аспект сложно применим, т.к. на паскале для МК пишут очень немногие...

Те, кто не понимает даже сообщений компилятора, не есть целевая аудитория данной темы, не сочтите за снобизм.

я думаю, что хорошие примеры возбуждают желание совершенствоваться, посему считаю, что наличие "нецелевых" участников в теме все-таки играет положительную "воспитательную" роль.

[Satyr]

B глобальные переменные, и goto, и даже лонгджамп в некоторых ситуациях в руках сведующего человека, видящего все варианты решения проблемы и понимающего отрицательные и положительные стороны каждого варианта, могут быть не ляпом, а мощным инструментом.

[Goldsmith]

так как потенциальные опасности так же являются угрозами надежности ПО, думаю, обсуждение глобальных переменных может быть уместным и в этой теме. но не настаиваю на этом

Я сначала подразумевал более узкий разговор о тестировании, но вы совершенно справедливо заметили, что глобальные переменные также отнюдь не способствуют повышению качества кода, поэтому в принципе можно и расширить рамки. Правда, на Паскале не писал уже очень много лет, да и к конкретному языку данная проблема не слишком сильно привязана. Предлагаю для простоты использовать псевдокод, который легко перевести на конкретный процедурный язык.

В качестве затравки предлагаю такой надуманный примитивный пример. Наш прибор должен отслеживать интервалы времени (не слишком большие) с точностью в миллисекунду. Для этого у нас есть глобальная переменная time размером 32 бита, которая инкрементируется по прерываниям таймера с частотой 1 кГц. Любой процесс, который желает узнать текущее "условное время", может считать значение этой глобальной переменной.

Годится такой вариант или хотите предложить другой?

[Goldsmith]

B глобальные переменные, и goto, и даже лонгджамп в некоторых ситуациях в руках сведующего человека, видящего все варианты решения проблемы и понимающего отрицательные и положительные стороны каждого варианта, могут быть не ляпом, а мощным инструментом.

Это абсолютно верно с учетом выделенных слов. Изначально речь шла о том, что это вполне нормальная повседневная практика, а не осознанный компромисс в особых случаях.

[Мастер Ломастер]

Годится такой вариант или хотите предложить другой?

не годится. нет смысла доказывать, что песочный куличик не вкусный. и псевдокод так же не приемлем, т.к. на выдуманном языке всегда можно найти либо выход, либо тупик. [добалвено позже]хотя... давайте и ваш вариант рассмотрим в вашей интерпретации - хочется посмотреть нить рассуждений.[конец добавления]

предлагаю более простой и конкретный пример: функция, выдающая значение интеграла от поступающих на ее вход отсчетов АЦП - фильтр, иначе говоря. язык - паскаль. предложите решение без глобальной переменной, хранящей состояние интеграла.

[Goldsmith]

предлагаю более простой и конкретный пример: функция, выдающая значение интеграла от поступающих на ее вход отсчетов АЦП - фильтр, иначе говоря. язык - паскаль. предложите решение без глобальной переменной, хранящей состояние интеграла.

Покажите, пожалуйста, как это выглядит с глобальной переменной.

[Мастер Ломастер]

предлагаю более простой и конкретный пример: функция, выдающая значение интеграла от поступающих на ее вход отсчетов АЦП - фильтр, иначе говоря. язык - паскаль. предложите решение без глобальной переменной, хранящей состояние интеграла.

Покажите, пожалуйста, как это выглядит с глобальной переменной.

Код: Выделить всё

var
   Sum : real = 0;

function Integral(Sample : real) : real;
begin
   Sum := Sum + Sample;
   Integral := Sum;
end;