aet - מקוון בענן

תָכְנִית:

שֵׁם

מבחן aegis - הפעל בדיקות

תַקצִיר

חסותו -מִבְחָן [ אוֹפְּצִיָה... ][ שם=ערך ][ שם קובץ... ]
חסותו -מִבְחָן -עצמאי [ אוֹפְּצִיָה... ][ שם=ערך ][ שם קובץ... ]
חסותו -מִבְחָן -רשימה [ אוֹפְּצִיָה... ]
חסותו -מִבְחָן -עֶזרָה

תיאור

אל האני חסותו -מִבְחָן הפקודה משמשת להפעלת בדיקות. אם אין שם של קבצים, כל הבדיקות הרלוונטיות
רצים. כברירת מחדל מופעלות גם בדיקות אוטומטיות וגם בדיקות ידניות.

אתה יכול לתת שם ספריות בשורת הפקודה, וכל הבדיקות הרלוונטיות בספרייה זו
עץ בשינוי יופעל. זו שגיאה אם ​​אין בדיקות רלוונטיות.

כל ארכיטקטורה חייבת להיבדק בנפרד. זה בגלל שיכול להיות עדין
בעיות שמתגלות רק בחלק מהארכיטקטורות. לחלק מהפרויקטים יש גם
קוד שונה עבור ארכיטקטורות שונות.

הסטטוס של ריצת הבדיקה האחרונה נזכר כך שבדיקות לא יופעלו אם אין
צוֹרֶך. (זה לא חל על -נְסִיגָה בדיקות, למרבה הצער.) יש להפעיל מחדש בדיקות
אם הבדיקה נכשלה בעבר, אם קובץ הבדיקה השתנה, אם היה בנייה,
ולכל ארכיטקטורה.

שם = ערך
ניתן להוסיף שם=ערך זוגות לשורת הפקודה, אלה יועברו ללא שינוי ל-
פקודת בדיקה. בדרך כלל בסוף שורת הפקודה, אך ניתן לשנות זאת ב-
קובץ תצורת הפרויקט.

אל האני כוח אפשרות גורמת לכך שמשתנה force=1 מרומז מתווסף לרשימה של
הקצאות משתנות, וכך נוסף לסוף הפקודה. זה הכי שימושי כאשר
באמצעות batch_test_command מתויק של קובץ תצורת הפרויקט.

זה עשוי להיראות בהתחלה כמו תהליך פיתוח סופי, המאפשר סקריפטים לבדיקה
נכתב כך שהם נותנים את כל התשובות הנכונות מבלי לעשות שום דבר. אתה
תמיד היו מסוגלים לעשות זאת עם משתני סביבה, אז זה לא משהו חדש.

אפשר לגרום לכל הקצאות המשתנים להפוך למשתני סביבה
על ידי הצבת $var ב- התחלה של הפקודה, לפני שם הקליפה, ולא ב
מיקום ברירת המחדל בסוף הפקודה.

שלח שם פרשנות
תוכנית aegis תנסה לקבוע את שמות קבצי הפרויקט מתוך שמות הקבצים
ניתן בשורת הפקודה. כל שמות הקבצים מאוחסנים בתוך פרויקטים של aegis כיחסי
לשורש של עץ ספריות קו הבסיס. ספריית הפיתוח וה-
ספריית השילוב הם צללים של ספריית הבסיס הזו, ולכן השמות היחסיים הללו
להחיל גם כאן. קבצים הנקראים בשורת הפקודה מומרים תחילה לנתיבים מוחלטים
אם נחוץ. לאחר מכן הם מושווים לנתיב הבסיס, ספריית הפיתוח
נתיב, ואת נתיב ספריית האינטגרציה, כדי לקבוע שם בסיס-יחסי. זה
שגיאה אם ​​הקובץ ששמו נמצא מחוץ לאחד מעצי הספריות הללו.

אל האני -BAse_RElative ניתן להשתמש באפשרות כדי לגרום לשמות קבצים יחסיים להתפרש כ
יחסית לנתיב הבסיס; שמות קבצים מוחלטים עדיין יושוו עם השמות השונים
נתיבים על מנת לקבוע שם בסיס-יחסי.

