Тестирование встроенного ПО, Кто как тестирует? Опции

[lamerok]

Вопрос возник вот почему. Ездили у нас товарищи на стажировку в америку. Так вот, там тестирование ПО, происходит следующим образом:
1. С помощью скриптового языка создается программная модель перефириии с которым работает контроллер, т.е. все интерфейсы (SPI, I2C, CAN, HARTи т.д) и нижнего и верхнего уровня, всей переферии (индикатора, управляющих портов, кнопок и т.д)
2. Подсоединяется некое устройство которое передает всю иноформацию с выводов контроллера в компьютер на котором запущена программная модель
3. И вся эта бодяга в разных условиях тестируется.. Т.е эмулируется нажатие клавиш, работа и сбои флеша, озу, ацп и т.д. Причем модель поведения тоже задается с помощью скриптов
4. Выводится отчет об ошибках в каких местах, и что надо сделать чтобы устранить.
Все про все занимает не более 8 часов.

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

[andk]

Абсолютно согласен с one_man_show по поводу приведенного примера

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

[-Tумблер-]

Абсолютно согласен с one_man_show по поводу приведенного примера

Выходит, Вы как раз склоняетесь к моей точке зрения.
За то время, пока фирма сумеет наладить стенд автоматизированного
контроля, "добровольные тестеры" юзеры пришлют нам
M претензий мылом, и мы выпустим N новых версий.
И стенд придется делать заново. Непрерывно. И этот
стенд никогда не успеет за реальной жизнью. И если программа
отлажена (а это делается один раз)- зачем вообще стенд отладки программ ?!!!

Вообще, такой стенд может иметь смысл толька для
примитивного контроля при массовом производстве ГОТОВЫХ изделий
(но не софта).
Тогда действительно он может существенно поднять производительность
труда и качество продукции.

[lamerok]

И если программа
отлажена (а это делается один раз)- зачем вообще стенд отладки программ ?!!! 

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

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

Вы наверное удивитесь, но именно так Америкосы и проверяют..

Т.е сигналы с индикаторных портов снимаются стендиком и вообще все сигналы снимаются, а прогрмма эмулирует действия пользователя, снимает сигналы с индикатора и смотрит верные ли это сигналы (Согасно ТЗ. т.е анализирует что сигналы действительно соответсвуют "добрый вечер" на 19 пикселов сбоку).
ПРимерно что они(Америкосы) проверяли, Встроенное ПО под управлением OS CMX Tiny, ЖК 160 на 160, CAN (ихний протокол верхнего уровня), HART, FieldBus, флешка по SPI, 10 клавиш, и всякие управляющие сигналы, часы.

Все действия задавились скриптом (нажатия клавиш, отказы, прерывания готовности каждые несколько мс, запрос мастера по каналу(CAN, HART ) в рендомазное время, неговоря уже про просто проверки отказов и т.д)...

Действительно на создание оборудования ушло у них около 4 лет и дохрена баксов, но сейчас для проверки нового ПО в новых устройствах, они уже тратят буквально не больше дня!!!! Причем для проверки ПО от разных устройств занят 1 человек, который вам через сутки скажет, что в вашей программе неправильно. И что надо поменять. Точнее скажет не он а программа.

[-Tумблер-]

Вы наверное удивитесь, но именно так Америкосы и проверяют..

Не удивлюсь. Судя по качеству Виндоус.

..тратят буквально не больше дня!!!!

Даааа ? Полагаю, что и этого много.
И что значит "не больше дня" ? Этот скриптописец ошибется
и не выявит ошибку. Вертолет упадет.
Вы также забыли , чтобы такое ТЗ для скриптописца написать
не один человеко-недель понадобится.

У нас на фирме в этом деле занято 0 человек и тратят они 0 дней.
Просто сам программист (инженер разработчик) должен выдать
готовый продукт "и все". Иначе ни в какие бюджеты не влезешь...
Как же он отлаживается ? Единственным способом - степ-бай-степ.

