Jack_A писал(а):Не стал искать жутконаучные средства, тем более инет был у меня медленный и не дома. Написал 2 проги : одна генерировала наборы данных ( полтысячи счел достаточным ), пропускал их через свою МК-прогу в симуляторе, данные скидывал в файл, и второй программой их анализировал.
То есть, другими словами: не стали искать готовые универсальные жутконаучные средства, а вместо этого написали свое собственное, узкоспециализированное жутконаучное средство, которое делает фактически то же самое, только для одного конкретного случая.
Конечно, каждый имеет право на выбор, как распорядиться своим рабочим временем. Например, стоит задача: в некотором тексте нужно заменить все вхождения "Ваня" на "Федя". Один напишет для этого свою программу, которая работает только с этими словами. Другой запустит готовый жутконаучный текстовый редактор и даст ему жутконаучную команду замены одного образца на другой. В принципе оба варианта в конечном итоге приводят к правильному решению, а победителей, как известно, не судят.
Jack_A писал(а):Закинул их опять в симулятор и пошел анализировать, включив голову. Прошел тщательно по всем точкам ветвления - и вот она, подлая. Редко встречающаяся комбинация, но в приборе в реалтайме эта п/п выполняется сотни тысяч раз, и он регулярно на нее натыкался.
Исправил - и доктор больше не нужен.
То есть: вручную проделали ту работу, которую система автоматизированного тестирования проделывает автоматически за считанные секунды - проходит по всем точкам ветвления и сравнивает реальный результат с ожидаемым.
В принципе один раз, конечно, можно и вручную. Но жизнь устроена сложнее. Например, как вскользь упоминалось в одной беседе, имеются рисковые парни, которые запросто пользуются глобальными переменными, причем таковых немало. Возникает вполне реальная перспектива, когда аукнется в одной части программы, а откликнется совсем в другой, причем вовсе не обязательно так, как было задумано. Чем больше таких неуправляемых связей, тем больше вероятность в процессе развития программы (а удачные программы почти всегда развиваются дальше) наступить на эти грабли. Внося изменения в текст программы, неплохо бы убедиться, что при этом не сломалось ничего из того, что работало раньше. Вручную постоянно проверять одно и то же долго и скучно, автоматически - моментально. Регрессионное тестирование дает шанс даже плохо написанной (в смысле стиля) программе работать правильно Конечно, можно и не проверять, - авось часто вывозит.
Кстати, при разработке "больших" программ испольтзуется методология Test Driven Design (TDD), при которой тесты пишутся раньше самого кода. На первый взгляд это кажется странновато, но это только на
первый взгляд. При ее применении доктор вряд ли потребовался даже единственный раз. Есть прецеденты успешного применения TDD и для микроконтроллерных программ.
P.S. Не так давно на форуме один товарищ делился идеей создать ручной программатор - задавать данные тумблерами, такты генерировать кнопками... Над ним почему-то потешались. А ведь в сущности идея та же - делать вручную рутинные, не требующие особого интеллекта действия, на которые способен обычный жутконаучный программатор. Люди - загадочные существа: смеются над предметом, а повернешь предмет другим боком - воспринимают всерьез. А ведь суть-то остается та же.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
уж этот баг нельзя не заметить на этапе проектирования, если на самом деле озабочен НАДЕЖНОСТЬЮ. и уж тем более проглядеть во время тестирования, какое б оно там ни было - но включали же первые экземпляры в лаборатории?! однако, приняли решение СН,АЧАЛА СОРВАТЬ БАБКИ, а потом ПРЕДЛОЖИТЬ АПГРЕЙД или ЗАПЛАТКУ (патч в виде чехла и т.п.). тем более что за этот патч еще и дополнительные бабки поступят 
А иначе зачем..? 