אל האני relative_filename_preference בקובץ תצורת המשתמש עשוי לשמש לשינוי
התנהגות ברירת מחדל זו. לִרְאוֹת aeuconf(5) למידע נוסף.

מבחן תהליך

כל שינוי נדרש להיות מלווה במבחנים, והבדיקות הללו נדרשות להיות
לרוץ נגד ספריית הפיתוח הבנויה, והם חייבים לעבור. זה מבטיח כי חדש
הפונקציונליות מלווה בבדיקות לאימות נכונותה, וכן תיקוני באגים
מלווה בבדיקות המאשרות שהבאג תוקן.

נסיגה בדיקות
בדיקות מטופלות כמו כל קובץ מקור אחר, ומתוחזקות בקו הבסיס ו
היסטוריה עם כל קבצי המקור האחרים. המבחנים שחייבים ללוות כל שינוי
להצטבר בקו הבסיס של הפרויקט, לספק הגדרה של פונקציה נכונה עבור
קו בסיס. ניתן לבצע את הבדיקות המצטברות הללו באמצעות פקודת "aegis -REGression",
כדי לוודא שהפרויקט לא "ייגמר" כתוצאה משינוי.

Baseline בדיקות
תיקוני באגים נדרשים כדי לבצע את הבדיקות שלהם להיכשל כנגד קו הבסיס של הפרויקט (בניגוד
לספריית הפיתוח). זה מבטיח שהבדיקה אכן מדגים את הבאג
בקו הבסיס, כמו גם הוכחה שהוא קבוע על ידי השינוי. חָדָשׁ
הפונקציונליות נכשלת באופן טריוויאלי מול קו הבסיס, ולכן aegis לא מנסה
נחשו אם בדיקה היא בדיקת תיקון באגים או בדיקת פונקציונליות חדשה, היא פשוט דורשת בדיקות כדי
להיכשל מול קו הבסיס.

דרישה זו חלה גם על מבחנים חדשים שנוצרים בעקבות שינוי וגם על מבחנים
שהועתקו לשינוי לצורך שינוי.

סוקר בדיקות
סוקרים עשויים להיות בטוחים ש-aegis אכף את דרישות הבדיקה; זה שינוי
חייבים מבחנים, שהשינוי חייב לבנות, שהבדיקות עוברות מול הפיתוח
מדריך, וכי הבדיקות נכשלות מול קו הבסיס. תנאים אלו נאכפים
by aede(1) והשינוי לא יקודם ל- להיות סקר המדינה עד אלה
מתקיימים תנאים. סוקרים צריכים אפוא לסקור מבחנים עבור שלמות של כיסוי של
הקוד בשינוי, וחוסר רגישות לשינויים בסביבת הביצוע (למשל
לא רגיש לתאריך). סוקרים צריכים גם להשתמש ב-"aegis -list change_details" כדי לאמת
שלשינוי יש או אין פטורים מבדיקה.

פטור
פטורים שונים מבדיקה עשויים להינתן על ידי מנהלי פרויקטים, ראה aepa(1) ו
aepatr(5) למידע נוסף. העתקת מבחנים לשינוי, או הוספת מבחנים חדשים ל-a
לשנות, רשאי לבטל פטורים אלה.

מבחן פקודה תְצוּרָה

הפקודה המשמשת לביצוע בדיקות מוגדרת על ידי ה test_command שדה בפרויקט
קובץ תצורה (ראה aepconf(5) למידע נוסף), זה כברירת מחדל לשימוש ב-
פגז בורן אם לא מוגדר. הספרייה הנוכחית תהיה בראש המתאים
עץ ספריות. אם בדיקות דורשות קבצים זמניים, עליהם ליצור אותם ב / Tmp, כמו
הבדיקה לא יכולה לצפות לקבל הרשאת כתיבה בספרייה הנוכחית.

אם אתה רוצה להשתמש במנוע בדיקה מתוחכם יותר, במקום בסקריפט קליפה פשוט,
אבל מנוע הבדיקה הזה לא מחזיר קודי תוצאות המתאימים לשימוש עם aegis, אתה יכול
עטפו אותו בסקריפט מעטפת שכותב מחדש את סטטוס היציאה לערכים שמצפה ל-aegis.
אתה יכול גם להשיג את אותן התוצאות על ידי כתיבת טקסט מורכב יותר test_command ב
פּרוֹיֶקט config קובץ.

