בדיקות פונקציונליות של 1C-Bitrix: היכן האתר נשבר
בדיקות פונקציונליות של 1C-Bitrix מתחילות לא בבדיקת ה-HTML, אלא בתרחישים עסקיים שבהם טעות עולה ביוקר: ביצוע הזמנה, סנכרון עם 1С, חלוקת הרשאות, אינטגרציות חיצוניות. המקומות האלה נשברים בשקט — הדף נפתח, הכפתורים נלחצים, אבל בצד הלקוח כבר הולכות לאיבוד הזמנות ומלאי לא מתאים.
סל הקניות הוא נקודת כשל קלאסית. המוצר מתווסף, אבל בחישוב מחדש של הנחה או בשינוי אמצעי המשלוח הסכום מחושב לא נכון; קוד קופון מוחל על פריט אחד במקום על כל הסל; בהזמנות מקבילות נגרע מלאי עודף. הלקוח רואה שגיאה באתר ברגע התשלום — והולך, במקום לדווח עליה.
הסנכרון עם 1С נשבר בלי שהחנות שמה לב: מחירים ומלאי מפסיקים להתעדכן, הזמנות לא מיוצאות למערכת החשבונאית, נומנקלטורה ומחסנים לא מתאימים. השגיאה מצטברת ימים שלמים, עד שהמנהל בודק את הנתונים ידנית.
הרשאות גישה — אזור הסיכון השלישי: אורח רואה מחירים לסיטונאים, מנהל אזור מקבל גישה לבסיס של מישהו אחר, ומדור למשתמשים מאומתים פתוח בקישור ישיר.
אינטגרציות עם תשלומים, שירותי משלוח ושירותים חיצוניים מוסיפים תקלות משלהן: התשלום עובר, אבל סטטוס ההזמנה לא משתנה; חישוב המשלוח מחזיר תשובה ריקה לכתובת לא סטנדרטית. כל קרע כזה — עבודה ידנית של התמיכה, החזרים ואובדן אמון. בואו נבחן כיצד לזהות את נקודות הכשל האלה לפני שהלקוחות ימצאו אותן.
מה נותנת הבדיקה: אפקט מדיד לעסק
בדיקות פונקציונליות של 1C-Bitrix עונות על שאלה אחת: מה בדיוק נשבר אצל המשתמש לאחר השינוי האחרון. מערך הרגרסיה מורץ בכל גרסה ומכסה תרחישים טיפוסיים — ביצוע הזמנה, תשלום, הרשמה, ייצוא קטלוג, סנכרון עם 1C.
שגיאות שבעבר צפו בפרודקשן יום-יומיים לאחר העלאה, נתפסות לפני הפרסום, ולכן זרימת הפניות לתמיכה יורדת באופן צפוי: מספר הטיקטים פוחת פי כמה, ולא באחוזים בודדים.
קצב שחרור השינויים עולה לא בזכות "כותבים קוד מהר יותר", אלא בזכות הפחד מהעלאה שהוסר.
כאשר קיימות בדיקות אוטומטיות בנתיבים קריטיים ופרוטוקול חזרה לאחור ברור, גרסאות יוצאות בתדירות גבוהה יותר ובגודל קטן יותר — תיקונים בתבניות, בקומפוננטות, בכללי הסנכרון עם 1C מפסיקים להיות אירוע של יום שלם.
הצוות לא מבזבז זמן על מעבר ידני על אותם תרחישים שוב ושוב, והתמיכה עוסקת בפיתוח ולא בפתרון תקלות זהות.
אפקט נפרד — היעלמותן של מחלקות שלמות של כשלים. בדיקות שלמות נתונים בסנכרון עם 1C מסירות אי-סנכרון של מלאי ומחירים; בדיקות סל ותשלום — הזמנות תקועות ותשלומים שאבדו; בקרת הרשאות גישה — דליפות דרך אזורים פתוחים.
זה לא "נהיה קצת יותר אמין", אלא פרופיל תפעול שונה: יציבות האתר מפסיקה להיות תלויה בשאלה מי בדיוק העלה את הגרסה ובאיזו משמרת.
בפועל זה נראה במטריקות: שיעור התקלות שנתגלו על ידי משתמשים יורד, הזמן הממוצע בין גרסאות מתקצר, והזמן לפתרון פנייה בודדת יורד, כי הסיבה כבר אותרה על ידי הבדיקה. נבחן כיצד מתאר בדיקות כזה נבנה עבור אתר ספציפי והאינטגרציות שלו עם 1C.
מצבי בדיקה: ריצה ידנית, בדיקות אוטומטיות, רגרסיה
שלושת המצבים אינם מחליפים זה את זה אלא משלימים זה את זה: בדיקה ידנית תופסת את מה שלא ניתן לתאר בתרחיש פורמלי, בדיקות אוטומטיות שומרות על יציבות לאורך זמן, ובדיקות רגרסיה מגנות על תרחישים שכבר עובדים מפני שינויים חדשים. הבחירה תלויה במה שמשתנה בגרסה ובמחיר הטעות באזור מסוים.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| בדיקה ידנית | תרחישים חדשים, עיצוב, טפסים, תשלום, אינטגרציות עם 1С | יקר לחזור עליה, תלויה בקשב של הבודק |
| בדיקות אוטומטיות | תרחישים יציבים: אימות, סל קניות, ביצוע הזמנה, החלפת נתונים | דורשות תחזוקה בעת שינוי עיצוב ולוגיקה |
| בדיקות רגרסיה | לפני כל גרסה ואחרי שינויים בליבה | ריצה מלאה אורכת זמן, נדרש תיעדוף |
| בדיקות עשן | אחרי פריסה ועדכונים | מכסות רק את המסלול הקריטי, אינן מחליפות ריצה מלאה |
כיצד בוחרים מצב לפי המשימה
אם הגרסה נוגעת בלוגיקה עסקית — תשלום, אזור אישי, החלפה עם 1С — תחילה ריצה ידנית של תרחישים חדשים, לאחר מכן עיגונם בבדיקות אוטומטיות. כך הבדיקה אינה הולכת לאיבוד עם השינוי הבא: התרחיש מתואר פעם אחת ומכאן ואילך מבוצע ללא אדם.
לעדכונים שוטפים של הליבה והמודולים מספיקה רגרסיה במסלולים מתועדפים ובדיקות עשן לאחר ההעלאה. ריצה מלאה של כל התרחישים בכל גרסה אינה מוצדקת — בוחרים את אלה שנוגעים בקוד שהשתנה.
מה נותן השילוב של המצבים
בדיקה ידנית חושפת פגמים שבדיקות אוטומטיות מפספסות: טקסטים שגויים, עיצוב מוסט, מעברים לא הגיוניים. בדיקות אוטומטיות מקבעות את התוצאה ומסירות את הגורם האנושי בשלבים חוזרים.
בדיקות רגרסיה מכסות את הסיכון העיקרי — "תיקנו אחד, שברנו אחר". בדיקות עשן נותנות ביטחון מהיר שהאתר חי אחרי הפריסה, ומאפשרות להחזיר את הגרסה לאחור לפני שהלקוח יראה את הבעיה.
איך מתבצעת הבדיקה: שלבי העבודה ההנדסית
הבדיקה אינה מתחילה בהרצת בדיקות, אלא במלאי: אילו רכיבים ומודולים מעורבים, היכן נמצא המטמון, אילו אינטגרציות עם 1С ושירותים חיצוניים, אילו תרחישים קריטיים לעסק. בלי זה תוכנית הבדיקות יוצאת פורמלית — מכסה את מה שקל לבדוק, ולא את מה שנשבר בפרודקשן. לכן השלב הראשון תמיד מניב מפת מערכת ורשימת סיכונים, ולא דוח על מספר ההרצות.
לאחר מכן בונים רצף כך שכל שלב נשען על התוצאה של השלב הקודם.
- ביקורת האתר — מפרקים את המבנה, גרסאות הליבה והמודולים, היסטוריית העריכות, השגיאות הנוכחיות בלוגים. מתעדים מה כבר עובד בצורה לא יציבה: אלו נקודות הכשל העתידיות.
- תוכנית הבדיקות — מתארים אילו מסלולים מכסים, אילו תרחישים נחשבים קריטיים, מה בודקים ידנית ומה מבצעים אוטומציה. מתאמים סדרי עדיפויות: קודם כל מה שמשפיע ישירות על הזמנות ונתונים.
- הגדרת הסביבה — מרימים עותק קרוב ככל האפשר לפרודקשן: אותן גרסאות, אותן הגדרות מטמון ותורים, אותה בסיס 1С. בדיקה על בנייה "נקייה" תופסת בעיות שלא קיימות ומפספסת בעיות אמיתיות.
- הרצת הבדיקות — בדיקות פונקציונליות של 1C-Битрикс מתבצעות לפי התרחישים המתואמים: ביצוע הזמנה, סנכרון עם 1С, הרשאות גישה, טפסים, אינטגרציות. כל כשל מתועד עם צעדי שחזור, ולא רק "לא עובד".
- ניתוח ותעדוף — מחלקים את מה שנמצא לחוסמים, קריטי וקוסמטי. חוסמים מתקנים מיד, את השאר — עם הערכה וסדר עדיפויות.
- הרצה חוזרת — מאשרים שהתיקונים לא שברו תרחישים סמוכים. רגרסיה כאן זולה יותר מאשר rollback בפרודקשן.
- מסירת התוצאות — דוח עם צעדים לשחזור, רשימת מה שתוקן, הסיכונים שנותרו והמלצות לניטור.
רצף כזה מניב תוצאה צפויה: עד moment ההעלאה לצוות יש לא "כאילו בדקנו הכל", אלא רשימת מסלולים מכוסים ואזורים שנקראו במפורש ונשארו מחוץ לבדיקה. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית בדיקה המותאמת לקונטור שלכם.
מה נשאר בידיים: ארטיפקטים ותקנונים
הבדיקה לא מסתיימת בפסיקת "עובד". התוצאה שלה היא סט של ארטיפקטים, שלפיהם צוות הלקוח ממשיך להוציא גרסאות ולקבל שינויים בלעדינו. כל מסמך סוגר סוג אחר של שגיאות, ולכן הרשימה קבועה.
- מקרי בדיקה לתרחישים קריטיים: ביצוע הזמנה, תשלום, הרשמה, אינטגרציה עם 1С, ייצוא קטלוג. כל שלב עם תוצאה צפויה וסימון האם הפגם משוחזר שוב.
- דוח בדיקה: מה נבדק, באיזו סביבה, אילו פגמים נמצאו, מה תוקן, מה נשאר עם סימון עדיפות. בלי "הכול טוב" — עם הצמדה לעמודים ולתרחישים ספציפיים.
- מפת סיכונים: נקודות תורפה שלא נשברות כרגע, אבל ייכשלו עם גידול בעומס או עדכון הליבה — שאילתות כבדות לקטלוג, סנכרון עם 1С לפי לוח זמנים, מטמון רכיבים.
- תקנון גרסה: סדר ההעלאה, בדיקות חובה לפני פרסום, נקודות חזרה לאחור, מי מאשר את השחרור. הכלל "קודם לסביבת בדיקה, אחר כך לפרודקשן" מפסיק להישען על הזיכרון של מהנדס אחד.
- צ'ק-ליסט קבלה: רשימה קצרה של 10-15 סעיפים, שעובר מנהל או מנהל פרויקט לפני מסירת משימה — טפסים נשלחים, מיילים מגיעים, תשלום עובר, הגרסה הישנה של העמוד נפתחת.
- ניטור מוגדר: התראות על נפילת האתר, שגיאות בלוגים, אי-זמינות של חילופי נתונים עם 1С. התקלה נתפסת לפני שהלקוח מתקשר, ולא אחרי.
- גיבויים ובדיקת שחזור: לוח זמנים, תקופת שמירה, היכן נמצאים הגיבויים ואיך פורסים אותם בסביבה נקייה. גיבוי שמעולם לא שוחזר אינו נחשב לגיבוי.
- הרשאות ותיעוד: חשבונות עם תפקידים, תרשים סביבות, הוראות לפעולות טיפוסיות — עדכון תוכן, הוספת מדור, עריכת מחירים.
הסט נשאר אצל הלקוח ואינו קשור אלינו: קבלן חדש או מפתח במשרה מלאה נכנס לפרויקט לפי המסמכים האלה, ולא משחזר את הלוגיקה לפי הקוד. תקנון הגרסה וצ'ק-ליסט הקבלה בדרך כלל שורדים כמה חילופי צוות — דווקא הם שומרים על האיכות כשהבדיקה כבר מזמן מאחור.
מקרה בוחן: כיצד בדיקה הסירה תקלות בסנכרון עם 1С
הלקוח — חברת סיטונאות עם חנות מקוונת על 1С-Битрикс וסנכרון קטלוג, מחירים ומלאי עם מערכת הנה"ח. הסנכרון הופעל לפי לוח זמנים, אך נכשל באופן קבוע: חלק מהמוצרים לא התעדכנו, המחירים סטו מהמציאות, והמנהלים תיקנו פריטים ידנית. שגיאות הסנכרון צצו כבר אצל הקונים — בדמות סירובים בעת ביצוע הזמנה ופניות לתמיכה.
מה היה לפני הבדיקה
התחלנו בבדיקות פונקציונליות של הסנכרון: הרצנו מחזור סנכרון מלא בסביבת בדיקה, ניתחנו את היומנים ושחזרנו תרחישים שבשגרה עברו "במזל". זיהינו תקלות מצטברות — מכפילויות של פריטים ועד לקטיעות באמצע החבילה, כאשר חלק מהנתונים נכתב וחלק לא.
בנפרד בדקנו את ההתנהגות בהרצה חוזרת: ללא טיפול נכון, הרצה חוזרת של הסנכרון הרביתה שגיאות במקום לתקן אותן.
מה שינו
כתבנו מחדש את לוגיקת הסנכרון עם עיבוד אידמפוטנטי — הרצה חוזרת כעת בטוחה ואינה יוצרת כפילויות. הוספנו בדיקת שלמות החבילה לפני הכתיבה והתראות ברורות בעת אי-התאמה, כך שתקלה נראית מיד ולא אחרי יממה.
הגדרנו הפעלה מחדש אוטומטית של משימות שנכשלו והפרדנו הרשאות כתיבה, כדי שתיקונים ידניים לא יתנגשו עם הסנכרון.
מה השתנה
מספר הפניות לתמיכה בנוגע לסטיות במחירים ובמלאי הצטמצם פי חמישה בקירוב. זמן ההשבתה של הסנכרון בעת תקלה ירד מכמה שעות לדקות — המשימה עולה מעצמה, ללא מעורבות מהנדס.
שיעור המחזורים המוצלחים של הסנכרון עלה לערכים יציבים, ותיקונים ידניים של הקטלוג כמעט נעלמו משגרת העבודה היומיומית של המנהלים.
במה שונה בדיקה לפני שחרור מ־רגרסיה שוטפת?
בדיקה לפני שחרור עונה על שאלה אחת: האם אפשר להעלות את הבילד הזה היום. המהנדסים מריצים תרחישים קריטיים — ביצוע הזמנה, תשלום, אימות, ייצוא קטלוג, סנכרון עם 1С — על אותה קבוצת נתונים כמו בפרודקשן. המטרה — לתפוס רגרסיה שנגרמה משינוי מסוים, ולא להחמיץ אותה אל הלקוחות. הרצה כזו היא חד־פעמית: היא קשורה לתאריך ההעלאה ונסגרת יחד עם השחרור.
רגרסיה היא לא פעולה חד־פעמית, אלא קו מתאר קבוע של איכות. היא מתקיימת ללא תלות בשחרורים: מערך הבדיקות קבוע, מבוצע לפי לוח זמנים ואחרי כל שינוי בקוד, בקונפיגורציה או בצד 1С.
המשמעות היא שהמערכת משתנה לא רק כשנוגעים בה: מתעדכן ליבת הפלטפורמה, מגיעות גרסאות חדשות של מודולים, הספק משנה את הייצוא, מתעדכנת 1С עצמה. כל אחד מהאירועים האלה יכול לשבור תרחיש שעבד אתמול.
ההבדל מתבטא בתדירות ובכיסוי. לפני שחרור בודקים את מה שנפגע מהתיקון — במהירות ובאופן ממוקד. רגרסיה מריצה את כל המסלול הקריטי במלואו, כולל אינטגרציות ומשימות רקע, ועושה זאת באופן קבוע, ולא מזדמן.
בדיוק משום כך רגרסיה תופסת דעיכה שבדיקה חד־פעמית פיזית לא תראה: אי־התאמה ביתרות לאחר סנכרון, פסקי זמן בייצוא, שגיאות בהודעות ובדיווחים.
המסקנה המעשית פשוטה: בדיקה חד־פעמית מפחיתה את הסיכון של שחרור מסוים, וקו מתאר קבוע של איכות מפחית את הסיכון של המערכת כולה. הראשון בלי השני מותיר אזורים עיוורים בין ההעלאות — ובדיוק שם בדרך כלל צצות בעיות שהלקוח לומד עליהן לפני הצוות.
ספקות טכניים נפוצים של לקוחות
לפני תחילת העבודה כמעט תמיד עולים אותם שאלות — לגבי עומס, הרשאות גישה, אינטגרציות ותאימות למה שכבר עובד. להלן התשובות כפי שאנו נותנים אותן בפגישות טכניות.
האם האתר יעמוד בעומס שיא לאחר השיפורים?
אנחנו לא מנחשים: לפני השחרור אנו מריצים בדיקות עומס על תרחישים שמשחזרים תעבורה אמיתית — תוך התחשבות במטמון, סשנים ופניות לבסיס הנתונים. אנו בוחנים לא את זמן התגובה הממוצע, אלא את ההתנהגות בשיא ואת הנקודה שבה המערכת מתחילה להתדרדר. אם מרווח הביטחון קטן מהנדרש, אנו מייעלים שאילתות ומטמון לפני הפרסום, ולא אחרי תקלה.
אילו הרשאות גישה אתם צריכים ועד כמה זה מאובטח?
נדרשת גישה לסביבת הפיתוח ולסביבת הבדיקות, ולסביבת הייצור — רק בזמן הפרסום. אנו עובדים דרך חשבונות נפרדים עם הרשאות מוגבלות, ללא סיסמת מנהל משותפת. כל הפעולות מתועדות ביומנים, הגישה נשללת עם סיום השלב — אתם רואים בכל רגע מי עשה מה.
האם האינטגרציות הקיימות יישברו?
תחילה אנו עורכים מלאי של כל מה שמחליף נתונים עם האתר: מחסן, תשלום, משלוח, CRM, שירותים חיצוניים. עבור כל אינטגרציה אנו בודקים את פורמט ההחלפה, טיפול בשגיאות והתנהגות כאשר הצד החיצוני אינו זמין. אנו מפרסמים שינויים כך שקראות ישנות וחדשות יעבדו במקביל — אז החזרה לאחור לא קורעת את הקשרים.
האם זה תואם לתשתית שלנו ולגרסת הפלטפורמה?
לפני ההערכה אנו משווים את הדרישות לסביבה שלכם: גרסת הליבה, תצורת השרת, סביבת בסיס הנתונים, המודולים המותקנים. אם העדכון הכרחי, אנו מתכננים אותו כשלב נפרד עם בדיקה על עותק של סביבת הייצור. כך אתם רואים את המגבלות האמיתיות לפני תחילת העבודה, ולא ברגע הפרסום.
מה אם אחרי השחרור משהו ישתבש?
אנו שומרים נקודת חזרה: גיבוי של בסיס הנתונים והקבצים לפני הפרסום, ניהול גרסאות של השינויים. אם לאחר השחרור מופיעה סטייה, אנו חוזרים למצב הקודם תוך דקות, ואת הסיבה מנתחים על עותק. זהו חלק סטנדרטי מהנהלים, ולא שירות נפרד.
תארו את המשימה שלכם ואת הסביבה הנוכחית — נחזור עם הערכה, תוכנית בדיקות ורשימת הרשאות הגישה הנדרשות.
נדון במשימה: נחזור עם הערכה ותוכנית
הבדיקה מתחילה בניתוח המצב הנוכחי: אילו מודולים ורכיבים מעורבים, כיצד בנויים התבניות, היכן נשמרים הנתונים, אילו אינטגרציות עם 1С כבר פועלות. בלי זה לא תהיה תוכנית — בדיקות פונקציונליות של 1C-Битрикс נבנות סביב קונפיגורציה ספציפית של הפרויקט, ולא לפי רשימת בדיקה כללית.
תארו את המשימה בצורה חופשית: מה מטריד כעת, מה השתנה לאחרונה, אילו תרחישי לקוחות נשברים לרוב. זה מספיק כדי לחזור עם הערכה ותוכנית בדיקה.
בהמשך אנו מקבעים את היקף העבודה והמועדים, מתאמים סדרי עדיפויות ורק לאחר מכן יוצאים לבדיקה. התוכנית כוללת:
- מלאי של רכיבים, מודולים והתאמות מותאמות אישית עם הערכת סיכון;
- בדיקת תרחישי משתמש: הזמנה, תשלום, הרשמה, אזור אישי, טפסים;
- בדיקת חילופי נתונים עם 1С — ייצוא, סנכרון מלאי, מחירים, יתרות, הזמנות;
- בדיקת הרשאות גישה ותפקידים: מה רואה אורח, מנהל, אדמיניסטרטור;
- הרצה בדפדפנים ובמכשירים, כולל תרחישים ניידים;
- בדיקת עומסים של עמודים מרכזיים ונקודות כניסה;
- דוח עם רשימת ליקויים, סדרי העדיפויות שלהם והמלצות לתיקון.
בסיום אתם מקבלים לא "הכול עובד" מופשט, אלא רשימה של מקומות קונקרטיים שבהם התנהגות המערכת סוטה מהמצופה, עם ציון שלבי שחזור. זה מאפשר לתכנן התאמות לפי המצב בפועל, ולא לפי השערות.
ספרו מה קורה עם האתר כעת ואיזו תוצאה נדרשת — נחזור עם הערכה, תוכנית בדיקה ומועדים.