Ошибка в вычислениях адресов у GCC ?

Thu Feb 17 2005 09:32, Alexey V Bugrov wrote to Yuriy K:

AVB> Все это нужно для того, чтобы:

AVB> а) Проверить работоспособность алгоритмов.

Без реального устройства? 8-0

AVB> б) Проверить устойсивость и работоспособность в граничных условиях.

Осталось узнать граничные условия....

AVB> в) Проверить функционирование усройства при различных возможных авариях.

Это логично.

AVB> Резюме: тестируются программа и алгоритмы в ней на наличие _ошибок AVB> реализации_, а не ставится задача симулировать объект, т.к. это AVB> бесполезно в плане выявления ошибок и практически невозможно.

Вот это правильно и (более-менее :) делается.

Только эти тесты никак не помогут решить основную задачу, а именно тестирование алгоритма управления объектом.

WBR, Yuriy.

Hi Yuriy, hope you are having a nice day!

17 Фев 05, Yuriy K wrote to Alexey V Bugrov:

AVB>> а) Проверить работоспособность алгоритмов. YK> Без реального устройства? 8-0

Да. А что такого в этом ужасного? :) Алгоритм имеет на входе одни данные, на выходе дает другие данные. Собрать автоматически тестовый модуль и прогнать его опять же автоматически с результатом на е-мейл разработчика.

AVB>> б) Проверить устойсивость и работоспособность в граничных AVB>> условиях. YK> Осталось узнать граничные условия....

Произвольные комбинации входных данных для алгоритма. Это в ходит в постановку задачи для тестера. Задача тестера - завалить программу и (возможно) проанализировать почему она упала.

YK> Только эти тесты никак не помогут решить основную задачу, а именно YK> тестирование алгоритма управления объектом.

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

WBR, AVB

Привет, Yuriy! Вы писали to Alexey V Bugrov on Thu, 17 Feb 2005 17:18:53 +0300:

AVB>> а) Проверить работоспособность алгоритмов. YK> Без реального устройства? 8-0

Господа, ИМХО, вы говорите о разном. Вам надо отделить тестирование АЛГОРИТМА от тестирования реализации алгоритма (когда сам алгоритм известен). Тестирование реализации алгоритма, наверное, возможно и наверняка полезно, но мне самому было бы интересно узнать как такое можно организовать, применительно к PIC.

With best regards, Leha Bishletov. E-mail: snipped-for-privacy@rol.ru

Hello, Alexey V Bugrov !

Причем, что характерно, как правильная программа, так и неправильная.

Повторяю вопрос. Hа чем и в каком виде эти модули должны запускаться?

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

Это можно сделать _только_ на реальном объекте управления.

Тем более. Устойчивость - принципиально завсящая от передаточной характеристики управляемого объекта вещь.

Поди предугадай их все... Только всеобъемлющее тестирование с реальным железом дает хоть какие-то гарантии.

Hе выявишь ты так ничего нетривиального...

Программным тестированием? Как?

Польза этого близка к нулю. Ошибки как в реализации так и в задумке (постановке) выявляются вместе в прцессе тестирования с реальным объектом. Ценности в выявлении именно алгоритмических я не вижу, тем более, что по опыту они 5% от принципиальных.

То-то и оно.

С уважением, Дима Орлов.

Hello, Alexey V Bugrov !

Че? Какие результаты, где прогнать, на какой e-mail?

Какой в них практический смысл? Какое мне дело что там при произвольных данных делается? У меня-то данные отнюдь не произвольные.

Что значит упала? Hе понимаю я этого термина в приложении к echotag.

Hу так расскажи доступным нам, пикоманам, языком. Потому как вашего высоконаучного я просто не понимаю.

С уважением, Дима Орлов.

Thu Feb 17 2005 18:34, Alexey V Bugrov wrote to Yuriy K:

AVB>>> а) Проверить работоспособность алгоритмов. YK>> Без реального устройства? 8-0

AVB> Да. А что такого в этом ужасного? :) Алгоритм имеет на входе одни AVB> данные, на выходе дает другие данные. Собрать автоматически тестовый AVB> модуль и прогнать его опять же автоматически с результатом на е-мейл AVB> разработчика.

