aet - Інтернет у хмарі

ПРОГРАМА:

ІМ'Я

aegis test - запустити тести

СИНТАКСИС

егіда -Тест [ варіант... ][ ім'я=значення ][ ім'я файлу...]
егіда -Тест -Незалежний [ варіант... ][ ім'я=значення ][ ім'я файлу...]
егіда -Тест -Список [ варіант...]
егіда -Тест -Допоможіть

ОПИС

Команда егіда -Тест Команда використовується для запуску тестів. Якщо файли не названі, усі відповідні тести
запускаються. За замовчуванням виконуються як автоматичні, так і ручні тести.

Ви можете називати каталоги в командному рядку та всі відповідні тести в цьому каталозі
буде запущено дерево змін. Це помилка, якщо немає відповідних тестів.

Кожну архітектуру необхідно тестувати окремо. Це тому, що можуть бути тонкі
проблеми, які виявляються лише на деяких архітектурах. Деякі проекти також можуть мати
різний код для різних архітектур.

Статус останнього тестового запуску запам'ятовується, щоб тести не запускалися, якщо його немає
потреба. (Це не стосується -РЕГРЕСІЯ тести, на жаль.) Тести потрібно повторити
якщо попередній тест був невдалим, якщо тестовий файл змінився, якщо була збірка,
і для кожної архітектури.

name = value
Ви можете додати ім'я=значення пар до командного рядка, вони будуть передані без змін до
тестова команда. Зазвичай у кінці командного рядка, але це можна змінити в
файл конфігурації проекту.

Команда - сила призводить до додавання неявної змінної force=1 до списку
присвоєння змінним і, таким чином, додається в кінець команди. Це найбільше корисно, коли
використання пакетна_тестова_команда файл конфігурації проекту.

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

Можна змусити всі призначення змінних перетворити на змінні середовища
поставивши $var у те старт команди перед назвою оболонки, а не at
типове розташування в кінці команди.

філе ІМ'Я Інтерпретація
Програма aegis спробує визначити імена файлів проекту за іменами файлів
задано в командному рядку. Усі імена файлів зберігаються в проектах aegis як відносні
до кореня базового дерева каталогів. Каталог розробки та
інтеграційний каталог є тінями цього базового каталогу, а тому ці відносні імена
застосувати і тут. Файли, названі в командному рядку, спочатку перетворюються на абсолютні шляхи
якщо необхідно. Потім вони порівнюються з базовим шляхом, каталогом розробки
шлях і шлях до каталогу інтеграції, щоб визначити назву, відносну до базової лінії. це є
помилка, якщо названий файл знаходиться за межами одного з цих дерев каталогів.

Команда -Base_RElative Опція може використовуватися, щоб інтерпретувати відносні імена файлів як
відносно базового шляху; абсолютні імена файлів все одно порівнюватимуться з різними
шляхи, щоб визначити назву, що відповідає базовій лінії.

Команда відносне_назва_файлу_налаштування у файлі конфігурації користувача можна використовувати для зміни
ця поведінка за замовчуванням. Побачити aeuconf(5) для отримання додаткової інформації.

TEST ПРОЦЕС

Кожна зміна повинна супроводжуватися тестами, і ці тести повинні бути
запускати зі створеним каталогом розробки, і вони повинні пройти. Це гарантує, що новий
функціональність супроводжується тестами для перевірки її коректності та виправленнями помилок
супроводжується тестами, які підтверджують, що помилку було виправлено.

Регресія Випробування
Тести обробляються як будь-який інший вихідний файл і зберігаються в базовій версії та
історію з усіма іншими вихідними файлами. Випробування, які повинні супроводжувати кожну зміну
накопичуються в базовій лінії проекту, забезпечуючи визначення правильної функції для
базова лінія. Ці накопичені тести можна виконати за допомогою команди «aegis -REGression»,
щоб переконатися, що проект не «регресує» в результаті зміни.

Базова лінія Випробування
Щоб мати свої тести, потрібні виправлення помилок невдача проти базової лінії проекту (на відміну від
до каталогу розробки). Це гарантує, що тест дійсно демонструє помилку
у базовій лінії, а також демонструючи, що вона виправлена ​​зміною. новий
функціональність тривіально не відповідає базовій лінії, тому aegis не намагається це зробити
здогадайтеся, чи є тест тестом на виправлення помилок чи тестом нової функціональності, для цього просто потрібні тести
не справляються з базовою лінією.

Ця вимога стосується як нових тестів, створених зміною, так і тестів
які були скопійовані в зміну для модифікації.

