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

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

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

בדיקה ידנית חיונית מכיוון שאחת מהן בדיקות תוכנה היסודות הם '100% אוטומציה לא אפשרית'.

דפוס עיצוב מפעל

למה אנחנו צריכים בדיקה ידנית

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

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

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

סוגי בדיקות ידניות

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

• בדיקת קופסה לבנה
• בדיקת קופסה שחורה
• בדיקת תיבה אפורה

בדיקת קופסה לבנה

בדיקת הקופסה הלבנה נעשית על ידי מפתחים, שם הם בודקים כל שורה בקוד לפני שנותנים אותו למהנדס הבדיקה. מכיוון שהקוד גלוי למפתח במהלך הבדיקה, לכן הוא ידוע גם בשם White box testing.

למידע נוסף על בדיקת קופסה לבנה, עיין בקישור הבא:

https://www.javatpoint.com/white-box-testing

בדיקת קופסה שחורה

בדיקת הקופסה השחורה נעשית על ידי Test Engineer, שם הם יכולים לבדוק את הפונקציונליות של אפליקציה או התוכנה בהתאם לצרכי הלקוח/הלקוח. בכך, הקוד אינו גלוי בעת ביצוע הבדיקה; לכן זה ידוע בתור בדיקת קופסה שחורה.

למידע נוסף על בדיקת קופסה שחורה, עיין בקישור הבא:

https://www.javatpoint.com/black-box-testing

בדיקת תיבה אפורה

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

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

https://www.javatpoint.com/grey-box-testing

כיצד לבצע בדיקה ידנית

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

תהליך בניית תוכנה

• לאחר איסוף הדרישה, היא תספק לשני צוותי הפיתוח והבדיקות השונים.
• לאחר קבלת הדרישה, המפתח המודאג יתחיל לכתוב את הקוד.
• ובינתיים, מהנדס הבדיקה מבין את הדרישה ומכין את המסמכים הנדרשים, עד עכשיו היזם רשאי להשלים את הקוד ולאחסן ב- כלי בקרה בגרסה .
• לאחר מכן, הקוד משתנה בממשק המשתמש, והשינויים הללו מטופלים על ידי צוות אחד נפרד, המכונה לבנות צוות .
• צוות הבנייה הזה ייקח את הקוד ויתחיל קומפילציה ודחיסה של הקוד בעזרת כלי בנייה. ברגע שקיבלנו פלט כלשהו, ​​הפלט נכנס לקובץ ה-zip, המכונה לִבנוֹת (אפליקציה או תוכנה). לכל Build יהיה מספר ייחודי כמו (B001, B002).
• אז ה-Build הספציפי הזה יותקן בשרת הבדיקה. לאחר מכן, מהנדס הבדיקה ייגש לשרת הבדיקה הזה בעזרת כתובת ה-Test ויתחיל לבדוק את האפליקציה.
• אם מהנדס הבדיקה מצא באג כלשהו, ​​הוא/היא ידווחו למפתח הנוגע בדבר.
• לאחר מכן המפתח ישחזר את הבאג בשרת הבדיקה ויתקן את הבאג ושוב יאחסן את הקוד בכלי Control version, והוא יתקין את הקובץ המעודכן החדש ויסיר את הקובץ הישן; התהליך הזה נמשך עד שנקבל את ה-Build היציב.
• ברגע שקיבלנו את ה-Build היציב, הוא יימסר ללקוח.

הערה 1

• ברגע שנאסוף את הקובץ מכלי גרסת Control, נשתמש בכלי הבנייה כדי להרכיב את הקוד משפה ברמה גבוהה לשפה ברמת מכונה. לאחר הקומפילציה, אם גודל הקובץ יגדל, אז נדחס את הקובץ הספציפי הזה ונזרוק לשרת הבדיקה.
• תהליך זה נעשה על ידי בנה צוות , מפתח (אם צוות בנייה אינו שם, מפתח יכול לעשות זאת) או מוביל מבחן (אם צוות הבנייה מטפל ישירות ב-zip ומתקין את האפליקציה בשרת הבדיקה ומודיע למהנדס הבדיקה).
• בדרך כלל, אנחנו לא יכולים לקבל Build חדש עבור כל באג; אחרת, רוב הזמן יתבזבז רק ביצירת הבנייה.

פתק 2

בנה צוות

התפקיד העיקרי של צוות הבנייה הוא ליצור את האפליקציה או את ה-Build ולהמיר את השפה ברמה גבוהה לשפה ברמה נמוכה.

לִבנוֹת

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

כלי גרסת שליטה

זוהי תוכנה או יישום המשמשים למטרה הבאה:

קו תחתון

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

דוגמה לתהליך בנייה

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

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

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

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

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

פתק 3

מחזור מבחן

מחזור הבדיקה הוא משך הזמן שניתן למהנדס הבדיקה כדי לבדוק כל Build.

הבדלים בין שני המבנה

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

באיזו תדירות קיבלנו את ה-Build החדש

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

כמה מבנים אנחנו מקבלים

אם ניקח בחשבון שנה אחת של פרויקט כלשהו, ​​קיבלנו 22-26 בנייה.

כשאנחנו מקבלים את תיקוני הבאגים

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

היתרונות של בדיקה ידנית

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

חסרונות של בדיקה ידנית

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

כלי בדיקה ידניים

בבדיקות ידניות, סוגים שונים של בדיקות כמו יחידה, אינטגרציה, אבטחה, ביצועים ומעקב אחר באגים, יש לנו כלים שונים כגון Jira, Bugzilla, Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube וכו'. שׁוּק. חלק מהכלים הם בקוד פתוח וחלקם מסחריים.

למידע נוסף על כלי בדיקה, עיין בקישור הבא:

https://www.javatpoint.com/software-testing-tools