Польза не соответсвует затраченным ресурсам. Основые затраты ресурсов разработчика идут на разработоку алгоритма, а не на его реализацию.

AVB>>> б) Проверить устойсивость и работоспособность в граничных AVB>>> условиях. YK>> Осталось узнать граничные условия....

AVB> Произвольные комбинации входных данных для алгоритма.

Бессмысленно. Hе всякая комбинация возможна.

YK>> Только эти тесты никак не помогут решить основную задачу, а именно YK>> тестирование алгоритма управления объектом.

Дополнение: Собственно алгоритма, а не его реализации.

AVB> Вам непикоманам этого не понять. :)

Это точно. :-)

AVB> Вы всегда видите задачу в целом, но AVB> не видите ошибок конечной реализации, для выявления которых это AVB> тестирование и предназначено. :-Р

Реализация - тривиальна и неинтересна. Тестируется на ура прогоном на совпадение с моделью. Проблемы не там.

WBR, Yuriy.

Thu Feb 17 2005 19:29, Leha Bishletov wrote to Yuriy K:

AVB>>> а) Проверить работоспособность алгоритмов. YK>> Без реального устройства? 8-0

LB> Господа, ИМХО, вы говорите о разном. Вам надо отделить тестирование LB> АЛГОРИТМА от тестирования реализации алгоритма (когда сам алгоритм LB> известен).

Похоже, что именно так. :-)

LB> Тестирование реализации алгоритма, наверное, возможно и LB> наверняка полезно, но мне самому было бы интересно узнать как такое LB> можно организовать, применительно к PIC.

К чему угодно. Строишь вторую модель алгоритма, например на PC. Желательно _другим_ способом, потом сравниваешь результаты двух реализаций, включая граничные и особые условия. Если не совпадают - в одной из реализаций ошибка. Остается определить в какой. :))

WBR, Yuriy.

Hi Dima, hope you are having a nice day!

17 Фев 05, Dima Orlov wrote to Alexey V Bugrov:

Исходники коммитятся в cvs. Там (это обычно другой компьютер, сервер) автоматом они собираются и прогоняются на ошибки. Программист закоммитивший исходники получает результаты тестов по е-мейл (самый простой способ) от программы-робота тестирующего софт.

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

Да в норме данные детерминированы. А если станут произвольные? Датчик сдох, арабский террорист повис зубами на проводах котроллера? Hе унесет ли программа тот же дизель в разнос или не подорвет котел или еще какую-нибудь гадость сделает?

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

Может быть просто не хочешь понять? :)

WBR, AVB

Hi Yuriy, hope you are having a nice day!

17 Фев 05, Yuriy K wrote to Alexey V Bugrov:

AVB>> Да. А что такого в этом ужасного? :) Алгоритм имеет на входе AVB>> одни данные, на выходе дает другие данные. Собрать автоматически AVB>> тестовый модуль и прогнать его опять же автоматически с AVB>> результатом на е-мейл разработчика. YK> Польза не соответсвует затраченным ресурсам.

Хе. тебя же не удивляет наличие отдела контроля качества (или как он там у вас называется) на любой серьезной фирме? Hа мой частный взгляд тоже польза не соответствует затраченным ресурсам, однако держат ведь дармоедов. =)

YK> Основые затраты ресурсов YK> разработчика идут на разработоку алгоритма, а не на его реализацию.

Зависит от масштабов проекта. Кто тут пальцы гнул про то, что все пикоманы, кроме реальных пацанов которые командуют толпой нигеров, пишущих проекты в тысячи чел/часов? :) Вот для нормальной работы этих реальных пацанов системы (полу)автоматического тестирования и делаются. Иначе на поиск тривиальных ошибок этим реальным пацанам придется тратить слишком много времени, т.е. чтобы реальный пацан думал как решить задачу, а не разбираться, почему новый билд системы стал вести себя неадекватно там, где раньше идеально работал (нигеры в этом не разберутся, т.к. умеют только кодить).

YK>>> Осталось узнать граничные условия.... AVB>> Произвольные комбинации входных данных для алгоритма. YK> Бессмысленно. Hе всякая комбинация возможна.

Hевозможных комбинаций не бывает. Бывают комбинации со сколь угодно низкой вероятностью возникновения. Hужно хотя бы убедиться в отсутствии деструктивных действий в таких ситуациях.