אפשר גם לכתוב פקודות בדיקה שמסוגלות לבדוק יותר מקובץ אחד ב
פַּעַם. זה נשלט על ידי batch_test_command תחום הפרויקט config קוֹבֶץ. ב
במקרה זה, ההחלפה ${output} מציינת את שם הקובץ שפקודת הבדיקה חייבת
ליצור, ב aetest(5) פורמט, כדי להכיל את תוצאות הבדיקות הרצות. זה משמש לעתים קרובות
על מערכות עם מספר מעבדים או יכולת להפיץ עבודות על פני מספר מחשבים
ברשת.

החלפות
כל aesub(5) החלפות זמינות בפקודות הבדיקה. חלק מהם כן
יש לציין במיוחד:

ארכיטקטורה
החלפה זו מוחלפת בשם הארכיטקטורה שתיבדק.

Search_Path
החלפה זו מוחלפת ברשימה מופרדת בנקודתיים של נתיבים מוחלטים אל
חפש כאשר מחפשים קבצי תמיכה לבדיקה.

Search_Path_Executable
החלפה זו מוחלפת ברשימה מופרדת בנקודתיים של נתיבים מוחלטים אל
חפש כאשר מחפשים קבצי תמיכה ברי הפעלה (קבצי ספרייה ותת-
פקודות).

רוב הזמן $Search_Path_Executable זהים בדיוק. עם זאת, במהלך "aegis -t
-bl” הם יהיו שונים, עם $Seach_Path החל בספריית הפיתוח (ה
בדיקה שמתנהלת) ו $Seach_Path_Executable החל בקו הבסיס (הווית ההפעלה
לָרוּץ).

מִבְחָן תוֹצָאָה קופונים
כאשר כל בדיקה מופעלת (דרך test_command שדה בפרויקט config קובץ), aegis
קובע אם הבדיקה הצליחה או נכשלה על ידי הסתכלות על מצב היציאה שלה. היציאה הזו
המצב הוא לרוב כצפוי עבור פקודות UNIX.

הַצלָחָה
בדיקה צריכה לצאת מ-0 כדי לציין הצלחה, כלומר שהפונקציה הספציפית הנבדקת
עבד כמצופה.

כשלון
בדיקה צריכה לצאת מ-1 כדי לציין כישלון, כלומר שהפונקציה הספציפית הנבדקת
לא עבד כמצופה.

אין תוצאה
בדיקה צריכה לצאת מ-2 כדי לציין שאין תוצאה, כלומר שהפונקציה הספציפית תחת
לא ניתן היה לבצע את המבחן כי משהו אחר השתבש. למשל ריצה
אזל מקום בדיסק בעת יצירת קבצי קלט הבדיקה ב- / Tmp במדריך.

דילג
בדיקה צריכה לצאת מ-77 כדי לציין שדילג עליה. זה בדרך כלל קשור ל
הארכיטקטורה הנוכחית אינה בעלת משמעות. במידת האפשר, השתמש ב"ללא תוצאה"
במקום זאת. (הערך נבחר עבור תאימות למערכות בדיקה אחרות.)

למעשה, כל קוד יציאה שאינו 0, 1 או 77 יתפרש כ"אין תוצאה".
עם זאת, שימוש תמיד ב-0, 1, 2 או 77 אומר שאם נדרש קוד תוצאה חדש על-ידי a
שחרור מאוחר יותר של Aegis הבדיקות הקיימות שלך ימשיכו לעבוד.

מבחן מתאמים

ניתן להשתמש בפקודה "aegis -Test -SUGgest" כדי ש-aegis יציע רגרסיה מתאימה
בדיקות לשינוי שלך, על סמך קובצי המקור בשינוי שלך. זה אוטומטית
ממקד את מאמץ הבדיקה למבחנים רלוונטיים, ומצמצם את מספר מבחני הרגרסיה
הכרחי כדי להיות בטוח שלא הצגת באג.

