УДОСТОВЕРЕН
ЮФКВ.20139-01-УД
|
|
|
Система автоматического тестирования и непрерывной интеграции ПО
Руководство пользователя
ЮФКВ.20139-01 95 01
(ЮФКВ.20139-01 95 01-001ФЛ)
Листов 21
Литера
Инв. № подл
|
Подп. и дата
|
Взам. инв. №
|
Инв. № дубл
|
Подп. и дата
|
|
|
|
|
|
АННОТАЦИЯ
Данный документ содержит руководство пользователя cистемы автоматического тестирования и интеграции системного и прикладного ПО
NAST (Native Automatic Software Testing). Руководство включает информацию, необходимую для настройки, запуска и проверочного тестирования программы. Информация по установке и настройке инфраструктуры описана в документе «NAST. Инструкция по применению» ЮФКВ.20139-01 93 01-001ФЛ
Первым применением системы стало её использование при создании средств разработки ПО (СРПО) для процессора 1879ВМ6Я.
Содержание
3.4 Драйверы тестов 14
5 Правила ведения баг-трекера JIRA 16
5.1 Создание тикета (issue в JIRA) 16
1 Назначение и условия выполнения программы
Система NAST предназначена для автоматического тестирования ПО и обеспечения его непрерывной интеграции, то есть предотвращения деградации программного проекта. Система NAST была разработана как составная часть проекта СРПО - средств программирования, предназначенных для кросс-компиляции ПО микропроцессоровсемейства NeuroMatrix.
Хотя система NAST может быть использована автономно, включение её как составной части тестируемого проекта обеспечивает самотестирование системы. Система реализована на языке Python версии 3.5 и обеспечивает:
- повышение эффективности тестирования за счёт его автоматизации;
- непрерывную интеграцию ПО;
- независимость от хост-платформы (Windows, Linux);
- возможность тестирования ПО не только на программных симуляторах, но и на реальном целевом оборудовании.
2 Описание программы и методики тестирования
2.1 Терминология
Проект - здесь это совокупность программных и аппаратных компонентов подлежащих автоматическому регрессионному тестированию в процессе их разработки, отладки и сопровождения. Структура проекта отражает взаимное расположение основных компонентов в репозитории, алгоритмы и полноту тестирования проекта. Структура проекта описана в файле NMC.py и может быть изменена при необходимости.
Компонент проекта - логическая единица проекта, обладающая атрибутами: драйвера билдинга, драйвер исполнения, адрес расположения исходников, файл списка тестов, зависимость по билдингу, зависимость по исполнению. Каждый атрибут может отсутствовать.
Юнит-тестирование - здесь это отдельные скрипты, выполняющие или билдинг или тестирование отдельных компонентов проекта, с собственной тестовой базой. Принятое именование юнит-скриптов - run_tests.[sh|bat|py] и builder.[sh|bat|py]
Цепочным тестированием называется комплексное тестирование всего проекта. Драйвера цепочного тестирования используют собственную тестовую базу или тестовую базу компонентов.
В драйвере записан сценарий тестирования пользователя. Драйвером может быть любой исполняемый файл с параметрами. Драйверу юнит-тестинга передаются два параметра: $ws - копия репозитория («песочница») и $bin – директория бинарных файлов («тулчейн») - исполняемые файлы, скрипты, библиотек и т.п. Драйвер исполняет алгоритм, записанный в сценарии, и возвращает ноль в случае успешного завершения. Кроме этого он создает соответствующий файл логов.
Тулчейн - набор исполняемых файлов или аппаратных модулей проекта. Тулчейн может быть скопирован (установлен) заранее или создается в результате билдинга.
Билдинг - компиляция программного компонента в исполняемый двоичный файл выполняется специальными драйверами – билдерами.
2.2 Интерфейс системы, опции командной стоки
Интерфейс системы NAST версии 3.0 представлен следующими скриптами,
которые запускают сессию тестирования из консоли или из системы Jenkins:
'rsb' [] [<�опции>]- только билдинг тулчейна из компонентов из списка;
'rsr' [] [<�опции>]- только исполнение компонентов из списка, если тулчейн уже был собран ранее в данной рабочей копии проекта или если указана опция --release;
'rsd' [] [<�опции>]- билдинг всех компонентов и исполнение указанных в списке компонентов.
Интерфейсные скрипты явяются макросами, вызывающими основной скрипт nast.py с различными параметрами и представлены в виде пар (bash и bat командных файлов) для Linux и Windows соответственно.
Где
<�опции> =
--save - cохранять рабочую директорию тестового кейса и в случае его успешного завершения, в случае падения она сохраняется по умолчанию;
--release – использовать в сессии тулчейн, установленный на инструментальном (хост) компьютере, по умолчанию используется тулчейн, предварительно собранный в результате билдинга ( из директории Bin );
“cases=” – запускать только указанные тестовые кейсы из указанного компонента;
“config=<�имя файла конфигурации> - по умолчанию это составной конфиг NMC.py, в котором последовательно используются NMC_soft.py и NMC_hard.py;
--mc121_free - используется в проекте CРПО для закрытия семафора монопольного использования модуля mc12101 (только с инсталлированным
в системе NMCGCC-SDK из проекта CРПО-2016)
--help – печать подсказки.
2.3 Автономный запуск сессии тестирования
NAST 3.0 может быть запущен автономно из консоли (в ручном режиме). На примере тестирования проекта SDK NMC4:
git clone :/opt/repo/nmc4.git</a></i> клонируем в директорию 'nmc4', если еще нет рабочей копии<br /><br /><i> cd nmc4</i><br /><br /><i> rsb</i> билдинг всего тулчейна<br /><br />... // правка компонента Compiler<br /><br /><i>rsb Compiler </i>// повторный билд компонента Compiler<br /><br /><i>rsr Compiler Chain_QEMU</i> // запуск юнит-тестинга Compiler и цепочного тестинга Chain_QEMU<br /><br />...// добавление тестов для NM-GDB и для QEMU<br /><br /><i>rsr</i> NM-GDB QEMU Chain_QEMU // ...<br /><br />…// запуск тестового кейса fft_256 из компонента UTDSP (на симуляторе):<br /><i>rsr</i><i> </i><i>UTDSP</i><i> “</i><i>cases</i><i>=</i><i>fft</i><i>_256” --</i><i>save</i><br /><br />…// запуск тестового кейса iir_1_1 из компонента UTDSP_mc121 (на плате mc121):<br /><i>rsr</i><i> </i><i>UTDSP</i><i>_</i><i>mc</i><i>121 “</i><i>cases</i><i>=</i><i>iir</i><i>_1_1”</i> <br /><br />…// запуск тестового кейса fft_256 из компонента UTDSP_mc121-g (на плате mc121 c запуском отладчика NM-GDB в пакетном режиме ):<br /><i>rsr</i><i> </i><i>UTDSP</i><i>_</i><i>mc</i><i>121 “</i><i>cases</i><i>=</i><i>fft</i><i>_256” --</i><i>save</i><br /><br />..// запуск всего пакета тестов из компонента UTDSP_mc121 (на плате mc121) c предустановленным тулчейном NMCGCC-SDK и печать лога:<br /><br /><i>$ ./rsr UTDSP_mc121 --release > LOG</i><br /><br /><i>$ cat LOG</i><br /><br /><i>NAST invoked as:</i><br /><br /><i>QA/nast.py</i><br /><br /><i>--no_build</i><br /><br /><i>UTDSP_mc121</i><br /><br /><i>--release</i><br /><br /><i>run= UTDSP_mc121 --release</i><br /><br /><i>==================</i><br /><br /><i>Toolchain release is testing: 1.2.416 cb0218f3</i><br /><br /><i>from /opt/share/FailDB/Bin</i><br /><br /><i>=== --no_build ===</i><br /><br /><i>Be aware: Building for nmc4 switch off !</i><br /><br /><i>=== UTDSP_mc121 ===</i><br /><br /><i>=== --release ===</i><br /><br /><i>=== run= UTDSP_mc121 --release ===</i><br /><br /><i>Be aware: NAST config = NMC</i><br /><br /><i>NAST start: Thu Oct 19 18:31:56 2017</i><br /><br /><i>NAST uses NMC</i><br /><br /><i>master</i><br /><br /><i>3.1.2</i><br /><br /><i>Running [1] components: ['UTDSP_mc121']</i><br /><br /><i>/home/v.krushnyakov/nmc501/QA/QA_logs</i><br /><br /><i>/opt/share/FailDB/v.krushnyakov/nmc501--master</i><br /><br /><i>NMC4 Testing session</i><br /><br /><i>Thu Oct 19 18:31:56 2017</i><br /><br /><i>RUNNING with PATH=/opt/share/FailDB/Bin/bin:/opt/share/FailDB/Bin/lib:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin</i><br /><br /><i>~~~~~~~~ TESTING: component=UTDSP_mc121</i><br /><br /><i>driver=nmc4.py</i><br /><br /><i>Thu Oct 19 18:31:56 2017</i><br /><br /><i>=========Work dir is /home/v.krushnyakov/nmc501/QA/Work/UTDSP_mc121===========</i><br /><br /><i>RUN_COMP /home/v.krushnyakov/nmc501 /opt/share/FailDB/Bin UTDSP_mc121 /home/v.krushnyakov/nmc501/QA/Test_Base/UTDSP.lst /home/v.krushnyakov/nmc501/QA/Test_Base/nmc4.py</i><br /><br /><i>test= simple result=PASS</i><br /><br /><i>test= sinf result=PASS</i><br /><br /><i>test= fir_32_1 result=PASS</i><br /><br /><i>test= iir_1_1 result=PASS</i><br /><br /><i>test= latnrm_8_1 result=PASS</i><br /><br /><i>test= lmsfir_8_1 result=PASS</i><br /><br /><i>test= fft_256 result=PASS</i><br /><br /><i>test= mult_4_4 result=PASS</i><br /><br /><i>test= mult_4_4_wo_input result=PASS</i><br /><br /><i>test= option-fPIC result=PASS</i><br /><br /><i>UTDSP_mc121 - OK. (passed=10 failed=0)</i><br /><br /><i>+++++++++ TESTING DONE FOR component=UTDSP_mc121 driver=nmc4.py</i><br /><br /><i>Thu Oct 19 18:32:21 2017</i><br /><br /><i>Sent email with subj=NAST_3.0:RELEASE 10 PASS + 0 FAILS =10 TOTAL Standalone_job to user=v.krushnyakov@module.ru</i><br /><br />Результаты сессии печатаются на экране, в логах, резюмируются в электронной почте.<br /><br />Логи сессии создаются в ./QA/Work/ для каждого компонента и теста отдельно.<br /><a name="_toc498347786"></a> <b>2.4 Тестирование ПО на реальном оборудовании</b><b><br /></b><br /><br /><br /><b> </b>Система NAST обеспечивает тестирование ПО, загруженного на реальное оборудование. В проекте СРПО-2016 это модули mc1201 и mc7607, с ядрами архитектуры NMC4 и NMC3 соответственно.<br /><br />В проекте СРПО компоненты тестирования , выполняющие работу данного типа имеют в своём наименовании соответствующие слоги, например:<br />'Compiler_kernels_O1_mc121' или 'mc7607_nmg++', атрибут ‘arch’ в описании компонента со значениями 'nmc4’ или ‘nmc3’, а также атрибут ‘mc121’: True для модуля ‘mc12101’.<br /><br />Например, в файле конфигурации NMC_hard.py, описывающем компонент, работающий с ‘mc12101’ описывается так:<br /><br /><i>'UTDSP</i><i><b>_</b></i><i>mc121' : {</i><br /><br /><i>'run' : join( QB,'nmc4.py' ),</i><br /><br /><i> 'list' : join( QB,'UTDSP.lst' ),</i><br /><br /><i>'cc_options': C_LIB_OPTIONS + CONFIG_RUN_COMMON +' -O0 -std=c99 -fno- builtin -I'+str(join(*[QB,'UTDSP'])),</i><br /><br /><i> 'compiler': 'nmc-gcc',</i><br /><br /> 'mc121': True,<br /><br /> 'arch': 'nmc4',<br /><br /><i>'total': 8,</i><br /><br /><i>'pass': 8,</i><br /><br /><i>'fail': 0</i><br /><br /><i>},</i><br /><br />Следует отметить, что данный тип работы подразумевает наличие специальной библиотеки в составе СРПО, которая включат в себя утилиты загрузки и обмена , а при тестировании отладчика в пакетном режиме, еще и утилиты stub , обеспечивающей взаимодействие между платой и отладчиком.<br /><br />При работе с платой в удаленном режиме при многопользовательском режиме возможны конфликты по доступу к плате. В NAST этот конфликт разрешается путем автоматического создания файла-семафора, при работе такого компонента и его удалении при завершении работы, что обеспечивает последовательный доступ к плате пользователей. Если плата занята, NAST переходит в режим ожидания, пока семафор не будет открыт. В NAST также предусмотрен режим принудительного открытия (удаления) семафора по опции –mc121_free.<br /><a name="_toc498347787"></a> <b>2.5 Непрерывная интеграция в NAST с помощью системы Jenkins</b><br />В системе постоянной интеграции Jenkins каждый пользователь может завести своё задание для автоматического тестирования всего проекта, находящегося под управлением некоторой СУВ, например, Git или SVN.<br />При любом изменении исходных текстов проекта автоматически запускается сессия тестирования (посредством скрипта NAST ‘rsd’), проверяющая проект на возможную деградацию. Если все компоненты тестирования успешно прошли этапы билдинга и исполнения, то сессия тестирования NAST и само задание, которое её инициировало, считаются успешно завершившимися.<br />Обычно главное задание проекта , ответственное за выпуск релиза, настроено на ветку ‘master’, в которой отслеживаются все изменения, вносимые участниками проекта. <br />В случае успешного прохождения задания с заданным «коммитным» объёмом тестирования формируется очередная релизная версия проекта. Так, в проекте СРПО хранятся несколько последних релизных версий, которые автоматически обновляются в циклическом режиме. Они хранятся по адресу: <br /><br />https://www.module.ru/jenk/NMCGCC-SDK/Linux <br />https://www.module.ru/jenk/NMCGCC-SDK/Windows.<br /><br />Более того, другое специальное задание (запускаемое обычно раз в сутки в нерабочее время) выполняет инсталляцию собранных пакетов на указанной машине, выбирая из хранящихся пакетов самый свежий. Таким образом, NAST обеспечивает полную автоматизацию поддержки жизненного цикла программного проекта, начиная от его создания, внесения изменений, сборки, комплексного тестирования и, наконец, инсталляции ПО, будь то инструментальный компьютер для кросс-компиляции ПО или встроенная микропроцессорная система.<br /><br />Каждый участник проекта может также завести собственное задание для тестирования персональной ветки. Рассмотрим основные настройки задания на примере проекта СРПО.<br /><br />В главном меню<i> </i>кликаем “New Item” и заводим имя задания, например, “NAST_QA”<br /><br />Кликаем “Configure” и определяем следующие поля:<br /><br /><i>Discard old builds</i> - выбираем стратегию и сроки хранения предыдущих сборок(сеансов)<br /><br /><i>Restrict where this project can be run</i> – определяем сервер, где будет выполняться сеанс, здесь – ‘<a rel="nofollow" href="http://liner.module.ru">liner.module.ru</a>’<br /><br /><i>Source Code Management</i> – выбираем СУВ, здесь – 'Git’<br /><br /> Branches to build, здесь 'master’<br /><br />Repository browser, здесь FishEye<br />URL: <a rel="nofollow" href="http://thalia.module.ru:8060/browse/nmc4">http://thalia.module.ru:8060/browse/NMC4<br /></a><br /><br /><br /><i>Additional Behaviours</i> - Clean before checkout (очищать рабочую диркторию перед каждым сеансом)<br /><br /><i>Build Triggers Poll SCM</i> – установка триггера запуска, здесь - настроить на опрос появления изменений в репозитории:<br />H/5 * * * * - каждые 5 минут<br /><br /> <i>Build</i> - строка запуска - как собственно запускать NAST- здесь выбираем запуск через alias-скрипт:<br /> ./rsd “config=NMC_soft”<br /><br /><i>Post-build Actions</i> – какие сохранить результаты по окончании сессии (не вытираются при запуске следующей)<br /> <i>Archive the artifacts</i>: QA/*.*, QA/QA_logs/*.*, QA/QA_logs/**/*.*,<br /><br /><i>Jira Build Notifier</i> – указание системы баг-трекинга для автофиксации результатов в базе.<a rel="nofollow" href="http://thalia.module.ru:8090/rest/jenkins/1.0/job/84/sync"><br />http://thalia.module.ru:8090/rest/jenkins/1.0/job/84/sync<br /></a>Кликаем кнопку Save - сохраняем введенную конфигурацию джобы Jenkins.<br />Запуск сессии осуществляется либо автоматически по установленным триггерам запуска, либо вручную при нажатии кнопки "Build now".<br /><br /><a name="_toc498347788"></a> <b>3 Структура и настройка системы</b><br /><a name="_toc498347789"></a> <b>3.1 Состав системы </b><br /><br />Основными составными частями системы являются файлы конфигурации NMC*.py. В этих файлах описываются основные константы, переменные и компоненты тестирования проекта.<br /><br />NMC_const.py - глобальные константы системы, такие как:<br /><br />адрес системы Jenkins, имя задания (джобы), выпускающего релизную версию, адрес массовой рассылки результатов тестирования, структура директорий и другие.<br /><br />В проекте СРПО в директории QA:<br /><br /><i>NMC</i><i>_</i><i>soft</i><i>.</i><i>py</i> - описание компонентов, в которых стадию исполнения выполняет программная модель процессора – симулятор QEMU;<br /><br /><i>NMC</i><i>_</i><i>hard</i><i>.</i><i>py</i> - описываются компоненты, где тесты исполняются на реальной аппаратуре (модули mc1201 и mc7607).<br /><i>nast</i><i>.</i><i>py</i> - главный скрипт системы;<br /><br /><i>Utils</i><i>.</i><i>py</i> -утилиты.<br /><br /><i>Test</i><i>_</i><i>Base</i> - локальная база тестов и тестовые драйверы.<br /><a name="_toc498347790"></a> <b>3.2 Структура и настройка файла конфигурации</b><br />Файл конфигурации (по умолчанию NMC.py) предназначен для управления содержанием и объёмом сессии тестирования и может быть отредактирован пользователем под конкретную задачу и сохранён под другим именем. Нужная конфигурация, отличная от умолчания, подается через параметр “config= <config_name>”.<br />В течение сессии выполняется тестирование программных (или аппаратных) сущностей, являющихся объектами тестирования. В качестве такой сущности может выступать любое программное приложение (либо аппаратный модуль) или его часть. Каждый объект тестирования в системе NAST идентифицируется одним или несколькими компонентами. Каждый компонент имеет своими обязательными атрибутами: как минимум один драйвер ‘driver’ и один атрибут местоположения ‘src’. Дополнительным атрибутом является список тестов компонента ‘list’.<br /><br /> python nast.py [“config=<NMC>”] [<a rel="nofollow" href="/c:\pages\createpage.action%3fspacekey=distr&title=--no_build&linkcreation=true&frompageid=21954609">--no_build</a>] [<a rel="nofollow" href="/c:\pages\createpage.action%3fspacekey=distr&title=--no_run&linkcreation=true&frompageid=21954609">--no_run</a>] <a rel="nofollow" href="/c:\pages\createpage.action%3fspacekey=distr&title=%22build=+%3clist_of_components%3e%22&linkcreation=true&frompageid=21954609">["build= <list_of_components>"</a>]<a rel="nofollow" href="/c:\pages\createpage.action%3fspacekey=distr&title=%22build=+%3clist_of_components%3e%22&linkcreation=true&frompageid=21954609"> ["run= <list_of_components>"</a>] <br /><br />В файлах конфигурации (включая NMC_const.py) задаются основные параметры сессии. Параметры могут быть изменены пользователем, за исключением WS в случае запуска из системы Jenkins<i>.</i><br /><br />В случае запуска сессии из Jenkins можно задать имя главной джобы проекта:<br /><br />MAIN_EMAIL – адрес массовой рассылки писем с результатами сессии для главной джобы (например, в проекте SDK NMC4 это почтовый alias “nm_tools@<a rel="nofollow" href="http://module.ru">module.ru</a>”)<br /><br />WS – рабочая копия тестируемого репозитория в случае автономного запуска NAST <br /><br />QA - директория скриптов NAST (компонент QA в проекте SDK NMC4)<br /><br />QB - директория базы тестов NAST<br /><br />WORK - рабочая директория NAST<br /><br />QA_LOGS - директория логов NAST<br />и поддиректории:<br /><br />BUILD_LOGS - директория логов билдинга<br /><br />UNIT_LOGS - директория логов юнит-тестирования отдельных компонентов<br /><br />CHAIN_LOGS - директрия логов комплексного (цепочного) тестирования<br /><br />export chain_logs=$QA_logs/Chain_logs – логи цепочного тестинга.<br /><br />Основными объектами сессии тестирования являются компоненты.<br />Компоненты определяются как элементы структуры (словаря) 'Cfg'.<br /><br />Например:<br /><br /><i>Cfg = {</i><br /><br /> <i>'Asm' : { # описание компонента 'Asm'</i><br /><br /> <i>'src': join( *[WS,'Binutils','Asm']), # исходные тексты</i><br /><br /> <i>'build': join( *[WS,'Binutils' ,'Asm', builder]), # </i><i>драйвер</i><i> </i><i>билдинга</i><br /><br /> <i>'build_deps': ['Binutils'], # зависимость по билду: cначала должен быть выполнен билдинг компонента 'Binutils'</i><br /><br /> <i>'run': join( *[WS,'Binutils','Asm', run_tests]), # драйвер юнит-тестинга</i><br /><br /> <i>},</i><br /><br /> <i>'Binutils' : {</i><br /><br /> <i>'src' : join(WS,'Binutils' ),</i><br /><br /> <i>'build' : join(*[WS,'Binutils' ,'builder.sh']),</i><br /><br /> <i>}, …</i><br /><br /><i>}</i><br /><br /><br />Некоторые компоненты, как, например, выше описанный ‘Binutils’, могут не иметь атрибута ‘run’, а только атрибут ‘build’. Это означает, что компонент является вспомогательным и не будет задействован при исполнении, он только должен быть успешно собран. Компоненты, которые имеют в своём описании атрибут ‘run’, также имеют дополнительные: ‘total’, ‘pass’ и 'fail’. Эти дополнительные атрибуты управляют процессом создания релизной версии.<br />‘total’ – общее число тестовых кейсов в компоненте,<br /><br />‘pass’ и ‘fail’ – требуемые величины ожидаемо прошедших и упавших кейсов. Если ожидаемые значения не лучше реальных, полученных в результате сессии, компонент успешно прошёл коммитное тестирование. Успешное коммитное тестирование всех компонентов – условие создание новой релизной версии.<br /><br />По ходу исправления ошибок планка ожидаемых значений повышается. В реальности при большом количестве кейсов 'fail’ редко бывает нулевым, но все ожидаемые падения должны быть зафиксированы в системе баг-трекинга. Например:<br /><br /><i>'Compiler-O2' : {</i><br /><br /><i>'compiler': 'nmc-gcc',</i><br /><br /><i>'list' : join( *[WS,'Compiler' ,'Testing_system','testlist.gcc.dg']),</i><br /><br /><i>'run' : join(QB,'compile_only.py'),</i><br /><br /><i>'cc_options' : '-O2 -I'+join(*[QBC,'gcc.dg','HEADERS']),</i><br /><br /><i>'arch': 'nmc4',</i><br /><br /><i>'total': 5867,</i><br /><br /><i>'pass': 5819,</i><br /><br /><i>'fail': 48</i><br /><br /><i>}</i><br /><a name="_toc498347791"></a> <b>3.3 Структура и настройка тестовой базы</b><br />Структура тестов произвольна, определяется пользователем. Тест представляется адресом директории или отдельного файла. Рекомендуемая организация теста – это директория с поддиректориями : src- исходные тексты, input – если есть входные данные, output – выходные данные, ref – эталонные выходные данные.<br /><br />Тесты условно делятся на два класса юнит-тесты и цепочные(комплексные). Юнит-тесты обычно тестируют какой-то отдельный модуль ПО и используют внутренние списки тестов, не отраженные в файле конфигурации. Комплексные (цепочные) тесты предназначены для цепочного тестирования взаимосвязанных компонентов ПО, обычно имеют явный список тестов – атрибут ‘list’.<br /><br />Пример:<br /><br /><i>'Compiler_dg_run_cpp-O1' : {</i><br /><br /><i>'compiler': 'nmc-g++',</i><br /><br /><i>'run' : join(QB,'nmc4.py'),</i><br /><br /><i>'list' : join( *[WS,'Compiler' ,'Testing_system','dg.cpp_run_list.m']),</i><br /><br /><i>'cc_options' : '-O1 '+ CPP_LIB_OPTIONS,</i><br /><br /><i>'arch': 'nmc4',</i><br /><br /><i>'total': 512,</i><br /><br /><i>'pass': 510,</i><br /><br /><i>'fail': 2</i><br /><br /><i>}</i><br /></nmc>
|
