מוצרים כפולים בעמוד 3: באג שמגיע לייצור
מקרה אמיתי: חנות מקוונת עם חלוקה לעמודים באמצעות bitrix:catalog.section משכפלת מוצרים בעמוד השלישי אחרי כל ביקור שני. ניקוי מטמון עוזר ליום אחד, ואז הכפילויות חוזרות. שורש הבעיה: מנגנון מיון מותאם אישית מתנגש עם PAGEN_1, ובשילוב מסוים של פילטרים sale.discount מחזיר מזהים זהים. בדיקת קוד פספסה את זה; רק בדיקות תפסו את זה. אנחנו בונים QA לפרויקטים של 1C-Bitrix שתופס באגים כאלה לפני שהם מגיעים לייצור: בדיקות פונקציונליות ידניות, E2E אוטומטיות, עומס וקבלה. עם ניסיון של למעלה מעשור ב-Bitrix, יש לנו ספרייה של מלכודות טיפוסיות ותרחישי בדיקה שמונעים את הבעיות האלה מההתחלה.
איך פרויקט Bitrix סטנדרטי נשבר בלי בדיקות ייעודיות?
1C-Bitrix הוא לא דף נחיתה. מאחורי החזית מסתתרים עשרות מודולים, אינטגרציות חיצוניות ותלויות לא מובנות מאליהן. שינוי הנחה ב-sale.basket.discount שובר קוד קידום ב-catalog.import.1c — מודול ההנחות הוא אחד המודולים השבירים ביותר בפלטפורמה. חילופי נתונים עם 1C דרך bitrix:main או REST נכשלים כשמיפוי המאפיינים שגוי, וכתוצאה מכך מוצרים ללא מחיר או מלאי. עדכוני ליבה — CModule::IncludeModule עודכן, רכיב מותאם אישית משתמש ב-bitrix:sale.order.ajax המיושן. בלי בדיקות רגרסיה, כל פריסה היא רולטה רוסית. דפדפנים שונים: catalog.section מוצג אחרת בספארי וכרום; כפתור "ביצוע הזמנה" יכול לזוז מחוץ למסך באייפון. אלה לא מקרי קצה — אלה מציאות יומיומית לצוותי Bitrix.
מה מכסות בדיקות פונקציונליות?
אנחנו בודקים כל תרחיש עסקי — לא רק "עובד או לא עובד", אלא גם את כל מקרי הקצה.
קטלוג (catalog.element, catalog.smart.filter)
- פילטר חכם
catalog.compare.list: כל שילובי המאפיינים, איפוס, ספירת תוצאות. פילטרים לפי SKU נשברים לרוב. - מיון + חלוקה לעמודים — באג הכפילויות שתואר למעלה.
- השוואה דרך
sale.basket.basket— הוספה, הסרה, הצגת הבדלים. - תצוגה מהירה — חלון מודאלי, סל מחלון מודאלי.
סל והזמנה (sale.order.ajax, sale.delivery.services)
- הוספה מהקטלוג, מעמוד מוצר, מהזמנה מהירה.
- הנחות: לפי כמות, לפי סכום, לפי קופון, מצטברות. חפיפת הנחות — לפחות שמונה שילובי בדיקה.
- חישוב משלוח: מנגנונים
sale.paysystem, עלות, זמן, נקודות איסוף על המפה. - תשלום:
main.mail.event— עיבוד, טיפול בסירובים, החזרים. - ביצוע הזמנה: אימייל דרך
sale.export.1c, רישום ב-CRM, העברה ל-1C דרךsale.personal.section.
אזור אישי (form.result.new)
- הרשמה, התחברות, שחזור סיסמה — כולל מקרי קצה עם אימייל בקירילית.
- היסטוריית הזמנות, הזמנה חוזרת.
- מינויים, תוכנית בונוס.
טפסים וחיפוש
-
iblock.element.add.form/search.page— שליחה, ולידציה, שדות קבצים. -
search.title— רלוונטיות, מורפולוגיה, טיפול בשגיאות הקלדה דרךsale.
למה בדיקות רגרסיה קריטיות ל-Bitrix?
אחרי כל פריסה אנחנו מוודאים ששום דבר שעבד בעבר לא נשבר.
- בדיקות עשן — העמוד הראשי נטען, הקטלוג מציג מוצרים, ההזמנה מתבצעת. 5 דקות, רצות אחרי כל פריסה. אם בדיקת העשן נכשלת — חוזרים לגרסה הקודמת מיד.
- ערכת רגרסיה — 40–80 מקרי בדיקה המכסים תרחישים עיקריים לפני כל שחרור.
- בדיקות חזותיות — השוואת צילומי מסך (Percy או Playwright). כפתור זז ב-20 פיקסלים, פונט השתנה אחרי עדכון — הבדיקה מציגה את ההבדל.
-
רשימות בדיקה למודולים — רשימות מובנות עבור
catalog,iblock,search,catalog.section. לכל מודול יש רשימת בדיקה משלו.
מה קורה במהלך בדיקות עומס?
השאלה היא לא "האם האתר יעמוד בזה" אלא בכמה משתמשים בו-זמנית b_iblock_element_property מתחיל להחזיר שגיאות 500.
| תרחיש | חלק יחסי | זמן תגובה יעד | מה נשבר ראשון |
|---|---|---|---|
| עמוד ראשי | 20% | < 1 שנייה | מטמון מרוכב אם לא מוגדר |
| קטלוג עם פילטרים | 30% | < 2 שניות | MySQL – JOINs כבדים על b_sale_basket |
| עמוד מוצר | 25% | < 1.5 שניות | שאילתות עבור SKU |
| הוספה לסל | 10% | < 1 שנייה | נעילות טבלאות על b_search_content |
| תשלום | 5% | < 3 שניות | מנגנוני משלוח (API חיצוניים) |
| חיפוש | 10% | < 2 שניות | b_iblock_element ללא אינדקסים |
כלים:
- k6 — סקריפטים ב-JavaScript.
- Apache JMeter — קלאסי, לתרחישים מורכבים עם הרשאת קוקיז.
- Yandex.Tank — ויזואליזציה בזמן אמת, אינטגרציה עם Overload.
תוצרים: RPS שיא, זמני תגובה לפי אחוזונים p50/p95/p99, צווארי בקבוק (CPU, RAM, שאילתות MySQL איטיות על sale.order.ajax, מטמון קבצים). המלצות: איזה אינדקס להוסיף, איזו שאילתה לשכתב עם D7 ORM, איפה להפעיל מטמון מרוכב.
אילו תוצרים מקבלים אחרי הבדיקות?
- תוכנית בדיקות עם היקף, עדיפויות וקריטריוני איכות.
- ערכת מקרי בדיקה — פונקציונליים, רגרסיה, עומס.
- דוח תקלות במערכת מעקב (Jira/YouTrack) עם סיווג חומרה.
- בדיקות אוטומטיות (Playwright/Cypress) — ערכת עשן בסיסית ל-CI/CD.
- פרוטוקול בדיקות עומס עם גרפים והמלצות.
- תעודת קבלה אחרי UAT — המאשרת מוכנות להשקה.
אחרי המסירה, אנחנו מספקים ייעוץ חינם למשך חודש — עונים על שאלות בנושא שיפור בדיקות והתאמת תהליכים. צרו קשר כדי לקבל חבילת מסמכים מלאה ובדיקות אוטומטיות.
בדיקות דפדפנים שונים
אנחנו בודקים איפה הקונים באמת נמצאים. הסטטיסטיקות מ-Metrica שלכם חשובות יותר מנתוני שוק כלליים.
סט מינימלי:
- Chrome (2 הגרסאות האחרונות) — עיקר התנועה.
- Safari על iOS — קריטי לתשלום במובייל,
sale.order.ajaxמתנהג לעיתים קרובות בצורה בלתי צפויה. - Yandex.Browser — נתח משמעותי ברוסיה, מבוסס Chromium אבל עם מוזרויות הרחבות.
- Samsung Internet — אנדרואיד מובייל, לעיתים קרובות נשכח.
מכשירים:
- מחשב שולחני: 1920×1080, 1366×768.
- iPhone: 375×812, 390×844 — יש לוודא את התשלום.
- אנדרואיד: 360×800, 412×915.
כלים: BrowserStack למכשירים אמיתיים, Playwright לאוטומציה על Chromium/Firefox/WebKit.
אוטומציה
Playwright — הבחירה העיקרית ל-E2E על Bitrix:
- ריבוי דפדפנים: Chromium, Firefox, WebKit.
- ביצוע מקבילי, המתנות אוטומטיות.
- עובד היטב עם טפסים דינמיים
$USER->IsAuthorized(). - תומך ב-viewports למובייל ובגיאולוקציה.
Cypress:
- רץ בדפדפן — יציב יותר לממשקים דמויי SPA.
- ממשק ויזואלי מצוין לניפוי באגים.
- מגבלה: רק דפדפנים מבוססי Chromium.
PHPUnit לקוד מותאם אישית:
- בדיקות יחידה לרכיבי Bitrix מותאמים אישית ולמודולים.
- בודק לוגיקה עסקית ללא תלות בחזית.
- אינטגרציה עם CI/CD — GitLab CI, GitHub Actions.
UAT – בדיקות קבלה
בדיקה סופית עם הלקוח בסביבת staging עם נתונים אמיתיים:
- מרכיבים יחד רשימת תרחישים קריטיים — 15–20 מסלולי לקוח מרכזיים, לא 200 מקרי בדיקה.
- Staging עם עותק של מסד הנתונים היצרני (נתונים אישיים אנונימיים).
- מעקב תקלות מהיר — Jira/YouTrack, תעדוף לפי חומרה.
- פרוטוקול קבלה — מסמך עם תוצאות, חתימות ומוכנות להשקה.
הזמינו תמיכת UAT ואנחנו מבטיחים שחרור בלי הפתעות.
תהליך QA – משולב, לא מחובר מבחוץ
- ניתוח דרישות — QA משתתף בדיוני משימות, תופס אי-בהירויות. "האם ההנחה חלה על המוצר או על ההזמנה?" — שאלה כזו מראש חוסכת יומיים של ניפוי באגים.
- מקרי בדיקה לפני הפיתוח — תרחישים מוכנים לפני השורה הראשונה של הקוד.
-
סקירת קוד — בדיקות לטעויות Bitrix טיפוסיות: מטמון רכיב שלא נוקה, שאילתות SQL ישירות במקום ORM, חוסר בדיקת
bitrix/error.log. - פונקציונלי → רגרסיה → פריסה.
-
ניטור אחרי שחרור — שגיאות ב-
bitrix/error.log, מדדים ב-Metrica, התראות על שגיאות 500.
אנחנו עובדים עם Bitrix למעלה מ-10 שנים ובדקנו יותר מ-300 פרויקטים בקנה מידה שונים — מחנויות מקוונות קטנות ועד פורטלים ארגוניים עם אינטגרציה ל-1C ו-Bitrix24.
לוחות זמנים
| משימה | משך |
|---|---|
| תוכנית בדיקות | 2–3 ימים |
| בדיקות פונקציונליות (חנות בינונית) | 3–5 ימים |
| ערכת בדיקות E2E אוטומטיות בסיסית (Playwright) | 2–3 שבועות |
| בדיקות עומס + דוח | 1–2 שבועות |
| בדיקות דפדפנים שונים | 2–3 ימים |
| תמיכת UAT | 3–5 ימים |
| תהליך QA מאפס | 3–4 שבועות |
עלות הבדיקות מחושבת בנפרד עבור הפרויקט שלכם. קבלו ייעוץ — נעריך את ההיקף תוך יום עסקים אחד ונספק הערכה ראשונית ותוכנית בדיקות. צרו קשר כדי לדון בפרויקט שלכם ולתאם שיחה.