מתאמי הבדיקה נוצרים על ידי הפקודה "aegis -Integrate_Pass", אשר
משייך כל בדיקה בשינוי לכל קובץ מקור בשינוי. לפיכך, כל אחד
קובץ המקור צובר רשימה של בדיקות שהיו קשורות אליו בעבר.
זה לא מדויק כמו ניתוח כיסוי קוד, אבל הוא קירוב סביר ב
תרגול.

אל האני aecp(1) ו aenf(1) פקודות משמשות כדי לשייך קבצים לשינוי. בזמן שהם
אל תבצע את השיוך באופן פעיל, אלו הקבצים שבהם משתמשים aeipass(1) ו
aet(1) כדי לקבוע אילו קובצי מקור משויכים לאילו בדיקות.

מִבְחָן מתאם דיוק
בהנחה שמתאמי הבדיקה מדויקים ושהבדיקות שווה
מופץ על פני חלל הפונקציה, יהיה פחות מ 1/מספר סיכוי שא
הבדיקה הרלוונטית לא בוצעה על ידי "aegis -Test -SUGgest מספר" פקודה. קטן
כמות הרעש מתווספת לשקלול הבדיקה, כך שדברים בלתי צפויים לפעמים
נבדק, ואותן בדיקות לא מופעלות בכל פעם.

ניתן לשפר את דיוק מתאם הבדיקה על ידי הבטחה ש:

· כל שינוי צריך להיות ממוקד מאוד, ללא הכללת קבצים מיותרים. זֶה
מונע מתאמים מזויפים.

· יש להוסיף כל פריט של פונקציונליות חדשה בשינוי אינדיבידואלי, במקום
כמה ביחד. זה מתאם מאוד בדיקות עם פונקציונליות.

· יש לתקן כל באג בשינוי פרטני, ולא בכמה ביחד. זֶה
מתאם חזק בין בדיקות לפונקציונליות.

· מתאמי בדיקה יאבדו אם קבצים יועברו. זה בגלל שמתאמים הם לפי
שם.

הדרך הטובה ביותר עבור בדיקות לתאם במדויק עם קבצי מקור היא בעת שינוי
מכיל בדיקה ובדיוק אותם קבצים הקשורים לפונקציונליות הנבדקת. גַם
קבצים מזויפים רבים יחלישו את התועלת של מתאמי הבדיקה.

אפשרויות

האפשרויות הבאות מובנות:

-אוֹטוֹמָטִי
ניתן להשתמש באפשרות זו כדי לציין בדיקות אוטומטיות. בדיקות אוטומטיות דורשות לא
סיוע אנושי.

-קו בסיס
ניתן להשתמש באפשרות זו כדי לציין שקו הבסיס של הפרויקט הוא הנושא של
הפקודה.

-BAse_RElative
ניתן להשתמש באפשרות זו כדי לגרום לשמות קבצים יחסיים להיחשב ביחס אליהם
הבסיס של עץ המקור. לִרְאוֹת aeuconf(5) עבור המשתמש המתאים
הַעֲדָפָה.

-CUrrent_RElative
ניתן להשתמש באפשרות זו כדי לגרום לשמות קבצים יחסיים להיחשב ביחס אליהם
הספרייה הנוכחית. זו בדרך כלל ברירת המחדל. לִרְאוֹת aeuconf(5) עבור
העדפת המשתמש המתאימה.

-שינוי מספר
ניתן להשתמש באפשרות זו כדי לציין שינוי מסוים בתוך פרויקט. לִרְאוֹת
חסותו(1) לתיאור מלא של אפשרות זו.

-כּוֹחַ ניתן להשתמש באפשרות זו כדי לציין שיש להפעיל את כל הבדיקות, גם אם
מצב ריצת הבדיקה האחרונה מעיד על כך שאין צורך להריץ ספציפי
מבחן.

-עֶזרָה
ניתן להשתמש באפשרות זו כדי לקבל מידע נוסף על אופן השימוש ב- חסותו
תכנית.

-עצמאי
אפשרות זו משמשת כדי לציין שהבדיקה תתבצע ללא תלות בכל
שינוי מסוים. אם אין שם בדיקות, כל הבדיקות בקו הבסיס יופעלו.

