Система тестирование софта - сведение воедино всех идей. Версия 0.00 -> картинка http://upload.caxapa.ru/Visio-testing_y2007m07d26.pdf
Картинка в пояснение
http://upload.caxa …esting_y2007m07d26.pdf
Справделиво и для синтетического порта, и для симуляторов, и для хардварного решенения.
Есть система. Это память: код, стек, куча и переиферия.
Код стстоит из модулей.
Модуль - это некая последовательность действий, которая автономна и общается с внешним миром через точки входа и через точки вызовов других модулей.
При вызове через точку входа модуль получает все, что ему надо.
Модуль использует локальную память на стеке (спасибо, кто пояснил это!) для внутрених переменных автоматического класса.
Прямое использование глобальных переменных забанено!!! Т.е.
= glob_var
glob_var =
if (glob_var)
забанены.
Вместо этого используется &glob_var, который модуль получает при вызове. (похоже, я опять С++ изобретаю. Там это вроде инкапсуляция называется).
Глобальные переменные порождаются специальным модулем при init системы. Либо статическая компиляция.
Есть система целиком как взаимодействие кода, данных и периферии. Все это живет отдельно:
* как особый процесс внутри ОСи - синтетический порт
* как виртуальная система - симулятор
* как железяка с JTAG или монитором любым
Есть скрипт - "дроччер". Он собирает систему, загружает ее, расставляет "яркие точки" (brake points, хотя яркие точки - более общее определение).
Тщетельно парсится листинг компилера и линкера. Строится глобальная таблица сущностей.
При старте далаем снимок кода - crc. Код в процессе работы не меняется.
Дошли до точки 1. заполнили сводобный стек случайным шумом из полинома (техника, которую openBSD использует). Сделали снимок всех переменных (охрененная таблица: адрес, длина, crc).
Запустили прохождение точки 1. Ловим точку 2.
crc кода - а не шарахнул ли кто по памяти?
crc переменных - а какие глобальные переменные изменилось? А это можно было делать?
Так отлавливаем все ошибки при использовании указателей.
Анализируя состояние свободной памяти, ищем конец нашего "белого шума" и понимаем, на сколько нырял наш модуль в стек.
Анализируя значения переменных, понимаем - а сделали ли наш модуль то, что от него надо.
Структурированный лог всего в SQL - чтобы потом было легко анализировать.
Далее запускаем систему до следующей точки и т.д.
Большая портянка с графом всех сущностей системы.
Полностью автоматизированная система тестирования софта по любым параметрам.
Система получается очень затратной по ресурсам хост машины, но:
* они велики - будет чем заняться 4-х ядерной системе с 4Г памяти (осенью такие системы будут 1.5k$ стоить)
* многие процессы параллелятся (например, таблицу сущностей надо хранить в SQL, который, в своб очередь, держит все в памяти. Он живет в отдельном процессе, и автономно индексирует при добавлении сущностей.)
* все масштабируется в пределах кластера - каждый пысюк гоняет свой набор данных на модели.
Зато система не имеет ограничений по гибкости и полностью автоматизируется.
Evgeny_CD (26.07.2007 14:21, просмотров: 4585)
)
)
)