[lamerok]

TMX
Собственно со всем согласен, так оно похоже у всех и делается.
У нас это делает все один человек. Т.е. на один прибор - один человек, который и пишет все блоки для этого устройства или берет уже готовые.
На все блоки своя дока.

Даааа ? Полагаю, что и этого много.
И что значит "не больше дня" ? Этот скриптописец ошибется
и не выявит ошибку. Вертолет упадет.
Вы также забыли , чтобы  такое ТЗ для скриптописца написать
не один человеко-недель понадобится.

У нас на фирме в этом деле занято 0 человек и тратят они 0 дней.
Просто сам программист (инженер разработчик) должен выдать
готовый продукт "и все". Иначе ни в какие бюджеты не влезешь...
Как же он отлаживается ? Единственным способом - степ-бай-степ.

1. Скриптописец ошибиться не может. Так как даже если он ошибся, то программа выдает все действия которые выпоняет скрипт. И всегда можно проверить, почему вышло не так как хотелось. Это пишется в отчете.
2. Для тестирования ПО, обычно пишется программа испытаний(тестирования), собственно срипт практически и описывает эту программу.
Поэтому написание программы испытаний и скрипта - это одна и таже работа, делающаяся за одно и тоже время. И скрипт не коим образом, не увеличивает трудоемкость.
3. Про 0 человек. Нельзя проверить все пошагово в сложной программе. Отладка в основном идет блочно как сказал TMX, сложные большие куски например, ГУИ отлаживаются и вовсе просто на Компе (как например ГУИ От Микриума uC/GUI).
Естественно перед этим все алгоритмы уже описаны в виде блок схем и диаграмм. Т.е проработано практически все до мелочей. И создана дока, например API для такого-то блока (где указано, что функции должна делать). Реализация API функций - это уже дело программиста.
4. Программист по доке и алгоритмам пишет ПО, отлажиает его у себя. Отдает, как ему кажется , готовое ПО тестеру, который паралельно написанию ПО, уже написал программу испытаний и создал скрипт для этого ПО.
5. Тестер за 1 день тестит, отдает обратно программисту с результатами.
Программер меняет что-то по результатм тестов, возможно указывает ошибки самого тестера. После этого повторяет шаг 4.

[-Tумблер-]

..собственно срипт практически и описывает эту программу.

Вот ОНО !!!

Встроенная в устройство программа - сложный автомат
с огромным (значительным) числом состояний.
Протестировать ее - значит создать не менее сложный
(а на самом деле значительно более сложный) автомат
состояний.

И время его создания и отладки .. гм-гм.. мы уже это обсуждали.

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

Пример - тестирование автомата "Процессор INTEL 8080".
Он тоже имеет внутри программы (микропрограммы)
Если на проверку одного состояния этого процессора
затратить 1 мкс, на все тестирование уйдет время
превышающее возраст нашей Вселенной.

То о чем Вы все время говорите - это простейшее тестирование готовых
устройств на "грубый отказ".

[bialix]

Встроенная в устройство программа - сложный автомат
с огромным (значительным) числом состояний.
Протестировать ее - значит создать не менее сложный
(а на самом деле значительно более сложный) автомат
состояний.

И время его создания и отладки .. гм-гм.. мы уже это обсуждали.

Я так понимаю, что Ваш абсолютный скептицизм, основан на том, что Вы пишите программы на ассемблере, для которого не существует нормальных методик автоматического тестирования программ. В индустрии производства ПО давно разработаны методики оценки правильности работы модулей программ на основе unit-тестов. Т.е. никакой модуль и не тестируется на всем возможном многоообразии входных данных: тестируются на среднестатистических данных и на граничных данных, а также проверяется устойчивость к неверным (ложным) данным. Если модуль проходит тестирование на такой ограниченной выборке тестов, которая тем не менее корректно отображает его поведение на возможных наборах - то нет смысла тестировать Intel 8080 на всех комбинациях регистров.
Это законы больших чисел.

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