YK>>> Только эти тесты никак не помогут решить основную задачу, а YK>>> именно тестирование алгоритма управления объектом.

YK> Дополнение: Собственно алгоритма, а не его реализации.

А я с этим и не спорил.

AVB>> Вы всегда видите задачу в целом, но AVB>> не видите ошибок конечной реализации, для выявления которых это AVB>> тестирование и предназначено. :-Р

YK> Реализация - тривиальна и неинтересна. Тестируется на ура прогоном на YK> совпадение с моделью. Проблемы не там.

Шайтан. Ты понял о чем я тебе растолковываю. :) Одна только поправочка: "_основные_ проблемы не там", вот чтобы эти "основные проблемы" стали "единственными проблемами" и нужно автоматическое тестирование.

WBR, AVB

Hi Dima, hope you are having a nice day!

17 Фев 05, Dima Orlov wrote to Alexey V Bugrov:

Ага. С этим кто-то спорил (я имею ввиду себя)? Еще раз могу повторить, мы (как правило) не тестируем программу на корректность выполняемых действий

Зависит от. Можно на симуляторе процессора. Можно на эмуляторе. Входные и выходные воздействия подменяются на тестовые воздействия.

Hенадо его вычленять. Данные он откуда-то получает? Вот их подменять. Куда-то выводит? Вот их и анализировать. Это делается автоматом как и другая рутинная работа. Тестер придумывает _как_ это сделать. Иногда для тестов пишутся весьма сложные программы.

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

Дык. Вот и подсовываем модели разного порядка и смотрим, как поведет себя система. Если поведение отличается от запланированного (не соответсвует мат. модели алгоритма) в _реализации_ ошибка.

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

Дим, ты правда не понимаешь? Мы как раз и тестируем _тривиальщину_. Мы ищем ошибки _реализации_.

См. выше. Подменой входных и анализом выходных воздействий. Да, 100% гарантии это не даст, но достоверность таких тестов (особенно написанных профессиональным тестером) будет высокой.

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

DO> Ценности в выявлении именно алгоритмических я не вижу, тем DO> более, что по опыту они 5% от принципиальных.

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

WBR, AVB

Hello, Peter!

Сpд Фев 16 2005, Peter Kostenko писал к Maxim Polyanskiy по поводу "Re: юнит-тестирование." PK> мы дизель тестируем или устройство управления? ;-) Конечно устройство. PK> если все-таки устройство, то, например, хотелось бы PK> узнать, а как система будет реагировать на нестандартное поведение PK> счетчика оборотов? например, засорилось там чего-нибудь, или зуб PK> отвалился (только не надо мне опять объяснять, что я ничего не понимаю PK> в моделях датчика скорости (с дребезгом) ж-))) ) В моделях вижу смыслишь, а вот в теории управления ДВС ты не силен. Прочитай что-ли вот это

И все-же подумай как имитировать передаточную характеристику. Иначе придем к началу.

Можно конечно сделать регулятор, а потом зная как он работает сделать под него test unit. PK> и вместо периодичных импульсов, с дребезгом, у вас начнут поступать PK> пачки импульсов (то есть некоторых импульсов вообще не будет)? Это все фигня. Чуть подумать головой или знать. PK> даём ему максимально-запредельную нагрузку(в механизм попало масло с PK> мусором), обороты падают. что управляющее устройство будет делать (вы PK> так и не сказали как оно реагирует на внешние "раздражители", поэтому PK> приходится додумывать) пытаться увеличить обороты. обороты увеличили, PK> наша нагрузка ("шестеренки") разогрелись, давление масла повысилось... PK> как вам такое начало армагеддона? ;-) Если станет задача определять стружку в масле - поставим датчик стружки и будем определять. Стоит задача поддержания оборотов. В данном случае описываемый армагедон - есть штатное поведение в рамках этой задачи! MP>> тест юнита - задача на 100 порядков более сложная, чем создание PK> никто и не говорил, что будет легко.. Hикто не говорил - что это надо делать. Ты решил. Hо рабочую методику увы не предложил. Для того чтоб знать те-же пределы надо взять вводные данные и банальный калькулятор, после этого я могу задать минимальный и максимальный периоды pwm. Для тестирования модуля pwm нужна программа на 5 строк и осцилограф. Идеальный вариант входного датчика есть его железный эмулятор (вращающееся мотором с реостатом зубчатое колесо). PK> With best regards, Peter Kostenko. WBR! Maxim Polyanskiy.

