tomron87/hebrew-wikipedia-sentences-corpus huggingface dataset:
קיימים כלים אוטומטיים רבים לבדיקות איכות תוכנה ואיתור תקלות ("באגים") אך מעט מאוד כלים הבודקים אבטחה של תוכנה.
ספריות אלה מכילות אוסף של מתקפות ידועות אשר ניתן להריץ בצורה אוטומטית על המערכת.
היתרון של השיטה הוא בכך שהיא מונעת הישנות של מתקפות מוכרות אשר התרחשו בעבר ויש להם פתרון ידוע.
בדיקות אלו מבוססות על העיקרון שמתכנתים נוטים לחזור על אותן טעויות בעת כתיבת קוד.
השיטה לא מגיבה היטב לסוגים חדשים של מתקפות מכיוון שספריות כאלו מתעדכנות בתדירות נמוכה בהרבה מהקצב בו מתקפות חדשות מתגלות.
OWASP הוא פרויקט פיתוח תוכנה אשר עוסק בהיבטי אבטחת מידע.
הקוד של תוכנה הוא פתוח (Open-source software).
קהילת OWASP כוללת חברות, מוסדות חינוך ונציגים מכל העולם.
הקהילה עוסקת בחיבור מאמרים, פיתוח מתודולוגיות וכלים אשר נגישים לכלל האוכלוסייה.
רשמית הקהילה קיימת מאז יוני 2011 והיא רשומה כארגון ללא מטרות רווח באירופה.
ישנן פרצת אבטחה רבות, רובן המוחלט עדיין אינן ידועות.
לכן בדיקת עמידות תוכנה לכל פרצה שקיימת היא משימה הדורשת משאבים עצומים.
הזרקת SQL - הכנסת שאילתת SQL זדונית באפליקציית אינטרנט לשדה קלט (בדרך כלל שדה טקסט חופשי) במקום נתונים המבוקשים.
מטרת השאילתא היא לגרום נזק למסד נתונים של השרת ו/או לגשת למידע אשר משתמש פשוט לא מורשה אליו.
קיימים הרבה קלטים זדוניים אפשריים אשר ממלאים את המטרה, מה שמהווה קושי ניכר בבדיקות אבטחת תוכנה.
XSS - הכנסת קוד זדוני באפליקציית אינטרנט.
בדרך כלל קוד זה כתוב ב-JavaScript.
שדות להכנסת טקסט חופשי הן המקור העיקרי למימוש מתקפה זו.
כל גולש אשר מגיע לדף אינטרנט וקורא טקסט לא מודע לסקריפטים של JavaScript שהדפדפן מריץ.
גם כאן קיימים קטעי קוד אפשריים רבים שניתן להכניס לגוף של הודעת טקסט שגרתית.
התקפת אדם באמצע - מתקפה נפוצה בעיקר ברשתות אל-חוטיות.
האקר או קראקר מתחבר לשרת או נתב ברשת אינטרנט מקומית ומתחזה עליו.
המשתמש הפשוט אשר רוצה להתחבר לאותו שרת/נתב, מקבל אשליה שהוא התחבר ישירות לנתב אך בפועל הוא מחובר למחשב של האקר.
כך נוצר מצב בו האקר מאזין לכל התקשורת העוברת בין נתב למשתמש הפשוט.
כדי לנסות לזהות מתקפה כזו ניתן למדוד זמן תגובה של המשתמש, אך מאוד קשה להגדיר מהו זמן תגובה סביר שמבטיח כי אין "אדם באמצע".
על מנת למנוע אותה יש להיעזר במנגנוני ההצפנה.
בדיקות לתוכנה בענן היא פרדיגמה בתחום בדיקות תוכנה שנוצרה בעקבות השימוש הגובר במחשוב ענן, פיתוח אפליקציות חדשות לענן, והצורך לבדוק את תקינותן.
בעקבות העלייה הגוברת בשימוש במחשוב ענן בתחום התוכנה על ידי שימוש בתוכנה כשירות (SaaS) ופלטפורמה כשירות (PaaS),
נוצר צורך לבצע התאמות לבדיקות התוכנה הרגילות כך שיתאימו למאפיינים המיוחדים של תוכנות בענן.
בדיקות התוכנה המסורתיות אינן מספיקות על מנת לוודא תקינות של תוכנה בסביבת הענן ומאחר והענן הוא סביבה משותפת למספר תוכנות במקביל והעבודה מולו מתבצעת ב-HTTP ישנה חשיבות רבה לזמינות השירות.
סוגי בדיקות תוכנה בסביבת הענן
קיימים ארבעה סוגי בדיקות תוכנה עיקריות בתחום מחשוב הענן:
בדיקות של תוכנה בענן: בדיקה המשמשת על מנת לוודא את איכות התוכנה של תוכנה כשירות בהתבסס על הדרישות הפונקציונליות והלא-פונקציונליות שהוגדרו במסמך הדרישות של השירות.
בדיקה של הענן: בדיקה המשמשת על מנת לוודא את איכות שירות הענן מנקודת מבט חיצונית בהתבסס על פירוט היכולות ועל התכונות של הענן.
בדיקה בתוך הענן: בדיקה המשמשת על מנת לבדוק את איכות שירות הענן מנקודת מבט פנימית.
בדיקה זו מתבצעת על ידי ספק הענן ומתבססת על התשתית הפיזית של הענן.
בדיקה בין עננים: הבדיקה משמשת על מנת לבדוק אפליקציות מבוססות ענן על פני שירותי ענן שונים.
כולל בדיקה של שירותי ענן פרטיים, ציבוריים או משולבים.
הסכם רמת שירות (SLA) במחשוב ענן, כל העננים, תוכנות כשירות ותוכנות אחרות, מספקים בדרך כלל שירותים שונים למשתמשי הקצה והלקוחות שלהם באמצעות הסכם רמת שרות מוגדר היטב הקובע זאת.
מודל תמחור ושרותי חשבון מאחר שתשלום לפי שימוש הוא אחד מהעקרונות היסודיים של מחשוב ענן, מודל התמחור והחשבון הופכים להיות חלק מנושא בדיקות התוכנה.
כמות נתונים גדולה ותנועה רבה יישום והדמיה של כמויות גדולות של גישות משתמשים למערכת ובדיקה של עומסים בחיבור חשובים מאוד בבדיקות תוכנה על מנת לבצע בדיקות תקינות ובדיקות ביצועים.
ריבוי דיירים (Multi-Tenants) אחת התכונות העיקריות של מחשוב ענן היא האפשרות של תוכנות שונות על אותו השרת לשתף משאבים בניהן.
בדיקות התוכנה נדרשות לוודא כי התוכנה לא נפגעת ולא פוגעת בתוכנות אחרות כתוצאה משיתוף המשאבים.
סילומיות רוב שרותי הענן מאפשרים להגדיל או להקטין באופן אוטומטי את כמות השרתים המשמשים את האפליקציה בהתאם לעומס על האפליקציה בנקודת זמן.
מחשוב ענן מציב מספר אתגרים בתחום אבטחת מידע עליהם יש לתת את הדעת בבדיקות התוכנה:
כיצד ניתן לוודא שהתוכנה מאובטחת בתוך תשתית ענן של שירות צד שלישי?
אילו מודלי-בדיקות, בדיקות-התאמה וטכניקות-בדיקה אחרות קיימם על מנת לוודא אבטחה מלאה לאורך כל הדרך בין האפליקציה, שירות הענן והלקוח?
כיצד אנחנו יכולים לוודא פרטיות בתשתית מבוססת ענן?
בתוכנה רגילה בדיקות נסיגה מתבצעות בדרך כלל לאחר ביצוע שינוי בקוד התוכנה או בסביבת ההרצה על מנת לוודא כי התוכנה ממשיכה לפעול באופן תקין.
אולם, במחשוב ענן קיימת יכולת של ריבוי דיירים המאפשרת לשתף משאבים בין התוכנות בסביבת הענן.
כתוצאה מכך, ייתכן כי שינוי בתוכנה מסוימת שנמצאת בענן ישפיע על תוכנה אחרת בענן.
בנוסף האחריות לביצוע עדכוני תוכנה מוטלת על ספק הענן, ולכן לא תמיד ידוע לנו מתי מתעדכנת גרסה של תוכנה תשתיתית בענן.
בעקבות זאת קיים קושי להגדיר מתי בדיוק יש להריץ את בדיקות הנסיגה, ולכן על בודקי התוכנה להחליט על דרך פעולה בנושא.
מודל בדיקה נדרשים מודלים גמישים שיוכלו לבדוק את התוכנה כאשר יש שינויים בעומס על התוכנה.
המודלים צריכים להתחשב בעלות ביצוע הבדיקה.
מודל אינטגרציה בדיקות אינטגרציה צריכות לכלול בדיקת זמינות של השרת ובדיקה של ה-API בין השרתים השונים.
בנוסף צריך לבדוק את האינטראקציה של תוכנה כשירות עם תוכנות ישנות.
בדיקות ופתרונות חדשניים בדיקות תקינות מתמשכות ובדיקות נסיגה, פיתוח של בדיקות אוטומטיות בין שירותי ענן.
שימוש בטכנולוגיות חדשות על מנת לבדוק את ההתאמה של שירות הענן לתוכנה.
בפיתוח תוכנה זריז מבצעים פיתוח איטרטיבי ואינקרמנטלי של תוכנה, המבוסס על רעיון של זריזות וגמישות הפיתוח.
יש חשיבות לזריזות וגמישות על פני ניתוח ואפיון מפורט.
הכלי אשר משמש לתיעוד הדרישות הוא סיפור משתמש.
כלי זה הוא מתומצת וקצר.
חוץ ממנו לא קיימים עוד כלים לתיעוד הדרישות.
בבדיקות תוכנה מבוססות פיתוח זריז נעזרים במידע של מקרי בדיקה עסקיים, הן בשביל בדיקות והן בשביל תמיכה בפיתוח כפיצוי על חוסר האפיון המפורט.
תפקיד הבודקים העיקרי הוא לקחת סיפור משתמש ולהפוך אותו לבדיקות על ידי יצירת מקרי בדיקה.
רוב הבדיקות האלו עוברות אוטומציה ונשמרות כדי לאפשר בדיקות רגרסיה.
בדיקות מסורתיות נעשות מול קוד שנכתב עם האפיון המפורט, אך הם לא קיימים בפיתוח זריז.
לא ניתן לערוך בדיקות מסורתיות בלי ספציפיקציות, ולכן עריכת בדיקות מסורתיות במתודולוגיה זריזה אינו אפשרי.
סיפורי משתמש הם קצרים, מועטים ולא תמיד מספיקים למפתחים כדי להבין את הדרישות הפונקציונליות במלואן.
בגלל שאין דרישות מפורטות, ואין גם ספציפיקציות בפיתוח תוכנה זריז מקרי הבדיקה העסקיים (הנקראים גם ספציפיקציות ניתנות להרצה), משמשים גם לבדיקות רגרסיה, וגם כעזרה לפיתוח.
בדיקות בשלבי פיתוח תוכנה זריז
Sprint 0: שלב שמבוצעת בו הכנה, וגם קונפיגורציה של סביבה ומסגרת הבדיקות.
Iteration: כולל מספר sprint אשר כוללים פונקציונליות שנחשבת ציון דרך לעסק.
sprint i: כל שלב נבחרים סיפור משתמש בעלי עדיפות גבוהה.
הבודקים והמפתחים עובדים במקביל וקיימת תקשורת ביניהם ובין המנתח העסקי.
release: נקודה שבה מסתיימת פיתוח האיטרציה והפונקציונליות הנדרשת.
UAT: כאן צריך לבדוק את התוצר של האיטרציה.
המשתמש או הלקוח צריך לבדוק את התוצר.
מקרי הבדיקה העסקיים עוזרים לאשר לו את טיב התוצר.
בדיקות ידניות יכולות להתבצע כהכנה לשלב זה.
בודק תוכנה: לוקח ובונה מקרי בדיקה עסקיים.
מכיוון שסיפורי משתמש הם בעלי אינפורמציה מועטה הוא עובד צמוד עם מנתח עסקי או מומחה דומיין, כדי ליצור מקרי בדיקה טובים.
הבודק צריך להגדיל ראש ולכסות כמה שיותר תסריטים.
את מקרי הבדיקה הוא כותב במסגרת עבודה של בדיקות.
מקרי בדיקה עסקיים: מקרי בדיקה המוסברים במונחים של תחום העסק הנקראים גם "ספציפיקציות ניתנות להרצה".
מסגרת העבודה של בדיקות מאפשרת להפוך את הבדיקות לאוטומטיות.
כדי לעשות זאת הבדיקות נכתבות בסביבת העבודה, ובאמצעות ה FIXTURES מחוברות עם קוד האפליקציה.
לבסוף ניתן להריץ את הבדיקות מול האפליקציה (Application Under Test), ולהחזיר תוצאות.
קיימות מספר מסגרות בדיקה כגון FIT, Fitness, Concordian ועוד.
Fixtures: נכתבים במסגרת הבדיקות מטרתם היא לקשר בין המקרי בדיקה העסקיים ל AUT.
בדרך כלל יש צורך בידע תכנותי כדי ליצור אותם, אך לא תמיד לבודק יש ידע כזה.
המפתח: בפיתוח תוכנה זריז אין דרישות פונקציונליות מפורטות, לכן המפתח נעזר במקרי בדיקות עסקיות.
הוא יוצר יחידת בדיקה בדומה ליצירתם בפיתוח מונחה בדיקות.
בדיקות אלו הופכות לאוטומטיות על ידי כלים כמו JUnit .
יש צורך במקרי בדיקה עסקיים שיכסו מספיק מקרים אפשריים כך שיהיה למפתחים אינפורמציה, וגם הבדיקה תהיה מספיק טובה.
בדרך זו ניתן לעשות אוטומציה למקרי בדיקה עסקיים ובדיקות יחידה אשר ביחד משמשים לבדיקות רגרסיה מתמשכות.
הרבה בדיקות מסובכות וקשות ליישום ולכן חלק מהבדיקות לא עוברות אוטומציה וחלקן מבוצעות ידנית בסוף sprint.
בדיקות תוכנה על מכשירים ניידים נועדו על מנת לוודא כי היישום או אתר האינטרנט מתאימים לשימוש במכשירים ניידים, כגון טלפונים חכמים ומחשבי לוח.
העולם נמצא במעבר מסביבה של מחשבים אישיים לסביבה של מכשירים ניידים.
לכן, כל ארגון הנותן שירות עסקי באמצעות מכשירים ניידים, וכן המפתחים עצמם צריכים לוודא את התאמת האתרים או היישומים למכשירים ניידים.
האתגר המרכזי העומד בפני הבודק הוא ריבוי מערכות ההפעלה והמכשירים הסלולריים הקיימים, המחייבים בדיקות תאימות לכל סביבה וסביבה.
כאשר מדובר ביישומים, על התוכנה להיות מותאמת למערכת הפעלה מסוימת ועל המתכנתים העובדים על פיתוח היישום מוטל כבר בשלבים הראשונים של הפיתוח לעבוד לפי הדרישות של מערכת ההפעלה שנבחרה.
לכן במקרים אלו אתגר הבדיקה מצומצם למכשירים השונים של מערכת ההפעלה עבורה פותח היישום.
אתרי אינטרנט ניתנים לפיתוח חוצה-פלטפורמות ולכן הבדיקות עבורם יהיו בכמה מערכות הפעלה.
בנוסף, מסכי מכשירים ניידים קטנים יותר ממסכי מחשב ולכן מחייבים ממשק נוח ובעיקר ניווט קל בין הדפים.
במכשירים ניידים בדרך כלל גם כוח המעבד, רוחב הפס והזיכרון קטנים יותר בהשוואה למחשבים אישיים.
כאמור, האתגר הגדול ביותר המייחד את עולם בדיקות המכשירים הניידים, הוא ההיצע הרב של המכשירים הקיימים ומערכות ההפעלה המותקנות עליהם.
מערכות ההפעלה הנפוצות ביותר הן:
אנדרואיד- מבית גוגל, מבוססת ליבת לינוקס
iOS- המותקנת על מכשירי אפל
BlackBerry OS- המותקנת על מכשירי RIM
ישנם כלים רבים בשוק, חלקם חינמיים וחלקם בתשלום, המאפשרים סימולציה של התוכנה או האתר במערכות ההפעלה השונות.
באמצעותם, ניתן לראות מבעוד מועד כיצד התוכנה או האתר פועלים ונראים במערכות הפעלה שונות, בחומרה שונה ובגודלי מסך שונים.
כמו כן, ישנן מעבדות המחזיקות מבחר רב של מכשירים בהן ניתן להשלים את בדיקת התאימות.
קיימים מאמרים ומדריכים רבים המתארים בניית ממשק משתמש עבור יישומים ואתרים המיועדים למחשבים אישיים, בעוד שהמחקר על תחום עיצוב הממשק למכשירים ניידים חדש יחסית ולוקה בחסר.
במאמרו של בן שניידרמן, "שמונה כללי הזהב לתכנון ממשק", מוצגים כללים בסיסיים לעיצוב ממשק למחשבים אישיים, אשר יכולים להוות נקודת פתיחה לכללים לעיצוב אתרים עבור מכשירים ניידים.
שמונת כללי הזהב לתכנון ממשק
אפשר למשתמשים מיומנים להשתמש בקיצורי דרך.
אפשר יכולת שליטה פנימית על ידי משתמשים מנוסים.
הצע מניעת טעויות וטיפול בבעיות פשוטות.
הפחת העומס על הזיכרון לטווח הקצר.
ארבעת הכללים הראשונים תקפים ללא שינויים גם עבור מכשירים ניידים: השימוש בקיצורי דרך הכרחי ביותר בעולם המכשירים הניידים, שכן המשתמש שואף לצמצם ככל האפשר את מספר הפעולות שהוא מבצע ולהגיע לתוצאה הרצויה בזמן המזערי.
כמו כן, קבלת משוב על הפעולות שהמשתמש ביצע, הגדרת מבנה הפעולות כך שתהיה התחלה, אמצע וסוף, והרגשה כי המשתמש הוא זה ששולט ביישום ולא להפך, הכרחיים הן לעבודה מול מחשב והן לעבודה במכשיר נייד.
ארבעת הכללים האחרונים דורשים שינויים על מנת להתאים לעולם המכשירים הניידים.
אחידות במכשירים ניידים לאחידות יש מימד נוסף שיש לתת עליו את הדעת.
ייתכן כי משתמש ירצה להשתמש ביישום לסירוגין במחשב האישי ובמכשיר הנייד שלו.
ייתכן כי יישומים מסוימים יעבדו במחשב ולא במכשיר הנייד, עקב אי תמיכה בתוכנות מסוימות.
לדוגמה, משתמש מבקש לקרוא מסמך מסוג מסוים במחשב שלו ולאחר מכן להעבירו למכשיר הנייד על מנת להמשיך ולקרוא אותו.
אולם, המכשיר הנייד לא בהכרח תומך בקריאת מסמך מסוג זה.
יכולת ביטול פעולה קשה יותר ליישם זאת במכשירים ניידים, בגלל זיכרון קטן יותר וכוח עיבוד חלש יותר בהשוואה למחשבים אישיים.
בגלל מגבלות הזיכרון מוגבלת היכולת לזכור את מצבי המערכת לפני הפעולות האחרונות.
הצעת מניעת טעויות וטיפול בבעיות פשוטות יש להתייחס גם לצד הפיזי של מכשירים ניידים.
במכשירים ניידים עולה הסבירות לטעויות הנגרמות מהקשה לא נכונה, בגלל הקרבה הפיזית של המקשים (הפיזיים או מקשי המגע).
הפחתת העומס על הזיכרון לטווח הקצר שימוש במכשיר נייד חושף ליותר הסחות דעת מאשר שימוש במחשב אישי.
ייתכן כי השימוש במכשיר נייד נעשה לצד שלל פעולות אחרות ולעיתים אף אינו העיסוק המרכזי (כמו בזמן הליכה למשל).
לכן, הפעולות צריכות להיות פשוטות וללא העמסת פרטים מיותרים על המשתמש.
אתרים שנבדקו ונמצאו נגישים ממחשבים אישיים, אינם בהכרח נגישים גם ממכשירים ניידים.
התקן לנגישות אתרים למכשירים ניידים נוסח על ידי קהילת W3C אשר מובילה קווים מנחים לנגישות באינטרנט.
על מנת לבדוק אם אתר הוא נגיש למכשירים ניידים (Mobile Friendly), ניתן להשתמש בשירות החינמי של הקהיליה.
בין בדיקות הנגישות, נבדק האם האתר עומד במגבלות נפח העמוד המרבי, המצאות טבלאות מקוננות ועוד.
להבדיל ממחשבים אישיים, למכשירים ניידים יש סוללה מוגבלת ולכן חשוב לשים לב כי היישום חסכני בצריכת החשמל מן הסוללה.
על מנת לתמוך בבדיקה זו, ניתן להשתמש בכלים אשר ממפים את אחוז צריכת הסוללה עבור כל יישום בנפרד.
בדיקות תוכנה ממוכנות (מכונות לרוב "בדיקות אוטומטיות", באנגלית: "Test Automation") הן בדיקות תוכנה המבוצעות בדרך אוטומטית על ידי שימוש בתוכנת מחשב ייעודית (נפרדת מהתוכנה הנבדקת).
ניתן לממש בדיקות אוטומטיות כתחליף לתהליכי בדיקות ידניים, או בנוסף להן – עבור תרחישים שלאדם יהיה קשה מאוד (ולעיתים בלתי אפשרי) לבצע ללא מיכון.
בדיקות תוכנה הן הניסיון להפעיל את כלל התהליכים האפשריים במערכת הנבדקת ולהעריך את פעולתם, זאת על ידי כתיבת מקרי בדיקה וביצועם.
כאשר מבוצעת באופן ידני, עבודה זו עלולה להיות מייגעת, לדרוש זמן רב ולהתבצע באופן לא יעיל בשל חזרה מרובה על אותן הפעולות (חזרה מרובה היא מאפיין נפוץ בעבודת הבדיקה).
אוטומציה של התהליך יכולה לפתור את הבעיות הללו מהסיבות הבאות:
מאפיין בסיסי של תכנות הוא ביצוע יעיל של פעולות החוזרות על עצמן בשל שימוש בלולאות ושגרות
על הבודק לממש את הבדיקה באופן אוטומטי פעם אחת – ומאז ניתן להריצה שוב לפי הצורך, ללא צורך בעבודה אנושית נוספת
מחשב מבצע את הפעולות הנפוצות בבדיקות במהירות העולה בהרבה על כל ביצוע ידני.
ניתן לחלק בדיקות אוטומטיות לשני סוגים:
בדיקות מבוססות קוד – הממשקים והמודולים השונים של המערכת נבדקים באמצעות קלטים מסוגים שונים תוך וידוא התוצאה המוחזרת.
בדיקות ממשק משתמש – סביבת האוטומציה מייצרת אירועים המדמים אינטראקציה של משתמש עם המערכת כגון שימוש במקלדת ובעכבר, בוחנת את השינויים בממשק המשתמש שנגרמו כתוצאה מכך ומשווה אותם להתנהגות הרצויה.
טרנד מתפתח בפיתוח תוכנה הוא שימוש בכלי בדיקות כגון JUnit או NUnit המאפשרים הרצה של בדיקות יחידה כדי לקבוע האם חלק מסוים בקוד מתנהג כצפוי תחת תנאים שונים.
מקרי הבדיקה מתארים בדיקות הכרחיות לווידוא הרצה תקינה של התכנה.
אוטומציה של בדיקות מבוססות קוד הוא פיצ'ר מרכזי במתודולוגית פיתוח תוכנה זריז, ומוגדר גם כפיתוח מונחה בדיקות (TDD).
בדיקות היחידה נכתבות להגדרת הפונקציונליות לפני כתיבת הקוד.
עם זאת, בדיקות אלו מתפתחות ומתרחבות במקביל להתקדמות תהליך הפיתוח שבמהלכו סוגיות חדשות מתגלות והקוד נתון לשינויים.
רק במקרה שבו כל הבדיקות עבור הפיצ'רים המפותחים עברו, הקוד נחשב גמור.
חסידי הגישה טוענים שהיא מפיקה תוכנה אמינה יותר וזולה יותר מאשר קוד שנבדק בצורת חקירה ידנית.
גישה זו נחשבת אמינה יותר מכיוון שכיסוי הקוד נרחב יותר.
כמו כן, הבדיקות רצות לעיתים תכופות במהלך תהליך הפיתוח ולא פעם אחת בסופו.
המפתח מגלה פגמים מיד עם ביצוע השינוי בקוד, בשלב שבו תיקון הפגם זול יותר ביחס לשלבים אחרים.
בסופו של דבר, ארגון הקוד מחדש הוא בטוח יותר; תהליך שינוי הקוד על ידי שיפור המבנה הפנימי תוך שמירה על ההתנהגות החיצונית יניב פחות פגמים בשימוש בגישה זו.
כלי אוטומציה רבים מאפשרים את היכולות להקליט פעולות משתמש ולהציג את תוצאות ההקלטות לצורך השוואת ההתנהגות בפועל להתנהגות הרצויה.
היתרון בגישה זו הוא שפיתוח התכנה שנדרש עבורה הוא מועט אם בכלל.
ניתן להשתמש בגישה זו בכל אפליקציה שכוללת ממשק משתמש.
יחד עם זאת, גישה זו עלולה ליצור בעיות אמינות ותחזוקה רבות.
תיוג מחדש של כפתור או הזזתו למיקום אחר במסך דורשת הקלטה מחודשת של הבדיקה.
כמו כן, חלק מן ההקלטות כוללות "רעשים" – פעולות לא רלוונטיות או הקלטה שגויה של חלק מן הפעולות.
דוגמה לווריאציה של כלי מסוג זה – כלי לבדיקת אתרי אינטרנט.
במקרה זה, ה"ממשק" הוא דף האתר.
כלים מסוג זה משתמשים בטכניקה שונה של קריאת דף ה-HTML במקום לבחון אירועים במסך.
וריאציה נוספת היא אוטומציה ללא תסריטים (סקריפטים) שבה במקום להקליט ולהציג את פעולות המשתמש, יוצרת מודל של האפליקציה הנבחנת ומאפשר לבודק לייצר מקרי בדיקה על ידי עריכה פשוטה של הפרמטרים ותנאי הבדיקה.
גישה זו לא דורשת מהבודק יכולת כתיבת תסריטים, אך עדיין יש לה את הכוח והגמישות של גישה מבוססת תסריטים.
תחזוקת מקרי הבדיקה פשוטה למדי, אין קוד שדורש תחזוקה ועם כל שינוי באפליקציה הנבחנת מעדכנים את המערכת ליצירת מודל חדש.
הבעיה היא שמודל האפליקציה מבוסס על תסריטי בדיקות שדורשים תחזוקה כל פעם שיש שינוי באפליקציה הנבחנת.
כלי בדיקה יכולים לעזור להפוך מטלות לאוטומטיות כגון התקנת מוצר, יצירת נתוני בדיקה, אינטראקציית ממשק משתמש גרפי, זיהוי בעיות וכו', לא בהכרח על ידי הפיכת הבדיקות לאוטומטיות בתצורת רשת קצה-אל-קצה.
יש לבדוק התקיימות דרישות פופולריות כאשר חושבים על אוטומציה של בדיקות:
אי תלות של פלטפורמות ומערכות הפעלה
היכולת המונעת על ידי נתונים (קלט, פלט, נתוני-על)
ניפוי שגיאות ותיעוד יומן בצורה קלה
שליטה ידידותית בגרסאות – קבצים בינאריים מינימליים
בר הרחבה ובר התאמה (API חופשיים כדי שיהיה אפשר לשלב עם כלים אחרים)
דרייבר נפוץ (לדוגמה IDE עבור JAVA).
זה מאפשר ביצוע אינטגרציה בין בדיקות לזרימת העבודה של המפתחים.
תמיכה בהרצת בדיקות לא-מטופלות לצורך אינטגרציה עם תהליכי build ואצווה.
שרתים של אינטגרציה מתמשכת דורשים זאת.
הודעות אימייל (הודעה אוטומטית במקרה של כישלון או השגת רף כלשהו).
מסגרת היא מערכת משולבת, שקובעת חוקים של אוטומציה למוצר ספציפי.
המסגרת משלבת את ספריות הפונקציות, מקורות הנתונים של הבדיקות, פרטי האובייקטים ומגוון מודולים לשימוש חוזר.
רכיבים אלו פועלים כאבני בניין קטנות אשר צריכות הרכבה כדי לייצג תהליך עסקי.
המסגרת מספקת את הבסיס של בדיקות האוטומציה ומפשטת את מאמץ האוטומציה.
הגדרת גבולות בין מסגרת אוטומציה וכלי בדיקה
כלים מעוצבים באופן ייעודי לסביבת בדיקות מסוימת, כגון סוג מערכת ההפעלה וכלי אוטומציה אינטרנטיים, וכולי.
כלים משמשים כ-driving agent עבור תהליך אוטומציה.
אולם, מסגרת אוטומציה היא לא כלי לביצוע מטלה ספציפית, אלא תשתית שמספקת פתרון, היכן שכלים שונים יכולים לבצע את עבודתם בצורה אחודה.
זה מספק פלטפורמה רווחת למהנדס האוטומציה.
יש סוגים שונים של מסגרות.
הן מקוטלגות על בסיס רכיב האוטומציה שהן ממנפות:
כלי בדיקות אוטומציה ראויים לציון
בדיקה רפואית שגרתית היא בדיקה רפואית אשר מבוצעת לטובת רפואה מונעת או לעדכון תמונת המצב הרפואית של אדם.
תוצאות של בדיקה שגרתית יכולה לעזור באבחון בעיות ומחלות אפילו לפני התפתחותן, או לעדכן את הצוות הרפואי לגבי המצב הנוכחי.
הבדיקות מבוצעות במטרה לגלות מחלות וליקויים בשלב מוקדם ככל האפשר, ותוך ראייה שמשתפרים הסיכויים לרפא מצבים רבים ככל שהגילוי שלהם נעשה בשלב מוקדם יותר.
אבחון בעיות בשלב מוקדם ומידע רפואי נכון ועדכני יכולים להגביר את הסיכויים לטיפול יעיל ולהחלמה מהירה.
ההמלצות על הרכב הבדיקות, תכיפותן, והיקפן מושפעות מגיל, מגדר, מהיסטוריה הרפואית אישית והמשפחתית, מסגנון חיים (הרגלי תזונה, פעילות גופנית, עישון) ומגורמים נוספים.
בישראל בדיקות שגרתיות לתינוקות ולפעוטות נעשות בישראל לרוב בתחנה לבריאות המשפחה, ולמבוגרים במכונים לבדיקות סקר בריאות.
בדיקה רפואית כללית אצל הרופא: מיועדת לבחון מצבים רפואיים שונים והיסטוריה רפואית.
כמו כן, הבדיקה כוללת תשאול על הרגלי התזונה, סגנון חיים, פעילות גופנית, התמכרויות, חיי חברה, בעיות נפשיות ובהן דיכאון.
תשאול היסטוריה רפואית: ההזדמנות של המטופל לדבר על תלונותיו וחששותיו לגבי בריאותו, אשר משתף המטופל עם הרופא שלו כל מה שקשור בסגנון החיים, כמו עישון, שתיית אלכוהול, תזונה, פעילות גופניות וכולי.
בדיקת סימנים חיוניים כמו לחץ דם, קצב דפיקת לב, קצב הנשימה, מדד חום.
מראה כללי של המטופל: לאיסוף מידע התרשמותי כללי
בדיקת לב: בדיקת דופק הלב בעזרת מסכת
בדיקה גופנית כללית מקיפה: לגילוי מחלות ומצב בריאותי כללי, ונותנת עדכונים להיסטוריה הרפואית של המטופל
בדיקת התפתחות: לגילוי בעיות בריאות שונות (בילדים ונוער) וכוללת בדיקה פיזית של מערכות הגוף, שקילה ומדידת הגובה, מדידת היקף הראש והערכת ההתפתחות בכמה תחומים, כגון המוטוריקה והתקשורת בילדים, או ובדיקת אם מתנהלת כסדרה ההתפתחות הגופנית (כולל התפתחות מינית) והנפשית אצל בני נוער.
בדיקות עיניים וראייה: לגילוי מחלות והפרעות בהתפתחותן ותפקוד של העיניים ושל מערכת הראייה, ואבחון ירידה בחדות וטווח ראייה.
כמו כן, בדיקות לאיתור מחלות הגיל המבוגר, ובהן גלאוקומה, קטרקט, ניוון מרכז הראייה וגידולים על גלגל העין, ואיתור השפעות על העיניים של מחלות סיסטמיות כגון יתר לחץ דם וסוכרת.
בדיקת שיניים: חיפוש סימנים לעששת, בדיקת ריריות הפה (הלחיים, השפתיים, החך והלשון), וחיפוש סימנים למחלות במערכת התמיכה של השן - בעיקר מחלות חניכיים (מחלות פריודונטליות)
ספירת דם: לבחינת מצבם של שלושה מרכיבים מרכזיים של הדם: תאי דם לבנים, תאי דם אדומים וטסיות דם
מדידת לחץ דם: במטרה לאתר לחץ דם חריג במיוחד בסובלים ממשקל יתר.
לחץ דם לא תקין עלול לפגוע באיברים חיוניים רבים ובהם הלב, המוח, הכליות והעיניים.
בדיקת עור: בדיקה שמיועדת לגלות התפתחות של סרטן העור (כגון מלנומה) ושל מחלות עור נוספות.
שקילה וחישוב BMI: לאבחון עודף משקל שהוא גורם סיכון ליתר לחץ דם, לסוכרת, לטרשת עורקים ולמחלות קשות רבות אחרות
בדיקת פרופיל שומנים: לאיתור רמות גבוהות מהנורמה של כולסטרטול "רע" ושל טריגליצרידים המהווים גורם סיכון להתפתחותן של מחלות קשות רבות, ולאתר רמות גבוהות של כולסטרול "טוב" שעשויות למנוע או לעכב רבות מהמחלות האלה
בדיקת צוואר הרחם (בדיקת פאפ): לגלוי את סרטן צוואר הרחם או סימנים המעידים על התפרצות אפשרית וקרובה של המחלה.
בדיקת שד: לגילוי גושים חשודים בשד שעלולים להצביע על התפתחותו של סרטן השד
בדיקת אק"ג: לאבחון הפרעות קצב ומחלות שונות של שריר הלב
בדיקה לגילוי דם סמוי בצואה: לגילוי סרטן המעי הגס
בדיקת צפיפות עצם: לאבחון מחלת האוסטאופורוזיס ("בריחת סידן") המחלישה את העמידות של העצמות, וכתוצאה מכך גדל הסיכון לשברים
קולונוסקופיה: לאיתור סימנים לסרטן המעי הגס.
בדיקות לסרטן הערמונית: סוגים נפוצים של הבדיקות הם אנטיגן ספציפי לערמונית (PSA), ובדיקה רקטלית דיגיטלית.
בדיקה רקטאלית היא בדיקה רפואית פולשנית של החלחולת הנערכת על ידי רופא או איש צוות רפואי אחר.
בדיקה רקטאלית במישוש היא בדיקה רפואית פשוטה באופן יחסי.
המטופל חושף את פלג גופו התחתון ונמצא בתנוחה שבה ניתן לגשת לפי הטבעת (בדרך כלל, בשכיבה על הצד, בכריעה על שולחן הבדיקה, בהתכופפות על שולחן הבדיקה, או בשכיבה ורגליו מפוסקות ומורמות).
אם המטופל שוכב על צידו, הרופא יבקש בדרך כלל מן המטופל לקפל את רגליו כלפי החזה.
הרופא מפסק את העכוז, ותחילה בודק באופן חיצוני את אזור פי הטבעת וחיץ הנקביים לסימני מחלה, כגון טחורים, גידולים, או פריחה עורית.
לאחר הרגעת המטופל הרופא מחדיר אצבע עטויה בכפפה ומרוחה במשחה לתוך החלחולת, דרך פי הטבעת, וממשש בתוך החלחולת כחמש שניות עד דקה שלמה.
ניתן להשתמש בבדיקה רקטאלית למטרות הבאות:
אבחון גידולים באזור פי הטבעת והחלחולת;
אבחון הפרעות בבלוטת הערמונית, בעיקר גידולים והתרחבות שפירה של הבלוטה, אולם בבדיקה רקטאלית לא ניתן בדרך כלל לאבחן את רוב הגידולים בבלוטת הערמונית הנמצאים בשלבים מוקדמים;
אבחון דלקת התוספתן או מצבים אחרים של בטן חריפה;
הערכת מצב פי הטבעת, מידע העשוי לסייע במקרי אי שליטה בסוגרים, מחלות עצביות, או פגיעה טראומטית בעמוד השדרה;
למישוש איברי רבייה אצל נשים;
כדי לפסול מומים מולדים בפי הטבעת אצל ילודים.
פעמים רבות משלבים את הבדיקה הרקטאלית עם בדיקת דם סמוי בצואה העשויה להצביע על דימומים במערכת העיכול כתוצאה מכיב, או גידול.
בדיקה רקטאלית אינה מספקת כדי לפסול אפשרות של סרטן המעי הגס כיוון שבדיקה זו סוקרת רק כ-10% מכלל שטח המעי הגס, אולם היא מהווה חלק חשוב מבדיקה גופנית כללית כיוון שגידולים רבים ומחלות אחרות עלולות להתבטא בממצאים העולים בבדיקה רקטאלית.
בדיקה רקטאלית משמשת כלי אבחוני חשוב ברפואה וטרינרית.
בבדיקת כלבים ניתן להעריך באמצעותה את מצב בלוטת הערמונית (בדומה לבני אדם), את שלפוחית השתן, בלוטות לימפה, ובלוטות פי הטבעת.
בסוסים היא חלק בלתי נפרד מבדיקה גופנית של סוס לאבחון כאבי בטן (קוליק), ומצבי מחלה אחרים.
בדיקה רקטאלית בסוסים נושאת סיכון קטן של גרימת קרע בפי הטבעת, מצב מסכן חיים בסוסים.
בבקר בדיקה רקטאלית היא בדיקה שגרתית ומשמשת אחת השיטות לאבחון הריון.
בדיקות קופסה לבנה הן בדיקות תוכנה המתייחסות למבנה הפנימי של הרכיב או המערכת.
בניגוד לבדיקות קופסה שחורה, שמטרתן היא לבדוק את קיום הדרישות של הרכיב, בדיקות קופסה לבנה בודקות את נכונות החלקים הפנימיים של הרכיב.
הבדיקות מבוססות על קוד המקור, ולכן נכתבות בעיקר על ידי מתכנתים, ולא על ידי בודקי קוד.
בדיקות קופסה לבנה נעשות בעיקר ברמת בדיקות יחידה, אך יכולות להתבצע גם ברמת בדיקות אינטגרציה ובדיקות נסיגה.
השאיפה היא לכתוב סט בדיקות שיוודאו את נכונות כל הקוד ברכיב.
הבדיקות נכתבות מול הקוד, ומסתמכות על הידע של הבודק וההבנה שלו בלוגיקת הרכיב.
באופן כללי, הבודק בוחר קלט שיבדוק חלק מסוים בקוד, ומשווה אותו עם הפלט שהוא מצפה לקבל.
כדי להעריך את היקף הבדיקות שכתבנו, נשתמש במדדי כיסוי קוד.
דרך טובה להתחיל היא להבטיח כיסוי שורות קוד מרבי, שכל שורת קוד תרוץ פעם אחת לפחות.
לצורך כך, אפשר להיעזר בתרשימי זרימה של הרכיב, ולכתוב בעזרתם בדיקה לכל מסלול אפשרי.
שיטה זו נקראת "בדיקת מסלולי בסיס", והיא מספקת מספר מינימלי של בדיקות שצריך לקבלת כיסוי שורות קוד מקסימלי.
בנוסף לכיסוי שורות קוד, חשוב גם לבדוק תקינות לולאות שמופיעות בקוד.
בדיקת לולאות היא בדיקה שמריצה קלטים הבודקים לולאה מסוימת בקצוות שלה ובטווח הפעולה שלה.
הבדיקות עוזרות לגלות מקרי-קצה ושגיאות חבויות בקוד.
הבדיקות מעודדות את הכותב להבין את קוד המקור היטב, ולשפר אותו.
בגלל שהבדיקות מבוססות על הקוד, כאשר בדיקה נכשלת, יותר קל למצוא את שורות הקוד שאחראיות לבעיה.
הבדיקות מסובכות יחסית לכתיבה, ולכן הבודק חייב להיות בעל ידע במבנה הפנימי של המערכת ועם יכולות תכנות גבוהות.
בגלל מספר המסלולים האפשריים הרב בקוד, לא תמיד ניתן לכתוב בדיקות לכל מסלול וחלק מהם לא יבדקו.
אף על פי ששיטת בדיקה זו יכולה לגלות הרבה בעיות ושגיאות, היא לא בהכרח תגלה דרישות חסרות או חלקים לא ממומשים בקוד.
כיום, ישנם מספר כלים לייצור אוטומטי של בדיקות קופסה לבנה.
כלי אוטומציה כמו Pex יודעים לנתח את הקוד ולמצוא ערכי קלט מייצגים שיאפשרו מעבר במסלולים שונים בקוד.
בהקשר של בדיקות חדירות, שהן בדיקות שנעשות למערכת כדי לחפש חולשות אבטחה, בדיקות קופסה לבנה מהוות בדיקות בהן לתוקף יש את כל המידע על המערכת.
בדיקת A/B (מבחן A/B או Split Testing) היא שיטה לבדיקת הקיים אל מול השינוי וקביעת הגרסה בעלת התוצאות החיוביות יותר.
בדיקה זו נפוצה בתחומי השיווק, סחר אלקטרוני, פיתוח אתרים ותחומים נוספים ומאפשרת לבחון את תגובות המשתמשים לשינויים.
בדיקת A/B מוכרת גם בשם Split Testing ו-bucket tests אך מונחים אלה מכילים גם מבחנים מעט יותר מורכבים.
הבדיקה מתבצעת על ידי השוואת 2 גרסאות, A - בדרך כלל הגרסה הנוכחית (control) מול B - גרסה עם שינוי יחיד (treatment).
שתי קבוצות משתמשים דומות מקבלות בו זמנית את המערכת הנבדקת, כל קבוצה גרסה אחרת.
מודדים את מטרת הבדיקה ומחליטים איזו גרסה גרפה תוצאות טובות יותר.
החלת שינוי לא מבטיחה שיפור ולכן יש סיכוי להפסד.
ביצוע בדיקת A/B מספק מידע אמין על שינויים לפני שמחילים אותם בפועל ותוצאות הבדיקה הן מקור מידע בעל ערך רב למקבלי ההחלטות.
שימוש בבדיקה זו יוביל להפחתת סיכונים והוזלת עלויות.
השינויים יכולים לבוא לידי ביטוי בשינוי טקסטואלי, מבנה הדף (layout), שינוי הצבעים, גודל האובייקטים, תזמוני הופעה, שינוי אלגוריתמי, חשיפה שונה לקבוצות שונות וכו'.
התאוריה של ניסוי מבוקר פותחה על ידי סר רונלד א.
פישר דרך ניסויים שערך באנגליה בשנות העשרים.
אמנם ניסויים לא מקוונים מפותחים היטב בעולם הסטטיסטיקה שנים רבות, ניסויים מבוקרים ברשת החלו בסוף שנות התשעים עם צמיחת האינטרנט כאשר דרכים חדשות לדגום אוכלוסיות הפכו לזמינות.
מהנדסי גוגל ביצעו את מבחן ה-A/B הראשון שלהם בשנת 2000 בניסיון לקבוע מה יהיה המספר האופטימלי של תוצאות מוצגות במנוע החיפוש שלה.
הבדיקה הראשונה לא הצליחה עקב תקלות שנבעו מזמן טעינה איטי.
אמנם מאוחר יותר מחקרים של בדיקות A/B הפכו מתקדמים יותר אך הבסיס והעקרונות הבסיסיים נשארו זהים.
בשנת 2011, 11 שנים לאחר הבדיקה הראשונה שלה, גוגל ביצעה מעל 7,000 בדיקות A/B שונות.
בשנת 2012, עובד מיקרוסופט שעבד על מנוע החיפוש בינג יצר ניסוי לבחינת דרכים שונות להצגת כותרות פרסום.
תוך שעות בודדות הפורמט האלטרנטיבי הניב עלייה בהכנסות של 12% ללא השפעה על מדדי חוויית המשתמש.
באוקטובר 2017, פלטפורמת פייסבוק השיקה לראשונה מערכת המאפשרת ביצוע מבחני A/B או Split Testing, אשר קיימת לכל מטרה פרסומית פרט לשלוש קטגוריות: Brand Awareness, Messages, Store Visits.
ניסויים מבוקרים ברשת נחשבים בימנו לכלי חיוני והשימוש בהם הולך וגדל עבור סטארטאפים ואתרים קטנים יותר, וחברות רבות משתמשות בגישת ה"ניסוי המעוצב" לקבלת החלטות שיווק, מתוך ציפייה שתוצאות מדגם רלוונטיות יכולות לשפר את יחס ההמרה.
זהו נוהג נפוץ יותר ויותר ככל שהכלים והמומחיות צומחים בתחום זה.
נרצה למצוא את האלטרנטיבה שמשיגה את התוצאות החיוביות ביותר ומייעלת לפחות אחת ממטרות המערכת.
תכנון- הגדירו היטב מה אתם בוחנים- מהי מטרת הבדיקה, באילו מדדים תשתמשו כדי להוכיח שינוי חיובי, ומה נחשבת תוצאה טובה.
העלאת רעיונות לשינויים - יצירת בנק רעיונות שיכיל גרסאות שונות, שיוכלו תיאורתית לשפר את אחוז ההמרה.
הגדרת קבוצות - בחינת אוכלוסיית המשתמשים באפליקציה או באתר, והתאמת השינויים עבור אוכלוסייה.
מטבע הדברים, בחלק נרחב מהמוצרים זהו דבר לא הכרחי - וההרצה תהיה רנדומלית.
איסוף הנתונים - קביעה מראש של איך יראו הנתונים שיאספו, ולאן הם ינותבו - דבר שיאפשר ניתוח מהיר ויעיל.
הערכת זמן הריצה - לא מפסיקים טסט כשמגיעים למובהקות סטטיסטית, אלא מתי שעבר זמן הריצה שהוגדר מראש על ידי העוצמה הסטטיסטית הרצוייה.
ביצוע- ניתן לפתח בדיקת A/B עצמאית או להשתמש בכלים חיצוניים.
כיום ישנם מספר כלים מתקדמים שניתן לבצע את הבדיקה דרכם.
תוצאות- תוצאות הבדיקה מוצגות כמידע כמותי המאפשר השוואה ברורה (רצוי להגיע למובהקות סטטיסטית).
לפעמים אין הבדל משמעותי בין הגרסאות וחשוב לא למהר להסיק מסקנות.
כמו כן צריך לחשוב על ההשפעה של הגרסה המנצחת של הפריט הנבדק על מטרות ופריטים אחרים.
בדיקות A/B משווקות בחלקן כשינוי בפילוסופיה ואסטרטגיה עסקית בנישות מסוימות, אם כי הגישה זהה לעיצוב בין נושאים המשמש לעיתים במגוון תחומי מחקר.
בדיקת A/B כפילוסופיה של פיתוח רשת מביאה את התחום לכיוון רחב יותר המתבסס על ראיות וניתוח נתונים.
היתרונות של מבחני A/B באים לידי ביטוי בכך שניתן לבצע את המבחן באופן רציף כמעט על כל דבר, במיוחד מכיוון שלרוב תוכנות האוטומציה השיווקית כיום יכולת לבצע בדיקות A/B באופן שוטף.
בתחום הרפואה למשל, מתבצעת הבדיקה כדי לבדוק אפקטיביות של תרופה חדשה לפני שיוצאת לשוק- מנסים על קבוצת נסיינים את התרופה האמיתית ועל קבוצה אחרת תרופת פלצבו (תרופת דמה) וכך בודקים את השפעתה או חוסר השפעתה.
בעולם השיווק הדיגיטלי, בדיקת A/B הן למעשה ניסוי סטטיסטי המשווה בין שתי גרסאות במטרה לזהות ולהטמיע את השינוי שיביא לשיפור התוצאה הרצויה, למשל: אחוזי הקלקה, הרשמה, רכישה וכו'.
ניתן ורצוי להשתמש בכלי הזה כדי לעשות אופטימיזציה להרבה מאוד דברים: עיצוב ותוכן של מיילים וניוזלטרים, דפי נחיתה, תיאורי מוצרים בחנות וירטואלית, מודעות בגוגל וברשתות החבריות ועוד.
המטרה העיקרית בביצוע בדיקת A/B היא לחסוך כסף למשווק.
בדיקה טובה ומקיפה מאפשרת להביא שיפור משמעותי בהמרות של קמפיין נתון, אפילו עד פי 10 מהמצב הקודם שלו וכך להוזיל את עלות הפרסום.
אם אפשר לשנות אותו אפשר לבדוק אותו - כמעט כל דבר שמשפיע על התנהגות המשתמשים אפשר לבדוק בעזרת בדיקת A/B.
לדוגמה: אלמנטים באתר אינטרנט שאפשר לבדוק-
טקסט וכפתורים – "Call to Action"
מודעת פרסום ברשת חברתית:מטרת הבדיקה- למקסם מספר הקלקות על המודעה והגעת המשתמש לאתר החברה ביחס לכמות החשיפות למודעה (CTR).ניתן לבדוק מספר שינויים במודעה למשל המסר, התמונה המצורפת, גודל פונט, מיקום המודעה באתר ועוד.נשווה מספר הקלקות על כל גרסה של מודעה כאשר 2 המודעות נחשפו מספר שווה ולקבוצה דומה של משתמשים.
בין החברות שמתמחות בבדיקת A/B ניתן למנות חברה ישראלית ABBI שנרכשה לאחרונה על ידי WalkMe
חברה עם מאגר לקוחות של 2,000 איש מחליטה ליצור קמפיין במייל עם קוד הנחה על מנת לייצר מכירות דרך אתר האינטרנט שלה.
לשם כך, נוצרו שתי גרסאות של הדוא"ל עם קריאה לפעולה שונה (החלק של העותק שמעודד לקוחות לבצע פעולה - במקרה של קמפיין מכירות, לבצע רכישה) וזיהוי קוד קידום מכירות.
דוגמה לבדיקת A/B דרך דוא"ל
לאלף אנשים נשלח הדוא"ל עם הקריאה לפעולה ובה נאמר "ההצעה מסתיימת ביום שבת הקרוב!
השתמש בקוד "A1" ולעוד אלף איש נשלח הדוא"ל עם הקריאה לפעולה ובה נאמר "ההצעה תסתיים בקרוב!
כל שאר האלמנטים בהעתקה ובפריסה של הדוא"ל זהים.
לאחר מכן החברה מנטרת לאיזה קמפיין יש את אחוזי ההצלחה הגבוהים יותר על ידי ניתוח השימוש בקודי הפרסום.
לאימייל המשתמש בקוד A1 שיעור התגובה של 5% (50 מתוך 1000 האנשים שקיבלו את הדוא"ל השתמשו בקוד כדי לקנות מוצר), והדוא"ל שמשתמש בקוד B1 מכיל שיעור תגובה של 3% (30 מהנמענים השתמשו בקוד כדי לקנות מוצר).
לפיכך החברה קובעת שבמקרה זה, הקריאה לפעולה הראשונה יעילה יותר ותשתמש בה במכירות עתידיות.
בדיקה מקיפה יותר תכלול יישום של בדיקות סטטיסטיות כדי לקבוע אם ההבדלים בשיעורי התגובה בין A1 ל-B1 היו מובהקים סטטיסטית.
בדוגמה לעיל, מטרת הבדיקה היא לקבוע איזו היא הדרך היעילה יותר לעודד לקוחות לבצע רכישה.
אם בכל זאת, מטרת הבדיקה הייתה לראות איזה דוא"ל יפיק את שיעור הקליקים הגבוה יותר - כלומר, מספר האנשים שלמעשה לוחצים לאתר לאחר קבלת הדוא"ל - ייתכן שהתוצאות היו שונות.
לדוגמה, אף על פי שיותר מהלקוחות שקיבלו את הקוד B1 נכנסו לאתר, מכיוון שהקריאה לפעולה (Call To Action) לא הצהיר את תאריך הסיום של המבצע, רבים מהם עשויים לחוש דחיפות לבצע רכישה מיידית.
כתוצאה מכך, אם מטרת הבדיקה הייתה פשוט לראות איזה דוא"ל יביא תנועה רבה יותר לאתר האינטרנט, ייתכן שהדוא"ל המכיל את הקוד B1 היה מצליח יותר.
לבדיקת A/B צריכה להיות תוצאה מוגדרת הניתנת למדידה כמו מספר המכירות שבוצעו, המרת שיעור קליקים או מספר האנשים שנרשמים / נרשמים.
בדיקת פריט אחד עם שלוש אופציות וחלוקת קבוצת הנשאלים לשלוש כנראה עדיין תיחשב בדיקת A/B, למשל בדיקת גרסאות שונות לכותרת בדף אינטרנט כך שבכל גרסה הכותרת בצבע שונה.
עדיף לבצע מבחן אחד במקביל לשלושת הצבעים מאשר שלושה מבחנים שונים (A/B, A/C, C/B).
בדיקה הכוללת שינויים ביותר מפריט אחד באותו מבחן לא תיחשב בדיקת A/B.
למשל שינויים בכותרת וגם בכפתור ביצוע בדף אינטרנט, בדיקה זו נקראת multi-variate test והיא יותר מורכבת.
בדיקת CRAAP פותחה על ידי Sara Blakeslee וצוות הספרנים באוניברסיטת קליפורניה, צ'יקו כדי להעריך איכות של מקורות מידע המשמשים למחקר אקדמי בתחומי דעת שונים.
המספר העצום של מקורות באינטרנט, מקשה על בחירת המקורות שניתן לבסס עליהם מחקר אקדמי.
בדיקת CRAAP נועדה להקל על מרצים וסטודנטים לקבוע אם ניתן להסתמך על המקורות שאיתרו.
הערכת מקורות באמצעות בדיקת CRAAP היא שיטה הנלמדת בעיקר בהדרכות של ספרנים בספריות אקדמיות.
המונח CRAAP הוא ראשי התיבות מאנגלית של: עדכניות, רלוונטיות, סמכות, דיוק, מטרה
עדכניות (Currency)- האם המקור עדכני?
האם פורסם או עודכן בזמן האחרון?
היכן המקור פורסם או עודכן?
יש לשקול אם נושא המחקר מחייב מקורות חדשים או מעודכנים, או שיש ערך גם למקורות ישנים יותר.
רלוונטיות (Relevance )- האם המקור רלוונטי לנושא המחקר.
איך הוא מתייחס לנושא המחקר?
האם המקור נכתב עבור קהל היעד המתאים?
האם המקור כתוב ברמת מורכבות המתאימה לחוקר: כלומר, לא ברמה בסיסית מדי או מתקדמת מדי עבור החוקר.
סמכות (Authority )- בדיקת הסמכות של מקור, מתייחסת לרקע של המחבר, כמו גם לרקע של המפרסם או של נותן החסות.
נבדקת רמת ההשכלה של המחבר והשיוך שלו למוסדות אקדמיים או אחרים.
האם המחבר מוסמך לכתוב על הנושא?
צריך להיות גם מידע ליצירת קשר עם המחבר או המפרסם.
דיוק (Accuracy )- הדיוק של התוכן במקור נמדד לפי ההתאמה בין הראיות למידע שמבוסס עליהן.
הראיות חייבות לתמוך במידע המוצג.
ראיות עשויות לכלול ממצאים, תצפיות או הערות שדה.
המקור צריך להיות שפיט או מצוטט במקורות אחרים.
המידע במקור חייב להיות מאומת במקור אחר או מוכר לציבור רחב.
השפה בה נכתב המקור צריכה להיות בלתי-משוחדת ונטולת רגש, ולהתרכז בדיווח על עובדות.
התוכן במקור צריך להיות נקי משגיאות כתיב, דקדוק או שגיאות דפוס.
מטרה (Purpose )- המטרה של המקור קובעת אם הוא מתאים למחקר שלשמו הוא אותר.
"מטרה" יכולה להיות: ליידע, ללמד, למכור, לבדר, או לשכנע.
המטרה של המחבר צריכה להיות ברורה.
יש לבדוק אם המידע מבטא עובדה, דעה או תעמולה, ואם הוא מוטה בהטיה פוליטית, אישית, דתית או אידאולוגית.
הערכת מקורות באמצעות בדיקת CRAAP נלמדה לראשונה בשנת 2004 במסגרת סדנה שערכה Sarah Blakeslee למרצים של סטודנטים בשנה הראשונה.
Sara המציאה את ראשי התיבות כדי לזכור את הקריטריונים להערכת מקורות.
היא רצתה ללמד שיטה קלה יותר לקבוע רמת איכות של מקורות.
בדיקה זו נוצרה בשנת 2002 על ידי קבוצה של ספרנים באוניברסיטת קנט סטייט בעקבות הדרישה לבדיקת הערכה שתעזור לסטודנטים להתמצא במקורות חשובים.
מאז החל השימוש בבדיקת CRAAP באוניברסיטת CSU Chico, אוניברסיטאות אחרות אימצו אותה כדי לסייע בהערכת האתרי אינטרנט.
במאמר שלה, Cara Berg, ספרנית יעץ ורכזת הדרכת משתמשים באוניברסיטת William Paterson, מתייחסת בהרחבה להערכת אתרי אינטרנט ככלי למחקר פעיל.
הערכת אתרים באמצעות CRAAP נלמדה במסגרת קורסי כתיבה לסטודנטים שנה ראשונה, כדי לסייע להם לחדד את מיומנויות המחקר שלהם.
כאשר בדיקת CRAAP הוטמעה לראשונה, היו מספר אתגרים טכניים.
הסדנה להערכת אתרים הייתה מואצת וברוב המקרים הספרן לא הצליח להעביר את החומר בשלמותו.
סטודנטים רבים לא הבינו שהם צריכים להעריך את האתר ובמקום זאת העריכו את התוכן שפורסם בו.
חלק מהסטודנטים השלימו את המשימה מבלי להבין את ההנחיות.
היה צורך בהנחיות יותר מפורטות וכאשר ניתנו כאלה, הסטודנטים הצליחו להעריך אתרים בעזרת בדיקת CRAAP.
בדיקת CRAAP נלמדת בדרך כלל בהדרכות ספרייה לסטודנטים שנה הראשונה.
השימוש הנפוץ ביותר הוא בקורסי כתיבה, אך משתמשים בה גם בקורסים רבים אחרים, ובהם קורסים בתחומי המדעים וההנדסה.
מאמר שפרסמו ספרן היעץ Toni M.
Carter ומרצה בקורסי כתיבה בשנת 2016 יצא כנגד הנטייה של ספרנים בספריות אקדמיות לספק "רשימת מכולת" של קריטריונים להערכת מקורות, ובדיקת CRAAP היא הדוגמה העיקרית לרשימות מסוג זה.
הטענה היא שרשימות כאלה מוותרות על המורכבות והניואנסים שבהערכת מקורות ומעודדות הערכת מידע דיכוטומית (נכון / לא נכון).
במאמר נטען כי רשימות מסוג זה ספגו ביקורת רבה מאז ש-ACRL פרסמה קווים מנחים להנחלת אוריינות מידע בשנת 2015. לפי קווים אלה נדרשת גישה הוליסטית ופדגוגיה אותנטית המתמקדת בפרקטיקות של למידה מהתנסות ביצירת מידע ורפלקציה.
בדיקות שמיעה נעשית כאשר עולה חשש לפגיעה בשמיעה.
מטרת הבדיקה היא לקבל תמונת מצב של יכולת השמיעה ועד כמה יש ירידה בשמיעה ואופייה, כמו גם על מנת לאפשר קביעת הטיפול הנדרש לשם שיקום.
בדיקת השמיעה כוללת שני סוגים עיקריים של בדיקות: בדיקות שמיעה אובייקטיביות שאינן תלויות בתגובת המטופל, ובדיקות שמיעה סובייקטיביות התנהגותיות שדורשות שיתוף פעולה מצד הנבדק.
בדיקות אובייקטיביות כוללות: בדיקת טימפנומטריה (הערכה ורישום שמיעתי של האוזן התיכונה), רפלקס אקוסטי, בדיקת הדים קוכליאריים ובדיקת פוטנציאלים שמיעתיים מעוררים – רישום הפעילות החשמלית של עצב השמיעה, בעקבות גירויים אקוסטיים, מרמת הקוכליאה עד לגזע המוח.
האוזן האנושית מחולקת לשלושה אזורים: החלק החיצוני, מרכזי ופנימי.
בדיקת הטמפנומטריה מתמקדת בחלק המרכזי – האוזן התיכונה.
הבדיקה מבוצעת יחד עם בדיקת שמיעה התנהגותית לצליל טהור (pure tone audiometry), שבה נמדדת גם התגובה ההתנהגותית של המטופל.
בדיקת הטמפנומריה אינה מוגדרת כבדיקת שמיעה אך ניתן להגדיר אותה כבדיקת יעילות אובייקטיבית של האוזן התיכונה.
באוזן התיכונה ישנו חלל מלא באוויר הנקרא חלל התוף (tympanic cavity), ושלוש עצמות שמע – פטיש, סדן וארכוף.
האוזן החיצונית מעבירה גלי קול המגיעים מבחוץ הגורמים לרטט בעור התוף – קרום דק המפריד בין האוזן החיצונית והאוזן התיכונה.
כחלק מהבדיקה משתמשים במכשיר טמפנומטריה, המכיל בקצהו שלושה חורים.
החור הראשון הוא מעין דיבורית המשמיעה צליל – גל קול בתדירות של 226Hz בדרך כלל, כאשר בפעוטות עד גיל 4 חודשים הצליל יהיה שונה – גל קול בתדירות של 1,000Hz.
עוצמת הצליל ואמפליטודת גל הקול, נשארת קבועה.
החור השני, תפקידו לשנות את לחץ האוויר בתעלת השמע החיצונית והחור השלישי מכיל מיקרופון אשר מודד את הצליל החוזר לחלק החיצוני של האוזן.
הצליל החוזר הוא גל קול בתדירות מסוימת אשר "קופץ" חזרה מעור התוף המכונה גם הממברנה הטימפנית דרך תווך האוויר המצוי בתעלת השמע החיצונית.
לצורך מעבר של גלי הקול באוויר דרך קרום התוף, לחץ האוויר בתעלת השמע החיצונית ובחלל התוף שבמרכז האוזן צריך להיות שווה.
מטרת הבדיקה היא לגלות באיזה לחץ אוויר, הכמות המזערית ביותר של צליל מוחזרת ונמדדת על ידי המיקרופון של מכשיר הטמפנומטריה.
נקודה זו, של החזרת צליל מינימלית, מעידה על ההיענות המקסימלית של האוזן התיכונה.
לפי שינויי לחץ האוויר על ידי מכשיר הבדיקה יחד עם מדידת הצליל החוזר במיקרופון, ניתן להבין מה הוא לחץ האוויר באוזן התיכונה.
במצב שמע תקין, ביצירת לחץ אוויר נייטרלי בתעלה החיצונית על ידי המכשיר, תהיה היענות מקסימלית של האוזן התיכונה כלומר החזרה מינימלית של צליל למיקרופון.
למצב זה קוראים Type A tympanogram – כשלחץ האוויר באוזן התיכונה הוא נייטרלי.
בלחצי אוויר שליליים או חיוביים בחלל האוזן התיכונה, מרכז האוזן יהיה נוקשה ולא יאפשר מעבר של צליל ביצירת לחץ אוויר נטרלי בתעלת האוזן החיצונית.
בדיקת הטמפנומטריה מזהה גם מצבים פתולוגיים של שמע.
דוגמה למצב שכזה היא דלקת באוזן התיכונה.
הדלקת יוצרת הצטברות של נוזל בחלל התוף.
בבדיקת טמפנומטריה בהתחלת ההיווצרות של דלקת זו, ניתן לראות שההיענות המקסימלית של האוזן התיכונה או לחלופין החזרת הצליל המינימלית למיקרופון, מתרחשת ביצירת לחץ אוויר שלילי בתעלת השמע החיצונית בעזרת המכשיר.
כלומר בשלב זה של הדלקת, לחץ האוויר במרכז האוזן הוא שלילי ולא נייטרלי כמו במצב תקין.
בהתקדמות הדלקת והצטברות משמעותית של נוזל, נקבל החזרת גלי קול רבה בכל לחץ אוויר שנייצר בתעלת השמע החיצונית.
בשל הנוזל הרב שמצטבר באוזן התיכונה, החלל הטימפני נעשה נוקשה ביותר ולא מאפשר מעבר של צליל דרך עור התוף.
לכן בדלקת באוזן התיכונה עשויה להיות פגיעה בשמיעה בשל חוסר הענות.
למצב מתקדם זה קוראים Type B tympanogram, קו יחסית שטוח בגרף המעיד על חוסר הענות בחלל התוף.
פתולוגיה נוספת שבאה לידי ביטוי בבדיקת טמפנומטריה היא טרשת האוזן.
זוהי מחלה שבמהלכה ישנה גדילה לא סדירהשל עצם סביב עצם הארכוף באוזן התיכונה.
גדילה זו גורמת לפגיעה תפקודית של מבנים אחרים באוזן ובסופו של דבר לירידה בשמיעה.
בבדיקת טמפנומטריה של חולה ההיענות המקסימלית של מרכז האוזן תהיה ביצירת לחץ אוויר נייטרלי בתעלת השמע, כמו במצב תקין – Type A tympanogram, אך הפעם מדובר במצב מעט שונה.
ההיענות המקסימלית על אף שתתרחש בלחץ אוויר נייטרלי, תהיה נמוכה יותר מ-Type A ותיקרא – Type As tympanogram.
מצב זה עשוי להעיד על ירידה בשמיעה אצל המטופל.
האוזן התיכונה היא חלל מלא אוויר הממוקם לאחר עור התוף.
לחץ אוויר נייטרלי באוזן התיכונה נשמר הודות לתעלת השמע (תעלת אוסטכיוס), המחברת בין האוזן התיכונה והגרון.
בחלל האוזן התיכונה מצויות שלוש עצמות קטנות, הן עצמות השמע הקרויות: פטיש, סדן וארכובה.
שרשרת עצמות זו יוצרות מנגנון מינוף המעביר את התנודות של האוויר בתעלת האוזן לנוזל שבאוזן הפנימית.
שני שרירים קטנים, הסטפדיוס והטנסור טימפאני המחוברים לעצמות השמע, מתכווצים על ידי רפלקס לא רצוני, כתגובה לקול בעל עוצמה חזקה המגיע לאוזן (החל מ-DB HL85 עד DB HL 100 אצל אדם בעל שמיעה תקינה).
כאשר הם מכווצים, הם מפחיתים את האנרגיה התנודתית המתקבלת באוזן החיצונית לזו העוברת ממנה לאוזן הפנימית, ובכך למעשה מספקים לה הגנה מגלי קול בעלי תדירות נמוכה.
הרפלקס האקוסטי אינו יכול לתת מענה הגנתי כתגובה לגירוי ממושך של קולות חזקים ובהתאם תפקודו יורד, וכן אינו יעיל בתגובה לרעשים עזים ופתאומיים.
באופן תקין, כאשר הרפלקס האקוסטי מגורה באוזן אחת, שרירי הסטפדיוס ו-הטנסור טימפני בשתי האוזניים יכווצו ולמעשה הרפלקס יהיה הן איפסי-לטרלי (שנמצא או שמשפיע על אותו צד בגוף) והן קונטרה-לטרלי (שקורה או משפיע על הצד המנוגד בגוף).
הרפלקס האקוסטי מורכב מגורמים רבים ומכיל מעבר לעצמות ושרירי השמע גם את השבלול, עצב השמיעה, גזע המוח, עצב הפנים, הקומפלקס האוליבארי העליון () וגרעין השבלול.
לפיכך, היעדר רפלקס אקוסטי, כשלעצמו, אינו די מספיק כדי לאבחן באופן חד משמעי את מקור הבעיה.
הבדיקה אשר היא בדרך כלל לא נוחה אך קצרה, נעשית בסיום בדיקת הטימפונומטריה באמצעות אותו מכשיר הטימפונומטר, אשר בודק את תנודות עור התוף על ידי יצירת לחץ ברמות משתנות בתוך תעלות השמע.
היא מורכבת משלושה משתנים שנשלטים על ידי מכשיר הטימפונומטר – לחץ האוויר, רמות לחץ הקול הנובעות ממשרעת גל הקול ותדירות הגל, שמכשיר הטימפונומטר מפיק.
במהלך בדיקת עור התוף, יופעל לחץ קל על עור התוף כדי לקבוע באיזו מידה רוטט עור התוף וכמה אוויר הוא צורך.
הבדיקה כוללת השמעת טונים קצרים על ידי רמקול במכשיר, באורכי גל של Hz226 בעוצמה של DB SPL 70, באופן רציף וקליטה של גלי קול המוחזרים מעור התוף על ידי מיקרופון שנמצא על גבי המכשיר.
נוסף על כך, ברגע מסוים במהלך המבחן יושמע גם צליל חזק על ידי רמקול נוסף, בתדירות Hz 500 או Hz1000 בעוצמת DB HL 85-110 המספיק להפעלת הרפלקס האקוסטי על ידי כיווץ שרירי הסטפדיוס והטנסור טימפני, שגורם לשבריר שנייה של החזרה מוגברת של קול מעור התוף חזרה למיקרופון של מכשיר הטימפונומטר.
אם בתוצאות הבדיקה אכן מזוהה במכשיר הטימפונומטר החזרה מוגברת של קול בעקבות אותה השמעת קול חזק, ניתן להסיק שהרפלקס האקוסטי תקין.
אולם, אם לא מזוהה, ייתכן והרפלקס האקוסטי נפגע.
כמו כן, כאשר נוכח רפלקס גם בתגובה לצלילים בעוצמה נמוכה, ניתן לומר כי קיימת הפרעה בתפקוד המערכת (לדוגמה, בתסמונת טנסור טימפני טוניק).
אם הרפלקס אינו קיים כלל, ייתכן וקיימת ירידה משמעותית בשמיעה אשר מקורה במערכת העצבים.
הבדיקה האיפסי-לטרלית מתבצעת כאשר מכשיר הטימפנומוטר מבצע את כל חלקי הבדיקה (הן הפקת הטונים הקצרים וקליטת הקול המוחזר והן הפקת הקול החזק).
בעבר, אודיולוגים היו מבצעים את שתי הבדיקות הללו כדי לאבחן מצבים פתולוגיים שונים, אולם כיום הודות למכשירי דימות מתקדמים, כדוגמת MRI, ניתן להסתפק רק באחת מצורות הבדיקה ללא הבדל.
בדיקת מענים קוכליאריים (בעבר הדים קוכלארים)
בדיקת מענים קוכליאריים היא בדיקה בעזרתה בודקים את פעילות תאי השיער בתוך השבלול באוזן הפנימית.
מדובר בבדיקה יחסית קצרה ולא מסובכת לביצוע, אך הפיזיולוגיה שמאחוריה אינה פשוטה.
בדיקה זו נקראת גם בדיקת פלט אקוסטי מכיוון שהפלט האקוסטי, הוא צליל שמיוצר באוזן הפנימית ובאופן ספציפי בתאי השיער החיצוניים, וניתן לקלוט אותו על ידי מיקרופון רגיש שנמצא בתעלת השמע.
בעבר, בדיקה זו נקראה הדים קוכליאריים משום שחשבו שהפלט הוא הד, וכי ישנו חלל סגור (האוזן) שמכניסים אליו צליל שחוזר.
אלא שהתכונות הפיזיקליות של ההד, ובכללן זמן החזרה, טווח התדרים ומשך הגירוי, אינן מתקיימות בפלט האקוסטי.
ד"ר תומאס גולד שהיה אסטרופיזיקאי אוסטרי, הביע כבר בשנת 1948 את עמדתו, שכן לא יכול להיות שצליל נכנס לאוזן, ועובר מנגנונים רבים, עדיין מספיק חזק כדי שנשמע אותו.
ד"ר גולד טען, שמוכרח להיות מנגנון שמגביר את הצליל, מנגנון פאסיבי של פידבק, כך שהצליל חוזר על עצמו וגורם להגברה.
ד"ר גולד אמנם לא ידע כיצד התופעה מתרחשת אך שיער כי זאת התוצאה שלה.
פיזיקאי בריטי בשם דייוויד קאמפ, היה הראשון שהצליח בשנת 1978, להוכיח בניסוי את ההשערה שהעלה ד"ר גולד.
הוא הראשון ששם מיקרופון בתעלת השמע וקלט את הפלט, מה שיצר את ההבנה שיש מנגנון אקטיבי שמייצר צליל.
דייוויד קאמפ הצליח להוכיח, כי פליטות אוטו-אקוסטיות, נוצרות באמצעות מספר גורמים תאיים ומכניים שונים, בתוך האוזן הפנימית.
בדיקת מענים קוכליאריים, היא בדיקה מהירה, המשמשת לעיתים קרובות כבדיקת סקר ליילודים או אצל מבוגרים, שאינם מסוגלים לשתף פעולה, זאת משום שהבדיקה אינה גורמת לכאבים וניתן לבצעה, על מטופל ישן ואפילו מחוסר הכרה, כי אין צורך בשום תגובה התנהגותית.
במהלך הבדיקה, מחדירים מתמר זעיר לתעלת האוזן.
המתמר משדר קול וקולט בעזרת מיקרופון את ההחזר שלו –OAE .
מקובל להניח כי מקור ה-OAE הוא בתאי השיער החיצוניים בשבלול, אשר מתכווצים ומשתחררים שכן התכווצותם מגדילה את תנועת הממברנה בשבלול, ויוצרת גל שחוזר לאוזן התיכונה, ומשם דרך עור התוף לתעלת השמע החיצונית, שבה ניתן למדוד את המענים הקוכליאריים.
לכן, הגל שעובר בקוכליאה נקרא גל נוסע.
הגל מתקדם לאורך הממברנה הבזלית, תאי השערה החיצוניים יוצרים אפקט הגברה שמחדד את הגל שעובר.
כך שהם יוצרים המשכיות של הגל לאורך הממברנה, מהחלק הבזאלי לחלק האפיקלי.
אבל, התנועה שעולה ויורדת, יוצרת גם גל חוזר לכיוון השני.
רוב האנרגיה הוא בכיוון הגל הנע, אבל יש תנועה כלשהי גם אחורנית - החזר שניתן למדוד.
במהלך הבדיקה נוצרים 4 קולות לבדיקה:
1. SOAEs – הוא הד ספונטני שייווצר ללא גירוי חיצוני.
נוכחות של SOAES מסמלת שמיעה תקינה, אך אי נוכחות לא בהכרח תעיד על פגיעה בשמיעה, מכיוון שהיא קיימת רק ל־40%-50% אנשים, בקבוצת השמיעה התקינה.
2. TOAEs – הוא פלט הנוצר כתגובה לגירוי מאוד קצר "מעין קליקים".
מרבית הקלינאים משתמשים בנוכחות TOAE.
רגישות השמיעה צריכה להיות 30 dB HL ומעלה, אלא אם כן קיים מרכיב תפקודי או עצבי.
3. DPOAEs – פלט שנוצר מגירוי של שני צלילים שקרובים בתדר שלהם ונשמעים בו זמנית אלו מאפשרים ספציפיות גבוהה יותר לתדר, ומשמש להקלטה בתדרים גבוהים יותר מ-TOAEs.
לכן DPOAEs עשויים להיות שימושיים במיוחד, לגילוי מוקדם של נזק לשבלול.
4. SFOAEs – הוא פלט שנוצר כתוצאה מגירוי מתמשך שיוצר טון רציף.
זאת מכיוון שהגירוי והפליטה, חופפים בתעלת האוזן, ההקלטה של המיקרופון מזהה את שניהם כך שSFOAE אינם משמשים אותנו קלינית.
בבדיקת ABR (auditory brainstem responses) הנקראת גם BERA (brainstem evoked responses) מודדים ועוקבים אחר הפעילות המוחית, או באופן ממוקד יותר את פעילות העצב השמיני במספר שלבים מהעצב הפריפרי לקורטקס כתגובה לגירויי שמע חיצוניים הנקראים "auditory evoked potentials" ובקיצור EP.
בתגובה לגירוי אקוסטי, נוצרים אותות חשמליים על ידי מערכת השמיעה המרכזית והפריפרית.
סיגנלים אלו מגיעים ממספר גדול של נוירונים בעצב השמיעה ובגזע המוח ונקלטים על ידי אלקטרודות המונחות על קרקפת ותנוכי האוזניים.
באמצעות המכשיר ניתן לרשום את הפעילות המוחית הנגרמת בקורטקס לאחר גירוי שמיעתי.
התגובות מחולקות לשלושה סוגים ומסייעות בבדיקות ואבחנות שונות:
תגובות מוקדמות (early responses) – אלו התגובות רלוונטיות לנו לבדיקת ה-ABR, תגובות המתקבלות במוח לאחר פחות מ־10 מילישניות.
תגובות אמצעיות חבויות (midde-laency responses) תגובות בין 10–15 מילישניות, להן בקושי שיש שימוש קליני.
תגובות מאוחרות (late responses) תגובות המתקבלות בקורטקס לאחר 15 מילישניות, מתארות למשל את תשומת הלב של המטופל.
בדיקת "מעבדת מחקר למחלות מין" היא בדיקת דם לאיתור עגבת וטרפונמטוזיס שאיננו קשור למחלות מין (Treponematosis הוא מונח המשמש לתיאור אינדיבידואלי של כל אחת מהמחלות הנגרמות על ידי ארבעה חברים מהסוג של חיידקי טרפונמה פאלידום.
ארבע המחלות מכונות ביחד טרפונמטוזות).
הבדיקה שפותחה על ידי המעבדה האמריקאית המכונה בשם זה.
בדיקת VDRL משמשת לבדיקת שלב העגבת (יש לה רגישות גבוהה), בעוד שבדיקות אחרות וספציפיות יותר משמשות לאבחון המחלה.
מבחן VDRL הומצא לפני מלחמת העולם הראשונה, כשהגרסה הראשונה שלו הייתה זו שפותחה על ידי אוגוסט פון וסרמן בסיועו של אלברט נייסר ב-1906. מבחן VDRL, כפי שהוא נעשה ברובו עד היום, פותח ב-1946 על ידי האריס, רוזנברג ורידל (Harris, Rosenberg, and Riedel).
שם המעבדה שונה מאז ל- Treponemal Pathogenesis and Immunology Branch של שירות הבריאות הציבורי של ארצות הברית.
ה-VDRL הוא סקר סרולוגי לא-טרפונמאלי לאיתור עגבת המשמש גם להערכת התגובה לטיפול, לזיהוי מעורבות מערכת העצבים המרכזית וכסיוע באבחון של עגבת מולדת.
בסיס הבדיקה הוא שנוגדן המיוצר על ידי חולה עם עגבת מגיב לתמצית המופקת מלב שור (דיפוספטידיל גליצרול - diphosphatidyl glycerol).
לכן הוא מזהה נוגדני אנטי-קרדיוליפין (IgG, IgM או IgA), המוצגים באמצעות הקצף של נוזל המבחנה או ה"הפתתה" (הפתתה - מלשון פתית - היא תהליך הפיכת המים לצלולים, כלומר הסרת עכירות וצבע.
שלב זה נעשה באמצעות הוספת חומרים שיגרמו להגדלת המוצקים על ידי התלכדות חלקיקים לפתית גדול יותר ויצירת משקע שניתן להסיר אחר כך בסינון.
מבחן הפלזמה המהירה (RPR) משתמש באותו אנטיגן כמו ה-VDRL, אך בבדיקה זו, הוא נקשר למספר מולקולות אחרות, כולל חלקיק פחמן, כדי לאפשר הדמיה של תגובת ההפתתה ללא צורך במיקרוסקופ.
מצבים רפואיים רבים אחרים יכולים להניב תוצאות חיוביות שגויות, כולל וירוסים מסוימים (מונונוקלוזיס, הפטיטיס), תרופות, הריון, קדחת שגרונית, דלקת מפרקים שגרונית, זאבת וצרעת.
נוגדני העגבת האנטי-קרדיוליפין אינם תלויים ב- Beta-2 גליקופרוטאין (Apolipoprotein H), ואילו אלו המופיעים בתסמונת אנטי-פוספוליפידית (הקשורה לזאבת למשל) תלויים ב-Beta-2 גליקופרוטאין וניתן להשתמש בזה כדי להבדיל ביניהם בבדיקת ELISA.
בדיקה זו שימושית מאוד מכיוון שמגמת הכיל נמצאת בקורלציה לפעילות המחלה (כלומר ירידה בכיל מעידה על טיפול מוצלח).
יש לו רגישות טובה מאוד לעגבת, למעט בצורה השלישונית המאוחרת.
ישנן מספר בדיקות ספציפיות טרפונמל כגון בדיקת קליטת נוגדני טרפונמל פלואורסצנטי (FTA-ABS), מבחני TPHA (Treponema pallidum particle agglutination assay), ומבחן מיקרו-המגלוטינציה (MHA-TP).
מבחן ה-MHA-TP משמש לאישור זיהום עגבת לאחר שמבחן בשיטה אחרת חיובי לחיידקי העגבת.
בדיקת MHA-TP מאתרת נוגדנים לחיידקים הגורמים לעגבת וניתן להשתמש בה לאיתור עגבת בכל השלבים, למעט במהלך 3 עד 4 השבועות הראשונים מההדבקה.
בדיקה זו אינה נעשית על נוזל עמוד השדרה.
מבחן MHA-TP משמש היום לעיתים רחוקות.
למרבה הצער, זיהומים טרפונמלים אחרים כגון פטלת, בג'ל ופינטה ואולי "טרפונמות קומנסליות לא פתוגניות" עלולות לגרום לתוצאה חיובית.
לא כל המחלות הללו הן מחלות מין, על כן הומלץ למעבדות לכלול הסבר זהיר של עובדה זו עם תוצאות הבדיקה.
בדיקות תאימות (Compatibility testing) הן חלק מבדיקות לא פונקציונליות הנערכות על תוכנה במטרה לוודא את תקינות פעילותה בסביבות מחשוב שונות.