Перевірка Випробування
Рецензенти можуть бути впевнені, що Aegis дотримується вимог тесту; що зміна
повинні мати тести, що зміна повинна будувати, що тести проходять проти розробки
каталогу, і що тести не відповідають базовій лінії. Ці умови виконуються
by aede(1) і зміна не буде перенесено на буття відгуки стан до цих
умови виконуються. Тому рецензенти повинні переглядати тести для повноту охоплення
код у зміні та нечутливість до змін у середовищі виконання (наприклад,
не залежить від дати). Рецензенти також повинні використовувати «aegis -list change_details» для перевірки
що зміна має або не має винятків для тестування.

вилучення
Адміністратори проекту можуть надавати різні винятки для тестування, див aepa(1) і
аепаттр(5) для отримання додаткової інформації. Копіювання тестів у зміну або додавання нових тестів до a
змінити, може скасувати ці винятки.

TEST КОМАНДА КОНФІГУРАЦІЯ

Команда, яка використовується для виконання тестів, визначається тест_команда поле в проекті
конфігураційний файл (див aepconf(5) для отримання додаткової інформації), за умовчанням використовується
Оболонка Борна, якщо не встановлено. Поточний каталог буде верхнім відповідним
дерево каталогів. Якщо для тестів потрібні тимчасові файли, їх слід створити / Tmp, як
test не може очікувати дозволу на запис у поточному каталозі.

Якщо ви хочете використовувати більш складну систему тестування, а не простий сценарій оболонки,
але цей механізм тестування не повертає коди результатів, придатні для використання з aegis, ви могли б
загорніть його в сценарій оболонки, який перезаписує статус виходу в значення, які очікує aegis.
Ви також можете досягти тих самих результатів, написавши більш складний тест_команда в
проект конфиг файлу.

Також можна написати тестові команди, які можуть перевірити більше ніж один файл
один раз. Це контролюється пакетна_тестова_команда сфера проекту конфиг файл. в
у цьому випадку заміна ${output} вказує на ім’я файлу, яке має виконати тестова команда
творити, в aetest(5) формат, який містить результати виконання тестів. Це часто використовується
на системах з декількома ЦП або можливістю розподілу завдань між кількома комп’ютерами
в мережі.

Заміни
Всі aesub(5) заміни доступні в тестових командах. Деякі з них є
на особливу увагу:

АРХІТЕКТУРА
Ця заміна замінюється назвою архітектури, яку потрібно перевірити.

Search_Path
Ця заміна замінюється списком абсолютних шляхів до, розділених двокрапками
пошук під час пошуку файлів підтримки тестів.

Search_Path_Executable
Ця заміна замінюється списком абсолютних шляхів до, розділених двокрапками
пошук під час пошуку виконуваних файлів підтримки (файли бібліотеки та під-
команди).

Більшість часу $Search_Path_Executable абсолютно однакові. Проте під час “егіди -т
-бл” вони будуть різні, с $Seach_Path починаючи з каталогу розробки (the
виконується тест) і $Seach_Path_Executable починаючи з базової лінії (виконуваний файл
бігати).

Тест Результат Codes
Під час виконання кожного тесту (через тест_команда поле в проекті конфиг файл), егіда
визначає, успішний чи невдалий тест, переглядаючи його статус виходу. Цей вихід
статус в основному відповідає очікуванням для команд UNIX.

Успіх
Тест повинен вийти з 0, щоб вказати на успіх, тобто що конкретна функція, що тестується
працював, як очікувалося.

Провал
Тест повинен вийти з 1, щоб вказати на збій, тобто що конкретна функція, що перевіряється
не спрацювало, як очікувалося.

Немає результату
Тест має вийти 2, щоб вказати відсутність результату, тобто що конкретна функція під
тест не вдалося виконати, оскільки щось пішло не так. Наприклад, біг
бракує місця на диску під час створення тестових вхідних файлів у / Tmp каталог.

Пропущено
Тест має вийти 77, щоб вказати, що його було пропущено. Зазвичай це пов’язано з
поточна архітектура не має сенсу. По можливості використовуйте «Немає результату»
замість цього. (Значення вибрано для сумісності з іншими тестовими системами.)

Насправді будь-який код виходу, відмінний від 0, 1 або 77, буде інтерпретовано як «немає результату».
Однак завжди використовувати 0, 1, 2 або 77 означає, що якщо новий код результату вимагає a
пізніше випуску Aegis ваші існуючі тести продовжуватимуть працювати.

TEST КОРЕЛЯЦІЇ

Команду «aegis -Test -SUGgest» можна використовувати, щоб aegis запропонував відповідну регресію
тестування ваших змін на основі вихідних файлів у вашій зміні. Це автоматично
зосереджує зусилля тестування на відповідних тестах, зменшуючи кількість регресійних тестів
необхідно бути впевненим, що ви не запровадили помилку.

