pavia писал(а):
1. Как лучше сделать
Включаем наши тестовые модули в нашу программу.
либо наоборот
Включаем тестируемые модули в тестовую программу.
либо не включать, а копировать и компилировать?
Идеальное тестирование ОС может быть только на эмуляторе. Правда требования к эмулятору получаются тоже идеальные (недостижимые). Но тем не менее - по многим частям системы тестирование на эмуляторе абсолютно реализуемо. Но есть одна мелочь - нужно вручную допиливать эмулятор. Вам, как пишущему на С, это проще, потому что на С написан целый ряд качественных эмуляторов. Нужно просто выбрать какой-то из них и далее соорудить систему мониторинга состояния вашей ОС внутри эмулятора. Я даже в рамках ограничений Qemu и протокола GDB на Java что-то похожее сваял, но конечно же уровень контроля над системой оставляет желать много лучшего.
Но выше сказанное относится к большим модулям. Мелочь же тестируется какими-нибудь юнит-тестами или чем-то подобным. Так гораздо эффективнее.
pavia писал(а):
2. Есть функция без внешних входов и входов
Код:
procedure InitVGA;
assembler;
asm
PUSH BX
MOV AX,0003h
XOR BX,BX
INT 10h
POP BX
end;
Стоит ли тестировать данную функция?
И если стоит, то как это лучше проделать?
Гранулирование тестов, конечно же, реализуется на ваше усмотрение. Но если говорить про идеальное тестирование (и требующее идеального времени на него), то нужно тестировать абсолютно всё. Другой вопрос - а есть ли необходимое время. Поэтому всегда выбирается некий компромисс. В целом тесты пишут для частей системы, которые подвержены изменениям, но при этом их внешние интерфейсы меняются минимально. То есть максимальная выгода от тестирования достигается при многократном изменении тестируемой части при неизменной тестирующей - таким образом после каждого ковыряния в потрохах системы можно быть уверенным, что не внесены новые баги (точнее - не внесены охваченные тестами баги). Ну а конкретный выбор по грануляции и списку охваченных модулей - делать вам исходя из архитектуры вашей системы.
Вход
Регистрация
FAQ
Поиск
