כלי לביצוע בדיקות

1-מבוא: כיום השימוש בכלים הפך חיוני כדי להפוך לאוטומטיים תהליכים רבים. בדיקת זרימת במיוחד הוא זרם חשוב מאוד בפיתוח תוכנה. החקירה של השימוש בכלים הפכה הכרחית כדי לשפר את האיכות והיעילות של זרם זה. במהלך החקירה יהיה מכירים בחשיבות של הכלי לשימוש, כמו גם הפעולה שלו, דרך דוגמאות מן החיים האמיתיים של בדיקות שבוצעו על מודול. 2 – כלי JMeter JMeter כלי חינם, הוא גם כלי Java המאפשר ביצועים בדיקה ובדיקה תפקודית על יישומי אינטרנט. זהו כלי של נטל לביצוע סימולציות על כל משאב תוכנה. JMeter כלי Java בפרוייקט בג'קרטה, המאפשר לבצע בדיקות ביצועים, בדיקות פונקציונליות של יישומי האינטרנט ומסדי. קיימים מספר כלי בדיקות בחינם ותשלום (LoadRunner), אך JMeter בולטת עבור הרב-גוניות שלה, יציבות, ועל היותו של שימוש ללא תשלום.

JMeter מאפשר אינטרנט קלאסי בדיקות, אלא גם מאפשר לך לבצע בדיקת FTP, JDBC, JNDI, LDAP, סבון/XML-RPC ושירות האינטרנט (בטא). בנוסף, מאפשר לך להפעיל בדיקות מבוזרת בין מחשבים שונים לביצוע בדיקות ביצועים. JMeter מראה את התוצאות של בדיקות על מגוון רחב של דוחות וגרפים. גם מקלה על זיהוי מהיר של צווארי בקבוק הקיימת עקב זמן תגובה מוגזמת. כל הכלים הללו יכול לשמש כדי להפוך את יעילות תחת עומס אינטנסיבית בדיקות, עם זאת ישנם כמה בעלי יתרונות ביחס לאחרים, כך הם אופטימליים יותר לשימוש במהלך הבדיקות המדובר. ביישום, חשוב להעסיק קצת זמן להכין את יעילות תחת עומס, בדיקות מאמץ, לפני שנשלחה. הזמן בילה משוחזר בהרבה, שכן תופעות הלוואי האפשריות זוהו יכול לבדוק אם פונקציונליות חדשה זו תומכת בהכמות לכמות משתמשים שצוינו בדרישות.

