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

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

פיתוח מבוסס-בדיקה

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

אינטגרציה רציפה ובדיקות אוטומטיות

בבדיקות של אינטגרציה רציפה (CI) תתבצע באופן אוטומטי בדיקות נגד שינויים בקוד, למשל במהלך בדיקות קוד או מיזוג קוד עם מאגר הקודים. בדיקות אוטומטיות משפרות את האיכות הכוללת ואת המהימנות של הקוד שנשלח, כי הן מפחיתות את הסיכון להפסקות או רגרסיות במהלך הפיתוח. מומלץ להגדיר מערכת בדיקה אוטומטית לסביבה כדי לוודא את תקינות האפליקציה. כדאי להשתמש במערכת שנתמכת על ידי הארכיטקטורה, הפלטפורמה והשפה שמשולבת בצורה חלקה בצינור עיבוד הנתונים של הפיתוח. לדוגמה, תוכלו להשתמש ב-GitHub Actions for a CI workflow או בצינור עיבוד נתונים של CI מובנה בענן, שמותאם אישית להגדרות שלכם.

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

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

בדיקת יחידה

בדיקת יחידות: בדיקה של חלקים קטנים של קוד בבידוד. השתמשו במסגרת של בדיקת יחידה שמומלצת ופופולרית עבור השפה או ה-framework של הקצה העורפי שלכם. לדוגמה, לאפליקציה מונוליתית מבוססת Java, צריך להשתמש ב-JUnit, או באפליקציה מבוססת-JavaScript ללא שרת (כולל Dart או TypeScript), צריך להשתמש במסגרת שמיועדת לבדיקת JavaScript, כמו Jest.

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

בדיקות שילוב

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

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

בדיקות של התנהגות ופונקציונליות

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

בדיקת רגרסיה

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

בדיקת עשן

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

סביבות ייצור ו-Staging

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

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

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

צריך להביא בחשבון את קנה המידה של המערכת ולבדוק אם סביבה עומדת מתאימה לאפליקציה שלכם. סביבות ביצוע ראשוניות שאפשר לפרוס באופן אוטומטי באמצעות מערכת פיתוח רציף (continuous delivery) מציעות גם הזדמנויות נוספות לבדוק גרסאות build יומיות או שבועיות ולתת להן בדיקה נוספת לפני ההשקה.

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