בואו נבין אותם אחד אחד:

LoadRunner

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

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

תכונות של LoadRunner

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

פרי הדר

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

כדי לבצע את בדיקת מקרה השימוש מקצה לקצה, הדר תומך במספר פרוטוקולי HTTP, JMS ו-SOAP.

מאפיינים של הדרים

להלן כמה מהתכונות החשובות של כלי הדר:

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

ZAP

ZAP הוא סורק אבטחה של יישומי אינטרנט בקוד פתוח. זה מייצג Zed Attack Proxy . בדיוק כמו כמה כלים אחרים, זה גם כתוב ב- שפת תכנות JAVA . זה הכי יעיל פתח את פרויקטי אבטחת יישומי אינטרנט [OWASP].

תכונות של ZAP

ההבדל בין אריה לנמר

• הוא תומך במערכות הפעלה רבות כמו Windows, Linux, OS X.
• יש לו ארכיטקטורה מבוססת תוספים.
• הוא מכיל שוק מקוון המאפשר לנו להוסיף תכונות חדשות או מעודכנות.
• לוח הבקרה של ה-GUI של ZAP קל לשימוש.

נְזִירָה

NUnit הוא אחד מכלי בדיקת היחידות הנפוצים ביותר. זהו כלי קוד פתוח ונגזר בעיקר מה- JUnit .

זה נכתב לגמרי ב- שפת תכנות C# ומתאים לכולם שפות .Net .

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

יכולות הקשורות לרפלקציה. מאפיינים מותאמים אישית אחרים.

מאפיינים של NUnit

• זה מאפשר את הקביעות כשיטה סטטית של מחלקת היתרון.
• זה מקיים את הבדיקות מונעות הנתונים.
• הוא תומך במספר פלטפורמות, כמו .NET core Xamarin mobile, Silverlight ו-framework יעיל.
• היכולת של NUnit עוזרת לנו לבצע את הבדיקות בו זמנית.
• הוא משתמש ב-console runner כדי לטעון ולבצע את הבדיקות.

JIRA

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

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

תכונות של JIRA

גדלי גופן בלטקס

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

כדי לקבל את המידע המלא על כלי Jira, עיין בקישור הבא: https://www.javatpoint.com/jira-tutorial.

SonarQube

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

הוא כתוב במלואו בשפת התכנות JAVA. הוא מציע הערכה ואינטגרציה אוטומטיים לחלוטין עם Ant, Maven, Gradle, MSBuild וכלי אינטגרציה מתמידים. ל- SonarQube יש את היכולת לתעד היסטוריית מדדים ונותנת את גרף האבולוציה.

תכונות של Sonarqube

להלן כמה מהתכונות המשמעותיות של הכלי SonarQube:

• הוא תומך במספר שפות תכנות כמו C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL וכו'.
• תחת רישיון GNU Lesser General Public License, Sonarqube זמין באופן חופשי.
• SonarQube קשורה לכמה כלים חיצוניים חשובים כמו GitHub, Active Directory, LDAP ואחרים.
• SonarQube התמזגה עם סביבות הפיתוח Visual Studio, Eclipse ו-IntelliJ IDEA בשל ה SonarLint תוספים.

JMeter

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

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

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

תכונות של JMeter

להלן כמה מהמאפיינים החיוניים של JMeter:

• זה בלתי תלוי בפלטפורמה, שמקבל כמו JVM Windows, Mac ולינוקס וכו'.
• הוא תומך ב-GUI ידידותי למשתמש, שהוא אינטראקטיבי ופשוט.
• ניתן להרחבה להפליא לטעון את מבחן הביצועים במספר סוגים של שרתים.

למידע נוסף על JMeter, עיין בקישור הבא:

https://www.javatpoint.com/jmeter-tutorial.

עם באגז

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

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

Bugzilla הוא כלי קוד פתוח המסייע ללקוח וללקוח לעקוב אחר הליקויים. Bugzilla נחשבת גם לכלי ניהול בדיקות מכיוון שבכך אנו יכולים לקשר בקלות כלים אחרים לניהול מקרי בדיקה כגון ALM, Quality Centre וכו'.

תכונות של Bugzilla

ל-Bugzilla יש כמה תכונות נוספות שעוזרות לנו לדווח על הבאג בקלות:

• הוא תומך במערכות הפעלה שונות כמו Windows, Linux ו-Mac.
• בעזרת Bugzilla, נוכל לרשום באג במספר פורמטים.
• העדפות המשתמש יכולות למדוד הודעות דוא'ל.
• ל-Bugzilla יכולות חיפוש מתקדמות.

גְמָל שְׁלֹמֹה

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

תכונות של גמל שלמה

כמה מהתכונות הסטנדרטיות של הכלי המסוים הן כדלקמן:

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

לקבלת פרטים נוספים על כלי מעקב אחר באגים, עיין בקישור הבא: https://www.javatpoint.com/defect-or-bug-tracking-tool .

טסי

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

מערך הוספת אלמנטים java

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

Tessy מכיל שלוש פונקציות עיקריות, שהן כדלקמן:

• עורך ממשק בדיקה (TIE)
• עורך נתוני בדיקה (TDE)
• סביבת עבודה.

תכונות של TESSY

התכונות הסטנדרטיות של TESSY הן כדלקמן:

• הוא מייצר את דוח הבדיקה עבור תוצאות ביצוע הבדיקה.
• הוא תומך בשפות תכנות שונות כגון C ו-C++.
• Tessy משמש להערכת הממשק של הפונקציה ומתאר את המשתנה המשמש את אותה פונקציה.

למידע נוסף על כלי בדיקת אינטגרציה, עיין בקישור הבא: https://www.javatpoint.com/integration-testing-tools .

סקירה כללית

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

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

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

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

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