בדיקת עומסים כשירות CI למפתחים

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

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

אתה יכול למצוא פתרונות לכמה בעיות ארגוניות בבדיקות שאנו משתמשים בהן ב-Positive Technologies ב מאמר אחר. ובזה, אדבר על האפשרות לשלב בדיקות עומס בצינור CI נפוץ תוך שימוש במושג "בדיקת עומס כשירות" (בדיקת עומס כשירות). תלמד כיצד ובאילו תמונות docker של מקורות עומס ניתן להשתמש בצינור CI; כיצד לחבר מקורות עומס לפרויקט ה-CI שלך באמצעות תבנית בנייה; איך נראה צינור ההדגמה להפעלת בדיקות עומס ופרסום התוצאות. המאמר עשוי להיות שימושי למהנדסי בדיקות תוכנה ומהנדסי אוטומציה ב-CI שחושבים על הארכיטקטורה של מערכת העומס שלהם.

מהות הרעיון

הרעיון של בדיקת עומס כשירות מרמז על היכולת לשלב את כלי הטעינה Apache JMeter, Yandex.Tank והמסגרות שלך למערכת אינטגרציה רציפה שרירותית. ההדגמה תהיה עבור GitLab CI, אך העקרונות משותפים לכל מערכות ה-CI.

בדיקת עומסים כשירות הינו שירות מרוכז לבדיקת עומסים. בדיקות עומס מופעלות במאגרי סוכנים ייעודיים, התוצאות מתפרסמות אוטומטית ב-GitLab Pages, Influx DB ו-Grafana או במערכות דיווח בדיקות (TestRail, ReportPortal וכו'). אוטומציה ושינוי קנה מידה מיושמים בצורה פשוטה ככל האפשר - על ידי הוספה ופרמטר של תבנית gitlab-ci.yml הרגילה בפרויקט GitLab CI.

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

למען פשטות התיאור, נניח שיישום היעד או השרת הנבדק כבר נפרס והוגדר מראש (ניתן להשתמש בסקריפטים אוטומטיים ב- Python, SaltStack, Ansible וכו'). אז כל הרעיון של בדיקת עומס כשירות מתאים לשלושה שלבים: הכנה, בדיקה, פרסום דוחות. פרטים נוספים על התרשים (כל התמונות ניתנות ללחיצה):

מושגי יסוד והגדרות בבדיקת עומסים

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

סוכן עומס - מכונה וירטואלית בה תופעל האפליקציה - מקור הטעינה (Apache JMeter, Yandex.Tank או מודול עומס בכתב עצמי).

יעד בדיקה (יעד) - שרת או אפליקציה מותקן על השרת שיהיה נתון לטעינה.

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

פרופיל או תוכנית טעינה (פרופיל) - פנימה מתודולוגיית ISTQB (סעיף 4.2.4, עמ' 43) פרופילי עומס מגדירים מדדים שהם קריטיים לבדיקה מסוימת ואפשרויות לשינוי פרמטרי עומס במהלך הבדיקה. ניתן לראות דוגמאות של פרופילים באיור.

מִבְחָן - סקריפט עם קבוצה קבועה מראש של פרמטרים.

תכנית בדיקה (תכנית בדיקה) - סט בדיקות ופרופיל עומס.

Testran (testrun) - איטרציה אחת של הפעלת בדיקה אחת עם תרחיש עומס מבוצע במלואו והדוח שהתקבל.

בקשת רשת (בקשה) — בקשת HTTP שנשלחה מסוכן אל יעד.

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

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

זמן תגובה (שהייה) - הזמן מסיום שליחת בקשה (בקשה) ועד תחילת קבלת תגובה (תגובה).

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

מדדים בסיסיים למדידת פרמטרי עומס

כמה מהנפוצים והמומלצים ביותר במתודולוגיה ISTQB (עמ' 36, 52) המדדים מוצגים בטבלה להלן. מדדים דומים עבור סוכן ויעד רשומים באותה שורה.

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

כמות  vCPU וזיכרון RAM,
דיסק - מאפייני "ברזל" של סוכן העומס
CPU, זיכרון, שימוש בדיסק - דינמיקה של טעינת מעבד, זיכרון ודיסק
בתהליך הבדיקה. נמדד בדרך כלל כאחוז מ
ערכים זמינים מקסימליים

תפוקת רשת (על סוכן עומס) - תפוקה
ממשק רשת בשרת,
היכן מותקן סוכן העומס.
נמדד בדרך כלל בבתים לשנייה (bps)
תפוקת רשת(במטרה) - רוחב פס של ממשק רשת
בשרת היעד. נמדד בדרך כלל בבתים לשנייה (bps)

משתמשים וירטואליים- מספר המשתמשים הווירטואליים,
יישום תרחישי עומס ו
חיקוי פעולות משתמש אמיתיות
סטטוס משתמשים וירטואליים, עבר/נכשל/סה"כ - מספר מוצלחים ו
סטטוסים לא מוצלחים של משתמשים וירטואליים
עבור תרחישי עומס, כמו גם המספר הכולל שלהם.

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

בקשות לשנייה (דקה)- מספר בקשות הרשת בשנייה (או דקה).

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

מאפיין חשוב של שירות היעד: כמה
ליצור ולשלוח תגובות לשאילתות עם
סוכן הטעינה

סטטוס תגובת HTTP- מספר קודי תגובה שונים
משרת היישומים שהתקבל על ידי סוכן הטעינה.
לדוגמה, 200 OK פירושו שיחה מוצלחת,
ו-404 - שהמשאב לא נמצא

חֶבִיוֹן (זמן תגובה) - זמן מהסוף
שליחת בקשה (בקשה) לפני שמתחילים לקבל תגובה (תגובה).
נמדד בדרך כלל באלפיות שניות (ms)

זמן תגובה לעסקה- זמן עסקה אחת שלמה,
השלמת מחזור הבקשה-תגובה.
זה הזמן מתחילת שליחת הבקשה (בקשה)
עד לסיום קבלת תגובה (תגובה).

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

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

סטטוס עסקה , עבר / נכשל / סה"כ - מספר
מוצלח, לא מוצלח והמספר הכולל של העסקאות.

למשתמשים אמיתיים לא מוצלח
המשמעות של העסקה תהיה למעשה
חוסר יכולת לעבוד עם המערכת תחת עומס

תרשים סכמטי של בדיקת עומס

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

הערות סכמטיות:

• QA.Tester הוא מומחה בבדיקת עומסים,
• Target הוא יישום היעד שעבורו אתה רוצה לדעת את ההתנהגות שלו תחת עומס.

מסווג של ישויות, שלבים ושלבים בתרשים

שלבים ושלבים
מה קורה
מה יש בכניסה
מה הפלט

הכנה: שלב ההכנה לבדיקה

LoadParameters
הגדרה ואתחול
על ידי המשתמש
טעינת פרמטרים,
בחירת מדדים ו
הכנת תוכנית בדיקה
(טען פרופיל)
אפשרויות מותאמות אישית עבור
אתחול סוכן עומס
תוכנית בדיקה
מטרת הבדיקה

VM
פריסת ענן
מכונה וירטואלית עם
מאפיינים נדרשים
הגדרות VM עבור סוכן הטעינה
סקריפטים אוטומציה עבור
יצירת VM
VM מוגדר ב
הענן

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

LoadAgents
התקנה, תצורה ופרמטריזציה
סוכן הטעינה.
או הורדת תמונת docker מ
מקור טעינה מוגדר מראש
טען תמונת דוקר מקור
(YAT, JM או מסגרת בכתב עצמי)
הגדרות
סוכן עומס
מוגדר ומוכן
לסוכן עומס עבודה

בדיקה: שלב ביצוע בדיקות עומס. המקורות הם סוכני עומס הפרוסים במאגרי סוכנים ייעודיים עבור GitLab CI

לִטעוֹן
הפעלת סוכן הטעינה
עם תוכנית בדיקה שנבחרה
וטעינת פרמטרים
אפשרויות משתמש
לאתחול
סוכן עומס
תוכנית בדיקה
מטרת הבדיקה
יומני ביצוע
בדיקות עומס
יומני מערכת
דינמיקה של שינויים במדדי יעדים וסוכן עומס

הפעל סוכנים
הוצאה להורג של סוכן
המון סקריפטים לבדיקה
בהתאם
טען פרופיל
אינטראקציה של סוכן טען
לצורך בדיקה
תוכנית בדיקה
מטרת הבדיקה

יומנים
אוסף יומנים "גולמיים".
במהלך בדיקת עומס:
עומס רשומות פעילות של סוכן,
מצב יעד הבדיקה
וה-VM שמנהל את הסוכן

יומני ביצוע
בדיקות עומס
יומני מערכת

מדדים
איסוף מדדים "גולמיים" במהלך הבדיקה

דינמיקה של שינויים במדדי יעדים
וסוכן עומס

דוח: שלב הכנת דוח הבדיקה

גֵנֵרָטוֹר
עיבוד שנאסף
מערכת טעינה ו
מערכת ניטור "גולמית"
מדדים ויומנים
גיבוש דוח ב
צורה קריא אנושית
אפשרי עם אלמנטים
אנליסטים
יומני ביצוע
בדיקות עומס
יומני מערכת
דינמיקה של שינויים במדדים
מטרה וסוכן עומס
יומנים "גולמיים" מעובדים
בפורמט המתאים ל
העלאות לאחסון חיצוני
דוח עומס סטטי,
קריא אדם

לפרסם
פרסום הדו"ח
לגבי עומס
בדיקה חיצונית
שֵׁרוּת
מעובד "גולמי"
יומנים בפורמט מתאים
לפריקה לחוץ
קמרונות
נשמר בחוץ
דוחות אחסון על
עומס, מתאים
לניתוח אנושי

חיבור מקורות עומס בתבנית CI

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

ראשית, בעזרת מהנדסי ה-DevOps שלנו, יצרנו מאגר ייעודי של סוכנים ב- GitLab CI להפעלת בדיקות עומס. כדי לא לבלבל אותם בתבניות עם אחרים, כמו בריכות הרכבה, הוספנו תגיות לסוכנים האלה, תיוגים: לטעון. אתה יכול להשתמש בכל תגיות מובנות אחרות. הם שאלו במהלך הרישום GitLab CI Runners.

כיצד לגלות את הכוח הנדרש לפי חומרה? ניתן לחשב את המאפיינים של סוכני עומס - מספר מספיק של vCPU, זיכרון RAM ודיסק על סמך העובדה ש-Docker, Python (עבור Yandex.Tank), סוכן GitLab CI, Java (עבור Apache JMeter) צריכים לפעול על הסוכן . עבור Java תחת JMeter, מומלץ גם להשתמש במינימום של 512 MB של זיכרון RAM וכגבול עליון, 80% זיכרון זמין.

לפיכך, בהתבסס על הניסיון שלנו, אנו ממליצים להשתמש לפחות ב-4 vCPUs, 4 GB RAM, 60 GB SSD עבור סוכני עומס. התפוקה של כרטיס הרשת נקבעת על סמך הדרישות של פרופיל העומס.

אנו משתמשים בעיקר בשני מקורות טעינה - Apache JMeter ו-Yandex.Tank docker images.

Yandex.Tank הוא כלי קוד פתוח מבית Yandex לבדיקת עומסים. הארכיטקטורה המודולרית שלו מבוססת על מחולל בקשות HTTP אסינכרוני בעל ביצועים גבוהים של Phantom. הטנק כולל ניטור מובנה של משאבי השרת הנבדק באמצעות פרוטוקול SSH, יכול לעצור את הבדיקה באופן אוטומטי בתנאים מוגדרים, יכול להציג את התוצאות הן בקונסולה והן בצורה של גרפים, אתה יכול לחבר את המודולים שלך אליו כדי להרחיב את הפונקציונליות. אגב, השתמשנו בטנק כשהוא עדיין לא היה מיינסטרים. במאמר "אוטומציה של Yandex.Tank ועומסים» אתה יכול לקרוא את הסיפור של איך ביצענו איתו בדיקות עומס ב-2013 PT Application Firewall הוא אחד ממוצרי החברה שלנו.

אפאצ'י Jeter הוא כלי לבדיקת עומסים בקוד פתוח מבית Apache. ניתן להשתמש בו באותה מידה לבדיקת יישומי אינטרנט סטטיים ודינאמיים כאחד. JMeter תומך במספר עצום של פרוטוקולים ודרכים לאינטראקציה עם יישומים: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET וכו'), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) ו-IMAP(S), מסדי נתונים דרך JDBC, יכולים לבצע פקודות מעטפת ולעבוד עם אובייקטי Java. ל-JMeter יש IDE ליצירה, איתור באגים וביצוע תוכניות בדיקה. קיים גם CLI לפעולת שורת הפקודה בכל מערכת הפעלה תואמת Java (Linux, Windows, Mac OS X). הכלי יכול ליצור באופן דינמי דוח בדיקת HTML.

לנוחות השימוש בתוך החברה שלנו, למען יכולתם של הבודקים עצמם לשנות ולהוסיף את הסביבה, עשינו בניית תמונות דוקר של מקורות עומס ב- GitLab CI עם פרסום למערכת הפנימית docker registry ב-Artifactory. זה עושה את זה מהיר יותר וקל יותר לחבר אותם בצינורות לבדיקות עומס. כיצד לבצע דחיפה של docker לרישום באמצעות GitLab CI - ראה הוראות.

לקחנו את קובץ הדוקר הבסיסי הזה עבור Yandex.Tank:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

ועבור Apache JMeter זה:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

תוכל לקרוא כיצד פועלת מערכת האינטגרציה הרציפה שלנו במאמר "אוטומציה של תהליכי פיתוח: איך הטמענו רעיונות DevOps ב-Positive Technologies".

תבנית וצינור

דוגמה לתבנית לביצוע בדיקות עומס זמינה בפרויקט טעינת הדגמה. בתוך קובץ readme אתה יכול לקרוא את ההוראות לשימוש בתבנית. בתבנית עצמה (קובץ .gitlab-ci.yml) יש הערות לגבי מה אחראי כל שלב.

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

1. שלב להכין יש להשתמש כדי להגדיר מראש יעדי בדיקה או לבדוק את זמינותם. אין צורך להגדיר את סביבת מקורות הטעינה, הם בנויים מראש כתמונות docker ומפורסמות ברישום docker: רק ציין את הגרסה הרצויה בשלב הבדיקה. אבל אתה יכול לבנות אותם מחדש וליצור תמונות שהשתנו משלך.
2. שלב מִבְחָן משמש לציון מקור הטעינה, הפעלת בדיקות ואחסון חפצי בדיקה. אתה יכול לבחור כל מקור טעינה: Yandex.Tank, Apache JMeter, שלך או כולם ביחד. כדי להשבית מקורות מיותרים, פשוט הגיבו או מחק את העבודה. נקודות כניסה למקורות עומס:
   • פרמטרי השקה עבור Yandex.Tank מפורטים ב-./tests/yandextank.sh,
   • פרמטרי ההפעלה של Apache JMeter מצוינים בקובץ ./tests/jmeter.sh.

   הערה: תבנית תצורת ההרכבה משמשת להגדרת אינטראקציה עם מערכת ה-CI ואינה מרמזת על מיקום היגיון בדיקה בה. עבור בדיקות, נקודת הכניסה מצוינת, שבה נמצא סקריפט הבקרה של הבקרה. שיטת הפעלת הבדיקות, הפקת דוחות ותסריטי הבדיקה עצמם חייבת להיות מיושמת על ידי מהנדסי QA. בהדגמה, עבור שני מקורות הטעינה, בקשת הדף הראשי של Yandex משמשת כמבחן הפשוט ביותר. סקריפטים ופרמטרי בדיקה נמצאים בספרייה ./בדיקות.

3. בשלב להגיש תלונה עליך לתאר כיצד לפרסם את תוצאות הבדיקה שהושגו בשלב הבדיקה לאחסון חיצוני, למשל לדפי GitLab או למערכות דיווח מיוחדות. GitLab Pages דורש שהספרייה ./public לא תהיה ריקה ותכיל לפחות קובץ index.html לאחר סיום הבדיקות. אתה יכול לקרוא על הניואנסים של שירות GitLab Pages. по ссылке.

   דוגמאות לייצוא נתונים:

   • מ-JMeter ועד דפי GitLab,
   • מ-Yandex.Tank ל InfluxDB ו-Grafana.

   פרסום הוראות התקנה:

   • סטטי HTML ב דפי GitLab,
   • ל-InfluxDB ולאחר מכן ל גרפנה.

בדוגמה ההדגמה, הצינור עם בדיקות עומס ושני מקורות עומס (תוכל לבטל את המיותר) נראה כך:

Apache JMeter יכול להפיק דוח HTML בעצמו, כך שכדאי יותר לשמור אותו בדפי GitLab באמצעות כלים סטנדרטיים. כך נראה דוח Apache JMeter:

בדוגמה ההדגמה של Yandex.Tank, תראה רק דוח טקסט מזויף במדור עבור דפי GitLab. במהלך הבדיקה, הטנק יכול לשמור את התוצאות במסד הנתונים של InfluxDB, ומשם ניתן להציג אותן, למשל, ב-Grafana (ההגדרה מתבצעת בקובץ ./tests/example-yandextank-test.yml). כך נראה הדו"ח של טנק בגרפאנה:

תקציר

במאמר דיברתי על המושג "בדיקת עומס כשירות" (בדיקת עומס כשירות). הרעיון המרכזי הוא להשתמש בתשתית של מאגרים מוגדרים מראש של סוכני עומס, תמונות docker של מקורות עומס, מערכות דיווח וצינור המשלב אותם ב- GitLab CI בהתבסס על תבנית .gitlab-ci.yml פשוטה (דוגמה по ссылке). כל זה נתמך על ידי צוות קטן של מהנדסי אוטומציה ומשוכפל לבקשת צוותי מוצר. אני מקווה שזה יעזור לך בהכנה ויישום תוכנית דומה בחברה שלך. תודה על תשומת הלב!

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

מחבר: טימור גילמולין - סגן ראש תחום טכנולוגיה ותהליכי פיתוח (DevOps) בחברת Positive Technologies

מקור: www.habr.com