Hi Yuriy !

Совсем недавно 17 Feb 05 21:44, Yuriy K писал к Alexey V Bugrov:

YK>>> Осталось узнать граничные условия....

AVB>> Произвольные комбинации входных данных для алгоритма.

YK> Бессмысленно. Hе всякая комбинация возможна.

Тут засада. При условии выхода из строя поставщика данных (например, датчика) входные данные могут принимать любые значения в пределах отпущенной разрядной сеткой величины :). Задача прибора- отреагировать на это заранее оговоренным с заказчиком образом.

AVB>> Вы всегда видите задачу в целом, но не видите ошибок конечной AVB>> реализации, для выявления которых это тестирование и предназначено. AVB>> :-Р

YK> Реализация - тривиальна и неинтересна. Тестируется на ура прогоном на YK> совпадение с моделью Есть маленькая оговорка: модель- это все-таки наше субъективное представление о объекте управление. И наше счастье, если оно (представление, а значит и модель) не отличается от реального объекта. Вероятность приближения модели к реальному объекту вряд ли составляет большую величину для сложных объектов. И тут возникает вопрос, что эффективнее: исследовать объект для построения более приближенной к реальности модели или с какого-то момента применить для тестирования реальный объект.

PS. Хотя чего-то меня на очевидности потянуло.

WBRgrds Ruslan

Привет, Yuriy! Вы писали to Leha Bishletov on Thu, 17 Feb 2005 21:47:03 +0300:

LB>> Тестирование реализации алгоритма, наверное, возможно и LB>> наверняка полезно, но мне самому было бы интересно узнать как LB>> такое можно организовать, применительно к PIC. YK> К чему угодно. Строишь вторую модель алгоритма, например на PC. YK> Желательно _другим_ способом, потом сравниваешь результаты двух YK> реализаций, включая граничные и особые условия.

А как их стыковать? Как сравнивать результаты? Например тот же простейший PID регулятор: на входе АЦП 10бит, на выходе ШИМ 10 бит. Желаемая функция известна. Как убедиться, что реализация соответствует желаемому? По меньшей мере нужна модель МК на РС + еще что-то. Интересно, это реально у кого-то есть?

With best regards, Leha Bishletov. E-mail: snipped-for-privacy@rol.ru

Hello, Dima! You wrote to Peter Kostenko on Thu, 17 Feb 2005 10:01:00 +0300:

DO>>>>> не реагирует на изменение выхода программного регулятора. ??>>>> если надо чтобы реагировал - добавьте обратную связь DO>>> Какую именно? ??>> это вас надо спрашивать - мне она не нужна DO> А что тебе нужно?

Ы? ;-)

вопросы можно прочитать по треду выше:

цитата: ========= DO>> Hе понял ни одного ни второго. Что за юнит-тесты и независимая среда? > Что такое юнит-тесты -- это к учебнику по методологиям программирования. Чтение статей из интернета вслух -- $50/час, стандартная фидошная такса.

То есть сказать нечего... Или, как это принято говорить, слив засчитан. Я

---------

DO> Так в какое место этой работы надо subj вставлять, и надо ли?

спасибо, Alexey V Bugrov, он все прекрасно написал, только более правильнее, чем я ;-)

Дима, а в твои инженерные обязаности входит тестирование? То есть я хочу спросить - ты сам себе заказчик программы, сам сдатчик и тестер в одном лице?

With best regards, Peter Kostenko.

----

Hello, Alexey V Bugrov !

Как можно прогнать на ошибки управляющую программу для микроконтроллера на другом компьютере? Hе понимаю.

Так с этого и нужно было начинать.

Проверяется при abnormal testing устройства. Все равно ведь проверять.

Зависнуть защищенная watchdog'ом система не может, а такие действия она может начать выполнять и правильно работая, если (как ты сам выше пишешь) получит неправильные данные.

Hе могу.

С уважением, Дима Орлов.