-רשימה
ניתן להשתמש באפשרות זו כדי לקבל רשימה של נושאים מתאימים לפקודה זו.
הרשימה עשויה להיות כללית יותר מהצפוי.

-מדריך ל ניתן להשתמש באפשרות זו כדי לציין בדיקות ידניות. בדיקות ידניות דורשות אדם מסוים
התערבות, למשל: אישור של התנהגות מסך כלשהי (X11, למשל), או
פעולה כלשהי של המשתמש, "נתק את כבל ה-Ethernet עכשיו".

-לא_רישום
ניתן להשתמש באפשרות זו כדי לבטל את הרישום האוטומטי של פלט ושגיאות
קובץ. זה שימושי לעתים קרובות כאשר מספר פקודות aegis משולבות במעטפת
תַסרִיט.

-תמידי
ניתן להשתמש באפשרות זו כדי לציין שיש להפעיל את כל הבדיקות, גם אם חלקן
לְהִכָּשֵׁל. ברירת המחדל לזו של המשתמש להתמיד_העדפה אם לא צוין, ראה
aeuconf(5) למידע נוסף.

-לא_חמור
ניתן להשתמש באפשרות זו כדי לציין שהפעלת הבדיקה תיעצר לאחר הראשונה
כישלון. ברירת המחדל לזו של המשתמש להתמיד_העדפה אם לא צוין, ראה
aeuconf(5) למידע נוסף.

-פּרוֹיֶקט שם
ניתן להשתמש באפשרות זו לבחירת הפרויקט המעניין. מתי לא -פּרוֹיֶקט
האפשרות מצוינת, ה AEGIS_PROJECT יש להתייעץ עם משתנה סביבה. אם
שלא קיים, של המשתמש $HOME/.aegisrc הקובץ נבדק לאיתור ברירת מחדל
שדה פרויקט (ראה aeuconf(5) למידע נוסף). אם זה לא קיים,
כאשר המשתמש עובד רק על שינויים בתוך פרויקט בודד, הפרויקט
ברירת המחדל של שם לפרויקט זה. אחרת, זו טעות.

-התקדמות
ניתן להשתמש באפשרות זו כדי לציין שיש להוציא הודעות התקדמות לפני כן
כל ריצת בדיקה או לפני כל ריצת בדיקה אצווה למקרה batch_test_command שדה
שצוין בפרויקט config קובץ (ראה aeuconf(5) למידע נוסף).

-אין התקדמות
ניתן להשתמש באפשרות זו כדי לציין שיש לדכא הודעות התקדמות.
זוהי ברירת המחדל.

-נְסִיגָה
אפשרות זו משמשת כדי לציין שיש להפעיל את חבילת בדיקות הרגרסיה. ה
חבילת מבחני רגרסיה מורכבת מכל הבדיקות בקו הבסיס שאינן מופיעות
בשינוי. זו שגיאה אם ​​אין מבחני רגרסיה. אסור לך
בדיקות שמות בשורת הפקודה בעת שימוש באפשרות -REGression. אתה יכול לתת שם
בדיקות בודדות שיופעלו בשורת הפקודה, ללא שימוש ב-REGression
אוֹפְּצִיָה; אם הם לא חלק מהשינוי, הבדיקות באותו שם ב-
יופעל קו הבסיס.

-לְהַצִיעַ [ מספר ]
"חסותו -Integrate_Pass” הפקודה אוספת נתונים סטטיסטיים של מתאם בדיקה כאשר
שינויים משולבים. אפשרות זו עשויה לשמש כדי לבקש ש-aegis יציע
אילו בדיקות יש להפעיל, באמצעות מתאמי בדיקה אלו. אם אין מספר
שצוין, יוצעו 10 מבחנים. אפשרות זו מרמזת על -נְסִיגָה
אוֹפְּצִיָה.

-SUGgest_Limit דקות
ניתן להשתמש באפשרות זו כדי להגביל את מספר הבדיקות למספר מסוים של
דקות. הם ינוהלו מהרלוונטיים ביותר לרלוונטיים לפחות.