Тестові кореляції генеруються командою “aegis -Integrate_Pass”, яка
пов’язує кожен тест у зміні з кожним вихідним файлом у зміні. Таким чином, кожен
вихідний файл накопичує список тестів, які були пов’язані з ним у минулому.
Це не так точно, як аналіз покриття коду, але є розумним наближенням
практиці.

Команда aecp(1) і aenf(1) команди використовуються для зв'язування файлів зі зміною. Поки вони
не виконують активно асоціації, це файли, які використовуються aeipass(1) і
aet(1) щоб визначити, які вихідні файли пов'язані з якими тестами.

Тест Кореляція Точність
Припускаючи, що кореляції тестування точні і що тести рівномірні
розподілений по функціональному простору, буде менше ніж 1/число ймовірність, що а
відповідний тест не проводився за допомогою «aegis -Test -SUGgest номер” команда. Невеликої
кількість шуму додається до тестового зважування, так що іноді трапляються несподівані речі
перевірено, і одні й ті самі тести не виконуються кожен раз.

Точність кореляції тесту можна підвищити, переконавшись, що:

· Кожна зміна має бути чітко сфокусованою, без зайвих включень файлів. Це
уникає помилкових кореляцій.

· Кожен елемент нової функціональності слід додавати в окремі зміни, а не
кілька разом. Це тісно корелює тести з функціональністю.

· Кожну помилку слід виправляти окремо, а не декілька разом. Це
тісно корелює тести з функціональністю.

· Тестові кореляції будуть втрачені, якщо файли будуть переміщені. Це тому, що кореляції за
ім'я.

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

ВАРІАНТИ

Розбираються такі варіанти:

-АВТОМАТИЧНИЙ
Цей параметр можна використовувати для визначення автоматичних тестів. Автоматичні тести не вимагають
допомога людини.

-Базова лінія
Ця опція може використовуватися, щоб вказати, що базова лінія проекту є предметом
команду.

-Base_RElative
Цей параметр може використовуватися для того, щоб відносні імена файлів розглядалися відносно
основа вихідного дерева. Побачити aeuconf(5) для відповідного користувача
перевагу.

-Current_RELATE
Цей параметр може використовуватися для того, щоб відносні імена файлів розглядалися відносно
поточний каталог. Зазвичай це значення за замовчуванням. Побачити aeuconf(5) для
відповідні переваги користувача.

-Змінити номер
Ця опція може використовуватися для вказівки певної зміни в проекті. Побачити
егіда(1) для повного опису цієї опції.

-СИЛА Цей параметр можна використовувати для вказівки виконання всіх тестів, навіть якщо
статус останнього тестового запуску вказує на те, що немає необхідності запускати певний
тест.

-Допоможіть
Цей параметр можна використовувати для отримання додаткової інформації про те, як користуватися егіда
програми.

-Незалежний
Ця опція використовується, щоб вказати, що тест потрібно виконувати незалежно від будь-якого
особлива зміна. Якщо жодного тесту не вказано, будуть запущені всі тести базової лінії.

-Список
Цей параметр можна використовувати для отримання списку відповідних тем для цієї команди.
Список може бути більш загальним, ніж очікувалося.

- Вручну Цей параметр можна використовувати для визначення ручних тестів. Ручні тести вимагають участі людини
втручання, наприклад: підтвердження певної поведінки екрана (наприклад, X11), або
деяка дія користувача, «від’єднайте кабель Ethernet».

-Not_Logging
Цей параметр можна використовувати, щоб вимкнути автоматичне ведення журналу виводу та помилок
файл. Це часто корисно, коли кілька команд aegis об'єднані в оболонку
сценарій

- Наполегливо
Цей параметр можна використовувати для вказівки виконання всіх тестів, навіть якщо деякі
провал. За замовчуванням використовується для користувача persevere_preference якщо не вказано, див
aeuconf(5) для отримання додаткової інформації.

-No_PERsevere
Ця опція може бути використана, щоб вказати, що тестовий запуск має припинитися після першого
невдача. За замовчуванням використовується для користувача persevere_preference якщо не вказано, див
aeuconf(5) для отримання додаткової інформації.

-Проект ім'я
Цю опцію можна використовувати для вибору проекту, який цікавить. Коли ні -Проект
вказано опцію, AEGIS_PROJECT консультується зі змінною середовища. Якщо
якого не існує, користувача $HOME/.aegisrc файл перевіряється на наявність за замовчуванням
Поле проекту (див aeuconf(5) для отримання додаткової інформації). Якщо цього не існує,
коли користувач працює лише над змінами в межах одного проекту, проекту
Ім'я за замовчуванням відповідає цьому проекту. Інакше це помилка.

-PROGress
Ця опція може бути використана, щоб вказати, що повідомлення про хід повинні бути видані раніше
кожен тестовий запуск або перед кожним пакетним тестовим запуском у разі пакетна_тестова_команда поле
зазначено в проекті конфиг файл (див aeuconf(5) для отримання додаткової інформації).