אלה הם כמה מטרות ספציפיות שניתן: ודא כי המערכת מכוון כדי לתמוך את עומס העבודה האפשריים המרבי באמצעות תשתית הנוכחי. ודא כי, לפני עומס מסוים, העמודים אשר ניתן לגשת להגיב פחות מרווח זמן שצוין על-ידי הקבוצה של מעצבים. לקבוע את הזמן הממוצע של התגובה שיקבלו על-ידי המשתמש. קביעת המספר המרבי של משתמשים במקביל לכל מי יכול לגשת ספציפי בדף, או טרנזקציות בשניה כי היישום הוא מסוגל לתמוך. זיהוי דפים מגיבים לאט יותר, הדרך המהירה. עוד מידע על עו"ד אמסלם ניתן למצוא באינטרנט. לזהות את הדפים עם סטיית תקן גבוהה יותר בזמני תגובה שלהם. יעילות תחת בדיקות עומס אינטנסיבית לפעול באופן אידיאלי על סביבה יציבה, הדומה ככל האפשר על סביבת הייצור הסופי, בעקבות לעיל הוזכרו מטרות, תמיד ניתן להוסיף משתמשים אחרים בהתאם הריבית נרדף. היתרונות של הכלי JMeter כלים חינמיים, זהו השלם ביותר שימושיות עבור הסוג של מבחן המדובר. זהו כלי לביצוע בדיקות תפקודי, אך משמש גם כדי לבצע בדיקות רגרסיה על יישומי אינטרנט, משהו כי לפעמים הוא באמת מסובך, בהתאם ליישום, אבל זה הכרחי כמעט תחזוקה, האבולוציה של יישומים, אם ברצונך להבטיח רמה קיבולת במשלוח המוצר. יש לו מבנה עץ זה נותן לך כוח אדיר המאפשר לו להיות הדמיון של מי להשתמש ערכת מגבלות בעת עיצוב תוכנית הבדיקה. והוא מציע מספר גדול של משתנים כדי לאסוף את התוצאות שהושגו, ומאפשר את שאר הכלים חינם, מה לעשות ניתוח ממצה בדיקות. 3 ביצוע של בדיקת ביצועים לרשומה של פעילויות יומיות (RAD) מודלים של מדי יום פעילות (RAD) מידע ניהול מערכת טפסים חלק עכשיו ערכת יישומים שפותחו עבור מערכת מידע בריאות (SISalud) האזור תימטיים 7 הפקולטה APS. בתוך דרישות שאינם פונקציונליים המפקחים על הפיתוח של היישום, יש למשל, מספר מסופים, המספר הצפוי של המחוברים בו-זמנית משתמשים, מספר הטרנזקציות לשנייה חייב לעמוד בפני המערכת, וכו '. כל דרישות אלה חייב להיות מדיד. זה צריך להיות שצוינו אחוזים (%) הקשורות לזמן שלהם. RNF 1: המערכת לתמוך חיבור בו-זמניות של משתמשים למעלה מ-60,000. 2 RNF: המערכת לתמוך תגובה פחות או שווה לזמן 30 שניות. RNF 3: במערכת חייב לתמוך תגובות סבון לא יעלה על 50 Kbyte בזמן תגובה למשתמש. הבדיקה בוצעה באחת מאפשרויות הרישום של פעילויות יומיות, משלוח המשמר, שבו האובייקט של מקרי מבחן שנראה לפי קטגוריה של דו ח חולים. מקרה השימוש מתחילה כאשר הצוות של יחידת בריאות מעוניינת מספר המקרים רואים אינדיקטורים של בריאות בתאריך מסוים. תיאור טקסטואלי. להשיג את המקרים דוח צפו לפי קטגוריה של שחקנים חולים: תיאור קצר: התניות: להתנהג: אנשי יחידת בריאות מקרה השימוש מתחיל כאשר הצוות של יחידת בריאות מעוניינת מספר המקרים לראות לפי קטגוריה של חולים בתאריך שצוין. המערכת מחזירה את הנתונים לפי המקרים שנראה על-ידי בקטגוריות הקיימות עד לתאריך זה. טבלה 1.1 תיאור מילולי לקבל דוח מקרים ראיתי לפי קטגוריה של חולים. מבחן 1: מקרי מבחן לראות לפי קטגוריה של מקרה חולים. בזמן האחרון אני מתחיל מאוד להעריך את השר אורי אריאל. שם הפרוייקט כדי למדוד: יומן פעילות יומית. שם מקרה מבחן: מקרים ראיתי לפי קטגוריה של חולים. השתמש כדי למדוד את שם האירוע: מקרים ראיתי לפי קטגוריה של חולים. מספר בדיקות: 1 רמה של הקבוצה בשיתוף פעולה או משתמש: 5 מחזורי עבודה: אפשרות 10 כדי לנסות: כדי לבדוק אפשרות 1 של מודול יומן יומי של פעילות. (להשיג את המקרים דוח לראות לפי קטגוריה של חולים). תוצאות של מבחן 1: זמן התגובה המרבית של ה אפשרות להשיג המקרים דוח לראות לפי קטגוריה של חולים: תוצאות שניה 2.1 ממוצע זמן: שגיאה % 0.4 שניה: 50% באפשרות מוכחת. תשובות בבתים: 9.2 kb/שניה טבלה 1.2 תוצאות של מבחן 1. מבחן 2: מקרי מבחן לראות לפי קטגוריה של מקרה חולים. שם הפרוייקט כדי למדוד: יומן פעילות יומית. שם מקרה מבחן: מקרים ראיתי לפי קטגוריה של חולים. השתמש כדי למדוד את שם האירוע: מקרים ראיתי לפי קטגוריה של חולים. מספר בדיקות: 2 רמת הקבוצה בשיתוף פעולה או משתמש: 10 מחזורים של עבודה: אפשרות 10 כדי לנסות: כדי לבדוק אפשרות 1 של מודול יומן יומי של פעילות. (להשיג את המקרים דוח לראות לפי קטגוריה של חולים). התוצאות המתקבלות מבחן 2: זמן התגובה המירבי של האפשרות לקבל דוח מקרים ראיתי לפי קטגוריה של חולים: תוצאות שניה 4.2 ממוצע זמן: שגיאה % 0.6 שניה: 50% באפשרות מוכחת. תשובות בבתים: 9.2 kb/שניה טבלת תוצאות 1.3 מבחן 2. מבחן 3: מקרי מבחן לראות לפי קטגוריה של מקרה חולים. שם הפרוייקט כדי למדוד: יומן פעילות יומית. שם מקרה מבחן: מקרים ראיתי לפי קטגוריה של חולים. השתמש כדי למדוד את שם האירוע: מקרים ראיתי לפי קטגוריה של חולים. מספר בדיקות: 2 רמת הקבוצה בשיתוף פעולה או משתמש: 15 מחזורים של עבודה: אפשרות 10 כדי לנסות: כדי לבדוק אפשרות 1 של מודול יומן יומי של פעילות. (להשיג את המקרים דוח לראות לפי קטגוריה של חולים). תוצאות של מבחן 3: זמן התגובה המירבי של האפשרות לקבל דוח מקרים ראיתי לפי קטגוריה של חולים: שניה 5.1 זמן ממוצע של תוצאות: שגיאה % 0.9 שניה: 50% באפשרות מוכחת. תשובות בבתים: טבלת התוצאות 1.4 של מבחן 9.2 kb/שניה 3. הבדיקה בוצעה באמצעות הדמיית עומס של המשתמשים 5, 10 ו-15, המבקש דיווחים על מקרים ראיתי לפי קטגוריה של חולים של הרשומה של פעילויות יומיות. בדיקה עם יותר מ 15 משתמשים לא יכול להיות לבצע בתנאים אלו, קרי ב מחשב יחיד, שכן היא מחייבת יישום מחשב אחד או יותר. מה שהופך אותו במחשב אחד, המספר המרבי של משתמשים שבאפשרותם הוא 15, אחוז ניצול CPU חייב להיות קטן 90%, אם הבדיקה צורכים יותר כי אחוזים, התוצאות הן שקר, הם לא האמיתיים. מוגדרת פעם אחת (מבחן לתכנן את החוט קבוצה) כדי לראות את המאפיינים של קבוצת המשתמשים שברצונך לדמות את העומס שנוצר על-ידי היישום, יוצר של בקשת המחדל (החוט קבוצה Config רכיב לבקש המחדל), צוינו פרמטרים נדרשים כשרת ip מספר לדוגמה, יציאה ועוד. שרת Proxy (ללא לספסל – מבחן רכיבי שרת Proxy), אשר מציין היכן שהם יהיו דוגמאות מאוחסנת לאחר מכן להוסיף. הוא מקבל להפעיל את הכלי, והיא מתחילה לעבוד ביישום, צעד אחר צעד כדי להשיג את המקרים דוח לראות לפי קטגוריה של חולים, כדי לבקר בדף החדש של היישום, הדוגמאות להשיג מדף זה, הוסיף בבקר העסקה (הוספת האב בקר עסקת בקר לוגי). פעם אחת הניווט של היישום, הוספה של שני דוחות אחד כדי לראות את זמני התגובה ואחרת כדי להיות מסוגל להציג שגיאות נמצאים בדיקה זו (קבוצת חוט להוסיף דוח סיכום מאזין ועץ תוצאות תצוגה בהתאמה). דו ח זה נותן את זמן התגובה של היישום תחת העומס של משתמשים 15, היא כי התגובה הממוצע של זמן היישום היא 2 שניות, ולוקח לי שהזמן המינימלי הוא השני 0.047 הזמן המרבי היה השני 5.1. אחוז השגיאה היה 50% אשר בניתוח של ההפניה reportea נעשה טעויות כאלה. החלונית מציגה גם שהביצועים של היישום במהלך הניווט היה שניות 14.9 לתגובה של 134 KB/שניה. עם דוח זה (תצוגת תוצאות עץ) יכול לקבל באגים נמצאה על-ידי כל עמוד ביקר, לדוגמה בדף הראשי של ראד, נמצאו שתי שגיאות (/general/style.css) / general/allstyles_aps.css) בו נכתב הדוח אינו קבצים אלה, כדי לבקש בדף זה קיים עיכוב, כדי להפוך את הבקשה עבור קבצים אלה שאינם קיימים. 3 מסקנות יש היא הצעה כלים כמו JMeter עבור בדיקות מאמץ. בנוסף מסמך ספציפי יותר על השימוש של כלי כזה. בעזרת כלי זה ניתן לנתח את הביצועים של יישום, בתנאים מסוימים כלומר מאפשר לנתח כיצד הוא מגיב יישום תחת הפעולה של כמות מסוימת של המשתמשים המחוברים אליו. רמירז, פונס Yilen. 2007 נוהל בדיקות יעילות תחת עומס אינטנסיבי ביישומים בריאות של האינטרנט. העיר Habanaa: האיגוד הבינלאומי לאופניים, 2007. 1.Autores, קולקטיבית של. 2005 אוסמוזה לטיני. [באינטרנט] ב- 20 / 10 / 05. [ציטט: אפריל 12, 2008.] :// 2.Autores, קולקטיבית של. 1999 אפאצ'י Jakarta הפרוייקט. : / / jakarta.apache.org. 1999 [און]. [ציטט: 20 / 04/08.] : //jakarta.apache.org/jmeter/ 3. cedeno גונזלס, פיליפ פביאן, Carralero Mulet, ראול. הצעה 2007 לבחון את תהליך המבוסס על-RUP לניהול פרוייקטים. מדעים האוניברסיטה של אינפורמטיקה. העיר Habanaa: מאוקלנד, שלמד, 2007. 4.Autores, קולקטיבית של. פתרונות אינפורמטיקה 1998. 1998 [און]. [ציטט: אפריל 25, 2008.] :// 5.Aguilar, חוזה אלפונסו. 2007 MYGNET. 8 [און] בפברואר 2007. [ציטט: 10 פברואר 2008.]