-SUGgest_רעש מספר
ניתן להשתמש באפשרות זו כדי לשלוט בכמות הרעש המוזרקת לבדיקה
בחירה שבוצעה על ידי -לְהַצִיעַ אוֹפְּצִיָה. המספר הוא אחוז רעש
להזריק. ברירת המחדל היא 10 אם לא צוין. הזרקת הרעש מבטיחה
שמגוון בדיקות מתנהלות בריצות עוקבות, וגם חלק מהשדה השמאלי
כבדיקת שפיות.

-תַמצִיתִי
אפשרות זו עשויה לשמש כדי לגרום לרישומים לייצר את המינימום של
מֵידָע. זה בדרך כלל שימושי עבור סקריפטים של מעטפת.

-מִלוּלִי
ניתן להשתמש באפשרות זו כדי לגרום ל-aegis להפיק יותר פלט. כברירת מחדל aegis
מייצר פלט רק על שגיאות. בשימוש עם ה -רשימה אפשרות אפשרות זו
גורם להוספת כותרות עמודות.

-לַחֲכוֹת ניתן להשתמש באפשרות זו כדי לדרוש מפקודות Aegis להמתין למנעולי גישה, אם
לא ניתן להשיגם מיד. ברירת המחדל לזו של המשתמש lock_wait_preference
אם לא צוין, ראה aeuconf(5) למידע נוסף.

-לא חכה
ניתן להשתמש באפשרות זו כדי לדרוש מפקודות Aegis לשלול שגיאה קטלנית אם גישה
לא ניתן להשיג מנעולים מיד. ברירת המחדל לזו של המשתמש
lock_wait_preference אם לא צוין, ראה aeuconf(5) למידע נוסף.

ראה גם חסותו(1) לאפשרויות המשותפות לכל פקודות ה-aegis.

כל האפשרויות עשויות להיות מקוצרות; הקיצור מתועד באותיות גדולות,
כל האותיות הקטנות והקו תחתון (_) הם אופציונליים. עליך להשתמש ברצף
רצפים של אותיות אופציונליות.

כל האפשרויות אינן תלויות רישיות, אתה יכול להקליד אותן באותיות גדולות או קטנות או א
שילוב של שניהם, המקרה אינו חשוב.

לדוגמה: הארגומנטים "-project, "-PROJ" ו-"-p" מתפרשים כולם כמשמעותם של
-פּרוֹיֶקט אוֹפְּצִיָה. הטיעון "-prj" לא יובן, כי רצוף
תווים אופציונליים לא סופקו.

אפשרויות וארגומנטים אחרים של שורת הפקודה עשויים להתערבב באופן שרירותי בשורת הפקודה,
אחרי בוררי הפונקציות.

שמות האופציות הארוכים של GNU מובנים. מאז כל שמות האפשרויות עבור חסותו ארוך,
המשמעות היא התעלמות מה-'-' המוביל הנוסף. ה "--אוֹפְּצִיָה=ערך"המוסכמה היא גם
הבין.

מומלץ כינוי

הכינוי המומלץ לפקודה זו הוא
csh% כינוי aet 'aegis -t \!* -v'
sh$ aet(){aegis -t "$@" -v}

שגיאות

זוהי שגיאה אם ​​השינוי אינו באחד מה להיות מפותח or להיות משולב
מדינות.
זוהי שגיאה אם ​​השינוי אינו מוקצה למשתמש הנוכחי.
זו טעות אם אין לך בדיקות רלוונטיות ואין לך פטור רלוונטי.

יְצִיאָה סטָטוּס

אל האני חסותו הפקודה תצא עם סטטוס 1 בכל שגיאה. ה חסותו הפקודה תהיה בלבד
צא עם סטטוס 0 אם אין שגיאות.

הסביבה וריאציות

לִרְאוֹת חסותו(1) עבור רשימה של משתני סביבה שעשויים להשפיע על פקודה זו. לִרְאוֹת
aepconf(5) עבור קובץ התצורה של הפרויקט פרויקט_ספציפי שדה כיצד להגדיר
משתני סביבה עבור כל הפקודות המבוצעות על ידי Aegis.

השתמש ב-aet באינטרנט באמצעות שירותי onworks.net