Способ тестирования компонентов микропроцессоров, тестовый оракул для тестирования компонентов микропроцессоров, способ работы тестового оракула, способ построения тестового оракула

Способ тестирования компонентов микропроцессоров, тестовый оракул для тестирования компонентов микропроцессоров, способ работы тестового оракула, способ построения тестового оракула

Иллюстрации

Показать все

Реферат

Область техники

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

Уровень техники

В современной экономике производство микропроцессоров имеет большое значение в силу их широкого использования во многих отраслях. Микропроцессор является сложным электронным устройством, производство которого можно начать только после тщательного проектирования. Проектирование микропроцессоров чаще всего выполняется на специализированных языках моделирования аппаратного обеспечения (например, Verilog, VHDL, SystemC), позволяющих абстрагироваться от деталей расположения и соединения отдельных элементов электронной схемы. Проект микропроцессора на таком языке является исполнимой программой с набором параметров, представляющих входы процессора, и называется моделью. По окончании проектирования модель транслируется в точное описание расположения и соединения друг с другом отдельных элементов электронной схемы процессора. Модель обычно имеет иерархическую структуру - в процессоре выделяются модули, более простые, чем процессор в целом, и определяются правила взаимодействия между ними. Каждый из модулей решает четко определенные задачи так, чтобы набор взаимодействующих модулей в целом делал ровно то, что требуется от микропроцессора. Отдельные модули могут быть декомпозированы далее на еще более мелкие модули.

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

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

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

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

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

В настоящее время существует три основных подхода к созданию тестов для имитационного тестирования микропроцессоров и их модулей.

Разработка тестов вручную. Это наиболее широко применяемый метод, описанный в работах: J.Bergeron. Writing Testbenches: Functional Verification of HDL Models. Second edition. Springer, 2003; A. Meyer. Principles of Functional Verification. Newnes, 2003; W.K.Lam. Hardware Design Verification: Simulation and Formal Method-Based Approaches. Prentice Hall, 2005. Он состоит в том, что каждый отдельный тест создается членом группы проектирования - тестировщиком. Тестировщик сам должен определить, как проверить правильность получаемых результатов в тестах, а также обеспечить достаточную полноту тестового набора в целом. Достоинством этого подхода является его простота, а его основной недостаток - это сильная зависимость полноты набора тестов от опыта и аккуратности тестировщика. Кроме того, при этом подходе общее количество используемых тестов ограничено производительностью труда тестировщиков и временем, отпущенным в проекте на тестирование. Это делает зависимость их полноты от грамотного проектирования тестового набора в целом еще более сильной.

Автоматическая генерация тестов как всех различных комбинаций возможных входных сигналов для тестируемого компонента описана в работах: W.К.Lam. Hardware Design Verification: Simulation and Formal Method-Based Approaches. Prentice Hall, 2005; H.Al-Assad and J. P. Hayes. Design Verification via Simulation and Automatic Test Pattern Generation. International Conference on Computer Aided Design, 1995, pp.174-180; S. Bhattacharya, S. Dey, and B. Sengupta. An RTL Methodology to Enable Low Overhead Combinational Testing. Technical Report 96-CO16, C&C Research Labs, NEC USA, April 1996. При этом разрабатывается программа-генератор тестов, генерирующая различные сценарии подачи сигналов. Для проверки соответствия результатов требованиям к тестируемому компоненту вручную разрабатывается программа, выполняющая эту проверку. Достоинством этого подхода является возможность получить набор тестов, покрывающий очень большой набор возможных ситуаций. Его недостаток - это невозможность строить в генерируемых тестах сложные сценарии использования тестируемого компонента, поскольку сложность проверки правильности получаемых результатов в этом случае значительно возрастает и разработка программы для этого становится слишком сложной.