[-Tумблер-]

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

Это вы ошибаетесь
1. я практически не пишу на ассемблере.
2. нет разницы, на чем пишесшь с точки зрения отладки.

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

тестировать Intel 8080 на всех комбинациях регистров.
Это законы больших чисел.

Да я сам держал в руках мобильный телефон, который работал
совсем хорошо. Только в случае, когда вызов поисходил
когда не был запущен скринсейвер...
Запущенный скринсейвер + вызов - > глюк.

Вот вам пример - во всех состояниях и переходах состояний устройство функционирует нормально.
И лишь в одном из переходов происходит (проявляется!)сбой.
И неважно почему,важно что такое "вот оно", на самом деле существует.

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

Что значит "более терпимо" ? Не могу я с вами согласиться и все.
Мое мнение не является истинной в последней инстанции,
можете не соглашаться. Разрешаю. <_<
Ни каких внешних приличий ведения беседы нарушено не было с моей стороны.

И действительно я никогда не отлаживаю программ - есть же
доказательство, что это бесполезно. И это действительно так.
Не отладка, а само производство программы осуществляется
"СТЕП БАЙ СТЕП". То есть, когда автомат (или их совокупность)
еще "малы" и тривиальны есть теоретическая и практическая
возможность их точно отладить полностю. Что и приводит
к качественному результату.
Конечно, при росте проекта обязательна "интерференция", связь
между старым и новым. Главным образом по захватываемым
(и высвобождаемым) ресурсам. И это главный недостаток
такой технологии. Но эти ресурсы во встроенной технике
можно непрерывно контролировать..стек например/

[bialix]

Это вы ошибаетесь
2. нет разницы, на чем пишесшь с точки зрения отладки.

Речь вобще-то не про отладку как таковую, а про тестирование. Программист не может хорошо проводить тестирование своего кода, потому что он его слишком хорошо знает.

Да я сам держал в руках мобильный телефон, который работал
совсем хорошо. Только в случае, когда вызов поисходил
когда не был запущен скринсейвер...
Запущенный скринсейвер + вызов - > глюк.

Вот вам пример - во всех состояниях и переходах состояний устройство функционирует нормально.
И лишь в одном из переходов происходит (проявляется!)сбой.
И неважно почему,важно что такое "вот оно", на самом деле существует.

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

Тестирование != отладка.

[-Tумблер-]

Это пример, что _не во всех_ состояниях устройство функционирует нормально.

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

А чего там долго рассуждать.
Возьмите чего-либо попроще. Не надо сразу мобильный телефон.
Возбмите, к примеру ПИД-регулятор температуры.
Распространенная техника, практически стандартный проект.
Температуру измеряем датчиком DS1820 или диодом+ацп. На выбор.
Шим модуляция нагревателя. Дисплейчик, пара кнопок.

1.Попробуйте прикинуть, во что обойдется создание тестирующего
оборудования. С технической точки зрения хотябы.
2. попробуйте предложить это бухгалтеру и директору.
3.А потом это предложение распространите на каждый проект
организации.

Увидите, что вам ответят...

[bialix]

А чего там долго рассуждать.
Возьмите чего-либо попроще. Не надо сразу мобильный телефон.
Возбмите, к примеру ПИД-регулятор температуры.
Распространенная техника, практически стандартный проект.
Температуру измеряем датчиком DS1820 или диодом+ацп. На выбор.
Шим модуляция нагревателя. Дисплейчик, пара кнопок.

1.Попробуйте прикинуть, во что обойдется создание тестирующего
оборудования. С технической точки зрения хотябы.
2. попробуйте предложить это бухгалтеру и директору.
3.А потом это предложение распространите на каждый проект
организации.

Увидите, что вам ответят...

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

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