הרצאה 1 - קורס Load Runner הראשון
פרקי ההרצאה: הרצאה 1 - קורס Load Runner הראשון
תמלול ההרצאה: הרצאה 1 - קורס Load Runner הראשון
הטקסט המלא של הדקות הראשונות בהרצאה «הרצאה 1 - קורס Load Runner הראשון» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
עכשיו אפשר להתחיל, אוקיי מצוין, טוב אנחנו מתחילים בהרצאה, מצוין, אוקיי השיעור הראשון שאנחנו מתחילים בו זה בדיקות אוטומטיות ובדיקות עומסים והכלי שאנחנו נשתמש בו זה לואוד ראמר, שמי מקסים גניף, מטרת הקורס היא לתת לכם אפשרות לבצע בדיקות עומסים בסביבה שאתם תבחרו בה ולדעת
איך אוספים את הנתונים, איך מבצעים בדיקות אוטומטיות, איך מבצעים בדיקות עומסים. הכלי שאנחנו בחרנו זה לואוד ראנר מחברת HP שבמקור הייתה חברת מרקורי ונרכשה לפני מספר שנים.
הכלי קיים כבר קרוב ל-15 שנים בשוק, אולי קצת יותר. הגרסה שאנחנו עובדים בה היא גרסה 11 וכל הקומפוננטות שקיימים בכלי אנחנו נוכל לחשוף לפניכם וככה תדעו להשתמש בו.
התהליך של הבדיקות ומסים הוא תהליך לא פשוט, יש בו מספר שלבים ואנחנו נדע מה ה-Workflow הקיים בבדיקות עומסים וגם נדע לבצע את הסצנריו ולבצע את ההקלטה של ה-Load Runner.
בנוסף, בהמשך הקורס נדע לכתוב Runtime Settings בעצם להגדיר את כל מה שנדרש לנו בשביל להעלות את העומס, בשביל להגדיר את הסצנריו הנדרש, להשתמש ב-Virtual Users, ב-Load Generators, אלה מושגים מעולם ה-Load Runner, ואנחנו נלמד אותם בהמשך.
וכמובן, אנחנו נבחר את האפליקציה האמיתית לבדיקות עומסים. אנחנו נבחר סימולטור טיסות, סימולטור הזמנת טיסות, שמי שיצר אותו זה חברת HP, מר קוריל לשעבר, והיא אפליקציה ובית.
הקורס הזה התמקד לרוב באפליקציות וביות. כמובן אני אזכיר את היכולות של הכלי ואם אנחנו ניכנס לסטארט של המחשב שלי ואנחנו נלך ל... תיקיית לואוד ראונר אפשר לראות בסמפלס הפניה ל-HP Web Tools אפליקיישן היא עובדת עם ה-Web Service זאת אומרת אם אני אעלה כרגע את ה-Web Service על המחשב שלי ונחזור על אותו תהליך
דביר להניח שאנחנו נוכל להיכנס לאפליקציה ולראות מה היא עושה כרגע זה מעלה, ככה תראה האפליקציה שאנחנו הולכים לבדוק, עוד מעט תראו את שאר הדברים, צריך להירשם, אני אנסה להשתמש ביוזר הקיים שלי, כמובן אני אסביר בהמשך איך נרשמים לאפליקציה ומה אפשר, בואו נראה אם
יש לנו, אוקיי, טעיתי בסיסמה, נוותר בשלב הזה, לא כל כך חשוב, אפליקציית הזמנת טיסות, אתם עושים את זה בדקה תשעים בגוליבר בכל דבר נוסף וככה תראו אוקיי משהו מפריע לי לעבור הנה הצלחתי אוקיי תהליך הקורס הקורס מורכב מתשע עשרה שיעורים השיעור ה-CRY פי ספופינג נושא שעומד מאחורי לואוד ראנדר מאפשר להריץ הרבה יוזרים מהמכונה אחת שיעור אופציונלי
אנחנו היום בשיעור ראשון Product Training נלמד על המוצר ועל כל המרכיבים שלו בשיעור שלישי נלמד להתקין את הלואוד ראונר זה תהליך לא כל כך טריוויאלי אני אתן לכם את ההורדה ונמשיך הלאה בשיעור תשיעי אנחנו נוכל לנתח את כל התוצאות שיצרנו בשיעור שביעי נלמד על ה-Performance Monitors וכל הניטורים של האפליקציה אוקיי, למה צריך לעשות בדיקות עומסים?
קודם כל, היום בעולם שלנו שהמערכות מאוד מאוד מורכבות, הן מורכבות מהרבה שכבות והארכיטקטורה מאוד מורכבת, האפליקציות נופלות, המערכות נופלות.
והן לא נופלות סתם, הן נופלות בגלל התעבורה לא צפויה ברשת, בגלל הכמות של המשתמשים הגבוה. מה קורה ללקוחות שלכם, ללקוחות של האפליקציות שלכם?
הם פשוט עוזבים, עוזבים אתכם לטובת המתחרים. כדי שנוכל למנוע את המצב הזה, אנחנו צריכים לבצע בדיקות עומסים לפני, בדיקות פרפורמנס לפני, וככה נוכל למנוע את הדברים.
אני לא יודע אם אתם מודעים לזה, אבל 15% האנשים שהתחילו להשתמש ב-loadrunner או בכלים מסוג דומה, גילו שהם עומדים רק ב-15% מציפיות הפרפורמנס שלהם.
זאת אומרת, אם הם ציפו שהמערכת שלהם תעבוד ב-100 משתמשים, היא רק עמדה ב-15 משתמשים בשלב הראשון של הבדיקה. אחרי זה אפשר לעשות Fine Tuning, אפשר לשפר את האפליקציה, אבל רק שתדעו, חייבים בדיקות עומסים.
מה עוד? כשאנחנו בעצם נמצאים בעולם האמיתי, אנחנו, כמו שאמרתי, לא מודעים לכל מה שיכול לקרות. פתאום יצאה הודעה, לדוגמת האתר של חברת החשמל, פתאום הם מודיעים שיש עומס, מודיעים על השירות החדש וכולם נכנסים לאתר שלהם, האתר ייפול.
וזה דברים שקרו וזה דברים שיכולים לקרות. ברגע שאנחנו נבצע בדיקות עומסים אנחנו נקטין את הזמן הפיתוח, אנחנו נדע שהמוצר לא יחזור אלינו אחרי שהוא היה אצל הלקוח.
וכמובן, אנחנו נוכל להיערך לחומרה הנדרשת. אנחנו נדע בדיוק מה החומרה שאנחנו צריכים כדי לשחרר את המוצר, וככה גם נקטין את העלויות של החומרה.
אוקיי, כשאנחנו מדברים על בדיקות עומסים, לא תמיד אנחנו מתכוונים ל-Low Testing בלבד. יש גם בדיקות נוספות, כמו Press Testing, Volume Testing ו-Component Testing.
מה הכוונה ל-Component Testing? שאנחנו מבצעים רק שכבה אחת של בדיקות. יש לנו מערכת שמורכבת משלוש שכבות, משלושה רכיבים, אנחנו נבדוק רק רכיב אחד ואנחנו נדע להגיד שהזמן תגובה ברכיב הזה הוא X שניות.
זה לא אומר שבכל המערכת הזמן תגובה הוא יהיה X שניות, הוא יכול להיות יותר, הוא לא יכול להיות פחות, בדרך כלל הוא יותר. בדיקות עומסים, זה מה שאנחנו קוראים לואו טסטינג, למעשה, אני מצפה שמערכת שלי תעמוד בעומס מסוים.
וכדי להגיע במצב נורמלי, בסביבה נורמלית, בכמות המשתמשים הנורמלית, וזה ה-Low Testing, לזה אנחנו מתכוונים כשאנחנו מדברים ל-Low Testing.
יש גם Stress Testing. הכמות הלא צפויה של המשתמשים פתאום נכנסת למערכת, 10,000, 20,000, 30,000, ואנחנו נעשה גם את הבדיקה הזאת כדי להיערך למצב הזה.
בדרך כלל המערכת עובדת עם 100 משתמשים, ביום מסוים היא עובדת עם 200 משתמשים. צריך לבדוק שאנחנו נוכל לעמוד בפיק הזה. ווליום טסטינג, המערכת אולי עומדת ב-100 משתמשים לשנייה, לשתי שניות, לשלוש שניות, אבל האם המערכת מסוגלת לעבוד 24 שעות, 7 ימים בשבוע, בעומס הזה?
וזה נקרא ווליום טסטינג. ואלה הבדיקות גם שנעשים בעזרת המוצר, מריצים אותם בדרך כלל בסופי שבוע בלילות כדי לוודא שאנחנו יכולים לעמוד בעומס לאורך זמן. השאלות בדרך כלל שנשאלות בבדיקות עומסים הן שאלות כמו כמה זמן לוקח למשתמש לבצע פעולה מסוימת?
כמה זמן עד שהחלון חוזר אליי? וזה נקרא Application Response Time. אני רוצה לדעת כמה זיכרון אני צריך בשביל האפליקציה שלי, וזה נקרא Configuration Sizing.
אני רוצה בעצם להתאים את המערכת שלי לחומרה מסוימת. מפתחים או Production Managers בדרך כלל שואלים את עצמם האם המערכת היא מספיק בשלה כדי לצאת לעולם החוצה, אם היא מוכנה ללכת ללקוחות, וגם כאן Load Runner נותן לנו מענה.
אני בדרך כלל אבצע בדיקת עומסים פעם אחת ומחר אני מוסיף עוד פיצ'ר נוסף. האם אני יכול לבצע אותה בדיקת עומסים פעם נוספת?
כן, אם אני משתמש במוצר שיש בו סצנריות מוקלטים. וזה לרגרשן. מאוד חשוב לי שהמערכת תהיה אמינה. ומתי אני אדע שהמערכת אמינה?
כשהיא עומדת בעומס מסוים. המערכת שלי, בדקתי אותה, כל שכבה ושכבה עונה לי לדרישות, אבל משהו בכל זאת תוקע, ומה זה יכול להיות? איזשהו באטרנק.
יכול להיות שיש לי לוק על הדאטאבייס, יכול להיות שהכרטיס רשת לא מספיק חזק, וגם זה אני אוכל לגלות. אני יוצא לפרודקשן, אני רוצה לדעת כמה שרתים אני צריך בשביל 100 יוזרים, כמה שרתים ווב אני צריך, וגם כאן אני אוכל לקבל תשובה.
השקף הזה הוא לא סתם קיים פה, ולמעשה נדמה שכאילו הוא חוזר על אותם דברים שדיברנו קודם, אבל זה לא. מה שאני רוצה להגיד כאן, שככל שתיכנסו לבדיקות ומוסעים בשלב מוקדם של הפיתוח, ככה תחסכו עלויות.
גם בשלב של הפלנינג והדיזיין, שאתם רק מתכננים את האפליקציה שלכם, אתם צריכים לדעת מה השרת שנדרש לכמות היוזרים. עברנו את השלב הזה, אנחנו עכשיו בשלב הפיתוח.
פיתחתי איזשהו מודל. אני רוצה לדעת אם הזמן תגובה שהמודול שלי מחזיר הוא זמן לפי הדרישות. אז גם כאן אני יכול להפעיל לואוד ראנר או כלי לבדיקות עומסים אחר וגם לענות לשאלה הזאת.
אני בשלב של להוציא את המערכת שלי לפרודקשן, בשלב ה-Deployment. האם המערכת שלי מסוגלת לצאת לשם? האם היא מספיק אמינה? וגם זה ייתן לנו לואוד ראנר. אני בשלב של הפרודקשן, המערכת כבר אצל הלקוח, והלקוח מרים לי טלפון, אומר, הלו, מקסים, מה קורה?
אני עכשיו בבעיה, המערכת פתאום לא מגיבה טוב, מה קורה? ואם יש לי לואוד ראנר שם, אני גם יכול להתקין אותו אצל הלקוח ולראות מה הבעיה.
אני יכול גם לדמות מצב דומה לסושי סימולציה אצלי באתר, וגם להגיע לתשובות ולדעת למה יש ירידה. אוקיי, עניתי על השאלה הזאת, אני בדקתי הכל אצלי, גיליתי שיש לי בעיה, אני חוזר, אני חוזר על אותו תהליך, אני עוד הפעם מפתח מודול, אני משפר את המודול, ואני עוד הפעם שואל אותם שאלות.
וכך עד שהמערכת לא מוכנה לשחרור. אוקיי. בעבר, ולא בעבר רחוק כל כך, גם בעולם הלואוד ראנר היו בדיקות עומסים, תמיד היו בדיקות עומסים.
לפני הלואוד ראנר, אחרי, באמצע. מה עשו לפני? עשו את זה בצורה ידנית. יש לזה גם יתרונות, זה לא רק יתרונות. אולי אתם צוחקים, אומרים איך אפשר לעשות את זה בצורה ידנית, אבל כן.
ולא מעט ארגונים עובדים עדיין בשיטה כזאת. מביאים 80 בודקים טסטרים רגילים, מביאים מישהו מאוד מאוד חזק לארגן את האנשים האלה, לאו דווקא מומחה לעומסים, אלא מארגן טוב, קוראים לו קואורדינטור, מתקינים על כל עמדה אצל כל טסטר את האפליקציה ואז הקואורדינטור אומר, אוקיי, עכשיו אנחנו
לוחצים על הכפתור הזה. כולם לוחצים בו זמנית ומבצעים אותה פעולה. מישהו יושב, מסתכל מה זמן התגובה באפליקציה. אותם טסטרים יושבים עם סטופר, לוחצים, מסתכלים מה קורה.
מצב אפשרי, עושים אותו. אפילו בארגון שאני נמצא בו היום עושים אותו ויש לזה כמה יתרונות. אחד, לא צריך להחזיק חומרה נוספת בבדיקות.
אפשר ביום שישי, כשאף אחד לא עובד, לנתק את כל המשתמשים ולעשות את זה על המערכת האמיתית. מה החסרונות? נורא נורא נורא יקר.
להביא עכשיו 80 אנשים שיעשו רק את הפעולה הטיפשית הזאת, בלתי אפשרי. גם השאלה איך מסנכרנים בין כולם, איך אני עכשיו אומר לכולם תלחצו בדיוק בשנייה הזאת, אולי מישהו התעכב, אולי מישהו בדיוק שתה מים, אי אפשר לדעת.
אוקיי? ואז בא הפתרון של הלואוד ראנר. לואוד ראנר היה מהחלוצים בתחום הזה, יש לו לא מעט מתחרים כמו ריישיונל מבית IBM, יש ובלואוד לעולם וב, מצב לא רע, אבל לואוד ראנר הוא למעשה המרסדס מכל הכלים האלה.
הוא עולה כסף, הוא לא זול, אבל הוא נותן את המענה. לא כולם צריכים, לא כולם צריכים לצעוד במרסדס. לפעמים אני יכול להסתפק בפציעת פונטו כי אני רוצה להיות זריז, אני לא רוצה להתבלט, אני לא רוצה להוציא הרבה כסף ואז אני אבחר גם מוצר יותר פשוט.
אבל אם אני רוצה לקבל את הבאף, אני אלך על הלואוד ראנר. מה לואוד ראנר מספק לי? הוא מספק לי אותו קואורדינטור, אתם רואים את האיש בצד שמאל?
הוא אותו קואורדינטור, רק קוראים לו עכשיו קונטרולר כי הוא שולט