Автоматическая генерация тестов на основе модели требований к тестируемому компоненту описана в работах: A.Aharon, D.Goodman, M.Levinger, Y.Lichtenstein, Y.Malka, C.Metzger, M.Molcho, and G.Shurek. Test program generation for functional verification of PowerPC processors in IBM. In 32-nd Design Automation Conference, DAC 95, pages 279-285, 1995; J.Dushina, M.Benjamin, and D.Geist. Semi-formal test generation with Genevieve. In Design Automation Conference, DAC 2001, pages 617-622, 2001; В.П.Иванников, А.С.Камкин, В.В.Кулямин, А.К.Петренко. Применение технологии UniTesK для функционального тестирования моделей аппаратного обеспечения. Препринт 8 ИСП РАН, Москва 2005. Модель требований представляет собой формальное описание требуемого поведения тестируемого компонента. Различные сценарии тестов определяются так, чтобы задействовать все элементы этой модели (операции, инварианты и другие проверяемые ограничения). При разработке тестов в этом случае создаются модель требований и набор сценариев тестирования, а также используется специальный программный инструмент - транслятор моделей требований и сценариев. Достоинством этого подхода является возможность автоматизации генерации сложных тестов, проверяющих различные функции тестируемого компонента более глубоко. Его недостаток - сложность и повышенные требования к навыкам разработчиков модели требований и сценариев тестирования. Однако при его использовании один разработчик модели требований может подготовить столько тестов, сколько при ручной разработке сделают за то же время десяток тестировщиков.

Подход к генерации тестов на основе модели требований может использовать следующую общую структуру тестов, описанную в работах: В.П.Иванников, А.С.Камкин, В.В.Кулямин, А.К.Петренко. Применение технологии UniTesK для функционального тестирования моделей аппаратного обеспечения. Препринт 8 ИСП РАН, Москва 2005; I.Bourdonov, A.Kossatchev, V.Kuliamin, and A.Petrenko. UniTesK Test Suite Architecture. In Proc. of FME 2002. LNCS 2391, pp.77-88, Springer-Verlag, 2002; В.В.Кулямин, А.К.Петренко, А.С.Косачев, И.Б.Бурдонов. Подход UniTesK к разработке тестов. Программирование, 29(6):25-43, 2003. При этом подходе тест состоит из генератора тестовой последовательности и тестового оракула, где:

Генератор тестовой последовательности строит последовательность обращений к различным входам тестируемого компонента (или его исполнимой модели). Каждое обращение определяет набор сигналов, одновременно подаваемых на входы модели.

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

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

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

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

Оракул генерируется с помощью транслятора моделей требований из спецификации (описания модели) требований к тестируемому компоненту.

До последнего времени оставалась нерешенной проблема автоматической генерации тестов, использующих параллельные обращения к тестируемому компоненту или проверяющих корректность выполнения последовательностей инструкций в конвейерных микропроцессорах. В процессорах конвейерной архитектуры выполнение каждой инструкции разлагается на выполнение нескольких микроопераций (стадий выполнения этой инструкции) и происходит «перемешивание» микроопераций: микрооперации различных инструкций могут выполняться разными модулями одновременно или даже в порядке, обратном порядку соответствующих инструкций. При этом проверка правильности работы каждой инструкции значительно усложняется и не может напрямую использовать те же свойства ее результатов, которые выполняются при отдельном выполнении этой инструкции.

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

Решаемая техническая задача

Техническая задача состояла в создании группы изобретений, позволяющих осуществлять построение автоматизированного тестового оракула для проверки правильности моделей компонентов микропроцессоров конвейерной архитектуры, а также проверки правильности работы самих компонентов микропроцессоров и создании на его основе способа тестирования моделей микропроцессоров конвейерной архитектуры и их модулей. Причем этот способ должен обеспечивать применение тестов, использующих возможности параллельного выполнения инструкций или выполнения цепочки инструкций с возможным «перемешиванием» их микроопераций.

Сущность изобретения

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

Причем компонентом микропроцессора может быть как сам микропроцессор, так и модуль микропроцессора, а также модель микропроцессора или модель модуля микропроцессора.

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

Причем компонентом микропроцессора может быть микропроцессор конвейерной архитектуры или модуль микропроцессора конвейерной архитектуры.

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

Причем компонентом микропроцессора может быть как сам микропроцессор, так и модуль микропроцессора.

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

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

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

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

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

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

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

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

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

Причем компонентом микропроцессора может являться микропроцессор или модуль микропроцессора.

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

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

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

Причем компонентом микропроцессора может являться микропроцессор или модуль микропроцессора.

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

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