-No_PROGress
Цей параметр можна використовувати, щоб вказати, що повідомлення про хід виконання повинні бути придушені.
Це значення за замовчуванням.

-РЕГРЕСІЯ
Цей параметр використовується, щоб вказати, що потрібно запустити набір тестів регресії. The
набір регресійних тестів складається з усіх тестів базової лінії, які не відображаються
у зміні. Це помилка, якщо немає регресійних тестів. Ви не можете
іменуйте тести в командному рядку під час використання параметра -REGression. Ви можете назвати
окремі тести для запуску в командному рядку без використання -REGression
варіант; якщо вони не є частиною змін, однойменні тести в
базовий рівень буде виконано.

-ПРОПОНУЙТЕ [ номер ]
"егіда -Integrate_Pass” команда збирає тестову статистику кореляції, коли
зміни інтегровані. Цю опцію можна використати для запиту пропозиції aegis
які тести слід виконувати, використовуючи ці тестові кореляції. Якщо номера немає
буде запропоновано 10 тестів. Цей варіант має на увазі -РЕГРЕСІЯ
варіант.

-SUGgest_Limit протокол
Цей параметр можна використовувати для обмеження кількості тестів до певної кількості
хвилин. Вони будуть проходити від найбільш релевантних до найменш релевантних.

-SUGgest_Noise номер
Цю опцію можна використовувати для контролю рівня шуму, що вводиться в тест
відбір виконує в -ПРОПОНУЙТЕ варіант. Число є відсотком шуму
вводити. За замовчуванням 10, якщо не вказано. Введення шуму забезпечує
що різноманітні тести виконуються під час наступних прогонів, а також деякі з лівого поля
як перевірка осудності.

-TERse
Ця опція може використовуватися для того, щоб списки створювали мінімум
інформації. Зазвичай це корисно для сценаріїв оболонки.

-Детальніше
Ця опція може бути використана, щоб змусити aegis виробляти більше результатів. За замовчуванням aegis
видає лише помилки. При використанні з -Список варіант цей варіант
викликає додавання заголовків стовпців.

-Почекай Цей параметр можна використовувати, щоб вимагати від команд Aegis очікування блокування доступу, якщо
їх неможливо отримати відразу. За замовчуванням для користувача lock_wait_preference
якщо не вказано, див aeuconf(5) для отримання додаткової інформації.

-Ні_чекай
Цей параметр можна використовувати, щоб вимагати, щоб команди Aegis видавали фатальну помилку під час доступу
замки неможливо отримати відразу. За замовчуванням для користувача
lock_wait_preference якщо не вказано, див aeuconf(5) для отримання додаткової інформації.

Дивіться також егіда(1) для параметрів, загальних для всіх команд aegis.

Усі варіанти можуть бути скороченими; абревіатура задокументована як великі літери,
усі малі літери та символи підкреслення (_) є необов’язковими. Ви повинні використовувати послідовний
послідовності необов'язкових букв.

Усі параметри не чутливі до регістру, ви можете вводити їх у верхньому чи нижньому регістрі чи a
поєднання обох, регістр не важливий.

Наприклад: всі аргументи "-project, "-PROJ" і "-p" інтерпретуються як
-Проект варіант. Аргумент "-prj" не буде зрозумілий, тому що послідовний
необов'язкові символи не були надані.

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

Довгі назви параметрів GNU зрозумілі. Оскільки всі назви параметрів для егіда довгі,
це означає ігнорування додаткового провідного '-'. "--варіант=значення"конвенція також
зрозумів.

РЕКОМЕНДУЄТЬСЯ ALIAS

Рекомендований псевдонім для цієї команди
csh% псевдонім aet 'aegis -t \!* -v'
sh$ aet(){aegis -t "$@" -v}

ПОМИЛКИ

Це помилка, якщо зміна не в одній із буття розвиненою or буття інтегрований
держави.
Якщо зміна не призначена поточному користувачеві, це помилка.
Це помилка, якщо у вас немає відповідних тестів і відповідного звільнення.

EXIT СТАТУС

Команда егіда команда вийде зі статусом 1 у разі будь-якої помилки. The егіда буде тільки команда
вийти зі статусом 0, якщо немає помилок.

НАВКОЛИШНЄ СЕРЕДОВИЩЕ ЗМІННІ

Читати егіда(1) для списку змінних середовища, які можуть вплинути на цю команду. Побачити
aepconf(5) для файлу конфігурації проекту конкретний_проект поле для встановлення
змінні середовища для всіх команд, що виконуються Aegis.

Використовуйте aet онлайн за допомогою сервісів onworks.net