Технический результат от использования изобретений состоит в том, что способ тестирования компонентов микропроцессоров, тестовый оракул для тестирования компонентов микропроцессоров, способ работы тестового оракула и способ построения тестового оракула позволяют построение автоматизированного тестового оракула для проверки правильности моделей компонентов микропроцессоров конвейерной архитектуры, и позволили создать на его основе сам тестовый оракул и способ тестирования микропроцессоров конвейерной архитектуры, их модулей и их моделей. Причем созданные способы и устройства работают с применением тестеров, использующих возможности параллельного выполнения инструкций или выполнения цепочки инструкций с возможным «перемешиванием» их микроопераций.

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

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

Предлагаемые изобретения и их работа поясняются графическими материалами, представленными на Фиг.1-5.

На Фиг.1 представлена общая схема тестирования компонентов микропроцессоров конвейерной архитектуры, где 1 - генератор тестовой последовательности, 2 - тестируемый компонент, 3 - тестовый оракул, 4 - модель требований к тестовому оракулу, 5 - модель конвейера тестируемого компонента, 6 - тестовый отчет.

На Фиг.2 представлена схема предлагаемого устройства тестового оракула 3, где 4 - модель требований к тестируемому компоненту, 5 - модель конвейера тестируемого компонента, 7 - описание структуры интерфейса, 8 - модель внутренних данных, 9 - ограничения, 10 - ограничения целостности данных, 11 - предусловия операций, 12 - условия блокировки стадий, 13 - постусловия стадий, 14 - модель данных конвейера, 15 - функция сдвига конвейера, 16 - функция проверки стадий.

На Фиг.3 представлены первые два такта работы оракула 3 по описанному способу.

На Фиг.4 представлена схема предлагаемого способа построения тестового оракула, где 17 - формальная спецификация требований к тестируемому компоненту на расширении языка программирования или моделирования аппаратного обеспечения, 18 - вспомогательная библиотека, 19 - транслятор моделей требований.

На Фиг.5 представлена временная диаграмма сигналов сумматора.

Предлагаемые изобретения и их работа описаны в нижеприведенных материалах.

- Способ тестирования компонентов микропроцессоров

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

- Тестовый оракул для тестирования компонентов микропроцессоров

Устройство тестового оракула определяет набор элементов, из которых состоит оракул, и связи между ними.

- Способ работы тестового оракула

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

- Способ построения тестового оракула

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

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

Общая схема тестирования компонентов микропроцессоров конвейерной архитектуры (представлена на Фиг.1)

Предлагаемая схема тестирования построена на основе общеупотребительной схемы (описанной, например, в работах: В.П.Иванников, А.С.Камкин, В.В.Кулямин, А.К.Петренко. Применение технологии UniTesK для функционального тестирования моделей аппаратного обеспечения. Препринт 8 ИСП РАН, Москва 2005; I.Bourdonov, A.Kossatchev, V.Kuliamin, and A.Petrenko. UniTesK Test Suite Architecture. In Proc. of FME 2002. LNCS 2391, pp.77-88, Springer-Verlag, 2002; В.В.Кулямин, А.К.Петренко, А.С.Косачев, И.Б.Бурдонов. Подход UniTesK к разработке тестов. Программирование, 29(6):25-43, 2003; С.Campbell, W.Grieskamp, L.Nachmanson, W.Schulte, N.Tillmann, M.Veanes. Model-Based Testing of Object-Oriented Reactive Systems with Spec Explorer. Microsoft Research Technical Report MSR-TR 2005-59) введением в нее тестового оракула, имеющего особое устройство.

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

- Тестируемый компонент

Тестируемый компонент 2 представляет собой модель микропроцессора или модуля микропроцессора конвейерной архитектуры. При тестировании он работает в рамках симулятора.

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

- Генератор тестовой последовательности

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

В начале каждого такта генератор тестовой последовательности 1 передает очередной набор входных сигналов на входы тестируемого компонента 2 и на входы тестового оракула 3.

Генератор тестовой последовательности 3 разрабатывается таким образом, чтобы он реализовывал возможные сценарии работы тестируемого компонента. Различные способы построения генераторов тестовой последовательности описаны в работах: В.П.Иванников, А.С.Камкин, В.В.Кулямин, А.К.Петренко. Применение технологии UniTesK для функционального тестирования моделей аппаратного обеспечения. Препринт 8 ИСП РАН, Москва 2005; I.Bourdonov, A.Kossatchev, V.Kuliamin, and A.Petrenko. UniTesK Test Suite Architecture. In Proc. of FME 2002. LNCS 2391, pp.77-88, Springer-Verlag, 2002; В.В.Кулямин, А.К.Петренко, А.С.Косачев, И.Б.Бурдонов. Подход UniTesK к разработке тестов. Программирование, 29(6):25-43, 2003; С.Campbell, W.Grieskamp, L.Nachmanson, W.Schulte, N.Tillmann, M.Veanes. Model-Based Testing of Object-Oriented Reactive Systems with Spec Explorer. Microsoft Research Technical Report MSR-TR 2005-59.

- Тестовый оракул

Тестовый оракул 3 оценивает соответствие поведения тестируемого компонента 2 в ходе теста требованиям к нему и выносит вердикт о их соответствии или несоответствии. Входные сигналы, получаемые тестируемым компонентом 2 в начале такта, выходные сигналы, выдаваемые им в конце такта, а также свой вердикт об их корректности оракул записывает в тестовый отчет 6. Тестовый оракул 3 в начале каждого такта принимает входные сигналы, создаваемые генератором тестовой последовательности 1, в конце каждого такта он принимает выходные сигналы тестируемого компонента 2, анализирует их корректность, после чего записывает входные сигналы, выходные сигналы и вердикт об их корректности в тестовый отчет 6.

Если оракул 3 обнаруживает некорректные результаты работы тестируемого компонента 2, он, помимо записи в отчет, сигнализирует об этом и генератору тестовой последовательности 1, чтобы остановить тестирование. Тестовый оракул 2 для тестирования компонентов конвейерной архитектуры строится особым, описываемым ниже способом и состоит из модели требований к тестируемому компоненту 4 и модели конвейера тестируемого компонента 5.

- Тестовый отчет

Тестовый отчет 6 представляет собой запись событий, происходивших во время тестирования (передаваемых тестируемому компоненту 2 входных сигналов, получаемых от него выходных сигналов), и результатов проверки их корректности оракулом 3. Он используется для анализа результатов тестирования и обнаруженных в ходе теста ошибок. Запись в тестовый отчет 6 выполняется тестовым оракулом 3.

Устройство тестового оракула (представлено на Фиг.2)

Предлагается строить тестовый оракул 3 для компонентов конвейерной архитектуры из двух основных элементов - модели требований к тестируемому компоненту 4 и модели конвейера тестируемого компонента 5.

- Модель требований к тестируемому компоненту

Этот элемент содержит набор ограничений, проверка которых позволяет оракулу 3 установить выполнение или нарушение требований к поведению тестируемого компонента на тех результатах его работы, которые получаются в ходе теста. Модель требований 4 состоит из следующих частей.

- Описание структуры интерфейса 7 тестируемого компонента 2

Такое описание представляет собой определение входов и выходов тестируемого компонента 2. Возможные входные сигналы разделяются на операции и их аргументы.

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

- Описание модели внутренних данных 8 тестируемого компонента 2

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

- Описание ограничений 9 на поведение тестируемого компонента 2.

Ограничения представляют собой основное содержание требований.

Ограничения бывают четырех видов.

- Ограничения целостности данных 10

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

- Предусловия операций 11

Эти ограничения определяют аргументы операций, с которыми она может быть вызвана. Нарушение предусловия 11 означает попытку неправильного использования тестируемого компонента 2 и является ошибкой теста.

- Условия блокировки отдельных стадий 12

Эти ограничения определяют ситуации (значения внутренних данных и состояние конвейера), в которых соответствующая стадия не может быть выполнена. Однако выполнение условия блокировки означает не ошибку, а необходимость отложить выполнение данной стадии на последующие такты. Стадия остается невыполненной до тех пор, пока условие блокировки не нарушится на некотором такте, на этом же такте эта стадия будет выполнена.

- Постусловия отдельных стадий 13

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

- Модель конвейера тестируемого компонента 5

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

- Модель данных конвейера 14

Это описание состояния конвейера. Каждое состояние представляет собой множество стадий операций, выполняемых на данном такте. Операции, не вызывавшиеся до текущего такта, или те, выполнение которых уже завершилось, никак не участвуют в состоянии конвейера. Состояние конвейера изменяется в ходе тестирования с помощью функции сдвига конвейера 15.

- Функция сдвига конвейера 15

Эта функция отвечает за изменение состояния конвейера 15 при переходе от одного такта к следующему. В начале каждого такта она помещает в состояние ко